X and NeWS history

The comment about how X is really just a distributed database system with occasional visual side effects that could be reduced down to 10 or so API calls gives us a glimpse as to what life could have been.

It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me. I hate how much of a hack Remote Desktop is on Windows machines.

> It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me.

I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.

Classically, the X protocol kept a huge amount of state on the server, and clients would just send small requests to manipulate that data. Drawing would take place server-side, and it was relatively simple drawing at that, since UI needs were fairly modest. Text rendering occurred on the server with small strings sent from the client. And overall, it made sense to send a small amount of data to produce a large amount of graphics.

These days, however, rendering occurs almost exclusively on a combination of the client and the GPU. Everything takes place via large memory buffers, and compositing. And pushing those over the wire doesn't work nearly as well; if you're going to do that, you need protocols designed for it, with compression and delta-encoding, much like modern video codecs (but optimized for remote-desktop).

So I think it makes sense that network transparency is being rethought, in favor of protocols that look a lot more like remote-video (and remote-audio).

People not familiar with X reading the above (which is correct) might miss that client/server is reversed from the way most people think about it. For X, the server is the system where the display/keyboard/UI is physically attached and the client is the host (remote host for this discussion) where the application is actually running.

I don't know why this is confusing to people, at least if they understand sockets. The display server does listen(2). The application does connect(2). Why is that hard?

Windows and Mac use similar terminology to "display server" too, but I guess those are proprietary components that few people look into...

I understand sockets and I understand how X works, and I think it's confusing and stupid. It places unnecessary emphasis on an implementation detail that is unimportant to the end user.