The Case for Flatpak, AppImage, and maybe even Snappy

Through the several years I’ve used Linux, I have seen way too much hate directed at containerized package distribution on Linux. Snappy/Snapcraft/snap rightfully gets the most flak, but purists decry anything that ships its own libfftw.so or libQt6.so. Everything should be shared. Code should never be duplicated, even when compiled.

(Un)surprisingly I used to be among that group of package puritans.

But do these critics have some valid things to say? Are you a bad Linux user if you use Flatpaks, AppImages, or Snaps? Good heavens, why are we even asking these questions? I thought the point of FOSS was the freedom to do what you want.

That said, I do have some opinions, which I hope you will consider. These are as follows:

1. The critics have a legitimate point (well, actually several).
2. These package managers do fill a need. It may not be your need, but there is a need filled.
3. There is probably a “best choice” for your use case, if, that is, you have one.

The Critics Have a Point

First, I think it’s good to go through the arguments made by critics against each of these package managers, because I do not think that they’re without merit. For the purposes of this blog post, I’m going to try to go over criticisms with the paradigm, moreso than specific package managers. That said, I will briefly touch on criticisms of specific package managers, because one in particular has some pretty big dealbreakers.

Actually, might as well get that out of the way first.

The elephant in the room here is snap. You all knew this was coming, and to be honest, I’m not going to try to defend it. I, admittedly, can’t bring myself to use snaps, for the reasons many Linux users have litigated ad-nauseum. To start, the Snapcraft repository is the only place you can get snaps from, and that backend is proprietary. The source code for the snap package manager itself (as it runs on your computer, not the server-side one) is available, but to my knowledge, nobody has bothered to fork it to allow the use of a repository other than the central Snapcraft repo. This, I would say is moderately bad, but still better than a proprietary app store, like what exists on your phone.

But the clincher with snaps has more to do with the fact that they were somewhat forced on Ubuntu users. My first distro was (K)ubuntu, and when I started using it, every package you’d ever need was available in apt. That’s not the case anymore. Firefox, for example, is only available on a default Ubuntu install as a snap. In fact, sudo apt install firefox “corrects” to sudo snap install firefox. If you try to install a nonexistent apt package, for which there is a snap available, the system informs you “there is a snap by that name.” To be honest though, if it weren’t for the other issues with snap, this would be helpful, although it does mean that Canonical is shipping a modified version of apt designed to promote their pet package manager. Oh, and snap packages update without your permission.

More broadly, the criticisms of containerized packages, which apply to all three mentioned here.

Containerized packages take longer to start up and have a larger memory footprint

This is true. Not only is this true, but this is a major drawback of all three package managers mentioned here. And the reason for this is simple: on startup, the container for the app to run in has to be set up. This isn’t a full-bore containerized OS a la Docker, but a pseudo-filesystem that contains generally some combination of /lib, /usr/lib, /lib64, /bin, etc. The creation of this pseudo-filesystem is a necessary first step, before the true filesystem can be mounted within it.

And memory footprints are larger, obviously, because any dynamically linked shared code (i.e., anything in a shared object or library) has to be loaded into memory per-app. And header information for each of these must exist, since they’re separate files, so the impact is greater than if everything was just statically linked.

And then there’s the hard drive footprint. Once again, the reasons for this should be obvious: for the same reason a statically-linked binary is larger than a dynamically linked one, a containerized package will be larger than a non-containerized one because the shared code must be duplicated, on the hard drive the same as in memory.

Deferring dependency version control to developers is a potential cybersecurity risk

Let me spell out a scenario for you: libFooBar.so is released at version 1.0.0, and it’s so cool that everybody starts including it in their apps. Maybe it does logging, or maybe it simplifies the process of making network requests to a specific service. Whatever it is, before long it’s widely adopted. Or maybe it’s a slow burn. But for whatever reason, dozens of major apps depend on it.

Pretty soon, with all this attention, someone discovers a zero-day vulnerability in libFooBar.so. The developers rapidly push out a fix, and many app devs update their dependencies. Inevitably, some won’t. Users soon need to update. If libFooBar.so exists in one place on the user’s computer, there’s one place to update. Once the new version is there, the vulnerability is gone. But, if some apps that use libFooBar.so are installed via containerized packages, it’s up to the developers of all of those apps to push out an update, and for the user to install all of them. The fact that the packages are containerized affords some safety, but how much, if any, that is depends on what the vulnerability is, and what permissions each app is granted. Bigger attack surface.

Containerized Packages DO Fill a Need

I do think that there are some pretty major benefits to package management that containerizes packages to some degree.

First, it’s much easier to avoid dependency hell, since if you’re a developer, you have much tighter control over what dependencies are being included, from versions to build options, to everything else. This eliminates a ton of non-determinism when trying to package your software for a wide variety of targets, like the myriad of Linux distros there are.

Second, Flatpak at least comes with a permission system, meaning you can restrict apps’ access to, say, the filesystem or the network. While mandatory access control and security contexts already exist in Linux via SELinux, it’s nice to have it built into your package management. If you’re looking at downloading a basic text editor or calculator and it requests full network access, you can think twice.

Mobile applications on Android and iPhone have already been doing this for more than a decade. The reason for this is partially because software management is shifted to a single user of the phone. Back in the day, kids, for example, didn’t have control over the software installed on the family computer. Now, teens have smartphones, and their parents aren’t monitoring what apps they install. So, app-specific access control was implemented, partially as a way to mitigate the damage of your twelve year old installing malware on his/her phone for free Robux.

Even if you are technically proficient, extremely careful, and vigilant, sketchy software can still slip through the cracks. I, personally, install non-system software via Flatpak/Flathub these days.

Also, AppImages are designed to be portable, which is nice. That’s the main draw for them, I’d say. You can put an AppImage on a USB drive, and plug it into any Linux machine to have your software of choice (or, a specific version of that software) instantly availabe. And to Snappy’s credit, Canonical does do a good job of filtering the packages you can install.

Broadly, I think there are a few types of software that lend themselves really well to containerized packages.

• Large, relatively monolithic software suites: Things like Blender, LibreOffice, or large proprietary tools like Xilinx Vivado, Matlab, Cadence Innovus, Synopsys Tetramax, etc.
• Web Browsers: these are largely already rather monolithic, and it’s not like you’re opening Firefox hundreds of times from a script. Well, maybe you are, who am I to judge? Plus, web browsers are exposed to the internet, where there is a myriad of cybersecurity risks. So, the containerization is nice, even if web browsers already do some of that for you.
• Software you just want to temporarily try: containerized packaging tends to manage orphaned config files and such better than those installed natively. If you like the tool, you can install it more classically.

In contrast, small, modular tools, especially CLI tools, should probably not be installed via these packaging systems. The increased startup time will have noticeable effects if you have to call these tools from a script. If you’re a UNIX philosophy purist, I can see why these packaging systems would seriously rub you the wrong way. But I like to find the nuance in everything.

Should YOU Use Them? Which is Best?

Just to get this out of the way, between Flatpak, AppImage, and snap, I gravitate the most towards Flatpak. It has basically everything I want in a containerized package system, except for a native messaging bridge (which makes some things difficult). I’ve also used AppImages before, but they’re a bit inconvenient since

Most in line with the general consensus among other Linux usere, I think that if at all possible, snap should be avoided. I recognize that on the most recent versions of Ubuntu, it is quickly supplanting apt/dpkg as the main package manager (though not for system components), and as such might be unavoidable. And yes, it does rub me the wrong way that sudo apt install firefox funnels to sudo snap install firefox. However, as mentioned earlier, web browser is something you may want running in some kind of a container.

Anyway, those are just my opinions.