Lead Mir Developer: 'Mir More Relevant Than Wayland In Two Years'

M-Saunders writes Canonical courted plenty of controversy with it announced Mir, its home-grown display server. But why did the company choose to go it alone, and not collaborate with the Wayland project? Linux Voice has an interview with Thomas Voss, Mir's lead developer. Voss explains how Mir came into being, what it offers, and why he believes it will outlast Wayland.

Comments

Not Invented Here

[headkase]

I think the main issue Canonical has with Wayland and X is that they are Not Invented Here. Canonical has their own priorities and regardless of the technical merits vs. Wayland and others Canonical wants to be in control of the display server so they can lead it to their interests and not have to convince other parties to go their way.

Re:Why?

[0123456]

What's wrong with X?

Fixing old code that mostly works is boring. Must Have New Shiny!

Re:Why?

[Anonymous Coward]

The things X does well (e.g. network transparency) are really irrelevant nowadays (you can just send video instead of a render command stream, it will be better) while it's underlying design makes many things we want now (e.g. smooth UI, hotplug display devices without spending 3 hours maintaining Xorg config, composited rendering, works on limited hardware) unnecessarily difficult and complicated, which encourages the proliferation of X extensions (XRandR, AIGLX), hurts the performance of the display stack, and actually break the one thing X does well (network transparency was dropped sometime around when they added Direct Rendering Manager to try and fix the X performance issues).

Re:I still don't see what's wrong with X

[Anonymous Coward]

Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?

If X, or more specifically the X.org implementation, had been written by Leonard Poettering every article would be followed by a gazillion comments whining about how it is a monolithic single point of failure (which had to run as root until very recently on many systems), it has terminal NIH syndrome (everything from ELF library loading to low-level graphics drivers to stippled line rendering), it "violates the UNIX philosophy" by doing multiple things (it's a remote display protocol, it's a input event multiplexer, it's a bitmap typeface renderer), it is not easily extensible (extending the core protocol is often not portable so GNOME and KDE etc overload scores of "window properties" to serve as a quasi-protocol), it's full of useless crud (for example, with modern toolkits the much-vaunted 'network transparency' usually boils down to sending pre-rendered bitmaps, as the aforementioned stippled line support is not considered sufficient) etc.

Of course, X11 was a gift stolen by Prometheus from the Unix gods. All right-thinking people know that it is obviously sacrosanct and even the suggestion that someone might someday be able to do better is a vile heresy. If you need to do something it doesn't support, why not glue another carbuncle of an extension onto the creaking superstructure and perform the required ritual goat sacrifice? Thus it ever was, thus it ever shall be.

Re:I still don't see what's wrong with X

[Kjella]

Except that's pretty much what all AJAX web apps do, they "export the UI through some generic mechanism" to the browser so I'd say it's very common. No need for roll-outs and patches, if the server now says there should be a new button there is a new button for everyone. The issue is that I find most web apps really suck compared to native applications so locally I usually want a native, non-web application.

What I'm talking about is a native toolkit that'd make the applications you normally use locally network transparent at the application level, not the display server level. Essentially a toolkit where the UI is always living in its own thread, asynchronously to the actual application. Network transparency just means that thread happens to be living on a different machine, drawing to a different display. And you could tweak it to handle that better, but you wouldn't have to it'd sort of run remotely without modification.

For example, I made a basic calculator just as a proof of concept. Connected locally (I still used a TCP connection just to localhost, better options are available) it looked and acted entirely as a native app you could use every day. It recorded buttons pushed, sent the push events to the back-end and sent updated display text back. I hadn't made it better, but I hadn't made it worse either. The cool thing though was that now I could connect to it remotely. Same calculator popped up, my button clicks go over the network, display text came back over the network. It's a working local native app and a working network transparent remote app. At once. Without any application logic in the client, just drawing tools.