Six distributions, six ways for one program to fail

Distributing a desktop application on Linux runs into the same wall every time: dependencies. The same program, built once, may refuse to install on a different distribution because the library versions it expects are not there, or because paths are arranged differently. The failure is rarely interesting; it is a version number and a missing name, and the user is left to work out which of the two systems to blame.

The usual answer is to build a separate package for every distribution, which multiplies the work by the number of targets and still leaves the odd combinations uncovered. Flatpak takes a different route.

Bundle the runtime with the application

Its approach is to package the application together with the runtime it needs, and to keep that runtime independent of the system underneath. The application no longer borrows the distribution's libraries; it brings its own. As a result the same bundle installs the same way and starts the same way on systems that otherwise share very little.

That independence is the whole idea, and it is worth being precise about what it buys. It does not make an application portable in the abstract; it makes the runtime a fixed quantity, so that one thing has to be right instead of a whole chain of system packages. The cost sits on the other side: the runtime is shipped and updated as its own object, which means more disk and more updates than a native package would need.

A sandbox between the application and the system

Between the application and the system sits a sandbox. By default the application cannot see the whole filesystem, and it does not hold direct access to devices. When it needs to read or write a particular directory, or to use a particular device, that has to be declared explicitly in its permissions.

The model makes the boundary of an application's behaviour clearer, and it lets a user see, before installing, roughly which resources a program will touch. That is a modest gain in practice and a real one in principle: the question of what a program will reach stops being answered by trust alone.

Finer device permissions in 1.18

Version 1.18 added more granular conditions for device permissions. An application can ask for the one class of device it actually needs rather than opening the door to all of them. The change sounds small and is not: blanket device access is one of the reasons a sandbox is easy to dismiss, and narrowing it makes the declaration mean something instead of decorating the install screen.

There is a general lesson in that detail. A permission system earns attention when the requests are specific enough to be judged; a system where everything is asked for at once trains users to click through without reading.

Where the applications come from

The most common source is Flathub, a central repository that gathers a large number of applications. From the command line one install command is enough, and graphical software centres usually carry it as well, so the same catalogue is reachable from either direction.

Beyond the official repository, third-party repositories can be added. This deserves a warning rather than an instruction: a third-party repository does not pass through the same review process, so its origin should be established before it is added. Version 1.18 also supports installing directly from OCI images, and it improved the messages shown when an update fails. The second change only matters once something has already gone wrong, which is exactly when it matters most.

The other approaches, and what separates them

Several projects work on the same class of problem with different weights. One family puts the application in a central store with a review process behind it and covers many distributions. Another is tied closely to a single distribution, whose account and update machinery it uses. A third is the simplest of all: one file that runs as it is, but with neither central updates nor a shared catalogue.

None of them replaces the system package manager, and reading the comparison as a contest is a mistake. What differs is where the effort is placed: coverage and review, integration with one platform, or minimal packaging with the maintenance left to the user.

A sensible arrangement

For most desktop users the stable combination is to treat this as a supplementary channel and to keep system-level tools on the distribution's native packages. Applications that the distribution does not carry, or carries too slowly, come from the bundle; the things that touch the system itself stay where the system expects them.

Three operations cover most of the day-to-day work: installing, updating, and inspecting what an application has been granted. The third is the one people skip, and the one that makes the sandbox worth having in the first place.

Flatpak's value is that it decouples the question of which machines can run an application from the differences between distributions, and then makes the install inspectable through sandbox and permissions. It does not replace the system package manager; it fills in the part that was missing.