Running apps in a bundled-up packaged app format keeps things tidy and include all the necessities to run, so that an app developer can develop one version of the app rather than a different version for every different desktop.
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 seem to less frequently to require your attention, because the dominant administering corporation declares a single standard by fiat then irons the bugs out.
This tries to solve several problems at once
- managing dependencies
- (optional) timely updates
- ease of building for a developer
- (optional) improving security by sandboxing the app packages
In practice, like every unifying standard, these meta-standards have supplemented rather than replaced the existing standards, and many app maintainers now distribute their app to three different packaging systems in addition to the classic OS-specific system package managers. 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.
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.
Open question: How do any of these standards work for dependent software, such as optional plug-ins and extensions to an app you use? In classic OS packaging system it is natural to include various optional dependencies as small atomic packages, but it is not clear how you do this with bundled apps; For a start it seems to violate monolithic design and the popular sandboxing security model. How does that work then? Flatpak support Github extensions somehow; I should probably try to understand how they do it.
OK, are we good? So then! Here are the main players:
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
how 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 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. They are involved in a complicated controversy which is about corporate control, and limitation of early-stage technology and PR gaffes.
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 as actually used. 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, wherein a notification pops up to tell you that a PDF app selector has opened, which you click on to see the PDF selector which it in turn asks how you want to open the PDF, which you must repeat anew every single time you open a PDF.
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.
See the package manager page.