On Wayland, systemd and Convergence

Posted by Jack on 2012-02-09 at 17:08
Tagged: software

One of the reasons the Linux desktop is making strides is that we are beginning to converge. One might look at the Unity/gnome-shell split, or the vast differences between GNOME/KDE/Xfce/Xmonad/etc. and think that that statement is a complete load. But look at the tech running our Linux desktops today:

This isn't even counting the defacto libraries that handle a lot of the less glamorous tasks on virtually every desktop Linux machine, like poppler for PDF display, or freetype2 for fonts, or components of the non-graphical GNU userland. And also not counting the various standards we almost universally adhere to, like EWMH (where possible).

Convergence provides us with great benefits. You might not like NetworkManager, you may prefer another, but it's because of NetworkManager that major distribution installs all operate identically. Loading Ubuntu / Mint / Debian / Arch / Fedora with GNOME or KDE and immediately you'll see what I mean. It fires up an applet, and the user just knows what to do. It's got permissions, it just works. Compare this to the days before when each distro had its own crazy script crap with varying levels of interfaces and it's the difference between night and day. Today I can hand my girlfriend - not a Linux expert by any stretch - her laptop with a default install of Arch w/ GNOME and she can hit the network. Not so long ago, I had a collection of bash scripts I tried to teach her to use.

Same with PulseAudio. You may believe that using straight ALSA is a better solution, but only until you have multiple sound devices you want to use. Or bluetooth headphones. Or want to do network sound. Or UPnP. Because the major desktop environments have converged around PulseAudio, they all operate similarly and have the same features. Settings in GNOME affect settings in KDE. Media applications can take advantage of PulseAudio's features and not have to worry about fallbacks.

You may argue that Telepathy applications aren't as mature or full featured as Pidgin, the classic IM client, but it's getting there and has several interfaces across toolkits (or lack thereof), and integrated with greater flexibility. Clients written to use it get so much for free that it's compelling.

Applications can be more featureful, stable, and interoperable when most of their functionality is shared in a backend. This was enshrined in the Unix Philosophy and forgotten somewhere along the way: separation of capabilities and presentation. These technologies aren't perfect, they may not eclipse alternatives yet, but the important thing is that they're agnostic of toolkit, window manager, or desktop environment. If you were to start another desktop environment today, there would be far less work to have a functional system today than 10 years ago because of them and that's a win for every person that's ever been unhappy with the state of their desktop.

The controversial part

I haven't yet mentioned the two pieces of software in the title of this piece for good reason. Wayland and systemd are, almost by definition, not about convergence. If anything they're about divergence as we, the open source community, have already converged on Xorg and sysvinit pretty definitively. However, these components are outdated and flawed. They form the basis of all the open source desktops, but we cannot allow that to force us into using them forever.

In the larger scheme of things, replacing these two pieces of software are part of what I perceive as a new push to converge on another component. The Linux kernel. These pieces are software are tightly coupled to it. This is the philosophy of their authors:

Kristian Høgsberg, creator of Wayland

FOSDEM 2012 Interview, February 2012 FOSDEM: Wayland requires Linux-specific features such as KMS and udev. Would it be much work to port Wayland to other free operating systems such as the BSDs? Do you know of any efforts or interest in this domain?

Kristian: It's certainly possible to port Wayland to other operating systems, but they'll have to provide the same level of infrastructure as Linux does. One of the things that went wrong with X was that we tried to pull too much of the OS into X so that we could run on every old platform out there. Or to put it more bluntly, bending over backwards for fringe platforms. There's a real cost to that; the code gets encrusted in #ifdefs, codepaths that never get tested and bad architecture decisions such as userspace PCI bus enumeration and writing your own dynamic linker.

I also find that the Linux kernel has a lot of cool features that can make applications faster, safer and simpler, and we often don't use those in the name of portability. There is an accept4 syscall that lets you accept a connection on a socket and sets O_CLOEXEC atomically. The epoll mechanism with timerfd and signalfd does most of what many complex userspace event loops do in many thousands of lines of code. We need to embrace all the new features the kernel offers and not insist on some outdated lowest common denominator.

Lennart Poettering, creator of systemd

Linux.fr Interview, June 2011 LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ?

Lennart : Yes, I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit.

I am pretty sure those other systems are not irrelevant for everbody, after all there are people hacking on them. I just don't think it's really in our interest to let us being held back by them if we want to make sure Linux enters the mainstream all across the board (and not just on servers and mobile phones, and not in reduced ways like Android). They are irrelevant to get Free Software into everybody's hand, and I think that is and should be our goal.

But hey, that's just me saying this. I am sure people do Free Software for a number of reasons. I have mine, and others have others.

To me, this is exactly the attitude we need. FreeBSD and same-kernel variants are the only open kernels with any sort of desktop presence other than Linux[1] and it has a tiny fraction the number of desktop users. OpenBSD is still relevant in its own ultra-secure niche, but the desktop is a completely secondary goal. NetBSD is... well, NetBSD. The point is that the Linux kernel has quite a lot of relevant features, and many times the number of users such that it doesn't make sense to warp the codebase of two of our most important components to function on them.

Wayland is a major win for the open desktop because it's dead simple, performant, and in it's 4 year life has already acquired features that are completely lacking in Xorg. It's shed years of X11 cruft in favor of a solution that makes sense on modern open source desktops. We no longer live in a world in which it makes sense to optimize your entire display server for the off chance that the window is going to be remotely connected over a network when 99.99% of the time the application is going to be a local window [2]. The simplicity of this approach lends itself to leaner, faster software built on top of it. But the simplicity Wayland has achieved is from leveraging technology that isn't present in non-Linux kernels. Apart from the tech that Kristian mentions in the quote above, FreeBSD (again - the most advanced w/r/t desktop capabilities BSD) lacks even rudimentary support for kernel mode setting (KMS) and other technology for this lightweight rendering in released code (although there are out-of-tree patches for Intel chips only).

Systemd too, taking advantage of the more featureful Linux-only u* tools and interfaces, shouldn't have to be warped to support tiny tiny fractions of the community. If it did, and the device hotplug or cgroup functionality it provided couldn't be relied upon, the higher level graphical applications would have to compensate, most likely by ignoring features or using messy fallbacks.

Pieces of the modern open source stack should be written to take full advantage of current technology (Linux[3]) and damn the rest. Not because I don't like BSD, not just because it has so few desktop users, but because open source, at its heart, is a do-it-ocracy. In no other software ecosystem in the world do independent developers feel beholden to support ancient and rare configurations of infrastructure or to hold of on adoption until support can be universal. In no other software ecosystem in the world does it make less sense to do so. If BSD users want Wayland and systemd, the code is right there, waiting for them to start a patch set against them.

And for those that would say that I'm impugning the open source grail, the freedom of choice, I ask you what you are choosing? Why choose one piece of software over another? Because one does what you want how you want it done, and another does not[4]. I want to live in a world where the way my software works is completely separate from the way I work with my software. How it works (sending messages, emails, making sounds, connecting to networks, displaying images or webpages etc.) should be solid, featureful and, most importantly, independent from how I work with it (CLI, graphical, integrated into this or that, windows here, buttons there, flashing icons, popups and notifications etc.). I think that you'll find that most of your choice has nothing to do with underlying technology and only with capabilities and presentation. Lets agree on capabilities and then we are free to choose presentation.

The time has come to take the final steps of convergence at the low level and the high level. To choose the best tech to standardize the underpinning technologies of our systems. Let's drop the harmful pretense of equality and instead usher in an age in which we can all count on a modern kernel, a modern init, a modern display server and functionality that is separated from interface. Then, and only then, will we have created not just the Year of the Linux Desktop, but the Year of the Ultimate Desktop.

[1] (Open)Solaris and kin could be considered challengers here, I see murmurs of better graphical support on the internet, but they're incomplete in terms of driver support, and the number of desktop users is minscule even compared to BSD.

[2] Which isn't to say that we don't want or need the capability of using graphical apps over a network, just that we don't need to cause crippling performance or design problems to accomodate it. That sort of functionality belongs in a plugin or a library. If anything, having it separated from the display manager just means it would be easier to tweak and perfect.

[3] And yes, this includes moving elsewhere in the exceedingly rare likelihood that Linux would ever be supplanted. It's the year 2012, Linux has the greatest number of developers and users, has faced down all of its (prospective though bullshit) legal problems and has gained widespread support in markets outside of the desktop. As of yet there are no open contenders other than OpenSolaris and BSD, unless you want to count HURD, hahahahaha.

[4] Licensing is also a factor, but I consider that part of "how I want it done."