Date: Fri, 3 Jul 1998 01:02:23 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <v04011721b1c20a7a03ab@[128.113.24.47]> In-Reply-To: <5406.899427726@time.cdrom.com> References: Your message of "Thu, 02 Jul 1998 18:50:46 EDT." <v0401171cb1c1b6683f8e@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
At 6:02 PM -0700 7/2/98, Jordan K. Hubbard wrote: >> What you're arguing for here is a symlink based on the unix userid, >> which certainly is a good candidate for a system-wide variable. All > > But that's NOT what I was arguing for - that was merely a convenient > example. I'm specifically arguing for being able to exploit an > application's *existing* use of environment variables and NOT having > to think "well gee, I guess a username is one thing we should make a > magic variable for, and maybe the uid and pid, and ..." I agree that the possible keys (ie, variable names) for symbolic links should not be something that's fixed at system build time. Some variable names and the default values for them should be system-wide, but users (any and all useres) should be able to add to the set of names without needing any special privileges. >> However, let's say the program itself happens to set an environment >> variable called "PROGUSER", and you're going to use that. You do >> not depend on the user themselves remembering to set this variable >> (which is good (*)), because you know the program itself sets the >> value before it reads the configuration file. The user runs the >> program, the program goes to the desired config file, and it > > You're somehow confusing the user for the application writer here. > When you say "you are going to use that", what you're really saying > is the _user_ is going to use that as a convenient hook only after > determining that it *is* a convenient hook. Hmm. Well, no. Actually I'm assuming another layer of people... :-) In my mind there's the developer of a program (who may be on the other side of the world, and sometimes even seems to be on another planet), the adminstrator of all the local machines (we have a handful of people administering about 500 to 1000 unix machines at RPI), and then the end-users (5,000 to 10,000 end users at RPI). I read your example as: The administrator goes to install the program, and notices he or she can avoid some administrative headaches by using a variant symbolic link. He or she does this, and then releases the package to the end-users, and then waits for end-users to call up with any problems they encounter. Now, admittedly that's not exactly what your example actually *said*, I'm just explaining why I replied the way I did... The person running the program could very well have no idea that a variant symbolic link is being used. I expect that variant symbolic links will be useful enough that one person will be creating a variant symbolic link which will effect (indirectly) a large body of users who won't even know they are using *any* symbolic link. To quote from the article written by Terry: > For example, we could have made the /usr/lib/aout change appear > to have zero impact. My guess is that no one is going to make the aout change appear to have zero impact by assuming *every* *end-user* is individually going to create symbolic links and set environment variables. No, I suspect some administrator or system-developer is the person making the decision to create that particular symbolic link... And once they do, then *every* end user had better not choose that particular environment variable unless they fully understand how it's being used for this symbolic link (even though ideally they wouldn't even know the link exists). > In any case, this argument is also somewhat moot since neither of > us is actually doing the work of IMPLEMENTING this baby and it's > the implementor who is always going to have the final say as to > how it works anyway. :-) Sure, go and get all practical on me. Go ahead and ruin all my fun babbling... :-) Actually, though, I think that what I'm proposing is really just an alternative to environment variables (not just "environment variables for symbolic links", but "an alternative to environment variables for holding configuration settings"). Perhaps that wouldn't be too hard to do a simple cut of? To get the kernel to correctly *use* environment variables for symbolic links is going to take some work (even if everyone agrees it's the best of all ideas), and perhaps an alternative would be less work to do. If so, I can get away with all this babbling without irritating any person who is actually doing the useful work on 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?v04011721b1c20a7a03ab>