If you follow the Linux news, you’ve probably already heard about the instant pack debate. Developed by Canonical as a faster and easier way to install the latest versions of software on Ubuntu systems, the software has ended up starting a fierce debate in the large 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, a dangerous step has been seen toward the types of proprietary “walled gardens” that may have led to Linux in the first place.
Perhaps the most vocal snap opponent, and certainly the one with the most media attention, is Linux Mint. In a June 1 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 would not include it in the basic installs. Additionally, it announced that Mint 20 would actively block users from installing the fast 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 explicit consent of the user.
The short version of Clement’s complaint is that the Quick Pack is installed from a Canonical-specific proprietary source. If you want to distribute snapshots, you must set up an account with Canonical and host it there. While the underlying software is still open source, the Instant Packager breaks with the long-standing tradition that software distribution is also open and free. This certainly makes installation simple for naive users and easier to maintain for canonical maintainers, but it also eliminates freedom of choice and diversity of package sources.
A package to rule them all
To understand the situation, we should probably step back and see what snaps really are. Simply put, they are containerized software packages that include libraries that the program in question requires to run. The idea is that developers can launch a single plugin that works essentially on any modern Linux system, rather than having to create specific distribution packages. In theory, this saves developer time and effort, and ensures that even users of more niche distributions can access the software they want.
Naturally, there are downsides to distributing software like this. On the one hand, an instant package will always be larger than a traditional package for the same program, since all dependencies must be shipped with it. Since many programs will naturally have the same dependencies, this means that a system with many snaps installed will unnecessarily waste storage space on redundant data. Although when even entry-level systems now include terabyte hard drives, this may not be as concerning 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 must be mounted before they can run. Some users find this item to be especially annoying from a system maintenance point of view, as each instant package you install will show up as a mounted file system.
In fact, there has been talk of adding a special flag to mounted plugin packages so that common tools like mount or lsblk It won’t show them, but obviously that leads to its own problems. After all, it is valuable to be able to determine how much disk space they take up.
For example, let’s take a look at how the plugin package for a common tool compares to direct installation:
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 instant package of the same program weighs an incredible 91 MB. It is clear how this problem would get worse as more snaps are installed.
That said, there is certainly a demand for this type of “universal” Linux package. Enough so that there are at least two other competitive approaches operating under similar principles, Flatpak and AppImage.
The chrome debacle
From the point of view of system resources, containerized packages are clearly not ideal. On the other hand, many would be more than happy to take the performance hit if it meant that they had access to the latest versions of popular programs without having to wait for them to reach 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.
What makes Canonical handling of the Chromium package in Ubuntu 20.04 so problematic. Let’s take a close look at what happens when you try to install it via apt:
While we ask the system to install the native package, what we actually receive is the plugin. The user has no other choice, there is no warning. If they weren’t paying enough attention, they wouldn’t even realize what happened. At the risk of sounding too dramatic, this is subversion.
To be sure, there are valid reasons why Canonical would like to distribute Chromium in an instant. Instead of creating versions for each supported Ubuntu version, they can remove a single plugin that will work on all of them. This is especially true for older versions of Ubuntu LTS (Long Term Support), which might otherwise be stuck in an older version of the browser due to outdated system libraries.
By using this “stealthy” installation method for the Chromium plugin, they can ensure that the process is as streamlined and painless as possible for their users. In fact, most would probably not even notice the change that happened.
But for those who noticed it, it is a big problem. Many users abandoned proprietary operating systems specifically to get away from this type of behavior. These people want to be the arbiter of their own computer, and they don’t politely make the important decisions that are made on your behalf without even a warning that they are happening. These are the users Clement Lefebvre had in mind when he promised that future versions of Mint would never install instant packages without prior consent.
Go to the future
While Canonical is no stranger to backing down on unpopular decisions, instant packages are almost certainly here to stay. The logistical benefits of containerized packages are simply too great when your entire business is structured around providing support for multiple versions of a Linux distribution. Conversely, users who have strong feelings about snapshots will inevitably be a small (albeit vocal) minority. Snapshots designed by Canonical to be the solution to the unique challenges of maintaining a huge and multifaceted distribution like Ubuntu, and it’s working exactly as expected.
That said, it seems unlikely that the larger Linux community will adopt instant packages. Currently the repository backend is actually proprietary. While Canonical allows companies to create “branded” versions of the Snap Store, it is only a cosmetic change and does not allow you to run your own server. So even if another distribution, like Mint, decided to adopt the instant package format, they would have to rely on Canonical to provide the infrastructure to distribute the packages to their users. This single point of failure is sure to be a point of contention for adoption outside of Ubuntu.
