Appimages, snaps and flatpaks, which one do you prefer and why?
As far as I know, Flatpaks have the best foundation currently, there are a number of issues, but they are fixable and not entirely by design. And with Fedora Silverblue/Kinoite and OpenSUSE MicroOS you can really see how native debs/rpms/whatever isn’t really that good of an idea for the average user and Flatpak is a solution to that.
Appimages at a glance seems like a perfect solution for apps that for some reason or another needs to be kept outdated. But there is (was?) an issue of it not really bundling everything it needs, it looks and behaves as it is portable, but as far as I’m aware, it really isn’t.
And then there’s Snap. Yeah, that one is just weird, it honestly just doesn’t feel like a proper solution to any of the problems it tries to fix.
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
deleted by creator
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.
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.
You know they flatpaks doesn’t verify the packages it downloads from your “trusted” repository, right?
Snaps is too well controlled by Canonical and does have it’s limits.
Flatpaks can be very secure, and works in most distros. It is one of my favorites.
AppImages are real easy, and is designed to work on most distros. The only problem is that many apps aren’t current. So I don’t recommend it unless an app provides it on their own sites. AppImages are often made by somebody else.
Flatpaks are not secure. Please don’t spread misinformation.
Flatpak for sure, appimages are okay in certain circumstances and snaps are trash.
pacman or from source 😎 (i am superiour because i make it harder for myself)
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.
You can sign AppImages.
Real talk? I genuinely don’t care. I have actual work that needs to get done. I’m going to use whatever I can to make that faster/easier. Of all the decisions I need to make in a day, this is a pretty inconsequential one.
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
And, uhh, security?
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.
Snap isn’t really closed source, it’s common misconception, the closed source is only backend (canonical servers), the snap core itself, which is installed on Ubuntu, is fully open source
Edit: snap definitely sucks tho
@KotoWhiskas @sohrabbehdani @Rega If you can’t effectively use it without the closed source part being open doesn’t mean much.
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.
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?
Although I mostly use native software, I find AppImages useful for testing beta software, since they’re one file and easy to try out.
For example: I’ve been using it with the Krita 5.2 beta and I have also used it before for Godot betas.
I use Flatpak when the native package doesn’t work properly or isn’t updated at the rate I’d like, although there are cases where I will use it for other reasons, like sandboxing when I don’t want an app to have access to everything.
I have never used snaps.
Flatpaks because their updating works (compared to my experience with Appimages) and the Apps starting instantly (compared to my limited experience with snaps). But sadly, a lot of production software doesn’t want to support either of this package formats? I haven’t seen support from Davinci Resolve or Mari, as an example.
those softwares are released with their own installer ( davinci resolve for example )
Not sure if one would call this support, but technically Davinci Resolve can be installed as a flatpak.
