Linked by Thom Holwerda on Mon 30th Jan 2012 20:39 UTC
General Unix Finally something really interesting to talk about. If you've used UNIX or any of its derivatives, you've probably wondered why there's /bin, /sbin, /usr/bin, /usr/sbin in the file system. You may even have a rationalisation for the existence of each and every one of these directories. The thing is, though - all these rationalisations were thought up after these directories were created. As it turns out, the real reasoning is pretty damn straightforward.
Permalink for comment 505173
To read all comments associated with this story, please click here.
Maybe not as intended, but still useful
by saso on Mon 30th Jan 2012 21:21 UTC
Member since:

Maybe the filesystem isn't used the way it was decades ago, but there are certain use-cases where the original multi-disk split still does make sense.

Btw: your example of kill/killall is particularly badly chosen. "kill" does the same thing on every *nix, but "killall" has wildly different meanings. Try "man killall" on Solaris and see for yourself that it's not always a synonym for "kill `pgrep <name>`".

Now I will agree that the names are somewhat cryptic - it takes a bit getting used to, but just like every other system developed largely by academia, there is a somewhat steeper learning curve, mostly because of jargon. But once you get past that, it starts to make sense (mostly).

There are use-cases where having a separate /bin, /usr/bin and possibly /usr/local/bin is beneficial - diskless network-booting machines spring to mind. A minimal kernel+initrd via PXE contains / and most everything else is loaded from NFS mounted at /usr. The /usr/local environment is provided for site-customized versions of stuff in /usr, making it easy to keep the original distro stuff separate.

Again, I'm not saying that the *original* reasons why Unix had those were very good reasons to begin with, but bad solutions can adapt to new problems and become good solutions to those.

Reply Score: 3