[mkj]

My objection is that it's simply fragile and overcomplicated software. Operations that one would expect to be instant take a second to run. I attempted to reinstall snap recently so I could use lxd (which seems good itself), and was greeted with inscrutable error messages so gave up and moved it all over to libvirt.

Contrast with something like systemd that also has its haters, but it is solidly written software so seems to be accepted by a lot more people.

[thecosmicfrog]

> fragile and overcomplicated

Couldn't that description be applied to the existing Linux packaging ecosystem? It seems that "fragile and complicated" dependency graphs are exactly what Snap/Flatpak/AppImage are trying to fix.

[pxc]

The Linux packaging ecosystem works extremely well for open-source software, and it produces a much leaner, more integrated system than bundling approaches like are common on macOS (and in a less extreme way, Windows).

There are two things that Snap and Flatpak are trying to 'fix':

1. The Unix security model, which relies on the user as a main boundary for security/policy. These tools are trying to add sandboxing that makes running untrusted software safer and accounts for the fact that being able to access everything in a user's home dir (and so on; this isn't just about the filesystem) is 'bad enough'.

2. The Linux packaging ecosystem (and whole userland, down to glibc's ABI policies) has never been intended to serve proprietary software developers/publishers/vendors who want to be able to throw their binaries over the wall or test only on an extremely limited range of library versions.

(AppImage only aims to 'fix' the latter, and poorly at that, since it doesn't even attempt to encapsulate huge parts of the runtime environment that vary from distro to distro.)

The only thing 'fragile and complicated' about Linux packaging itself is the practice of installing everything into a shared global namespace on the filesystem, which is already better addressed within the packaging infrastructure itself, as has been done on NixOS, GuixSD, GoboLinux, and Distri. (The latter two being more research projects than practical distros.) Those distros all prove that resource sharing and dynamic linking are actually red herrings when it comes to what is problematic about distributing software on Linux— you can keep both of those things and escape dependency hell forever (with or without containerization).