Dividing the Linux desktop

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.

The Ubuntu desktop has been committed to the Unity shell for some time; more recently, Canonical also announced that Ubuntu will be moving over to the new, in-house Mir display server. That decision raised a number of eyebrows at the time, given that most of the desktop Linux community had long since settled on Wayland as its way forward. As time passes, though, the degree to which Canonical is breaking from the rest of the community is becoming increasingly clear. The Linux desktop could never be described as being "unified," but the split caused by projects like Mir and SurfaceFlinger may prove to be more profound than the desktop wars of the past.

Canonical developer Former Canonical developer Jonathan Riddell started the most recent discussion with some worries about the future of Kubuntu, the KDE-based flavor of the Ubuntu distribution. KDE does not currently run on Mir, and some KDE developers (such as KWin lead developer Martin Gräßlin) have made it clear that they are not interested in adding Mir support. So Ubuntu will be shipping with a display server that does not support KDE in any sort of native mode. While libraries providing X and Wayland protocol support for Mir will certainly exist, they are unlikely to provide the level of functionality needed by desktop components like the KDE core. The result, Jonathan said, was that "the switch to Mir in Ubuntu seems pretty risky for the existence of Kubuntu"; he wondered about how other Ubuntu flavors might be affected as well.

Unsurprisingly, the developers working on Mir insist that they do not want to throw out the non-Unity desktop environments. Ubuntu community manager Jono Bacon was quick to say:

[I]t would be a failing of the Mir project if it meant that flavors could no longer utilize Ubuntu as a foundation, but this is going to require us to collaborate to find good solutions.

In other words, Canonical has a certain willingness to help make other desktop environments work on Mir, but it will take some effort from the developers of those environments as well. More specifically, Thomas Voß has offered to work with the developers of KWin (the KDE window manager) to find ways to make it work within the Mir environment. Assuming that a path forward is found, it is entirely possible that Kubuntu will be able to run under Mir on a Ubuntu-based system.

The problem is that such solutions are likely to be second-class citizens in general, and there are reasons to believe that the problem could be more acute in this case. The Mir specification does not describe it as a display server for all desktop environments; instead, it says "The purpose of Mir is to enable the development of the next generation Unity." There are a number of implications that come out of a position like that, not the least of which being that Mir and Unity appear to be developed in lockstep with no particular effort to standardize the protocol between them.

Canonical developer Christopher Halse Rogers described the situation in fairly direct terms:

We kinda have an explicit IPC protocol, but not really. We don't intend to support re-implementations of the Mir client libraries, and will make no effort to not break them if someone tries.

This position differs significantly from that of the Wayland project, which has based itself on a stable protocol specification. Leaving the system "protocol-agnostic" (that's the term used in the Mir specification) certainly gives a lot of freedom to the Mir/Unity developers, who can quickly evolve the system as a whole. But it can only make life difficult for developers of any other system who will not have the same level of access to Mir development and who might like a bit more freedom to mix and match different versions of the various components.

The result of this approach to development may well be that Mir support from desktop environments other than Unity ends up being half-hearted at best; it cannot be a whole lot of fun to develop for a display server that exists primarily to support a competing system. Few other distributions have shown interest in using Mir, providing another disincentive for developers. So, as the X Window System starts to fade away into the past, Ubuntu looks to be left running a desktop stack that is not used to any significant degree anywhere else. Ubuntu, increasingly, will be distinct from other distributions, including the Debian distribution on which it is based.

The success of Android (which uses its own display server called SurfaceFlinger) shows that reimplementing the stack can be a workable strategy. But there must certainly be a limit to how many of these reimplementations can survive in the long run, and the resources required to sustain this development are significant. Canonical is taking a significant risk by separating from the rest of the graphics development community in this way.

Over the many years of its dominance, X has been both praised and criticized from many angles. But, perhaps, we have not fully appreciated the degree to which the X Window System has served as a unifying influence across the Linux desktop environment. Running one desktop environment did not preclude using applications from a different project; in the end, they all talked to the X server, and they all worked well (enough). Over the next few years we will see the process of replacing X speed up, but there does not appear to be any single replacement that can take on the same unifying role. We can expect the desktop environment to fragment accordingly. Indeed, that is already happening; very few of us run Android applications on our desktop Linux systems.

"Fragmentation" is generally portrayed as a bad thing, and it certainly can be; the proprietary changes made by each Unix vendor contributed to the decline of proprietary Unix as a whole. But we should remember that the divergence we are seeing now is all happening with free software. That means that a lot of experimentation can go on, with the best ideas being easily copied from one project to the next, even if licensing differences will often prevent the movement of the code itself. If things go well, we will see a quicker exploration of the space than we would have under a single project and a lot of innovation. But the cost may be a long period where nothing is as well-developed or as widely supported as we might like it to be.

