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.
Thread beginning with comment 505209
To view parent comment, click here.
To read all comments associated with this story, please click here.
leech
Member since:
2006-01-10

Maybe it's "made up after the fact", but bringing order into chaos is laudable goal. It's too bad the Linux folks (and SysV folks in general) never "got it".

Just look at the hier(7) man page on FreeBSD to see a hierarchy that makes sense:
* / is for the OS, what's needed to boot
* /usr is for the OS, what's needed after boot (can be NFS mounted)
* /usr/local is for third-party apps installed by the user

Nice and clean, and makes sense. bin directories are for normal user apps. sbin directories are for system admin apps.

But, FreeBSD has a clear separation between "OS" and "third-party apps", which Linux doesn't have.

The unfortunate side-effect of this change is that the /usr/bin directory is going to be absolutely *HUGE* as every single application installed (from OS utils, to Xorg, to KDE, to Firefox, to Apache, etc, etc, etc. And there won't be many sub-directories.

It's bad enough already, but this is just going to make it worse.


The way I had always seen it explained across all *nix systems was that /bin and /sbin were for core files that were required to boot (throw /boot in there too) anything else is 'userland'. For the record, Debian and almost every other Linux distribution is the same as what you've shown there with FreeBSD. /usr/local is for source compiled (Third party) software. Whereas anything that is packaged and distributed with the distribution (handled by the package manager) goes into the proper /usr/bin, /usr/sbin with the data going into /usr/share/<packagename>. Debian's packaging guidelines are pretty strict about this.

For the record Thom, I had always heard that this was the way it was meant. That /bin and /sbin had run out of space and it was for mounting other drives (or doing network mounts later on). That's the true beauty of the Unix file system hierarchy.

Reply Parent Score: 3

cjcoats Member since:
2006-04-16

AND /bin and /sbin had statically linked executables, so that you can't corrupt the essential part of the system by installing a malicious .so (still true on the BSDs but no longer true on Linux, where the ideology is to have everything possible dynamically linked, in spite of the fact that vendors' insufficiently-tested .so's break mission critical apps. Much too frequently.

Reply Parent Score: 4

Lennie Member since:
2007-09-22

The part about statically linked executables isn't true these days on all Linux/Unix, it just is: without dependencies on /usr

Then again in Linux you just have an initrd these days anyway.

Reply Parent Score: 2

Soulbender Member since:
2005-08-18

For the record, Debian and almost every other Linux distribution is the same as what you've shown there with FreeBSD. /usr/local is for source compiled (Third party) software


Except that in the BSD's /usr/local is for everything that comes as a package so it's not like Linux.

Reply Parent Score: 2