[423] in SIPB bug reports
/usr/sipb/*bin/man
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Thu Mar 23 19:09:33 1989
Date: Thu, 23 Mar 89 19:10:10 EST
From: Jonathan I. Kamens <jik@Athena.MIT.EDU>
To: srz@ATHENA.MIT.EDU
Cc: bug-sipb@ATHENA.MIT.EDU
In-Reply-To: Stanley R Zanarotti's message of Thu, 23 Mar 89 17:03:18 EST <8903232203.AA08535@CHARON.MIT.EDU>
The message jik refers to is [0332] in SIPB bug reports; the
message contained 10 points, and the one about man asked "Does the
file apropos.sh serve any useful purpose?", and continued on with
"ditto for whatis.sh & man.sh". I do not consider a message like
that a warning about it going away. It was a question.
\begin{flame}
I followed the same procedure with apropos, man, etc. that I followed
with all of the other changes I've made, and no one has complained
about any of the other changes. I decided what I thought should
happen, and then I sent out a message to sipbsrc explaining what I
intended to do and asking for comments.
I waited several weeks for comments. None came. It's not my fault if
people don't read their mail or don't bother to read it carefully or
don't bother to respond to it.
Shall we institute a SRFC policy? "SIPB Request For Comment number
972: Intent to remove man from the SIPB locker after a one week
warning period."
\end{flame}
I think we should keep man around, since all it's costing is a half-second
of response time. Of course, I'm not going to cry too hard if it goes
away, if people are properly warned.
I see no reason on punting bm & bm.x10. At the time it was installed,
xsetroot was not documented.
I consider it a win to remove these programs from the locker for a few
reasons:
1. The speed hit involved in running the shell which executes the
man. This is a minor consideration, but it should be considered
nevertheless, especially on Athena when speed is always a problem.
2. The fact that there are better ways to do what the scripts are
doing which use the system the way it is supposed to be used and
which take less time.
3. Xsetroot *is* documented now. MANPATH is also documented in both
Athena and SIPB documentation.
4. Lots of people don't even *realize* they're using the SIPB man and
getting a speed hit where it's not necessary since they've already
got sipb in their MANPATH.
5. IMHO, two-line hacks like scripts to do an xsetroot are better off
in users' home directories than cluttering up the sipb locker.
Especially when they are not even necessary.
6. I think it's more of a win to explain how to define a bm alias in
the Inessential Guide than it is to have a shell script that does
it. Ditto for setting MANPATH. This way, we not only provide a
service for users but also teach them something they can use in the
future on things besides the SIPB filesystem.
7. Finally, the programs I removed all (except apropos which *might*
have done things partially right) were buggy, because they ignored
the user's MANPATH. This is not a win. You might say that it
could be fixed by fixing the bug, but my opinion is that if we're
going to rewrite the shell scripts, and they're not necessary
anyway, why not just get rid of them?
8. Also IMHO, I think it's stupid to keep obsolete programs that do
not perform optimally around when it's not necessary to do so.
Backward compatibility is a wonderful thing (which is why a warning
period for man would be good), but moving forward with progress is
even more wonderful.
jik
