[812] in testers
/usr/athena/lib/init
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Mon May 21 01:07:56 1990
From: qjb@ATHENA.MIT.EDU
Date: Mon, 21 May 90 01:07:28 -0400
To: testers@ATHENA.MIT.EDU
In-Reply-To: [0804] in testers meeting
Cc: amgreene@ATHENA.MIT.EDU, lnp@ATHENA.MIT.EDU, jfc@ATHENA.MIT.EDU,
1. I generally disagree with statements that start off with
"anyone who knows x knows y." Knowing how to log in to a
machine with mkserv remote run on it means knowing how to
use telnet and having a friend who is a watchmaker. Knowing
how to manually activate a workstation and how to recognize
when this needs to be done requires a moderate degree of
sophistication. If we want to make the system friendly to
novice users, we can't go around expecting them to put this
check in their own files. A large and important set of
users who know how to log into workstations that have been
"mkserv remote"ed but that probably don't know about
activating workstations would be the support or
administrative staff members with private workstations and
modems. If mkserv remote is adequately publicized, then
these people will likely often run into the situation that
Lisa described in her original report.
2. Copying the contents of /usr/athena/lib/init locally to the
workstation is not an adequate fix since it only covers
the mkserv remote case. It does not cover the case of
people who CTRL-P log in to public workstations. People who
still want to be safe will still have to edit .cshrc itself.
If mkserv remote is intended to be used on machines that normal
people (including support staff who find out from the release
notes that they can now use mkserv remote to fix their
workstations so they can log in from home) are supposed to log
into, then why not put some check such as the one amgreene
described into the standard initialization files? The reasons
for not doing this are pretty out of date now (i.e., you don't
want to ever run activate on some machines that people may be
able to log into...).
If anyone has legitimate objections to this or reasons why the
current situtation is better than the old one, please respond.
I think this is an important issue since leaving things as they
are will break some users unnecessarily and since a relatively
clean fix would be fairly easy to come up with.
Jay
