Hacker News new | past | comments | ask | show | jobs | submit login
Ubuntu Snap auto updates broke my development setup, can't turn them off (raymii.org)
57 points by hernantz 49 days ago | hide | past | favorite | 35 comments

The more I read about Snap, the more its user-hostile behaviour bothers me.

I've read again and again (on here, of all places) that snap packages are _great_ for server administration, but I feel like production machines are a place where you wouldn't want a random assortment of packages updating. I can hear the sysadmins scream already, from here.

With the fact that Snap (and Flatpak) package releases are often delayed due to whatever vetting needs to take place (plus packaging or rollout delays?), combined with the fact that it can and will auto-update without your approval, even if you've told it otherwise, it sounds like the worst of both worlds.

For what its worth, Pop!_OS also doesn't use snap... and of all things, the reason why I switched from Ubuntu 20.04 to Pop!_OS was because the calculator took five seconds to load (of course, being a snap package) on Ubuntu, and milliseconds, on Pop, as it should.

>combined with the fact that it can and will auto-update >without your approval, even if you've told it otherwise

This behavior is easy to rationalize if you think of it as a business decision. Canonical is happy to sell you an "enterprise edition" app store (a so-called "brand store") that restores full control of app updates. See https://core.docs.ubuntu.com/en/guides/go-to-production/adva....

I don’t understand who wants auto-updates.

The best practices I’m familiar generally have immutable things (images, containers), with new versions deployed continuously (with a build & validation pipeline). In-place upgrade just adds new failure dimensions, let alone automatic in-place upgrade.

"Microsoft is doing it"

If you're a consumer it's great, you just get the new thing automatically without having to do anything. But of course that can be realized with an off-button if you're not an asshole.

With Flatpak you can have your own repositories. Therefore packages can be released as soon as developer wants, without depending on someone else deciding whether to allow for that or not.

I believe the author is (partially) wrong. You can use 'snap revert' to revert to the working version of CLion. For example for the hugo snap.

sudo snap revert hugo

will revert the hugo snap to the last version.

He is right that you have (almost) no control over snap updates. The snap will be refreshed if a new version after the latest is published according to the docs.


I am a little disappointed in this. I expected to be able to pin a software version or at least be able to access a lot more than the very last version of a snap. A lot of software publishers (both proprietary and open source) like to break compatibility with plugins that would break your workflow. You may be waiting a while for your plugins to update (or you give up on your plugins once other plugins show up or the new version has matured enough for you to move over).

A quick search of Flatpak shows that you can revert an older version and have more options to choose from.


Also, Flatpak's 'mask' command may allow you to pin a version?


Perhaps someone familiar with Flatpak can chime on it. Last I used it Atom was still popular.

This mirrors my experience. I've been a mostly happy Ubuntu user since 5.04/Hoary, baring a few bumps like Unity and pulse audio becoming defaults before they were polished enough for general release.

But after upgrading to 20.04, and fighting with Snap slowdowns, and yet another change in desktop direction, the weird data sharing of searches with Amazon, and weird power management problems on hardware that had previously "Just Worked", I just had had enough. I switched to Mint a month ago, and haven't look back.

I love how Ubuntu has brought Linux into the (somewhat) mainstream, but I'm just over how much it keeps changing direction, and releasing things before they're ready.

Get over that damn Amazon link already. It's been gone for years!

> It's been gone for years!

That's simply not true. It was there until earlier this year[0].

Regardless, even if it had been removed years ago. It wouldn't have made any difference to my remarks or decision. It's just one more straw on the proverbial camel's back.

[0] https://www.omgubuntu.co.uk/2020/01/ubuntu-removes-the-amazo...

Snap auto updates brought down a 4 node Raspberry Pi 4 lxd cluster I was running in my home lab. One of the nodes went down and before there was a chance to address it snap decided to auto update lxd on the remaining nodes. Since the down node wasn't updated this caused the entire cluster to fail because not all the cluster members were on the same lxd version. I was able to force remove the down node from the cluster to bring things back up.

As soon as possible I moved away from lxd which is a shame. It met my needs better and was easier to manage than k3s which replaced it. Unfortunately as long as it is only available as a snap it is a non-starter for my lab. I don't see how it could possibly be considered for a real deployment.

The way canonical is pushing snap reminds me of how Google once tried to force Google+ into everything.

Seriously? You aren't able to install LXD via apt any more? Suppose that's what you get when a product is owned by Canonical...

That's right.

You used to get LXD over APT but they changed it and now you can't.

Well there's an APT package, but it simply tells Snap to install using Snap. You can do the latter yourself and get the same result either way.

Most of my servers use LXD for containers, and started doing so when it was over APT like any other package.

Then it was like a much improved LXC, and pretty nice. Things "just worked".

It's just as well it's like an improved LXC, because the commands are both "lxc" -- to maximise confusion! I need both old-style LXC and new-style LXD-pretending-to-be-LXC installed at the same time, because some LXC container images fail to run under LXD.

The change to forcing Snap is literally the only use of Snap on my host servers now. It's annoying and disconcerting. I'm still not sure if it will auto-update or not, and I daren't find out by switching to the current version of LXD. I'm sticking with an old version, which seems safer!

I could study Snap and get to know it, but that seems silly given I don't use it for anything else.

It's also annoying because of the mount points and data isolation inside Snaps, which I've basically had to workaround. I appreciate the benefits of container isolation, of course, but it did require some bind-mounting to accomodate my existing images and configurations.

In due course I expect I will switch out LXD for Kubernetes. That will be a pain, because K8s/Docker are not optimised for running distro images, but I don't think the pain will be any worse than trying to obtain certainty about LXD+Snap's evolving behaviour, and daily familiarity with K8s has far higher market value.

Which is a shame, because LXC and LXD are great technologies, and the various packaging and relevance issues have made even old-style LXC something to move away from.

Yes, it's weird that it can't be turned off, but the snap documentation is very clear about the auto update.

Snap versions also can be reverted.... it is annoying, but the article is a bit overdramatic, since it's not a secret..

RocketChat has this issue to. They work around that by delaying the snap release for weeks. And they also provide different update channels.

You can use the revert command to revert to the last version, but what if you want to pin to a specific version? From what I've heard, that is not possible.

... and what if you revert a package, and a new version gets published, will it pull the rug out from under you and update again?

Then don't use snaps.

It's not snap that broke the IDE/Workflow. The author decided to use an install method that auto updates and the authors of the plugins didn't checked compatibility with the latest version.

This is more of a lesson of "don't auto update important tools" than "snap bad".

Under Ubuntu, you don't have a choice any more.

Some packages that used to be found under APT, in older versions of Ubuntu, are now only available via Snap.

Chromium was due to the absolute nightmarish amount of manpower on Canonical’s part it took to keep up packaging with releases. Copying Debian’s work wouldn’t have helped because they had and still have fewer resources than Canonical did to commit to packaging it.

LXD ships a private version of a library as it has changes not accepted by upstream. It pretty much needs to be a snap as it doesn’t fit into the realm of .deb packaging due to that.

Two fits “some”. Off the top of my head I cannot recall anything else that has a .deb that diverts to snap. More might come in the future perhaps. 2020 has not been the kindest of years to bookmakers in Vegas and elsewhere.

I, for one, refuse to use snap. While I do admit It makes some things stupid easy to install, there are trade offs. First. The fact that it’s breaking things is bad. Second, for every snap install there is a ‘/loop/blah” entry in your did output. This is severely annoying and not needed IMHO. While breaking things is far worse, little annoyances have an effect. I will personally avoid snap and stick to installing things the way I always have.

Every single time that I’ve tried Ubuntu it’s been killed by an update.

Manjaro is the only distro that was stable enough to keep running without fail. Been running it for 2 years now. One of the best things it has over Ubuntu is the ease of installing software. No more hunting down keys or PPAs.

I guess Ubuntu will provide a enterprise edition of Snap in future. It will allow users to suspend updates.

Don't use snap.

There will never be any such thing as a free lunch.

I have never understood why so many people think installing Ubuntu is a good idea. It's not like there is any shortage of absolutely outstanding distributions. Debian, Arch, Nix, Suse, Fedora, Gentoo -- something for everyone, none habitually weird.

I can tell you why it is a good idea for me.

After having tried most (major) distros available over and over again, I decided about 2 years ago that I will just stick with Ubuntu in the future. Why is that?

- Stuff just works (better). No matter which hardware I used, Ubuntu was always the best out of the box configuration. I am getting to old to spend 2 days on setting up an obscure printer driver on arch e.g. These days I just want to be able to print as soon as I boot the first time and use my time for better things.

- It's polished. It just has the best desktop experience of all distros. The fonts look good. The theme does not look like a mess of things jumbled together.

- Most software is available in the repos or you can download a .deb package or use PPAs. The rest I can as usual just build myself.

The only "downside" for me is that it is not a rolling release.

Same. I use xfce + plank + autorandr with hooks, and a bunch of keyboard shortcuts for tiling. Don't really care which distro is underneath but Ubuntu has been my choice for about 13 years straight.

I removed snap after a very short time because I hate it's while also. It's easy to get around the requirement for snap by repackaging them in .deb packages. Just install the snap a vm, find apt packages that provide the deps you need (examine the snap, use ldd/strace). Once they're added to the DEBIAN/control, build. If specific versions are required and aren't available in apt, bundle them and set an LD_LIBRARY_PATH. Use strace if shit still doesn't work). I'm probably not gonna bother updating those apps very often.

Ubuntu UI, snap, search, some small design decisions is annoying though. So I'd recommend try Fedora or Mint first, for a more polished experience.

Well I disagree. As I said, I basically have tried them all.

I like the Ubuntu UI. I have customized shortcuts a lot but I like the current gnome.

I am still undecided about snaps. I have only a few installed and I am glad they were available as snaps (emacs 27 e.g.).

Not sure what you mean with search.

Then probably Debian + nice theme is already enough for you

mostly because for many people it has the most comfortable defaults. Unless you go for the non-free ISOs Debian is too barebones and stable ships extremely old software, rolling releases like Arch may break at any point, Suse often lacks 3rd party support for proprietary software and so on.

Fedora is pretty solid but also very much on the experimental side, like shipping Wayland as a default versions ago when half of the applications didn't work right.

I've defaulted to Ubuntu because it 'just works', every other distro I just have to spend time to do what Ubuntu does anyway.

The "newer" packages in other Debian based distros are pretty much the same as in Debian testing /unstable / experimental. I have been running Debian unstable on business laptop for more then a decade now. If I had issues, I would stop, but I haven't. Hopefully this gives you some confidence.

You should give the more recent fedora versions a try. The MATE release has been turnkey on my hardware for a few years now with no loss of functionality including hotkeys, hotplugging multiple displays, power management, etc.

Approximately everyone goes to the non-free Debian installers, and upgrades to the "unstable" version immediately for anything they care about having current. I have not encountered anything supported in Ubuntu but not in Debian unstable. Ubuntu stuff mostly comes from Debian unstable, but with added weird.

Nice to see NixOS mentioned. Haven't tried it yet, but it's cool seeing such an innovative distro.

Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact