←back to thread

X and NeWS history

(minnie.tuhs.org)
177 points colinprince | 2 comments | | HN request time: 0.415s | source
Show context
jandrese ◴[] No.15325477[source]
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.

replies(5): >>15325577 #>>15325788 #>>15326024 #>>15327449 #>>15329716 #
JoshTriplett ◴[] No.15325788[source]
> 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).

replies(6): >>15325815 #>>15325972 #>>15326464 #>>15327043 #>>15328455 #>>15330839 #
lscotte ◴[] No.15325972[source]
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.
replies(4): >>15326013 #>>15326239 #>>15327054 #>>15327220 #
1. rhizome ◴[] No.15326013[source]
Like in DLNA, which repeatedly confuses-slash-aggravates me for no good reason.
replies(1): >>15328491 #
2. efreak ◴[] No.15328491[source]
Except that DLNA has that third controller role that's usually taken over by either the client or the server, plus the confusion added by openhome servers with playlists (made even more confusing/annoying for me, since mine is provided by a fourth service/proxy, BubbleUPnP).

Standard DLNA is easy to remember, however, as long as you know the terms--[file]server, renderer, and controller. It even uses http for the fileserver (not sure if that's part of the standard or not though)