The Linux display saga
The title of this article may be slightly misleading. What I want to talk to you today is the looming battle between Mir and Wayland, and there’s no better time to do that than right now, a few days after the latest edition of the Ubuntu family has been released upon the world. Now, we did talk about Wayland before, but it was more of a technical discussion, closely following another one on Qt, and how it might make Linux big one day.
And then, just a few days back, we discussed what is wrong with Linux, and there’s gonna be a sequel to that one, I promise, because it is inconceivable that a whole fleet of operating systems should have just eight bad things associated with it. Does not compute. Inconceivable. Yes, I used the joke again. Now, Wayland and Mir.
Alien vs. Predator
Did you watch that movie? Well then, you were surely disappointed. It just couldn’t have been good, no matter how you liked the two originals. Usually, nothing glorious comes out of such concept, for one simple reason. Quality is linear. Hype is quadratic. So when you try to double the awesome, you just get two portions of awesome, and you’re left with a sour taste of missed expectations.
What am I trying to say here, you wonder. Well, sometime in the future, there might come a clash between Wayland and Mir, if it hasn’t happened already, and when it does, the audience will surely be left with a great sense of loss. That is something we surely want to avoid, and with this kind of ominous portend looming above the article, let’s proceed into the discussion.
Unlike the movie, the Linux display server protocol story is a little different. It begins humbly in the 80s, when concepts of modularity, scalability and security were secondary to novelty and experimentation, and thus, the X Windows system was born, allowing people to see pixels dance on their slightly radioactive cast-glass monitors.
Fast forward thirty years, it is time for a change. In other words, the X does not scale well with the rest of the technology, and some feel that progress is hampered by legacy. Linux, never being a technological collective that takes much heed of backward compatibility and stability, is an excellent platform to test new and radical software, even when it touches the very core of the user-machine functionality.
As you imagine, the very announcement about the replacement, or let’s say, possible replacement for the X Windows caused fear and alarm among the users. Just as people started getting relatively decent support for their graphics cards, and some flavors of Linux made it possible to install drivers without bleeding at the sacrifice altar, there comes this new server protocol that threatens everything.
Actually, not one replacement, but two!
Wayland is one way of it doing. Way-land. Get it? One way. And Mir is the second one. Of course, no proper Linux core tool would be complete without at least three sub-versions and a handful of acronyms, because you also have XMir, a compatibility layer for X during the transition period, which we hope will be shorter than the IPv6 implementation, any day now, based on XWayland, which does the same for the second solution. This does not help you in any sense.
What happened really is, the community decided to work on Wayland. Canonical was unhappy about this, for various reasons, and decided to create its own implementation, called Mir. And so the Linux world was split in twain.
In reality, the problem is much bigger. When you fragment a fundamental component of the operating system, you double the effort needed to maintain it properly for every fork or iteration. Which effectively means that, in order to support the two new server display protocols, not to mention the old one not going away any time soon, developers will now have to invest at least three time as much effort in getting things to work properly, as if they did not have enough diversity already.
Let me explain why this is so bad. As you can imagine, no one really wants to be the underdog in this story, but the industry seems inclined toward supporting Wayland, and even rejecting Mir. That puts Canonical, and Ubuntu in a very tight spot, because it effectively blocks the adoption of their solution, which is essential to the success of this operating system, especially as Canonical moves forward in the mobile market. To make things worse, Kubuntu and Xubuntu also decided not to use Mir. They will stick with Wayland instead.
And so it begins, the great rift. If Ubuntu and Kubuntu start using different display server implementations, they will no longer just differ in the graphical desktop environment, they will become incompatible systems. Moreover, every single application developer will have to take this into account, if they want their stuff to run smoothly on both Mir and Wayland. Some might choose not to. For example, since KDE is a rather self-closed system, then it’s quite likely that KDE engineers might decide not to support Mir. That means Ubuntu users will not be able to run KDE software on their boxes, like for example Amarok or Kdenlive. And it gets worse.
Ubuntu, for better or worse, is one of the driving powers of the open-source innovation and Linux adoption in the home market. It is no small coincidence that Valve decided to finally go with Linux and chose Pangolin as their test bed. Moreover, there are rumors that the upcoming SteamOS will be based on Ubuntu. So now the matter of gaming might also be at stake. Will Steam support non-Mir protocols? Will all games be equally available on all Linux versions? In fact, what does it mean really? Can Ubuntu really be treated as Linux from this point on?
If you look at OSX, it’s BSD underneath, but that connection is long gone. The same might happen to Ubuntu. They just might go their own way, and a decade from now, it could be an extremely successful operating system with a great gaming support, but it will not have much in common with the rest of the Linux bunch.
So if Ubuntu gets ostracized, then other platforms might be in jeopardy. How will Linux Mint move forward from here? Will be see more fragmentation still? Will anyone else choose to adopt Mir rather than use Wayland? It’s a tough question, especially since possible future market share could heavily impact the people writing software. Money is a key factor here, and it could cause segmentation and intellectual starvation. In theory, the same way many companies refuse to compile their software for Linux, because the market is too small, or the potential profits are too meager, they might decide to just support Ubuntu or maybe not, and then, you will end up with an imbalanced ecosystem driven by ego and financial gains. Much like today, only squared.
Now, we head into the shops of graphics cards and drivers. What will Nvidia and ATI do now? How will they handle this problem? They will face the same dilemmas. Nvidia might partner with Steam, which sounds kind of logical, but then might not bode well for other Linux distributions. Or they just might work harder to support everyone. But still, when you ask someone, Linux, graphics, they could just say Nvidia, and the answer to that might limit you to a single Linux distribution. With a single desktop environment called Unity. No more Cinnamon, KDE or anything else. Take it or leave it.
How do we undo the drama?
All right. From speculative to practical. If you ask me, there must not be two display protocols. Because if you have two, why not seven. After all, we have a dozen desktop environments, let’s make each come with its own custom-made protocol that best suits its application stack. The kernel is also quite tricky, with different versions and signatures used in every other distro, however it’s more or less a single entity. And if this diversity somehow helped Linux bloom, at least from the technological perspective, the display battle will kill it.
All of the other layers did not slow down the evolution of the Linux application world. But now, finally, there’s one component that can break everything. If you cannot enjoy your software on every one distribution, without limitation, you might as well not use it. We have talked about this before, and this is exactly the reason why Linux has never it big yet. That plus hardware. Now we propose making it even more difficult to embrace the technology by creating this dividing line that none shall cross, and just at the critical time when Linux gaming is finally, finally taking root. Speaking of bad timing.
Technology-wise, there’s no reason why either Mir or Wayland cannot be the sole solution. After all, the X served us well for so long, any replacement can be tweaked well enough to do anything and everything we need. Therefore, the decision is purely political. Maybe there’s legalese involved, but it sure is not a matter of technology. That’s the easy part really. Perhaps Canonical wants more this and that, fine, hire a bunch of developers and they can sort it out. Or someone else might do it. The possibilities are endless in that sense, and it cannot be the bits and pieces of code that make the difference.
But is it possible to resolve this peacefully? Well, I sure hope so, otherwise we will end up with a serious problem that will erode Linux in the long term. Mark my semi-prophetic words, but it won’t end well with this kind of brotherly quarrel continuing.
Dedoimedo would suggest using one display server and making it rock, so that it is developed at the speed, quality and legal terms satisfactory to everyone. It can be done, and what’s needed is simple, pure human will to reconcile and do good. Everything else is secondary. I don’t want to sound mushy, we do not need a group hug right now. But if Linux can survive with a single authority for the kernel, and this works fabulously, the same principle ought to govern the display stack.
My hunch is, Wayland, and it has nothing to do with GPL, who leads the effort, who uses what. Simply because most distributions are leaning that way, and it’s a simpler matter of inertial consensus. Really, we will solve the technical bits quite easily. If only we can crack the human part. United we stand, divided we compile.