A technical comparison between snaps and debs

by Igor Ljubuncic on 29 August 2019

How are snaps different from debs? This is a common question that comes up in technical discussions in the Linux community, especially among developers and users who have just embarked on their snap journey and are interested in learning more details. Indeed, the introduction of self-contained application format likes snaps has created a paradigm shift in how Linux applications are built, distributed and consumed. In this article, we’d like to give you an overview of some of the main differences between the two file formats, and how they can best suit your needs.

Debian format at a glance

Debian packages (deb in short) are packages used on the Debian distribution and its derivatives (including Ubuntu), containing the executable files, libraries, and other assets associated with a particular program. Each package is an ar archive and typically carries a deb file extension (.deb). Inside the ar archive, the package contains three components:

• control-binary – a file that declares the Debian format number.
• control.tar – a tar-based archive that contains the package control information and meta data, including pre- and post-install scripts, configuration files, list of shared library dependencies, and so on.
• data.tar – a tar-based archive that contains the program binaries and libraries, which will be installed in the Linux system.

The management of Debian packages is done on multiple levels. The low-level management is done through dpkg utility. Most Linux distributions ship with a separate, higher-level utility that offers a more user-friendly syntax. Often, Debian-based systems use apt, but other implementations are possible.

Some distributions also offer a graphical frontend, in the form of a software center. In many cases, the use of the software center is closely tied to the distribution and the use of the desktop environment, creating a tightly coupled stack that cannot easily be broken into separate pieces. For instance, Ubuntu uses Ubuntu Software Center on top of the GNOME desktop environment, whereas Kubuntu uses KDE Discover on top of Plasma desktop, although both use apt under the hood (there are additional mechanisms involved, like PackageKit, but the finer details are beyond the scope of this article).

Snap format at a glance

Snaps are self-contained application packages designed to run on any system that supports them. Practically, this translates into 41 systemd-enabled distributions at the moment. Each snap is a compressed SquashFS package (bearing a .snap extension), containing all the assets required by an application to run independently, including binaries, libraries, icons, etc. The actual data structure of each snap will vary, depending on how it was built, but it will usually resemble the standard Linux filesystem structure. We will discuss the full details of the snap architecture in a separate article.

unsquashfs testsnap_1.0_amd64.snap
Parallel unsquashfs: Using 8 processors
4 inodes (138 blocks) to write
[=============================|] 138/138 100%
created 4 files
created 6 directories
created 0 symlinks
created 0 devices
created 0 fifos

cd squashfs-root/

ls-ltra
total 24
drwxr-xr-x 5 igor igor 4096 Dec 17  2018 ./
drwxrwxr-x 3 igor igor 4096 Aug 27 13:40 ../
drwxr-xr-x 2 igor igor 4096 Dec 17  2018 bin/
-rwxr-xr-x 1 igor igor   38 Dec 17  2018 command-testsnap.wrapper*
drwxr-xr-x 3 igor igor 4096 Dec 17  2018 meta/
drwxr-xr-x 3 igor igor 4096 Dec 17  2018 snap/

Snaps are managed by snap, the command-line userspace utility of the snapd service. With snap, users can query the Snap Store, install and refresh (update) snaps, remove snaps, and perform many other tasks, like manage application snapshots, set command aliases, enable or disable services, etc.

Practical differences – installation & use

The best way to examine the two formats is to go through a typical setup of an application in a Linux system, from a search done by the user to the installation and actual usage of the software.

Debian package installation and use

In a Debian-based system, a user will search for an application using the high-level command-line package manager (like apt) or using a frontend package manager like Synaptic, KDE Discover, Ubuntu Software Center, or others. Usually, the search results will show any entry that contains the search string, and this can include the desired asset but also shared libraries and development packages that the user may not necessarily require or interact with directly. For instance, searching for vlc (the media player) will return something like:

apt-cache search vlc
browser-plugin-vlc - multimedia plugin for web browsers based on VLC
cubemap - scalable video reflector, designed to be used with VLC
dvblast - Simple and powerful dvb-streaming application
fp-units-multimedia - Free Pascal - multimedia units dependency package
fp-units-multimedia-3.0.4 - Free Pascal - multimedia units
freeplayer - wrapper around vlc for French ADSL FreeBox
freetuxtv - Internet television and radio player
…
python3-pafy - Download videos and retrieve metadata from YouTube
smtube - YouTube videos browser
vlc - multimedia player and streamer
vlc-bin - binaries from VLC
vlc-data - common data for VLC
vlc-l10n - translations for VLC

In a GUI package manager, the results will be different – usually a shorter list, with fewer entries returned, often more accurately representing what the user expects. This can be a problem, as users with different levels of skills – and methods – may not necessarily achieve the same end goal, based on the same starting parameters, i.e. a search for an application.

The installation will include the main requested program but also any dependencies that the software needs. A user may only want to install vlc, but they will also see (on the command line) that additional assets are going to be set up, usually a number of shared library dependencies, each provided as a separate Debian package. For instance:

sudo apt-get install kmahjongg
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
kdegames-mahjongg-data-kf5 libkf5kmahjongglib-data libkf5kmahjongglib5
The following NEW packages will be installed:
kdegames-mahjongg-data-kf5 kmahjongg libkf5kmahjongglib-data libkf5kmahjongglib5
0 upgraded, 4 newly installed, 0 to remove and 31 not upgraded.

In the example above, the user’s request to install the Kmahjongg game will install four deb packages. In some cases, there could be dozens of library dependencies, and some of these will be common across many applications (like audio and video codecs).

Debian packages support GPG signature verification, but this is typically not used – instead, the integrity and verification of archives is done on a repository level. In other words, if you trust a repository, you inherently trust all its contents. From a security perspective, this could potentially be a problem, as users can manually add repositories to their system (like PPA), or manually install Deb packages obtained from non-repository sources.

If the installation is interrupted, the system will often be left in an inconsistent state that will require repairing (tools like apt have mechanisms to rebuild their indices) before any additional package management can be completed.

The installation of software also reveals two additional constraints:

• There can only be one version of a particular software package installed.
• Since shared libraries can be installed (or removed) as part of any Debian package installation, it is possible that a separate package setup will introduce a library change that could cause cause a regression or breakage in an unrelated application.

Snap installation and use

With snaps, things are similar – and yet different. A command-line search using snap and the results displayed in the Snap Store will also include all applications matching the relevant string. However, the results will be identical. Moreover, each result will be a separate snap that contains all the necessary assets to run independently.

snap find vlc
Name            Version                 Publisher  Notes  Summary
vlc             3.0.7                   videolan✓  -      The ultimate media player
dav1d           0.2.0-1-ge29cb9a        videolan✓  -      AV1 decoder from VideoLAN
peerflix        v0.39.0+git1.df28e20    pmagill    -      Streaming torrent client for Node.js
mjpg-streamer   2.0                     ogra       -      UVC webcam streaming tool
audio-recorder  3.0.5+rev1432+pkg-7b07  brlin      -      A free audio-recorder for Linux (EXTREMELY BUGGY)

Snap installations are also different from debs. Since snaps are fully self-contained applications, during the installation, the snap package (SquashFS filesystem archive) is decompressed and mounted as a read-only loopback device, with a separate writable private area created in the user’s home directory. Because snaps contains all the elements required to run an application, their disk footprint is typically larger than an equivalent Deb package. This is partially mitigated by having snaps compressed, and in some cases they might actually have a smaller size on the disk.

During the installation, a security profile will be created for the snap, which will determine what the snap can or cannot do once run. By default, snaps cannot access other snaps, or ever the underlying system. Specific overrides are required, which we will touch upon shortly. Furthermore, the isolated manner in which snaps are configured means that once the user removes a snap, all the assets are completely removed from the system. 

Snaps are cryptographically signed. Users can install snaps that originate outside the Snap Store by providing an explicit, manual override flag. This is common during development, allowing developers to test their snaps before uploading them to the store.

Channels & parallel installs

Snaps come with several additional features. The Snap Store supports channels, allowing developers to publish multiple versions of their software in different channels. This gives users the flexibility to switch between channels, e.g. edge, beta or stable, to test and try features available in different versions of the snap.

Moreover, they can also install multiple versions of the same snap in parallel. Since each snap lives in isolation, this gives users the freedom to experiment with their software without the fear or breakage or data loss.

Application updates

Most Linux distributions have a semi-automatic update mechanisms. Users can configure their systems to check for updates periodically, in order to keep their systems patched, but they also have the option to complete disable this feature (which can sometimes lead to a gap in the security coverage). This procedure comes with the same shortcomings as the individual package setup, in that an interruption may harm the system’s consistency, and updates could introduce regressions, usually in shared libraries, that break applications.

Snap updates are automatic, transactional and atomic, meaning if an update fails, the existing version of the snap will continue running (the functionality will not be impaired), the buggy update will be deferred, and the application will only be updated once the developer releases a new, improved update that is verified to work well. Of course, there are no silver bullets. There could be functional regressions in the software itself, which will not cause an update to fail.

Runtime security

Earlier, we briefly touched on the security isolation mechanisms. With deb packages, security is enforced on the system level, and may differ from one distribution to another. In some cases, Web-facing applications may be partially restricted, primarily to protect them from exploits. However, in most cases, software installed as Debian packages will have unrestricted access to system resources. Generally, an application will be able to write to disk, use the audio or video devices, or connect to the network.

On the other hand, snaps are designed to be isolated from the system, and this is done through a granular mechanism of security policies that prevent snaps from accessing the underlying system in an unchecked manner. Multiple confinement levels are possible, and in the strict level, snaps have no access to any resource, including home directory, network or display. It is possible to allow per-resource access using interfaces.

During the snap creation, developers can declare the use of one or more interfaces, which can then provide the necessary functionality to their applications – like audio, USB or perhaps hardware acceleration. We’ve touched on this concept in the Introduction to snapcraft tutorial series, and you may want to read it to get a deeper understanding of how you can use this during software development.

The isolation can have a negative side – in that application startup can be slower than a contemporary Debian package. The setup of the snaps requires several steps that do not occur in the traditional configuration with debs. This is something we take very seriously, and have made significant progress in making snaps faster to launch.

Summary of differences

The table below contains the major points covered in the article:

Conclusion

Most people don’t really care about the underlying mechanics of software management, but sometimes, it can be useful to understand the differences. Traditional Linux software packaging and distribution is designed for a very small, compact target footprint, which has been of great value in the times of expensive disk storage, or when deploying to devices with limited resources. However, along the way, this method can sometimes manifest in breakages during installation and updates.

That does not mean you should abandon your distro software right away! Debian packages are a perfectly valid way of consuming software, and in most cases, they will be a reliable, trusted method. Snaps complement and enhance the traditional ways with a more robust and granular approach, allowing for better control and separation, with reliability and uninterrupted service as primary drivers. This is of particular value in IoT deployments, but desktop users can and will also enjoy the benefits of confinement and isolation.

In this article, we did not touch on the development side at all. The use of different packaging formats and their associated toolchains also has a significant impact on how software is created and distributed. For the most part, this is hidden from the end user, but it is critical to software developers. In future articles, we will address this aspect of snaps vs. debs, too, and also examine how snaps are different from other self-contained application formats available on the market, like Flatpak and AppImage. For the time being, if you have any comments or questions, please join our forum for a discussion.

Photo by Anthony Brolin on Unsplash.