5 ms·

The FHS (Filesystem Hierarchy Standard) [1] is the go-to reference for this sort of thing. It explains that `/bin` is for binaries that are essential before oth

The FHS (Filesystem Hierarchy Standard) [1] is the go-to reference for this sort of thing. It explains that `/bin` is for binaries that are essential before other file systems are mounted (e.g. in single user mode), and `/usr/bin` is for "most user commands" (all others). This allows you to keep a minimal local filesystem containing only the binaries needed for init to get the system running, and then `/usr` can be mounted, say, from a network share. This is useful because then network admins can install software to the common `/usr` share and make it immediately available to all machines which mount that share. The `/sbin` and `/usr/sbin` directories are for commands needed only by administrators, which will not normally be used by regular users. Most systems don't really require this separation, but it does make sense. Perhaps the historical reason for doing it is no longer a factor, but that doesn't mean it's perpetuated merely because of tradition. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html http://www.pathname.com/fhs/pub/fhs-2.3.html

hollerith 15y ago
I know about FHS and the rationale FHS uses for the continued existence of /usr, I just do not agree with it (nor with the existence of /usr/share).
- tmhedberg 15y ago
  I'm curious, what is your opposition to `/usr/share`? It seems quite logical to me as a place to store non-executable, read-only, shareable data like man pages and other documentation, fonts, keymaps, color profiles, game data, etc. Where else would you propose to store this sort of thing? I can't really think of a different location in the hierarchy that would make sense.
  - kstenerud 15y ago
    Because everyone's idea of what "makes sense" is different. Thus: /bin /usr/bin /usr/share/bin /usr/share/local/bin /usr/local/bin /usr/local/share/bin /opt/bin /opt/some/clever/path/system/bin Followed by hacky symlinks so that programs can find what they're looking for in /usr/local/share/lib/x, which really resides in /usr/share/lib/x or maybe /var/lib or maybe /var/local/lib or maybe just /lib because it's considered "essential" on some systems but not others. It reminds me of this: http://xkcd.com/927/ http://xkcd.com/927/
    - jonhohle 15y ago
      Perhaps you have some misbehaving software, but I've never seen /usr/share/bin, or /usr/local/share/bin or a lib directory in either of those locations. I just checked FreeBSD boxes (which, admittedly, follow their own standards closely), and a Redhat box. var is a directory which may be found under /usr or /usr/local, but won't contain a local directory. Think of it as 3 roots: / is required for boot, /usr is stuff maintained by an administrator (say, company wide), /usr/local is where files installed by local users go. Within each of these 3 roots, you'll have some subset of bin, etc, lib, libexec, sbin, and var. The root directory has some additional singleton directories which don't make sense in the other directories: dev, root, mnt, boot, proc, rescue.
      - X-Istence 15y ago
        /usr is maintained by the OS, and contains stuff that isn't required for boot but to round out the system. /usr/local is where local modifications to the OS go, these can be site-wide (company wide) and can be hosted on NFS for example for network boots. User installed stuff belongs in /usr/home/<name>/*. Users shouldn't have root access to install stuff in /usr/local.
        lmm 15y ago
        Side point: it really bothers me that on freebsd the ports system takes over /usr/local. I expect /usr/local to consist of things that I as admin have installed by hand, and nothing else.
        elehack 15y ago
        Agree totally. NetBSD uses the more sensical /usr/pkg for package-managed software, leaving /usr/local for the admin.
        X-Istence 15y ago
        You can change where packages are installed using some make.conf flags. You can then install the software anywhere you want. Your users will need to add the new path to their PATH and you'll need to set some flags in rc.conf to pick up the new rc.d path as well (so software installed through ports gets auto-started). Then again, when you install ports you as the sysadmin are installing those by hand ...
  - hollerith 15y ago
    Well, first let me extend your explanation of the rationale for /usr/share: the reason for having a place to store not-executable shareable data is that in some network environments, it helps to have to maintain only one copy of this data, on some file server somewhere, which then gets mounted over the network to every machine. We need to keep /usr/share separate from /usr/bin, the rationale continues, because our network might be heterogenous in executable formats. In other words, some networks cannot maintain only one centrally-maintained copy of /usr/bin because some machines need, e.g., the x86 version of /usr/bin and some need the ARM version. In contrast, every machine can mount the same version of /usr/share. Now suppose you are an admin for a network in which the numerical software foocode is a big deal. the software contains a large read-only database of numbers, which according to the logic of the FHS goes into /usr/share/foocode/. Now suppose that some machines upgrade to a new version of foocode which for performance reasons stores integers in some specialized format, not the ones-complement format that has become something of a standard. So now, if we continue to apply the logic that motivated the creation of /usr/share in the first place, we need a place to put numbers of the new format so that they are kept separate from the numbers in the old format. Thus /usr/share/ones_complement/foocode and /usr/share/new_format/foocode are created. Suppose further that yet another version of foocode is released, and again that some machines are upgraded to it and some are not. This new version introduces a new, more performant format for the database in which the numbers are stored. Well, if the old format is called the 'hyperbolic' format and the new format is called the 'elliptical' format, then the logic that led us to create /usr/share leads us to create /usr/share/ones_complement/hyperbolic/foocode, /usr/share/ones_complement/elliptical/foocode, /usr/share/new_format/hyperbolic/foocode and /usr/share/new_format/elliptical/foocode. My point is that at some point you need to move to some way of assigning 'attributes' (and "read-only, shareable, non-executable" would be an example of an attribute) to files in some way other than putting those attributes in the name of the file. It would have been better for that point to have arrived before the FHS caused programmers around the world to have to type /usr/share/emacs/23.3/lisp 500 million times when /emacs/23.3/lisp would have done. What would this other way of assigning attributes to files be? A detailed explanation would be too many words for a HN comment. For the specific problems mentioned in this comment, namely, centrally-adminned file servers, you probably make your net-mount command more complicated like they did in Plan 9. ADDED. div and mod are well know numeric functions, right? The mere fact that some group of people would like some convenient way to refer to all the numeric functions does not justify requiring every programmer to write numeric/div and numeric/mod (or numeric :: div and numeric :: mod) every time they want to use or refer to one of those functions. I say the same argument applies to /usr and /usr/share.
ta12121 15y ago
FYI, the linked post completely contradicts what you wrote.
gchpaco 15y ago
The central thing about all these conventions is they developed in the absence of good union mounts. In Plan 9 there is no $PATH: all such things are bound into /bin. This works both because Plan 9 has very good union mounts, but also because those union mounts can be localized to a specific process and as a result are user accessible. I seem to recall some work was done to make this possible on Linux but It didn't get accepted into the main kernel because it is at odds with how we see how a Unix system should behave. It would be interesting to see a Linux distro that embraced this.
- pmarin 15y ago
  I wonder why rc still has $path in Plan9. term% echo $path . /bin What happen with Ape ports whom expect the path environment variable?
  - 4ad 15y ago
    rc has $path because rc predates Plan9, it first appeared in tenth edition Unix. Inferno's shell doesn't use a $path variable.
  - p9idf 15y ago
    Ape's execlp() tries first the program name passed to it (be it relative or absolute), and if that fails it prepends "/bin/" and tries again. It ignores environment variables entirely.† Rc's path variable allows you to easily tell rc to check the current directory when looking for programs to exec. Doing that with bind after each cd would be clumsy. And if your working directory is a remote server, you can set path to just /bin so that you aren't statting the remote directory before each exec. Inferno's sh does use a path variable, but it is typically left unset and the default (/dis .) is used.†† † See http://plan9.bell-labs.com/sources/plan9/sys/src/ape/lib/ap/plan9/execlp.c http://plan9.bell-labs.com/sources/plan9/sys/src/ape/lib/ap/... †† See /usr/inferno/appl/cmd/sh/sh.b:/^runexternal
zobzu 15y ago
`quote'

hollerith 15y ago

I know about FHS and the rationale FHS uses for the continued existence of /usr, I just do not agree with it (nor with the existence of /usr/share).

tmhedberg 15y ago
I'm curious, what is your opposition to `/usr/share`? It seems quite logical to me as a place to store non-executable, read-only, shareable data like man pages and other documentation, fonts, keymaps, color profiles, game data, etc. Where else would you propose to store this sort of thing? I can't really think of a different location in the hierarchy that would make sense.
- kstenerud 15y ago
  Because everyone's idea of what "makes sense" is different. Thus: /bin /usr/bin /usr/share/bin /usr/share/local/bin /usr/local/bin /usr/local/share/bin /opt/bin /opt/some/clever/path/system/bin Followed by hacky symlinks so that programs can find what they're looking for in /usr/local/share/lib/x, which really resides in /usr/share/lib/x or maybe /var/lib or maybe /var/local/lib or maybe just /lib because it's considered "essential" on some systems but not others. It reminds me of this: http://xkcd.com/927/ http://xkcd.com/927/
  - jonhohle 15y ago
    Perhaps you have some misbehaving software, but I've never seen /usr/share/bin, or /usr/local/share/bin or a lib directory in either of those locations. I just checked FreeBSD boxes (which, admittedly, follow their own standards closely), and a Redhat box. var is a directory which may be found under /usr or /usr/local, but won't contain a local directory. Think of it as 3 roots: / is required for boot, /usr is stuff maintained by an administrator (say, company wide), /usr/local is where files installed by local users go. Within each of these 3 roots, you'll have some subset of bin, etc, lib, libexec, sbin, and var. The root directory has some additional singleton directories which don't make sense in the other directories: dev, root, mnt, boot, proc, rescue.
    - X-Istence 15y ago
      /usr is maintained by the OS, and contains stuff that isn't required for boot but to round out the system. /usr/local is where local modifications to the OS go, these can be site-wide (company wide) and can be hosted on NFS for example for network boots. User installed stuff belongs in /usr/home/<name>/*. Users shouldn't have root access to install stuff in /usr/local.
      - lmm 15y ago
        Side point: it really bothers me that on freebsd the ports system takes over /usr/local. I expect /usr/local to consist of things that I as admin have installed by hand, and nothing else.
        elehack 15y ago
        Agree totally. NetBSD uses the more sensical /usr/pkg for package-managed software, leaving /usr/local for the admin.
        X-Istence 15y ago
        You can change where packages are installed using some make.conf flags. You can then install the software anywhere you want. Your users will need to add the new path to their PATH and you'll need to set some flags in rc.conf to pick up the new rc.d path as well (so software installed through ports gets auto-started). Then again, when you install ports you as the sysadmin are installing those by hand ...
- hollerith 15y ago
  Well, first let me extend your explanation of the rationale for /usr/share: the reason for having a place to store not-executable shareable data is that in some network environments, it helps to have to maintain only one copy of this data, on some file server somewhere, which then gets mounted over the network to every machine. We need to keep /usr/share separate from /usr/bin, the rationale continues, because our network might be heterogenous in executable formats. In other words, some networks cannot maintain only one centrally-maintained copy of /usr/bin because some machines need, e.g., the x86 version of /usr/bin and some need the ARM version. In contrast, every machine can mount the same version of /usr/share. Now suppose you are an admin for a network in which the numerical software foocode is a big deal. the software contains a large read-only database of numbers, which according to the logic of the FHS goes into /usr/share/foocode/. Now suppose that some machines upgrade to a new version of foocode which for performance reasons stores integers in some specialized format, not the ones-complement format that has become something of a standard. So now, if we continue to apply the logic that motivated the creation of /usr/share in the first place, we need a place to put numbers of the new format so that they are kept separate from the numbers in the old format. Thus /usr/share/ones_complement/foocode and /usr/share/new_format/foocode are created. Suppose further that yet another version of foocode is released, and again that some machines are upgraded to it and some are not. This new version introduces a new, more performant format for the database in which the numbers are stored. Well, if the old format is called the 'hyperbolic' format and the new format is called the 'elliptical' format, then the logic that led us to create /usr/share leads us to create /usr/share/ones_complement/hyperbolic/foocode, /usr/share/ones_complement/elliptical/foocode, /usr/share/new_format/hyperbolic/foocode and /usr/share/new_format/elliptical/foocode. My point is that at some point you need to move to some way of assigning 'attributes' (and "read-only, shareable, non-executable" would be an example of an attribute) to files in some way other than putting those attributes in the name of the file. It would have been better for that point to have arrived before the FHS caused programmers around the world to have to type /usr/share/emacs/23.3/lisp 500 million times when /emacs/23.3/lisp would have done. What would this other way of assigning attributes to files be? A detailed explanation would be too many words for a HN comment. For the specific problems mentioned in this comment, namely, centrally-adminned file servers, you probably make your net-mount command more complicated like they did in Plan 9. ADDED. div and mod are well know numeric functions, right? The mere fact that some group of people would like some convenient way to refer to all the numeric functions does not justify requiring every programmer to write numeric/div and numeric/mod (or numeric :: div and numeric :: mod) every time they want to use or refer to one of those functions. I say the same argument applies to /usr and /usr/share.

ta12121 15y ago

FYI, the linked post completely contradicts what you wrote.

gchpaco 15y ago

The central thing about all these conventions is they developed in the absence of good union mounts. In Plan 9 there is no $PATH: all such things are bound into /bin. This works both because Plan 9 has very good union mounts, but also because those union mounts can be localized to a specific process and as a result are user accessible. I seem to recall some work was done to make this possible on Linux but It didn't get accepted into the main kernel because it is at odds with how we see how a Unix system should behave. It would be interesting to see a Linux distro that embraced this.

pmarin 15y ago
I wonder why rc still has $path in Plan9. term% echo $path . /bin What happen with Ape ports whom expect the path environment variable?
- 4ad 15y ago
  rc has $path because rc predates Plan9, it first appeared in tenth edition Unix. Inferno's shell doesn't use a $path variable.
- p9idf 15y ago
  Ape's execlp() tries first the program name passed to it (be it relative or absolute), and if that fails it prepends "/bin/" and tries again. It ignores environment variables entirely.† Rc's path variable allows you to easily tell rc to check the current directory when looking for programs to exec. Doing that with bind after each cd would be clumsy. And if your working directory is a remote server, you can set path to just /bin so that you aren't statting the remote directory before each exec. Inferno's sh does use a path variable, but it is typically left unset and the default (/dis .) is used.†† † See http://plan9.bell-labs.com/sources/plan9/sys/src/ape/lib/ap/plan9/execlp.c http://plan9.bell-labs.com/sources/plan9/sys/src/ape/lib/ap/... †† See /usr/inferno/appl/cmd/sh/sh.b:/^runexternal

zobzu 15y ago

`quote'