I was reading a bit about it recently, seems like there two positions are valid, curious to see what people here think.
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.
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.
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.
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 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
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
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
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.
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).
-
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-runand 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.
