Hacker News new | ask | show | jobs
by totallywrong 1084 days ago
Stéphane Graber's work is fantastic and LXD had a lot of potential. But Canonical managed to drive me away from it with that abomination called Snap and its auto updates that could bring down a cluster without warning.
11 comments

It is really sad that more people aren't aware of LXD, because it is a really good solution of a number of projects and it's really well done.

On Snap... Even if you like Snaps packages, I can't imagine that you'd feel like it's a good choice for LXD. For a browser or email client, sure it's a solution, I suppose, but for thing like LXD it just adds an entire level over complexity that doesn't help. I'd go so far at to say that Snap packages makes LXD unusable, it's simply to complex, to messy. Canonical also have Microk8s (I think) which is packaged as a Snap, rendering it completely useless. The mental overhead required to make it function completely eliminates the point.

It also completely ignores highly regulated businesses, because Snap does not care and will just roll out an update whenever it feel like it.

I don't particularly like Snap, but I can see the use on desktops. For the server side... I don't know anyone who'd thinks it's neat.

It's also annoyingly opinionated in stupid ways. There's no supported way, for example, to adjust which services are enabled or not, and especially there's no concept of 'started but not autostarted', which can be important on a server (it's also obnoxious on the desktop as well, since it seems like a lot of the results for trying to fix this is people saying 'how do I stop snap slowing down boot').
According to the documentation services can be enabled and disabled. They can also be started but not enabled to automatically start.

https://snapcraft.io/docs/service-management

ah, that helps, it must be a new addition, I previously tried and failed to find a way to do this.
`snap refresh --hold` will hold updates indefinitely

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

I suspect the thing people find offensive is that this is not the default
If the reason of snapping is that their preference isn't the default, life must be quite tough for them.

If there's an option, live with it and change it.

I can't see what's so destructive about snaps. It's probably another echo chamber when people find a common target to yell at.

> I can't see what's so destructive about snaps

The implementation is shit.

Things take 10 times as long to start.

There are annoying 'Turn off firefox so snap can update it' messages. Nothing happens when you stop firefox, you'll just get the same message a few hours later.

Shutdown is going to take ages for some reason because it's waiting for snap to do something.

I don't give two shits about whatever snap is trying to do, but having to wait 10 minutes for my workstation to be useful whenever I want to reboot is not what I'm about.

Professionally, the company I'm at ditched ubuntu in our CI builds because of snaps.

The packaging is very limiting, and I don't want to have to fight against the system to get a version of software installed that works.

I personally used to run MicroK8s (snap based). I finally gave up about 6 months ago. Were snaps the root cause? Eh... no, the root cause was dqlite synchronization problems that I was tired of dealing with, but snaps made the whole process so much worse. They're hard to automate, they're hard to interact with using normal tooling. They just aren't part of the system in the same way, and while I understand there's value there (hell - I'm running containers and microk8s for a reason) there's also pain. K8s was an okish trade on that front: I felt a lot of pain and gained a lot of value.

Snaps seem to be falling into the worst possible spot: I'm feeling a lot of pain and the product is usually not any better at all (and sometimes much worse).

HA Microk8s with snaps and nvidia-container-toolkit (The GPU addon) just isn't all that stable (I would consistently get hard lockups on some hardware). That same hardware running Arch and k3s is chugging away beautifully.

So maybe it is an echo chamber - but the echoes I keep hearing are system admins saying this is making life harder and they don't understand the upside, and Canonical pushing forward anyways.

---

So maybe there's light at the end of the tunnel somewhere for snaps. Maybe the grand vision will eventually come and folks will be fine with it. But my suspicion is that Ubuntu is being replaced at most orgs before then.

Steam is throwing weight behind Arch (LOTS of new linux users coming in here). Alpine is a strong contender in containers. Nix is interesting.

Both Flatpak and AppImage seem to achieve the "easy user installs" part without all the pain of snaps, and they're neutral on whether I use them or not.

Basically - if snaps were so good (even if they're only good in some cases) I would expect a conversation about snaps similar to that of SystemD - Strong arguments on both sides, real advocacy from the community for the product, even if it's painful to adopt, or doesn't meet all user needs.

Instead snaps are just "meh" all around. There's a steady stream of folks leaving, and no real advocates outside of Canonical. At most - you have neutral folks like yourself who just don't mind snaps.

To me - that's a bad sign. I bailed. It wasn't worth betting my personal projects on. I've been pretty happy with the decision too.

Well, it depends. I liked upstart, I liked Unity (I still use them as long as I can!) and I didn't dislike Mir, although it never came to anything. But I don't thing snaps are good, at least for me. But what bothers me the most about snaps is not what I consider to be technical deficiencies or annoyances, but the fact that it's becoming the only way to install some software packages in Ubuntu, with no other alternative than leaving Ubuntu for good.
It seems like it was only introduced in December, so I can see why they haven't made it the default. It would be rather surprising to have run a Snap package for the past six years and then suddenly have it stop updating.
That's at least a comfort that they finally implemented that, I haven't used Snap in the past year, so I missed that.
You've been able to specifically schedule refresh times and interval's for awhile now. We did it monthly at a specific time and then set a calendar event with a couple notifications to keep track of it. IMO the "I can't turn off the updates" concern is overblown. If you aren't patching your systems ever you have problems anyways.
Overblown? Tell that to people that were hit with production outages. The whole idea of automatic updates for software running critical workloads is so stupid that I lost all respect for Canonical as a vendor.
The problem with auto updates for daemons and services is that the maintainer cannot possibly account for all the different ways their software is used to be able to guarantee that the new version doesn’t break some critical service. It’s akin to a team outsourcing their CI/CD pipeline to some 3rd party who have no idea they exist!
Yeah I'm setting up a Debian 12 Bookworm machine right now after ~13 years of being an Ubuntu user

So far it's very snappy! My Ubuntu 18.04 machine somehow "rotted" in ways that previous installs didn't -- everything became slow and janky, sorta like Windows

And I specifically installed 18.04 in 2021, to avoid Snaps

But now it looks like Debian will work great

> My Ubuntu 18.04 machine somehow "rotted" in ways that previous installs didn't -- everything became slow and janky, sorta like Windows

Oh man, this reminds me of two years ago. During Covid lockdowns, I figured I'd try Ubuntu, see what's up with gnome. This was 20.04. I was pretty meh, but it was okay. Then I found out about Regolith [0], which is a "spin" or whatever it's called, that comes with i3 (like Kubuntu has KDE instead of Gnome).

I don't know exactly why, and I was too lazy to dig, but that thing was one of the most sluggish experiences I've ever had. At the time, I'd daily drive an i5-6500 with integrated graphics, and my regular Arch with i3 and light Picom effects (blurring for notifications and dimming inactive windows) worked great on the integrated GPU. Somehow, the Ubuntu version was worse on a newer i5-8500.

[0] https://regolith-desktop.com/

I'm in literally the same boat, on Debian now because of snaps. Their other homegrown stuff were mostly out of the way, like Unity or upstart, but snap was just really annoying with how it's integrated into the system.
On OpenSuSE Tumbleweed now because of Snap, rolling releases, best of class KDE support and pretty good testing of packages.
Sounds attractive. I quickly read up on it, and apparently gaming is also not a problem. Next time I install Linux, I'll give it a whirl!
They also started shipping LXD recently.
I switched to Debian 11 for the same reasons around Christmas. I also found out faster than Ubuntu 20.04 and the fan starts spinning less often. I've been on Ubuntu since 8.04.

When I can I'm creating servers with Debian too, personal ones and for customers. The only problem there is that Letsencrypt uses a snap to update the certificates, even on Debian [1]. Not all my servers need a web server but when they do I usually use ngnix. I'm investigating alternative update clients with no hurry. When that is solved, goodbye to Ubuntu.

[1] https://certbot.eff.org/instructions?ws=nginx&os=debianbuste...

certbot is available in classic apt repositories in Debian and Ubuntu. No need to install it from snap.

https://repology.org/project/certbot/versions

Haven't checked, but looking at version parity between these 2 I think both have the same maintaining team for Let's Encrypt.
If you pick "pip" instead of a specific Linux distro it gives you instructions without a snap.
I'm afraid that this is only a wrapper around the snap. I quote from that page

> If you have any Certbot packages installed using an OS package manager like apt, dnf, or yum, you should remove them before installing the Certbot snap to ensure that when you run the command certbot the snap is used rather than the installation from your OS package manager.

That seems to be a doc issue. It certainly did not install a snap when I just tested this, and the certpot python package it installs explicitly checks to see whether it is running in a snap or not, which would make no sense if running it outside wasn't an option.
That doesn't mean the other means wrap snap. It just means in order to truly install via snap, you should remove the same package installed via other means before
I like acme.sh
I switched to dehydrated after LetsEncrypt snapped their client.
As a stepping stone out of Ubuntu, Pop_OS! has been pleasant and snap-free.
The thought of people going to Pop to escape snap has me crackling.
That gave me a chuckle while eating my morning cereal. Very good! :-)

For those who don't get the reference: https://en.m.wikipedia.org/wiki/Snap,_Crackle_and_Pop

Tbf it doesn't default to the really slow snaps. Instead it defaults to the dreadfully slow flatpaks.
You made this sound like snap is faster than flatpak. It isn't, unless something changed this year. Did something change?
My understanding is that Pop uses Flatpak sparingly, whereas Canonical is pushing Snaps for an increasing amount of software.

That is, IIRC, you get (say) Firefox via Debs in Pop. Canonical wants to install it via Snap.

IMO Flatpak is a great option for a set of desktop software where packaging across distros may be problematic for some reason. I use the Firefox Flatpak on Fedora / RHEL because it doesn't disable the video codecs, for instance. The native package doesn't have some codecs enabled.

Canonical is (AIUI) pushing Snap for desktop and server software. And Canonical is the only source of Snaps, I believe? With Flatpak you get Flathub but AFAIK anybody could set up a repo of Flatpaks.

Flatpaks have some startup time penalty, but it's an order of magnitude better than Snaps. They also have way better disk usage characteristics per installed package than Snaps do (they scale better).

You can use them side-by-side on the same system. Install a dozen of each and take some measurements.

Took me a minute. Well done.
I have tried it, and reviewed it.

I kinda like the window tiling, but it's still GNOME and GNOME is still a pain.

As a cleaned-up Ubuntu, I like Zinc.

https://teejeetech.com/2022/05/07/zinc-22-04/

Ubuntu, with the smallest cleanest but richest desktop on Linux -- Xfce -- and neither Snap nor Flatpak. Instead, `deb-get` which finds and installs native DEB packages, configures the repos for you, manages updates and so on.

I was on KDE for a bit, love it on my ultrawide monitor with tiling. But on my laptop Gnome is so sweat. I have a 2nd hand HP ProBook and I swear, for the very first time ever in my Linux life the trackpad feels like my MacBook trackpad. 3 fingers swipe up, overview of windows, another swipe is app grid, swipe left right, move to other desktops. I really find the whole experience very smooth and I enjoy it a lot (all Wayland, on NixOS).

I have suspend/wake working well so far, USB-C charging + screen + all peripherals via 1 USB-C cable, all "media" buttons work. And this is still on 8 GB of ram (soon the 2x32 GB will arrive ;)), I haven't even heard the fans so far! I'm on Teams, camera works, nobody would even know I'm on Linux if it wasn't for my constant evangelizing!

I'm really impressed (yeah, I know, Linux people easily are when it comes to desktops, basically we're impressed if things work).

I did enable AppIndicator. Solaar, NextCloud and Tailscale all really require it to be considered functional. I don't understand why that is not a standard thing (it is on many distros though).

> Gnome is so sweat

... Sweet?

I don't like GNOME. I don't like GNOME accessories; I hate CSD and hamburger menus and that big empty wasted top panel. I want more things vertical, while GNOME is moving its vertical workspace-switcher to horizontal.

The Cosmic tiling is good. That's an improvement. GNOME's window management sucks, and this is better.

I also really don't like systemd-boot and it broke one of my laptops severely.

So, I am happy that it is good for you, but it is not something I'd choose.

Arg yeah sweet indeed, pronounciation is just no guide at all in English (neither in Dutch btw)...

...Seat, sweat, chaste, caste, Leigh, eight, height, Put, nut, granite, and unite. ... [0]

And I do agree on the very high amount of pixels wasted in the top panel, expecially on an ultrawide monitor, something MacOS does better. On a laptop screen it's ok for me.

[0] http://ncf.idallen.com/english.html

Do you have a git repo somewhere with your configuration.nix?
Not yet, but it's fairly simple, I now have 1 week of NixOS experience ;) I installed with the graphical installer, choose Gnome, added some specific things like darkmode and many packages to the configuration.nix. Then I read about Home Manager and put packages under there.

OOTB the Gnome install was as good as can be. It's a nice way to play with Nix, batteries included.

Right now I need to deploy a server used for bioinformatics, and I need Conda... And that is a pain [0], so again I'm on the fence: Deploy Ubuntu or NixOS and persevere... I'm thinking Ubuntu, then perhaps later in the learning curve I go for Nix or perhaps just make a container to use on Nix.

[0] http://www.jaakkoluttinen.fi/blog/conda-on-nixos/

I will use them, at least for a while, when their currently in development Rust desktop env is out. Super curious how that pans out (as traditionally all popular GUI libs are very OO).

https://github.com/pop-os/cosmic-epoch

https://github.com/pop-os/libcosmic

https://github.com/iced-rs/iced

I had numerous issues with it, like the inputs would not focus in firefox-esr. Unfortunately I had to install Ubuntu 22.04 which works fine but has all sorts of annoyances like snaps and text ads in apt. Ubuntu didn't even set up grub right after I used custom partitioning to avoid nuking my /home partition, it only booted after I did a manual grub-install.
I did the same by the time Jessie was released. I realised the XFCE version was good enough, and I could use a few tools from the vendor binaries plus a couple of things I could compile.

Yes, it is more work, but since then I've been upgrading Debian and it just gets better!

Did the same ubuntu > debian transition a while ago… but then got fed up with old packages and other stuff. Nowadays I’m on fedora (xfce spin) and it’s just perfect.
Yeah, snaps can go to hell. In addition to what you already mentioned, they are extremely complicated to debug when things go wrong.
The left column of my Ubuntu machine is filling up with useless directory icons from pseudo file systems that contain Canonical's "snaps".
I agree. Snap is the weak point of LXD. I have been using it in production servers and until

snap refresh --hold

was made available my team went through the pains of snap workarounds [1]

The LXD team was very proactive in the support side but the truth is that Snap is a pain and without --hold it would be possible for production servers to break out of a sudden due to uncontrolled updates (who did every think that this was a good idea?).

LXD itself is a very good project because it uniformizes the use of containers and VMs with a friendly CLI - the syntax is more intuitive than the one from Docker, by the way. We recently managed to combine LXD and Puppet to manage containers and VMs in a declarative way. I am a big fan of the LXD project.

Somebody else commented here that the latest Debian makes LXD available in the normal distribution packages - that is something worth checking.

[1] - https://discuss.linuxcontainers.org/t/repeatable-lxd-install...

I'd like to hear more about your experience on joining Puppet and LXD, mind to share?
Moved completely off ubuntu after snaps were introduced. Sticking with gentoo now because it’s one of a few distros that doesn’t try to control what software you have to use.
This is the worse

>The LXD section on the LinuxContainers community forum will slowly be sunset in favor of the Ubuntu Discourse forum run by Canonical

A lot of useful lxd information are in forum.Stephane and the team is super helpful there.

Also snap auto update kills my containers so I had to put on held.

They also had just fixed a long standing bug that makes rebooting lxd container sometimes fails due to snap messing up with zfs mounts.

To this day about 90% of discourse links I click do not load. Seems to be some adversarial interaction with uBlock origin. As usual Canonical is on the wrong side of history.
I wonder, I don't remember the case like yours - I see LXD updates, but VEs (virtual environments) are kept running fine
Have you tried nixos? Its a totally different paradigm and definitely an acquired taste, but I used gentoo for ~2 years, then used Arch for ~5 and now am switching everything to nixos.

Main benefits is setting up a new machine is much easier, and updates are easier because almost all the normal configuration is managed by nixos (in the nix language) as opposed to regular files floating around etc.

Me too. Turns out alpine is better for server vms for my use case and cachyos is better for desktop for my use case as wrll (at least possibly until i figure out nixos)
I recently transitioned on the desktop from Debian then-testing to Alpine edge. I switched for a newer kernel (4.9 to 6.1 for recent fixes to busted microcode -- little annoyances around charging and the touchpad) but I like a lot of things about it: quick install, up-to-date repos, easy-to-understand init, battery lasts longer...
While at it, have you tried Void Linux? Sort of lightweight like Alpine, but much more convenient as a daily driver.
Do you use alpine for the host os as well as the vms? Been concerned that musl would prove a handicap.

Also, can confirm void is amazing on the desktop.

Can confirm alpine works fine as a libvirtd/kvm/qemu hypervisor, fwiw.

The one gotcha to be aware of here is that libvirtd as of now has two ways to be operated: Either run just the monolithic libvirtd service, or individual subsystems like virtstoraged. Trying to do both at the same time will cause issues.

Due to the limitations of OpenRC compared to systemd for interdependent and interoperating system services like this, I stuck with the monolthic libvirtd approach and it's been running fine so far.

https://libvirt.org/daemons.html#architectural-options

Oh yeah, I hated that when systemd would kill (restart) my libvirtd daemon (and my various VMs/containers whenever I adjusted my systemd-controlled nftable.

Monolithic libvirtd (which is disabling the systemd libvirt) is the way to go.

Nice, thanks. Though I was going to try using Xen on there, rather than kvm - any experience/thoughts on that?
Nope, but I'd be keen to learn of your results.

I was also aiming for Xen initially. However, my host just crashed (can't recall the exact dump) when I tried running a Xen kernel - Alpine or not. I never confirmed if it's due to the Intel N5105 lacking the proper CPU extensions to support Xen or if I could hope to hassle the machine vendor for a firmware update to get it working.

I would expect musl to be less of a problem for the host than guests, though, since a VM/container host only needs to run packaged software from the distro's official repos (mostly libvirt/docker, probably). What problem would you expect to hit?
no, proxmox is too good not to use. That runs on the bare metal and then the vms are all alpine at this point.
I'm also a big fan of alpine on the server.
Thankfully, the latest release of Debian provides LXD via .deb packages.
Really? That's great, finally I can get rid of snaps on my personal web hosting. I'll be testing it next week.
I run LXD on snap. It used to be straight up LXD using .deb. The switch has caused the host to continuously have a load of 3+.

SnapD is always the top process. I actually started a migration to Archlinux, which has LXD as native packages. Insane. I know.

The first think I always do after a fresh Ubuntu installation is removing snap entirely. Works fine in 20.04.
Snap has the capability to hold updates for any period of time https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...
unfortunately, the same for me. I would really like to spin up some lxd container on fedora but not with snap.
Stéphane made snaps too ? I hate them. I strongly dislike lxd too. If he isn’t a core person behind snaps he sure advocates hard for it.
He works for Canonical so I'd imagine he had to get on board with snaps, like it or not.
Working at Canonical shouldn't mean the only supported way to use LXD should be via snaps. It almost violates the whole idea of Linux.