Le 19/07/2016 16:03, Simon Hobson a écrit :
> Didier Kryn <kryn@???> wrote:
>
>> I guess this is exactly what "multi-seat" means: severall keyboards and severall grapical cards connected to the same host. It certainly does not include serial terminals. Serial terminal fall in the category "multi-user", like ssh connections, not "multi-seat".
>
> I disagree there. In the context of "graphical consoles" being discussed I see where you are coming from, but serial terminals are just a sub class of multi-seat - while the "multiple graphics card-keyboard-mouse" setup is another sub-set. The key difference is that there is a long historyof multi-seat via serial (and more recently, network) terminals and (forexample) the serial etc systems inherently support multi-seat.
> The way the problem is solved for serial terminals is simple - abstractthe hardware into a stable device API, and run multiple instances of the"login" program (one per seat). "In theory" the same should be possible with the graphics-keybourd-mouse combo - EXCEPT that (AIUI) the software components involved were mostly written a) without that standard abstraction and b) without regard to the possibility of multiple instantiations.
> Just think how easy it musty have seemed at one point to just "intertwine" the software and hardware such that a single instance of "something" acted as the sole gatekeeper between the serial line and the machine - for a single seat. There'd then be discussions on how to work around that to enable multi-seat. As it happens, the serial line one was such a "no brainer" given how many different things used the serial lines - the solution we have must have seemed so obvious from the very beginning.
>
I don't understand all your explanations, sorry :-) . I understood
the concept of "seat" as the combo you describe (graphics-keyboard-mouse).
If the concept of "seat" includes serial terminals, I see no reason
to not include remote logins: until the middle of the 80's, serial
terminals could be far remote, by the means of modems, and,
conceptually, this isn't different of a telnet connection. If multi-seat
involves all that, then the concept is not relevant in this discussion.
Which is relevant is wether the user can push the shutdown button of
the DM or "send" ctrl-alt-del, and neither serial terminals, nor remote
sessions can do that - except, possibly remote graphic sessions through
XDMCP.
To come back to Slim, why should it behave differently of wtfdm and
ask a password to halt/reboot? It makes no fundamental difference wether
this is obtained by clicking a button or by entering a special text in
the login window.
Didier
::
Re: [DNG] F1 and special usernames …
