Re: Understanding /root, /usr, /var and so on

[Andrew Cady <d@jerkface.net>]

On Thu, Mar 30, 2006 at 10:42:15AM -0500, hendrik@topoi.pooq.com wrote:
> On Thu, Mar 30, 2006 at 10:03:06AM -0500, Andrew Cady wrote:
> > 
> > Apparently the BSD folks decided in retrospect that mixing binaries with
> > configuration was a bad idea.  But why not put them in /bin?  It may
> > well have been performance reasons; that also seems to have been the
> > original reason for placing binaries in /usr/bin.  At least, AT&T unix
> > shipped everything in /bin, but recommended the administrator place most
> > of those commands in /usr/bin for faster performance on lookups in /bin.
> 
> So. presumably the advent of filesystems that can handle large directories 
> efficiently (like reiser) have made some of these distinctions unnecessary?

I would say so.  Less for faster filesystems than for faster hardware: a
"large" directory today is one containing many thousands of files, not
dozens.  My /usr/bin has 2021 files, and I doubt it's appreciably slower
than /bin, even with hashed b-trees disabled.  Probably the directory
stays cached in memory most of the time; searching it in memory would be
over 100k times as fast as the original unix, according to Moore's law.

(PII450 from 1995, original Unix in 1969; 26 years is a 2^17 increase.
Of course, the original Unix had low limits on filename length; probably
its directories used a much faster representation in general).

> Or maybe the user in intended to do
>   ls /bin
> whenever he forgets the name of a common command without being distracted by 
> commands he can't or probably won't want to execute?

The better way to achieve that effect would be to link the commonly used
commands into a directory elsewhere -- especially since common use will
vary from machine to machine and user to user. /bin is only for commands
required before mounting /usr or for recovery, so, e.g., readlink and
loadkeys are included, but mplayer and mutt (two of my favorites) are
not.