From owner-freebsd-hackers Thu Jul 2 08:59:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16860 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:59:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA16848 for ; Thu, 2 Jul 1998 08:59:06 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id LAA11573; Thu, 2 Jul 1998 11:59:03 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by dignus.com (8.8.8/8.8.5) with ESMTP id LAA13161; Thu, 2 Jul 1998 11:20:09 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.8/8.6.9) id KAA15866; Thu, 2 Jul 1998 10:52:26 -0400 (EDT) Date: Thu, 2 Jul 1998 10:52:26 -0400 (EDT) From: Thomas David Rivers Message-Id: <199807021452.KAA15866@lakes.dignus.com> To: drosih@rpi.edu, jkh@time.cdrom.com Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG In-Reply-To: <15895.899343408@time.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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