Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!aries!mcdonald
From: mcdonald@aries.uiuc.edu (Doug McDonald)
Newsgroups: comp.lang.postscript
Subject: Re: Adobe PPD files
Message-ID: <1989Dec7.151304.649@ux1.cso.uiuc.edu>
Date: 7 Dec 89 15:13:04 GMT
References: <1025@maxim.erbe.se> <17380@rpp386.cactus.org> <2140@ruuinf.cs.ruu.nl>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Organization: School of Chemical Sciences, Univ. of Illinois at Urbana-Champaign
Lines: 25

In article <2140@ruuinf.cs.ruu.nl> piet@cs.ruu.nl (Piet van Oostrum) writes:
>In article <17380@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
>`DON'T change the serverdict password.  If for some reason you forget it,
>`you will have to send the controller off to get it recovered.  Secondly,
>`may aplications depend on server password to be the default of 0 and will
>`flat out fail. ...
>
>Well, isn't that a very silly thing: a password that you shouldn't change
>and should always have the default value. What if one of our students
>decide to change it? Which they can do if the password is 0. It shouldn't
>be too difficult to keep the password around: write it on a piece of paper
>and lock it somewhere. Keep it with your Laserprinter bill, with your tax
>administration, write it in your will :=),...
>-- 
What all this proves is very clear: the latter person has a very good
argument: if you leave it 0, a malicious person could set it to a random
value. If you change it, the device fails for many purposes. The
solution should be OBVIOUS: a jumper on the logic board that forces
it to 0 so it can be reset if disaster happens. Or store the
value in some sort of CMOS logic that resets to 0 if the battery is removed.
So simple. So obvious.

So common in some places.

Doug McDonald