Linux has packages.
Depending on your distro, these may be called different things; debs, rpms, etc., but they all are basically the same idea. Each distro compiles and distributes the applications that run on it, this ensures they work and are easily available.
More recently, things have started to change, while core system packages remain in the traditional packaging formats, desktop applications have started to use different packaging formats that are distro independent.
The problem with classical package formats is two fold; there is a central group (the distro) that controls them, and they are distro dependant (and even version of the distro dependant).
So if I want to create a desktop application for Linux, and distribute it across multiple distros, that would mean I’d have to package it multiple times, across multiple distros. That’s a lot of extra work for the application developer and no one is going to package for every distro (there are hundreds of them).
As such, three distro independent packaging formats have come into the fore:
- AppImages
- Flatpaks
- Snaps
Each has it’s pro’s and con’s, so let’s talk about them a bit.
AppImages
AppImages are self contained packages that run on any distro, and have no central store (ok, there is appimagehub, but it looks unprofessinal and is not what I’d expect for the default store). This makes them appealing but does create a few issues.
The two that stand out are:
- No shell integration by default.
- No automatic updates (kinda).
Shell integration is a big deal for most users, if the application doesn’t appear on their application list, or can’t be easily managed, they’re not going to have a good time with them. There is a shell service to do that integration for you, but none of the major distros seem to ship with it installed by default.
Technically, AppImages do support auto updating, but it’s a relatively recent addition and it’s not mandatory. That’s a problem, or two.
Mobile phones, for better or worse, have made it a base assumption for most people that they don’t have to worry about updating theirs apps, that it will just happen in the background. AppImages break that expectation and it gets worse.
Even if you want to manually update the apps, the default behaviour of most browsers when downloading files, is to append a number if the file already exists, this can cause your shell integration to spawn numbered “versions” of the AppImage on your application menu.
I have used AppImages in the past, and they work fine, but they just feel like an afterthought, so I’ve removed the last of my AppImages from my system.
Flatpaks
Flatpaks are self contained packages that run on any distro, and have a central store (Flathub).
Flatpaks look to be winning the application packaging war overall, Fluthub is professional and well run, with funding and a roadmap to support purchasing software in the future.
Virtually all of my apps are Flatpaks at this point. There are a few that aren’t, mostly as they don’t support Flatpak yet.
But not is all rainbows and sunshine with Flatpak’s. There are a couple issues:
- Sandboxing
- Official vs. Unofficial Flatpaks
One of Flatpaks security measures is sandboxing the application from the rest of the system, this is a good idea in theory, but sometimes can trip things up. For example, I have a Flatpak music player, and by default it only has access to my “Music” folder on my system. Well, that’s ok, but I have music in other places… so…. 🤷
The solution is to edit the permission of the sandbox manually, using Flatseal, which is fine for me, a technical user. However, a run of the mill users would never figure out what was going on.
The other big issue (and this is improving) is that there are a lot of Flatpaks that aren’t created by the application developer. That adds another layer of required trust into the equation, and depending on how you feel about that, may be a deal breaker for unofficial Flatpaks.
Snaps
Canonical, the company behind Ubuntu, created Snaps for their enterprise server distro, as a way to easily deploy server software like SQL servers and web servers. They are self contained packages with a centeral store (snapcraft).
There has been a lot written about he issues with Snaps, mostly around performance as a desktop packaging format, and I won’t go over that here. In the end, I don’t see that as a big deal, if an application takes 3 seconds or 5 to start up, most people start their apps once and leave them running.
There are other issues with them though:
- Sandboxing
- Centrally controlled/limited reach
- Login required
Much like Flatpaks, Snaps are sandboxed, causing issues with permissions sometimes. Right now Steam is having issues with it’s Snap. So while Flatpaks have Flatseal, you’re at the mercy of Canonical if you have the same kind of issue with a Snap.
The biggest is the central control over the standard and platform. Yes Flatpaks have a central store, but there is a built in way to add additional stores and you can run your own if you want. Canonical has been very tight fisted over the Snap system, and practically speaking, that means only Ubuntu based distros (and not even all of them) have embraced it.
Another issue I have with them, is that the last time I tried to use one, Canonical required me to have a login, even to download free apps 🤔.
I will say that Snaps do have one benefit that neither AppImages or Flatpaks have, you can install non-graphical applications with them. That’s because that is what they were designed for.
That strength though is the cause of many of their weaknesses, what did it matter how quickly a snap started up when it was only ever starting when the system rebooted? A couple of extra seconds on a server that takes minutes to start up anyway is no big deal. Require a login? No problem for your corporate customers that have support contracts with you anyway.
Final Thoughts
Overall, for me, the way to go is Flatpaks. They have broad support across many distros (Ubuntu excluded of course) by default and they’re gaining popularity rapidly.
They aren’t perfect, but far better than relying on your disto to eventually package the latest version of LibreOffice for you… assuming they get around to it or don’t require you to update to a newer release to get it.
