Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)

[Carl Wilhelm Soderstrom]

On Sun, Mar 24, 2002 at 02:35:58PM -0500, Marcus Brinkmann wrote:
> On Sun, Mar 24, 2002 at 01:08:10PM -0600, Carl Wilhelm Soderstrom wrote:
> >     of course, I'm still puzzling a bit over why there is a need to move
> > all the /usr stuff to /. I know it cuts down the paths, but it adds more
> > complexity to /, which is something I'd like to avoid. :)
> 
> You mean it adds complexity to a slash?  (I am deliberately
> misunderstanding you here :)  The reason we do all this is because it is
> the right thing.  We are not scared of complexity, as long as we feel
> sure that we can manage it, and it is flexible enough to allow to do
> simple things easily.

        I prefer to have the listing of / be short & sweet, so its easier to
visually parse. makes it easier when doing something like 'du -chs /*' to
see where space is being used. 
        also, it makes tab-completion easier. only having /foo, rather than
/foo and /foobar makes it faster to type, because if there's only one
possibility for /f<tab>, I don't have to type any more. fewer root dirs
means less chance of a namespace collision like that.
        that, and mostly I just like the aesthetics of simplicity. (up to a
certain point... only to the point that it makes operation and understanding
simpler).

> > this gets back to the old per-package directory/per-function directory holy
> > war;
> 
> Not at all, because you are not supposed to access the /packages files
> directly.  (Well, maybe the package itself should be allowed to access it via
> this path, that is something to think about).  This is just another way
> to implement a packaging system.
        well, if I'm not supposed to access them normally, I hope there's a
way I can avoid looking at them. :)
        maybe /.package? not quite what I want; since .filename is still
visible with ls -a... is there a way to set an extended attribute for
visibility like that?

> [packagefs]
> > this could be generated pretty easily, based on information in the package
> > database. problem there, is that it's not guaranteed to be up-to-date, since
> > changes might be made after a package is installed.
> 
> Well, this can be done but it is completely upside down to what I have
> mentioned here.  
        yes. I know. I intended the post to be a thought experiment; and a
proposition for a stopgap measure (plus a tool that some people might find
useful).

> The hierarchy I was talking about is supposed to be (eg
> replace) the packaging system.  The users would still see the normal
> irectory hierarchy (collapsed).
> 
> Note that you ca do clever things like for /etc/inetd.conf you can
> concatenate all /packages/*/etc/inetd.conf files with a special
> translator setting.  (Kudos to RMS for this one).
        interesting. kind of like what xinetd does, with the collection of
files in /etc/xinetd.d/. 

Carl Soderstrom
-- 
Network Engineer
Real-Time Enterprises
www.real-time.com