So during the BSD / System V merge (project Lulu at Sun) the /opt filesystem was introduced as a way to keep 'packages' separate from 'system'. The difference between /bin and /sbin was that sbin was 'static-bin' which is to say everything in it was statically linked and could run without any libraries being available.
The fact that Linux starts up differently is because Linux never was UNIX they are two different OSes, pretty much from the ground up. They use similar concepts, processes, file descriptors, Etc, but they are two different species. FreeBSD on the other hand is a derivative of UNIX and last time I checked it started up in a similar way.
The lack of space on the RK05s was indeed the reason for the addition of /usr/{lib, bin} and the general consensus at Sun and AT&T in the 80's was that the root file system contained the system, and the /usr file system contained stuff that was not-system.
AT&T (the guys that 'owned' UNIX) had some pretty detailed specifications about what lived in what directory and why. It was a "BigDeal" (tm) to add a new directory in the root file system so new directories, when they were proposed, appeared under /usr. And once /opt existed it gave people free reign to create their own trees. Early package managers would build /opt/<package>/{bin/lib/share/man} and the downside was that ones path variable got longer and longer, and there arguments about if there should be more constraints on opt.
No, it really has nothing to do with that at all. Linux can boot in pretty much the same way the genetic Unixes do, and in fact did for a long time. initrd and then initramfs came later and took some time to become widely used. Historically, Linux just mounted whatever filesystem the bootloader told it to as /, and executed init, which usually followed either a BSD or System V model, depending on distribution.
Linux evolved. Lots of things evolved. The filesystem layout, unfortunately, has merely become more chaotic.
There were certainly sites that used /u for what is now commonly /home (or /export/home on Solaris, /Users on OS/X, ...) This was not something that predated "/usr" though: /usr was already added back in the early 1970s (the linked article was correct about that, although it got many other details wrong)
Basically /usr was originally only for home directories (as the name implies) Then it became the place for anything you didn't want to use the precious space on the root filesystem for (hence /usr/bin popped up, and later things like /usr/dict/words) Finally, it became so cluttered that people started locating home directories elsewhere and now the name "/usr" is completely unrelated to its actual purpose.
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.
It would be interesting to see a Linux distro that embraced this.
term% echo $path
. /bin
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/...
†† See /usr/inferno/appl/cmd/sh/sh.b:/^runexternal
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.
/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/
Of the paths you mentioned, there is no such thing as:
/usr/share/bin
/usr/share/local/bin
/usr/local/share/bin
/usr/local/share/lib
/usr/share/lib
/opt/bin
The `/opt` hierarchy is pretty much the wild west, I'll give you that. It's basically like `Program Files` on Windows; packages get an entire hierarchy to themselves. Most of the software I've seen that installs to `/opt` is Linux ports of Windows software, where the authors were either ignorant of the Unix way of organizing things, or simply didn't want to bother conforming with the norms of a different platform.
Incidentally, one of the reasons I prefer Arch Linux over some other distros is that the organization of the file system follows the standard and actually makes sense. Things are always where I expect them to be.
Your overall point may have some merit, but it feels a little like you're reaching for support for your position by making up wacky, confusing paths that don't actually exist.
My point is that what "makes sense" is subjective. Each developer/distro manager who made one of those paths thought to himself "it makes perfect sense to do it this way". FHS does go a long way towards cutting back on the craziness (by arbitrarily dictating "do it this way"), but it's still clunky.
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.
/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.
Then again, when you install ports you as the sysadmin are installing those by hand ...
Linux' failure to differentiate between system and non-system binaries is IMO one of it's worst features.
Neither FreeBSD nor Linux accommodate network mounted NFS mounted applications as well as SunOS did so successfully by the late '80s. This is probably due to the corrupting influence of Unix and Linux engineers who came from MS Windows backgrounds. Windows admins waste countless hours having to install software locally on every machine. Sad that only Solaris provides for a standard network-based application filesystem. Odd too that Solaris is home to the single most ill-thought-out non-system directory, /opt.
To me the BSD distinction doesn't make much sense anyway. You still have to just know which bits are "local" and which are not, plus anything I pull in that isn't a port gets lumped in with them anyway.
But i do remember seeing /usr/share/bin and /usr/share/local/bin and thinking wtf... But then i play around too much with my OS to reliably blame it on the distro...
Mac OS X, I think, has done a decent job of structuring the file system to be more user friendly despite the -nix background.
Modern use cases typically revolve around either installation and use of specific applications, often with dozens or hundreds of files needed, and data storage. In Windows/Mac, applications (for the most part) are installed into their own individual application folder and a GUI (as opposed to the PATH) is used to provide easy access to the application. This makes it easy to 1) know where to put a program you're installing, 2) know how to locate a program after install, and 3) keeps all the application components in a single place for easy move or removal.
In my somewhat limited experience with Linux, I find that the complicated nature of the file system makes package management systems necessary to simply keep track of where all the files are: executable in /usr/local/share/bin, configuration files in /etc, libraries in /usr/lib, and I'm not sure where non-binary resources of an application get stored.
I once installed my favorite browser (Opera) in Ubuntu. It didn't make a desktop or Applcation menu icon for some reason, so I figured I'd just go make a icon to point to it. It took quite a while to just figure out where the executable was at.
This could very well be one of the reasons that many people find Linux on the desktop difficult to use. They don't understand where anything goes.
I hope that one day one Linux distribution will at least step up and consider restructuring the file system to be more friendly and straight forward and to take advantage of the availability of long file names.
Only the most simple of Windows applications get away with putting everything into a single folder under $PROGRAM_FILES. More usually, lots of stuff is in $COMMON_FILES, and may or may not be shared. And these common files are tied in to the program files via a giant complicated global variable, the registry; the program looks up ProgIDs and CLSIDs to instantiate COM objects, so the registry becomes a very sensitive source of failure, particularly when you have different versions of $COMMON_FILES that break the various linkages.
Furthermore, these days Windows Installer is often used to manage the Windows equivalent of packages. These too are sensitive to corruption; if you end up missing the MSI files from c:\windows\installer for one reason or another, you can easily get into a situation where you can't even reinstall an application cleanly, because the installer notices that you already have it installed, and tries to uninstall it first, but fails (usually quietly, in the middle of the installation, where the progress bar goes into reverse and at the end you get a cryptic and unhelpful error message). To fix this, you must venture forth once more into the registry, find out the cryptic (hex) name for the relevant package, and surgically excise it. Not even the MSI/MSP/etc. files have meaningful names. It's tortuous.
All that said, I by far prefer working in Windows to any other OS. If it had a faster performing yet fully POSIX compliant layer as well integrated as Cygwin (i.e. not off in its own parallel little world like SFU/SUA), it would be even better.
1) Programs put themselves in various directories on my windows 7 machine, some are under \Program Files, some are under \Program filees (x86), some are \Programs and so on, variations and variations.
2) to locate a program you need to know its corporation, which people often dont know. There are setup.exe start.exe fireup.exe and run.exe and variations, which one should the user use to start the program?
3) all the applications components are not in a single place but are spread out over \Program-Files, \Windows\system, \windows\xx\xx and the registry at the least. Then they put stuff in \users\application data\ and \users\xx\applications or whatever.
You and many people dont understand where anything goes because unlike for Windows, GNU/Linux systems actually make sense and actually have a structure (that is different from windows) which you need to learn to operate the system, just as you learned to navigate the mess of windows.
Of course, I have installed things manually from source. But when I do, I only install them locally in my home directory.
So the complexity is there, I just haven't had to deal with it.
Also, I think that GUI-centrism is short-sighted, but that's another matter altogether. In short: command-line tools are just as "modern" as GUI tools; they're just harder to learn but tend to be more powerful.
dpkg-query --listfiles package-name
Understanding the bin, sbin, usr/bin , usr/sbin split
Content fetched 0 seconds ago