Date: Thu, 2 Jul 1998 18:10:44 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Mike Smith <mike@smith.net.au>, Thomas David Rivers <rivers@dignus.com> Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <v0401171bb1c1acb4f7a9@[128.113.24.47]> In-Reply-To: <199807021813.LAA01087@antipodes.cdrom.com> References: Your message of "Thu, 02 Jul 1998 10:52:26 EDT." <199807021452.KAA15866@lakes.dignus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:13 AM -0700 7/2/98, Mike Smith wrote:
>>
>> So, given my experience - I'd prefer to not have this feature
>> in FreeBSD... I'd suggest, at least, a mechanism (vis sysctl var?)
>> to globally disable it at an installation...
>
> How about "just don't use it"? The point here is that it's an enabling
> technology, not an intentional constriction of freedom. If you don't
> want it or can't manage it properly, you don't have to use it.
Enabling technology will probably be attractive to people working on
ports. I suspect many of us will find ourselves using it, whether we
are personally thrilled with it or not. Certainly the idea of using
{arch} to distinguish between alpha-specific vs intel-specific files
would be immediately attractive, for instance. I'm just asking what
the best (most reliable) implementation might be for this variable
symlink facility.
In my case, I'm only using freebsd for my own personal stuff, so I
am not too concerned about how it's implemented. As you say, if it
is too dangerous then I simply will not use it. It'd be a pity to
implement an enabling technology which is too dangerous to use, but
that shouldn't be any skin off my own personal teeth.
However, I am also thinking how this capability would work in an
environment like the unix (AIX, Solaris, IRIX) environment at RPI.
I don't mean, "how would it work under AIX?", I mean "what would
it be like if RPI replaced all public unix machines with freebsd
machines which have this implemented via environment variables?".
My guess is that it would be a nightmare when it came to end-user
support.
I think there would be less headaches all-around if symlinks did not
key off environment variables, although I do think we'd want them to
key off of something as simple to adjust as environment variables are.
I must admit I can't quite come up with an excellent alternative. I
think I want something which works quite a bit like environment
variables, but which are at least in a separate namespace (so values
aren't clobbered when some script happens to use a name which is also
used in some symlink).
In some sense I'm basing my thoughts on (what seems to me) a
principle here. Symlinks are embedded in the filesystem, and as
such they are global in nature. These global values "should not"
(in some philosophical sense) depend on something as ephemeral and
constantly changing as the user's environment. Yes, you will want
to change it's effective value on a "local" basis (such as in one
shell in one window), but the symlink itself is a global value.
I realize I'm not contributing any particularly good answers here,
but I thought it would worthwhile to discuss alternatives, instead
of simply rushing out and recreating the Apollo implementation
because that was known to be useful in some situations. Perhaps we
can come up with something just as useful, but with less potential
for pitfalls. Certainly we won't if we just dismiss the discussion
by saying "Well, if you don't like it, don't use it".
---
Garance Alistair Drosehn = gad@eclipse.its.rpi.edu
Senior Systems Programmer or drosih@rpi.edu
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v0401171bb1c1acb4f7a9>