My position is not that certain users would prefer to update on their own schedule. Of course there are.
Or that new updates sometimes break things and that's a hassle. Of course they do and it is.
The problem is if you want to distribute an important security update, what do you do? Ask everyone nicely to upgrade? How? Again, what % of users will manually update their software? Not a lot.
For #2, that seems like a resolvable problem that can be brought to Canonical. I'd prefer to see auto-updates fine-tuned rather than have super users immediately dismiss the idea in general.
It's just my opinion but I think the greater good of the Linux community is served by auto updates, even if occasionally it means an update to an individual application has a bug here or there.
Maybe this doesn't apply to you but I wonder how much of the Linux community just doesn't like change. Sometimes Canonical stuff does crazy stuff (Mir?) but auto-updates seem like a noble principle worth attempting to adopt.
> The problem is if you want to distribute an important security update, what do you do? Ask everyone nicely to upgrade? How? Again, what % of users will manually update their software? Not a lot.
The thing is, I do not give a rats ass what the maintainer of the software wants.
I’m sure they’d like their software to be patched quickly on all the PC’s that use it, and more power to them. But I do not want their decision to patch something to affect my system unless I explicitly tell it to, period.
If I do want my software to update automatically, I’ll enable that. Just don’t force it onto me.
> The problem is if you want to distribute an important security update, what do you do? Ask everyone nicely to upgrade?
What the application author wants isn't all that matters. It's the user's system, so they install what they want when they want to.
Ensuring that the user can easily install important updates while preserving the overall order of the system is the job of the disto maintainers for the distro the user has chosen. This is the whole point of distros. The alternative, where each individual application author has free rein to jam their app into the system without coordination, gets you the kind of mess Windows has.
This. It is of no concern what the developer wants -- it is the USER's system. If there is a reason I want to be backreved on app or library XY or Z it is my concern. This is really the most bone headed change I have seen from ubuntu.
It is "fine" to make auto updates the default.
It is "not fine" to make it the only option.
Have some respect for your userbase. Who was the bonehead that make this call -- so stupid.
I guess that, exactly yes, they should ask! The problem people have is that there is no way to turn them off, not that they exist. This is nothing to do with change and everything to do with taking control away from the user. For some users, yes, that may be beneficial. But without at the very least giving the option you're also alienating many more. I want to update my system when it's convenient for me to do so (particularly because I'm currently in a location with very poor internet), not when I'm in the middle of important work, at the whim of my operating system.
Edit: Apparently you can set a preferred schedule for the updates (from another comment)? That's still one more thing I need to think about, that I shouldn't have to. Just make it optional and everyone is happy.
The problem is that you want to control your users, but when and how they upgrade is frankly none of your damned business. This busybody attitude has proliferated in software and it's an unfortunate direction our culture is going in. FLOSS software should be where we fight that the most.
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.
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.
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.
I think there would be a lot less complaining about the existing unattended-upgrades functionality being enabled by default on dektop, than the new self-updating capabilities of snaps.
Honestly, this wasn't a real problem. If you just turn on automatic upgrade in apt/Ubuntu updates/whatever and leave it that way, a user can change things and all is well.
I have this vague feeling snap is here to stay but I don't like it.
Or that new updates sometimes break things and that's a hassle. Of course they do and it is.
The problem is if you want to distribute an important security update, what do you do? Ask everyone nicely to upgrade? How? Again, what % of users will manually update their software? Not a lot.
For #2, that seems like a resolvable problem that can be brought to Canonical. I'd prefer to see auto-updates fine-tuned rather than have super users immediately dismiss the idea in general.
It's just my opinion but I think the greater good of the Linux community is served by auto updates, even if occasionally it means an update to an individual application has a bug here or there.
Maybe this doesn't apply to you but I wonder how much of the Linux community just doesn't like change. Sometimes Canonical stuff does crazy stuff (Mir?) but auto-updates seem like a noble principle worth attempting to adopt.