🚀 go-pugleaf

In article <8062@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>The symbolic links that point to the old places are there for the
>benefit of both programs and people that haven't converted yet.

I thought the main reason that everything was sym-linked was to allow
(as you say later) the removing of machine dependent files from a
normal file system into somewhere else (local to each machine) so that
many machines could share common disks.

If this is the case, why such a bogus hack. HP looked at the problem
and came up with a general purpose solution that *doesn't* break
anything. The technology for this has been given to OSF and it's
called Context Dependent Files (CDFs).

Basically a file looks, smells and behaves like an ordinary file, but
can vary from machine to machine depending on the context (which
currently covers things like processor types supported (including
sub-classes), name of the current machine, local or remote root
file-system and even a default if nothing else matches.

With this scheme nothing is broken, everything behaves the way it used
to, you don't have to have it if you don't want it, you can make
*anything* node independent (like directories, device files...).

>One original motivation for the file system reorganization was to make
>it a bit more pleasant to support diskless clients (that was certainly
>one of Rusty's motivations for pushing the idea in the first place), so
>that the root and (later) "/var" file systems would contain stuff that
>would generally be per-client and the "/usr" file system could contain
>stuff that would be shareable by all clients.  An additional consequence
>of that split is that, if done right, you can mount "/usr" read-only.

See above

I'm intrigued as to how diskless clients are supported under this
massive sym-linking exercise, since they have no local disks, how do
the sym-links point to an area of disk which is for that machine only?


NB: With CDFs /usr can't be mounted read-only, but then somehow most
machines seem to be able to survive that at the moment.

>Few, if any, changes are entirely devoid of bad consequences, but that
>doesn't mean few, if any, changes should be made....

*BUT* they should be done in a way that does least harm and if
possible in an intuitive, generic and simple way.


			vic
--
Victor Gavin <vic@grep.co.uk||..!ukc!logitek!grep!vic||..!ukc!vision!grep!vic>