AFAIK, snaps don't have a (official) way of disabling auto updates which means everything run a snap might update at any time, rather than when the best time is. This might work fine for a personal computer you use for Facetime or whatever, but in a professional environment or for servers, you can't just let software update when it thinks it time to do it, you need to figure out a good opportunity for it to happen.

Yes they do: https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...

Ah, supported in 2.58+ which is the latest stable version, seems I'm up to date when it comes to my snap knowledge. Happy that it finally is supported, but not super happy about it taking ~7 years to get in place...

Yeah, I don’t understand the hate in HN. Both snap and LXD are good container technologies. Snap is better than flatpak in several ways, for example, system programs could be confined too.

> What's peoples aversion to snaps in the thread?

In my case, because it's being forced and replacing applications that worked out of the box with applications with issues. Firefox, for example. After it became a snap, you'll see a message telling you to close Firefox so it could update itself (?) but simply closing it is not enough and, last time I checked, it looked like you had to run some command line to solve it. Also, due to its sandboxing, external hardware like smart card readers didn't work in the snap version, so I couldn't log into e-government websites anymore.

I ended up installing the tarball version...

Eh Firefox probably isnt the best example due to security being so important.

Something like an IDE is a better example since its not much of an attack vector.

You mean Firefox is a good fit for a snap due to security reasons? In that case they should've made the experience seamless, and provide the same functionality you get when using Firefox from the deb or the tarball, before pushing it like that.

Because otherwise, the result is people pissed of with that change.

Have you ever used it in a production / server environment?

One of the problems I have with Snap is that it does auto-updates. So you can't control when updates are performed. Furthermore, you can only use Canonical's repository. So if you want to use a custom build of some sort, you can't - unless you pay big bucks to Canonical.

It's funny because I found a way to disable auto update for snaps in 2 minutes by Googling and half of the angry voices in gere are because of auto updates. What is going on?

There is this announcement about a new snap release from November 2022 [1] in which they made this possible. So this is a relatively recent addition. Before that, Snap basically did everything in its powers to ensure that all packages were continuously updated.

1. https://snapcraft.io/blog/hold-your-horses-i-mean-snaps-new-...

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.

> 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.

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).