Linked by Thom Holwerda on Wed 26th Jun 2013 14:12 UTC
Linux "This document outlines the set of requirements and guidelines for file and directory placement under the Linux operating system according to those of the FSSTND v2.3 final (January 29, 2004) and also its actual implementation on an arbitrary system. It is meant to be accessible to all members of the Linux community, be distribution independent and is intended to discuss the impact of the FSSTND and how it has managed to increase the efficiency of support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems."
Thread beginning with comment 565684
To read all comments associated with this story, please click here.
ROFL
by lustyd on Wed 26th Jun 2013 18:41 UTC
lustyd
Member since:
2008-06-19

Wasn't it on OSNEWS last year that there was a direct quote by the guy who wrote the file system originally saying all this was nonsense? The reason for sbin and usr was down to the low capacity of hard drives and nothing else at all. A disk filled up so they made a reason to separate stuff to elsewhere. In hindsight this was a mistake as people now argue over the directory structure and purpose and nobody is willing to fix the mess and remove the excess.

Reply Score: 6

RE: ROFL
by Milo_Hoffman on Wed 26th Jun 2013 18:52 in reply to "ROFL"
Milo_Hoffman Member since:
2005-07-06

Nope.. sbin was originally for STATIC compiled binaries that could run stand alone and not need any dynamic libs to be loaded.

That is important for the early phases of bootup, and for single user rescue tasks, when /usr/lib is not mounted yet.


However, just using /bin+/lib on the root disk and /usr/bin+/usr/lib on the os disk would do the trick if you ask me.

Edited 2013-06-26 18:57 UTC

Reply Parent Score: 4

RE[2]: ROFL
by Vanders on Wed 26th Jun 2013 19:27 in reply to "RE: ROFL"
Vanders Member since:
2005-07-06

That is important for the early phases of bootup, and for single user rescue tasks, when /usr/lib is not mounted yet.

However, just using /bin+/lib on the root disk and /usr/bin+/usr/lib on the os disk would do the trick if you ask me.


In this day and age of bind mounts, why even bother? Have a small /bin & small /lib on the initrd and bind mount the disk over it.

Reply Parent Score: 3

RE[2]: ROFL
by MeinNick on Wed 26th Jun 2013 20:08 in reply to "RE: ROFL"
MeinNick Member since:
2013-03-14

No, sbin is for SYSTEM binaries. Anything that normal user will never run. sbin is usually not in user's PATH.

sbin and bin have their use and should/will remain separated forever.

/usr/bin /usr/sbin /usr/lib are redundant given the size of our disks however. In fact, a few distro create them as symlinks to /bin /sbin /lib.

Other distributions use the opposit, with symlinks behing in the root and real dir being in usr.

Those arguing that /sbin and /bin are useful for rescue, then explain to me what is the purpose of the initrd? Drivers can perfectly be loaded from the disk or built into the kernel, what remains? The rescue prompt!

Edited 2013-06-26 20:10 UTC

Reply Parent Score: 4

RE[2]: ROFL
by lustyd on Thu 27th Jun 2013 07:04 in reply to "RE: ROFL"
lustyd Member since:
2008-06-19

"Nope.. sbin was originally for STATIC compiled binaries that could run stand alone and not need any dynamic libs to be loaded. "

Oh really? The guys that created it would disagree...

http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bi...

Reply Parent Score: 5

RE: ROFL
by VistaUser on Thu 27th Jun 2013 02:25 in reply to "ROFL"
VistaUser Member since:
2008-03-08

I believe that Fedora (and therefore the next RHEL) has moved away from the standard directories to put everything inside usr/.

There are still symlinks from the old locations though.

Reply Parent Score: 2

RE: ROFL
by Soulbender on Thu 27th Jun 2013 10:11 in reply to "ROFL"
Soulbender Member since:
2005-08-18

Wasn't it on OSNEWS last year that there was a direct quote by the guy who wrote the file system originally saying all this was nonsense?


What it meant back then is not important, what's important what it means today and today it's an established *nix convention.

Reply Parent Score: 2