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