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 565688
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: ROFL
by Milo_Hoffman on Wed 26th Jun 2013 18:52 UTC 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[3]: ROFL
by Doc Pain on Thu 27th Jun 2013 05:21 in reply to "RE[2]: ROFL"
Doc Pain Member since:
2006-10-08

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


For statically compiled programs, some systems offer (or offered?) a specific /stand directory located on the root partition that contains programs to be used under absolute emergency circumstances.

As an example, the FreeBSD manual page for the file system hierarchy, "man 7 hier", explains /sbin as follows; "system programs and administration utilities fundamental to both single-user and multi-user environments".

Source: http://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7

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


The separation is intended and may even be useful.

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


This is possible. Non-Linux system sometimes keep the differentiation between /sbin and /usr/sbin and define /usr/sbin as follows: "system daemons & system utilities (executed by users)".

Those arguing that /sbin and /bin are useful for rescue, then explain to me what is the purpose of the initrd?


This concept and its execution is relatively specific to Linux, whereas the directory separation is more generic and applies to many kinds of UNIX and UNIX-alikes.

Drivers can perfectly be loaded from the disk or built into the kernel, what remains? The rescue prompt!


Sometimes you're lucky to get that far. ;-)

As I said, for normal users all this directory layout discussion does not matter. In case of an emergency that you today cannot even imagine, and under worst circomstances, you'll be happy about any separation and differentiation that lets your system come up to a state where you can start recovery procedures or other actions to get out of shit. Because you never know. And if you don't experience such kind of trouble: Be happy. Ignore the rest. It doesn't matter.

Reply Parent Score: 5

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