SoylentNews is people
SoylentNews
Chris Siebenmann over on his personal web page at the University of Toronto writes about X networking. He points out two main shortcomings preventing realization of the original vision of network transparancy. One is network speed and latency. The other is a too narrow scope for X's communication facilities.
X's network transparency was not designed as 'it will run xterm well'; originally it was to be something that should let you run almost everything remotely, providing a full environment. Even apart from the practical issues covered in Daniel Stone's slide presentation [warning for PDF], it's clear that it's been years since X could deliver a real first class environment over the network. You cannot operate with X over the network in the same way that you do locally. Trying to do so is painful and involves many things that either don't work at all or perform so badly that you don't want to use them.
Remote display protocols remain useful, but it's time to admit another way will have to be found. What's the latest word on Wayland or Mir?
Source : X's network transparency has wound up mostly being a failure
(Score: 3, Interesting) by KiloByte on Saturday February 10 2018, @11:25AM (4 children)
In the previous millenium, we played Quake from four IRIX boxen ssh-ing into a single Linux server. With the default window size (320x240), the window was pretty small but framerate quite playable. I imagine that two decades later, there shouldn't be any issues with sending fully rendered frames over the network.
Ceterum censeo systemd esse delendam.
(Score: 5, Interesting) by TheRaven on Saturday February 10 2018, @12:13PM (2 children)
Once X.org gained AIGLX support (proprietary X servers from companies like Sun and SGI had supported it for ages), it became quite feasible to run GLQuake over a LAN with little latency. The textures were all cached on the display server (client in not-X terminology) and rendered there.
sudo mod me up
(Score: 3, Informative) by maxwell demon on Saturday February 10 2018, @12:43PM
Wrong. It is the client only in the terminology of the clueless. You do not really want to tell me that my terminal window, my browser, and any other graphical program are servers that are contacted by the X client in order to provide the service "give me something to show", do you? No, it is all those graphical programs that contact the X display server which is the one managing the resource (the display).
Remember: "Server" does not refer to where the machine running the code sits (and BTW, for X in many cases both the server and the client run on the same machine anyway). It refers to which program provides a service (in this case, access to the display), and which program requests its services (in this case, the GUI applications).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by KiloByte on Sunday February 11 2018, @12:59PM
It was before GLquake, so pure software rendering only. You're right about OpenGL, though.
Ceterum censeo systemd esse delendam.
(Score: 3, Interesting) by turgid on Saturday February 10 2018, @02:38PM
There's a cool thing called VirtualGL [virtualgl.org] nowadays that lets you render on remote GPUs and display on your local workstation (or any other on the network). It's a bit fiddly to set up but it works really well. It's very handy if you have a farm of shared workstations with GPUs to share.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].