Date: Fri, 3 Jul 1998 00:00:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: drosih@rpi.edu (Garance A Drosihn) Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807030000.RAA14014@usr09.primenet.com> In-Reply-To: <v0401171cb1c1b6683f8e@[128.113.24.47]> from "Garance A Drosihn" at Jul 2, 98 06:50:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 > happens that the config file isn't exactly what the user wants. > They quit the program, Bzzzt. The click on "Edit" and then click on "Preferences...". > Certainly it is an attractive idea to base symlinks on environment > variables, but maybe we should ask ourselves how hard it would be > to implement a "nice clean private namespace somewhere". I think > we'll be happier with the separate namespace, something which isn't > disrupted as readily and as often as the user environment. A namespace is a namespace. Your arguments apply no matter where the namespace is located, so long as you permit the user to modify it at all. For the "init" namespace, you don't let the user modify it. This is because what you are in fact modifying is the environment of the "init" process itself. This is, in fact, a "system logical name table". For the "process group leader" or "session leader" (the "group logical name table"), you would, preferentially, make this a session manager program. The session manager program does not need to be owned by the user. There are many good reasons to have a session manager; the main interesting one is to act as a credential holder for credentials and authentications you want shared between processes. The "user logical name table" is the user's environment, as it is currently understood. The only semantic difference that variant symlinks have from VMS logical names is their placement in a filesystem reference. The VMS placement must be as a prefix, and the placement we have been contemplating is "as a path component expansion in a symbolic link target. In point of fact, the concerns about tar'ring up these links was ill-founded: a "readlink" or, reflexively, "symlink" by tar will result in the correct behaviour (tar does not expand the environment, and "readlink" does not evaluate the target, it only reports it). Most of the concerns seem to be of the category "yeah, but if you make it work, people migh actually (shudder!) *use* it!". Something which allows you to do stupid things also allows you to do clever things. The question is whether the value of the clever things outweighs the risk of the stupid things. For the most part, having used systems that provided variant link technology, I have to say that the value of the clever things you can do with them vastly outweighs the risk that comes with them. For example, we could have made the /usr/lib/aout change appear to have zero impact. We could also have done a large number of other things with apparently zero impact, that would allow us to build multiple targets on the same machine, for example, something that the current build environment is not good at. There are numerous other examples that I can bore you with, if you insist... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199807030000.RAA14014>