[2615] in SIPB bug reports
Fortune program on Suns
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Tue Mar 17 15:05:47 1992
Date: Tue, 17 Mar 92 15:04:44 -0500
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: lwvanels@MIT.EDU
Cc: solo26@MIT.EDU, bug-sipb@MIT.EDU
In-Reply-To: lwvanels@Athena.MIT.EDU's message of Tue, 17 Mar 92 10:23:58 -0500 <9203171523.AA16136@fionavar.MIT.EDU>
From: lwvanels@Athena.MIT.EDU
Date: Tue, 17 Mar 92 10:23:58 -0500
Reply-To: lwvanels@MIT.EDU
>With the new change to vendor-supplied operating systems and platforms,
>the change to allow /usr/sipb cannot be made; thus this path (and any
>other programs that use it) should be modified....
This is simply not true; we created the symlink on the RS/6000, and there is
no reason not to do so on other platforms we do a port to.
Actually, the consensus the last time this was discussed in the
athena-ws discuss meeting is that it is pretty unreasonable for the
exception for the sipb locker to still be around, and that we can
probably assume that the /usr/sipb link will go away at some point in
the future. Therefore, we've been migrating over to using /mit/sipb.
Since the vast majority of people using the sipb locker are on Project
Athena, it is reasonable for the software in the locker to use
/mit/sipb instead of /usr/sipb. If there is anyone using the sipb
locker outside of Athena, it seems eminently more reasonable to expect
them to do "mkdir /mit" and then mount the locker in /mit/sipb rather
than to ask Athena to make a special exception, out of all lockers,
for the SIPB. The non-Athena users are, after all, the exception, not
the rule.
NOTE: It is my impression that I'm rehashing a conclusion of a
discussion that has already taken place, not making new and different
assertions. If you do think I'm coming out of left field and wish to
discuss what I've written, please do it at a meeting or in one of the
discuss meetings for discussing such things, not in mail on the
bug-sipb list.
jik
