I am currently using Linux Mint (after a long stint of using MX Linux) after learning it handles Nvidia graphics cards flawlessly, which I am grateful for. Whatever grief I have given Ubuntu in the past, I take it back because when they make something work, it is solid.
Anyways, like most distros these days, Flatpaks show up alongside native packages in the package manager / app store. I used to have a bias towards getting the natively packed version, but these days, I am choosing Flatpaks, precisely because I know they will be the latest version.
This includes Blender, Cura, Prusaslicer, and just now QBittorrent. I know this is probably dumb, but I choose the version based on which has the nicer icon.
I don’t like flatpak or snap or any of them. System libraries exist for good reason, just because your computer is stupid fast and you have enough disk for the library of Congress a couple times over doesn’t mean you should run a veritable copy of your whole operating system for each program. IMO it’s lazy.
Sandboxing is a different thing though, if that’s the purpose then it’s doing it right.
I have a ton of flatpaks which means packages are shared between them, so no it’s not lazy or a copy of the whole system. It makes a ton of sense for stability.
Updates are diff’s so downloading and updating is fast. Not entire packages.
Making every package work with only a certain version of a dependency and hoping it is stable doesn’t make a lot of sense.
You’ve just moved the packaging problem from distributions to app developers.
The reason you have issues is historically app developers weren’t interested in packaging their application so distributions would figure it out.
If app developers want to package deb, rpm, etc… packages it would also solve the problem.
Sure. Except you gain universal compatibility for all distros that have flatpak and aren’t building all the different package formats. Makes it much more attractive for actual developers to package since it’s only done once.
There’s no right answer here, but there are definite benefits.
I’ve had many little issues since I moved to Linux years ago, most of which would never have been an issue if flatpaks were there at the time. My experience has been better with them.
Makes it much more attractive for actual developers to package since it’s only done once.
I maintain a few apps that are included into some distributions with no participation from my side apart from tagging what I consider releases in my git repo. How is doing something only once is more attractive as not doing it at all?
Because you can make sure it was done right. You don’t have to worry about bugs or other issues being the result of faulty packaging if you’re the one doing the packaging. Plus It makes reproducing bugs easier when everyone’s using the same package, and declaring the flatpak as the official package makes it much more likely that people will use the flatpak.
You know you can have many versions of a library on your system at once, right?
As long as they don’t cause conflicts. You know dependency hell is a thing right? The reason flatpaks were thought up in the first place? Right?
I see your point, and I agree. No need to spend resources just because we have them.
Sandboxing is definitely a benefit, but alas as I am learning I have no control of it’s permissions, so that can potentially go wrong.
You can manage Flatpak permissions with Flatseal.
Great! I knew it was possible. That is one less argument against it.
Flatseal is super easy for anyone with a tech background to use. You can very quickly expand or reduce the access an app has to your system. Even below what the app comes with by default.
I do kinda wish the guis for installing flatpak apps were more forthcoming with the permissions, and possibly integrated some of the features of flatseal so you could modify the permission set before installing.
It does seem pretty intuitive.
Honestly I just sometimes want the app to see a file outside of Downloads.
For a long time now, if a flatpack is available and maintained, I use it.
I briefly considered getting into Fedora Silverblue, and I still may for this very purpose.
If you switch everything you can to flatpaks and use distrobox for other apps before you switch you’re pretty close (better than toolbox and recommend layering it if you do switch to Silverblue).
Anything can be layered onto Silverblue if it can’t be installed another way. I’ve found it works well.
Whoa! Distrobox looks cool! Did this come out on Android first? Seems like something I used to have fun with.
Damn, there are so many cool software I have never even seen in passing. I mean, I guess anything is possible. Hah.
Same. Better stability, frequent updates, no building from aur, and permission management with flat seal are great.
If you use mostly flatpaks they share packages which means they don’t take nearly as much space overall as single packages do.
Updates with only downloading diff’s is fast and works well.
I also like them just for the sake of tidiness. Some apps like Steam tend to make a big mess of dependencies all over the place, so it’s nice to have that all contained in one place. It does take up more space but I have a reasonably big hard drive so it’s kind of negligible for me.
I want a stable OS, but I want the latest versions of applications (programs) without messing up anything. For me flatpak and snap meet that need, but I prefer flatpak.
It seem that whatever problems Flatpaks may have, due to sandboxing, is truly isolated. I think as a non-power user, I do not have strong opinions about any kind of technology, I just enjoy the magic of things working without effort on my part. I will dive deeper as my needs change, but my needs are kind of simple too.
I’m running Ubuntu now and I’m in Snap hell.
It works well enough for some very basic apps, but for me personally, Snap has created far more problems than it has solved. With Firefox, for example, it makes it a lot harder to use some extensions, and FileBot is entirely useless without file system access (I mean, that’s the entire point of the program).
I’ve heard Flatpak is better but my experience is somewhat limited. It could hardly be worse, though…
Each snap is mounted as its own filesystem, which is messy for several reasons (try making sense of the output of
lsblkon your system). Flatpaks don’t do that, though they sandbox in other ways. There really isn’t a “Flatpak hell”, the worst that can happen is packages that depend on different versions of the same library taking up a lot of storage space, which is a problem with snaps too.I still prefer to rely on official repos but I do use a few Flatpaks here and there. But one of the main reasons why I don’t run Ubuntu is because of Canonical’s aggressive pushing of snaps.
100%. I just wrote a long post surmising this somewhere, but I’m switching my 5 year old Arch install to something like Debian Stable/Testing because I use almost entirely Flatpaks for my user applications (I would do 100% of them if every app I used had a Flatpak), and it’s really just a much better idea to run bleeding edge on only the stuff you care about instead of an entire system.
Nope, don’t like them. Nor snaps. I find the sandbox nature annoying and many developers don’t actually seem to understand it correctly anyway meaning you have to use flatseal etc. Then having to deal with some apps writing config within the sandbox and some writing it outside the sandbox…
My order of preference is generally I pick the “official” supported version as opposed to any community maintained ones. Then within that:
- Install via the language’s package manager (cargo, npm, pipx, cabal etc.)
- Appimage
- Native package (.deb, .rpm etc.)
- Plain binary
- Build from source
- Snap
- Flatpak
Out of interest why do you favour snap over flatpak?
I’ve just had fewer issues with snaps. Honestly I don’t care for either of them so the difference between them for me is pretty slim but I just find Flatpak to be particularly annoying, Snaps just haven’t caused me any real issues other than polluting my device list with endless loop devices.
True. I have run into a lot of dumb issues with sandboxing, mostly in choosing a folder other than downloads for file interaction.
I have overlooked Appimage, and I will consider it. I am intrigued that you put it before native package. I had not considered using the package manager of the language it is built in, which honestly is probably the optimal way to install a package.
Alright, I have some reading to do. I love learning new ways to do things. I am glad I asked!
There is a bit more nuance to it I suppose - I like Appimages for “complicated” apps, i.e. big GUI apps like Inkscape where I prefer native packages for terminal tools. The nice thing about Appimages is that there just isn’t much in the way of integration and therefore its really easy to just try something out with no risk of installing a bunch of extra dependencies and no way of breaking your system - I use Appimagelauncher for managing them but have been considering swapping to something like Appman/AM.
The other thing that sometimes puts me off of native packages is having to deal with excessive numbers of PPAs or other repos when they aren’t in the main ones.
I use Flatpaks for everything I can. I like how Flatpak keeps apps in a container isolated from my system. Also, Flatpaks contains every lib in every version I need for my installed apps, which means It does not rely on my system libs, and I like It, cause my system libs is to make my system works only.
Flatpaks are just the future of packaging
Great explanation and rationale for using Flatpaks! I hope others with questions see this.
I understand how people may be annoyed by the redundancy of every app packaging their own lib, but I swear those are measured in kilobytes, and people tend to be so obsessively minimalist it is a non-issue. Then again, minimalist are probably compiling their software.
I disagree. The other day I wanted to install some audio app that came in flatpak install format (I’ll check and add the name later). The app was less than 30MB in size, but the installation included 300MB of a previous version of org.freedesktop!
I think that is one time download of a library so the app can run. Also, any other app that needs it.
It seems to me that the biggest complaint people have with flatpaks are the space it takes.
I wonder if the blow up in GBs was an early buggy behavior?
Flatpaks are my second choice when there isn’t a recent enough version in the repos. They’re fine but take 1. too much storage space, and 2. are usually slower
No, because I don’t have a very powerful computer
Even if I did, I would still prefer to have native applications because it would be more permissive
I am totally ignorant, do flatpaks use a lot more processing?
They can take longer to start up, which can suck on older hardware. It’s not as bad as it used to be though. Once they’re running there shouldn’t really be any difference. The main drawback is actually that Flatpaks use more storage space.
I am glad that the startup times have improved, that bodes well for future startup times. Using up more storage really is what makes it suck for everyone. I thought that it was more efficient, since I see a lot of .platform, and I assumed those are libraries shared across flatpak apps that use those dependencies.
I am almost sure AppImage has the same problem? I don’t know, people do rated that better though.
Storage space mostly isn’t as bad as it is with AppImages. Each AppImage stores all the libraries it needs, even if they are shared with another one. They can’t even know if they have shared libraries. A single AppImage will probably actually use less storage than a single Flatpak if you only have one, just because the AppImage only uses exactly the libraries it needs, while Flatpaks use shared sets of them. That being said, Flatpaks generally get less bad the more of them you use, because of the shared libraries. They’re still a whole extra set of libraries on top of your system ones though, plus they put out a new set every year. Apps that are still under active development generally get updated to the latest version, but older apps that are basically finished often require older libraries, so that’s more space used. Overall for a one off program when you’re not using universal packaging systems regularly AppImages are mostly better, but if you’re going to be using them regularly Flatpak quickly becomes far better. It still uses more storage space than just using native apps though.
Another difference between Flatpak and AppImage is that it can be kind of a pain to theme Flatpaks to match the rest of your system, and I don’t know of any good way to do it with qt6 apps yet, but it’s just straight up impossible to theme AppImages. They can technically have themes built into them, but unless you’re using Adwaita, or maybe Breeze if you’re lucky, they just don’t, and having to rebuild your own custom AppImage completely defeats the main benefit of using AppImages.
That is what I thought, and I was confused about people complaining about the redundancy. Also, every new program I install manually seems to pull a crap-tonne of new dependencies, so nobody is saving space.
On my main PC I use for gaming I run Arch and prefer native packages whenever I can use them. I’m quite happy to have this one computer by a hobby project, and native applications just make more sense on something as up to date as Arch when they’re available. I have started to prefer Flatpak over AUR packages though. The AUR is pretty overrated, in my opinion.
On my laptop and anything else I install Linux on I usually just use LMDE, and I’ll often prefer the Flatpak, just because it’s way more up to date. There are some apps that Mint keeps up to date native versions of, and there are some apps that come preinstalled that I just don’t care about having the latest version of, but for everything else I usually just download the Flatpak.
Definitely not me. I am on LiveUSB right now which makes my disk volume limited. And native packaging satisfies my needs (even when packages are old)
That is cool. I imagine it would be great to have an array of USBs with different distros for specialized uses.
For the most part, I don’t even look at the version number when downloading packages. Most of the time it does not matter. Still, when I need something up to date, all I have to do is choose the flatpak version.
I prefer my binary over every other universal packages.
No
I had fedora installed the last few years, and was digging flatpak… until I wasn’t. One day I ran out of disk space - 230 Gb of flatpak dependencies. I run a pretty slim system, so what the actual heck? Did some research, learned how to flush cached and redundant packages, shrunk my flatpak deps to… 150 Gb
I’ve since been trying Endeavor
That is unreal. I had no idea it can get that bad. Makes no sense, honestly.
It was likely the build up of a few years’ packages, updates, and so on, but it eventually came to a head and I had to wipe and load. Maybe it’s better now, but I think I started that install around Fedora 34? So not too long ago
Weird. That is unfortunate, and I hope it was just an ugly bug that unfortunately effected you.
When using Fedora Silverblue, there is no other option, which I do!
But there are other options with Silverblue.
It’s the preferred option for gui programs.
That doesn’t mean it is the only option.