Date: Thu, 2 Jul 1998 10:52:26 -0400 (EDT) From: Thomas David Rivers <rivers@dignus.com> To: drosih@rpi.edu, jkh@time.cdrom.com Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807021452.KAA15866@lakes.dignus.com> In-Reply-To: <15895.899343408@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan writes: > > > My initial reaction is that I wouldn't want links to depend on values > > in environment variables. If I setup some "clean environment" for a > > program I'm exec-ing, I'm not going to think to copy values which are > > important for these links to work. > > If you have ever used Apollo's Domain/OS, the advantages of having > synlink behavior be configurable by something as dynamic as the user's > environment become very quickly apparent. :) > > - Jordan > Well - after working with Domain/OS for several years; I'd have to count this symlink behaviour as one of the least-pratical features. [Although, it sounded good from the start.] What we discovered for decent-sized projects (i.e. more than 1000 source files) was that the proper environment management required to ensure every symlink was "real" became more-and-more cumbersome. And, provided little return for the investment. Eventually, we concluded that the fact that a symlink can change because of an 'external' influence was a bad idea. Imagine, driving home in your red car works, but when you borrow a friend's car because your's is in the shop, (i.e. log in to someone elses machine), you can't find your way home (the streets have changed.) Furthermore, imagine that to get to your house requires a red car. It is then imcumbent on all the visitors to your house to use a red car... it can get quite frustrating... In deliverying products in this environment - we would frequently be called on problems because people couldn't find 'component X'. Our response would be "did you set blah-de-blah environment variable?" We would find that they had set it previously, but not in a permanent fashion, and, after logging on, nothing worked... 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... - Dave Rivers - 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?199807021452.KAA15866>