http://www.phoronix.com/scan.php?page=article&item=wayla...
Hopefully in 2-3 months, when SC 4.9 is slated for release, we'll have KDE on Wayland. X is aging and is not very lightweight. Wayland brings some nice innovations, like eliminating the need to switch between VTs to differentiate X sessions.
The FAQ is also worth reading:
Innovations like these (if not needing to switch VTs even counts as an innovation) pale in comparison to innovations like network transparency, which will be missing at first and eventually present but crippled in Wayland.
The ability to ssh to another system, launch a GUI app, and have it display on the system you're SSHing from has always set Unix+X apart from Windows and Mac OS. I can't believe this is being tossed aside so you can have cross-fades and rotating cubes when switching between sessions.
It's true that network transparency will be possible with Wayland, but it will be some sort of VNC-like pixel scraping approach, which has never worked as well as native X forwarding. Network transparency will be a second-class citizen in Wayland.
See http://tech.slashdot.org/comments.pl?sid=2699657&cid=391... for some more disturbing problems with Wayland.
I agree wholeheartedly.
"I can't believe this is being tossed aside so you can have cross-fades and rotating cubes when switching between sessions."
I think you're ignoring most of the motives for Wayland development.
"It's true that network transparency will be possible with Wayland, but it will be some sort of VNC-like pixel scraping approach, which has never worked as well as native X forwarding."
I disagree. For example, xpra (http://xpra.org/) ships images across the wire and works much better for me than X11 forwarding over both local and remote links.
"Network transparency will be a second-class citizen in Wayland."
Just because it's not a part of the core protocol doesn't mean it won't be developed and work well. As the phoronix article says, it is under development right now.
"See [snip] for some more disturbing problems with Wayland."
That looks like trolling. A better link might be http://www.h-online.com/open/features/Wayland-Beyond-X-14320...
I know there are other motives, but it's largely about getting more pretty rendering and the fact that X has a lot of baggage. Also, I'm still shocked that the only reason on their FAQ under "Is wayland replacing the X server?" is that VT switching is "horrible."
> I disagree. For example, xpra (http://xpra.org/) ships images across the wire and works much better for me than X11 forwarding over both local and remote links.
xpra is faster for me over remote links, but native X is superior on local links, in speed, simplicity, and also robustness. X11 forwarding is super-simple and rock-solid; xpra is awkward to set up and is rather flaky. I fear that since network transparency is not a core, high-priority feature of Wayland, it will end up having a "second-class" feel like xpra does. Just because network transparency is under development right now doesn't mean it will be good. Their FAQ says it's not a high priority feature, and I've read several mailing list posts from developers that agree with that sentiment.
> That looks like trolling. A better link might be http://www.h-online.com/open/features/Wayland-Beyond-X-14320....
My link may portray Wayland in a negative light, but only insofar as yours portrays it in a positive light.
OTOH, the Sun Labs SLIM project (that became Sun Ray) found that pixel-scraping was comparable or faster than X11. http://labs.oracle.com/features/tenyears/volcd/papers/Nrthcu... (Of course NX is much better than vanilla X11, but there has also been research in screen compression since SLIM.)
For the case of network-delivered applications, we have webapps - the unholy misappropriation of HTML and JavaScript glued together to kind-of sort-of work like an actual application. It's the worst kind of remote application, except all the others.
Don't get me wrong - I don't see the point of wayland at all, but I have also never benefited from X's remote windowing capabilities.
Mac OS and Windows also have remote access solutions available which seem to be perfectly serviceable for people that need it.
It seems silly to architect the entire graphics server around network transparency when it's not a hugely used feature compared to compositing etc.
When was the last time you've actually done that?
I have large (64 core, 256 gigs of ram) servers in a university data center, and a lab full of small atom machines.
I can run matlab without a gui, but still have graphs etc pop open when I need one.
Yesterday I ran a remote Firefox on a machine in the same room so that I could play sound on attached speakers, but still view the video locally, on my laptop.
Sometimes I need to run expensive applications on a big machine, but from the comfort of my home or office. X11 forwarding is pretty nice for that.
I run headless Linux VMs on my mac, and ssh to them, running them natively displayed on my laptop. Sure, I could use whatever VMware gives me to display apps, but X11 works better.
It's got plenty of valid use cases, and that's just ones for me.
Network security admins allow only a port 22 binary connection to an inner enclave of protected machines, protected by firewall. I need to admin those machines, sometimes with gui apps. ssh -X to the rescue.
Why do you need X11-apps from multiple(?!) local linux VMs on your desktop?
What GUI-app other than matlab do you need to run remotely?
Exporting X11 windows from multiple VMs on localhost? X11 forwarding Firefox to access remote speakers? Seriously?
Yes, there are niche scenarios where nerds still use X11 for useful hacks like that (myself included), but the discussion is about the future display architecture for the proverbial linux desktop.
X11 has been a ball on a chain here for a really long time now. Use-cases such as "too lazy to open a matlab pool" or "splice firefox audio" are not exactly a convincing counterweight.
I'll gladly trade in my ability to run a remote gnuplot every once in a blue moon for a desktop experience remotely comparable to OSX or Windows.
Bringing these examples up as scenarios that must be considered in the design of the future linux display system seems... well, contrived to me.