Understanding the bin, sbin, usr/bin , usr/sbin split
lists.busybox.net
lists.busybox.net
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.
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.
I wonder if this is the origin of the 'bin' user as well, because that's a design decision that never seemed to make any sense.
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.
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.
/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/
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.
NetBSD uses the more sensical /usr/pkg for package-managed software, leaving /usr/local for the admin.
Then again, when you install ports you as the sysadmin are installing those by hand ...
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.
Their being included in FHS does.
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...
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.
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.
System.Console.WriteLine
System.out.println
Ada.Text_Io.Put_Line
It would be interesting to see a Linux distro that embraced this.
term% echo $path
. /bin
Inferno's shell doesn't use a $path variable.
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
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.
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
dpkg -L package-name $ dpkg --search /etc/apt/
debconf, apt: /etc/aptOnly 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.
Wait no longer: http://guide.macports.org/
A lot of Linux distributions by default suggest using the entire disk and creating a single partition named /. In that case it doesn't make sense to have the various different locations since mounting / means you have /usr/bin as well.
I don't want a user being able to fill up the hard drive stopping me from writing my logs, stopping me from logging in or various other things (yes, i've filled up my / partition at one point and was unable to log in because SSH was failing to log something or other). There are also security reasons and being able to set various security flags on mount makes it easier to secure a machine as well (such as noexec on /tmp and or /var).
/ on a FreeBSD system is generally kept small. It doesn't have softupdates on when using UFS2 since it is also the location where your kernel lives, along with rescue utilities and your main /bin. Nothing else.
The proposal as put forth is misguided (talking about Fedora's in this case) and I don't think that the system should be re-engineered just because that is the default use case these days. I remember when I first started using Linux and I created a separate, /boot, /, /usr, /home, and /tmp. Just because udev and others now fail to work correctly doesn't mean it isn't a good idea to keep those separate...
This is just going to cause more trouble, more fragmentation between unix/unix-like systems and Linux and it's various distributions.
FreeBSD recommends softupdates on all filesystems, including /.
Also, the LSB doesn't really apply much to the BSD's.
The installer may still not have softupdates on, but the installer is very very conservative about defaults, and probably hasn't changed since, well ever. However, from the handbook http://www.freebsd.org/doc/en/books/faq/disks.html#SAFE-SOFT...
"9.4. Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems.
Short answer: you can usually use Soft Updates safely on all partitions.
Long answer: There used to be some concern over using Soft Updates on the root partition. ..."
/var should go on a separate partition so that the log files don't fill up the partition that /tmp is on. A server can easily generate large log files quickly, and it would be unfortunate if that caused the server to fail in weird ways at inconvenient times.
Makes no logical sense. When you create an (inter-disk) partition you reduce the blocks available to all remaining partitions on that disk. By reducing partition size you _increase_ the probability of all remaining partitions filling.
If you had said adding disks for /tmp and /var were indicated I might agree, but would still be wondering what kind of applications you have.
Looking back at Unix' history we see that partitioning was only added before RAID and only to accommodate additional disks. It is the failure to understand this history and rational that leads certain sysadmins to believe that inter-disk partitions accomplish anything other than reducing robustness (in absence of a badly behaved application, which is 99% of the time a badly configured server or application, per the log rotation example).
http://www.gobolinux.org/index.php?page=doc/articles/clueles...
The really hacky solution to that seems to be building versioned packages in versioned directory paths (e.g. "/opt/lib/db/4/4.2/4.2.52/libdb.so") and mess with linker paths and create a sprawling tree of symlinks and wrappers for weird use cases. With a custom package manager it works really well: run 6 conflicting versions of the same library and just build apps against the library you know works, instead of fighting to get everything running on one compatible library.
Would you mind buying me a memory upgrade when this happens? I'll need one.
Roughly how many processes are you running? Can anyone give a wild-assed guess how much memory it take to boot and load gmail in FireFox on a statically linked Linux?
If you somehow managed to get a statically linked Firefox (I think it would be very difficult, given the degree to which Drepper has abandoned the idea) on a modern Linux system, though, the resource usage would admittedly probably be quite impressive.
Thus, to run a dynamically linked program you need to use the same amount of memory as you would a statically linked program.
However, if you are lucky (or have enough RAM), there is a chance that you won't have to load the page containing the library as it may already be in memory.
So there is a valid argument that to take full advantage of dynamically linked libraries you need more memory than for statically linked libraries.
This situation has only improved a little. There are still lingering bits of it here and there, depending on how deeply you poke and which distribution you have installed.
ArchLinux, for example, still really, really wants you to make a /boot.
I have an encrypted laptop that boots from a read-only USB key that is attached to my keyring. It will only boot from this keyring (and a backup CD-R that I have), and the system and the boot media are never stored together. Before USB keyrings became common, I would have the boot media be a CD-R.
The Fedora move is why this link got posted and is getting upvotes.
$ for f in /bin/*; do [ -e "/usr$f" ] && echo /usr$f; done;
/usr/bin/dumpkeys
/usr/bin/ksh
/usr/bin/less
/usr/bin/lessecho
/usr/bin/lessfile
/usr/bin/lesskey
/usr/bin/lesspipe
/usr/bin/loadkeys
/usr/bin/mail
/usr/bin/nano
/usr/bin/tcsh
/usr/bin/touch
/usr/bin/which
/usr/bin/zsh
FreeBSD's default install creates: /, /usr, /tmp, /var and swap space.
When you boot in single-user mode all you get is / and nothing else. If everything was in /usr you wouldn't be able to mount /usr ... :P
See man hier [1].
For example, on a FreeBSD install, it is perfectly safe to rm -rf /usr/local/. Your system will still boot without issues.
[1] http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...
On linux to configure a wireless device you have iwconfig and ifconfig. And you have to use each in a different order to get it work. Whereas in FreeBSD I have ifconfig and it does all of it.
Eg, an alias on a vlan on a bond.
Does 'ip' have a form that just prints the current addresses without all the surrounding cruft? That would be pretty useful for the occasional shell script.
ip -4 addr show dev eth0 or ip -6 a s eth0There is an argument that it's nice to be able to upgrade libraries and have everyone pick them up, but in practice that's mostly a myth because such upgrades are vulnerable to nasty small failures. Another argument is that is saves hard disk space - not an issue these days (perhaps it is in a small number of embedded systems still).
Any good counters to that?
Update: thanks for response. I found the link to the Drepper article linked elsewhere in this thread v informative also.
With static linking, that would clearly not happen.
Also, these libraries/frameworks are not exactly small, not even for todays hard drives, so the de-duplication does make some sense (and that is not factoring in the smaller size of SSDs). That said, I guess you could make this into an argument for filesystem level deduplication instead of dynamic linking.
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.
My understanding for the latter is that /bin is "normal stuff", while /sbin is system maintenance. But, hey, maybe that split is actually there for obsolete historical reasons, too. Does anyone know?
As someone with only 2 years Linux experience, this blows my mind
So no, it does not replace a working /.
If it's needed to boot, it goes in root: boot images (including root filesystem) can be initrds, bootp images, flash sticks, or other similar tools. Maintaining the discipline of keeping what you need in / and what you don't need to boot in /usr helps when you're trying to minimize boot images, troubleshoot, and/or just simply keep things comprehnsible.
Different partitions can be mounted differently: There are still a few things in the root FS which are written periodically, especially in /etc. By contrast, /usr is largely static. They can be mounted writeable vs. read-only (dittos /boot BTW). Root may require device permissions. Both require suid (but /home doesn't). For various degrees of security and self-inflicted foot-gunshot incidents, mounting with minimal permissions can be useful.
Not all bootloaders handle all filesystems and storage: Applies more to /boot, but particularly for exotic / networked storage, ensuring that early-stage bootstrapped filesystems are accessible with a minimum of fuss can be useful.
The arguments from Fedora about the ability to manage a system from within an initramfs are particularly amusing given RHEL's traditional use of a non-interactive, script-only shell: Yes, that's right, you can't exit out of the initramfs shell to do maintenance. Debian's 'dash' shell is not only smaller than the RHEL equivalent, but supports interactive use. Go figure. (Apologies if this has changed recently but it was true as of the past year or so).
Shared/network mount purposes: A read-only, shared /usr filesystem can be used and accessed by multiple systems. Maintaining the root /usr split ensures that local system commands (if necessary) can be provided independently of the shared bits.
While the origins of /bin vs. /usr/bin lie in what are now largely irrelevant disk capacity constraints, there are a number of reasons why maintaining the split continues to make sense. As has been noted, a fair bit of hierarchy persistence is on account of differentiating between differently-managed packages at different parts of the system. As the guy who gets to come in, comprehend, rationalize, and clean up systems afterward, I can assure you that a logical ordering and seggregation does help markedly.
For distros with a decent package management policy and toolset, there's no particular problem to maintaining this. $PATH variables already make the end-user impact essentially nil.
For those who wish to combine things, union mounts or symlinks can certainly be used, again, with little or no end-user impact. For some embedded/small systems this makes sense. There's no reason to force one-size-fits-all on everyone, however.
I'm also generally opposed to arbitrarily adding top-level directory trees. The naming rarely stays consistent over time (business unit / institutional name changes are notorious). And it tends to complicate matters especially concerning backups and where essential local data lives.
Tempest in a teapot.
"Fedora (and other distributions) have begun work on getting rid of the separation of /bin and /usr/bin, as well as /sbin and /usr/sbin, /lib and /usr/lib, and /lib64 and /usr/lib64. All files from the directories in / will be merged into their respective counterparts in /usr, and symlinks for the old directories will be created instead"
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...
Of course, /bin will never be removed since there are millions of scripts depending on /bin/sh in the wild. So they'll basically end up having to maintain this symlink spaghetti for a long time.
You get wins on packaging (don't need to worry about where to scatter executables, although this doesn't affect many packages), as well as "all software is under /usr", so everything the package manager touches except config file updates is under a single directory. This makes both centralized updates and pre-update snapshotting much more feasible.
I'm really looking forward to this feature. With appropriate support from the file system and yum, it seems like it brings us one step closer to truly transactional multi-package system updates/software installations. Yes, some of this was already possible with snapshotting support in a plugin for Yum, but I think the consolidation will likely make implementing such features simpler and more robust.
More history bits like this please.
At the same time, makes you think about dropping FHS .. yeah I said it.
It is awesome, especially the easy rollback and that you can specify an entire system with a recipe. Still, it feels strange for us who are used to mainstream Unix systems.
And for that matter, another "unixy" OS uses "bundles" to keep all of an apps files together instead of splattering them all over the OS: Mac OS X.
As said before GOBO does that too; there was a handful of distros at max.
All this to save a few bytes in $PATH, to avoid problems with systemd, and to avoid fixing udev.
There are specific reasons why having a single mount point for all OS-provided binaries is a good idea, for example because maintaining a split that differs across distros and unixes is a maintenance nightmare. The main counterargument -- that it is desirable to have a minimally functional system without /usr mounted -- has been obsolete for years.
- If it's needed to boot the system, it belongs in /
- Binaries for normal users are in bin, system (i.e., root user only) binaries are in sbin
That's all.
What's attractive about /usr? A lot of things, but mostly: single export-point, possible to separately mount (from a network, read only, whatever), logically nice to have all those directories not polluting /.
I propose that / should contain the following directories:
/cfg/ /home/ /local/ /mnt/ /system/ /tmp/
You would mv /boot /dev /bin /sbin /var /root /proc /sys /usr /lib /run /system, then mv /opt /local
/etc/ is renamed /cfg/ just because I can and left in / because some things really are global configuration (and we can't be mounting /etc ro all the time).
But don't stop there, because now /system/ is a mess. You obviously still can't treat /system as /usr because e.g. /dev is there, so put /dev, /proc and /sys under /system/kernel, because these things are figments of the kernel's imagination anyway. Under /system/boot/ throw in a directory for your bootloader, initrd and whatnot and one for any statically-linked binaries you have, if you have any (hey, it's optional). No need for a lib, because it's all static or in the initrd. Just because I'm a mean curmugeon who hates greybeards and love n00bs, let's mv /system/var /system/data. Inside /system/usr let's merge files from games, bin and sbin into bin and get rid of the empty directories. Then mv /system/usr/local/ /local/usr/.
Speaking of /local/, it'd have two subdirs: /local/opt/ and /local/usr/. The former would contain an opt-style directory hierarchy and the latter would be like /system/usr, only with the purpose of the FHS /usr/local. Okay, so the /local/ stuff isn't to be found in an exported /system/usr/, but /local/ is just a fetish of mine. You could put it in /system/usr/, too. And yes, /system and part of its structure is required to be on / during boot. So sue me.
Now you have:
/cfg/ /home/ /local/ /local/usr/ /local/opt/ /mnt/ /system/ /system/data/ /system/boot/loader/ /system/boot/sbin/ /system/kernel/dev/ /system/kernel/proc/ /system/kernel/sys/ /system/root/ /system/run/ /system/usr/bin/ /system/usr/lib/ /system/usr/share/ /tmp/
Now you have a tree for homes, a tree for the whole system, which has a splits where you might need them for partitioning and exporting, a tree for configuration, which also has a name users can understand, a tree for non-packaged software, which allows for both crazy-opt style layout and traditional, and you have your global tmp and temporary mount point root.
Did I leave anyone out?
http://www.linuxtopia.org/online_books/linux_beginner_books/...
Its for serving using various services, so you would have /srv/http /srv/ftp and so on, you dont put packages/programs into /srv
For example /dev is defined by objective criteria, and thus there's not much argument to what goes into /dev. We should only have core directory structure defined by objective criteria.