Clearing Up Wayland FUD, Misconceptions
An anonymous reader writes "In clearing up common misconceptions about Wayland (e.g. it breaking compatibility with the Linux desktop and it not supporting remote desktops like X), Eric Griffith (a Linux developer) and Daniel Stone (a veteran X.Org developer) have written The Wayland Situation in which they clearly explain the facts about the shortcomings of X, the corrections made by Wayland, and the advantages to this alternative to Canonical's in-development Mir."
Better remoting than with X11? Seriously? I'm in!
Just recall to support authentication (certificates, kerberos, and/or ssh piping), and root windowless operation, and you will get every admin that works in corporate environments at least to test Wayland. If it manages to fulfill the promise on better reactivity (== better usability), Wayland will catch like wildfire.
Each application does its own rendering? 31-bit pixel counter?
This sounds like it's all pixels, like X, rather than geometry, like NeWS or display postscript.
So if I have monitors with high resolution I still have to tell all the applications to change their size, individually, or use a microscope to read the text, right?
If I stretch a window (intending to scale it, rather than just see more of what it shows) it has to go back to the application for re-rendering, right?
And if I have adjacent monitors with different resolutions they won't match up. Heaven help me if I lay a window across the boundary between two, the T between 3, or the + between four. Right?
Or have I missed something?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Why not fix X?
The simplest and most obvious answer: it's easier and faster to just not bother and start from scratch.
In addition, X was originally written when networks and client systems were slow(er). Many of original design decisions are no longer appropriate with respect to the X server code complexity and maintenance requirements. A long (long) time ago, I wrote a program (called CXC - Concurrent X Control) to manage the low-level X protocol (think everything in the X11 Volume 0 book) and support transparent X traffic interception, blocking, redirection and insertion for a CBT application (called CAST) and, if I remember correctly, I remember wanting to off myself (or at least start drinking heavily) after trying to make sense of it all. Just my $.02.
It must have been something you assimilated. . . .
With the release of hardware drivers for the Raspberry Pi I decided to investigate Wayland a bit further.
One thing that has confused me about Wayland is "where are all the alternate GUIs?", X window managers number in the hundreds with every man and his dog writing one.. The extremely basic GUI seen in Weston has barely changed in years.
It seems that Wayland has thrown away X's 'mechanism, not policy' mantra, and the architecture combines device drivers, the display server and the window manager into one blob (the reference one being Weston). This means that every alternate GUI needs to know how to talk to hardware, instead of just how to lay out windows and control them, it's rather laughable. At least turn the hardware support and abstracted device driving into some sort of library,. Also there's practically no documentation on Weston to use as a basis for another GUI, and the code is barely commented.
Wayland may be good, but it needs many more years of work at the current rate and still has some big issues;
1) The terrible architecture that I mention above that makes it difficult for people to build GUIs.
2) Driver support needed for running, that doesn't seem to be forthcoming from some of the biggest names in graphics cards.
3) The fact that we'll need to run X clients in Wayland for years, if not indefinately. Negating most of the arguments of "but we can throw away the crusty bits of X, hurrah".
I'm not going to discuss the X remote support issue, I think that one has been done to death :)
I've seen demos of Wayland that had per window remoting, including moving and cloning per window across different diplays. Wouldn't it be nice if xmove still actually worked for most applications? If you could just move your application across Xservers as you wished and didn't have to worry about temporary network outages killing you application? Well apparently Wayland can do that. So it seems to me that Wayland has potentially more to offer in terms of network transparency than X. It isn't done yet, so let's wait and see. Everything I've seen looks very promising.
Craft Beer Programming T-shirts
I'm not worried about it, or complaining about the difficulty of installing it, as I'm aware that I'm currently not the target audience (although the Apache comment was hyperbole). Just wondering if I had missed anything, or if the current situation really was "build xwayland or gtfo." It sounds like the answer is, "build xwayland or gtfo."
I use the networking capability of X (process on IP address X using display on address Y, same or different IP, different user) every day, all the time.
For example, I always run a X server on Windows boxes, because I can then run some Linux process on the Windows display "root" window. Productivity is higher because I don't have to switch "containers", in order to switch applications, and copy/paste is trivial.
Similarly, I can have a process in a different, more locked-down, user running on the root window of "my" desktop, toggling between applications without having "switch user", open a different VM, ...
I'll keep using X11 as long as I can.