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).
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.
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.
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.
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).
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.