9 ms·

opt etc.)

153 points by alexholehouse 13y ago

deleted 13y ago
[deleted]
sciurus 13y ago
I think the Filesystem Hierarchy Standard is a better resource than this. Version 2.3 can be browsed at http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html. Development of version 3.0 (the first update since 2004) began in 2011; you can see a draft at http://www.linuxbase.org/betaspecs/fhs/fhs/index.html http://www.linuxbase.org/betaspecs/fhs/fhs/index.html
- yajoe 13y ago
  I've used linux for years (15? 20? get off my lawn... :) Thank you for posting this link! I never knew why the paths were what they were, I could only explain what to expect in each.
talloaktrees 13y ago
I wrote a utility called 'dirhelp' that can give you info on any directory: https://github.com/jrenner/linux-directory-help https://github.com/jrenner/linux-directory-help It's written in Go, binaries are available in the repo
- alexholehouse 13y ago
  This is so truly, fantastically excellent. This should be a standard system utility!
- javert 13y ago
  I haven't actually tried it, but that's really nifty looking. I made something not dissimilar, which lists all the man page sections for a given term with a brief description, to help you pick the right section.
- talloaktrees 13y ago
  mistake: I wrote 'any' directory, but that's not true. It has a limited set of information, but I tried to make it as complete as possible.
- yankcrime 13y ago
  hier(7) accomplishes largely the same thing.
hendry 13y ago
I prefer the simpler filesystem proposal from http://sta.li/filesystem http://sta.li/filesystem 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?
- javert 13y ago
  The whole stali idea is pretty cool. I was wondering recently if there could be any role for something like Docker in an experimental/radically different Linux distro.
- derefr 13y ago
  One thing I've never been able to figure out is where to store web-application code for webserver backends not associated with any particular vhost. I ended up deciding to package them as full "applications" under /opt, but this still feels a bit off. Under stali, would these be in /svc?
- gizmo686 13y ago
  That looks like a really cool idea. One thing I don't like about its filesystem is its insistence that all binaries go into /bin. As a user, I greatly appreciate the concept of having some sort of /local directory to distinguish between files (or just executable in this case) which the end user installed and which are part of the distribution. If you abandon the idea that /bin has no subdirecories, then I could see /bin/local as a viable alternative (although I think I would still prefer a /local folder where that had /local/bin, /local/etc ...).
  - dredmorbius 13y ago
    The point of standards is that they define how others (distros, vendors) should interact with your system. Debian Policy makes this more explicit by noting that it defines what packages (and hence: package maintainers) must do, may do, and must not do. Among the latter: other than creating some of the hierarchy under /usr/local, packages may not delete content under this tree. That is for local system management. Similarly, /opt as a location where third-party vendors can install their crap, excuse me, packages, is a pretty well established standard. Note too that you can offer the filesystem view independent of the underlying storage view, whether by symlinks (e.g., ln -s /usr/local/opt /opt), union mounts, or other means. Any parts of the filesystem you create outside the defined standards are pretty much yours to worry about, though I've also got extreme reservations about polluting the root filesystem excessively. Better to create a structure under /usr/local or elsewhere (if for no other reason: it simplifies backups). This is a practice often respected in the breach in reality, however....
FreakyT 13y ago
I never understood why this hasn't been modernized. The three-letter nearly-meaningless directory names seem so obsolete.
- trafficlight 13y ago
  They are easy to type and do have meaning in and of themselves.
  - eru 13y ago
    > [...] have meaning in and of themselves. Mostly because of long usage.
- e3pi 13y ago
  I gather you're also not versed in the unix command line? Piping and redirecting long dir paths thru commands and arguments welcomes everything abbreviated. The mnemonics is just engineered happiness sugar-on-top of all the intrinsic greatness.
- quackerhacker 13y ago
  Unless your ssh'd into a machine, it's annoying to type long dir's. What's worse is compensating for spaces in filenames.
  - freework 13y ago
    Thats what tab completion is for.
    - quackerhacker 13y ago
      Thank you freework, didn't know about that one (embarrassing as it is to admit). Still sucks dealing with spaces when it comes to command processes like ffmpeg -i <no_tab>...but awesome for cd'ing or ls'ing!
      - 13y ago
dmourati 13y ago
Amazing how few people I've worked with have any concept of FHS.
quackerhacker 13y ago
/usr/games One of my pet peeves when I work on clusters before I even mess with the fstab or ufw is always deleting this folder.
- freework 13y ago
  You must be great at parties.
  - jlgreco 13y ago
    Games can go in /usr/bin or /usr/local/bin or anywhere other reasonable location. What is next, /usr/editors ? /user/browsers ? It is senseless.
    - housel 13y ago
      /usr/games has been around since Unix v7, released in 1979. Before there were package managers, putting optional features in a designated place was the only way to conveniently control them. There were once systems that controlled access to the /usr/games directory during work or daylight hours to keep game playing from interfering with other users on the multiuser system.
- kryten 13y ago
  Why bother. Just leave it there.
  - quackerhacker 13y ago
    It's just a pet peeve. Since alot of the clusters I work on are web servers or parallel computing servers (that still have access through to a network), I like to clear out any dirs and files that aren't needed, mount ro access to any dirs that shouldn't be written to, and do every other thing I do to lock down the server. It's helped me before detect unauthorized files that contained malicious code.
chalst 13y ago
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: > 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 1. /bin contains the executables needed at boot time; 2. /usr/bin contains the other executables used by the OS installation; 3. /usr/local/bin contains executables installed by the system administrator that are not part of the base OS. 4. ~/bin contains the user's own executables. > 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. > 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. On the Unix&Linux SX - http://unix.stackexchange.com/a/11917/5197 http://unix.stackexchange.com/a/11917/5197
- klrr 13y ago
  Thanks! I've always thought /usr/bin was for software later installed (due to its name "user slash binaries") and thought /usr/local/bin was useless. This actually makes more sense, gonna start installing programs to /usr/local/bin now.
  - atsaloli 13y ago
    Here is what the Unix manual from Bell Labs (the origin of Unix) says about /usr/bin versus /bin: Commands generally reside in directory /bin (for binary programs). Some programs also reside in /usr/bin, to save space in /bin. There were hardware limitations in the early days of Unix. Short command names (like “ls” and “rm”) were used to save memory and paper (teletypes were used in the days before video terminals). Each byte mattered back then. There must have been a constraint on how much they could put in /bin (I am guessing). Here is the manual: http://plan9.bell-labs.com/7thEdMan/ http://plan9.bell-labs.com/7thEdMan/
contingencies 13y ago
/srv 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 /var/www/ and /var/lib/... paths for different daemons to me.
chacham15 13y ago
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?
- ordinary 13y ago
  http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
IvyMike 13y ago
Not enough people know this, but when you say "etc" out loud in reference to the directory, it is supposed to sound like "etsy". 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".
- oneeyedpigeon 13y ago
  Why?
  - IvyMike 13y ago
    Faster to say, and that's how I learned it in 1992. This is one of those "jif" v. "gif" holy war issues. (Maybe "etc" is a minor skirmish rather than a full blown war.)
    - anigbrowl 13y ago
      Faster to say A poor excuse for advancing illiteracy in both the linguistic and operational spaces. It's faster to say, but you've also made it harder for the lay person to understand. This sort of user hostility is a general problem in Linux; we are long since liberated from the days of unreliable teletype links, and the fetish for 3-letter contractions and abbreviated commands like cp and mv (instead of copy and move) does absolutely nothing to foster computer literacy.
      - IvyMike 13y ago
        Man you really harshed the mood on what I thought was just a cute little bit of old-timey unix lore.
        anigbrowl 13y ago
        Sorry, I didn't mean it that way. I used to love such insider knowledge as well, but over time I've become convinced that it's an anti-pattern that drives away more people than it attracts.
TerraHertz 13y ago
Some related articles: 20120128 http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... Understanding the bin, sbin, usr/bin, usr/sbin split 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. 20030430 http://www.osnews.com/story/3431 http://www.osnews.com/story/3431 http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page2/ http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page... http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page3/ http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page... If I Had My Own Distro (Linux)
nathell 13y ago
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).
Aissen 13y ago
Unfortunately this is obsolete in many modern distros, including Fedora and Archlinux, because of the /usr merge: http://fedoraproject.org/wiki/Features/UsrMove http://fedoraproject.org/wiki/Features/UsrMove Also it doesn't take /run into account (for which many distros had a hack before settling on /run).
bbanyc 13y ago
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. /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.
merlincorey 13y ago
In FreeBSD, we have `man hier` HIER(7) FreeBSD Miscellaneous Information Manual HIER(7) NAME hier — layout of file systems
cabalamat 13y ago
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). Gobolinux: http://www.gobolinux.org/ http://www.gobolinux.org/
- kmicklas 13y ago
  Nix/NixOS (http://nixos.org/ http://nixos.org/) is a more modern package manager/distro with many goals similar to GoboLinux, but that is actively maintained and has a number of other benefits.

153 points by alexholehouse 13y ago

deleted 13y ago

[deleted]

I think the Filesystem Hierarchy Standard is a better resource than this. Version 2.3 can be browsed at http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html. Development of version 3.0 (the first update since 2004) began in 2011; you can see a draft at http://www.linuxbase.org/betaspecs/fhs/fhs/index.html http://www.linuxbase.org/betaspecs/fhs/fhs/index.html

yajoe 13y ago
I've used linux for years (15? 20? get off my lawn... :) Thank you for posting this link! I never knew why the paths were what they were, I could only explain what to expect in each.

talloaktrees 13y ago

I wrote a utility called 'dirhelp' that can give you info on any directory: https://github.com/jrenner/linux-directory-help https://github.com/jrenner/linux-directory-help It's written in Go, binaries are available in the repo

alexholehouse 13y ago
This is so truly, fantastically excellent. This should be a standard system utility!
javert 13y ago
I haven't actually tried it, but that's really nifty looking. I made something not dissimilar, which lists all the man page sections for a given term with a brief description, to help you pick the right section.
talloaktrees 13y ago
mistake: I wrote 'any' directory, but that's not true. It has a limited set of information, but I tried to make it as complete as possible.
yankcrime 13y ago
hier(7) accomplishes largely the same thing.

hendry 13y ago

I prefer the simpler filesystem proposal from http://sta.li/filesystem http://sta.li/filesystem 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?

javert 13y ago
The whole stali idea is pretty cool. I was wondering recently if there could be any role for something like Docker in an experimental/radically different Linux distro.
derefr 13y ago
One thing I've never been able to figure out is where to store web-application code for webserver backends not associated with any particular vhost. I ended up deciding to package them as full "applications" under /opt, but this still feels a bit off. Under stali, would these be in /svc?
gizmo686 13y ago
That looks like a really cool idea. One thing I don't like about its filesystem is its insistence that all binaries go into /bin. As a user, I greatly appreciate the concept of having some sort of /local directory to distinguish between files (or just executable in this case) which the end user installed and which are part of the distribution. If you abandon the idea that /bin has no subdirecories, then I could see /bin/local as a viable alternative (although I think I would still prefer a /local folder where that had /local/bin, /local/etc ...).
- dredmorbius 13y ago
  The point of standards is that they define how others (distros, vendors) should interact with your system. Debian Policy makes this more explicit by noting that it defines what packages (and hence: package maintainers) must do, may do, and must not do. Among the latter: other than creating some of the hierarchy under /usr/local, packages may not delete content under this tree. That is for local system management. Similarly, /opt as a location where third-party vendors can install their crap, excuse me, packages, is a pretty well established standard. Note too that you can offer the filesystem view independent of the underlying storage view, whether by symlinks (e.g., ln -s /usr/local/opt /opt), union mounts, or other means. Any parts of the filesystem you create outside the defined standards are pretty much yours to worry about, though I've also got extreme reservations about polluting the root filesystem excessively. Better to create a structure under /usr/local or elsewhere (if for no other reason: it simplifies backups). This is a practice often respected in the breach in reality, however....

FreakyT 13y ago

I never understood why this hasn't been modernized. The three-letter nearly-meaningless directory names seem so obsolete.

trafficlight 13y ago
They are easy to type and do have meaning in and of themselves.
- eru 13y ago
  > [...] have meaning in and of themselves. Mostly because of long usage.
e3pi 13y ago
I gather you're also not versed in the unix command line? Piping and redirecting long dir paths thru commands and arguments welcomes everything abbreviated. The mnemonics is just engineered happiness sugar-on-top of all the intrinsic greatness.
quackerhacker 13y ago
Unless your ssh'd into a machine, it's annoying to type long dir's. What's worse is compensating for spaces in filenames.
- freework 13y ago
  Thats what tab completion is for.
  - quackerhacker 13y ago
    Thank you freework, didn't know about that one (embarrassing as it is to admit). Still sucks dealing with spaces when it comes to command processes like ffmpeg -i <no_tab>...but awesome for cd'ing or ls'ing!
    - 13y ago

dmourati 13y ago

Amazing how few people I've worked with have any concept of FHS.

quackerhacker 13y ago

/usr/games One of my pet peeves when I work on clusters before I even mess with the fstab or ufw is always deleting this folder.

freework 13y ago
You must be great at parties.
- jlgreco 13y ago
  Games can go in /usr/bin or /usr/local/bin or anywhere other reasonable location. What is next, /usr/editors ? /user/browsers ? It is senseless.
  - housel 13y ago
    /usr/games has been around since Unix v7, released in 1979. Before there were package managers, putting optional features in a designated place was the only way to conveniently control them. There were once systems that controlled access to the /usr/games directory during work or daylight hours to keep game playing from interfering with other users on the multiuser system.
kryten 13y ago
Why bother. Just leave it there.
- quackerhacker 13y ago
  It's just a pet peeve. Since alot of the clusters I work on are web servers or parallel computing servers (that still have access through to a network), I like to clear out any dirs and files that aren't needed, mount ro access to any dirs that shouldn't be written to, and do every other thing I do to lock down the server. It's helped me before detect unauthorized files that contained malicious code.

chalst 13y ago

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: > 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 1. /bin contains the executables needed at boot time; 2. /usr/bin contains the other executables used by the OS installation; 3. /usr/local/bin contains executables installed by the system administrator that are not part of the base OS. 4. ~/bin contains the user's own executables. > 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. > 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. On the Unix&Linux SX - http://unix.stackexchange.com/a/11917/5197 http://unix.stackexchange.com/a/11917/5197

klrr 13y ago
Thanks! I've always thought /usr/bin was for software later installed (due to its name "user slash binaries") and thought /usr/local/bin was useless. This actually makes more sense, gonna start installing programs to /usr/local/bin now.
- atsaloli 13y ago
  Here is what the Unix manual from Bell Labs (the origin of Unix) says about /usr/bin versus /bin: Commands generally reside in directory /bin (for binary programs). Some programs also reside in /usr/bin, to save space in /bin. There were hardware limitations in the early days of Unix. Short command names (like “ls” and “rm”) were used to save memory and paper (teletypes were used in the days before video terminals). Each byte mattered back then. There must have been a constraint on how much they could put in /bin (I am guessing). Here is the manual: http://plan9.bell-labs.com/7thEdMan/ http://plan9.bell-labs.com/7thEdMan/

contingencies 13y ago

/srv 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 /var/www/ and /var/lib/... paths for different daemons to me.

chacham15 13y ago

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?

ordinary 13y ago
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...

IvyMike 13y ago

Not enough people know this, but when you say "etc" out loud in reference to the directory, it is supposed to sound like "etsy". 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".

oneeyedpigeon 13y ago
Why?
- IvyMike 13y ago
  Faster to say, and that's how I learned it in 1992. This is one of those "jif" v. "gif" holy war issues. (Maybe "etc" is a minor skirmish rather than a full blown war.)
  - anigbrowl 13y ago
    Faster to say A poor excuse for advancing illiteracy in both the linguistic and operational spaces. It's faster to say, but you've also made it harder for the lay person to understand. This sort of user hostility is a general problem in Linux; we are long since liberated from the days of unreliable teletype links, and the fetish for 3-letter contractions and abbreviated commands like cp and mv (instead of copy and move) does absolutely nothing to foster computer literacy.
    - IvyMike 13y ago
      Man you really harshed the mood on what I thought was just a cute little bit of old-timey unix lore.
      - anigbrowl 13y ago
        Sorry, I didn't mean it that way. I used to love such insider knowledge as well, but over time I've become convinced that it's an anti-pattern that drives away more people than it attracts.

TerraHertz 13y ago

Some related articles: 20120128 http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... Understanding the bin, sbin, usr/bin, usr/sbin split 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. 20030430 http://www.osnews.com/story/3431 http://www.osnews.com/story/3431 http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page2/ http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page... http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page3/ http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page... If I Had My Own Distro (Linux)

nathell 13y ago

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).

Aissen 13y ago

Unfortunately this is obsolete in many modern distros, including Fedora and Archlinux, because of the /usr merge: http://fedoraproject.org/wiki/Features/UsrMove http://fedoraproject.org/wiki/Features/UsrMove Also it doesn't take /run into account (for which many distros had a hack before settling on /run).

bbanyc 13y ago

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. /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.

merlincorey 13y ago

In FreeBSD, we have `man hier` HIER(7) FreeBSD Miscellaneous Information Manual HIER(7) NAME hier — layout of file systems

cabalamat 13y ago

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). Gobolinux: http://www.gobolinux.org/ http://www.gobolinux.org/

kmicklas 13y ago
Nix/NixOS (http://nixos.org/ http://nixos.org/) is a more modern package manager/distro with many goals similar to GoboLinux, but that is actively maintained and has a number of other benefits.