I think the Filesystem Hierarchy Standard is a better resource than this. Version 2.3 can be browsed at <a href="http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html" rel="nofollow">http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html</a>. Development of version 3.0 (the first update since 2004) began in 2011; you can see a draft at <a href="http://www.linuxbase.org/betaspecs/fhs/fhs/index.html" rel="nofollow">http://www.linuxbase.org/betaspecs/fhs/fhs/index.html</a>
I put up an explanation of the difference between /bin, /usr/bin, /usr/local/bin, and ~/bin, as part of an argument why the "robustness" of using #!/usr/bin/env $binname vs. hardcoding #!/path/to/binname is not a good thing:<p>> The reason that depending on PATH is not considered good practice is that the script can make no assumptions about the content of the PATH environment variable, breaking the "sequential dependency model" of binaries where<p>1. /bin contains the executables needed at boot time;<p>2. /usr/bin contains the other executables used by the OS installation;<p>3. /usr/local/bin contains executables installed by the system administrator that are not part of the base OS.<p>4. ~/bin contains the user's own executables.<p>> Each level should not assume the existence of binaries later in the sequence, which are more "application" but may rely on binaries earlier, which are more "fundament". And the PATH variable tends to run from applicationy to fundamental, which is the opposite direction to the natural dependency above.<p>> To illustrate the problem, ask yourself what happens if a script in ~/bin invokes an script in /usr/local/bin that invokes Ruby? Should that script depend on the OS installed version at /usr/bin/ruby, or on the personal copy the user happens to have at ~/bin/ruby? PATH searching gives the unpredictable semantics associated with the latter (maybe ~/bin/ruby is a broken symbolic link), while baking in the path to #! gives the former.<p>On the Unix&Linux SX - <a href="http://unix.stackexchange.com/a/11917/5197" rel="nofollow">http://unix.stackexchange.com/a/11917/5197</a>
I prefer the simpler filesystem proposal from <a href="http://sta.li/filesystem" rel="nofollow">http://sta.li/filesystem</a><p>The FHS has been poorly done for years. For e.g. where is the canonical place for a Web vhost root? /srv/www? /srv/web? /var/www?
Not enough people know this, but when you say "etc" out loud in reference to the directory, it is supposed to sound like "etsy".<p>I expect there will be people who reply to this comment to argue it should be "E-T-C" or "Et Cetera". You can ignore those people; they probably say "exclamation mark" instead of "bang".
I wrote a utility called 'dirhelp' that can give you info on any directory:
<a href="https://github.com/jrenner/linux-directory-help" rel="nofollow">https://github.com/jrenner/linux-directory-help</a>
It's written in Go, binaries are available in the repo
<i>/srv</i> baby! Since I discovered that had semi-official support (even though it often doesn't exist), I've rarely written elsewhere. Makes far more sense than <i>/var/www/</i> and <i>/var/lib/...</i> paths for different daemons to me.
Some related articles:<p>20120128
<a href="http://lists.busybox.net/pipermail/busybox/2010-December/074114.html" rel="nofollow">http://lists.busybox.net/pipermail/busybox/2010-December/074...</a>
Understanding the bin, sbin, usr/bin, usr/sbin split<p>Ohhh THATS why!
Taking the meaning of 'legacy' to new extremes.
This very detail, is one of the prime reasons I refuse to use Linux. I have always thought the categorization of folder usage was insane.
Now I know WHY it's insane.<p>20030430
<a href="http://www.osnews.com/story/3431" rel="nofollow">http://www.osnews.com/story/3431</a>
<a href="http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page2/" rel="nofollow">http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page...</a>
<a href="http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page3/" rel="nofollow">http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page...</a>
If I Had My Own Distro (Linux)
Fedora has made some major changes to the hierarchy recently (merging /bin and /lib into /usr, introducing /run) that will be present in RHEL 7.<p>/run has been widely adopted, but the /usr merge is a bit more controversial. I expect this will become another factor in the growing bifurcation of Linux into Red Hat-style distros and Ubuntu-style distros (see also systemd vs. upstart, Wayland vs. Mir, etc.) with a few "traditionalist" distributions like Slackware on the sidelines. As a Debian user, I expect that the next few years will be...interesting.
I remember reading an article that discussed why there were so many folders that seemed to have the same purpose (e.g. /bin,/sbin,/usr/bin) and the reason was that hard drives were so small that they needed to make sure that the essentials were available on boot. Seeing as how this isnt an issue anymore, why do we persist this same structure? E.g. to me the Mac filesystem seems to make much more sense and for the large part has eliminated all of this redundancy. Why isnt Linux in general following suit?
While ubiquitous, this is not strictly necessary for a Linux system. For an example of a distro that makes a radical departure from FHS, see GoboLinux (sadly seems to be not updated anymore).
Unfortunately this is obsolete in many modern distros, including Fedora and Archlinux, because of the /usr merge:
<a href="http://fedoraproject.org/wiki/Features/UsrMove" rel="nofollow">http://fedoraproject.org/wiki/Features/UsrMove</a><p>Also it doesn't take /run into account (for which many distros had a hack before settling on /run).
What do people think if the way Gobolinux does it? It seems a more sensible (and understandable filesystem hierarchy to me, but I wonder if there are problems with the idea).<p>Gobolinux: <a href="http://www.gobolinux.org/" rel="nofollow">http://www.gobolinux.org/</a>