Trying to keep up with the release cycle of many Linux distributions can be costly and time consuming. You get your software working for one release, and an update breaks it all over again. Vendors that want to ensure their software runs on Linux computers sometimes simply develop for an operating system version with a long support window, such as an LTS version of Ubuntu, a Debian stable, or RHEL. Problems can occur when the user doesn't even bother to design for compatibility with intermediate versions, or when the user wants to switch to another distro. The cost of keeping pace with the ABI and API changes in Linux is frequently too high.

Lennart Poettering and some other systemd developers have sketched an ambitious proposal [1] addressing the compatibility issues that plague Linux updates. The goal of the plan is to make certain parts of a Linux distribution uniform for all users, admins, developers, and software vendors. If the developers succeed in their efforts, the result will be improved software distribution and security, as well as more seamless support for server, cloud, and embedded environments.

Poettering summarizes the benefits of the plan as follows:

• Software vendors will not need adapt their software to the libraries of specific distributions; instead, they select an optimal run-time environment and then pass the necessary information on to all distributions.
• Admins and users will be able to install software without worrying about the distribution.
• Updates will occur according to a uniform scheme and can be implemented in the same way for operating systems, OS containers, applications, and programming ABIs.
• A chain of trust ranging from the firmware via the bootloader to the kernel will provide the necessary security in a "post-Snowden world."

To achieve their goals, the developers are combining existing approaches pursued by Docker [2], CoreOS [3], and the Gnome OSTree [4]. The new project will be interesting for all distributions and workloads; at the same time, it will take advantage of the capabilities of systemd and Kdbus.

Treelike

Unlike similar projects in the past, such as Autopackage [5] and Zero Install [6], the developers are seeking to locate their ambitious concept at the filesystem level and, in particular, to leverage the possibilities of the Btrfs and Linux filesystem namespaces. In particular, the team is looking to make intensive use of subvolumes and a feature called "send-and-receive."

Put simply, this is a question of using subvolumes and read-only /usr trees to support the coexistence of multiple versions of the OS, run times, frameworks, applications, and home directories on the same Btrfs volume. At the same time, only readable, mounted /usr trees can be cryptographically verified.

The tree model gives developers the option of simply operating multiple run-time versions in parallel. Software vendors can make sure their software ends up in exactly the same environment on the user side as for development. Admins can use multiple operating systems  – whether on bare-metal machines or as containers.

The root /usr tree will thus contain, for example, all relevant distributor files and follow a pattern of:

usr:<vendorID>:<architecture>:<version>

The instances of different operating systems then reside in the /usr tree below this according to the following scheme:

root:<name>:<vendorID>:<architecture>

The /usr directory is initially empty. The run times and frameworks end up here – including the apps later on – one level down. For more details on the proposed naming scheme, read Poettering's blog [1].

For example, one instance of an operating system will launch at boot time; its empty /usr directory is then populated with a Java run time, in which, finally, LibreOffice runs.

Focus on Btrfs

As expected, the blog post on Google plus [7] and other web pages has been discussed extensively. Poettering already defused some of the worries in his blog entry: No, it will not cost much more space if an admin installs multiple run times in parallel. For one thing, many users only use a limited number of run times, and for another, Btrfs deduplicates duplicate files.

In other words, if an admin operates five operating systems in parallel, this will not mean having five almost identical /usr trees on disk. If an admin updates the software, says Poettering, Btrfs will retrieve the binary delta, which contains only the differences between the old and the new versions of the software.

At the same time, the Btrfs send-and-receive feature mentioned earlier enters the game; Poettering proposes a double buffer for this. The filesystem can transfer deltas to other systems as subvolumes.

Not only can updates be distributed in this way, during the install, the admin simply unpacks a send-and-receive delta in an empty Btrfs volume. You can also build test systems on your own /usr tree and distribute them as diffs. This approach also applies to embedded systems that run on TV sets or in-vehicle infotainment.

Obstacles

Why Btrfs? This is a recurring question that marks the filesystem as not currently being ready for the big show. Although Poettering argues that the /usr trees are only readable, he also acknowledges that the systemd developers are trying to push userspace issues into the fledgling filesystem. You need to patch Btrfs until it meets the requirements to avoid reinventing the wheel.

How admins can then patch the run time is another open issue. Poettering is hoping that some standard run times will crystallize that use software from existing distributions including the security patches.

In contrast to this, run time files that need hardware support, such as the OpenGL drivers, are an open issue. Although the developer states that there is no good solution to this dilemma, if GL does not support userspace drivers installed in parallel, it probably needs to be fixed.