Appimages, snaps and flatpaks, which one do you prefer and why?
Flatpak is my preference since it supports multiple remotes (repos) and sandboxing. With flatseal tweaking the sandbox is also easy.
Snaps work great on Ubuntu and support cli tools as well as system components. But their sandboxing doesn’t work on many distros and the one and only repo is controlled by one company. If I’m not on Ubuntu, I don’t see any reason to choose it over flatpak.
Appimages are great for putting on a USB stick or keeping a specific version of software. But I want to install software from a trusted repository, which Appimages support at best as an afterthought.
None. I prefer native packages. AUR usually has me covered and hasn’t broken my system…ever, really. Yet, anyways. (Well, it might have broken my Manjaro install, but it is Manjaro, so i probably sneezed wrong)
…but, if I had to pick one? Flatpaks. Outta the three, they’ve given me the least trouble and just work right out the gate. Still prefer native packages tho
I prefer flatpacks. There’s nothing wrong per se about snaps, it’s just that they are kinda slow, and Canonical is untrustworthy.
Appimages are to be avoided, imo. They are no better than downloading random crap like on Windows.
Flatpak – It’s not without it’s own issues, of course, but it does the job. I’m not fan of how snaps are designed, and I don’t think canonical is trustworthy enough to run a packaging format. Appimages are really just not good for widespread adoption. They do what they are designed to do well, but I don’t think it’s wide to use them as a main package format.
None of the above. Native debs/rpms/whatever for desktops, docker images for servers.
but what about the apps that are not in the official repository?
for example tuba the mastodon client
Then a tgz that I unpack to /opt/ or somewhere in ~/
Tuba is in the AUR
aur is limited to arch based distros only
aur is limited to arch based distros only
And rpms are for redhat tree, so ?
OP said
None of the above. Native debs/rpms/whatever for desktops, docker images for servers.
Your example package is readily available in my distro in native was my point. If your distro doesn’t have it then maybe you need to change distros.
Do you check packages you install from the aur? I ask, because it seems like people don’t. I did, and it was a pain in the ass, and that’s why I stopped using arch and arch based distros.
The aur has now broke your system congrats
Nope, nothing broke but
Aborting… error: failed to build ‘tuba-0.4.0-0.1’:
and I can’t be arsed troubleshooting why for a package I have no intention of using. LOL
Basically this. Not saying the “AUR breaking your system” thing isn’t, well, a thing but I get “error aborting installation” warnings waaaaay more often than my system just outright dying because of an AUR package (which is to say, it’s never actually happened to me).
And usually, when I see that warning, I go “kay, not even gonna bother” because if I ignore it and try to brute force the install…yeah, that potential breakage is on me, not the AUR
Ditto. I’ve literally never had an aur package break my system either, but like you if it doesnt want to play first go, I’ll almost always find an alternative.
pacman or from source 😎 (i am superiour because i make it harder for myself)
Flatpacks give me the least trouble so I guess those. All though appimages seem alright too. Snaps however seem to never want to install. I like the idea of easy one click installs for every distro but I think we are a few years away from that.
yes flatpaks are great but their only downside is the download size of an application
Flatpaks are quickly becoming my favorite. I’ve rarely had issues with App Images, but they are clunky and messy. Flatpaks are where it’s at IMO.
Snaps are pewpy.
I’ve rarely had issues with App Images, but they are clunky and messy.
How so?
You have to use a separate application to manage them, otherwise they act as portable .exe files in windows, just laying around in a folder you have to manually link to or navigate to to run. You have to set them as executable manually otherwise you can’t run them in certain distros, or they force you to click through the prompt. They aren’t listed in the general packages installed on your system.
They are often bulky in size, and depending on the distro and software, sometimes they don’t work properly. And again, without independent management software, they have to be manually updated independently.
They aren’t bad, they just arent as good as other options IMO. I like App Images for random small programs, or some games too, they aren’t a problem. But for large programs I want to use frequently, they are just less convenient.
I prefer Flatpaks by a wide margin. This presentation by openSUSE’s Richard Brown is a great watch for those looking for a thorough comparison.
Same here. I don’t really like Appimages because (AFAIK, unless there’s some tool I don’t know about) you have to just check each one individually for updates which feels old fashioned, like Windows.
Snap is just a worse version of Flatpak as far as I can tell, so I don’t bother with it.
none of them. I don’t like the idea of putting security updates in the hands of the developers of each individual application I use.
Oh your app only works with an old broken insecure version of the library? Fuck you then, you can’t just decide to install and use the insecure version.
Interesting idea, didn’t think about this before. Still you could argue because of the sandboxed nature, those outdated libraries should’nt be much of a problem?
example, suppose there was a bug in openssl’s prime number generation code. It will generate insecure keys.
No amount of sandboxing can help with that. The bug is discovered and the next day I run ‘pacman -Syu’ (I use arch, btw) and the problem is gone systemwide, except for any flatpaks or appimages etc. Those will only get updates (and stop leaking my data) if and only if its maintainer actually gives a fuck, is still alive and active. If not, you’re sol
I am very certain the most appropriate person to update the software would be the developer itself. So when suddenly for flatpaks & co the responsibility of updating libraries is put on the flatpak package maintainer for ANYTHING used in that container… it doesn’t sound optimal.
Still your example is a very edge-case scenario, because it would create a static vulnerability.
Containers are a form of static linking. just because they are different files inside the image, doesn’t mean they’re not effectively statically linked, if they can only be upgraded together
If I update my shared libraries, that application uses its own ‘statically linked’ libraries and doesn’t pick up the changes. Exactly like what happens with a normal statically linked binary.
I avoid static linking like the plague.
ELI5?
sandboxing protects apps from each other. If there’s a bug in some library that somehow leaks some security keys or something, sandboxing doesn’t help.
“leaks security keys of the app itself”, it can’t leak anything outside of the container?
AppImage is a nice idea, and avoids some of the performance overheads from containerised systems, but lacks a reasonable self update mechanism, lacks code signing and the desktop integration (having icons show up in the start menu) is poorly implemented.
Snap is essentially a Canonical-proprietary apt replacement with some very serious drawbacks around performance and desktop integration (themes).
Flatpak has some drawbacks but it largely achieves it’s design goals, and actually provides some advantages over installing things via the system package manager.
debs
Appimage, but only if I can’t get the program to compile from source first.
Flatpak is the best one imo. Never used appimages, and snap is pure trash (close source, slow, made by canonical). Overall, native packages are imo the way to go, but flatpak is also fairly good.
i use arch just so i don’t have to use any of these
