There is fierce debate brewing in the Linux community right now. Here we have two rival formats for packaging software. which one will be victorious and become the standard across all Linux desktops ? The answer in our opinion is that both will find a strong following for various reasons. Both will serve the common user, but one will reign supreme for industrial use. From as security viewpoint, at least for now, Flatpak has the advantage.
A brief history of software packages
A package is a piece of software that can simply be downloaded and run without the need to compile. “Hello world”, the first program taught in computer programming classes, is technically a package once it has been compiled. Packages are generally built on the assumption that all the necessary files and libraries need to run the software are installed on the operating system. GNU/Linux packages are either based upon Red Hat's RPM format or the Debian package format known as .RPM and .DEB respectively. There are some distributions that use tar.gz packages, but those will not be mentioned in this article.
During the mid 1990’s as Red Hat started becoming popular, users noticed that there was often difficulty in installing .rpm files. They experienced what is still known as “RPM Hell.” This term describes the situation where an RPM package cannot be installed for a number of reasons Generally, there are files missing or in the wrong version, preventing the RPM file from being installed. Users later found solace in the Debian package format which did not have this issue to the same extent. Debian relies upon repositories that contain all of the needed files The Debian system was built on the assumption that whatever packages were needed could be downloaded from somewhere in the Debian universe of repositories. Debian GNU/Linux distributions have the APT package management tool which solves dependency issues by downloading the required files and even compiling from source if needed. The RPM package manager tries to do the same thing but is not as effective as the Debian system. Red Hat tried to adapt to a repository based system but has not achieved the ubiquity of Debian-based repository system. As Debian became more popular it started being spun out into different derivative distributions such as Mint, Parsix, Elementary OS, Deepin, and numerous others, conflicts reminiscent of RPM hell are starting to become more common in the Debian world. There are only a literal handful of Red Hat derivative distributions as of the time of the writing of this article. Many believe that the primary reason for this is Debian’s superior package management. In the interest of fairness, the term “RPM Hell” has been expanded to the more proper and universal “dependency hell.” Also in the interest of fairness, it should be noted that Red Hat’s package management system has improved and does a much better job of using repositories. The problem of dependency hell still exists as of the time of the writing of this article.
Attempts were made to standardize the packages found in major distributions, in hopes of eliminating dependency issues. One such effort was the Linux Standard base. Because of the large variety of GNU/Linux distributions and derivative distributions, LSB failed in achieving this particular goal.
Over the course of time, Red Hat engineers and the Fedora community determined that they needed a package format which could compete with Debian and also prevent RPM hell from continuing. Ubuntu, a major GNU/Linux distribution, developed a package system which enabled packages written for their mobile phone operating system to be easily installed on any Ubuntu-based desktop operating systems. As a result of the transactional nature of Snappy packages, Ubuntu inadvertently developed Snappy, a package format which contains all of the needed files and binaries. Ubuntu developed what many believe to be the holy grail of package management. Ubuntu’s snappy packages could install on any GNU/Linux distribution, past, present, or future, as long as snapd was running. While Ubuntu was developing Snappy, Red Hat, along with Gnome desktop developers were developing Flatpak. Flatpak works on a very similar concept to Snappy packages. Flatpak requires Gnome desktop packages and the Flatpak executable, while Snappy requires only snapd, Ubuntu’s package installation daemon. Both Snappy and Flatpak applications can install and run on virtually any GNU/Linux distribution meeting these requirements. As is the nature of open source, several other universal types of packages are coming into existence. In the interest of brevity, those will not be discussed in this article. The market is expected to coalesce around Snappy and Flatpak.
The question of security
On the surface, it would seem that all would be well in the Linux community now that two excellent package formats have arrived. The truth is, that as of the time of this writing, there is a more complicated issue which has to be resolved. This issue is security. Red Hat developed a super-secure GNU/Linux Kernel module called SELinux In this system nothing happens without the user knowing. Access to every system function and file can be precisely controlled by the system administrator. When Ubuntu was developing Snappy, they developed around the Ubuntu system, which does not use SELinux. Ubuntu believes that all the security should be in the package itself. Snappy was developed based on an insecure Kernel and also on the insecure X11display server (Graphics system). Since SELinux requires that all systems be secure, SELinux would need to be turned off in order for snappy packages to install and run. Flatpak , on the other hand was built from the ground up to work with various security protocols and is extensible to any other security protocol that comes into use. Flatpak will also work with insecure GNU/Linux systems and, like snappy, has sandboxing and signed binaries, which does offer a form of security. Snappy does use Apparmor security protocol. The question for some is “ Is snappy secure enough?” The answer for most desktop users is that Snappy has sufficient security for most uses. For the enterprise, the difference is stark. Granular security is top-priority. How will this issue be resolved ? Most likely what will happen is that Ubuntu will try to update snapd to understand packages that have an added security layer which can interface with various security systems, including Apparmor and forthcoming secure display servers such as Wayland and Mir. This may be difficult to do since snappy is designed to work with a wide range of operating systems on various different types of devices. Some devices will be too small and low-powered to be able to handle the additional requirements that supporting various security protocols will require. So we have two different package systems, both of which are superior to the other in different ways. Red Hat finally has an advantage over the Debian world. How long will that advantage last, it is hard to say. Considering the resources that Ubuntu has used to develop their system the way it is, likely a very long time.
The question of distribution
Snappy works off of a concept similar to Apple's "App Store" Canonical is quite correct in referring to their approach as "transactional" Without Canonical's store, or some other Snappy server set up specifically to distribute your application, snappy may not work as you might expect. Flatpak on the other hand does not require a server of any kind. Your Flatpak file is fully independent and self-contained at all times. There is no app store unless the person distributing the app chooses to implement a transaction-based system.
A scandal is brewing
As of the time of this writing, it should be noted that there is somewhat of a scandal concerning the way in which Canonical has deceitfully marketed their Snappy package management system. For further info please consult:
Also: Great thanks to the author of the above-mentioned article for technical and chronological info will be used to correct any technical and/or historical shortcomings of this article.
Articles in agreement
Canonical has marketing muscle and large corporate partners. they have a soapbox for their point of view. This article is written for the contrarian view. as a result of this, there will be a section periodically updated with articles in agreement with our viewpoint.