[mrweasel]

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.

[rcxdude]

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

[tssva]

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

[rcxdude]

ah, that helps, it must be a new addition, I previously tried and failed to find a way to do this.

[sdeziel]

`snap refresh --hold` will hold updates indefinitely

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

[hkt]

I suspect the thing people find offensive is that this is not the default

[mekster]

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.

[tpxl]

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

[horsawlarway]

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.

[severino]

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.

[mrweasel]

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.

[mrweasel]

That's at least a comfort that they finally implemented that, I haven't used Snap in the past year, so I missed that.

[packetlost]

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.

[totallywrong]

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.

[a1445c8b]

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!