How do you guys get software that is not in your distribution’s repositories?
People spend a lot of time on this one. It must suck to be losing to snap.
There is no software that is not in AUR. I use arch, BTW.
But yeah, sometimes I just compile from source, if needed.
That’s exactly what the vast majority of AUR packages do already? You can also apply modifications to the compilation process if needed.
Indeed, but don’t underestimate my laziness.
My software, QuickDAV, is not in the AUR. It’s open source, and I release it only as an AppImage, because I am lazy.
I guess we should have added the word “notable”
I’m terribly sorry, you left the door wide open ;)
I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?
Ouch. xD
It’s super easy to create. And you distribute it on your own, so it’s basically like an installer exe on Windows. In my mind it’s one step above only offering source code.
I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?
The appimage is basically just
git clone->make->make install DESTDIR=/path/to/AppDir->wget appimagecreationtooland finallyappimagecreationtool /path/to/AppDirand that’s it you have your appimage.appimagecreationtool being several tools that can create the appimage from an AppDir, like linuxdeploy, linuxdeploqt, go-appimage, etc
And that on itself isn’t complex either, it if basically running ldd on the binary, then copy those libraries into the AppDir and finally run patchelf to patch the paths in the binaries and libraries, suyu uses a deploy script instead of using those tools, which I’ve recently forked and began expanding.
I don’t know how easy it is to make a flatpak or snap, but I do know the dev of zen browser hates dealing with the flatpak and iirc right now the flatpak is outdated as result.
EDIT: Also lite-xl has been making a flatpak for like 2 years and it isn’t ready yet.
There’s so much random, useful software distributed only as appimages. But not notable enough for packaging fanboys.
Gatekeeping the word “software” here?
Here’s something not in the AUR. Tested on archClearly we need an Arch version of rule 34 and rule 35
Rule 34a: If linux software exists, it’s in the AUR. No exceptions.
Rule 35a: If linux software is not in the AUR, it will be made available in the AUR.
This is such a weird gatekeeper take
Its a joke lol, why are you so serious all the time
I don’t intend on pushing that one to the AUR. It’s not worth it.
Maybe I’ll make an AppImage at most.I don’t know any formal requirements for it being on AUR, but I just feel like this one does not fit there.
Sorry, I’ve already posted the new internet rules and they took immediate effect, I’ll have to report this incident to…the council.
Someone will put the AppImage in AUR
i use arch based btw (I love my Manjaro and it’s AUR support) :>
Rpg paper maker
Though the Linux version is now in a “do not use” state. The developer decided to just make it into a web app because it was only working on Ubuntu
Native package manager > Native binaries > AppImage > Flatpak.
Yes, snap isn’t even on the scale.
App images are a very Windows way to do things. They bundle everything so they are big
They are windows, but the linux version of dll-hell across distros and distro versions makes windows dll hell look quaint.
If someone had addressed that better it would be one thing, but binary interoperability is infinitely broken, so app image is actually an improvement.
Isn’t the gnome runtime alone 2GiB? You know how many appimages that is?
Not to mention you are unlikely to only use one runtime.
Then again, loads of apps share that runtime. And if other runtimes have same stuff as that GNOME runtime, the shared parts are on your disk only once. It’s pretty smart in how it works.
I tested installing some web browers, kdenlive, yuzu and libreoffice and without knowing I ended up with 3 different runtimes and the total storage usage (with deduplication) was 4.79 GIB.
Meanwhile with 33 appimages that I have (which includes same flatpak apps I mentioned) are using 2.2 GiB.
It doesn’t matter if they share if in the end they end up using several times more storage than the appimage equivalent.
You should test it out with those 33 installed as flatpak. If you end up with 4.7GB for runtimes, that’s basically nothing these days as far as storage goes for that amount of programs. More you have, more you benefit from shared runtimes. I doubt it’ll be less than AppImages but it’s usually the starting runtime space use that shocks people.
Here someone tested it with 163 flatpaks and the runtimes used 8.7GB. With the top 5 most used runtimes covering 128 of those flatpaks.
https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/
I just checked out mine, I have 34 apps and runtimes use 3,1GB
It doesn’t matter if they share if in the end they end up using several times more storage than the appimage equivalent.
Well we are talking about two gigs, after all. Unless you’re using an embedded system, it’s not a much of a concern if you ask me. But it is more, true
. If you end up with 4.7GB for runtimes, that’s basically nothing these days
Yes but that wasn’t the original comment I replied to was about.
163 flatpaks and the runtimes used 8.7GB
163 flatpaks using 8.7 GiB means that the average flatpak is using 54.6 MiB.
That’s good the other time I got this linked: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users
Which is no good as in that example there was 173 flatpaks using 27.66 GiB, average 160 MiB, while in your case the average flatpak is using 91 MiB.
This is what I have with appimages:
In this case the average appimage is using 69 MiB, though there is one outliner which is the Steam appimage that I have there (470 MiB) which is an entire conty container with its own video drivers and everything, without it the average would be 56 MiB.
I know this doesn’t matter these days but once again that wasn’t what the original comment was about.
Well we are talking about two gigs, after all. Unless you’re using an embedded system, it’s not a much of a concern if you ask me. But it is more, true
Thanks for the link showing an average flatpak using 54 MiB though, didn’t think it was possible lol.
WAIT I just took a deeper look at the link, isn’t that guy just showing the runtimes without the applications using 8.7 GiB?
Yes but that wasn’t the original comment I replied to was about.
I know this doesn’t matter these days but once again that wasn’t what the original comment was about.
I agree, it was just about the size differences. I just think it’s good to bring up since there’s many confused about the flatpak size use. Often people might want to install some small app and they’re hit with gigs of stuff and come off thinking that’s the same for every app, which would be insane of course.
WAIT I just took a deeper look at the link, isn’t that guy just showing the runtimes without the applications using 8.7 GiB?
Yes it’s specifically comparing runtimes. Same for my number, I was calculating how much the runtimes used.
Ran out of space on a 30GB partition when trying around 10 smallish programs as flatpaks. Runtimes are shared in theory but not in practice.
If you allocate 30 GB for / that seems pretty low these days for a desktop system. If you don’t have much space, it’s always best to go with regular repository packages
Here someone had 163 flatpaks and it used 8,7GB in runtimes. So I’m guessing the 30GB number is for whole of /.
I just checked out mine, I have 34 apps and runtimes use 3,1GB
Runtimes are shared in theory but not in practice.
I think three runtimes (newest freedesktop, KDE and GNOME) cover 90% of my flatpaks. Then there’s programs that use some EOL’d runtime and never get updated, which sucks
It was on a phone, and 25 GB was Flatpak
I’m a technically savvy but new to Linux user who installed Mint as my primary OS about a month ago. So far I’ve used Flatpaks and AppImages without any issue and haven’t come across snaps. Would you explain the differences and why I would care about one over another?
At the end of the day, they’re just different ways of reaching the same goal: universal packages for Linux. I personally use them interchangeably depending on the application and use case.
There are some packages that definitely work better and are intended to be used and installed via your native package manager (if they rely on system libraries and whatnot). But using either a Flatpak or AppImage results in the same experience - in my experience. It’s a personal preference.
IMO flatpaks are the future of installing linux apps. The comment you replied to lives in the past. System package manager should be for system binaries, not for applications.
But I like my applications years out of date and I think its good that every distro has to spend manhours on packaging it individually.
lmao you joke but half this thread is exactly that opinion
I see the appeal for the package manager for a lot of things, but space got so incredibly cheap and fast that duplication is way less of a deal than the effort to make stuff work the traditional way. But im not a real linux user. I don’t like tinkering, I want to download something and it works. And the amazing thing is we can have both. If people like spending time to package something be my guest.
The funniest interaction I had recently. I downloaded a program that isn’t in my package manager or had any sort of flatpack/appimage so I downloaded it as a deb and it didn’t run because of some dependency. So I could clone the git and build it from source which might have worked, but I was too lazy to. So I just downloaded the windows exe and ran it through wine, which worked flawlessly.
I don’t like tinkering, I want to download something and it works.
And this is what’s keeping Linux at bay. Normies are that to the extreme. They want something that is as simple and resilient as possible, they couldn’t care less about the dependencies or even know what they are. They want
a programan app and just install it from an “app store” if possible.you are a real linux user don’t let some neckbeard tell you otherwise :P
And the last three aren’t even an option in the enterprise unless your CTO is 24.
Not a fan of AppImages myself. For an universal format it has surprising amount of issues with different distros, in my experience. And the whole Windows style “go to a website, download the AppImage, if you want to update it, go to the web page again and download it again” is one thing I wanted to get away from. At least they don’t come with install wizards, that clicking through menus thing was a pain.
For one off stuff I run once and never need again, AppImage is alright. But not being built-in with sandboxing, repos, all that stuff, it just seems like a step back.
I ran into the same issues, mentally, when trying out AppImages for the first time - but my attitude changed once I found and started using this tool: https://github.com/ivan-hc/AM
Glad you like AM.
So it’s Scoop, but for Linux? (That’s a compliment. I love Scoop.)
Artix repos > Arch repos > existing AUR package > create my own AUR package
No need to use any of these flatpak/appimage/snaps when I can just make a package for my distro. Most software is not difficult to package.
This may be true from your perspective but won’t sway over many newbies / plebs who don’t have the knowledge (yet) or who simply do not have or want to take the time for self packaging.
And flatpak, snap and appimage tend to become the standard to get verified, tried and tested software hosted & supported by the official maintainers or the company behind the software.
Now to the personal part:
There was a time when I was motivated enough to get packages from user repos - I actually never was motivated enough to do self packaging so maybe I have missed something world changing - but I got so tired of having to figure out the missing “optional” dependencies that meant the software wasn’t working as expected and having to trust 3rd party maintainers when most stuff on flathub was “install & ready” and officially supported or at least hosted by a “verified” source. And maybe distro xyz has a mindblowing solution to all my problems but for the moment I am happy with what I have and not looking for yet another distrohopping and yet another point was whilst distrohopping it was soo easy that I could use the same install.sh containing all my favourite flatpak apps & the “applications” folder containing my favourite appimages no matter if I was on a Debian, RedHat, Arch, … based distribution.
I never claimed I was trying to “sway over newbies”? Do what you want, this is just my personal preference.
My bad, I didn’t emphasize the Your-way-is-perfectly-fine-part at all and focused more on underlining how it doesn’t work for everyone which made it look like I was completely opposed to you.
I wanted to say that both ways, flatpak/snap/appimage and self packaging / user repos are perfectly fine in their ways. The first may be more targeted towards newbies and people who do not want to hassle around with dependencies and the latter is for the more experimental kind of person.
If it works for you and you are happy then there is no reason to change anything. Having the freedom to decide how our OS should be is what drove most of us to Linux in the first place.
In that regard I fully agree with you and especially with “Do what you want, this is just my personal preference.”
Native binaries
Wow a reference to those Mac Vs PC ads from like 15 years ago
I am fairly certain the original version of this meme has red shirt saying Linux and getting beat up
They stopped that ad campaign about 15 years ago, and they started it closer to 20 years ago.
Install from source if there isn’t a repo for the software.
Hardcore
Way back in the before times there was only the source.
If I could, I’d compile all my software from source. Unfortunately, it seems a lot of open source developers don’t like writing software in C, which means the burden of sorting through dependancy-hell has been deferred to my shoulders instead.
In that case install Gentoo. Compiling everything from source is its thing. And on the way it will resolve all the dependencies for you. The dependencies you want.
If you don’t compile from source, do you even Linux?
AUR changed my life
Did someone’s script wipe out your tax returns?
Linux From Scratch user detected
Ah … yeah … totally. I would never use some filthy peasant distro like Mint. No sir! Never never ever!
Or Slackware
Or gentoo.
If not in Fedora repos or any Copr, then AppImage (manage using Gear Lever for that ease of use) then Flatpak
Compile from source.
Every February, I emerge qtwebengine to keep us warm.
Lol. It’s not the groundhog we should be watching, then?
deb
If it’s C or C++, I get the source from the project’s GitHub / GitLab / Source Hosting thing and compile it for myself.
For programming languages that I don’t read, I usually use the AUR.Also,
- GoG for games
- Xilinx website, for that one time, I got the ISE
- AppImage sometimes
God that’s painfully me.
Except I moved to lxc and zfs with homebrew scripts for most now, pass containers around the network like candy, including an arch lutris one.
Nix, if not in nix pkg for nix, then nix
I understand appimages. I use them exclusively. Can someone explain what flatpak and SNAP are and how they work? I have autism so please be as clear and concise as possible?
The easiest way to think of it is flatpaks are AppImages with a repository and snaps are flatpaks but bad.
That has benefits and detriments. Appimages contain everything they need to run, flatpak’s mostly do, but can also use runtimes that are shared between flatpaks.
All flatpaks are sandboxed, which tends to make them more secure. AppImages can be sandboxed, but many aren’t.
Flatpaks tend to integrate with the host system better, you can (kinda) theme them, their updates are handled via the flatpak repo, and they register apps with the system.
AppImages are infinitely more portable. Everything’s in one file, so you can pretty much just copy that to any system and you have the app.
That was a fantastic explination, but you forgot to explain SNAP. Oh snap, you forgot SNAP. Intrusive though won. So what is SNAP, how does it work, and why is it bad?
Yeah, sorry couldn’t resist.
snaps are very similar to flatpaks and, honestly, is technically better in a lot of ways.
Snap can be used for basically an entire system, while flatpak is limited to graphical apps. (Ubuntu core is built basically entirely off snaps.)
Snap is controlled by canonical, and the backend for the snap repo is entirely closed source. I’ve heard snaps are also easier for developers to work with, but I haven’t experienced that side of them.
Snaps automatically update by default where flatpaks don’t.
Snaps also get treated as loopback devices when they’re installed, which bloats a lot of utilities. (And they keep a few old versions around which makes it even worse). For example, you could run
lsblkand if you’re using snaps like 90% of it will be snaps you’ve installed instead of actual devices.Flatpaks are also noticeably faster to start up, which for desktop apps matters, but wouldn’t really matter for a server that’s aiming for a lot of uptime.
The loopback device issue is the main reason I don’t use snaps. I also like flatpak being completely open, but realistically that doesn’t matter for much. There used to be an open snap store, but that shut down because nobody used it.
I tried to install Ubuntu and it kept uninstalling Command Center every reboot. Not a fan of SNAPs. Or Canonical. But thanks for the explination.
Yeah, imo the problems solved by using snaps for core system stuff are better solved with immutable distros, and I see very little reason to use snaps for anything else.
