An old adage says there is nothing new under the sun, and to a certain extent, this could be true when applied to the subject matter of the this article. Formats for packaging software are as old as software itself. The formats commonly in use today include DEB from Debian and RPM from Red Hat. These two formats have divvied up much of the Linux world between themselves.

When these formats are used, individual package components like binaries, libraries, configuration, and documentation are distributed across the entire directory structure during installation. The distribution is carried out according to the Filesystem Hierarchy Standard (FHS) [1], and some of the placements are not always desirable. This is because the structure was based on needs for limited resources that existed in the early years of Unix development [2].

Figure 1: The Flatpak installation in Fedora also drags in OSTree.

Nothing New

For a long time now, it has been clear due to operating systems like GoboLinux, NixOS, and NeXTSTEP that this structure doesn't need to stay this way. The approach behind these operating systems is to package an application with its dependencies and manage everything together. The new formats function according to the same principle, and they reveal advantages and disadvantages when put to practical use.

Dissatisfied Developers

One definite disadvantage to the diversity among currently used formats is that they require significant work on behalf of developers and the software maintainers when the software needs to be packaged and maintained for multiple distributions and the various current branches.

During a question and answer session that took place at a Debian conference in 2014 [3], Linus Torvalds explained why a piece of software he had programmed for his scuba diving hobby exists as a package for Windows and MacOS X, but not for Linux. It is because none of the large distributions were able to package the components satisfactorily.

He even considers this to be one of the reasons why Linux has not found success on the desktop. At about the same time that Torvalds was conducting his question and answer session, the systemd mastermind Lennart Poettering was offering his thoughts on the question of how we will be building distributions and installing software in the future. Some of what he had to say was already starting to sound like concepts presently utilized in Flatpak and Snappy [4].

Figure 2: The run time of Gnome 3.20 is required to install LibreOffice 5.2 Beta.

From XDG-App to Flatpak

The XDG-App initiated by the Gnome project and Fedora, renamed Flatpak in May 2016, encounter the same problem that Torvalds and numerous other developers and companies have when it comes to packaging software for distributions. Flatpak packages applications with almost all of the dependencies, libraries and other components together.

In order to install and use this type of package, there only needs to be a suitable run-time environment. The distributions and desktops where the package will run are of secondary importance. The fact that an identical package of the same or another version is already installed on the system is also irrelevant.

Figure 3: Installing the LibreOffice Flatpak is easy.

This is where Flatpak exhibits another advantage. All of the apps run in a sandbox and are isolated from one another. If this reminds the user of containers, then the connection is not far off. The principle is the same.

In addition, the container software LXC is used, thus making Flatpaks into a desktop container. Therefore it is no surprise that the developers would like to have the specifications remain compatible with the standard for the open container initiative.

The name of the format originates from Sweden, which is the home of the developer Alexander Larsson. It references Ikea and the method the company uses for packaging products in flat boxes. Larsson works on the Gnome project for the desktop and also for Red Hat on container technologies.

Figure 4: LibreOffice 5.2 Beta installed from Flatpak.

He is convinced that Flatpak can be used with technologies from the kernel such as cgroups, namespaces, bind mounts, and seccomp, plus OSTree [5] from Red Hat's Atomic project and the Open Container Initiative's OCI format. Flatpak and Snaps are connected to these platforms through the application of Linux-specific technologies.

Newly developed technologies like Bubblewrap [6] are finding their way from Flatpak into the Atomic project. Bubblewrap makes it possible for the normal user to use and install isolated applications without giving the applications access to the system and the home directory and without increasing their privileges.

Not Statically Linked

An essential difference exists when it comes to containers from the server world. Container systems like Docker are statically linked. The run-time environment is connected in each container. Flatpaks, on the other hand, include a dependency to the run-time environment, which affords access to the basic system libraries.

The advantage here is that theoretically, a Flatpak has an unlimited run time even if the basic system and the demands on the hardware change. However, an application can only depend on one run-time environment at a time. In order to create more flexibility, the developer is working on dividing the run-time environment into modules.

A general advantage of this and similar formats is the shortening of the path from developer to user. The user does not have to update all of the distributions in order to have suitable dependencies for a current piece of software. The possibility exists of keeping an Ubuntu LTS version while still testing out the newest software.

One disadvantage, which is no longer quite so important thanks to the low price of hard drives, is the space needed on the drive since each Flatpak or Snap includes some of its libraries and other dependencies. Accordingly, the individual packages tend to take up more space on your drive in this format.

Early Stage

Flatpack is still in development and therefore is not yet well known. The software center in Fedora 23 GNOME Software and the IDE GNOME Builder have been prepared for Flatpak. The installation of LibreOffice as a Flatpack is being tested.

Figure 5: Command overview with flatpak -h.

Grab It

Canonical's own design Snappy is a development that has its roots in the Click package format for the Ubuntu phone. This concept was used for the first time in 2014 with Snappy Ubuntu Core for the Internet of Things (IoT) and for embedded systems. From there, the developers came up with the idea of Snappy Personal, which is supposed to implement the concept for the desktop.

The idea was officially successful on the desktop for the first time starting with the release of Ubuntu 16.04 Xenial Xerus. The packages have the simple name "Snaps," and they are suitable for the parallel installation into DEB format (Figures 8-10). They likewise contain all of the software in a bundle, which is divided in the same way as Flatpaks. Additionally they offer the possibility of atomic updates by means of Delta files [7]. Canonical refers to such updates as transactional.

Figure 6: Flatpak can also be quickly installed in Ubuntu.

In the context of Ubuntu 16.04, Canonical founder Mark Shuttleworth has often pointed to the gain in security achieved with the sandbox system. Shortly after its release, the well-known developer Matthew Garrett refuted this notion in his blog, indicating nothing would change as long as Ubuntu is still based on X11 and Mir is not yet used [8].

It is only fair to point out here that this is more of a problem with X11 than with Snappy. The fact remains however, that the gain in security will be noticed at the earliest in a year when Ubuntu sits on its own Mir display server.

Fixated on Ubuntu

Snaps for the desktop are still fairly new and development is still ongoing. The clear disadvantage here is the fixation on Ubuntu as a platform. While other distributions readily adopt Flatpaks, things are different for this system. Another disadvantage relates to assumptions about how updates work.

If an error is discovered in a library on a conventional system, the user replaces the affected library. With Snaps, the library has to be replaced in all of the bundles in which it is found. On the other hand, an advantage to Snaps is that the user can build it relatively easily from a DEB package or from the sources [9] [10]. As always, a run-time environment must be present. In this case, it is Snapcraft [11].

Snaps have played a large role in Canonical's work on convergence. In recent years, this goal has taken precedence over everything else. The idea is that software should be built with the same code for all platforms ranging from the smallest gadget for the IoT to an IBM mainframe computer. This would mean that a smartphone can function as a desktop when display, keyboard and mouse are attached. The first attempts at achieving such a set up can currently be tested using the Ubuntu Tablet BQ M10 and the Meizu Pro 5 smartphone. However, Snaps will play only a minimal role outside of Ubuntu and its derivatives.

The Ubuntu 16.04 user can call up a list of available Snaps with the snap find command. The snaps are installed via sudo snap install.

Figure 7: Run-time and install of LibreOffice 5.2 as a Flatpak on Ubuntu.

Flatpak in Media

I started with the most up-to-date beta version of Fedora 24 as the basis for the Flatpak test. In addition, I tested under the siduction distribution with Plasma 5.6.4. However, any distribution offering of the Flatpak format will do. I chose the beta version of LibreOffice 5.2 as the Flatpak (Figures 1-7). The only prerequisite for this choice is a Gnome 3.20 run-time environment.

The distributions have to be installed before they can handle the Flatpak format [12]. Flatpak itself is available for both Fedora 23/24 and Mageia 5 in the corresponding archives. Ubuntu uses a Personal Package Archive (PPA). Under Debian, the user enters the name in the source list and then loads the package via the Advanced Package Tool (APT).

Figure 8: Snaps are supposed to be sold in the future.

Currently, Flatpak can also be installed directly from Debian's experimental repository. Once this issue of Ubuntu User makes its way to readers, the format should be in Debian Unstable. Listing 1 works for Debian 7 "jessie."

$ wget -O - https://sdk.gnome.org/apt/debian/conf/alexl.gpg.key|apt-key add -
$ echo "deb [arch=amd64] https://sdk.gnome.org/apt/debian/ jessie main" > /etc/apt/sources.list.d/flatpak.list
$ sudo apt update && apt install flatpak

Nonetheless, I carry on with my test primarily with Fedora since Flatpaks are the closest to this distribution (that said, I also followed the same process on Ubuntu 16.04, and it worked flawlessly). First, update the distribution via sudo dnf upgrade to its most recent version. Once Flatpak is installed via sudo dnf install flatpak , you need to add the repository for the Flatpak run-time environment. This is accomplished with Listing 2.

$ wget https://sdk.gnome.org/keys/gnome-sdk.gpg
$ flatpak remote-add --user --gpg-import=gnome-sdk.gpg gnome https://sdk.gnome.org/repo/
$ flatpak install --user gnome org.gnome.Platform 3.20
$ flatpak install --user gnome org.gnome.Platform.Locale 3.20

Figure 9: Krita is easily installed as a Snap in Ubuntu 16.04.

LibreOffice All at Once

The run-time environment and localization require 200MB. Once installed, you can download the LibreOffice Flatpak with its 156 MByte [13]. After this, a standard user can install the package from the download folder via:

flatpak install --user --bundle LibreOffice.flatpak

It is irrelevant to this procedure whether a version of LibreOffice has already been installed, and if so, which version. The applications have no problems with one another. After about 20 seconds, you can start the office suite using

flatpak run org.libreoffice.LibreOffice

from the command line.

The run-time environments and the applications that have been installed are found in the home directory under ./local/share/flatpak . The man page and the flatpak -h command offer an overview of commands for Flatpak.

The Gnome software center also already comes with an integrated LibreOffice Flatpak. If another LibreOffice package has been installed via a standard procedure, then both versions appear here with icons that look identical to one another.

In addition, there are still some restrictions arising out of the early stage of development the format finds itself in. Since Flatpak applications are isolated from one another in sandboxes, LibreOffice still does not allow for hyperlinks to work from documents. Another feature yet to be completed is the online help, which does not currently load via F1. Also, there is still no Java Runtime Environment (JRE). Consequently, the functions, which are based on this environment, cannot be used.

Figure 10: Diagram describing the way Snapcraft works.

Conclusion

Flatpaks and Snaps provide an alternative to traditional package formats. The advantages they offer include compatibility independent of the distribution, installation without root rights, and isolation from both other packages and the host system. Potential disadvantages include the need for more space and the existence of previously undiscovered security issues due to the early stage of the format's development

Flatpaks are universally applicable. Testing under Debian with Flatpak from the experimental repository [14] works just as well as with Fedora 24. Snaps are generally found in the Ubuntu world of IoT gadgets, Ubuntu phones, desktops, servers, and the cloud. The user who utilizes Ubuntu and other distributions can also use Flatpaks under Ubuntu. It is doubtful whether Snaps will spread beyond Ubuntu.

The new package formats are good for some of the trials and tribulations experienced by developers and package maintainers plus users with customary applications. It is still not clear whether these new formats will be adopted more widely. Our opinion is that at a minimum, they will be able to hold their own next to DEB and RPM in the foreseeable future. Interest does exist on the development side as can be seen from the LibreOffice Flatpak tested here.

Mozilla and the newcomer Nextcloud have announced Snaps for their products. Currently, Flatpaks and Snaps can only demonstrate that the new formats work. Actual gains in security from isolation like the situation with containers can only be identified with the distribution of Wayland and Mir. At this point, nothing should stand in the way of the formats becoming more widely used.