[7600] in SIPB bug reports
Re: xscreensaver conflict with default dotfiles
daemon@ATHENA.MIT.EDU (David Z Maze)
Fri Jun 16 13:11:29 2000
To: John Hawkinson <jhawk@MIT.EDU>
Cc: Greg Hudson <ghudson@MIT.EDU>, bug-sipb@MIT.EDU
From: David Z Maze <dmaze@MIT.EDU>
Date: 16 Jun 2000 13:11:27 -0400
In-Reply-To: John Hawkinson's message of "Fri, 16 Jun 2000 12:50:28 -0400"
Message-ID: <y68wvjpwny8.fsf@indiana.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
John Hawkinson <jhawk@MIT.EDU> writes:
JAH> I'm afraid I feel like I'm missing something here. I do not
JAH> understand how "dueling screensavers" would occur -- is this if
JAH> both the sipb xscreensaver and the release's jwz xscreensaver are
JAH> configured to autolock the screen after some time interval?
I can envision a situation similar to the following: User starts SIPB
xscreensaver, uses it to lock his screen, and leaves the workstation
for a while. In the meantime, jwz xscreensaver notices that the
workstation is idle, and also starts up in locked mode. Now the two
screensavers need to fight with each other to completely blank the
screen (including the other screensaver), and to read the user's
password when they return.
JAH> If it's not that, then how is this problem specific to
JAH> xscreensaver? It seems like you'd encounter the same problem
JAH> with xlockmore (in outland), for instance.
If jwz xscreensaver was made an Athena default and started by the
default dotfiles, users would have to know to disable jwz xscreensaver
before running their own screen-locking program. I'm not convinced
that Athena's standard methods of publicizing release changes would be
adequate to warn users (though this isn't really a bug-sipb issue).
--
David Maze dmaze@mit.edu http://www.mit.edu/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
