Re: [9fans] First-timer help

["Martin C. Atkins" <martin_ml@parvat.com>]

On Mon, 18 Jul 2005 12:45:32 +0200 lucio@proxima.alt.za wrote:
> > Nevertheless, I must add that this is one reason why I haven't
> > installed Plan9 on my systems at home - there are more people than
> > computers here, and I can't lose all my context (of active windows,
> > etc), when my wife needs to check her email, or my daughter wants to
> > paint a picture....
> 
> I was thinking, when Russ suggested that the infrastructure for
> changing ID without rebooting was a possibility, that we'd lose the
> extreme reliability of the current approach.  That need not be true,
> either, as the reboot option is unlikely to go away.

The other approach, that might "just happen" without specific
development effort in Plan 9, is that if/when Xen provides graphical
screens for virtual machines, then it should be possible to run a
cpu/file server, and a terminal for each user, each on their own
virtual screen, switching between them somewhat like virtual
consoles. (Of course, in principle, I could do that today with
Vmware, if I had enough memory, etc.)

[Of course, this would mean that everything would have to be running
on top of Linux/whatever...]

> That said, a stand-alone Plan 9 device seems to need better
> specification, I'm sure a CPU server is perfectly capable of sharing
> its console to different users at different times.  But different
> logins on different windows (as Martin seems to suggest) would be more
> complicated.  I guess somebody ought to give the idea some careful
> thought and suggest an implementation.  Specially where we actually
> want the stand-alone device to be more of a workstation than a CPU
> server, yet we need local authentication and device management.

Agreed.

Allowing some form of su (as was suggested elsewhere) is very useful,
but isn't really an answer to my problem. Also the
drawterm-on-top-of-a screensaver idea (while a nice bit of lateral
thinking!) also wouldn't be very satisfactory, because the reverse
problem then occurs: we lose the context in the drawterm when going
back to the underneath "original" session (and how would it nest
further?). 

Again (I'm sorry to say): Linux virtual consoles work very well,
since all the logins are "at the same level". One can also screenlock
a session, and let someone use another virtual console, reasonably
sure that they can't fiddle with your session. (assuming the other
security mechanisms are working 'correctly')

BTW: This problem is even more acute when travelling, and we only want
to carry one laptop as a family, and carry it around with all our
personal sessions suspended.

This is the counter example for Bill Gates' infamous "your computer
should be as personal as your underwear" gaff - unfortunately, this
seems to be the philosophy for Plan 9 terminals, currently. big :-)

[Although I should reiterate that I think the situation can be quite
different in other environments - such as offices and terminal
classrooms - where rebooting makes lots of sense.]

Moving to solutions, rather than problem statements: wouldn't the
"Plan 9 way" of dealing with this be to run a multiplexer process
pre-login, that multiplexes access to /dev/draw(etc) across several
virtual consoles, and puts a login process in each one? Could that be
done with the current mechanisms? I guess it would have worked with 8
1/2, but maybe it is more difficult with the rio approach (I don't
know)? I also don't know if this is consistent with the way /dev/user
(etc) work. Comments anyone?

Martin
-- 
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}