Ubuntu 20.04 LTS’ snap obsession has snapped me off of it • Hacker News Board

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

#621

Post by Jonnax » Sun, May 03, 2020, 9:40 PM UTC

m463 wrote: post #512

shock wrote: 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'…

I have to use Ubuntu 18.04 for some things and even with a minimal installation, I found some things phoned home or pushed changes. I could remove some packages, like ubuntu-report or unattended-upgrades, but some seemed to be intertwined with other packages in a (purposeful?) labyrinth of nested dependencies. They made themselves critical and uninstalling would break or cripple other fundamental system components. S…

What's the benefit in all this effort for you?

It's not like you're paying them for support.

And it seems like you're modifying the OS in such a way that might break compatibility.

Also commercial software? Linux is commercial software. Red hat and Canonical.

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

#622

Post by pnako » Sun, May 03, 2020, 11:49 PM UTC

Jedd wrote: post #604

pnako wrote: post #580

Earlier quoted context omitted.

I don't see how it aligns with their ethical standpoint. Firmware is just a blob you load into the device. The alternative is to have it already burned into ROM. What exactly do you achieve by refusing to load it? Are you more free in one case and not the other?

If you feel it could be better documented than: https://wiki.debian.org/Firmware you could perhaps offer to update that page to remove the ambiguities you believe exist.

That page does not really offer any explanation.

For all intents and purposes, firmware is like a key or a password you must supply to the device to make it work. The driver, which is indeed open-source, just says: "here, device, is the firmware you need". That's it. You are not achieving anything useful at all by making people go through some ceremony to download it separately. Maybe they just want to send the signal that people should buy devices where the firmware is already burned into ROM or ASIC or whatever?

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

#623

Post by pdonis » Mon, May 04, 2020, 1:28 AM UTC

kikoreis wrote: post #608

pdonis wrote: post #546

Earlier quoted context omitted.

> The root of this issue with snaps is the trade-off between built-in security and user control. What this tells me is that I am not the kind of user you are targeting. I don't either need or want any such trade-off. I'm knowledgeable enough to make my own decisions about security; I don't need a third party to do it for me. So if your distro will end up insisting that I cede any control over what software runs on my…

Ubuntu does stand for a certain set of values; security built in and doing The Right Thing on the behalf of the end user are part of it. That does lead to certain distro semantics that I'm sure not everyone will like. And that's OK, we do appreciate that some people want to control more deeply what happens in the distro. There is a whole other set of users that would prefer that Ubuntu kept out of their way administr…

> We wanted to make it easier for software publishers -- think games, desktop tools, browsers -- to deliver their software to Ubuntu users, but debs were both too hard and too powerful to make that a viable proposition.

Is there somewhere--a blog post on Canonical's website, perhaps--that explains this in more detail? Off the top of my head I'm having a hard time seeing how snaps improve the situation, unless it's simply the "dependency hell" problem.

> nobody in the community reads through the source code of every patch applied to binaries in their systems

That's true, but irrelevant to the concerns of users like me. We aren't saying we insist on controlling when all updates are applied to our systems because we want to ensure that we have time to read the source code. We're just saying we insist on controlling when all updates are applied to our systems, period.

> There is a degree of assumed trust in any update.

Trusting that, for example, a particular update doesn't include malware is one thing. Trusting a third party to control when an update is applied to my system is something quite different. It seems to me that you are trying to conflate the two, which might be fine for some set of users (and, again, if that's simply the only set of users you are targeting, that's your call), but is not fine for me, nor I suspect for other users with similar concerns to mine.

> All of those installed as root!

Doesn't any update get installed as root? I certainly don't want system-level binaries installed to my user account; that would be a huge breach of security since my user would then have write access to them.

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

#624

Post by kikoreis » Mon, May 04, 2020, 2:26 AM UTC

guug wrote: post #524

kikoreis wrote: post #518

Earlier quoted context omitted.

FWIW, for this very reason, there is refresh.metered=hold, as I note in my comment earlier in the thread.

Will setting `refresh.metered=hold` prevent snap updates indefinitely? Can I mark all my network connections as metered?

I'm not sure how refresh.metered behaves when there is a network device change, but I assume it will, yes.

And I'm pretty sure NM lets you set all network connections metered, i.e.

  nmcli connection modify $CONNECTION connection.metered yes

See https://unix.stackexchange.com/questions/364927/networkmanag...

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

#625

Post by GekkePrutser » Mon, May 04, 2020, 2:54 AM UTC

efreak wrote: post #620

majewsky wrote: post #189

Earlier quoted context omitted.

Windows has a long history of tech-illiterate users downloading optimizer tools from shady websites that mess with registry keys and break stuff in surprising ways. And it's always Microsoft who gets the blame, not the shady utility. From that POV, I can understand Microsoft being reserved about gating this kind of stuff behind registry keys. These days, you can only do this stuff with group policies if I'm not mista…

Isn't group policy applied by changing registry keys? I've never actually looked it up, but I've always been under the impression that group policy changes just update registry keys that are checked by other software/parts of the os, and that the only advantage to using it (in a non-domain environment) is that it's the official way of doing it.

It does yes, but it also prevents the user changing it (or it changes it right back if they can). But it is possible that the feature requires a domain join to actually work, or perhaps the Enterprise edition of Win10. I didn't look into it.

It's annoying having to set up a whole windows domain just to disable this though :(

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

#626

Post by guug » Mon, May 04, 2020, 2:57 AM UTC

kikoreis wrote: post #624

guug wrote: post #524

Earlier quoted context omitted.

Will setting `refresh.metered=hold` prevent snap updates indefinitely? Can I mark all my network connections as metered?

I'm not sure how refresh.metered behaves when there is a network device change, but I assume it will, yes. And I'm pretty sure NM lets you set all network connections metered, i.e. nmcli connection modify $CONNECTION connection.metered yes See https://unix.stackexchange.com/questions/364927/networkmanag...

Someone on reddit stated that snapd will update snaps regardless of what value `refresh.metered` holds when updates are postponed long enough. Unfortunately, I haven't been able to verify whether this claim is true or false.

Canonical should be up front about this type of information.

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

#627

Post by GekkePrutser » Mon, May 04, 2020, 3:03 AM UTC

at_a_remove wrote: post #473

cartoonfoxes wrote: post #461

Earlier quoted context omitted.

Enterprise and Education only.

I got Windows Long-Term Service Branch (LTSB, now LTSC for Long-Term Service Channel) for precisely this reason. After having an update happen at a bad time, one closing a file I hadn't yet saved, and another killing a process of computations I had been leaving to run overnight, I decided that I wanted to use my computer the way I saw fit, not the way someone else saw fit. If someone cannot wrap their head around the…

True, LTSB/C is really really nice. It doesn't come with any of the crap/bloatware that MS package in the normal editions either. It's just clean and does its job. I love it.

It's just really hard to get officially for consumers. They should sell it to everyone that wants it.

And yeah, Ubuntu Desktop is kinda the "Windows Home Edition" of Linux though. Something like Arch, Debian or Alpine won't do this to you.

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

#628

Post by [deleted] » Mon, May 04, 2020, 4:30 AM UTC

efreak wrote: post #618

jquast wrote: post #67

Earlier quoted context omitted.

> On-demand decompression like this has made very little sense on desktops since the mid 90s Ok, maybe not desktops? But ZFS on-disk compression is a sysadmin's frickin dream -- just one example that you can access logfiles with plaintext tools like grep while benefiting from the space savings with neglible cost, LZ4 has basically no overhead at all, https://www.servethehome.com/the-case-for-using-zfs-compress... I r…

Can't you just alias cat to zcat and so on? There should be such tools available for just about everything that isn't a container format (zip, 7z, tar).

[deleted]

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

#629

Post by jandrese » Mon, May 04, 2020, 1:56 PM UTC

firmnoodle wrote: post #210

philliphaydon wrote: post #117

Earlier quoted context omitted.

What’s wrong with the windows one? It’s instant and it calculates things?!?

Yeah, I'm confused as well. I just tried Calc on win10 for the first time in weeks or months and it opened before I could count 2 seconds. This is from a SSD where it won't have been in cache.

2 seconds isn't instant.

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

#630

Post by lightrush » Mon, May 04, 2020, 3:09 PM UTC

ordinaryperson wrote: post #12

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…

You're absolutely right. Snaps do solve legitimate problems that we've struggled for years with and are the right thing to do architecturally. Corner cases that might affect certain users like holding versions or disabling updates entirely "when the user really knows what they're doing" should just be fixed as they arise. But again, snaps or any equivalent system that allows stupid-simple packaging, bundling dependencies, doing fail-proof transactional updates and running in per-app confinement has been proven valuable by the mobile world and not only (automotive and embedded come to mind). It's high time the typical desktop/server Linux operating system got such a system by default. What we need is to iterate over it to cover its gaps. For example the one sticking point I see in this thread when people really get pressed to argument their unhappiness with snap seems to come down to being unable to stop the auto-updating behavior. I could easily see Canonical implementing a feature to control that and putting it behind an explanation of the downsides and a "Disable this only if you know what you're doing!" warning. And so on for the rest of the corner cases.

And from developer's point of view, I can attest that if I'm to package and publish something for Linux, I'd certainly use snap or Flatpak or both before using deb or rpm so long as they're not affecting me in some major negative way. I assure the reader this is not the minority opinion and the software catalog is only going to grow because of it. This is our way out of PPAs and dependency problems (among other things) for publishing up to date out-of-distro software. I have no problem with a particular set of users not wanting the latest version if they know what they're doing but that doesn't negate the benefits this kind of a system brings.

We've seen this play out with other new and needed Linux systems before and that's OK.