🚀 go-pugleaf

In article <1989Dec7.151304.649@ux1.cso.uiuc.edu>, mcdonald@aries.uiuc.edu (Doug McDonald) writes:
> 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

yes, except to Adobe.  
(no offense intended)