4 ms·

Auto-updating isn’t the only issue. I’m a stickler for security updates; I’m that crazy guy who always reboots his computer immediately whenever there’s an upda

Auto-updating isn’t the only issue. I’m a stickler for security updates; I’m that crazy guy who always reboots his computer immediately whenever there’s an update. I like that Windows forces updates. Even I recognize that this doesn’t make sense in the Linux world, though. Ubuntu is trying to be something it’s not—they’re trying to appeal to a new demographic, and, in doing so, driving away their existing users. Even with my stance on auto-updating, snaps are a problem for me because I mostly use Linux in the context of servers. Like it or not, that’s where Linux has the largest market share; Android aside, Linux’s consumer market share is negligible. In that context, snaps have problems: - I can’t have my servers updating on their own. Security updates rarely break things, but most other updates need testing. - I use auto-scaling. That means servers need to come up quickly when load increases. If a bunch of new servers come online and all decide to update, that’s worse than no servers coming online. - I don’t want or need a sandbox. In a cloud environment, the server is the sandbox. - Environments and server states need to be reproducible for testing and auditing. If I’m doing a post-mortem, I need the software on the relevant image to be in the exact same state as when the problem occurred. - Performance is critical. I’m already paying AWS for sandboxing in the form of many small EC2 instances; I don’t need the additional overhead of snaps. I’m not working with bare metal. All of these issues could be resolved, and I wouldn’t object to this experiment running in a non-LTS or desktop-only release. But it is truly an experiment: snaps aren’t ready for prime time. My options are to pay Canonical for extended support for old software, wait it out and hope the issues are sorted before I stop receiving security updates, or switch to something like Alpine or Debian. Keep in mind, this is coming from someone who loves automatic updates, generally prefers systemd, rather liked Unity, and didn’t see what all the fuss was with Upstart and Mir: - systemd works pretty damn well and is a big improvement, although it has its hiccups - Unity was fine. It looked nice out-of-the-box and wasn’t a resource hog. - Upstart usually worked well enough, though it sometimes had reliability issues. - Mir never really saw the light of day, so it didn’t matter. Snaps are where I draw the line. They might be the future, but they’re not ready for the present. And that’s not for lack of trying on my part—I had no trouble embracing Upstart and later systemd.

compuguy 6y ago
I honestly haven't used snaps in a server context. I get them from the desktop context. I would probably use docker containers & docker-compose before using snaps. I honestly have more control in pushing updates and the like in that situation.
Shared404 6y ago
+1 for almost everything. Also, Alpine is brilliant as a server OS.
lightrush 6y ago
All valid points and as you say it yourself, all addressable. The thing is though, Canonical can control this experiment by deciding on what debs get migrated to snaps. They can easily conduct this experiment in an LTS so long as they only keep it to desktop packages like GNOME components, browsers, third party software, etc. That way they don't have to wait yet more years before providing this system for use by all users and developers. For example I love the fact that VS Code and Spotify update on their own with no interaction required. I wouldn't love if something I don't want to update in our server fleet gets updated but I don't see many snaps in that area. But if we do see that I'm sure both of us can come up with a one liner stopping snap from updating if and until that use case is supported. Besides, the server space is gravitating towards immutability anyways, so doing something like `chmod -x $(which snapd)` or `chmod -x $(which apt)` on a production machine shouldn't be a big problem in that context. In fact that's one foolproof way to make sure packages are what you want them to be after installing them. Or read-only file systems.

compuguy 6y ago

I honestly haven't used snaps in a server context. I get them from the desktop context. I would probably use docker containers & docker-compose before using snaps. I honestly have more control in pushing updates and the like in that situation.

Shared404 6y ago

+1 for almost everything. Also, Alpine is brilliant as a server OS.

lightrush 6y ago

All valid points and as you say it yourself, all addressable. The thing is though, Canonical can control this experiment by deciding on what debs get migrated to snaps. They can easily conduct this experiment in an LTS so long as they only keep it to desktop packages like GNOME components, browsers, third party software, etc. That way they don't have to wait yet more years before providing this system for use by all users and developers. For example I love the fact that VS Code and Spotify update on their own with no interaction required. I wouldn't love if something I don't want to update in our server fleet gets updated but I don't see many snaps in that area. But if we do see that I'm sure both of us can come up with a one liner stopping snap from updating if and until that use case is supported. Besides, the server space is gravitating towards immutability anyways, so doing something like `chmod -x $(which snapd)` or `chmod -x $(which apt)` on a production machine shouldn't be a big problem in that context. In fact that's one foolproof way to make sure packages are what you want them to be after installing them. Or read-only file systems.