[6370] in SIPB bug reports

home help back first fref pref prev next nref lref last post

Re: The Sipb locker contains more than just executables...

daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Mon Jun 2 22:37:50 1997

From: mhpower@MIT.EDU
To: svalente@MIT.EDU
Cc: bug-sipb@MIT.EDU, bug-sipb-new@MIT.EDU
In-Reply-To: "[0012] in SIPB new bug reports"
Date: Mon, 02 Jun 1997 22:37:31 EDT

>Date: Sun, 25 May 1997 18:54:42 -0400
>To: big-sipb@MIT.EDU, bug-sipb-new@MIT.EDU
>From: Salvatore Valente <svalente@MIT.EDU>

Was big-sipb@MIT.EDU just a typo for bug-sipb@MIT.EDU?

>The sipb-new locker is more-or-less ready to go, that is, it contains
>99% of the necessary software.

I'm not sure I understand how you came up with the figure of 99%.

For the sun4 platform, it looks like there are 89 programs installed,
and I'd consider these 34 missing, which would be about 72%:

  cda cksum fingerprint fortune fptocksum fptomd5 fptosnefru
  fwhois hcal hdate macps mcread mcvert md5 moonphase nawm netstats
  nvi pps prepfix prtgif rcextract rcindex rcnroff rcshow rctypeset
  rn slide snefru type vile xcal xvile zsh

Of these, macps and rrn (a symlink to rn) are mentioned in the olc
stock answers. rn is also mentioned in Athena's What Runs Where
document (http://web.mit.edu/acs/www/whereruns.html), as is xcal.
Incidentally, What Runs Where lists the sipb locker for xcmd, but
that one might just be considered a mistake.

Also, there are some programs installed in sipb-new for the sun4
platform but not installed there for the the decmips platform:

  bfinger bwrite rolo sdate tgif tin xcol ytalk

(tgif and tin are mentioned in the What Runs Where document)

There are also lots of programs that exist in the sipb locker for
the decmips platform but don't exist there for the sun4 platform.
I suppose one might argue that some users realize these are
partially desupported since they're only available now on the
dialup machines, but probably there are some that are in frequent
use by people who just-about-exclusively use dialup machines.

  arc beav hebcal joe lcal memo omer ship sm splot tek2ps utree
  vcal vmail zoo

Obviously, a bunch of others might also be used by people who still
have private decmips machines where they can login using X.

For the rt and vax platforms, the only program in sipb-new is
archie, so I won't bother making a list of what doesn't exist. I'd
guess that xscreensaver and webster are the most often used.

Also, there's no arch/sun4m_412 directory. It'd be really nice if
the /mit/sipb/sun4osbin/lndir program remained available, even if
it had to move to another locker. I think that lndir is the finest
program that's ever been developed for the sipb locker.

So, what do people think should be done about the programs that
have existed in the sipb locker, but aren't in sipb-new? Presumably
the answer may be different for the sun4 and sgi platforms (and
potentially also decmips) than for less supported platforms. Is it
ok to copy any binaries from the sipb locker into sipb-new?

The last time we deleted programs from the sipb locker, we created
symlinks with their names that printed a message saying (more or
less) that the program had been desupported and that people could
send comments to bug-sipb. The idea was that, if a program just
disappeared, users might not know what locker they used to run it
from, so they would have no idea where to send requests for it.
(The most amusing result of this was that an IS director complained
that the "copy" program had been desupported, and evidently hadn't
realized that he could just use the "cp" program instead.)

Will sipb-new be providing these "has been desupported" messages?

The top level of sipb-new doesn't contain the directory sun4bin.
This seems to be unhelpful to users who follow either the olh
(http://web.mit.edu/olh/Dotfiles/Dotfiles.html#making_new) or olc
(http://consult.mit.edu/test/stock_answers/other/other_sipb.html)
suggestions about using $bindir, or who did what we told them on
the first page of Inessential Athena. I think decmipsbin is also
needed, and vaxbin and rtbin would be useful to several people.
Also, Inessential AFS (page 13) implies that paths starting with
/mit/sipb/@sys are ok, and some users have this in their dotfiles.

Matt

home help back first fref pref prev next nref lref last post