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:Not Invented Here

[bluefoxlucid]

Pretty much. "Mouthpiece for Canonical: Canonical-made System Better than Stupid Other System."

Site broken

[DoofusOfDeath]

It appears to be Slashdotted. Someone's got to show them how to use IIS!

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

[Lilith's Heart-shape]

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

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

[N7DR]

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

I taught myself X from scratch last year. I didn't find it hard at all. In fact, I found it a whole lot easier than either of the fancy modern GUI toolkits that I looked at first and tried to use to implement the project I was working on.

Out of desperation born of lack of progress over an extended period, I thought I'd take a look at X. And suddenly it became easy to get the interface to behave *exactly* the way I wanted instead in somebody else's idea of what I should want.

And the documentation was complete, correct, and easy to follow. I didn't have to keep asking people for help (often, with no resolution). In a word, both the documentation and the code for X are mature. Which I submit beats bleeding edge every time if you're trying to build something robust.

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

[mrchaotica]

It's not like 10 years ago it was enjoyable either to use a dumb terminal, and quite frankly I doubt it's improved (I think they were SUN dumb terminals connected to something I can't remember). These days you're still going to compete over resources over a extremely high latency link (relative to computer performance). Not to mention the increased use of graphical elements in the UI.

It's worse... these days we're making our dumb terminals using AJAX.

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

[jbolden]

Seriously, what's so broken about X?

There are 3 situations involving applications, networking and graphics
a) Running an application on a machine sharing ram with the video card.
b) Running applications on a machine close enough to the video card that the latency between them is lowish and the bandwidth is plentiful and performance is irrelevant.
c) Running applications on a machine where either the latency is high or the bandwidth is limited
X11 does terrific for (b) in exchange for damaging (a) and (c). X11 was designed in a world where (b) is common. In today's world (b) is uncommon.

Other issues:

1. The mixing of signed and unsigned coordinates causes problems both in the protocol, where 3/4 of the coordinate space is often unrepresentable, and in the C language bindings.
2. The X protocol is asynchronous for efficiency: in general, neither the server nor clients wait for replies. But the protocol’s synchronization mechanisms are insufficient, and leave many unavoidable race conditions.
3. The X protocol attempts to be policy-free and tries not to dictate any particular style of window management. However, some desirable window manager features cannot be implemented correctly, because there are window attributes which the window manager can neither fetch nor monitor.
4. The X protocol provides visibility notification events so that clients can avoid computation of obscured window contents. However, this notification doesn’t work well for nested windows or for windows with backing store.
5. None of the several ways that an application can implement interactive mouse tracking of crosshairs, bounding boxes, etc., allow both efficiency and correctness.
6. Popping up menus and dialog boxes is slow because it requires too many round trips and generates too many events. Repainting when portions of a window become visible is often slow.
7. Exceptional conditions are poorly handled. Faulty programs can freeze the server, and clients cannot kill queued requests if the user doesn’t want to wait for the server to finish servicing them.

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.

Re:Full Disclosure: M-Saunders works for LinuxVoic

[geminidomino]

Follow the link? What are you, new?

Re:Why?

[0123456]

What's wrong with X?

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

Quite

[Viol8]

Wish I had mod points. Canonical arn't really interested in Linux or unix in general other than how it can ultimately make them money. Its a means to an end and if that means dropping 30 years of experience because it doesn't quite suit them then they will.

X is far from perfect but its the unix display standard and it isn't going anywhere anytime soon. If canonical want to go their own way then they'll find their user base dropping away even further.

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).