From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6e35c06205071811246b50efb3@mail.gmail.com> Date: Mon, 18 Jul 2005 11:24:05 -0700 From: Jack Johnson To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] First-timer help In-Reply-To: <51b0ef71c372ee08703b4bd20017417c@proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050718145304.74dbbe00@localhost.localdomain> <51b0ef71c372ee08703b4bd20017417c@proxima.alt.za> Topicbox-Message-UUID: 6a7ab05a-ead0-11e9-9d60-3106f5b1d025 On 7/18/05, lucio@proxima.alt.za wrote: > > 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.... >=20 > 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. It's interesting to consider this specific problem, where you want to keep your context but allow someone else momentary use of your workstation. If cpu and auth servers are available, I wonder if it would suffice to lock most of the local resources and fire up another copy of rio in someone else's context? My brain can't wrap around how you might swing that at the moment, but I'm picturing something that's half screensaver (to keep the guest from accessing local windows/namespace) and half drawterm that doesn't export the local terminal's filesystem. The guest would still be susceptible to someone replacing the 'guestterm' binary, but you could have some sort of reasonable expectation that the guest could access the cpu server securely and still keep your session/data/namespace intact. You would probably want to re-authenticate after closing the guestterm. Feel free to poke more holes in my Swiss cheese. -Jack