That's a seriously awesome piece of work. I'm sure it could be used for more things than demos.
X11's client-server model is seriously underappreciated, and the continuing efforts to make X behave exactly like Microsoft Windows frequently forget about network transparency.
Conversely, trying to make X behave like Microsoft Remote Desktop is often unreasonably painful. I've not yet seen a nice solution for detaching and reattaching X applications like screen(1)
It's fake in a lot of ways, especially in its input model. It's well-commented and designed as a codebase to learn from, not as a real implementation of an X server that's reusable.
Unfortunately, while it appears to run just fine under Safari, the window inspector is broken. It's not vertically splitting the area and putting the attributes on the right; it's horizontally splitting and putting the attributes below the window list, except there's no room to see any of the attributes like that.
It seems a real shame for the layout of the window inspector to be the only compatibility issue with Safari. Any chance you can get that fixed?
Actually, it turns out it's not even working right under Chrome either. The inspector isn't tall enough to show Properties, and it's not scrollable, so all I see is the "Properties" header with nothing under it. Here's what I'm seeing:
I don't think X11's network transparency is useful at all nowadays. RDP and VNC give much better results.
And yet every single time someone brings this up, plenty of people chime it that it is useful, because they're using it. Unless RDP and VNC have fixed their performance problems and don't break UI flow by putting the whole remote desktop in a separate window (instead of making windows for remote apps seamless), then many would contend that RDP and VNC don't give better results.
And yet Wayland keeps steamrolling over these objections. Oh well, at least they finally admitted that network support isn't just some useless toy that can be added on later, "if anybody even uses it".
> Unless RDP and VNC have fixed their performance problems
They are both much, much faster than X11. X11 has higher latency and uses significantly more bandwidth.
> by putting the whole remote desktop in a separate window (instead of making windows for remote apps seamless)
Many of the things that make modern desktops nice (like client-side decorations) make it hard to merge remote and local windows. It's not impossible (witness VirtualBox's attempt), but there are peculiar corner cases if you want to make it generic across platforms.
If you want a modern desktop that's fast on modern hardware (arguably its primary purpose), remote desktop will have to work RDP/VNC style.
I do 99% of my development in the office in an eclipse instance running on a remote server connected via LAN. It's completely seamless, you would have absolutely no way of knowing that it's not running locally. Having never use RDP, I can't rule out it's as good; I don't see how it could be better. VNC is laughably bad in comparison.
For working from home, we've got NX. Again, it mostly just works; I can't really tell that it's a non-local window. Again, I can't rule out though cannot imagine RDP does it better; some amount of latency is unavoidable via WAN; VNC would be excruciating.
This setup has been working fine for about 6 years now, btw.
I am also using NX (specifically, Nomachine's NX, an older version before they replaced everything with proprietary crap.) Right now for Linux, I think it is still the best thing going. I use it in full desktop mode, as if it were a VNC or RDP session. Offsite, there's very little latency or artifacting. Onsite, as you say, it's nearly indistinguishable.
They are both much, much faster than X11. X11 has higher latency and uses significantly more bandwidth.
In my experience, this hasn't been the case. Running Emacs via X full screened across two monitors (both at 1920x1080) is much snappier than running VNC from a Windows box, single screened, lower resolution (can't remember exact numbers just now) and lower BPP. Of course, that could just be the typical disparity in IO performance between Windows and Linux.
And while I grant that X sessions can't be detached by default, there are solutions for that (see XPra further up thread). There's also been compression for X quite some time. On top of all of this, you don't even have to be running an actual GUI on the serving end; can the same be said for RDP and VNC? Or Wayland?
If your concept of "network transparency" is "remote desktop", then you're undoubtedly right. But that's not the only use case for X11 (or even the one it was developed for). Many of us are just fine pushing an individual app back to our display without having to load up VNC.
I can understand and emphasize with the feeling that X is way too crufty and needs a re-write; and I know I've done jack-all to contribute (haven't had the time); but I wish that the lessons of history wouldn't be so quickly forgotten and people might ask themselves why X has hung on so long and is so beloved.
I realize that the Wayland developers worked on X, and recognize their expertise and hard work. I have high hopes for Wayland! But I also chose Linux because it doesn't lock me into options (like one window manager), and it's just so gosh darn flexible I can use it for everything from embedded systems to servers, smartphones, clusters, supercomputers and desktops, all being able to export GUI apps in individual windows, without them having to be specially written, even if the sending side doesn't have a graphics card. To lose that would be disappointing to say the least.
I wouldn't use "beloved" to describe X, not when even its developers say "it's time to switch to Wayland".
As for Linux and choice, its desktop market share is barely above statistical noise. Platforms which limit choice, such as Windows and Mac, are much more widely used. This is because, as it turns out, consistency is preferable to choice when developing a platform. It makes it easier to run new desktop apps, it makes software integration easier, and it even makes requisitioning IT or devops personnel easier because their skills more readily translate between jobs and environments.
So the chaos of development in the 90s is settling into a focus on a few well-supported software components. This includes systemd for the startup daemon and Wayland for the display server. Everything else will be in semi-legacy status, and you will see brokenness or limited functionality in other software if you stray from the community-accepted path.
Welcome to life with a mainstream, modern operating system.
"No network transparency" is still true of the Wayland protocol. However, compositors (such as Weston) can forward windows over the network. I think this is where most of the confusion comes from.
There's a very big difference between network transparency and remote display. The FAQ is misleading about this, though. It's long needed an update. Perhaps I'll get to rewriting it one of these days.
The absolute curbstomping of the rest of the Unix workstation market by Mac OS X should put the lie to the notion that network-transparent display is in any wise essential. Beautiful, pixel-perfect, tear-free GUIs are much more important.
And anyway, even if you need remote display, network support isn't necessary in the core protocol. You can get networked display by having a Wayland compositor that runs on the remote end and communicates with a Wayland client on the local end in any number of better-than-X11 protocols: rdp, vnc, frickin' streaming h.264. And remote apps don't even have to know that they're being displayed remotely.
>> ...should put the lie to the notion that network-transparent display is in any wise essential. Beautiful, pixel-perfect, tear-free GUIs are much more important.
OSX comes pre-installed with an X server, which should put the lie to the notion that you can't have both. I don't know my way around this issue at an extremely low level, such as if I'd worked on the guts of an X server; however, I'm perfectly able to believe that video hardware has evolved capabilities that X11 just can't support properly. It also seems somewhat dubious that the subsystem that provides access to the video hardware needs to be coupled to a network protocol. It seems like, in principle, you could layer one atop the other and get the same -- or better -- result. Now, if GUI applications weren't forced to deal with X, then client support for X might start to erode as applications chose to go around it. But, how bad would that be? Is preventing it worth the opportunity cost?
OS X no longer comes preinstalled with an X server. Most Mac users are capable of getting along perfectly fine without it -- even developers. And anyway, X11 apps in Mac OS X are like weeaboos on the streets of Tokyo: no matter how earnestly they try to assimilate, they stand out like sore, awkward thumbs and obviously don't belong there.
If you want to develop beautiful apps on the Mac platform you use Cocoa -- not X. Apple decided against basing its graphics stack on X11 for sound technical reasons.
>> Apple decided against basing its graphics stack on X11 for sound technical reasons.
and even still, X runs on OSX just fine, AFAIK (please correct me if I'm wrong -- anyone). The X server could stand to have been a little more seamlessly-integrated into OSX from a usability standpoint, IME. But from a purely technical perspective it seemed to be fine.
In fact, they have fixed it. Well, RDP has; I don't know what the state of the art is for VNC implementations. Microsoft's "RemoteApp" does exactly what you describe.
It is when you have a networked device that speaks X protocol. They were common in the 90's for test equipment and many are still useful today. These sort of legacy devices can't use newer alternatives.
I should really do a Show HN of my X11rdp-o-Matic script, which automatically builds and installs X11rdp/xrdp from the github repo - it's been in existence for 2 years and I update the script(s) with enhancements from time to time.
xrdp and the X11rdp back-end X server is in constant and full development, with an actual Xorg module being worked on as well.
I love xpra and used to use it every day (using a Mac laptop now and haven't figured out how to make xpra not suck on it w.r.t. modifier keys and dock / cmd-tab support).
A big problem with xpra in myind is that the wire protocol doesn't even try to be version independent. If you're using slightly different versions on client and server, it just falls down.
If you're using distro packages this is fine e as long as all clients and servers are similar enough to have overlap in the versions that they package. Otherwise you're building from source on every client and server, on various platforms.
