Comment by capableweb | Hacker News Reader

Comment by capableweb | Hacker News Reader

Parent Full thread

My two cents, you don't have to agree but thought I'd just add a different perspective.

I prefer my own package manager (pacman) over snaps for the following reasons:

1) I like to upgrade on my own schedule. I use my computer for work, and I cannot have things break in the middle of the day or in the morning, just as I get started with work. I usually save upgrades for when I less things to do, so that in case stuff breaks, I can spend time fixing it. This has happened twice during the last 2 years, or something like that. One time Firefox got broken (or rather, the version upgrade broke an extension I use) and second time some API in neovim changes to a couple of plugins broke. If this breakage would just happen by itself, it would break the two most common tools I use on a day-to-day basis.

I've used both Windows and OSX for my professional work and while Windows is the worst offender when it comes to automatic updates, OSX is pretty horrible as well. At least with Windows you can expect some sort of backwards compatibility, while on OSX, one day you have to upgrade your entire OS, otherwise Notes or some stupid application won't launch. On the other hand, Windows eventually forces you to upgrade no matter if you like it or not. So both of them suck equally, but in different ways.

2) snap seems to create mountpoints for the applications and never removes them. When trying snap apps I always end up with bunch of pollution in my environment. Could be that I'm using snap/snapd wrong, but left a sour taste in my mouth, as I saw snap as something that wants to solve a problem that existed for a long time. Instead, they look a bit amateurish because of this.

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.

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.

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

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.

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.

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

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

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.

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.

> I think the greater good of the Linux community is served by auto updates

"Greater good"? You sound like an ambassador for Red Star OS[1]. :)

[1]: https://en.wikipedia.org/wiki/Red_Star_OS

I get your points. In situations where Ubuntu 20.04 machines are on airgapped networks or corporate networks that use mirrors and the like. For personal and other situations I prefer flatpak and snaps...

> I like to upgrade on my own schedule. I use my computer for work, and I cannot have things break in the middle of the day or in the morning, just as I get started with work.

You can arrange snapd to update on your preferred schedule. What you cannot do is defer updates forever.

Yes, I can. This is my computer, and if snap does not obey my wishes, it‘s getting removed.

You can just not install Ubuntu

That is pretty much the thrust of the OP itself, and most of the agreeing comments. So While true, it doesn't seem to be much of an observation.

At the same time, it's also perfectly valid to instead, express what you want and don't want, and generally try to fix something that has broken or correct the aim of something that has veered off course.

Approving of the new change is also valid for that matter.

The only invalid thing is telling whichever camp you're not in that they can leave if they don't like it.

Remember, this is a change, not just the way something has always been.

How about, if you like the idea of everything packaged in the form of snaps, and all those snaps updating themselves outside of your control, you can just go find, or create, some new distro that works that way, instead of changing one that already exists and forcing all it's existing users to either accept the change or move, to accomodate a change you like?

"Take it or leave it" are not the only options, and it says something unflattering about anyone who tries to suggest that they are.

This is the most constructive comment I've seen in this thread.

Would iptables help block snap from reaching out?

>What you cannot do is defer updates forever.

Says who? AFAIK the person who paid my hardware (me) is who is in command.

Reply on news.ycombinator.com