Snap and Flatpak are software deployment and package management systems for Linux, that become very popular recent time. Both look pretty similar at the first glance. Both have some level of isolation, contain all dependencies of application, once packaged, application can be installed in any distro that supports the packaging format, both has thousands of applications in repositories. But what the difference? And what to choose?
In this article I want to make a detailed comparison Snap vs Flatpak. I will overview some technical details of their implementation, purpose, advantages and disadvantages. But I will focus more on user experience and will skip all things related to creating that packages. I am not related to Snap or Flatpak developers, just did some research in the Internet, and examined how Snap and Flatpak work in my system and here is the result.
Table of Contents
- What Purpose of Snap?
- What Purpose of Flatpak?
- How Snap Works?
- How Flatpak Works?
- Snap vs Flatpak. What Difference?
- Wrapping Up
What Purpose of Snap?
Before we start comparing the formats, let's have a look why they were created. Canonical along many years tried to improve fresh software delivery for Ubuntu users. The main issue was that new versions of Ubuntu are published as fixed releases twice a year and users have to wait six months to get newer versions of software or even two years for those who want to use only LTS releases. Some applications, like, browsers, developing very rapidly and fast delivering new versions of such applications to end user is essential. Even six months is too long.
Firstly, Canonical launches PPA, then experimenting with point releases like 22.04.1, 22.04.2 that contain new version of browser and graphical drivers for old LTS distributions, then launches Software Center on top of PPA. All these attempts has their disadvantages. PPA considered as dangerous, because everyone can create a PPA and update packages without Canonical's review. Also, it requires a lot of work from developers to create a package for each Ubuntu release they want to support. Point releases also require a lot maintainers time. Software Center solves some problems, because Canonical was able to review and approve packages before adding. But it still be needed to re-submit each application for each Ubuntu release.
Around 2013, Canonical start developing Ubuntu Touch and Ubuntu for IoT devices. This area had its own peculiarities and requirements to software, like regular updates and high security to reduce amount of vulnerable IoT devices in the internet and simplifying developing and supporting apps for different versions of Ubuntu Touch. So that Click packages and then Snap packages was created.
The Snap packages solved most problems addressed above. They reviewed by Canonical or community before adding to store to ensure that they safe. Snap has regular automatic updates, so that you can't forget update it. And once created, a package can work on all distributions with snapd installed. Some time latter, Canonical added snap support for Ubuntu desktop. It happened in Ubuntu 16.04.
What Purpose of Flatpak?
Not only Canonical were making attempts to invent a better way to ship apps and make them more secure. GNOME developer Alexander Larsson was experimenting with application bundling using kernel containerization API and kernel namespaces since 2007. Developers of applications for Linux had the same problems as Ubuntu maintainers. They had not only to develop and release an application but also test and make it working at least on most popular distributions. Many distributions had different versions of libraries or even different package system like rpm and deb.
In 2015 Alexander Larsson introduced xdg-app to solve this problem. This tool provided for app developers an environments called Runtime that were used by applications to interact with GNOME desktop environment and were middleware between an application and OS. So that the application could be installed on each distribution that has xdg-app and required runtime. The advance of that approach was that you can have multiple runtimes with different versions of libraries. In addition, each application was launched in sandbox to increase security. The idea was to prevent application for accessing user files if it is not needed.
A few years latter xdg-app evolutioned into Flatpak but it still uses runtimes concept and sandboxing. To make installing and finding applications simpler by a new users FlatHub repository was created. However, the technology is completely Open Source and everyone can create his own repository.
How Snap Works?
Canonical tends to make Ubuntu as secure as possible, so they have only one Snap Store where all packages is reviewed before adding. The snap repository implementation is proprietary, so no one can create alternative stores. All you need to know, it that as user you can search packages in this repository, install the latest available version, choose channel (stable/edge) and check for updates.
Snap applications is packed into self-contained image file using SquashFS. This file has an extension .snap. All *.snap files installed in your system are located in the /var/lib/snapd/snaps/ folder. There are two types of packages: applications and snap core libraries. Application need an interface for interacting with operating system and snapd. This interface is provided by snap core packages. There may be installed multiple versions of the core in the same system, to support packages that were developed for different versions of Ubuntu.
Snaps are updated automatically and snapd checks for updates four times per day. It can't be completely disabled, but updates can be postponed or update frequency can be customized. When snap package is updated it stores previous versions in your filesystem too. By default two previous versions are stored. Here versions is called revisions. And you can use those stored versions later to revert previous version of package is something goes wrong. Since 2017 snapd support delta updates, when it can download not a full package but only delta.
Before using, each snap package should be mounted into filesystem. This is why usually you see a lot snap mountpoints in the lsblk output:
lsblk
By default, there are a folder for each package and each revision in /snap directory. For example, here transmission is name of package and 67 is revision:
ls /snap/transmission/
However, Firefox is updated more frequently, so in my system there are not only the current version but also two previous:
The package is mounted into the revision folder, and then all packages dependencies, interfaces and etc are mounted into that location too. But on host system you will see only contents of the snap file:
ls /snap/transmission/67
Snapd uses mount namespaces feature to make these mountpoints available only processes inside the snap package. However you can examine them by entering a package shell using the following command:
snap run --shell transmission
Path to the directory with the snap package data are placed in $SNAP environment variable. For example:
echo $SNAP
ls /snap/transmission/67
Here can be mounted host directories or directories from another snap packages. These mounting is configured by slots and plugs during snap creation.
Also, here you can try access some folders in your filesystem. For example, documents in home directory or configs from /etc/. And most likely you will get permission denied error:
ls /etc/
Snap applications may be in one of two confinement modes: strict and classic. In strict mode AppArrmor profiles is used to restrict access to all files that application should not access. Also seccmap profiles are used to limit access to kernel syscalls. Packages in classic confinement mode can access any file or folder in the filesystem.
Snap permissions are configured using slots and interfaces. It is just abstraction which allows to specify what features will be allowed for using. You can list it using the following command:
snap connections transmission
Additionally, you can configure snap permissions in the System Settings app on the Apps tab:
There are all applications listed, but only for Snap you will see detailed permissions configuration. Applications need to store their data somewhere. So snap provides two folders for data: /var/snap/ and ~/snap directory in users home dir. Links to that directories are placed in the following environment variables:
- SNAP_DATA - system-wide data for a specific revision of a snap package
- SNAP_USER_DATA - user data for a specific revision of a snap package
- SNAP_COMMON - system-wide data for all revisions of a snap package
- SNAP_USER_COMMON - user data for all revisions of snap package
echo $SNAP_DATA
When you delete a snap all that data is saved as snapshot in /var/lib/snapd/snapshots/.
To run an application from the Snap package you can use the following command:
snap run transmission
But also you can run it by typing application name as well as for regular applications. This is works, because snapd creates symbolic links for all available snap executables in /snap/bin to /usr/bin/snap.
ls -l /snap/bin/transmission
When you run any link, the snap command look at the first argument to determine application name, and then just run requested snap. So you will not see difference. Also icons and desktop files for snaps are exported in /var/lib/snapd/desktop/icons/ and /var/lib/snapd/desktop/applications/ folders. So you can run these applications from main menu as well.
How Flatpak Works?
Flatpak source code is completely open-source. Everyone can create their own repository and users can use that repository to install applications. However, to simplify application searching there are one most popular repository that has name Flathub. Each application there is approved by Flathub admins to meet repository requirements. Also, applications can be published by their developers as well as by third-parties. Apps published by developers have checkmark on their page and considered as verified:
Technically, each Flatpak repository is very similar to git repositories but for binary files. The technology that runs it is called ostree. Each application in the repository is branch and each version is a commit. So you can freely view information about all previous application versions and install any of them. For example, here is how you can view version history log for Transmission:
flatpak remote-info --log flathub com.transmissionbt.Transmission
And then you can update or downgrade application to a specific commit:
flatpak update --commit=1d4ddca72967f38c0339ab80dda38eb173e048800bfd11d635d21ec24781d477 com.transmissionbt.Transmission
In GUI you can manage versions of installed Flatpak apps using the Warehouse app. When you update Flatpak packages only changed data are downloaded instead of a whole package. After performing an update in the command line, you will see two sizes in the Download column, the first is delta is actually downloaded size and the second is the full download size:
flatpak update
Flatpak applications are placed to /var/lib/flatpak/ in the filesystem. Since the applications can work on each distribution where Flatpak is installed, they need some universal libraries that will work as middleware between the operating system and the application. As I said before, these libraries are called Runtimes. This concept was introduced on GNOME Developer Hackfest in 2013. Unlike Snap in Flatpak has different Runtimes with different set of tools, for example GNOME Platform, Freedesktop, KDE platform and etc. Applications and Runtimes are split in different folders: /var/lib/flatpak/app for applications and /var/lib/flatpak/runtime for runtimes:
ls /var/lib/flatpak/app
A Flatpak application itself is just a directory in the filesystem. For example files for Transmission package are placed to /var/lib/flatpak/app/com.transmissionbt.Transmission/current/active/. Icons and desktop files for Flatpak applications are exported to /var/lib/flatpak/exports/share/ to enable launching the applications from the main menu. By the way, only the current version of package is stored in your file system:
ls /var/lib/flatpak/app/com.transmissionbt.Transmission/current/active/
If you want to examine what the application can access, you need to enter the application shell. For example, use this command to run the shell for GNOME Clocks:
flatpak run --command=sh org.gnome.clocks
Here, you can see how the application environment looks internally. The application is in sandbox, but for me it looks more like container. There are its own root file system and the application files are mounted into the /app folder:
By default it is not your Linux root file system, but special file system with all needed libraries, sockets, devices and etc. For example, there are many empty folders in the /etc/ directory and /home directory is empty too:
Important notice, that the /proc directory, that contains all info about processes have info only about processes running in the sandbox:
I choose Clocks because it no need special access to files. Of course, if application needs access to root file system or user files it can request that permission and the real filesystem will be mounted into sandbox. This is widely used to overcome permission issues but even in that case sandboxed application can't mount the some directories from root filesystem, for example: /root, and /proc. Some other directories can be mounted but in /run/host, instead of root. And if application wants to mount users home directory, it still can't see in the file system data of other Flatpak applications.
To improve security and provide more control over application access to system resources, Flatpak developers created Portals technology that allows interact with desktop environment and files without accessing file system directly. For example Portals allows to make screenshots, record screen, choose a file and etc. Now Portals owned by Freedesktop project and can be used by all applications. Actually, since GNOME developers made internal GNOME API private, Portals is the only way to get access to some features of desktop environment.
Technically, Portal is DBus address with some API, that application can use to perform actions or gather data without direct access to sockets or file system. And application must ask permission from user to access each Portal. In package shell you can run the following command to see available protals and other DBus addresses:
dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
You can check permissions for Flatpak package using the info command with the --show-permissions option:
flatpak info --show-permissions io.missioncenter.MissionCenter
Additionally, you can examine or even change permissions of Flatpak applications using the Flatseal app. It shows all shared sockets, resources, folders, DBus interfaces, Protals and so on in GUI:
If Flatpak application need access that is not provided by Portals and can't be provided by mounting filesystems, it can use flatpak-spawn to run an arbitrary process on the host system. It requires permission to talk to DBus address org.freedesktop.Flatpak. During installation Flatpak shows permissions that application needs, so you will know what application can access before installing:
Data for Flatpak applications are located in ~/.var/app/. There are no global directory, and all user-related data is stored in his home folder. For example, for Transmission:
Also you can check some paths to folders with application data that stored in environment variables:
- XDG_STATE_HOME - application state (like /var/lib)
- XDG_CACHE_HOME - application cache
- XDG_CONFIG_HOME - application config files
- XDG_DATA_HOME - application resources (like /usr/share)
When you remove the application by default all these data remain in your file system.
Snap vs Flatpak. What Difference?
Now, you know what for these package formats were created and understand how they work. Let's do a summary and comparison in most important aspects.
1. Open Source
Both Snap and Flatpak package managers are open source. And both are developed and maintained by a huge community of users around the world. However, implementation of server side Snap store is proprietary. The API that snapd use packages is well documented and technically it is possible to create an alternative store. Even more, some time ago there were attempts, like Kebe, but at the moment of writing it looks like abandoned. So there are no working open-source alternatives. This may have some disadvantages, such as distributions and organizations can't create their own repositories to not be dependent from Canonical. And if Canonical decide discontinue Snap, community will not be able fork that repository and run an alternative.
Flatpak repository is based on the ostree tool, which is completely open-source, and users can create as many repositories as they want. However, there is most popular FlatHub repository which has most advantages that Snap Store have, like package review to protect users and simple user interface that allows to explore and install packages in your web browser.
2. Security
Both formats have isolation for applications to protect user data and system. Both have a mechanisms to overcome that isolation. Snap uses AppArrmor and Seccomp. AppArmor can ensure that application will not have access to directories that it not needed. But desktop applications very often need more permissions and so that they use classic confinement mode, when applications are not isolated at all. Such packages are approved manually before publishing to decrease security risks. As advantage snap packages may have access to /proc and other virtual file systems even in strict mode which allows to create snap packages for many command line tools like htop.
Flatpak has isolation that more looks like containerization implemented using bwrap. Each application has it's own root file system. All sockets, directories and interfaces that it can access should be explicitly provided into that file system. Everything that not allowed is restricted. Intended, that applications will use Protals as middleware to access different system features. However, at this moment Portals do not have all required features, so that flatpak-spawn exists that allows to execute arbitrary code on the host system. This is why Mission.Center can see all system processes. Snap applications can use Portals but flatpak-spawn is available only for Flatpak.
As you can see at security level both not ideal. Snap is more flexible and allows packaging apps that require a specific permissions more easily. But Portals is the future for Flatpak and Snap. Most likely, in the future Linux applications will have permissions configuration system like applications on Android.
3. Permissions Control
Developers can configure what files and system features application can access in Snap as well as in Flatpak. However, as user I want to be able change that settings and provide additional access rights to file system or sockets. In snap packages you can only manage predefined settings by turning on/off switches or selecting values in select list using System Settings app. Probably there are more configurations available in the command line, but it is not so easy to figure out what to change to provide access for some feature.
Flatpak allows you to customize almost any permissions using Flatseal app. You can allow or disallow executing code on host, provide access to required sockets, mount additional host folders into sandbox, allow access to system devices, add environment variables, configure available DBus addresses an so on.
3. Updates
Snap was designed for IoT devices, which should work most time without human interaction. Various vulnerabilities are constantly being discovered and patched in many programs. So it IoT like routers, hubs, and etc should get updates regularly. Snap updates the packages automatically and it checks for updates four times per day. That is great for IoT but not convenient for desktop. The application will be updated even if you are using it. For example, you are using your Firefox, and then see message that you should restart your browser because it was updated. Also developers can revert package version to previous. However, you as user can install only latest version or use previous versions that were stored in your system.
Flatpak does not support any automatic updates at all. But if you install integration with GNOME Software, it may update your packages during the system boot. Usually it fast and handy. On the one hand you always have fresh versions of programs, and on the other hand updating does not interrupt your workflow.
4. Disk Space Usage
Files of both package formats consume a lot of disk space. The packages contain all required libraries and resources so it can't be small. Additionally, snap preserves backup of previous package versions after update. By default you have two previous versions but you can configure it to store only one backup version. This means that if the package size is 1.5 Gb, snapd will consume at least 3 Gb for that package. And I not recommend remove the package backup because if something went wrong you will not be able to get the previous version from snap store. The advantage here that Snap packages are compressed so it took less space than regular applications.
Flatpak preserves only the current version of package. However this package is just folder with files, without any compression. I have did a test in two virtual machines with Ubuntu. I have installed 30 same apps using Snap and then using Flatpak.
Used space on root partition after installing all apps as snap increased by 8 gigabytes. However, this figure should be multiplied by three, because as new versions are released, the space occupied will grow. Three because one current version and two backups. So the actual disk consumption will be near 24 GB. Then I installed the same 30 applications using Flatpak and the used space was increased only by 13 GB. Of course applications also will store cache and user data but it is unlikely that these applications will consume much more space in the future. So there I can say that Flatpak uses less disk space than Snap in long term.
5. Popularity
Some time ago Snap statistics site reported that there are near 8000 snaps in the Snap Store. That's a lot. Other statistics such as installs and amount of active users are available only for application developers. Ubuntu uses snap by default, so many users have some applications installed as snaps by default. However, many applications are browsers, unofficial clients for something or system components for Ubuntu Core. Snap Store does not contain some applications from GNOME Circle. For example there are no Console, Text Pieces and Polari.
FlatHub statistics is open, and available at analyzen.com. At the moment of writing, there are 2500 applications and more than 3 millions downloads per day. You can find there many different applications which well categorized. There are all applications from GNOME Circle and much more.
Its complicated to determine which software repository more popular since I can't find open statistics for Snap Store, but for me FlatHub looks more alive. Although, both pretty popular. All most used applications can be found in Snap Store as well as in FlatHub.
6. Launching
Applications in Snap packages is more convenient run from command line because you can just type application name and then press Enter to run it. No need always write snap run and so on.
Flatpak names are very long, because they contain not only package name but also author name and domain prefix. So trick with symlinks like in Snap packages will not work. But it is not that bad. If you need to run Flatpak app from command line, you can use Bash auto-completion or you can create alias. Flatpak apps intended to be launched from main menu not for CLI.
The launching speed at the moment of writing is pretty same. After reboot Flatpak applications start a little longer as well as Snap apps. However, in my tests both were launched pretty fast.
7. Offline Install
You can download any snap package from Snap Store or a web site and then install it with --dangerous option locally even if you does not have access to the internet. This works pretty same as for deb packages, but you don't have to resolve dependencies, because everything needed already packed into self-contained image.
Flatpak allows developers to create single-file images with extension *.flatpak too. However, usually nobody does it, because Flatpaks depend on repository to get updates. You can't download a package from Flathub, but if needed you can create a USB with required packages and their metadata for offline install.
Wrapping Up
Snap and Flatpak work very well in the field for which they were designed. Snap solves most problems with security and updates for IoT devices. Most snap cons for desktop actually are advantages to IoT devices. Flatpak on the other side gives more control over application versions, behavior and permissions to end users which is better for desktop. Let's do summary comparison Snap vs Flatpak:
| Parameter | Snap | Flatpak |
|---|---|---|
| Fully Open-Source | No (Snap Store is closed) | Yes (ostree is open source) |
| Allows users to create their repositories | No | Yes |
| Has very popular repository/store | Yes (Snap Store) | Yes (Flathub) |
| Has application isolation | Yes (AppArrmor, Seccomp) | Yes (bwrap) |
| Allows disable that isolation for a specific apps | Yes (classic confinement) | No (But allows, mounting host filesystem in sandbox) |
| Allows to escape sandbox with a specific permissions | No | Yes (flatpak-spawn) |
| Provides access to /proc in sandbox | Yes | No |
| Allows to disable updates | No | Yes (No auto updates) |
| Allows to download package for local install | Yes | Partially (Creating offline USB) |
| Allows users to download previous versions of package | No (only latest) | Yes (all versions available) |
| Stores previous versions of package in system | Yes (at least one) | No (only current) |
| Simple launching apps from command line | Yes | No (long names) |
| Uses compression for application files | Yes (SquashFS, xz) | No |
| Allows users to configure permissions | Partially (Using System Settings) | Yes (Most permissions can be changed in Flatseal) |
| Has all apps from Gnome Circle | No | Yes |
| Can consume significantly more disk space after install | Yes (backups) | No |
| Can run apps in each distribution that supports this technology | Yes | Yes |
| Has universal libraries that can be used by developers to interact with system | Yes (core) | Yes (runtimes) |
| Updates programs when they are running | Yes | No (External tools allows updating before shutdown) |
| Can download only changed parts during update | Yes | Yes |
At my opinion nowadays Flatpak fits better for desktop, because it does not have not relevant for desktop behavior, consumes less disk space and have permissions system that can be managed using graphical interface. Of course Flatpak on desktop has some issues, so do Snap, but many of them can be fixed using Portals. What do you think about all this? Write in the comment section bellow!
