40
How do you feel about Flatpak? Do you like having universal packages separated from the operating system, or do you regret how much space they take? (piefed.zip)
submitted 1 year ago by to c/linuxquestions@lemmy.zip
40 comments fedilink hide all child comments
 

I was reading a bit about it recently, seems like there two positions are valid, curious to see what people here think.

you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 1 year ago (6 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 2 points 1 year ago* (last edited 1 year ago) (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 3 points 1 year ago* (last edited 1 year ago) (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 year ago (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 year ago (2 children)

    And this cannot be enabled in the nix config?

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago* (last edited 1 year ago) (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    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.

  • permalink
  • fedilink
  • source
  • parent