Live data from Hacker News

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

jatan.blog

581–590 of 645 posts

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

#581

Earlier quoted context omitted.

> things like Wireguard require a simple, but odd procedure to request apt pull packages from newer releases That's not a good idea, as it breaks the assurance that Debian Stable provides. Using the backports repository is the recommended approach if you need a newer version of some clearly-defined piece of software. It will pull the newer dependencies it requires from backports, while still relying on stock-provided…

It's not a good idea, but Debian's wiki is nevertheless recommending it: https://wiki.debian.org/WireGuard I tried it. Long story short, now I'm on Sid.

The Wiki instructions are outdated and WireGuard has since (March 2020) come to buster-backports.

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

#582
post #37

Earlier quoted context omitted.

> I wish all software would auto-update silently in the background -- when's the last time you even thought about upgrading Chrome? Updating everything has always been one click in Ubuntu (and I'm sure there's an option to have it go automatically). > 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 t…

This is getting OT, but could you elaborate on your issues with systemd? I’m genuinely curious. I often see people complain but haven’t seen or experienced specifics apart from it being complex and having higher learning curve than initd. (I don’t know if you’ve tried MX Linux BTW; Debian derivative without systemd by default) I will never defend pulseaudio though, that’s a horrible mess.

I like the init system (admittedly, I have not been using Linux long enough to remember a time before systemd), but components like networkd and resolved are a pain to work with in general. I've had the networkd DHCP client fail in situations that dhcpcd and dhclient handled with grace. It is not clear to me what benefit said systemd components provide over the more traditional solutions.

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

#583
post #52

> Auto-updating of snaps can only be deferred at best, until at some point, like Windows, it auto-updates anyway. Even on metered connections, snaps auto-update anyway after some time. This attitude is obnoxious. Yes, not everybody is on a metered connection or running a mission-critical system, but some are, and it is hardly unreasonable to accommodate them.

I don’t understand this overbearing obsession for computing companies to direct their users into certain corners. Why?

Ubuntu gets its money with Support. Maybe a corner is easier to support. That's my less cynical idea.

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

#584
post #453

Earlier quoted context omitted.

> Can I actually a publish without any checks and, once I got half a million users by repackaging the deb file in snap, add some subtle malware? There is no review process or anything? This is already possible with every other distribution method. If you host your own debs, then you can easily get them to do whatever you want. Even relying on the main archive isn't great - apt is typically delivered over HTTP to make…

> apt is typically delivered over HTTP This is a large misunderstanding of how it works. You can't MITM millions of servers around the world just because they use HTTP for downloading their apt archives. It verifies the cryptographic signatures. That's why you need to "apt-key add" when you add a custom repository. It doesn't rely on the transport method for integrity. > [Typo-squatting] is already possible with ever…

> This is a large misunderstanding of how it works. You can't MITM millions of servers around the world just because they use HTTP for downloading their apt archives.

Actually, a bug allowing exactly that was in the last 3 ubuntu LTS versions: https://justi.cz/security/2019/01/22/apt-rce.html https://usn.ubuntu.com/3863-1/

If they used HTTPS then an attacker would have to control the mirror instead of being able to perform the attack as a MITM.

Also using HTTP allows someone in the middle to know what software is installed on a server, which while not critical if it is kept up to date it leaks some information.

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

#585

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.

We must be nearly at the point in the plot when somebody declares that df "never did work properly anyway" and rewrites it.

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

#586
post #453

Earlier quoted context omitted.

> Can I actually a publish without any checks and, once I got half a million users by repackaging the deb file in snap, add some subtle malware? There is no review process or anything? This is already possible with every other distribution method. If you host your own debs, then you can easily get them to do whatever you want. Even relying on the main archive isn't great - apt is typically delivered over HTTP to make…

> apt is typically delivered over HTTP This is a large misunderstanding of how it works. You can't MITM millions of servers around the world just because they use HTTP for downloading their apt archives. It verifies the cryptographic signatures. That's why you need to "apt-key add" when you add a custom repository. It doesn't rely on the transport method for integrity. > [Typo-squatting] is already possible with ever…

> In apt, not anyone can just register any package name.

Yes they can. Yes distributions maintain archives and are able to decide what to include. But there's nothing special about apt per se that prevents namesquatting.

If you create a well-used PPA, for example, you could easily add extra packages, e.g. "firefix", later on. The next time someone runs `apt update`, they'll be exposed to the new package.

> My question was whether that's really a thing in snap.

It looks like that from the outside, but in practice that's not possible. All snap package names are tightly managed by Canonical staff.

> I'm not quite sure what you're trying to say here.

Lots of software vendors host their own archives. It's very difficult to get new packages into distros, and they're often updated infrequently once they're there. For example, the OSGeo project distributes its suite of packages this way.

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

#587
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…

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

At the risk of reigniting this particular flamewar, systemd changed that paradigm for the worse, using flimsy arguments that don't hold much water to anyone who knows better. Comparing snap to systemd doesn't exactly do the former a whole lot of favors.

> Browsers like FF and Chromium [on Windows] simply self-update

If I was okay with this being the norm then I'd still be using Windows.

> Ubuntu, since 16.04 LTS, ships with unattended-upgrades enabled

That's horrifying.

> and how reluctant users (like my dad and my wife!) are to click on "Install now" in the update-manager dialog.

Your dad and your wife are reluctant for good reason. Having experienced first-hand how prone Windows updates are to break things, and now seeing an admission here that y'all want to make Ubuntu more like Windows, this doesn't bode well in the slightest for a good user experience.

Like, one of the main points I make to people to convince them to at least try a Linux distro is "well unlike Windows it won't shove updates down your throat, and the updates are quick and easy and painless anyway". And then here comes Canonical wrecking the former assumption (and who knows how it's impacting the latter, but I don't exactly have high hopes).

Not that it matters much since I've given up on Ubuntu (in favor of openSUSE) in my recommendations to others (and switched to Slackware for my own use) ever since God-Emperor Mark chose to double-down on the Amazon Lens instead of listening to His users. Every once in awhile I take a look at Ubuntu again, hoping that maybe Canonical's figured things out, but always come away disappointed. It's always a bummer, given that my first distro was Ubuntu 7.10, and every once in awhile I'll fire that one up in a VM and remind myself what Ubuntu used to be, before it seemingly became a soulless husk of a distro.

But I digress.

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

#588

I was asked by a friend to get Netflix working on his Lubuntu 20.04 Linux laptop. He was running Chromium which comes without Widevine, and the extension wasn't available in the Chrome Web Store, but it can be enabled by simply making libwidevine.so available in Chromium's library path. But how to add a file to the sandboxed lib/ directory of a Snap? You can't without rebuilding the entire Snap as your own custom pro…

Did Firefox not ship with widevine?

Usually firefox does not ship with it, but it's a one-click install when needed. It depends on the package though, some packagers build it with it bundled some don't. Since it's not a FOSS component it can't be bundled in FOSS distros though.

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

#589
post #81

I know Snap maybe offered tighter sandboxing, but why didnt AppImage take off? It seems like it solves the problems of deb/rmp/etc war and is easy to create for app devs...

AppImage is not at all easy to create for app devs because there's no SDK, unlike FlatPak and Snap.

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

#590
post #400

Earlier quoted context omitted.

> We tried EVERY hack we could think up Just to be sure, installing the CA from that MITM box didn't work? Because that should be the generally recommended solution and I can't see why snap would have a hardcoded CA list separate from the system. If that didn't work, it's indeed a bug, but a rather weird one; definitely worth posting to the bug tracker.

The CAs are hard embedded in the core snap. They're pulled from some specific package when built, but snaps themselves are immutable. We attempted to overwrite it in several different ways, but the OS is just simply mounting these folders from the core snap (which is immutable), and then marking those mounted paths them as immutable. That being said, there are a list of paths you can write to, and they're listed here…

> The CAs are hard embedded in the core snap.

That is ridiculous. Thanks for the info, yet another reason to stay far away from snap...

Post reply on HN