[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Carl Wilhelm Soderstrom
Subject: Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)
Date: Tue, 26 Mar 2002 00:53:53 -0600
User-agent: Mutt/

warning: harping, hotheadedness, and almost-ranting follow. feel free to use
the <delete> key now. :)

> 2. Put sbin inside etc: /etc/sbin
        whoa. very bad. breaks the scheme of '/etc is for configuration
stuff, not for executables'. other Unices did things like that, and I find
them really annoying. :) 

        the thing I like most about the current FHS, is how it sorts stuff
into nice trees based on functionality. i.e. if you want to find a file, and
'locate' is not available, or too slow, or out of date; you should just be
able to cd to a particular tree and run 'grep -ri <whatever> *' or
'find|grep -i <whatever>', depending on whether you're looking for a file,
or the contents of a file. :)
        the more trees, the more typing and repetitive thinking necessary to
search them. stuff best left to consumers. :)
        this is one of things I'll miss about /usr... if I try doing a find
on /usr now (for instance, to see if a file is in /usr/local or /usr/bin or
/usr/sbin), I'll get all of /, which adds up to quite a lot more filesystem
accesses. :(
        I know that you'll be able to eventually rearrange your apparent
filesystem to be anything you want; but why should you have to?
> Apps dir: /apps  /local/apps
        interesting. what were your thoughts on the content of this? I
always thought /apps would be a far better name for /usr (at least in its
current use); but we're getting rid of /usr. :|
> Really though, the *NIX directory
> tree was pretty well thought out,
> and these silly changes would really
> only be for aesthetic purposes. 

I agree wholeheartedly. :)

Carl Soderstrom.
Network Engineer
Real-Time Enterprises

reply via email to

[Prev in Thread] Current Thread [Next in Thread]