Live data from Hacker News

Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

jatan.blog

551–560 of 645 posts

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#551

Earlier quoted context omitted.

A colleague of mine was also looking at Ubuntu Core for an IoT project recently, but Ubuntu wanted $15k/y to run a private, branded Snap store - erm.. no. If they really want snaps to succeed, there should be an open source snap store protocol, and 3rd parties should be allowed to run their own stores, just like you can add 3rd part apt repos, for example. We decided on Photon OS, BTW. It's tiny, and perfect for use…

Isn't there some old adage about how if you can't afford something you aren't the target audience. At the larger companies I've worked at you didn't even need approval for 15k/y.

At the two larger companies I've worked at (~1,000 and ~50,000), I've been explicitly told that I cannot sign any contracts without getting it approved by the legal department. Furthermore, all software purchases must go through the approval process.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#552

Earlier quoted context omitted.

Exactly. It seems like these days everyone assumes you are on a stable broadband connection. In many parts of the world getting a fast and stable internet connection is literally impossible.

Did you tick the metered connection box?

This is from the blog.

> Even on metered connections, snaps auto-update anyway after some time.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#553
post #421

I am very diligent about applying updates as soon as I'm able and generally read the changelogs of the updates I'm applying in Ubuntu's Software Updater. One thing I will not do is willingly allow somebody else a way to deploy and execute code on my computer without my say so (which snap is). After reading the whole thread at https://forum.snapcraft.io/t/disabling-automatic-refresh-for... and seeing Gustavo Niemeyer'…

It's probably not a surprise to you, but this is a hotly debated topic inside Canonical. And I apologize for that thread, as it really doesn't represent our best attempt at external debate. Changing a paradigm usually involves pushing the envelope and breaking some existing assumptions; systemd is everybody's favorite example of that in the Linux world. The root of this issue with snaps is the trade-off between built…

Sorry, but as a fellow Canonical employee, speaking from a throwaway obviously, it's evident to me that you're simply not telling the truth here.

You know just as well as I do that if you criticize Snap within the company, you get fired. Especially if Mark overhears you. There is no room for criticism. You either drink the koolaid or you shutup. So, no, sorry, we're going to keep pumping out Snap and those who don't fall inline will just fall out of the company. This is how we've always done these things, despite it failing repeatedly, and Snap is no exception. Actually, Snap is in particular no exception, given how hard it's being pushed by top level management.

[An aside from the main point of this comment: your point 3 is nonsense, and any security guy will tell you the same. For packages that the main sudo-ing user executes, sandboxed or not, there still is effectively no difference between that and root. Snap's sandbox is alpha quality at best, and major platform hurdles remain to make it capable of doing anything remotely useful. Say no to auto-updating snap backdoors. Please. There's a reason why Linux has thrived and benefited with its vetted-by-distros traditional package managers.]

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#554

Maybe I'm in the minority but I like Snaps. I wish all software would auto-update silently in the background -- when's the last time you even thought about upgrading Chrome? The author of this article claims it's too difficult to find Flatpak apps and that the Ubuntu software center prioritizes Snaps over .deb. Are platforms never allowed to migrate to a new standard? Why is it Canonical's fault that authors of indiv…

> Why is it Canonical's fault that authors of individual applications have yet to migrate Snaps?

Canonical is the one pushing for snaps, and they own the centralized Snap store. On most other distros snap support is either non-existent or much less than for package manager or even flatpak. Let me turn that question around. Why should individual application developers have to package their apps as snaps, which are mostly just used on ubuntu?

> Maybe I'm just naive and not doing advanced super user stuff these Snap haters are doing

Most of the complaints here have been about the automatic updates (and specifically that you can't disable it, not that they are on by default). But, personally, I am more concerned with the fact that snap apps run slower. Snap uses squashfs for the program and any associated files, and squashfs is not designed to be fast, it's designed to store a file system in a small amount of (usually read-only) space, such as on a Live CD. Besides slower startup times, snaps also take up more space on disk (which may not be a huge issue for most people), and more time to download (a bigger issue) since each snap has to include its own copy of all its dependencies.

The containerization of snaps provides some security benefits, but there are also a couple security concerns with snaps:

- Unlike the official apt repos, the snap store is not curated. It is much easier to put malicious software on the snap store than get in the official apt repos.

- Since all dependencies are bundled with the snap, if there is a vulnerability in a common dependency, such as libc or openssl, then instead of updating a single package on your system to get a fix, you need to update all of the snaps. And you are dependent on the maintainers of all of those snaps to watch for such vulnerabilities and make sure their dependencies are kept up-to-date.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#555
post #547
post #391

Earlier quoted context omitted.

The browser is actually the number one component you should update as soon as a security fix comes out. If you don't want new features ("more free stuff!"), use an LTS version that only includes the security updates?

> The browser is actually the number one component you should update as soon as a security fix comes out. The problem is that there is no way to have a browser that only pushes updates for security fixes. They're always mixed in with changes to the UI that force people to re-learn workflows. > If you don't want new features ("more free stuff!"), use an LTS version that only includes the security updates? There is no…

>The problem is that there is no way to have a browser that only pushes updates for security fixes

Yes there is, it's called firefox esr.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#556
This kind of unconstrained and minimally accountable automatic update is incompatible with strong security.

I already wouldn't use ubuntu due to their long established phone-home practices, but this further strengthens the case.

FWIW, I'm pretty happy with the recently released Fedora 32 so far.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#557
post #99

Earlier quoted context omitted.

The promise is that providers can build one package for all Linux distros, Afaik. Less work for packagers. More packages for obscure distros.

"Less work" undersells it, in my opinion. What snap (and things like it) do is promise to remove the support headache upstream providers get from users still using a version that was current 5 years ago which happened to make it into an LTS distro release because that happened to be the most recent build a packager had working at the time.

Love it when vendors shift their responsibilities onto users. Silently updating some piece of software on that 5-year-old LTS release might break the workflows of hundreds of people. But it's all good! It saves the vendor some "support headaches".

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#558
post #421

I am very diligent about applying updates as soon as I'm able and generally read the changelogs of the updates I'm applying in Ubuntu's Software Updater. One thing I will not do is willingly allow somebody else a way to deploy and execute code on my computer without my say so (which snap is). After reading the whole thread at https://forum.snapcraft.io/t/disabling-automatic-refresh-for... and seeing Gustavo Niemeyer'…

It's probably not a surprise to you, but this is a hotly debated topic inside Canonical. And I apologize for that thread, as it really doesn't represent our best attempt at external debate. Changing a paradigm usually involves pushing the envelope and breaking some existing assumptions; systemd is everybody's favorite example of that in the Linux world. The root of this issue with snaps is the trade-off between built…

Let me point out: to me, auto-updating isn't even the crucial issue (I use unattended-upgrades as well, so whatever).

Yes, functionality and workflows around installation and updates are still insufficient for many use cases, but that could have been ironed out given enough time.

But what you messed up badly, IMO, was to force-migrate packages to Snap in an LTS release before it was ready.

Had you waited until Ubuntu 20.10, I'd have been more forgiving. But you (collectively) were so eager to get this in before the window closed for another two years.

If you had made Snap a compelling product, even LTS users might have voluntarily migrated to snaps once they saw how good it was. Now you've kind of pulled off the opposite.

Sadly the ship has sailed: Both in general, since you've pushed so heavily for Snap in a LTS release when it simply wasn't ready yet. And for me personally, where the forced installation of Snaps by some debs (notably Chromium) broke my trust significantly enough that I turned my back on Ubuntu after over a decade.

Not only is the Chromium Snap dog slow, it also can't see my NFS shares. So the snap version is objectively worse, at least for now.

But if I install a deb, I expect to get a deb. You don't want to offer it anymore, fine, take it out of the repo. But sneakily migrating me to a snap, and not even notifying me, is just trust-breaking.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#559

Earlier quoted context omitted.

The the very least there should be a simple way to turn off snaps entirely. As in, when installing do we want any snaps? If we don't, don't even install the snap ecosystem. After install, have I decided I don't want snaps? If so, uninstall the entire ecosystem. Do these options currently exist?

The challenge is that a) we don't really want to (can't afford to, etc) maintain a forked package for everything which comes in snaps and b) snaps are really, really, much better for publishing and maintaining certain classes of application, in particular complex ones with hundreds of dependencies and a massive surface area, like a web browser. And users want web browsers, so the default is to include snaps. In gener…

If there are ever any 'potentially critical components ... only available via snaps', many of us will bail to distros that don't have that weakness.

I don't use, but see the advantages of such packaging. But auto-updating software (FOSS or blob) brings-in it's own barrel of concerns. In the event of something 'critical', a -message- alerting the user ... who can then research and decide ... is far preferable.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#560

I really dislike the way snaps create disk partitions. When I run $ df I want to see what I defined during OS installation, not a dozen nasty snap mounts. An application misusing fundamental system features like this feels like a violation of some UNIX principle.

Couldn't agree more. I have resorted to using an alias:

alias df='df -x"squashfs" -x"tmpfs"'

Post reply on HN