[13963] in Athena Bugs
Re: sun4 7.7T: sunsoft wrapper perl script ...
daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Oct 30 23:51:17 1995
Date: Mon, 30 Oct 1995 23:51:11 -0500
To: cfields@MIT.EDU
Cc: jhawk@MIT.EDU, jawetzel@MIT.EDU, napalm.discuss@BLOOM-PICAYUNE.MIT.EDU
In-Reply-To: "[13962] in Athena Bugs"
From: John Hawkinson <jhawk@MIT.EDU>
Yeah, bugs is the wrong place. lvsp? nfs2afs? :-) We can settle on
napalm, I guess. Enveloped to bugs so interested followers don't lose
us.
> > That's a very poor assumption. Lots of people run many things in AFS
> > either via the full afs paths, or via symlinks to the full afs path
> > that are not /mit/lockername/somethingbin/file.
>
> Not to start a flame war on the bugs mailing list, but the fact that
> you *can* attempt to run software directly from its AFS path by no
> means implies that you *should*. In fact, to do so is to break the
> abstraction barrier created by attach. It is a very useful
> abstraction, and if you want to break it and you lose, too bad.
That's one opinion.
The other opinion is that you should never assume the locker
is there and always attach it if you need it, or otherwise
use the AFS path.
I don't think there's a clear consensus that one opinion is better
than the other. Both have their advantages and their
disadvantages. Nevertheless, one approach is clearly more compatible
than the other.
> To assume that the locker you live in is attached is not a silly
> assumption. The fact that AFS provides an alternate access path is
> irrelevant. Do you suggest that all C code that needs to look for
> random configuration files look in the full AFS path rather than
> /mit/lockername/lib (or whatever)? This is wrong.
Actually, I would, yes. Or an environment variable, or a compiled in
default, or look in the locker path and fall back to the afs path,
etc., etc. For instance, the stuff I have in the mbone locker looks in
/mit/mbone for it's config files, and if that loses it consults
/afs/sipb/project/mbone. I run it w/ the AFS path all the
time. Admittedly I lose a stat here, but I think that's OK.
> It prevents lockers from being moved around, either between
> filsystem types or between AFS directories, without
> recompilation. It is generally a maintenance headache, especially in
> the long term, and not worth any benefit gained by people not having
> to run attach.
Depends on your application. I personally find the overhead of attach
a locker as part of your application to be disappointing, but I think
that people who aren't crazy enough to hand-fix their packages based
on their destination /afs path ought to do that, and people who are
crazy enough to keep careful and uptodate track of /afs paths can use
them instead of lockers. After all, hesiod takes a day to update, a
quick program maintainer can beat that _easily_.
--jhawk
