From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] Installed Plan 9, now what? From: Geoff Collyer In-Reply-To: <200312090300.hB930Sl24241@augusta.math.psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Mon, 8 Dec 2003 20:02:56 -0800 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 9dc627d6-eacc-11e9-9e20-41e7f4b1d025 I believe rsc and presotto mean to say `indirection', not `redirection'. To see the potential problem with just adding another level of indirection everywhere, consider the evolution of Lunix's filename space. Originally people edited files, including in places like /etc, directly. Then people began to worry that if they changed those files, their changes would get stomped on by the next OS upgrade from their vendor. In that world, checking changed files into RCS would let one just check them out again after an upgrade; in our world, we can just copy them out of the dump. But instead, people created a parallel file tree under /usr/local (or /local [a symlink] in places where people got tired of typing "/usr/local" endlessly). So additions and changes in /usr/local were now thought to be safe against upgrades. But then some vendors caught on to /usr/local and started shipping free-ish software pre-installed in /usr/local. And the gnu-ish folk decided that all non-vendors software should be installed in /usr/local. And some organisations wanted to share a standard /usr/local across their machines, including suborganisations. U of Toronto ended up with /csri/local, /cs/local, /ai/local and probably others that I've forgotten; I think U of Waterloo took it even farther (they've been much more ideological =E2=98=BA). So what's l= ocal, and who owns it? At various times, these owners have existed: - AT&T's System V maintainers (actually I think they populated /usr/lbin) - SGI, who shipped their own programs in /usr/local (it was local relative to System V), and probably other OEMs - campus computer centers, adding locally-installed (often imported) software to vendor distributions - departments - maintainers of clusters of machines - owners or users of individual machines Aside from the issue of name conflicts (who gets to control /usr/local?), more and more of the file system becomes fossilised boilerplate that most people (including administrators) are terrified (or forbidden) to touch. If you're in a big enough organisation, you can end up with /company/local/ /company/division/local /company/division/dept/local /company/division/dept/group/local /company/division/dept/group/my-machine/local I think we've made a very small step in this direction with termrc.local, /sys/lib/sysconfig/termrc, namespace.local and namespace.$sysname. One litmus test for when fear is driving these decisions is when people become afraid to edit files with `local' in their names and want to add another level of indirection. With the availability of dumps (or RCS on Lunix), there's little reason to be afraid of editing files.