Snap scares me a bit. Package managers are so great because we have explicit control over everything running in a system. Snaps are just glorified Mac app bundles.

Snaps might be good for deploying big complex things. But in case of smaller "apps" like some featured in their site (VLC, Blender, Krita...) this seems like a lazy solution. Lazy because we loose control over knowing which libraries are running in our system.

For example, if there's a security issue with libssl, I can quickly patch my libssl instances with apt, pacman or whatever my system uses. But with snap?

I think the way forward is the nix way [1]. It's a bit harder, but it pays off. Some big HPCs use it already, and it seems to work quite well.

[1] https://nixos.org/

Some good points, but just to clarify snaps current behaviour re libssl et al:

Snap makes a distinction between a minimal set of critical core system dependencies, and application dependencies.

So on every system with a snap, there is also a 'core' snap, which has the base root fs, including glic, libssl, bash, etc. This core snap is updated regularly by its publisher (just Canonical's ubuntu core snap right now, but nothing stopping some other core snap). So a lot of critical updates are applied by default, as per normal distro policy, but just in a better way (rollback, transactional, qa, etc).

The application snap is only responsible for keeping its own dependencies up to date, it uses the base libraries from the core snap. It's distinct from docker in this way, it tries to define a line between core and app dependencies, to get the best of both worlds. I.E. critical components are updated ASAP by the disro security team, but apps are free to use a specific version of a library (e.g gnome, qt) that they want to use, rather than being stuck on the distro maintained version. Which, of course, they can still use if they want :)

It does push the burden on updating libraries to the app vendor, but on the flip side, snaps run in a very confined environment, which mitigates the scope of most CVEs there might be in an older library.

A lot of careful trade-offs considered and involved in the design - we'll see they're the right trade offs or not :)

> It's distinct from docker in this way, it tries to define a line between core and app dependencies, to get the best of both worlds. I.E. critical components are updated ASAP by the disro security team, but apps are free to use a specific version of a library (e.g gnome, qt) that they want to use, rather than being stuck on the distro maintained version.

And then as soon as an app decides to not use the base version of a library, it will still be vulnerable when you update the base snap, so you still need to check every app for updates. That's not an improvement at all.

It's not a regression either, if an app developer wants to use their own version of base libraries they will already be doing that in their .deb, .rpm or .tgz packages.

VLC, Blender and Krita are not small applications. For the past decade these applications have been plagued by inconsistent, outdated and broken packaging. The distribution level cadence of one stable release every 2 years versus modern app cadence of an important release every few weeks leads to a neverending clash. Releasing with Appimage is not laziness, it's an escape from a Sisyphean task.

Yes I think Snap empowers the app vendor at the expense of the sysadmin. I think Nix is a much better approach for servers.

> Snaps are just glorified Mac app bundles.

AppImages even more so then. For the end user though either are simpler and allow people to get up to date versions of their apps, which is difficult when using shared libraries. Plus Snaps are also cross-distro which saves a lot of work for authors.

Snaps (and Flatpaks) are awesome for publishers of apps and laypersons though. There's a reason the average person sees the macOS style of installation (and removal) as the gold standard.

Gold standard? Mac apps, when uninstalled naively, leave lots of stuff around under /Library (or worse, if they had a .pkg). Then you have the Frameworks complications, plist-caching hell... Just because Mac apps don't use a central registry it doesn't mean they are so much better than Windows ones. In comparison, apt-get is not bad at all: you install and uninstall anything with one command and --purge gives you you decent guarantees that it will all go away, including config files.

Snaps can be 'strictly confined' which means all their reading and writing happens in a limited set of directories exclusively for their use. So 'snap remove' cleans everything up perfectly. Ask your upstream for a strictly confined snap, it's a bit more work but once they have done it everybody wins.

Note that I said average person. They will never touch a command line, so apt-get is out, and the Ubuntu Software Center is buggy as hell. Compare that to macOS: Drag app in .dmg to 'Applications' folder: installed. Drag app from 'Applications' folder to trash: uninstalled. Need to remove all settings? remove the apps' concerning folder in ~/Library/Application Support and plist in ~/Library/Preferences. Yeah, I'd say that's pretty simple. And although the Mac App store has its flaws (draconian sandboxing) it also works like a charm.

As a fellow California HPC admin I definitely like the idea of something like SNAP. But I would want full control over it, can't have production systems down because some infrastructure somewhere else in the world is down.

Of the ones I looked at NIX looks particularly promising, having dependencies based on checksums sounds pretty cool.

If you install snaps from the Canonical snap store, and it is down, your systems keep running. Just that updates won't happen, and new installs will fail (well, maybe that will all work too if you have a well configured web cache in between)

If you don't like that, you can install snaps from a local file (in which case you need to handle updates yourself), or run your own snap store (I think some assembly still required)

You can get the snapcraft.yaml con fig of the app and recreate the snap with your modifications and adaptations.