A different approach to application containers with Limba

Over the past two years, application packaging has become a topic of much debate within the GNOME project. The packaging effort that has garnered perhaps the most attention is the sandboxed applications work done by Alexander Larsson, but it is not the only one. Matthias Klumpp, for example, has been pursuing an application-packaging strategy of his own that takes a different approach. Klumpp's project is called Limba, and a new release was recently unveiled.

Klumpp started working on Limba in November 2014, citing as his inspiration the same proposal that eventually led to Larsson's work. That proposal was Lennart Poettering's blog post about the difficulty of packaging third-party applications for Linux desktops. But Poettering proposed packaging applications into bundles that were quite isolated from the rest of the distribution, an approach Klumpp found problematic. It duplicates shared libraries and other components, makes the running system harder to profile, and, quite simply, bypasses the distribution rather than working with it.

Beaucoup bundles

Larsson and others pursued many of the ideas set out in Poettering's post, with some changes, of course, and the result is the xdg-app tool set, which we looked at in January. Limba bears some resemblance to xdg-app in the broad strokes. Both models bundle the application into a self-contained package that is isolated from the rest of the operating system using various technologies common to other containerization efforts, like SELinux, control groups, and namespaces (specifically, filesystem, process, and network namespaces).

The xdg-app sandbox design, however, relies on the host system providing a static "runtime" environment that will provide each app bundle with the libraries and system resources it requires. The GNOME work in this area has been focused on defining a "GNOME runtime" tailored to each GNOME release— the 3.16 runtime, for example, would receive critical security updates, but app bundles using it can count on it remaining unchanged even after the GNOME 3.18 release and its accompanying runtime make their debut. Other vendors (including, perhaps, Linux distributions as well as other application platforms like KDE) could produce their own runtimes that could also serve as targets for app bundles.

In contrast, Limba's approach lets each application distributor define its own runtime tailored to its app bundle. The runtime definition is dependency-based, much like existing package dependencies are specified today. Thus, the pieces within the runtime can be updated if a new version of some dependency is released.

Practically speaking, these dependencies are specified with XML according to the AppStream metadata format. When the Limba bundle is executed, the controller process is responsible for merging the contents of the bundle, the local libraries, and potentially other Limba bundles into a single OverlayFS filesystem that satisfies the bundle's dependencies. This OverlayFS filesystem is then set up in a mount namespace, inside of which the app bundle is launched.

A Limba bundle's dependencies can be specified as "version X or greater," in addition to matching a specific package version. The bundle can also include its own libraries (a feature that is also supported by xdg-app) for those packages not provided by a distribution repository.

Thus, the Limba bundle represents something of a middle-ground between the locally installed package as provided by most distributions today and the containerized bundle of xdg-app. In a March 30 blog post, Klumpp highlighted some trade-offs he sees between the two designs:

He also points out that a Limba bundle could be made to mimic the behavior of an xdg-app bundle by specifying an exact dependency set that happens to, say, match the contents of the GNOME 3.16 xdg-app runtime.

Current status

Neither Limba nor xdg-app are yet production-ready, of course; both are still undergoing plenty of changes in development. But both are testable. Klumpp released version 0.4.0 in February, which has subsequently been followed by two minor updates. Included at present are the lipkgen tool to both generate a Limba bundle template as well as build the final package, the lipa tool to install bundles, and the runapp command to launch an installed bundle. Because Limba uses OverlayFS, the system does require a kernel built with support for that filesystem.

In the March blog post, Klumpp also provided a real-world application bundle for those interested in testing Limba. The application in question is Neverball, the same video game that Larsson released in an xdg-app bundle in February. Whether or not this series of events will lead to a rise in Neverball bundle tournaments at development events has yet to be seen; hopefully bundles with other types of application will be forthcoming.

It will be interesting to see where Limba goes next. At the moment, it does not have as much of a sandbox system in which to isolate the bundled application, but that is on the agenda and it is worth noting that xdg-app's sandbox is still under construction as well.

Considering how much overlap there is between the designs, one might be tempted to think that the success of the projects would come down to how software distributors feel about the runtime issue. If GNOME (or another project) makes a compelling argument for its all-in-one runtime, that could draw more developers toward xdg-app. But distributors might find it easier to work within the existing package-distribution model, which Limba targets.

In the longer term, though, both projects make a case that their respective bundle format provides a stable platform that the application developer can count on. Whether the large-runtime approach of xdg-app or the more traditional system-provided package environment of Limba provides better stability is something only time will tell.