Running apps in a packaged format keeps things tidy and cross-platform, so that an app developer can develop one version of the app rather than a different version for every different desktop. In practice, app maintainers now have to distribute their app to three different packaging systems so it’s not clear there is an overall win here. Nonetheless, I understand that for many apps it is much easier to package them using one of the below systems than it is to work out the system packaging systems of Fedora or Debian or whatever.
Here I focus on the Linux systems, but packaging is a hot topic for other OSes too; it’s just more user-transparent for those OSes, in that the packaging systems do not seem to require you to pay attention.
Related, but not the same, containerization which, loosely, is more about distributing light configured machine services than desktop apps. See also sandboxing, which is often integrated with packaging, but is conceptually independent.
OK, are we good? So then! Here are some systems I have encountered.
The most minimal system.
.AppImage files around.
See the AppImage site for information.
the documentation is comprehensive.
You don’t need to install anything to make these go.
It’s simply an executable packaged app file format. It doesn’t necessarily know
ho to update itself, handle cryptographic authentication etc.
chmod a+x might be needed to make it executable.
Desktop integration is available via AppImageLauncher.
AppImage doesn’t sandbox at all per default, but they encourage you to use
Firejail to manually sandbox. Which I will obviously never remember to do in practice.
On one hand, this is not ideal, having to manually assign permissions to everything.
On the other hand, there is little evidence that package maintainers put
much thought into the permissions they give sandboxed apps generally, so it is
probably not substantially worse than the alternatives.
The packaging system Ubuntu backs. Ubuntu explains snaps and how they are used by lots of linuces and this is convenient. Snapcraft.io is the landing zone. Snaps (Snap apps) seem to be well-integrated into the desktop (the GNOME desktop at least) and low-fuss. They update themselves magically. Ubuntu have come under fire for snaps being opaque and easy to backdoor, requiring trust in the the Ubuntu Czars to be the gatekeepers. That is, they are currently dubious for hardened oses, because while they provide sandboxing, it is leaky and comes at the price of accountability.
I needed some extra config to keep disk usage under control when trying snaps. Per default, it keeps many expired versions of every app lying around for no particular reason that I understand.
sudo snap set system refresh.retain=2
or to remove inactive expired versions right now (bash shell)
sudo bash snap list --all | while read snapname ver rev trk pub notes; do if [[ $notes = *disabled* ]]; then snap remove "$snapname" --revision="$rev"; fi; done
I think this one comes from Red Hat?
flatpak enables many sandboxed apps via flathub. It is shiny and GUI-friendly, and seems to include update infrastructure. It claims to be a secure way of running apps sandboxed, but may not be especially secure. It is at least, tidier for package maintainers so makes it easier to distribute software. The cost is that desktop integration is only kind-of functional. Disappointingly, Flatpak apps are not called Flaps.
For Ubuntu, Flatpak is almost well supported, but not installed per default.
sudo apt install flatpak # Integrate into GNOME: sudo apt install gnome-software-plugin-flatpak flatpak remote-add --if-not-exists flathub \ https://flathub.org/repo/flathub.flatpakrepo
UPDATE: in Ubuntu 20.04 or later default GNOME software app no longer supports flatpak, so installing flatpak installs another version of the Software store app.
The major pain-point of flatpak for me is the portal system, which is a bit of infrastructure that we as users would prefer to know nothing about, but which we can’t help but notice because of its obtrusiveness. When a flatpak app tries to ask a local app to open a file — e.g. a PDF view to open PDF files — rather than being a 1-click operation, it’s a tedious rigmarole, telling you that a PDF app selector has opened, which you click on to see the PDF selector which it in turn asks you then asking you anew each time which PDF app you would like to use. Every single time.
Another pain point is that Flatpak tends to rapidly consume disk space under
The Ubuntu software app gui sometimes seems to be confused about whether to install for a single user or system wide, or both. I found I can reduce the number of duplicate copies via
sudo flatpak remove --system org.zotero.Zotero flatpak install --user org.zotero.Zotero
One can AFAICT execute flatpak apps directly, via, e.g.
but one is supposed to do this:
flatpak run org.zotero.Zotero
If you get weird errors from a flatpak app about how it can’t access some important file, you might need to give it extra permissions.
flatpak override --user --filesystem=/path/to/dir org.app.Id
Flatpak does not allow access to USB (or indeed any) devices per default. That means that if you want to access peripheral hardware you need to do
flatpak run --device=all com.calibre_ebook.calibre
This is, as the phrasing implies, an all-or-nothing situation. Either you trust an app to access every device you have, or none of them.
Look, it is not quite the same thing, but the Nix build system works by isolating dependencies which accomplishes many of the same things but in an elegant way.
Nixos needs filing somewhere. It is a packaging system that builds unique combinations of dependencies for particular software in a functional language style (i.e. no side-effects)„. Works on linux or OSX. There is a whole linux distribution built on it which sounds like it is wonderful when it works, but it might occasionally be a crusade. The pills are a series of essays in how the system works.