3 ms·

no, you are right most software which did support network transparency in a way similar to what X11 started out with has giving up on it (like in the industry

no, you are right most software which did support network transparency in a way similar to what X11 started out with has giving up on it (like in the industry as a whole) and there seems to be a clear technical consensus that it's best to not to approach remote access this way, even in X11 it was kind of semi-abandoned long before X11 was semi abandoned (from developers not from people using it) As far as I can tell from the POV of the discussion of weather Wayland (or any other hypothetical replacement) needs to support it the answer always had been a clear "no it doesn't need to, nor should it try to". This doesn't mean that you can't have remote shared applications, desktops, screen sharing or similar just not using network transparency. I.e. not by pretending the things the application communicates with (compositor, GPU, etc.) are on the same computer and "transparently" routing (part of) them to a different computer. And if you consider the stark difference in latency, reliability and throughput between a Unix pipe/speaking to a GPU over PCIe and TCP over Ethernet it can feel surprising that it was ever considered to be a good idea (but then when X11 was build network transparency was just that big think people put into everything, from most of which it is removed by now). So what replaces network transparency (and did replace it in many cases long before Wayland was relevant) is typical remote desktop functionality. I.e. and additional application will grab the mouse/keyboard input on one side and the rendered output on the other side and sends them to each other. This has many benefits both for the people not using it and the people using it while many of the drawbacks often practically do not make much of a difference anymore. The main issue is if there is a high quality open source for free program you can use and if it's installed on the system where you want to use it...

erik_seaberg 3y ago
A server in a datacenter generally doesn’t have a GPU, certainly not enough to support thousands of clients (each of which does have a GPU plugged right into one user’s monitor). Software rendering is a regression that didn’t need to happen, and Javascript apps seem to be the way the industry is avoiding it (with the browser as a remote display server).
- esarbe 3y ago
  I'm not sure about your use case here. Why would a server in a data center need to render the GUI for thousands of clients?
  - dale_glass 3y ago
    Virtual desktops on demand with thin clients. Sometimes because you want users to be able to change workstations, sometimes because you want a highly specific environment outside of the user's control (it can reset on each connection), sometimes because you want nothing to be kept locally. Eg, the country somebody works in is untrustworthy, so they access everything somewhere remote and safe.
    - dathinab 3y ago
      virtual desktops on demand tends to be run on servers with GPUs and in general prefers server side GPU rendering because it's meant to work with any client which can access it even if it's has an extremely weak GPU and if you have no complex rendering requirements then often it's a much better choice to place the network gap in the GUI toolkit instead of the DM as this tends to work way better, in this case you do need a thin client on the other side, but so do you need for X11 remote (the client needs to run X11) so it's kinda not that difference. And today the easiest way to ship thin clients happens to be JS/WebGPU, which is how we have stuff like GTKs webrender backend.
- jcranmer 3y ago
  > Software rendering is a regression that didn’t need to happen Actually, it is. The actual straw that broke the X developers was font metrics, IIRC. Essentially, if you want to support fonts for the language of the most populous country on Earth, you need to do more or less complete font rendering to answer questions like "how long is this span of text going to be" (so that you can break it). And the X developers tried to make it work with the X model, but the only way they could get it to work well was to have the X server ship the font to the X client and the X client ships rendered bits back to the X server [even over the network!].
- 3y ago

erik_seaberg 3y ago

A server in a datacenter generally doesn’t have a GPU, certainly not enough to support thousands of clients (each of which does have a GPU plugged right into one user’s monitor). Software rendering is a regression that didn’t need to happen, and Javascript apps seem to be the way the industry is avoiding it (with the browser as a remote display server).

esarbe 3y ago
I'm not sure about your use case here. Why would a server in a data center need to render the GUI for thousands of clients?
- dale_glass 3y ago
  Virtual desktops on demand with thin clients. Sometimes because you want users to be able to change workstations, sometimes because you want a highly specific environment outside of the user's control (it can reset on each connection), sometimes because you want nothing to be kept locally. Eg, the country somebody works in is untrustworthy, so they access everything somewhere remote and safe.
  - dathinab 3y ago
    virtual desktops on demand tends to be run on servers with GPUs and in general prefers server side GPU rendering because it's meant to work with any client which can access it even if it's has an extremely weak GPU and if you have no complex rendering requirements then often it's a much better choice to place the network gap in the GUI toolkit instead of the DM as this tends to work way better, in this case you do need a thin client on the other side, but so do you need for X11 remote (the client needs to run X11) so it's kinda not that difference. And today the easiest way to ship thin clients happens to be JS/WebGPU, which is how we have stuff like GTKs webrender backend.
jcranmer 3y ago
> Software rendering is a regression that didn’t need to happen Actually, it is. The actual straw that broke the X developers was font metrics, IIRC. Essentially, if you want to support fonts for the language of the most populous country on Earth, you need to do more or less complete font rendering to answer questions like "how long is this span of text going to be" (so that you can break it). And the X developers tried to make it work with the X model, but the only way they could get it to work well was to have the X server ship the font to the X client and the X client ships rendered bits back to the X server [even over the network!].
3y ago