Ok. It’s not entirely fair, but I think Snap is designed like something with an ulterior motive masquerading as a solution to a problem of questionable severity.

Dynamic linking is a reuse solution, right? The benefits are that you reduce code duplication and size impact, and also get the benefit of wider positive impacts of bug and security fixes. But it was mainly developed as a way of reducing space requirements when disk and memory were far more constrained than today. Not only did you reduce at-rest size of programs, by dynamic linking also allows the OS to load code into memory once and re-use that across multiple programs. The downside is dependency hell, where OSes have to manage multiple versions, and poor vendor versioning practices where minor upgrades needed by some applications unexpectedly break others. This last point is one of the problems Snap and Flatpack are trying to solve.

Statically linked programs minimize dependency hell. A statically linked binary can be copied around to nearly any machine of the same architecture and will run. And it will be runnable, through system upgrades, almost indefinitely. There are almost no dependencies, not even e.g. on a running Snap service on the machine. The downside is greater binary sizes, being impractical for GUIs, the loss of auyomatic distribution of bug and security fixes in dependencies, and only being available to statically compiled languages (outside of bundling software for interpreted VMs, which have always been hit-or-miss second-class citizens).

So what does Snap get you?

• A dependency on what is almost a system-wide VM: snap itself
• Another service that needs to be running on the computer, or else you can’t run snap packages
• Dynamic linking to libraries, but without the benefit of broad application of bug and security fixes rolled out in dependencies - the downside of statically linked binaries
• The benefit of statically linked stability, but without the portability and independence of a statically linked binary
• The loss of much of the dynamically-linked space savings, as library version isolation ends up reducing the ability of the OS to share code between programs.

Fundamentally, automatic distribution of bug fixes, and stability through upgrades are conflicting goals; it is impossible to satisfy both. This is due to the essential truth that one tool’s bug fix is another’s breaking change.

I made the comment that I believe Snap has an ulterior motive, and I feel as if this needs an explanation. If you compare Snap’s design to, say, appimage or Flatpack, it’s pretty clear that - by intention or not - Snap creates a walled garden where the Store controlled by one entity which has the ultimate say in what shows up there. It isolate software; if you look at what’s happening in the OSS space, projects that are packaged for Snap tend to be far more difficult to install outside of Snap - the authors often don’t even bother to provide basic building instructions that don’t require Snap. This has a chilling effect on other distributions - I am encountering more software that is only available through the Snap store; without build instructions ouside of Snap, it makes it harder for volunteers to create packages for other distros. It’s not a lot, but it’s a disturbing trend.