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 fo 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.
I need some extra config to keep disk usage under control. 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 come from Red Hat or Fedora?
Disappointingly Flatpak apps are not called Flaps. 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.
For Ubuntu, Flatpak is almost well supported, but not installed per default.
sudo add-apt-repository ppa:alexlarsson/flatpak # before 18.10 sudo apt install flatpak sudo apt install gnome-software-plugin-flatpak # Integrates into GNOME flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
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
The Ubuntu software 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.