Choosing between portability and innovation

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

Portability is a key concept in the open source ecosystem. Thanks to this killer feature, your author has migrated his desktop operating system during the last ten years from Mac OS X to Linux (various distributions) and eventually to FreeBSD, but throughout that process he could keep using most of the same applications. When you present a recent openSUSE or PC-BSD desktop system to a computer newbie, they won't notice much difference, apart from a different desktop theme, perhaps. The same applications (OpenOffice.org, Firefox, K3b, Dolphin, and so on) will be available. In many circumstances, it just doesn't matter whether your operating system is using a Linux or FreeBSD kernel, as long as it has drivers for your hardware (and that's the catch).

This portability, however, is not always easy to achieve. Now that Linux is the most popular free Unix-like operating system, it shouldn't be a surprise that some projects have begun treating non-Linux operating systems as second-class citizens. This isn't out of contempt for the BSDs or OpenSolaris, it's just a matter of limited manpower: if almost all the users of the application have a Linux operating system and if all the core developers are using Linux themselves, it's difficult to keep supporting other operating systems. But sometimes the choice to leave out support for other operating systems is explicitly made, e.g. when the developers want to implement some innovative features that require functionality that is (at least for now) only available in the Linux kernel.

Xfce 4.8 and udev

In January, version 4.8 of the Xfce desktop environment was released. In the beginning of its announcement, the developers expressed their disappointment that they couldn't offer all the new features of the release on the BSDs:

We hope that everyone will enjoy this release as much as we do. Sadly, this will not be the case as the folks using any of the BSD systems will notice a sudden loss of features. We think that this announcement is a good opportunity to express our disagreement with the recent "Linux-only" developments in the open source ecosystem, especially with regards to the utilities we need in desktop environments.

This somewhat cryptic remark was followed by a summary of the new features, but it was clear that it was aimed at the new desktop frameworks introduced in the last few years, such as udev, ConsoleKit and PolicyKit. udev is only available on Linux, but both ConsoleKit and PolicyKit are already supported by FreeBSD, so as LWN.net commenter "JohnLenz" supposed correctly in a comment on the announcement, the problem is for a large part on the testing side: how many FreeBSD users are using these frameworks? And how many of them test these frameworks regularly and spend the time to report bugs?

The remark in the release announcement probably puzzled a lot of BSD enthusiasts as well, because Xfce developer Jannis Pohlmann followed up a few days later with an explanation on his personal blog. There he named udev as the culprit for the non-portability of some Xfce features:

At least udev is strongly linked to Linux and as far as I know is not available on any of the BSD flavors. Unfortunately it is now the only good way to detect storage devices, cameras, printers, scanners and other devices using a single framework. That's why we use it in Xfce now in situations where HAL provided us with device capabilities and information to distinguish between the different device types before. The consequence is that thunar-volman no longer works without udev and thus only compiles on Linux. In Thunar itself udev remains optional.

But then Pohlmann points to the broader context:

I don't know what the porting status of the other frameworks is. But I am pretty sure not all of them have been ported to other platforms yet which is why I felt the need to express our disappointment in the announcement. For 2-3 years now all this has been a big mess. New frameworks were invented, dropped again, renamed from *Kit to u* and somewhere on the way it became impossible to keep Xfce as portable as it was before. I know that this is nothing new and that BSD folks faced the same situation as they do now back when HAL was invented but I don't think it has to be this way.

Some Linux users, who may be used to six-month release cycles, might not see a problem here, as they now have all those new features. But the BSD operating systems generally have a much slower development life cycle and haven't caught up yet with the whole redesign of the desktop stack. The comments on Pohlmann's blog post are instructive in this regard (although somewhat degenerating into a flame war at the end). For example, one commenter points out that HAL did acquire BSD (and Solaris) support, but only years after it had been mainstream in the Linux world, and the BSD developers only contributed the necessary patches to make it work when Gnome and KDE started making HAL mandatory.

The problem seems to be that udev is not as easy to port to non-Linux systems as HAL was. FreeBSD has the devd daemon to handle volume mounting, but devd 's author Warner Losh commented that udev is not well documented, which hampers efforts to port it. However, this didn't stop Alex Hornung from porting udev to DragonFly BSD, although it's not yet a full drop-in replacement. The FreeBSD developers could take a look at his work, as DragonFlyBSD is a FreeBSD derivative.

OpenBSD developer Marc Espie also points to license issues: udev and other software close to the Linux kernel is using GPLv2, which the BSDs don't like to use. For example, OpenBSD developers don't add a component to the base system if it's less free than the BSD license, and the GPL is such a license in their eyes. However, the current problems are also clearly a consequence of different development styles. Components like udisks are part of the Freedesktop specifications (which are supposed to keep X Window System desktops interoperable), but the BSD developers didn't seem to participate in that effort. Maybe the PC-BSD developers can play a role in this, as they want to deliver a modern desktop operating system based on FreeBSD.

All in all, there are two possible solutions to a situation like the one the Xfce 4.8 release is facing. One solution is that the Xfce developers create an abstraction layer supported by as many operating systems as possible. The problem is that currently there is no such abstraction layer for detecting devices, which makes it perfectly understandable that the Xfce developers chose udev. It is used by their major development platform, Linux, and one can't expect them to support frameworks on operating systems they don't use. So the other solution is that some BSD developers port udev to their operating system, which is non-trivial but (as the incomplete DragonFly BSD port shows) doable, or that they propose an abstraction layer that could be supported on non-Linux platforms. As many desktop applications have already been rewritten in the last few years from using HAL to using udev, the latter won't be a popular choice and isn't likely to happen.

X.Org and KMS

Another important desktop component that is becoming more and more Linux-centric in recent years is X.Org. Recent open source video drivers (such as the Nouveau driver) require kernel mode setting (KMS), which is a problem for the BSDs and OpenSolaris, as these operating systems lack kernel support for KMS and Graphics Execution Manager (GEM). So a FreeBSD user who wants to get decent performance out of an Nvidia graphics card, currently has to use the proprietary driver. Fortunately, the FreeBSD Foundation recognized the gravity of this situation and announced last year that it was willing to sponsor a developer to work on KMS and GEM support in the FreeBSD kernel. Last month, the foundation announced that it had awarded a grant, co-sponsored by iXsystems (the developers of PC-BSD) to Russian developer Konstantin Belousov to implement support for GEM, KMS, and Direct Rendering Infrastructure (DRI) for Intel hardware. Matt Olander, Chief Technology Officer at iXsystems, says in the announcement:

Adding support for GEM/KMS will allow both FreeBSD and PC-BSD to run with enhanced native graphic support on forthcoming advanced architectures with integrated, 3d accelerated graphical capabilities. FreeBSD has long been dominant in the server market and this is one more step towards making FreeBSD a complete platform for netbooks, laptops, desktops, and servers. We are very pleased to be a part of this project.

More specifically, Belousov will implement GEM, port KMS, and write new DRI drivers for Intel graphics cards, including the latest Sandy Bridge generation of integrated graphic units. After this work, users should be able to run the latest X.Org open source drivers for Intel on their FreeBSD desktop. While the project is limited to Intel graphics, porting other drivers like Nouveau to FreeBSD will become a lot easier once Belusov's work is completed. And when KMS support is in place, FreeBSD users could run the X Server without root privileges, run the Wayland display server, and get access to a lot of other features that are until now only available on Linux.

This case also shows that cutting edge development often happens with Linux primarily in mind. During the last few years, X.Org's drivers were in a constant state of flux, with new technologies like KMS, GEM, translation-table maps (TTM), DRI, Gallium3D and so on being introduced one after another. As these are low-level technologies tightly coupled to the Linux kernel, porting them to FreeBSD is no small task, but fortunately the FreeBSD Foundation and iXsystems have seen that it is very important to follow the lead of Linux here.

systemd

An entirely different case is systemd: Lennart Poettering has no problem with the fact that systemd is tightly glued to Linux features. In a recent interview for FOSDEM, Poettering sums up the Linux-specific functionality systemd relies on: cgroups, udev, the fanotify() , timerfd() and signalfd() system calls, filesystem namespaces, capability sets, /proc/self/mountinfo , and so on. And then comes this quote, explaining why he designed systemd with Linux in mind:

Not having to care about portability has two big advantages: we can make maximum use of what the modern Linux kernel offers these days without headaches -- Linux is one of the most powerful kernels in existence, but many of its features have not been used by the previous solutions. And secondly, it greatly simplifies our code and makes it shorter: since we never need to abstract OS interfaces the amount of glue code is minimal, and hence what we gain is a smaller chance to create bugs, a smaller chance of confusing the reader of the code (hence better maintainability) and a smaller footprint.

Poettering took this decision because of his experience in writing some other low-level components in the desktop stack:

Many of my previous projects (including PulseAudio and Avahi) have been written to be portable. Being relieved from the chains that the requirement for portability puts on you is quite liberating. While ensuring portability when working on high-level applications is not necessarily a difficult job it becomes increasingly more difficult if the stuff you work on is a system component (which systemd, PulseAudio and Avahi are).

He even goes further with this provocative invitation to other developers to do the same:

In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface , ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!

Poettering touches some interesting points here. We have a family of standards that are known as POSIX (Portable Operating System Interface for uniX), defining the API of a Unix operating system. However, the POSIX specifications are not carved in stone and there are few operating systems that are fully compliant (Mac OS X is one of them since the Leopard release). POSIX is really an encapsulation of some choices that various Unix systems made along the way, rather than a body of text that got standardized and then implemented. According to Poettering, Linux should use its position as "market leader" (in the market of free Unix-like operating systems) and try out some new things. If developers don't force themselves into the constraints of the POSIX API, they could develop some really innovative software, like systemd shows. When these new developments happen to turn out really interesting, other operating systems could eventually adopt them as well.

The tension between portability and innovation

These three cases clearly show that there's a constant tension between portability and innovation, which are two important qualities of open source software. In a lot of domains, Linux is taking the lead with respect to innovation, and the BSDs are forced to follow this lead if they don't want to be left behind. While the BSDs will probably not be interested in adopting systemd, implementing KMS is a must-have because one cannot imagine a modern X.Org desktop any more without it. But the biggest portability problems will be in the layers right above the kernel that don't have suitable abstraction layers, such as the Xfce case shows. Will FreeBSD implement udev or will the problem be solved another way? These kinds of questions are important and choosing when to use the POSIX or the Linux API is a delicate balancing act: choosing a Linux-centric approach for a low-level component like systemd is understandable because of the performance and maintenance gains, but most applications won't necessarily benefit from that approach.

But maybe the biggest problem these cases hint at is that Linux development is being done at such a fast pace that other operating systems just can't keep up. Linux distributions and Linux-centric developers are used to the "release early, release often" mantra, including swapping out key components and breaking APIs each release. The BSD world doesn't work that way, and this makes working together on a modern cross-platform open source desktop increasingly difficult. The innovation of Linux inevitably comes at a price: Linux is the de facto Unix platform now, and hence more and more programs will not be portable to other operating systems.