For someone not familiar with this world, what is X Server and xfree86? What problem does it solve?
XFree86 is a specific X server implementation, though it has been superseded by X.org sometime around 2004 due to a license change from the MIT license to the 4-clause BSD license, which is incompatible with the GPL. X.org is by far the most dominant X server implementation in the free open source software community, but it is not the only implementation; off the top of my head there were proprietary X server implementations for SunOS and NeXT.
My understanding is that the scene for the fork had already been set by the time of the relatively late license change. I seem to recall reading at the time that the XFree86 core team was unhappy that a sole contributor was attempting to modernize the system by introducing extensions, without building consensus around them to their satisfaction.
So the license change was meant to prevent forks from merging in further work on XFree86.
Of course the fork was adding functionality everybody wanted. So the fork survived and upstream languished.
This is a kind of odd retelling/interpretation of events, considering the “rogue” contributor version is the only one that lived and XFree86 is history.
They envisioned a world in which they needed license changes to block the fork from stealing all their work... And worthwhile contributions from their side did not materialize.
Spurred by this discussion I read this old email thread linked by Wikipedia: https://web.archive.org/web/20030821073445/http://xfree86.or...
This is a year before the license change I think?
You will note that Keith is directly blamed for the fork and undermining XFree86. It sounds like there is also resentment for how XRENDER was done, also driven by Keith, but it would seem with more cooperation within the project. We know that the fork was the victor in history and XFree86 looks unreasonable to most observers but I was merely trying to accurately convey the other side in the dispute, without taking their side.
It does seem like there were a bit of tensions between "Linux on the desktop" types (driven by end user visible features and represented by the fork) and more conservative "old hand at X" types present in the thread, resisting such changes, maybe sometimes for good reasons and sometimes for bad. Though when I google around, it seems Keith and others were active in X before the rise of Linux.
It has a long a storied history. The concept of running an app remotely and use a local display server is probably the thing that sets X11 apart from the rest of the pack. This is still really useful in my humble opinion -- I can run X11 apps (e.g. xv) on a headless EC2 server running Linux in the cloud and have the UI/display on my Mac (using Xquartz).
This story runs in parallel with the history of Unix itself.
However, regarding remote setups, is X forwarding significantly superior to using something like VNC? I've never done a side-by-side myself, but most of what I've read indicates that VNC is usually faster.
As a semi-experiment, a few months ago I decided to try running Firefox in a Linux VM, and render it in XQuartz on my Mac host. The experience was not pleasant, to say the least. And that's what I'd think to be the best-case-scenario for latency. Hard for me to imagine using it over WAN.
The more interesting comparison between X forwarding and VNC is that X is really only displaying a remote application locally, not an entire screen or desktop. (Unless you use xnest to run X inside X which is pretty cool.) I used to have a FreeBSD workstation with a browser window running on a Linux server and a bunch of terminal windows spun up on different Sun servers, and you couldn't tell the difference between your local and remote windows. Remote windows are first class citizens in X11.
OTOH, the big strength of RDP is the async stream requests. This gives it a much lower apparent latency than X, but it can also do the VNC thing and render/compress parts of the UI on the remote machine.
XFree86 is a free software implementation of the X Window System.
The whole server/client thing is a bit outdated now, since almost nobody uses actual thin clients anymore. X forwarding is useful, but it's not a mainstream way to do your computing.
Sun also tried to get into this game early with the JavaStations. But they were ridiculously slow, so painful to use. In fact they kind of ruined Java for me. I was learning it at the time, and we got a JavaStation on loan from somewhere. Working on it just established this "Java = slow" feeling in my head and really put me off so much I went to do other things.
Of course this wasn't really deserved, and Java has gone on to become powerful (though I still consider its poor intra-version compatibility an issue). But I've never been able to quite shake that feeling.
The one place that X could use some updating is all the sync method calls, that unlike RDP become quite slow if the network connection has any real latency.
I wouldn't say the one place, but it is a pain point.
(And actually, many of the supposedly synchronous things are not synchronous at the protocol level, but at the C library binding level -- xlib. Nowadays there's a much closer to the protocol binding: libxcb.)
+----------------+ +----------------+
| Client +---->+ Server |
| | | |
| +-----------+ | | +-----------+ |
| |X Server +<---------+Application| |
| +-----------+ | | +-----------+ |
| | | |
+----------------+ +----------------+