Le 19/07/2016 16:03, Simon Hobson a écrit :
Didier Kryn <k...@in2p3.fr> 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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
