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!

Re:Site broken

[NotInHere]

from the archive.org headers (X-archive-orig-server), I can tell its cloudflare-nginx they use. What wonders me, as cloudflare prevents slashdotting??

Why?

[sexconker]

What's wrong with Wayland that Mir fixes?
What else does Mir bring to the table that would make people use it over Wayland?
What is preventing Wayland from improving over the next 2 years?

If you want people to click on, read, and discuss articles, Slashdot, you should have articles worth clicking on, reading, and discussing.

I read TFA. Nothing in it answers the questions I have, not even the answer to the same fucking question that the interviewer had.

So that’s looking at Mir in relation to X. The obvious question is comparing Mir to Wayland – so what is it that Mir does, that Wayland doesn’t?

This might sound picky, but we have to distinguish what Wayland really is. Wayland is a protocol specification which is interesting because the value proposition is somewhat difficult. You’ve got a protocol and you’ve got a reference implementation. Specifically, when we started, Weston was still a test bed and everything being developed ended up in there.

No one was buying into that; no one was saying, “Look, we’re moving this to production-level quality with a bona fide protocol layer that is frozen and stable for a specific version that caters to application authors”. If you look at the Ubuntu repository today, or in Debian, there’s Wayland-cursor-whatever, so they have extensions already. So that’s a bit different from our approach to Mir, from my perspective at least.

There was this protocol that the Wayland developers finished and back then, before we did Mir and I looked into all of this, I wrote a Wayland compositor in Go, just to get to know things.

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:Why?

[Uecker]

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)

No, network transparency is much more than sending pixels. It is full integration: cut&paste, window management, client to client communication etc..

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,

I do not think this is true. The underlying design of Wayland is basically the same as X: Sending messages over a socket and some buffer sharing.

which encourages the proliferation of X extensions (XRandR, AIGLX), hurts the performance of the display stack,

Why does it hurt performance?

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

This is complete bullshit. X network transparency works perfectly fine still today. I use it every day. Yes, you cannot use direct rendering over the network. 99% of all applications do not care.

Where does all the FUD come from?

Re:Full Disclosure: M-Saunders works for LinuxVoic

[Anonymous Coward]

He's even the author of the linked article. When you follow the link, you see it. I think that's disclosed enough?

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

[morgauxo]

"Wayland is exactly as network-transparent as X11 is in actual use these days: not very but you can make it work. Everyone is pretty much asking X11 for a drawing canvas, drawing on it, then giving it to a compositor to display. See above comments about beautifully anti-aliased fonts."

From the perspective of a low-level programmer working on Xorg and/or Wayland this is probably true. They certainly say it enough. As a user I'm not even entirely sure what a compositor is. However, I can create an X terminal in a few minutes by just doing a bare-bones Debian install with X but no desktop manager. Then a quick rc script edit makes it automatically start X and connect to my XDMCP server. From that point on all I have to do is hit the power button and I have the illusion of being at my main desktop PC. I don't really care how X is or isn't making this happening so long as it works!

Knowing nothing about compositors, 3d or 2d APIs or the source code of Weston how the hell will I do this when Wayland has replaced X? Do I have to learn write my own compositor? I already do aplicaiton programming for a living but when these Wayland guys talk I have no idea what the hell they are going on about. What will I have to learn to make Wayland work remotely? Where would I even begin?

Or.. until the applications I want to run no longer support it I can just keep using X. But what then?

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?

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.