When GNU/Linux was introduced in 1991, people used to compile their own software by themselves from the source code. You would simply download each component you want (or have it in a CD) and then take a few hours or even days to finish the compilation process. Of course, the compilation process is hard, as each component will require you to compile additional dependencies for the software to run, which will take extra few hours or days.
In 1994, however, the first package manager was introduced, which was PMS (Package Manager System) of the Bogus Linux distribution. Dpkg (Debian package system) was also introduced in 1994. And later on in 1995, the RPM (Red hat Package Manager) came to light.
A package is a pre-compiled piece of software that can be installed automatically on any host that is using the same architecture and has the needed dependencies. Packages solved the dependencies hell issue, and saved users a lot of time, and enabled non-technical people to have any software they needed. Packages & Package managers are still dominating till this day.
However, there are also some issues when it comes to the concept of packages; They are not isolated (working under a sandbox), for example, so any program you install as a package can access, read and modify (to some extent) every single file on your system. Also, packages usually come from repositories, and those repositories can either be official ones provided by your own Linux distribution or 3rd-party repositories. In the case of the latter, this adds a security danger since you are allowing random strangers to access your computer on the root level any time you update. Packages also have the issue of unsatisfied dependencies, where a certain dependency doesn’t exist in your distribution’s official repositories, or worse, when a certain dependency conflicts with another package’s dependencies and you end up with a broken system.
To solve all those problems, and other ones, what we can idiomatically call App Packages were introduced to Linux; App packages are usually containerized, dependency-satisfied portable set of various package formats that can be used to install a specific application on the user’s system. Each app format has its own features. Snaps, Flatpaks and AppImages are famous examples of app packages.
This article is part of a series about “App Packages on Linux“, where we try and review every single one of those app packages in order to show you the strong and weak points of each format. This series and other ones are part of our educational corner on the FOSS Post.
It depends on your use case and what distribution you use. None of the app packages currently market itself as a full replacement for traditional packages (Debs, RPMs..). Instead, they market themselves as a better alternative way to install a user-space desktop (or server) application.
If you are using a bleeding-edge distribution such as Arch, and you are not overdramatized about security, then you wouldn’t feel yourself in need of such formats. But if you are using a stable distribution like Debian but still want the latest version of a specific software without messing with your entire system’s dependency tree, then app packages are more than perfect for your use case.
App packages are actually more helpful to the developer than the user. As a developer, it may take you few hours only to build your app as a Flatpak or a Snap package, but if you are to build it as a traditional package for every single distribution out there in the Linux world, it would take you days and a lot of headache. Instead, in app packages world, the developer can simply put all the dependencies needed for his software to run in one single portable file, and distribute it to all of his users across various Linux distributions.
That’s why it’s worthy to note that the adoption of such formats isn’t mainly driven by user needs; It’s driven by developers needs. According to a poll by Distrowatch, 85% of readers don’t use Snaps or Flatpaks, they just use the traditional package managers.
Initially released in October, 2015 by Canonical. The Ubuntu maker aimed them to be a containerized format that developers can use to distribute their applications on desktop, server and IoT devices. They are an integral part of the Ubuntu distribution, and is installed by default there. In fact, some applications like GNOME System Monitor are installed as Snaps by default instead of packages in the recent Ubuntu versions. However, for other Linux distributions, you need to install the Snap daemon & tools by yourself and then start installing Snaps.
Snaps are sandboxed, contained filesystems. So when you are installing and using a Snap, what you are doing in fact is that you are mounting an image of a filesystem (a small filesystem, for each Snap) for the first time you use the app in your current session. This guarantees a good isolated environment where the Snap application can’t access the host (unless allowed otherwise). In this isolated filesystem, all the dependencies the application needs are available to it. Almost no dependencies at all are being shared with the root host or other applications.
In any app format, you still need an online repository or “store” to download the Snap packages. While all the Snap daemon source code is open source, the Snap Store is managed by Canonical, and the source code isn’t released (not open source). This means that anyone who wants to use Snaps will have to upload his/her program to the Snap Store only, and you can not run your own server instance of a Snap store.
Snaps are auto-updating by default. This means that whenever there’s a new release of a program that is installed as a Snap, it will be automatically upgraded in the background without any interference from the user. This guarantees that no users are left behind in terms of software updates.
The concept of “channels” also exists in Snaps; Developers can create many different channels for their program. A channel is a specific set of versions that are continuously updated according to a specific role. For example, the “stable” channel usually contains the latest stable production-ready version of the software, where as the “beta” contains an under-development version. Users can choose to subscribe to any channel they want, or even install the same software from multiple channels in the same time.
However, since every package publisher is responsible for their package alone, the operation of continuously updating the dependencies for the latest versions lies on them. This can be sometimes a bad thing in case the developer doesn’t respond to security updates on time and still ships the old dependencies, and my cause a security threat to the host system.
For more information about Snaps, visit Snapcraft official website.
Started around two months after Snaps (though it has an older history, see below). While it markets itself as a distribution-independent app package format, it is very fair to say that Flatpaks are coming from the Red Hat/Fedora camp in order to enter the competition with Ubuntu’s Snaps. Still, Flatpaks utilizes a different design approach than Snap packages.
Originally started as an idea and a prototype in 2007, and firstly released in September, 2015 under the name “xdg-app” and renamed later to Flatpak(s), they utilized many already existing containing and privileges/resources controlling technologies in the Linux ecosystem. Flatpaks for example use
namespaces from the Linux kernel, and
Bubblewrap from Project Atomic, and utilize a
D-Bus service.. Flatpaks can be either containerized or not, and it’s up to the developers to choose how their app will work. Flatpaks are not mounted images like Snaps, and while a sandbox exists by default, which limits a Flatpak package only to its files and runtime (not even the users’s home folder can be accessed), Flatpak packages can choose to escape that sandbox if they want by a simple configuration option in their build process. In other words, it’s up for the program developers that you are using to decide whether they want to stay in the sandbox or exit it, they are not all enforced to be sandboxed. This of course has its own reasons, benefits and downsides, but it’s an important thing to know about Flatpaks.
In Flatpak, there’s a number of “runtimes” which are a set of huge libraries that are shared among all the installed Flatpak packages. So for example if you just started using Flatpak and you wanted to install “GNOME Web” program as a Flatpak package, you’ll first need to download and install the entire GNOME X.xx runtime before you actually install the app (which can be 1-2GB in size). This runtime is shared between all Flatpaks, so you’ll have to download it only once. However, sometimes each Flatpak package you have may require a different version of that runtime, e.g GNOME 3.28 and GNOME 3.30, so that’s 2GB + 2GB = 4GB of downloads just for 2 desktop applications, and so on for all the other runtimes. It gets worse when you need to install just 5 Flatpaks, but each one of them requires a different runtime, resulting in cases where you get 10GB of download size and 20GB of disk usage.
Just like in Snaps, you need to install the Flatpak system on your Linux distribution before you start using Flatpaks.
There’s a central store to download Flatpaks which is called Flathub. However, the server source code is open source and released for free, which means everybody can have their own repositories any time they want. You may install Flatpak packages from any other source, not just Flathub.
For more information about Flatpak, visit its official website.
One of the oldest app packages on Linux; AppImages started in 2004 and are ready, willing and fully-enabled till this very day. AppImages, however, are neither sandboxed nor containerized. Instead, they are “bundles” of software along its dependencies in a single executable file.
AppImages, unlike Snaps and Flatpaks, do not require the installation of any software or runtimes at all. There’s no “AppImage” program to download and install before one can use AppImage packages, instead, you just download AppImage packages and start using them immediately, just like an
.exe file on Windows. You literally just click the package and it works on all Linux distributions.
Because of this, an AppImage is extremely portable, and doesn’t even employ the usage of any type of repositories. This had the downside that each user will have to pull the latest versions each few weeks/months manually by themselves, but is quite a good solution for developers who just want to release their app on Linux, like on Windows and macOS.
A good list of available apps as AppImages can be found in the AppImageHub.
For more information about AppImages, visit its official website.
There are other available app package formats on Linux, though less common:
- Nix Packages: Made by the Nix Linux distribution. Nix packages have ability of working on all Linux distributions and even the other Unix and Unix-like operating systems like macOS.
- 0Install: Similar to AppImages, but with extra security features.
- pkgsrc: Forked from the “Ports” application distributing system on FreeBSD. Works on all Unix-like systems too.
This was just an introductory article for app packages on Linux. You should have a basic idea now of what options are available and what may suit your needs both as a user and a developer. In future articles, we’ll go deep on each mentioned app package format to see their strong and weak points.