Appimages, snaps and flatpaks, which one do you prefer and why?
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
Like this guy. Native packages. In the very limited instances I've had to run something "built" it's been an appimage in ~/Downloads which I've later deleted once done with.
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.
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.
Flatpaks. On Mint, the GUI update tool updates both Flatpaks and natively installed packages. It's fantastic.
I just returned to linux after a few years. Mint is so slick and out of the box ready. Gonna stay a bit longer I think.
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.
Flatpak for sure, appimages are okay in certain circumstances and snaps are trash.
Flatpak and Appimages. Flatpaks are the best solution IMO, just better than snaps in about every setting except servers. Appimages are great simply because of their easy portability, just being a single executable. I like having GUI apps in Flatpaks because it separates the updates for those applications from my package manager.
pacman or from source 😎 (i am superiour because i make it harder for myself)
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?
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.
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
package myself; I chose Gentoo (and previously Arch) in part because its reasonably easy to package things there.
Most build systems are covered by eclasses ( libraries) that handle the repetitive minutia every package that build system needs.
Here's the tuba ebuild for example (from GURU, the Gentoo equivalent of the AUR), 90% of it is just listing the dependencies and telling it to use a few eclasses to handle everything else.
Oh, and here's the lemmy back end ebuild, the giant wall of crates is automatically generated/updated from a tool that reads the cargo files. (needed because Gentoo doesn't allow internet access during the build for normal packages so crates are downloaded ahead of time)
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.
Arch users being like "I have it in my AUR. What more could other people ask for ?"
You should realise it's a possibility not to want to change a system just to use (possibly broken) AUR
Which, again, misses the point. Original OP said "install native" replying OP said "but what about (package)" (obviously intending that to be a gotcha) and I replied with "well it's in mine"
I have no idea what debs& rpms are available, nor do i care.
And what is this "possibly broken aur" rubbish ? It's a repository, and it most certainly isn't broken.
Individual packages may be broken but they can be broken in any repository. Are you saying there's never been a broken package in a debian repository ? Lol.
Edit to correct "you" to "OP" as you aren't the original person doing the "whataboutism"
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.
I hope you turn on DCT because docker image downloads are totally insecure by default.
What's DCT? I'm not actually running Docker but Kubernetes.
Docker Content Trust. Its the (off by default and pretty broken) way that docker would verify what it downloads wasn't maliciously modified
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.
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 )
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.
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.
@CrabAndBroom@throwawayish I like flatpacks and their integration into some stores and the ease of update makes me not hate them. Unfortunately, this is where Linux is headed. Containerization and immutability.
Luckily, we will always have lots of distros to choose from.
Out of the three, I prefer Flatpaks. Mainly because they have a nice centralized-capable model for performing updates (but not locked centralized like Snaps are), and I can't say I've personally run into a distro where Flatpaks didn't work.
I haven't taken a look at them from a developer standpoint, but from what I hear the development experience isn't bad? If that isn't the case though, I'd love to hear more about why.
Appimage, but only if I can't get the program to compile from source first.
Appimages don't get updated which I find is a missing feature
Flatpaks for graphical apps and guix for CLI programs and libraries.
For personal use, Flatpak when there's no native option, in most cases. They always seem to work and with Flatseal, you can more finely control permissions and local filesystem access of them.
For servers, if it's a single-purpose VM (like I do with my PiHole/AdGuard servers), I'll also go native. Otherwise, Docker for compatibility and ease of management.
Appimages are good for downloading off sketchy websites, Snaps are good for server CLI apps, Flatpaks are good for GUIs
But honestly they all solve the main issue pretty well
I've used Flatpak, it feels somewhat sluggish;
I had once upon a time used Snap (unwittingly), never again;
Appimages... with a lack of options, they seem to run well, although the two I've used seem to take away quite the chunk of memory.
But if it's a reasonable choice, I'll always go with natively distributed or locally compiled binaries. They may be janky sometimes, but in my opinion they beat the "just ship the entire computer br0" philosophy that clearly comes from the Windows ecosystem.
How does that philosophy come from Windows? Windows was all about tying your application directly to the host OS via the old .net framework and COM. You had to wait for the OS to update before your app could, or the OS could randomly update and break your app
Containers as a technology are almost entirely a Linux thing as well, Windows ships with a full Linux kernel to support it now.
Nix.
If I'm not using the package manager, I use mostly Flatpak. I will use a random AppImage here and there.
I prefer those two because I can pick when I update them, and I've not had a lot of issues so far. I don't like Snap because it reminds me too much of Windows Update. I know it can all be adjusted to my taste, but I already have an option that works out of the box.
Definitly Flatpaks. Although snaps have improved since I last used them. But of all I still prefer the good old shell based Package manager.
I prefer the AUR, but if I have to use one of the three it's gotta be an AppImage these days.
I used to swear by flatpak, but because I'm on nvidia it just turns into a stupidly bloated mess since it never removes older driver versions.
They're certainly not "bad" though, and I use them on my SteamDeck for sure.
I preffered AUR over flatpak before as well but that changed more and more every time a AUR package didn't launch anymore or didn't update anymore because of some build error. I actually started migrating a lot of stuff over to the flatpak version because it just works.
I've had pretty much the opposite experience most of the time. Constantly dealing with flatpaks not opening or other weird issues that would go away as soon as I tried the AUR version or just installed it manually from the repo.
Weird. I've never had an issue with flatpaks, which makes sense since it's exactly the same on all systems. If it didn't launch for you, it shouldn't have for anyone else either, so the issue should have been fixed before the developer released a new version.
Preferring AUR over flatpaks and using nvidia on a Linux system...I think your credibility is lost. :P
Appimages could've been great if they had a store front like Flatpak, so while I do not always prefer Flatpak (because of how big the first download is) I use it the most.
Neither. I exclusively use Nix packages. If I had to pick, AppImage because I can easily extract it to package for Nix :P
Flatpaks work for me pretty well.
I prefer AppImages on my Debian desktops as they normally simply work out of the box (download, start) and I had (many years ago) trouble with snap and flatpak.
Makefile
perfect
i use arch just so i don't have to use any of these
The arch repos are enough for me except two softwares so I downloaded them as appimages. Appimages are enough for my small needs.
I'm still trying them out, but if they work as advertised, then AppImages. That's mostly because I use my desktop and laptop pretty much equally, so being able to copy and AppImage from one to the other and keep going would be really handy.
On a similar note, if a computer dies, being able to just copy and paste them to a new computer, or run them from a portable drive would be great.
yes appimages are good but my problem with them is that when there is a new version i should download them again and again....
Have you met appimageupdater?
None
I prefer all of them (including Snap) we should have a kid together and ask them their preference.
Snaps, hell no. I wouldn't touch anything Canonical TBH.
Appimages are very chaotic.
Fkatpaks leave a bunch of trash after uninstalling.
I use Flatpaks, while they are not perfect, they are improving.
Fkatpaks leave a bunch of trash after uninstalling.
From my experience, most of the things I'd like to delete after uninstalling are in ~/.var/app/(App ID)/.
I don't think I've ever actually found a flatpack in the wild. Not a fan of snaps but have a few appimages that seen to work fine.
None of them
I've only used flatpak and I honestly see no reason to try anything else.
The only issue I've encountered is that Steam games launched by the Steam flatpak occasionally act strange (sometimes they can't locate graphics drivers or connect to online services).
Flatpaks are insecure by design as they don't cryptographically verify their authenticity after download. Snaps too.
Install with a proper package manager that was designed doe security. Most OS package managers are designed with this.
Snaps. Everyone seems to hate them for ideological reasons rather than practical reasons. But for me, they just work. And if Canonical gets out of line, there's already been proof of concepts of third-party snap repositories, so that's a moot point.
Flatpaks seem like a solution in search of a problem to me. Not everything is a gui app, so not sure why the devs aren't supporting cli apps well. But the biggest problem is that most software I use simply isn't available as flatpaks.
And if Canonical gets out of line, there's already been proof of concepts of third-party snap repositories, so that's a moot point.
That's not really a moot point. A proof of concept is much different than an implementable specification. And especially in the commercial space, you'd want to host your own snap repo just for that handful of software you want to customize and then reference upstream for the other things. Snaps, to be useful to that user, need to have the same sort of design considerations apt/deb an yum|dnf|zypper/rpm have about multiple repositories and an implicit promise to not break the 3rd party stores version to version.
Additionally an open source server component was a day one promise from Canonical about Snaps (along with monetization and a functional license model for closed source software) and the gas lighting from Ubuntu about why that stuff isn't here and doesn't appear to be close gets harder to ignore every year it goes on.
Cli apps not being available as flatpaks is a huge oversight. It makes using flatpaks as my main source of applications a non starter.
tbh never looked into snaps flatbacks or appimages. However my instinct as a staunch linux is that anything besides apt-get or apt or aptitude is utter trash. we already have apt, why do people feel the need to divert energies to these unneccessary packagemanagement-fads?
The problem here is that there are so many linux distros that are trying to do their own thing. Sure, a Debian-based distro would use apt, but a lot of the other distros like Void and Fedora use different package managers to suit their needs. I personally use Arch Linux, and that uses pacman which is my manager of preference. There are packages that I cannot find and/or install via pacman and the AUR due to them either not being built as an Arch binary, or being left abandoned by the developer who couldn't bother supporting multiple distros and their package managers, or not having a compatible dependency built for my system.
Flatpaks and AppImages allow for a developer to place an application and all its dependencies in a neatly packaged group. This allows developers to only need to create one package that works on many distros and won't be affected by dependency changes. I use a Flatpak package for Steam because, due to the rolling-release-nature of my distro, sometimes the native install breaks and/or doesn't open properly.
In theory, Snap works in a similar way as the other two, but that is a proprietary package manager that doesn't work on my distro without far much more effort than needed for any proprietary software should ever need to get working ever.
The only real downside to these package managers that I've seen is that the package size is larger than any native install. I am personally fine with this tradeoff however, as I have gotten quite used to building Python container environments recently.
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
Like this guy. Native packages. In the very limited instances I've had to run something "built" it's been an appimage in ~/Downloads which I've later deleted once done with.
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.
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.
Flatpaks. On Mint, the GUI update tool updates both Flatpaks and natively installed packages. It's fantastic.
I just returned to linux after a few years. Mint is so slick and out of the box ready. Gonna stay a bit longer I think.
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.
Flatpak for sure, appimages are okay in certain circumstances and snaps are trash.
Flatpak and Appimages. Flatpaks are the best solution IMO, just better than snaps in about every setting except servers. Appimages are great simply because of their easy portability, just being a single executable. I like having GUI apps in Flatpaks because it separates the updates for those applications from my package manager.
pacman or from source 😎 (i am superiour because i make it harder for myself)
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?
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.
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.
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
package myself; I chose Gentoo (and previously Arch) in part because its reasonably easy to package things there.
Most build systems are covered by eclasses ( libraries) that handle the repetitive minutia every package that build system needs.
Here's the tuba ebuild for example (from GURU, the Gentoo equivalent of the AUR), 90% of it is just listing the dependencies and telling it to use a few eclasses to handle everything else.
Oh, and here's the lemmy back end ebuild, the giant wall of crates is automatically generated/updated from a tool that reads the cargo files. (needed because Gentoo doesn't allow internet access during the build for normal packages so crates are downloaded ahead of time)
Then a tgz that I unpack to /opt/ or somewhere in ~/
Tuba is in the AUR
aur is limited to arch based distros only
And rpms are for redhat tree, so ?
OP said
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.
Arch users being like "I have it in my AUR. What more could other people ask for ?"
You should realise it's a possibility not to want to change a system just to use (possibly broken) AUR
Which, again, misses the point. Original OP said "install native" replying OP said "but what about (package)" (obviously intending that to be a gotcha) and I replied with "well it's in mine"
I have no idea what debs& rpms are available, nor do i care.
And what is this "possibly broken aur" rubbish ? It's a repository, and it most certainly isn't broken.
Individual packages may be broken but they can be broken in any repository. Are you saying there's never been a broken package in a debian repository ? Lol.
Edit to correct "you" to "OP" as you aren't the original person doing the "whataboutism"
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.
I hope you turn on DCT because docker image downloads are totally insecure by default.
What's DCT? I'm not actually running Docker but Kubernetes.
Docker Content Trust. Its the (off by default and pretty broken) way that docker would verify what it downloads wasn't maliciously modified
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.
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.
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
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.
@CrabAndBroom @throwawayish I like flatpacks and their integration into some stores and the ease of update makes me not hate them. Unfortunately, this is where Linux is headed. Containerization and immutability.
Luckily, we will always have lots of distros to choose from.
Out of the three, I prefer Flatpaks. Mainly because they have a nice centralized-capable model for performing updates (but not locked centralized like Snaps are), and I can't say I've personally run into a distro where Flatpaks didn't work.
I haven't taken a look at them from a developer standpoint, but from what I hear the development experience isn't bad? If that isn't the case though, I'd love to hear more about why.
Appimage, but only if I can't get the program to compile from source first.
Appimages don't get updated which I find is a missing feature
Flatpaks for graphical apps and guix for CLI programs and libraries.
For personal use, Flatpak when there's no native option, in most cases. They always seem to work and with Flatseal, you can more finely control permissions and local filesystem access of them.
For servers, if it's a single-purpose VM (like I do with my PiHole/AdGuard servers), I'll also go native. Otherwise, Docker for compatibility and ease of management.
Appimages are good for downloading off sketchy websites, Snaps are good for server CLI apps, Flatpaks are good for GUIs
But honestly they all solve the main issue pretty well
I've used Flatpak, it feels somewhat sluggish;
I had once upon a time used Snap (unwittingly), never again;
Appimages... with a lack of options, they seem to run well, although the two I've used seem to take away quite the chunk of memory.
But if it's a reasonable choice, I'll always go with natively distributed or locally compiled binaries. They may be janky sometimes, but in my opinion they beat the "just ship the entire computer br0" philosophy that clearly comes from the Windows ecosystem.
How does that philosophy come from Windows? Windows was all about tying your application directly to the host OS via the old .net framework and COM. You had to wait for the OS to update before your app could, or the OS could randomly update and break your app
Containers as a technology are almost entirely a Linux thing as well, Windows ships with a full Linux kernel to support it now.
Nix.
If I'm not using the package manager, I use mostly Flatpak. I will use a random AppImage here and there.
I prefer those two because I can pick when I update them, and I've not had a lot of issues so far. I don't like Snap because it reminds me too much of Windows Update. I know it can all be adjusted to my taste, but I already have an option that works out of the box.
Definitly Flatpaks. Although snaps have improved since I last used them. But of all I still prefer the good old shell based Package manager.
I prefer the AUR, but if I have to use one of the three it's gotta be an AppImage these days.
I used to swear by flatpak, but because I'm on nvidia it just turns into a stupidly bloated mess since it never removes older driver versions. They're certainly not "bad" though, and I use them on my SteamDeck for sure.
I preffered AUR over flatpak before as well but that changed more and more every time a AUR package didn't launch anymore or didn't update anymore because of some build error. I actually started migrating a lot of stuff over to the flatpak version because it just works.
I've had pretty much the opposite experience most of the time. Constantly dealing with flatpaks not opening or other weird issues that would go away as soon as I tried the AUR version or just installed it manually from the repo.
Weird. I've never had an issue with flatpaks, which makes sense since it's exactly the same on all systems. If it didn't launch for you, it shouldn't have for anyone else either, so the issue should have been fixed before the developer released a new version.
Preferring AUR over flatpaks and using nvidia on a Linux system...I think your credibility is lost. :P
Appimages could've been great if they had a store front like Flatpak, so while I do not always prefer Flatpak (because of how big the first download is) I use it the most.
there is a store for them called appimage pool which is written in flutter and its also an appimage itself. https://appimage.github.io/AppImagePool/
Wow, thank you for this.
Pacman > Flatpak > won't use it
Neither. I exclusively use Nix packages. If I had to pick, AppImage because I can easily extract it to package for Nix :P
Flatpaks work for me pretty well.
I prefer AppImages on my Debian desktops as they normally simply work out of the box (download, start) and I had (many years ago) trouble with snap and flatpak.
Makefile
perfect
i use arch just so i don't have to use any of these
The arch repos are enough for me except two softwares so I downloaded them as appimages. Appimages are enough for my small needs.
I'm still trying them out, but if they work as advertised, then AppImages. That's mostly because I use my desktop and laptop pretty much equally, so being able to copy and AppImage from one to the other and keep going would be really handy.
On a similar note, if a computer dies, being able to just copy and paste them to a new computer, or run them from a portable drive would be great.
yes appimages are good but my problem with them is that when there is a new version i should download them again and again....
Have you met appimageupdater?
None
I prefer all of them (including Snap) we should have a kid together and ask them their preference.
Snaps, hell no. I wouldn't touch anything Canonical TBH.
Appimages are very chaotic.
Fkatpaks leave a bunch of trash after uninstalling.
I use Flatpaks, while they are not perfect, they are improving.
From my experience, most of the things I'd like to delete after uninstalling are in
~/.var/app/(App ID)/.I don't think I've ever actually found a flatpack in the wild. Not a fan of snaps but have a few appimages that seen to work fine.
None of them
I've only used flatpak and I honestly see no reason to try anything else. The only issue I've encountered is that Steam games launched by the Steam flatpak occasionally act strange (sometimes they can't locate graphics drivers or connect to online services).
Flatpaks are insecure by design as they don't cryptographically verify their authenticity after download. Snaps too.
Install with a proper package manager that was designed doe security. Most OS package managers are designed with this.
Snaps. Everyone seems to hate them for ideological reasons rather than practical reasons. But for me, they just work. And if Canonical gets out of line, there's already been proof of concepts of third-party snap repositories, so that's a moot point.
Flatpaks seem like a solution in search of a problem to me. Not everything is a gui app, so not sure why the devs aren't supporting cli apps well. But the biggest problem is that most software I use simply isn't available as flatpaks.
That's not really a moot point. A proof of concept is much different than an implementable specification. And especially in the commercial space, you'd want to host your own snap repo just for that handful of software you want to customize and then reference upstream for the other things. Snaps, to be useful to that user, need to have the same sort of design considerations apt/deb an yum|dnf|zypper/rpm have about multiple repositories and an implicit promise to not break the 3rd party stores version to version.
Additionally an open source server component was a day one promise from Canonical about Snaps (along with monetization and a functional license model for closed source software) and the gas lighting from Ubuntu about why that stuff isn't here and doesn't appear to be close gets harder to ignore every year it goes on.
Cli apps not being available as flatpaks is a huge oversight. It makes using flatpaks as my main source of applications a non starter.
tbh never looked into snaps flatbacks or appimages. However my instinct as a staunch linux is that anything besides apt-get or apt or aptitude is utter trash. we already have apt, why do people feel the need to divert energies to these unneccessary packagemanagement-fads?
The problem here is that there are so many linux distros that are trying to do their own thing. Sure, a Debian-based distro would use apt, but a lot of the other distros like Void and Fedora use different package managers to suit their needs. I personally use Arch Linux, and that uses pacman which is my manager of preference. There are packages that I cannot find and/or install via pacman and the AUR due to them either not being built as an Arch binary, or being left abandoned by the developer who couldn't bother supporting multiple distros and their package managers, or not having a compatible dependency built for my system.
Flatpaks and AppImages allow for a developer to place an application and all its dependencies in a neatly packaged group. This allows developers to only need to create one package that works on many distros and won't be affected by dependency changes. I use a Flatpak package for Steam because, due to the rolling-release-nature of my distro, sometimes the native install breaks and/or doesn't open properly.
In theory, Snap works in a similar way as the other two, but that is a proprietary package manager that doesn't work on my distro without far much more effort than needed for any proprietary software should ever need to get working ever.
The only real downside to these package managers that I've seen is that the package size is larger than any native install. I am personally fine with this tradeoff however, as I have gotten quite used to building Python container environments recently.