this post was submitted on 10 Nov 2025
38 points (100.0% liked)
Linux Questions
2826 readers
97 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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).
mmm
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:
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:
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.
And this cannot be enabled in the nix config?
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.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.
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 byflatpak runand snaps bysnapd, however with binfmt_misc it removes the need to manually have to useappimage-runand it instead does it automatically for you.So this makes no sense.
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. 😹
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.
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_miscbeing 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.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 blahand 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 likedistroboxor something, but at that point you might as well just download the app using thedistroboxenv's native package manager or whatever (note I haven't personally useddistrobox).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.