[dTal]

AppImage is not like the other two, it is fundamentally just a way to make a self-contained binary directory into a single runnable file - a way to avoid having to tell the user to extract a tarball and run a particular file inside. Convenience, nothing more. The other two define entire alternate runtimes.

[bionade24]

No, an Appimage still ships a dynamically linked executable + lots of dynamically linked libraries, that only link against system libraries when strictly needed, e.g glibc and libGL. Those files are bundled in a squashfs and have a script setting a custom LD_LIBRARY_PATH to the squashfs content for the binary. Snap does use this technique, too, but does more, for worse.

AppImages are not comparable with statically linked binaries.

[dTal]

I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more.

Meanwhile, Snap and Flatpak are package managers - what's more, they're invasive heavyweights with permanent costs that are even worse than distro package managers. Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck! They are both trying to impose some dubious vision of sandboxed apps that require bureaucracy to communicate with each other, instead of just tackling the core issue of software distribution. Maybe you even like sandboxing! But I've seen no justification why that should be co-mingled with package management.

[PlutoIsAPlanet]

> Flatpak requires you to run programs with "flatpak run" - yuck

To begin with Flatpak makes .desktop files so no one should be needing to use that command manually.

Secondly, Flatpak has an option folder you can add to your path that lets you run applications by running their FQDN. e.g. org.gnome.Gimp myFile.png rather than gimp myFile.png

[Kinrany]

> But I've seen no justification why that should be co-mingled with package management.

Building sandboxing on top of package management makes a lot of sense because you want sandboxing to work by default, and for that you need to identify the sandboxable things without making the user point to each one individually.

[simon_o]

> want sandboxing to work by default

Yeah, wake me up when Flatpak is remotely close to doing this. Most "apps" simply disable the sandbox.

Not to mention I'm not going to trust "app" developers setting their own permissions. That's the job of package maintainers.

[bionade24]

Afaik they disable filesystem sandboxing, not process namespaces. Still better if programs can't ptrace around, although this is indeed a big issue.

If someone knows why this sandboxing is better/worse than SELinux or AppArmor access rules, can you pls elaborate? I'd really like to know.

[account42]

You don't need any fancy packaging to restrict ptrace: https://www.kernel.org/doc/Documentation/security/Yama.txt

[simon_o]

I'm not comparing sandboxing against SELinux/AppArmor. It's a social problem, not a technical one.

I'm comparing "app developers holding themselves accountable" to "package maintainers dish out consequences for misbehavior".

I have absolutely zero trust in the former, and lots of trust in the latter.

[Kinrany]

What do you mean? If package developers don't specify permissions correctly, their code doesn't work when sandboxed.

[bionade24]

First of of all, I don't like Snap or Flatpak. I'm only really interested rpm-ostree as used in Fedora CoreOS and Silverblue. I don't hate Appimages, you're claim that they're "fundamentally different" is just hypocritical.

> The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more.

This still forces the user to learn the internals if the AppImage doesn't work. E.g. if MATLAB would use Appimage, I'd have to extract squashfs contents, fix the broken libraries inside and the repackage it. Or I would have to write a script to start the executable outside. It's a simpler from a pure technical standpoint when it's a tarball + wrapper script.

> Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck!

Snap has many issues Canonical just refuses to solve (e.g. users without home under /home), so I just ignore that. What flatpak does is arguably exactly what Appimage does, a wrapper script. Maybe more complex, but with additional features and the it's the same script for all packages. If you have 100 AppImages installed, you have the same thing as "flatpak run" in up to 100 slightly different versions. I can't see how that reduces complexity.

[the_why_of_y]

The problem with AppImage is that it doesn't tackle the core issue of software distribution: how to build the software so that it runs on all the systems you want it to run on.

Flatpak and Snap have SDKs for this purpose, but with AppImage an ISV is forced to guess which libraries need to be bundled and which may be dynamic link dependencies from the OS.

Not to mention the requirement for fuse2, which is being replaced with fuse3.