What’s the Deal With Snap Packages?

If you follow Linux news, you’ve probably already heard about the debate over snap packages. 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.

Mounted snap packages on a default Ubuntu 20.04 install.

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.

from Blog – Hackaday https://ift.tt/2Yv64WU