Who would have thought that software packaging software would cause such a hubbub? But such is the case with snap. Developed by Canonical as a faster and easier way to get the latest versions of software installed on Ubuntu systems, the software has ended up starting a fiery debate in the larger Linux community. For the more casual user, snap is just a way to get the software they want as quickly as possible. But for users concerned with the ideology of free and open source software, it’s seen a dangerous step towards the types of proprietary “walled gardens” that may have drove them to Linux in the first place.
Perhaps the most vocal opponent of snap, and certainly the one that’s got the most media attention, is Linux Mint. In a June 1st post on the distribution’s official blog, Mint founder Clement Lefebvre made it very clear that the Ubuntu spin-off does not approve of the new package format and wouldn’t include it on base installs. Further, he announced that Mint 20 would actively block users from installing the snap framework through the package manager. It can still be installed manually, but this move is seen as a way to prevent it from being added to the system without the user’s explicit consent.
The short version of Clement’s complaint is that the snap packager installs from a proprietary Canonical-specific source. If you want to distribute snaps, you have to set up an account with Canonical and host it there. While the underlying software is still open source, the snap packager breaks with long tradition of having the distribution of the software also being open and free. This undoubtedly makes the install simple for naive users, and easier to maintain for Canonical maintainers, but it also takes away freedom of choice and diversity of package sources.
One Package to Rule them All
To understand the situation, we should probably take a step back and look at what snaps actually are. Put simply, they are a containerized software packages that include libraries the given program requires to run. The idea is that developers could release a single snap that would work on essentially any modern Linux system, rather than having to create distribution specific packages. In theory this saves time and effort on the developer’s part, and makes sure that even users of more niche distributions can get access to the software they want.
Naturally, there are downsides to distributing software like this. For one, a snap package will always be larger than a traditional package for the same program, as all the dependencies need to be shipped with it. Since many programs will naturally have the same dependencies, this means a system with many snaps installed will be needlessly wasting storage space on redundant data. Although when even entry level systems are now including terabyte hard drives, this is perhaps not as much of a concern as it would have been in years past.
Snap packages also tend to be slower to run, in part because they are actually compressed filesystem images that need to be mounted before they can be executed. Some users find this element to be especially annoying from a system maintenance standpoint, as every snap package you install will actually show up as a mounted filesystem.
There’s actually been some talk about adding a special flag to mounted snap packages so that common tools like mount or lsblk won’t show them, but obviously that leads to its own problems. After all, there’s value in being able to determine just how much of your disk space they’re taking up.
For example, let’s take a look at how the snap package for a common tool compares to installing it directly:
As you can see, the difference is substantial. If we download youtube-dl directly from the developer’s website, the script only takes up 1.7 MB on disk. But the snap package of the same program weighs in at an incredible 91 MB. It’s clear how this problem would be compounded as more snaps are installed.
That being said, there’s undoubtedly demand for this sort of “universal” Linux package. Enough that there are at least two other competing approaches which operate under similar principles, Flatpak and AppImage.
The Chromium Debacle
From a system resource standpoint, containerized packages clearly aren’t ideal. On the other hand, many would be more than happy to take the performance hit if it meant they had access to the latest versions of popular programs without having to wait for them to arrive in their distribution’s native package repository. Users should be free to decide for themselves which route they want to take based on their personal needs.
Which is what makes Canonical’s handling of the Chromium package in Ubuntu 20.04 so troubling. Let’s take a close look at what happens when you attempt to install it through apt:
While we asked the system to install the native package, what we actually receive is the snap. The user is given no choice, no warning. If they weren’t paying close enough attention, they wouldn’t even realize what happened. At the risk of sounding overly dramatic, this is subversion.
To be sure, there are valid reasons that Canonical would want to distribute Chromium as a snap. Rather than building versions for each supported release of Ubuntu, they can push out a single snap that will work on all of them. This is especially true of older LTS (Long Term Support) Ubuntu releases, which might otherwise be stuck on an older version of the browser due to outdated system libraries.
By using this “stealth” installation method for the Chromium snap, they can ensure that the process is as streamlined and painless as possible for their users. Indeed, the majority would likely not even notice the change over happened.
But for those that did notice, it’s a huge deal. Many users left proprietary operating systems specifically to get away from this sort of behavior. These people want to be the arbiter of their own computer, and don’t take kindly to important decisions being made on their behalf without even so much as a warning they’re happening. These are the users that Clement Lefebvre had in mind when he promised future versions of Mint would never install snap packages without prior consent.
Snap to the Future
While Canonical is no stranger to walking back on unpopular decisions, snap packages are almost certainly here to stay. The logistical advantages of containerized packages are simply too great when your whole company is structured around providing support for multiple versions of a Linux distribution. Conversely, the users who have strong feelings on snaps will inevitably be a small (if vocal) minority. Canonical designed snaps to be the solution to the unique challenges of maintaining a huge and multi-faceted distribution like Ubuntu, and it’s working exactly as intended.
That said, it seems unlikely that snap packages will be embraced by the larger Linux community. Currently, the repository back-end is actually proprietary. While Canonical does allow for companies to create “branded” versions of the Snap Store, it’s just a cosmetic change and doesn’t allow you to run your own server. So even if another distribution such as Mint decided to embrace the snap package format, they would have to rely on Canonical to provide the infrastructure for distributing the packages to their users. This single point of failure is bound to be a point of contention for adoption outside of Ubuntu itself.
I demand 100% control over my system, and that includes the ability to completely disable any kind of updates or update notifications, this is absolutely non-negotiable and not up for discussion. This push toward Snap is exactly why I dumped Ubuntu after 12+ years and moved to Mint, won’t be looking back.
I appreciate, that I can run apps, which requires “wine” and it is natively integrated. Unfortunately, snap is making my 6-core cpu radiators crazy, turning them every few seconds and heavily using/loading resources. For now it is working piece of junk.
The best command , for now so far for snap is :
sudo apt purge snapd
As a learning developer, I don’t want to deal with the hassle of having to distribute my software to different package managers for distros, in different formats and adapt to different ecosystems.
Snaps solve this problem for me and make it much easier and seamless to release latest updates. It literally takes a few seconds to push a new version on snap store.
To everyone else, please understand why so many companies or developers choose to make snaps. It lowers the headache on our part and makes our products available to a wider audience.
Canonical sucks!
They want about 30k to get started with your own snap store. You have no option but to pay this if you want your own kernel modifications.
You cannot host your own snap store
They also charge per device justifying it with “we need your hardware so we can build your kernel”
Opensource, partly, but ubuntu is now heavily policed. I cannot roll my own drivers into a kernel and release to my machines without them doing it for me and paying potentially hundreds of thousands of dollars a year in the process. I just wanted to put a few machines out there..
Ubuntu core cannot be used without snaps. Its game over guys, its been fun.
“Power management doesn’t work properly – when my laptop is powered and I close the lid it’s supposed to keep running, but it suspends, and that doesn’t work for me.”
I got exactly that, roughly as long ago, after emerging Skype led directly to unintentionally admitting elogind into an old system. It immediately made a bad first impression by reminding me of that other thing from the same upstream clique that knows what you want better than you do: pulseaudio. I didn’t even realize what it was until I had to go find out what had taken over PM duties with its new ideas about reasonable defaults.
Using snap to install epsxe and virtual boy advance, none of them work. I miss deb package.
Whether it just happened that way or was by design, the way Ubuntu ditched the tried-and-true .deb packaging format for Snaps, complete with all their security, performance, and file size issues, is unforgivable in my book.
In a web-filtered distribution I recently created, F3OS, I 1) based it on Debian Stable, 2) disabled Snaps in it, 3) added non-free wireless network firmware, and 4) currently have it available with 2 desktops (Xfce and Openbox), with plans for others.