Re: [TUHS] X, Suntools, and the like

I think the main difference being discussed here is 3 approaches to remote logins: (1) the user has a single login session, effectively a console, and can connect to it/view it/interact with it from anywhere (2) the user creates a new login session whenever they connect to the server from a new station (or separately from the same station) (3) the user has a local GUI console and login session, but windows can be created in it that connect to remotely running apps I would say that VNC, RDP are cases of type (1) whereas standard X remoting (where a display manager runs on a diskless client, say) is type (2) and "ssh -X" type X remoting is type (3). Ignoring type (3) for the moment, I would say these approaches have the following advantages/disadvantages: - (1) is failsafe to dropped connections, etc, where (2) is not - (1) is helpful for remote assistance since multiple parties can view or interact with the desktop, where (2) is not - (2) should be IMO more efficient since all context is maintained in the terminal and the running applications can store stuff in offscreen memory, invoke complex drawing primitives, etc, where (1) lends itself more naturally to doing the drawing operations locally and then sending bitmap "patches" to the changed areas of the screen (this is what gives it the failsafe nature and also why apparently some people see it running faster, because of bitmap compression) - (2) is more powerful and scriptable IMO since a new session doesn't hurt or depend on any other session, it seems more unix-like considering how we use ssh and subshells and so on, basically multiuser facilities being used single-user, whereas the type (1) IMO seems limited in scalability and might also run into performance problems with super high resolution displays, or lesser hardware that can't compress bitmaps quickly. Types 1 and 2 have a direct analogue to console terminal sessions: (1) is where the user runs "screen" (or something like "nohup") whereas (2) is where the user does an "ssh" to the server causing the sshd to fork a new session. Personally, I think the type (2) should be extended to handle the use cases of type (1) since I believe it is more efficient for context to be stored in the terminal and drawing operations carried out there. So the ideal way I believe to handle these cases in a "new generation, de-bloatified X" would be to provide an optional utility like "screen" which caches any state which has been sent to the terminal, keeping dirty flags etc to indicate whether such state has also been forwarded onto the real terminal, and re-generate the protocol and all drawing commands having sent any dependencies such as offscreen bitmaps first. That way, you could have a type (2) system, but log into shared sessions and/or re-log into dropped sessions, migrate sessions and so on. But since the "screen" like program would be a separately installed, optional package, it wouldn't impact on the simplified base system unless you wanted this function. cheers, Nick On Fri, Mar 17, 2017 at 10:29 AM, Robert Swierczek <rmswierczek(a)gmail.com> wrote: