Slashdot Mirror
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.
He's even the author of the linked article. When you follow the link, you see it. I think that's disclosed enough?
from the archive.org headers (X-archive-orig-server), I can tell its cloudflare-nginx they use. What wonders me, as cloudflare prevents slashdotting??
Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?
You might seek out some of the tech talks given by Wayland developers. They lay it out pretty clearly.
Here's a good one: https://www.youtube.com/watch?v=RIctzAQOe44
From memory, X11 is full of cruft that no longer makes sense. Everyone wants beautifully rendered, anti-aliased fonts, but X11 not only doesn't give you that, if you comply with X11 you can't do that.
Wayland took a look at how X11 is actually used, today, and throws away the cruft that nobody uses anymore. Also Wayland adds a sane API versioning system.
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.
My favorite comment: "Everybody says the UNIX way is small programs that do one thing well. What is the 'one thing' that X11 does well?" He pointed out that at one point X11 had a print server embedded in it (it wasn't a good idea).
TL;DR Several of the top X11 developers think Wayland is a very good idea.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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?
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.