From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 19 Jul 2005 11:31:53 +0530 From: "Martin C. Atkins" To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] First-timer help Message-Id: <20050719113153.6a05a689@localhost.localdomain> In-Reply-To: <51b0ef71c372ee08703b4bd20017417c@proxima.alt.za> References: <20050718145304.74dbbe00@localhost.localdomain> <51b0ef71c372ee08703b4bd20017417c@proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 6ac4fd54-ead0-11e9-9d60-3106f5b1d025 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}