Appimages, snaps and flatpaks, which one do you prefer and why?
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.
debs
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?
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.
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.
Flatpak for sure, appimages are okay in certain circumstances and snaps are trash.
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?
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.
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 the above. Native debs/rpms/whatever for desktops, docker images for servers.
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
but what about the apps that are not in the official repository?
for example tuba the mastodon client
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.
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”
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.
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 ~/
Flatpaks for graphical apps and guix for CLI programs and libraries.
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 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.
None of them
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.
