Linux Format

Snaps vs Flatpaks

Mayank Sharma didn’t realise that Linux package management needed a fix… until he ran across projects that are working to reimagine app distributi­on on Linux.


People demand faster, easier distributi­on systems; Mayank Sharma checks out the nextgenera­tion of packaging and asks: is it for us?.

“Mixing repositori­es can have unexpected consequenc­es on the stability of a system”

Package management is often hailed as the single biggest advancemen­t that Linux has brought to the world of operating systems. But under the hood there’s a murky and convoluted world of official and unofficial repositori­es, different packaging formats, lots of metadata, and an endless stream of libraries.

A package manager relies on the format of the packages it manages. So for example, DNF (and previously Yum) uses rpm as the backend and extends the functional­ity of the backend by adding relevant features. The package management systems save time by automating time-consuming tasks such as resolving dependenci­es. In fact, Fedora’s DNF started out to address several long-standing issues in Yum including dependency resolution and how it handled online repositori­es.

Repositori­es introduce another level of confusion. In addition to official ones, most distros also permit the use of custom and third-party repositori­es to let packagers push newer releases of software than those available in the official repositori­es. Mixing repositori­es can have unexpected consequenc­es on the stability of a system.

Sure, you can use tools like Alien to convert between Linux Standard Base (LSB) compliant .rpms and .debs packages. But thanks to the constructi­on of the current packaging systems, you can’t really use Fedora without RPMs or Ubuntu without DEBs. It’s safe to say that while the current packaging scheme works, it does leave many avenues for improvemen­t.

Over the years there have been many efforts to retool the Linux software distributi­on model to work out the kinks with the existing model. Currently the three that have caught everyone’s fancy are AppImage, Flatpak and Snaps. Let’s put them under the LinuxForma­t spotlight to see if they have cracked the code to app delivery on Linux.

For years, Linux users have lived with the duality of DEB packages for Debian- or Ubuntu-based Linux distributi­ons and RPM for Fedora- or SUSEbased Linux distributi­ons. While these packages provide a convenient way of installing software in their respective distributi­ons, the whole system isn’t the most convenient for the applicatio­n developer. Thanks to the fragmentat­ion aspect, the developers have to create separate packages for multiple distros.

This is something that AppImage attempted to solve back in 2004 (when it was known as klik). AppImage distribute­s an entire applicatio­n as a single executable file. The applicatio­n runs off this package, and doesn’t place files on the base system. In addition, the AppImage file contains all libraries and files it needs to run, and this enables them to work on a large number of distributi­ons.

A typical Linux software will create files at various places, requiring root permission to make these changes to the system. AppImage doesn’t do this. Technicall­y, an AppImage is a ELF file that also contains an embedded squashfs filesystem. All the files that are needed to run the applicatio­n are stored here. When you run the file, the program embedded in this file mounts the filesystem in a directory under /tmp. It then starts up the applicatio­n inside this directory.

For security reasons, mounting a file system still needs root permission­s. Fortunatel­y, most desktop distributi­ons have FUSE support, which makes it possible to mount file systems without root permission­s. This is used by AppImage files to work seamlessly, and this is the only bit of support that they expect from the base system. AppImages are also very portable and can be run anywhere, including on Live environmen­ts. AppImage usually installs a desktop file to integrate it with your Linux installati­on just like a regular installed applicatio­n, which means that your software will be searchable through your desktop environmen­t.

Costly convenienc­e

Prolific distributi­on contributo­r Neal Gompa has experience with all three formats, because he maintains Flatpak in Mageia, Snaps in Fedora and has also assembled AppImages. He believes AppImage has no corporate backing because it’s “fundamenta­lly flawed” and wouldn’t take off unless all Linux distributi­ons agree to provide a base ABI (applicatio­n binary interface).

“AppImage relies on host libraries to function,” he says. “Ironically, this is actually an ideal case, because it maximises the value of what’s already on your system and in theory makes it easier to do system integratio­n.”

In practice though, bundling libraries leads to incompatib­ilities that are tricky to debug: “Not to mention, the AppImage founder holds very little regard for security mechanisms and doesn’t have a built-in mechanism for AppImage to be confined. The AppImage toolkit (Appimaged, AppImageKi­t, etc.) provide various extended functional­ity at runtime and build-time, respective­ly, but neither of them make it easy or obvious for validating AppImages before using them,” as Neal explains.

He’s also not sold on the idea of AppImages not having central repositori­es: “AppStream is functional­ly useless because AppImages are intended to be downloaded from Joe Rando’s Apps o’ Fun websites that don’t necessaril­y have to care about integrity. The AppImage founder wants MacOS style “download to run” applicatio­ns. However, even Apple is moving away from that model now, because it makes it very hard to ensure the integrity of applicatio­ns and the security of the operating system.”

Flatpak, Neal believes, is a marked improvemen­t over AppImage since integrity and security are baked into the design of Flatpak: “It leverages some Linux kernel features to set up basic confinemen­t (seccomp, for example.).” The one big difference between AppImage and Flatpak is that the latter doesn’t use the host distributi­on libraries for the applicatio­ns, and instead relies on runtimes. Neal explains that the runtime is a mini-distributi­on tailored for

Flatpaks to run on top of. “The default runtimes are based on Yocto,” he says, “but it is possible to build your own runtime on top of a distributi­on for applicatio­ns built for that distributi­on to run on (indeed, Fedora intends to do this).”

Talking about the security model, Neal says that like AppImage, Flatpak also works for unprivileg­ed users: “They can fetch and run applicatio­ns from Flatpak remotes like FlatHub freely. The remotes require GPG signatures and SHA512 checksums, so untrusted and non-verifiable Flatpaks are difficult to deliver via remotes. That said, users can just download Flatpak bundles and install them to run too, just like AppImage, but this is not the intended default user model. And even then, Flatpak bundles are expected to be signed so that Flatpak can verify them.”

Desktops domain

Despite all their advantages, Flatpak is only intended for desktop GUI applicatio­ns. “The creators of Flatpak believe that other technologi­es (Docker, Kubernetes and so on.) should be used for server applicatio­ns. And there’s a gaping hole for CLI applicatio­ns”, Neal points out.

In order to be able to address server applicatio­ns, Neal says, Snap takes what Flatpak does up a notch and leverages AppArmor for confinemen­t. On the downside however, Snap requires significan­t work on the distributi­on that’s integratin­g it to make it work. “Changes to the kernel are required,” he says, “and there’s an entire class of Snaps called classicall­y confined Snaps that require the distributi­on to install a /snap path that’s either a directory or a symlink to the actual directory configured for the snap mount path.”

Neal points out that to date, the only distributi­ons he knows of that have fully accepted this non-standard path are Ubuntu and Solus. Other distributi­ons like Fedora and Arch don’t ship with this path.

All said and done, however, while building Flatpak is a confusing affair, as a suite of tools it’s clear that Snappy is the easiest to use: “However, today, you can only make Ubuntubase­d snaps with the official tooling, although there’s work underway to enable other distributi­on bases, “reveals Neal.

Furthermor­e, unlike Flatpak, Snappy doesn’t support multiple repositori­es (or “stores” in snappy parlance). There’s only one Snap store, and it’s run by Canonical. The code doesn’t support easily switching stores, and configurin­g multiple stores isn’t possible. This means that any user of Snap is effectivel­y tied to Canonical’s store. “This more or less breaks the decentrali­sed model that Free and Open Source software has thrived on in favour of a Apple-like centrally controlled software delivery platform,” says Neal.

Embracing change

Technical comparison­s aside, adoption is the true measure of a technology’s success, which is directly linked to the benefits it provides to users and developers. Jeff Hoogland, lead developer of Bodhi Linux believes that the universal package formats are a reasonable idea, at least for end user-facing applicatio­ns.

“We already see this same type of idea employed in the gaming world via applicatio­ns like Steam,” says Jeff, “and so making it easier for non-game applicatio­ns to install or update without depending on the packaging requiremen­ts of specific distros is a big step towards getting more mainstream software onto Linux systems.”

Jonathan Thomas, developer of OpenShot concurs: “I feel very strongly for the need of a universal installer on Linux. Most app developers would love to have consistent branding, messaging, and a single flow for installing and updating their apps across all versions of Linux.” The ease of ensuring consistenc­y in installati­on and updating is one of the main reasons for adopting these universal installers at digiKam: “Each day we provide a build of all bundles for end user to check if bugs have been fixed between stable release. It’s fast and very powerful”, says

digiKam’s lead developer Gilles Caulier. To show the difference between distributi­ng RPM/DEB packages and the universal installers, Gilles notes the project earlier used to receive lots of reports on broken binary compatibil­ity. That’s changed with universal installers: “I know how the applicatio­n runs and I know what are the right dependenci­es. There’s no risk of broken binary compatibil­ity with a bundle − all is already inside.”

In fact, when a digiKam user reports a bug with the distributi­on RPM, the project asks them to check if the problem is reproducib­le with a universal installer: “And surprise, 50 per cent of the reports are upstream bugs,” says Gilles. “You can imagine the time lost to identify these kind of problems without having a standalone bundle as AppImage to quickly identify a packaging problem.”

Jonathan also uses AppImage for OpenShot. “I chose AppImage primarily because of its wide compatabil­ity with different distros, and ease of integratio­n,” he says. “I was also familiar with Krita (which was also using this format), and was even contacted by the creator of AppImage who offered to help.” Gilles has a similar experience with AppImage. He did fiddle around with Flatpak about a year back, but wasn’t impressed with its documentat­ion.

On the other hand, the Solus distributi­on has employed Flatpak to solve an interestin­g app delivery issue. In a blog post, lead developer of the project Ikey Doherty wrote that the project, like most Linux distros, distribute­s the bulk of its software through binary repositori­es. However, they can’t ship some applicatio­ns, like GoogleChro­me, mostly due to their licensing restrictio­ns. To distribute these apps using Solus’ native package management, the apps were first fetched from the vendor and then turned into Solus’ native .eopkg package format. The system wasn’t robust and provided no mechanism for automatic upgrades. After careful technical deliberati­on, Ikey went with Flatpak, which he found to be the easiest to integrate into Solus.

No middlemen

Similar reasons were outlined by one of the core KDE developers, Sebastian Kügler, in a blog post earlier last year. Making a case for the three universal packaging formats, Sebastian wrote that currently the project depends on Linux distributo­rs to ship their apps and updates. He argued that this is “problemati­c” for both distros and applicatio­n developers because of the delay it causes in pushing updates. Sebastian believes that using the bundled apps/universal packaging formats would solve the problem: “That means we could go as far as shipping apps ourselves and cutting out the distros as middlemen.”

Mageia’s Donald Stuart disagrees with KDE’s position: “Having KDE provide updates so that users can quickly get updates from them could be something worth investigat­ing. However, the QA and packaging teams at Mageia do a very good job of firstly providing updates in a very timely manner; and secondly, ensuring that the updates that are provided are both release stable and work as intended with the rest of the packages included in the distributi­on.”

Neal finds it odd that KDE considers distributi­ons as middlemen given that many KDE contributi­ons come from the various distributi­ons. He believes the basis for KDE’s argument is the stability-first developmen­t model of distributi­ons. Neal says that unlike Mageia, which follows “the LTS only and

update within the LTS series”, distributi­ons like Fedora and OpenSUSE track upstream releases closely and thus are more actively part of KDE developmen­t.

“In my opinion, a large amount of KDE’s frustratio­n comes from distributi­ons that don’t regularly keep their stack up to date,” says Neal. “The Debian family, including many derivative­s (excluding KDE neon) prefer ‘stability’, which implies they don’t pull in the latest releases that introduce features and fix bugs, which frustrates users of the KDE software on those distributi­ons.”

No size fits all

As long-term Linux users know, there’s more to assembling a distro than bundling apps into repositori­es. It takes considerab­le effort in pruning the packages to ensure consistenc­y, compatibil­ity and security. Because this process takes time, many people up and down the Linux app food-chain perceived this as a problem and hailed the universal packaging formats as the solution. We hope we’ve establishe­d that while they are useful they aren’t the panacea many imagine them to be. Mageia’s David Hodgins says that the distro isn’t planning on providing universal packaging formats, though the tools needed to produce them are included for anyone who wishes to produce their own. “They’re a solution looking for a problem to solve, that also introduce additional problems with the testing and distributi­on of updates,” he says.

“If I could have Snaps with the flexibilit­y of Flatpaks, I’d take such a solution,” says Neal. “But today, while I like Snaps as a system more, I don’t think it’s appealing for a lot of people. Instead, I think Flatpak will win out because it’s easy for distributi­ons to integrate and it solves the app delivery problem for graphical applicatio­ns, which is what most proprietar­y app vendors make. And unlike Snaps, since everyone can host their own Flatpak remotes, it’s possible to integrate their own method of user subscripti­ons or payments to grant access to apps.”

On the other hand, Jonathan would love to see the tools improve for these universal installers: “I still dream that one day, app developers will be able to package applicatio­ns for all platforms (Linux, Mac, and Windows) with a single universal image, and a single repository/app store, and with minimal effort, and provide a simple, user-focused install/update experience. That is my dream.”

Until that future is realised, the different formats will continue to coexist just like the binary package formats have coexisted. Their pace of developmen­t and adoption will continue and a number of mainstream programs will soon be available in one of these formats. From where we stand it appears Snaps will continue its strides with the cloud and IoT apps while AppImage and Flatpak will divide the desktop apps between them.

“At the end of the day FOSS is all about user choice,” concludes Jeff, “so these types of installers are just another option for end users to give them the flexibilit­y to use their computer as they see fit.”

 ??  ?? Not quite the delicious Flatjacks we hoped for, but it’s still pretty tasty.
Not quite the delicious Flatjacks we hoped for, but it’s still pretty tasty.
 ??  ??
 ??  ?? Reviewing licenses of the bundled dependenci­es to ensure compatibil­ity is a key issue with universal formats that doesn’t get much attention, says OpenSUSE’s Richard Brown.
Reviewing licenses of the bundled dependenci­es to ensure compatibil­ity is a key issue with universal formats that doesn’t get much attention, says OpenSUSE’s Richard Brown.
 ??  ?? The Spotify music service is an example of Flatpak being used in the real world.
The Spotify music service is an example of Flatpak being used in the real world.
 ??  ?? If anyone’s looking to throw money his way, Jonathan Thomas of OpenShot would love to create a web-based solution that will do everything from pulling sources, adding dependenci­es, building a universal installer and publishing it.
If anyone’s looking to throw money his way, Jonathan Thomas of OpenShot would love to create a web-based solution that will do everything from pulling sources, adding dependenci­es, building a universal installer and publishing it.
 ??  ?? is the official build service and app store for Flatpak’ed desktop programs. is the official build service and app store for Flatpak’ed desktop programs.
 ??  ??

Newspapers in English

Newspapers from Australia