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

Exactly. I recently had to replace Chromium with Google Chrome just because the Ubuntu maintainers thought it'd be a good idea to replace the Chromium apt package with an installer that pulls in the snap…

Good thing Firefox is my main browser and I only use Chromium/Chrome for testing (and whenever websites forget that there's more than just one browser to test for), otherwise I would have long ditched Ubuntu, too.

That they clobbered the apt install just to push Snap forward left a bad taste in my mouth.

Don’t do this to yourself! Debian is not going to give you bleeding edge. But there are plenty of distros that can. Despite being a meme, Arch Linux is one of the best distros available, and has been for years. Node, golang, are usually updated within hours of upstream, while the core system remains stable. If you’re looking for something more modern, Solus has been gaining popularity and also has relatively up to date packages. Debian is great for servers.

Now keep in mind we can't blame squashfs here. It was developed for use on <16 MiB large NOR flash chips for embedded devices likely connected over SPI - the underlying flash and interface is so unbelievably slow that no amount of compression or terrible kernel code would ever start showing up in some kind of benchmark. Using it on super fast desktop machines with storage that rivals RAM bandwidth and latency is just the opposite of what it was developed for.

And as someone living with OCD (the real thing) the whole Snap thing just makes me so anxious. And like you experienced, it is soooo slow. I cannot even go back to windows because for some reason the wifi on my laptop does not work well with it.

I do not care about bleeding edge anymore, but I am a casual user mostly doing genetic research, so Debian Buster with Cinnamon is, to me, the best distro on Linux today.

What are the biggest drawbacks? I know you said you don't miss Ubuntu at all, but is there anything which is causing you pain because it works differently or is just missing?

In practice though, they don’t matter for a vast majority of users, and package managers are far less hassle. Maybe it’s time for the principles to change?

Canonical has 443 employees according to the wikipedia page. Is that large in this context? I don't really think so. Redhat (13k employees) is large. Canonical isn't large.

Not sure if you were commenting on the whole approach or just snap, but FTR, flatpak uses shared base layers which can be updated individually, so there's still an upside to dynamic linking.

But perhaps base container images on scratch, not on ubuntu:latest ;)

Disclaimer: I never used snap and don't use Ubuntu.

I do think that's why the distinction between "free software" (copyleft) and merely "open-source" matters.

If you look historically, "open-source" became a thing as a reaction to free software where it preserves the most visible benefits, (source code in the open, modifyable by others), but treats these as purely a convenient workflow when working on code, whereas free software is more of a philosophy and so less likely to erode on principles.

There are two models.

The first model is the traditional distribution model. The distribution curates and integrates software, picking (generally) one version of everything and releasing it all together. Users do not get featureful software updates except when they upgrade to a new distribution release - all at once.

The downside of this model is that developers who want to ship their new software or feature updates without waiting for a new distribution release get stuck into dependency hell and have to operate outside the normal packaging system. Same for users who want to consume this. Third party apt repositories and similar efforts are all fundamentally hacks and generally all end up breaking users' systems sooner or later. Often this is discovered only on a subsequent distribution upgrade and users are unable to attribute distribution upgrade failures to the hacked third party software installation they did months or years ago.

The second model is the bundled model. Ship all the dependencies bundled in the software itself. That's what Snaps (and Flatpaks, and AppImage) do - same as iOS and Android. This allows one build to work on all distributions and distribution releases. They can be installed and removed without leaving cruft or a broken system behind. They allow security sandboxing.

All your objections seem to be criticizing the bundled model itself, rather than anything about Snaps themselves except that they use the bundled model.

If you don't like the bundled model, then you can carry on using Ubuntu 20.04 without Snaps just fine.

Some dev flat out[0] refuse (and I am not debating if it's right or wrong) to package their app for every distro (even major ones: ubuntu, debian, arch, rhel/fedora) so it's up to distro maintainers to package them so users are always at the end of a line of other people packaging the apps (either through distro packages or sandboxed one click installer).

[0] Words are too strong and user CJefferson https://news.ycombinator.com/item?id=24384206 is right to call me out on that. I agree, sorry about that. Poor choice of words. I had a very specific example in mind but there's obviously a whole gamut of reasons for not packaging. My position is that we can't nor should we expect dev to package their apps for the distro we use. Also it's no like app devs and distro/os devs/maintainers are living in hermetic boxes and their code/apps never interacting or evolving. Not editing out for context.

Of course, half the point of containers is to “vendor” your dependencies — a container-image is the output of a release-management process. So the symbolic reference part of dynamic linking is an undesired goal here: the container is supposed to reference a specific version of its libraries.

But that reference can be just a reference. There’s nothing stopping container-images from being just the app, plus a deterministic formula for hard-linking together the rest of the environment that the app is going to run in, from a content-addressable store/cache that lives on the host.

With a design like this, you’d still only have one libimagemagick.so.6.0.1 on your system (or whatever), just hard-linked under a bunch of different chroots; and so all the containers that wanted to load that library at runtime, would be sharing their mmap(2) regions from the single on-disk copy of the file.

Simple example. App A wants tensorflow 1.10, CUDA 8, and python 3.7. App B wants tensorflow 2.2, CUDA 10, and python 3.8. You want App A and B installed at the same time but the two versions of tensorflow are neither forward nor backward compatible. The two pythons will fight with each other for who gets to be "python3". How do you deal with this without containerization?

I don't think it violates the principles of open source at all, it's just making sure each application gets the exact versions of libraries it wants without messing up the rest of your system.

I actually think that’s exactly what we should do. Containers are an over-engineered solution for a problem that never needed to exist.

Dynamic linking doesn’t work unless you can live inside a distro maintainer’s special bubble for all your software. If you can exist in that bubble, great—I really like Debian for certain use-cases—but if you can't, the benefits of dynamic linking everything are clearly outweighed by the drawbacks.

I'm curious - are there any Linux distributions that contain nothing but fully static, self-contained binary executables ? As in, ships with no libraries ?

There's a certain subset of developers who are against dynamic linking at all, and they do have some convincing arguments that are worth reading.

I don't necessarily agree with them, but their arguments are worth acknowledging.

It's about getting dependencies with the app. I can't tell you the number of times I borked my OS install because I wanted a version of a single application that had a feature newer than a year or two old version supported in my distro's repository.

It helps to have both as options.

I've been slowly moving off GitHub to SourceHut, and it's been a breath of fresh air knowing that not only is all the software free (so you can self host) but the maintainer (Drew DeVault) is also quite committed to keeping it that way. I feel like I'm in safe hands.

Thankfully it's not yet another GitHub clone, but built around git+email -- so it's far more decentralized by nature.

https://sourcehut.org/

I think Mint's installation is too dumbed down tbqh. But, that said, I use Mint on all of the computers that I don't want to spend time to personalize.

The Enterprise Linux ecosystem is a solid alternative to Ubuntu. Fedora for desktop and either CentOS or Fedora for servers, depending on how stable they need to be and how much maintenance you're willing to do.

> But as a desktop user, I appreciate that I have the choice.

Just so we're clear, it's not that the apps auto-update, it's that there's no way to stop them auto-updating.

When I need to install some random app from the internet (last one I had to install was an advanced PDF viewer/editor) I manually unpacked the deb and found the binaries and run them as regular user.

For one multiple problems with linux containers due to lxd now being a snap package, which auto updates, restarts and sometimes doesn't like switching networks.

Apps that needed mounts that weren't there.

I mainly use nix packages now for ease of installation, removal, updates and for nix shell.

Need to run a shell with ffmpeg? `nix-shell --run bash -p ffmpeg` And ffmpeg is gone after the shell terminates.

I'm sorry but can you explain? How exactly is Snap helping Firefox? (I'm a Firefox user and I have never used Snap)

The real problem for me though is that snaps are slow as hell. I mean like taking 4-5+ seconds to open on a box with an SSD, i7, and 64GB of RAM. That's unacceptable.

The icing on the cake for me is that even through the command line as you mention apt now seems to be giving me snaps instead of debs for a great deal of programs, which affects much more than the store experience. And, also, regarding said store experience: if stuff like Spotify takes 5+ seconds to open I doubt a user coming from Windows giving Linux a try is going to want to stick around long...it would be great if there was just a better solution.

I install everything via CLI and pretty explicitly always avoid the GUI they have for installing software. It's never been good, ever.

I'm on 20.04 and I think it's a fantastic release, head and shoulders better than 18.04.

The only thing in the author's list that I really take issue with is installing a snap when a user attempted to install from a .deb file. That sort of shit is antithetical to linux, and if it continues to get worse would actually be a reason for me to leave Ubuntu.

But everything else is just a non-issue to me.

https://news.ycombinator.com/item?id=23772524

I am 100% agree with you.

Also, people complain on other OS that they can't remove or replace an existing software... Here, they can. But they prefer to move to another distro just because of this. I don't understand this world anymore... :(

1. Ubuntu is replacing "standard" apt packages with packages apt packages that just install the snap version.

2. Many snap packages have bugs that are caused by the snap setup itself.

Thus, it is impossible for these users to "just ignore snaps and use ubuntu like a regular debian system".

I'm sure there are obviously some; anything proprietary or with patent encumbrance requires using rpmfusion or something, and that may be a step further than enabling multiverse. Some stuff just might not be packaged. Ubuntu and Debian repositories are also exceptionally broad.

But I can't, right off the top of my head, think of that much of OSS that I couldn't install either from the official repos or rpmfusion.

Maybe I've just forgotten about any loops I had to jump through, but I've been using Fedora for about six years now (after moving from Ubuntu), and I've found that the repos are much richer than I thought they were. But maybe I just haven't run into the holes that you have found.

There are some things I preferred about Ubuntu, but generally things have been working surprisingly well for me.

You can't choose to install the .deb version instead, unless you add an unofficial repo.

That is absolutely forcing snap on people, since Chromium was a standard .dep package in the previous releases. And it's not the only package where the transition to snap is forced.

Now, I don’t use Ubuntu Desktop, but even in server space, lxd (again, first party) has been pushed to snap, with the deb package being a mere shim.

I happen to agree with you completely, and I say that as a 25 year veteran in the Linux world.

The open source world goes through things like this periodically. But then the change passes and we all get used to it and the next controversy comes along.

This just isn't true. Its clear that Ubuntu is moving away from debs and to snaps. LXD is software primarily developed by Canonical and is only distributed as a Snap. Look at Ubuntu Core, the IoT distro by Canonical that doesn't use debian packages at all, it just uses snaps.

I don't think it's accurate to say that it's the desire to install rolling-released third party software in itself that's the problem. It's the mismatch between the distribution's and the third party software's release cycles that make this a problem, and using a distribution that more closely resembles the software's release cycle does solve this problem without needing Snap.

silverblue effectively gives you the ability to have the benefits of a rolling distro and the benefits of a distro that does releases (stability focused).

I haven't had the time to try it out yet ... maybe a good weekend project. I've been using Ubuntu for over a decade now so it might take some time to switch over.

Debian.

Or jump ship for a BSD if your hardware is well supported or this is for servers.

They both opt for flatpak instead of snap. Pop prefers apt over flatpak in the graphical app store, I don't use Mint so I don't know how it's done there.

Debian is even more stable and retains apt as a package manager, but you will have older packages for stability and have to customize it a little.

If you can venture out of the Ubuntu space, I have found Manjaro to be an excellent experience in the few months I used it earlier this year. It has very fresh packages since it is Arch-based, but also uses an LTS kernel and has some measures in place on its own repositories for stability's sake. I can't attest to the effectiveness of the latter since I've never had stability issues on Arch, but Manjaro is certainly wonderful out of the box and a very pleasant experience in my opinion.

Notable diferences that might influence your decision are:

- RPMs instead of DEBs;

- Flatpaks instead of Snaps;

- Podman and Buildah instead of Docker (although you can get Docker if you really need to use that);

- SELinux enabled by default (some people don't like this for non-server usage, but I dig it);

- firewalld comes enabled by default, which may be annoying and unexpected if you're trying to get some iptables rule to work (I personally always remove firewalld and install ufw for the things I need);

- Fedora 33 (due for release next month) will be switching to btrfs as the default filesystem, whose features are definitely welcome for home usage (but I'll wait a bit before upgrading and see if people run into any issues);

- I'd also highly recommend installing Pop!_OS's Pop Shell [0] to add great tiling support for GNOME, but that goes for anyone using GNOME really

[0] https://github.com/pop-os/shell

If you like gaming though, I never tried setting up Steam or a ProtonDB game on Fedora to be able to report on that (I think it would be complicated enough to make me wanna switch distros), but if you'll be doing this a lot, Pop!_OS (Ubuntu based, snaps disabled) has a great out-of-box experience with Steam, as does Manjaro (Arch based) which has an excellent hardware detection and driver auto-installer tool called mhwd, and makes setting up NVIDIA cards and other finicky hardware a breeze.

If I had a visual way of installing snaps with the Ubuntu app store, I would use it no prob but adding 3rd party repos isn't a viable option for me when I could make do with the default vetted repos. I had to change my CI/CD config where I ran accessibility tests with Chrome's web driver into another distro because Ubuntu broke their previously functioning functions. Building from source would be possible but it's slow and costly to run for every commit.

It is clearly a NO GO Canonical, you can't ship slower apps (that start in 3-5 seconds), that out of snap (or in Windows), start in less than a seconds.

snapped Chromium takes 3-5 seconds in its first start in a 16GB ram, corei 5, ssd based machine. WHAT?

In the same hardware the .deb Chromium takes maybe half a second to load and be fully responsive.

The occurs with LOTS of software, and yeah, the start time of an app IS a thing.

If something takes more than half a second to start, and you know it is A LOT faster, you end up pissed off,

What have they done with MY hardware and why?

If Canonical start to annoy me with many more packages forced to snap like chromium, I'll be jumping to whatever distro lets me start MY apps in less than a second, as it is usual in 2020.

And if this unfinished, unpollished crap starts to show off in Ubuntu server in its current sorry state, I cannot express how fast I will be ditching LTS for Debian or anything "not snapped".

You NEED to make this thing to start A LOT FASTER,

and stop making "end user assumptions" about what you could mess up behind scenes in the system (yeah, you could end stomping actually useful things like sleeping in notebooks).

There are multiple gui frontends for apt. Are we disingenuously pretending this isn't so?

> Compile from scratch

On a lot of laptops this would be 24 hours of straight building which would have to be redone when underlying libraries changed. This would further be non obvious until after an update your browser didn't open. Furthermore the setup for building it would be apt pun intended to be at least slightly complicated and errors caused by lack of say the needed dev packages would be non obvious and confusing to regular users. Pretending this is a reasonable alternative is of dubious value.

The browser is the single most important application on most users computer. Syncing it by itself and the users profile, settings, bookmarks, and passwords restores much of what the user expects from their computer. Providing no obvious way to install it without learning about ppas and wading through tons of out of date ppas to figure out the correct one that works with your system is non obvious, non discoverable and frustrating. Virtually all new users will end up with the snap version and thinking linux is just slow.

>guess how Chrome is packaged and installed there

Methodologies for packaging have different attributes and downsides Snap != Mac OS

The article has been updated to accommodate changes since the original four months ago.

Third party software developers wanting to push their latest software releases directly to users, and for users wanting to install such software.

For users who are happy to use the traditional distribution-curated model, getting all "feature" software updates when doing a distribution release upgrade only, snaps are not necessary and you can use Ubuntu 20.04 perfectly fine, as normal, without using snaps.

Sandboxing desktop applications on Linux won't happen until distros start shipping strict SELinux policies that properly confine programs like Android does. Along with flatpak/systemd taking allowlisting seriously combined with stricter seccomp filters.

Please if you maintain any packages with systemd units go read this right now and harden them, it should only take a few minutes: https://www.freedesktop.org/software/systemd/man/systemd.exe... Verify them using 'systemd-analyze security $unit'.

They could have just stepped aside and used one of the alternatives—priceless.

Not to mention it doesn't cost billions to develop a read-only chroot archive, the building blocks are available to combine. Just have to have the humility to choose the most elegant design, which already exist.

A proof if you needed one that the "SJW" or "baizuo" culture isn't at all progressive, but a dangerous intolerant bunch more akin to the Khmer Rouge than anything else.

https://www.zdnet.com/article/richard-m-stallman-resigns-fro...

He said it was likely that some women of Epstein's presented as entirely willing to Marvin Minsky. This was twisted by the press into him saying they were entirely willing.

For this he was ousted.

Systemd did things differently, sometimes annoyingly, but the intention was still to allow you to control your own system. It also ate other projects (e.g. udev) and sprouted features (resolved, timedated, etc.) making it difficult to untangle, but it was/is still possible to do so.

The biggest complaints I see about snap as currently implemented are related to making arbitrary outbound network connections, automatic updates that you can't disable, and inability to mirror or vendor snaps or an entire archive / repo.

These don't seem similar to me at all. Systemd is opinionated, perhaps in a non-unix-philosophy way, but still preserves users' freedom. Snapd does not.

If you have a system with snapd, your system is doing things that you can't disable without replacing the system wholesale. The Microsoft-levels of telemetry and lack of control seem to me clearly worse in every way than anything that was ever wrong with systemd.

I don't actually believe that snapd is irredeemable, and think that these things will eventually be fixed, either as they progress on their roadmap, or as a response to user outrage. But I don't really understand how it got shipped in such a state. In particular, the non-disableable silent updates seem to me like a complete non-starter for a server operating system. How are you supposed to schedule maintenance? What were they thinking?

I like auto-updates. I almost always turn them on. But being able to turn them off is an important bargaining chip, to pressure devs to behave. I'm not excited about giving that up.