Snap is a software deployment and package management system like AppImage or any other package manager for that instance. It is originally designed for the now-defunct Ubuntu Touch Operating system. Snappy lets developers create software packages for use in a variety of Linux based distributions. The initial intention behind creating Snappy and deploying “snaps” on Ubuntu-based systems is to obtain a unified single format that could be used in everything from IoT devices to full-fledged computer systems that ran some version of Ubuntu and in a larger sense Linux itself.[4]
The lead developer behind the project is Canonical, the same company that pilots the Ubuntu project. Ubuntu had native snap support from version 16.04 LTS with more and more distros supporting it out of the box or via a simple setup these days. If you use Arch or Debian or openSUSE you’ll find it easy to install support for the package manager using simple commands in the terminal as explained later in this section. This is also made possible by making the necessary snap platform files available on the respective repos.
Snappy has the following important components that make up the entire package manager system.[6]
- Snap – is the file format of the packages themselves. Individual applications that are deployed using Snappy are called “Snaps”. Any application may be packaged using the tools provided to make a snap that is intended to run on a different system running Linux. Snap, similar to AppImage is an all-inclusive file and contains all dependencies the application needs to run without assuming them to part of the target system.
- Snapcraft – is the tool that lets developers make snaps of their applications. It is basically a command that is part of the snap system as well as a framework that will let you build your own snaps.
- Snapd – is the background daemon that maintains all the snaps that are installed in your system. It integrates into the desktop environment and manages all the files and processes related to working with snaps. The snapd daemon also checks for updates normally 4 times a day unless set otherwise.
- Snap Store – is an online gallery of sorts that lets developers upload their snaps into the repository. Snap store is also an application discovery medium for users and will let users see and experience the application library before downloading and installing them.
The snapd component is written primarily in C and Golang whereas the Snapcraft framework is built using Python. Although both the modules use the GPLv3 license it is to be noted that snapd has proprietary code from Canonical for its server-side operations with just the client-side being published under the GPL license. This is a major point of contention with developers since this involves developers signing a CLA form to participate in snap development.
Going deeper into the finer details of the Snappy package manager the following may be noted:
- Snaps as noted before are all-inclusive and contain all the necessary files (dependencies) that the application needs to run. Hence, developers need not to make different snaps for the different distros that they target. Being mindful of the runtimes is all that’s necessary if base runtimes are excluded from the snap.
- Snappy packages are meant to support transactional updates. Such a transactional update is atomic and fully reversible, meaning you can use the application while it’s being updated and that if an update does not behave the way it’s supposed to, you can reverse the same with no other effects whatsoever. The concept is also called delta programming in which only changes to the application are transmitted as an update instead of the whole package. An Ubuntu derivative called Ubuntu Core actually promises the snappy update protocol to the OS itself.
- A key point of difference between snaps and AppImages, is how they handle version differences. Using AppImages different versions of the application will have different AppImages allowing you to concurrently use 2 or more different versions of the same application at the same time. However, using snaps means conforming to the transactional or delta update system. While this means faster updates, it keeps you from running two instances of the same application at the same time. If you need to use the old version of an app you’ll need to reverse or uninstall the new version. Snappy does support a feature called “parallel install” which will let users accomplish similar goals, however, it is still in an experimental stage and cannot be considered to be a stable implementation. Snappy also makes use of channels meaning you can use the beta or the nightly build of an app and the stable version at the same time.[9]
- Extensive support from major Linux distros and major developers including Google, Mozilla, Microsoft, etc.[4]
- Snapd the desktop integration tool supports taking “snapshots” of the current state of all the installed snaps in the system. This will let users save the current configuration state of all the applications that are installed via the Snappy package manager and let users revert to that state whenever they desire so. The same feature can also be set to automatically take snapshots at a frequency deemed necessary by the user. Snapshots can be created using the snap save command in the snapd framework.[10]
- Snaps are designed to be sandboxed during operation. This provides a much-required layer of security and isolation to users. Users need not worry about snap-based applications messing with the rest of the software on their computers. Sandboxing is implemented using three levels of isolation viz, classic, strict, and devmode. Each level of isolation allows the app different levels of access within the file system and computer.[11]
On the flip side of things, snaps are widely criticized for being centered around Canonical’s modus operandi. Most of the commits to the project are by Canonical employees or contractors and other contributors are required to sign a release form (CLA). The sandboxing feature, a very important one indeed from a security standpoint, is flawed in that the sandboxing actually requires certain other core services to run (such as Mir) while applications running the X11 desktop won’t support the said isolation, hence making the said security feature irrelevant. Questionable press releases and other marketing efforts from Canonical and the “central” and closed app repository are also widely criticized aspects of Snappy. Furthermore, the file sizes of the different snaps are also comparatively very large compared to the app sizes of the packages made using AppImage.
Flatpak: Like the Snap/Snappy listed above, Flatpak is also a software deployment tool that aims to ease software distribution and use in Linux. Flatpak was previously known as “xdg-app” and was based on the concept proposed by Lennart Poettering in 2004. The idea was to contain applications in a secure virtual sandbox allowing for using applications without the need of root privileges and without compromising on the security of the system. Alex started tinkering with Klik (thought to be a former version of AppImage) and wanted to implement the concept better. Alexander Larsson who at the time was working with Red Hat wrote an implementation called xdg-app in 2015 that acted as a precursor to the current Flatpak format.
Flatpak officially came out in 2016 with backing from Red Hat, Endless Computers and Collabora. Flathub is the official repository of all Flatpak application packages. At its surface Flatpak like the other is a framework for building and packaging distribution agnostic applications for Linux. It simply requires the developers to conform to a few desktop environment guidelines in order for the application to be successfully integrated into the Flatpak environment.
Targeted primarily at the three popular desktop implementations FreeDesktop, KDE, and GNOME, the Flatpak framework itself is written in C and works on a LGPL license. The maintenance repository can be accessed via the GitHub link here.
A few features of Flatpak that make it stand apart are mentioned below. Notice that features Flatpak shares with AppImage and Snappy are omitted here.
- Deep integration into popular Linux desktop environments such as GNOME & KDE so that users can simply use Flatpaks using Graphical software management tools instead of resorting to the terminal. Flatpak can be installed from the default repositories of major desktop environments now and once the apps themselves are set-up they can be used and provide features similar to normal desktop applications.
- Forward-compatibility – Flatpaks are built from the ground up keeping the operating systems core kernel and runtimes in mind. Hence, even if you upgrade or update your distro the Flatpaks you have should still work unless there is a core update. This is especially crucial for people who prefer staying on rolling betas or development versions of their distros. For such people, since the kinks of the OS itself isn’t ironed out usually, the Flatpak application will run seamlessly without having to depend on the OS files or libraries for its operation.
- Sandboxing using Bubblewrap – snaps are also by default sandboxed in that they run in isolation from the rest of the applications running while you’re using your computer. However, Flatpaks fully seal the application from accessing OS files and user files during its operation by default. This essentially means that system administrators can be certain that Flatpaks that are installed in their systems cannot exploit the computer and the files it contains whereas for end-users this will mean that in order to access a few specific functions or user data root permission is required.[14]
- Flatpak supports decentralized distribution of applications natively however the team behind Flatpak still maintains a central online repository of apps/Flatpaks called Flathub. Users may in fact configure Flatpak to use multiple remote repositories as they see necessary. As opposed to snap you can have multiple repositories.
- Modular access through the sandbox. Although this capability comes at a great potential cost to the integrity of the system, Flatpak framework allows for channels to be created through the sandbox for exchange of specific information from within the sandbox to the host system or vice versa. The channel is in this case referred to as a portal. A con to this feature is discussed later in the section.
One of the most criticized aspects of Flatpak however is it’s the sandbox feature itself. Sandboxing is how package managers such as Snappy and Flatpak implement important security features. Sandboxing essentially isolates the application from everything else in the system only allowing for user-defined exchange of information from within the sandbox to outside. The flaw with the concept being that the sandbox cannot be inherently impregnable. Data has to be eventually transferred between the two domains and simple Linux commands can simply get rid of the sandbox restriction meaning that malicious applications might potentially jump out of the said sandbox.
This combined with the worse than expected commitment to rolling out security updates for Flatpak has resulted in widespread criticism of the team’s tall claim of providing a secure framework. The blog (named flatkill) linked at the end of this guide in fact mentions a couple of exploits that were not addressed by the Flatpak team as soon as they should’ve been.
