Tidying up after Linux 16767

In comp.os.linux.advocacy, NoStop wrote on Tue, 21 Jun 2005 16:00:45 GMT

In a way. AIUI, it fires up a remote desktop display; the user then interacts with the display. Tool launches (e.g., doubleclicking on the blue "e") will be displayed within the subwindow but run on the remote system. There may be issues on what sound does; I for one can't say.

For its part X protocol can be tunneled through ssh, which has the general effect of allowing things like

which will do the following.

1 Prompt for a pbuttword, if necessary, locally. 2 Log the user into remhost, and bind a socket (because of -X). 3 Execute xterm in remhost, with a suitable DISPLAY environment. 4 xterm fires up, forks its shell, opens the proferred display (the socket opened in 2, actually). 5 sshd, the owner of the socket, proxies that request to the local system. (For details, one can look at usr-X11R6-include-X11-Xproto.h, or Volume 0 of O'Reilly's, or the X server code -- if one can find the relevant code in the X server code. :-) It's probably in an obvious place, but I've not looked...) 6 Any time xterm draws something, sshd will send that drawing command to one's local system, and thence to the local X server, which interprets it as the same drawing command. Events on the window displayed on the user's local X server will be sent back to the system running xterm, and processed by xterm's parent process. The effect therefore is a slightly slowed-down xterm (because of unavoidable propagation delay) displayed on one's local system, with commands typed thereinto running remotely. 7 Since DISPLAY is also available to xterm's child shell, any command typed into this xterm will of course have the ability to open windows on the user's local system as well.

This is a little different from rdesktop, of which I don't know the details. AIUI, however, the rdesktop daemon keeps two local bitmaps (one working, one "last known") and sends bitmap updates to the user's display system, which has a local bitmap of its own. The X approach does not use dual bitmaps as such, and is potentially far more efficient -- though it depends on how brain-dead the app is being; XImages in particular are problematic.

-- It's still legal to go .sigless.