Why does network transparency have to be a function of the display system?

Because if you have network transparency in the display system then all your applications get network transparency for free. They just talk to the display system like they always do and the display system throws them up anywhere you're connected to, as you like.

It's not a niche feature. Just because you don't need it, it doesn't mean that millions of others don't.

Even on my home network I use X11 between machines every single day. It's the simplest solution to an awful lot of problems when you're using more than one machine and it generally works much better for interactive use than remote desktop or VNC on a local network.

Can't speak for the GP, but in my case, yes.

Yes, by all means spam me now with all the arguments that claim that X11 is terrible because it's imperfect. I'm well aware it's imperfect.

But the fact is it's not imperfect enough to warrant throwing it out and replacing it with something that lacks the more awesome things X11 does. Yes, I know the counter argument here too: "Nobody uses/needs/wants the awesome things!" says Baby Bathwater. But look at what you're proposing: a tiny, inconsequential, performance improvement and possibly cleaner API, in exchange for guaranteed incompatabilities and the removal of functionality.

So, pretty please, knock it off with the Wayland/Mir shit, at least until you achieve feature parity.

Except if you have very little bandwidth it is absolutely horrible and you'd do far better with a web interface and if you have lots of bandwidth you can use VNC. The pipe between your CPU/RAM and GPU is one of the fattest pipes in a computer able to push many GB/s and when you replace that with tin cans and a string you need to do something, it's like arguing that if I replace your graphics card so the game renders at 1 FPS that it's now supported for free. I'd never, ever design a system that'd depend on X11 for remote access, would you?

RDP, VNC, and Teamviewer all present whole desktops. This is infuriating. I want the application windows to be seamlessly navigable among my local applications.

That's not to say X is perfect either. X is highly latency sensitive, particularly for things like Java GUI applications. If network flakes out, the X client dies rather than 'detaching' for someone to later reconnect. X has no concept of audio streams.

I don't necessarily want X, but I want something that recognizes the core value of application level remote display (including things like the NETWM stuff to let 'tray' icons live in the right place.) and enhance it through better audio integration, detachable operation, and better network usage (e.g. Xlib primitives are rarely used anymore, having primitives more relevant to modern usage like RDP has would be a large improvement)

The RDP "whole desktop" is entirely an artificial limitation. It actually works great on the application level, after you've shell out the bucks. So, yes, it is infuriating that MS crippled their own product.

It looks to me that Wayland developers only have one desktop at home and were Windows users that want gaming on their linux box.

- What about asynchronous rendering? fast text scrolling in a windows like "find /" or "make -j32" thru a modem connection works in X11, I'd be surprised to see the same on Wayland.
- What about single GUI App running remotely: ssh to a cluster with no network card and need to start paraview or gnuplot? Should I run a full desktop with useless fancy gadgets just to see a gnuplot window?
- What about client application that freeze: Can't move the window because the decoration is done by the client?
- Wy can't I move parent windows when a modal window is open like a file selection dialog box. How do I move the parent app to see my shell window behind. Should I do the same as in windows: close the file selection dialog box move the windows and reopen the file selection dialog box?
- What about lost event because the client is buzy? I click on the button, but the event is lost because the client is buzy.....

Wayland is just a LOL in professional environment.

Thanksfully, I'm running KDE...The original desktop that Gnome tries to imitate since it's creation...I'm curious how it's manage the Wayland migration....

Open a remote editor on a machine the other side of the world? Have it integrated with my wm?
Copy and paste between windows on different machines without the app having to provide the copy/paste functionality?
Being able to set my preferences once, and not having to reconfigure 40 different desktops to my liking?
Get the correct DPI and fonts for the display I'm on, not the one of the remote machine?
Being able to run VMs that look and function the same as when run natively?

For everyone bitching about Wayland vs X11 and network transparency, you need to watch this talk [h-online.com] by Kristian Høgsberg. Keith and the rest of the devs have always said that remoting would eventually come down the pipeline.

And for everyone else talking about efficiency of sending pixmaps via the network, you should learn how your current stack actually works. It will be much better with Wayland.

I've used X11 since 1995, I'm very fond of it. But I also realize it needs to go...

For those too lazy, fast forward to the 1:10 mark and watch. You'll realize that the remoting prototype for Walyand is pretty damn sweet.

Yes, There are fundamental differences. RDP simply works with input events and draw regions. The draw regions use pretty much any compression routines under the sun and supports the windowed regions, so moving windows around inside the container is basically free network IO, whereas VNC requires redraws over all delta regions. I'm not sure if Window border rendering is client side of not, but obviously the inner contents need to be redrawn with graphics sent back.

The real killer against X over networks is in latency, since most of X is performed with operations instead of rasters. Instead of sending possibly hundreds of commands, RDP can send a single raster to represent the same thing. The possible overhead in sending / acking / processing the operations quite often causes a large amount of time. This isn't helped by the fact that traditionally X developers didn't spend much time optimizing network performance, so you'll see a large number of libraries / apps that perform highly serial operations maximizing operation processing latency (since it needs a full round trip just to continue to the next instruction).

On a side note, there's the NX protocol which is a much more highly optimized remoteing solution for X derived services, but its proprietary, so it makes it unlikely for use in wide adoption. NX works quite closely to that of RDP/Citrix so that's why performance should be comparable.

The reality is that X works really well and has solved a lot or problems which Wayland still does not solve. Yes, some code is not used anymore in modern applications, but this code is far from huge and it is already there. Also, it has to stay here for backwards compatibility anyway, separating it out will make the whole thing even more complex instead of simplier. Of course, the long term plan of the Wayland people seems to be that this code can be removed eventually. If Linux distributions switch to Wayland soon this is exactly what will happen in the near future (and this will also happen on embedded systems). This will then effectively break backwards and forward compatibility which has been maintained for decades. Of course there will be backwards compatibility options but they will bitrot not work for new applications using new features, not be installed by default, ... So basically it would suck. Personally, I consider this one of the worst imaginable things that could happen to Linux community.

But maybe there is a really good reason to break compatibility. So let's look at the advantages: Unfortunately, there is almost none. As the Wayland people state on their homepage, everything that can be accomplished with Wayland could also be done by extending the X server: "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X". So they break decades of compatibility for no good reason!

The other thing is that Wayland is small and simple now (and X is btw not bloated at all it ran fine on machines with 4-8 MB of memory in the past), but it is only small and simple because it has ignored a lot of problems which are solved with X. Basically, Wayland started with the idea that graphics is all about moving pixels. This is nice and good, but desktop applications need a lot more than graphics, they need various kinds of integration and communication protocols. So Wayland is in the process of adding all these things back which already exist in X (e.g. the recent work on minimizing) and this is way - after years of development - it is still not ready. This is also the reason why all this "network transparency is not a problem which should be solved in the core graphics systems we just add some mechanism to move pixels over the network later" is IMHO really stupid. Moving pixels is not the problem, integrating remote applications in a seamless way requires much more. There was a summer of code project to get support for remote applications into Wayland and the developer basically gave up ("Turns out it's not as simple as I thought.").

A final comment: Linux and Unix was an OS which had huge advantages when compared to other platforms because it had really great networking features. But this was never really exploited. Instead of embracing those powerful features and making them easy to use the current trend is to make a dumb OS for the masses which basically simulates what other OS do with some different GUI. This is really sad especially because we finally reach the state where we have internet connection always and everywhere and network transparency could be the basis of really cool and innovative features (and I have an X server on my cell phone and I think this is the coolest thing ever). The idea seems to be that a mobile OS needs a nice touch UI and a power efficient OS and that notion is what drives the development in the Linux graphics world now (e.g. Wayland) and this is IMHO really short-sighted and the opposite of innovative. For me, all the graphics and GUI work of the last years (also I appreciate many underlying technological advances) went along with regression in features, lack of stability (Linux is less stable for me than 5-10 years ago for graphic problems only), and GUI experiments which have not been thought through. Instead of wobbly windows, Unity, Gnome shell (and many graphics bugs) I would have hoped e.g. for support to move windows between devices (technically this works, but there was never user friendly way of doing it).