I'm a big fan, but I would also not categorize myself as a power user. I want my computer to "just work," and I have more than enough storage space that I'm willing to accept a trade-off in storage size to not have dependency issues. I never really notice and issues permission-wise though, if something really should have access to other files on my computer I just use Flatseal.
this post was submitted on 10 Nov 2025
43 points (97.8% liked)
Linux Questions
2831 readers
43 users here now
Linux questions Rules (in addition of the Lemmy.zip rules)
- stay on topic
- be nice (no name calling)
- do not post long blocks of text such as logs
- do not delete your posts
- only post questions (no information posts)
Tips for giving and receiving help
- be as clear and specific
- say thank you if a solution works
- verify your solutions before posting them as facts.
Any rule violations will result in disciplinary actions
founded 2 years ago
MODERATORS
i prefer to not use them when possible
I like them when a program isn't available in my distro's repos
I used to like them because of the sandboxing.
Now I don't like them, because of the sandboxing.
(I still use them because some programs are not available in my distro's repository)
I worked security while we created and shipped an enterprise linux distro and maintained AT&T Unix.
Flatpaks, even at their best, break Single Source of Truth for installed state. This alone should invalidate them, but they also don't validate contents against a signed manifest like proper packages will, and so the supply-chain exploits are a huge risk.
But if all your friends do risky things and you need to join them, then you be you.
I prefer native builds when possible, since they tend to be more streamlined and tailored for my distro (e.g. window borders, colors, and buttons all match).
But Flatpak is a good fallback. It's a lot to ask of maintainers to keep up more than a few builds, at least on small / low-budget projects. The occasional permission issues are a minor price for a huge convenience.
IMO apt, pacman, and Flathub are all about equally straightforward to use once you acclimate a little.
For me personally, I love it. I bought a pretty large SSD for my gaming PC, the space used by non-game apps is basically irrelevant.
But the convenience? Unmatched. Compatibility is a non-question, it's virtually impossible to break any app. Everything has exactly what it needs, if I go to make a bug report, my details are 1 line long, "Flatpak version", I don't have to consider whether X wants Y python when Z wants 2 versions later, just let each install its own version in its sandbox and update that version when it's ready to.
Want to try an app? Alright, look up the thing you want on bazaar, install 3 apps that do it, and try them. Effortlessly delete them when you don't like them, and it's even cached so that you can one-click reinstall it with your data if you later realize one was your best choice. Deleting something completely cleans it from your system, dependencies and temporary files and all.
Yes, it takes a little bit to understand permissions and such once you need them, but that's all not nearly as complicated as the problems I learned to solve before flatpaks came along, and Flatseal makes managing that stuff pretty darn straightforward too. Flatpaks are 10/10 easy to work with, and absolutely deserve to become the default way to install Linux applications in the way they have been.
Space is cheap. Installing everything as Flatpak triples the space your OS needs, but that never mattered even on a 256GB SSD.
The reason I went back to distro-specific packages was that the quality of Flatpaks and how well they integrate into your OS differs wildly.
Usually there isn't any issue for popular applications, but my attempt to install only the bare minimum needed for Gnome Shell to run and install everything else from Flatpak lead to interesting results.
On the other hand, as soon as something forces you to deal with multilib (Steam) or updates every week (Signal Desktop), Flatpkas work better with less hassle.
I really like Flatpaks, even if I was highly skeptical at first. I haven't had many issues, and I actually feel they have made installation and management easier. Yes, they take up more space, but that hasn't inconvenienced me at all. It's a really good system that solves some long running issues with Linux software distribution.
While I haven't used it, I like GNU Guix a lot conceptually also.
I don’t have any files on my OS drive and that is 1tb large. I have never had issues with space on that drive. What I mainly like about flatpak is that you usually get the latest version. Also not giving every app full system access during installation is reassuring, not just because of malware but because of package(updates) that break your system during to a bug
Ehhhh.. for me they're mostly annoying due to the permission issues. I prefer system native packages where I can, followed by appimage, and flatpak last, unless it's an app that won't need access to my PC beyond the standard permissions flatpaks get, in which case flatpak moves up to 2nd place, just cause I can get them through the GUI package manager lol
Fuck Fedora/FESCO for repacking flathub flatpaks as their own and forcing users to use their remote instead of flathub. That's really my only feelings.
Anyway, as an Atomic Bazzite user, I love Flathub-remote flatpaks. And I love that UniversalBlue strips out yucky Fedora remote, out-of-the-box.
Means I don't have to yuck up my image with more rpm OSTree layers. Bazaar is awesome. 😉
you can add flathub as a repo on fedora. ofc it would be nice if it was defaulted tho
I've used them before, and they work aside from a lack of integration with other programs. Same as any other isolation system (like Snap).
My main problem is a lack of digital signatures on the packages. Deb, RPM, everything else is digitally signed, and has been for a long time. Flatpaks should be signed too.
for me they're a "last ditch effort". If I can't get something working correctly on NixOS then i'll just settle for the flatpak but it's not often that happens. for example I only have 3 flatpaks on my system one of which is discord simply because I found the voice comms work better with the flatpak than the native package.
I might end up switching to appimages though to see if they're any better.
If you have more then one flatpak, they make more sense than appimage because they can deduplicate dependencies. Also, while their sandboxing isn't great, it's at least something and you can manually tune permissions using flatseal if a flatpak has overly broad ones (like the ones that want full filesystem access).
they make more sense than appimage because they can deduplicate dependencies
I just looked it up to check, and now I like appimage even less. They just package what the developer deems necessary to run, so if they miss something that's present on their distro but not others, it might break. It also hardcodes paths so it doesn't work on things like NixOS or Guix System out-of-the-box.
https://github.com/pkgforge-dev/Anylinux-AppImages
https://github.com/VHSgunzo/sharun
EDIT:
It also hardcodes paths so it doesn’t work on things like NixOS or Guix System out-of-the-box.
Also this take makes no sense, flatpak nor snap work on NixOS or Guix out of the box unless the user installs and configures them with all their dependencies, and that usually includes a reboot to make sure the flatpak exports get added to XDG_DATA_DIRS.
Meanwhile appimage can be made to work out of the box in those systems and for those that don't NixOS offers an FHS wrapper to run them.
Flatpak works just fine on both NixOS and Guix System. Occasionally you might need to expose systemwide SSL certs to the individual flatpaks or something on Guix. When I said out-of-the-box, I meant if you enable flatpak in your nix config, it works without issue. Obviously you need to install it since the only package manager provided by default is nix (or guix).
Direct quote from the Nix wiki:
On most distros, all one has to do is download the .AppImage file, make it executable chmod +x $AppImage, and execute it. This doesn't work in NixOS out of the box though, as AppImage files usually (if not always) depend on certain system libraries in hardcoded paths.
Basically every appimage needs to be run through a wrapper executable that I'm guessing patches the paths. So on top of the app not showing up normally in the DE, it also now cannot be directly run.
I meant if you enable flatpak in your nix config, it works without issue.
And this cannot be enabled in the nix config?
Basically every appimage needs to be run through a wrapper executable that I’m guessing patches the paths
It does not patch paths, it makes an FHS env with basic dependencies that the appimage can then use, NixOS also offers something similar for other apps called steam-run.
And once again you don't need it for every appimage, hopefully in the near future that will be all appimages.
Sure, you can enable it. That doesn't solve the problem. The problem is that you cannot execute the app directly and need to use a wrapper script. steam-run and the like are hacks to get things working. They shouldn't ideally be needed, especially with a format that is meant to work without issues across distros.
And once again you don't need it for every appimage, hopefully in the near future that will be all appimages.
If you're talking about the things you linked, it seemed to me the author needs to explicitly use those. In other words, it's still entirely author-dependent whether the app will work across different distros. The list of projects that use those tools is also quite small right now. Meanwhile, pretty much every flatpak I've tried has not been an issue.
Sure, you can enable it. That doesn’t solve the problem. The problem is that you cannot execute the app directly and need to use a wrapper script. steam-run and the like are hacks to get things working.
Do you know how binfmt_misc works? It makes it so that when you execute the appimage it automatically runs it with appimage-run, both flatpak and snap work in a similar matter, flatpaks need to be launched by flatpak run and snaps by snapd, however with binfmt_misc it removes the need to manually have to use appimage-run and it instead does it automatically for you.
So this makes no sense.
it’s still entirely author-dependent whether the app will work across different distros. The list of projects that use those tools is also quite small right now. Meanwhile, pretty much every flatpak I’ve tried has not been an issue.
Welcome to the world of centralized packaging systems that have requirements before running. flatpak or snap do not have this issue because they need runtime dependencies and setup before you can even try to launch any, you also likely get your flatpaks from flathub and I assume they at least test them once before publishing them.
probono once tried to enforce people to build their appimages on old systems to guarantee some quality and this was met with backslash. 😹
steam-run and the like are hacks to get things working. They shouldn’t ideally be needed, especially with a format that is meant to work without issues across distros.
FYI, AppImage itself is older than NixOS and MUSL, the whole tooling is also controlled by boomers that want standards to follow and what not.
Basically AppImage was based off the idea of executable directories of MacOS, on those systems there is a some basic set of dependencies that will always be there.
AppImage instead tried to target the most common linux systems, which back then 99.99% of the time was going to be an FHS filesystem with glibc. glibc guarantees backwards compatibility*** so they made the rational decision (back then) of relying on some host dependencies and what not.
Fast forward to 2025 and now linux is no longer that, you cannot even expect a system to be GNU/linux at all, nobody follows the FHS fully anymore. So the only thing you can complain about here is that appimage hasn't moved fast enough to these changes but this is just a 100% community project, I think only KDE has contributed to appimage meaningfully in the past, there is nothing the likes of Red Hat or Canonical behind the project unlike flatpak and snap.
***Even this crap has had a ton of exceptions years later btw.
Do you know how binfmt_misc works?
I looked at the wiki and it seems to mention that. I don't think that was there yesterday? Well, anyway, still depends on the wrapper script and binfmt_misc being set up and configured as opposed to the intended no hassle download and run style that it is meant to work on all distros. It's basically the same as flatpak here (with slightly more configuration), although unlike flatpak the apps won't show up in my DE without manual work.
AppImage instead tried to target the most common linux systems, which back then 99.99% of the time was going to be an FHS filesystem with glibc. glibc guarantees backwards compatibility*** so they made the rational decision (back then) of relying on some host dependencies and what not.
fastforward to 2025 and now linux is no longer that, you cannot even expect a system to be GNU/linux at all, nobody follows the FHS fully anymore. So the only thing you can complain about here is that appimage hasn't moved fast enough to these changes but this is just a 100% community project, I think only KDE has contributed to appimage meaningfully in the past, there is nothing the likes of Red Hat or Canonical behind the project unlike flatpak and snap.
I mean, fundamentally, if apps packaged with a distro-agnostic packaging system cannot be relied on to be distro-agnostic, the packaging system isn't really distro-agnostic. They may have had reasonable expectations when it was originally made, but like much software, their expectations were incorrect, so now we're in a limbo land where some apps might work fine, but others require distro-specific wrappers that may or may not even exist. For instance, while it's possible to run them on Guix System, there's AFAIK no actual wrapper script, so you need to manually create the FHS env using guix shell --container --emulate-fhs blah blah blah and expose a bunch of directories and env vars to the container. In a system without that functionality (to emulate an FHS environment), you'd just be SOL. You could maybe get it working using like distrobox or something, but at that point you might as well just download the app using the distrobox env's native package manager or whatever (note I haven't personally used distrobox).
Also, I admittedly don't like the download and run model, since that's been an easy way to download malware historically. Might be easier to convince some people to use Linux with it though because it's "familiar," although now since there are app stores on Windows and macOS and phones and so on, an app store should probably be familiar enough to most people.
I recently wrote about this in my setup post (which is not yet complete) so for a more detailed answer - https://sga.codeberg.page/setup.html#loc-13
and for a summary - space usage is one of the reasons for me not using it, but there are more reasons. and many of these can be solved if flatpak uses some for of compression (squashfs/dwarfs) and smartly mount the required flatpak archives. This is one the best things that snap does, but they do many things wrong the other way.
but problem with appimages is that there are no repositories
and they rely on older fuse implementation.
-
The official AppImage runtime has been static (no longer depends on any libfuse) and built with fuse3 since 3 years ago. Only electron builder remains with this nonsense of using the old runtime.
-
Also DWARFS AppImages that also do not need FUSE at all to run.
Recently I have been using language specific package managers more - cargo (and cargo binstall) to get most of rust stuff. And since I like new stuff, I happen to have quiet a few (~20) packages from it. binstall allows to fetch binary releases. Only major problem with it is that cargo has limitations in it’s pacakaging, and effectively only /bin parts of package is installed
I am using soar now for appimages and some other binary packages (go and rust) (recently got like 10 packages from it, and will update my page too), but if a package is on cargo, and soar, I prefer the cargo one (no strong reason for it).
I generally install apps (graphical programs I guess) using flatpak, and then anything non-graphical or system-related programs using the native package manager. The main exception is apps that already have a sandbox like Firefox or Chromium, which I install using the native package manager to avoid weakening their native sandbox.
My main gripe with flatpaks is the sandboxing kind of sucks, but it's still better than nothing. The other issue is apps will sometimes take a long time to move off EOL dependencies.
I'll use them when I have no better option but I've had annoying permissions issues exclusive to Flatpak. I can fix with Flatseal but it's more work I shouldn't have to do.
Most recently I had issues with GPU acceleration using the Flatpak version of PCSX2.
Haven't used it once.
I prefer native packages, but if the option is between Flatpak and no package at all, then I'd rather have the Flatpak. It's also nice that developers can package their application once and be done with it.
Lukewarm.
If I can install the program from a .deb I'll do it, even if it's outdated in comparison with the flatpak version. But if there's only a flatpak version I'll use it.
Im looking more at appimage but would love something that organizes it like portableapps does for windows.
Personally I avoid it, but mostly because I prefer everything to be controlled from one place: apt-get (or yum when on CentOS)
Permissions need to be sorted so they default to what they actually need. Nobody should need flat seal.
I also find it confusing picking which source to pull from because my system always defaults to one that doesn’t work on my system.
As an example of where this really falls apart: try setting up a password manager on a browser.
I like the idea though.
Not a huge fan, because they never seem to integrate quite as I expect.
I have used them for apps that I just can't get running otherwise though
You can have universal packages separated from the system that use very little space. That is known as AppImage
And now it is possible to make them truly universal, before appimage sucked since they had a dependency to libfuse2 and glibc, that's not needed anymore.
I’m pro flatpak it seems the best solution for the job. It saves devs compiling software for every single distro. This reduces wasted effort and also has a significant environmental benefit in reducing cpu energy use on compiling. Additionally the convinience and compatibility are great.
Don’t really care about the file size, storage is cheap. If you do care due to your hardware situation I can see it being annoying though.
Personally I like them when they work well enough for my needs
I don't mind the space issues, but sometimes they still have odd quirks. They keep getting better though :)
But I don't have any issues with native packages so I often choose them when available. Lots of the time I don't really pay attention and just grab whatever's in the software store and use that until I have a problem lol
I prefer guix packages. Solves the same problem, but without data duplication.
Guix is extremely good but I’m not sure if it’s ready for general users yet in the way flatpak is.
As a package manager I don't see why not? guix install foo and if it doesn't work you can still flatpak it. As a distro, yeah largely agree, although I'm no power-user and know embarassingly little about guix but use it as a daily driver.
Yeah for you and me, sure. But I don’t think any command line package managers are good for Joe Public either. My mum isn’t installing software from a command line, but she’s fine to download Netflix onto her phone from an app store. Flatpak integrates nicely into a lot of os software centres in a way I’ve not seen from Guix (though I could be wrong, I’ve not looked much).
I like having the option available as a final resort.