OSTree use-case: Flatpack

If you’ve been around Linux for some time, you’ll remember universal package managers such as Autopackage. There were quite a few of them, but they all failed. It’s hard to give a single reason why this happened but perhaps the world didn’t need another package format to maintain.

What makes Flatpack different is it’s not a package manager. It’s closer to Docker in that it brings you nearly self-contained, ready-to run applications. This is a clear departure from the previous state of the things where you need to install all the dependencies (such as a GUI toolkit) before you run an app. The idea of bundling everything with your app is also not new, but Flatpack employs new technologies (such as cgroups, namespaces and OSTree) to make it smart and safe.

When you ship applications as bundles, you trade ease of management for the download size and security. If a bundled library appears vulnerable, you have no single point of update, leaving everything up to the application vendors. Flatpack tries to balance these requirements via runtimes, which are large shared blocks such as Gnome or KDE platforms applications can build upon. Space-wise, OSTree is a contentaddressed filesystem, so each blob is stored only once. Then, communication between the Flatpack app and host operating system is restricted, keeping attack surface to a minimum.

Ubuntu Snap is similar to Flatpack, yet it targets server-side, not desktops. And it has nothing to do with OSTree.