[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Screensavers for the console

From: Marcus Brinkmann
Subject: Re: Screensavers for the console
Date: Wed, 14 May 2003 17:34:04 +0200
User-agent: Mutt/1.5.3i

On Wed, May 14, 2003 at 03:08:08PM +0200, Michal 'hramrach' Suchanek wrote:
> What about console locking? In FreeBSD and GNU/Linux this is independent of
> console screensaver. But for X it comes in one package. But there is built-in
> screensaver in XFree86 without locking, too.
> The question is: should the locking be implemented somewhere in the console, 
> in the screensaver, or as a separete application?

Yeah, well.

> A separate application that sits on a terminal until it receives a password or
> is killed should be easy.
> Implementing some support in the console itself would make it possible to
> lock/unlock several virtual terminals at once. But it would have to know about
> users logged in at the terminals. Afaik it does not care now.
> Locking in screensaver would be probably worst choice in this context because
> it has the limitation of standalone application but it may be executed
> with an identitiy different from the user that is logged in at the terminal.
> And it would require separate screensaver for every virtual terminal.

I don't believe in the concept of having one desktop for multiple user's
where each user gets a virtual console and you lock them individually with
that user's key.

So, if you want to lock your current login session, you should use whatever
floats your boat, a standalone program.  It could not restore the screen
correctly (unless we support something like xterm which restores the screen
after ncurses apps exit).  Importantly, this would then apply to all console
clients displaying that virtual console.

If you want to lock the physical console, then the console client could do
it, with it's own passwort, like the BIOS password is separate from
anything.  It should then lock all virtual consoles, ie, it should directly
disable the whole console client and display the password prompt on all
virtual consoles.  This would then only apply to that console client (other
clients might still access the same console).

This isn't so bad as it may sound at first.  Users can run their own console
_server_ and use their own client to display its content, and that client
can get its own password.

I am not sure this is the best solution, but it seems to fit into the
current design without adding new substantial features.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]