On Thu, Mar 30, 2006 at 10:42:15AM -0500, [EMAIL PROTECTED] 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
