15 ms·

sbin Split [pdf]

127 points by Somasis 11y ago

deleted 11y ago
[deleted]
egwynn 11y ago
The reasons for the complexity are lame, but sometimes there are nice consequences. For instance, on FreeBSD you can pretty much just nuke /usr/local/ and be left with a functional base-system (broken configs notwithstanding).
GutenYe 11y ago
Well, Arch Linux simplify them all, everything is in usr/bin and others just symlink to usr/bin.
- vezzy-fnord 11y ago
  I believe Fedora was the first to begin this trend.
  - johnny22 11y ago
    https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove and people sure did hate on it too.
  - 4ad 11y ago
    Solaris did it first.
    - digi_owl 11y ago
      It seems like Fedora is driving Linux towards a half and half between Solaris and OSX. I would not care either way, except choices are being removed or made difficult in the process.
- loevborg 11y ago
  Nixos (https://nixos.org/nixos/manual/ https://nixos.org/nixos/manual/) goes one step further and eliminates `/bin` and `/usr` further (except for `/usr/bin/env` and `/bin/sh`!), putting all binaries in package-specific directories and constructing a PATH including all individual package `/bin`s.
  - digi_owl 11y ago
    You have something similar on Gobolinux, where /System/Links (/System/Index on 015) holds symlinks to whatever is housed in the /Programs directories. BTW, there exist a pair of programs/scripts in Gobolinux that provide the possibility of putting program dirs in arbitrary places. DetachProgram and AttachProgram. The first allow you to move a directory out of /Programs. The second symlinks a detached directory to /Programs. While i have yet to try it, i think these could be used to provide something akin to the /bin /usr/bin split on Gobolinux.
- justincormack 11y ago
  Simpler still would be everything in /bin. At least one distro does that, forget which.
cremno 11y ago
>I’m still waiting for /opt/local to show up... Well, he doesn't have to wait anymore: https://trac.macports.org/wiki/FAQ#defaultprefix https://trac.macports.org/wiki/FAQ#defaultprefix >Why is /opt/local the default install location for MacPorts?
bobba 11y ago
Can we also address .bash_rc, .bash_profile, .profile, /etc/bash.bashrc, disambiguation. I get tired of instructions advising me to put PATH and other modifiers in .bash_profile when that only works for a login shell. Doesn't work, as needed, if you are actually using Linux as your desktop system.
- yes_or_gnome 11y ago
  First, it's .bashrc and /etc/bashrc. http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html http://www.gnu.org/software/bash/manual/html_node/Bash-Start... .bashrc - is for non-login shells (not run with --login option). This is where you want to configure your PATH, so all shell invocations behave the same. You'll likely have the PATH modification as the first line, then you may want to source the system rc file (/etc/bashrc), and, usually, you'll have some interactive-only modifications such modifications to PS1. .bash_profile(, .bash_login, or .profile) - is used for login shells. You may have some reason to run some commands (personal MTOD!?). There may be good reason to manipulate PATH here, but I can't think of one. (The rbenv tool from the Ruby community insists using .bash_profile; I don't know why.) Finally, you end by sourcing the .bashrc.
  - bobba 11y ago
    Thanks for the clarification and highlighting my point with the comment about rbenv. I think I found the source of my confusion which is (http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html http://www.joshstaiger.org/archives/2005/07/bash_profile_vs....) "An exception to the terminal window guidelines is Mac OS X’s Terminal.app, which runs a login shell by default for each new terminal window, calling .bash_profile instead of .bashrc. Other GUI terminal emulators may do the same, but most tend not to.". That may explain why so many github projects recommend adding PATH and other env variables to .bash_profile.
  - thristian 11y ago
    Environment variables are automatically shared from a parent process to its child processes, so typically you'd want to set up your environment in ~/.profile (or ~/.bash_profile) so you only have to do the work once. This includes things like setting $PATH, $LESS, $EDITOR, $LS_COLORS and so forth. On the other hand, things like shell aliases are not automatically shared to child processes, so you need to set them up afresh in every shell you launch. Therefore, ~/.bashrc is the place for those things.
ghshephard 11y ago
I personally like the differentiation between /sbin (71 files) and /usr/sbin (195 files) on OpenBSD and /bin (42 files) and /usr/bin (336 files). I don't know if it's still the case, but at one point, everything required to boot up a system, and get to a ksh prompt, was in /sbin and /bin, and the only purpose for commands in /usr was for user interaction. When mentally modelling the purpose of the commands, it was nice to have that differentiation, particular the "Stuff in /usr is really for the user only, not needed to boot a system." Of course, I have no idea whether that still holds true - but it's still a good starting point.
- deleted 11y ago
  [deleted]
- ben_bai 11y ago
  Yes, it's still true. /(s)bin is for booting a minimal system i.e. for maintainance and those binaries are statically linked. /usr/(s)bin is the rest of the base system. /usr/local/(s)bin is for packages/ports.
frik 11y ago
There are/were small Linux distro that fit on a 3.5" floppy diskette. I remember one that required just a single floppy disk to boot and a later version came with a second floppy with additional applications. So the bin /usr/bin split was still useful in the early Linux era (I used such a floppy Linux til 2002 for misc purposes). A starting point: http://superuser.com/questions/130457/what-linux-fits-on-a-floppy-disk http://superuser.com/questions/130457/what-linux-fits-on-a-f...
brandonmenc 11y ago
The original version: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... I make everyone I hire and/or work with read it.
- DougMerritt 11y ago
  Unfortunate, considering a lot of it is wrong. "Just so" stories (a term from Kipling) are appealing and yet historically incorrect. For instance, /sbin and /usr/sbin/ did not exist in the 1970s at all, let alone in the early 1970s. I'm not sure exactly which system it first appeared in, but on BSD, which originally was add-ons to the Bell Labs distribution, it was not present in the 1986 4.3 BSD but did appear in the 1993 4.4 BSD. You can verify that, and search for it on other early Unixes, here, for instance: http://minnie.tuhs.org/cgi-bin/utree.pl http://minnie.tuhs.org/cgi-bin/utree.pl
  - brandonmenc 11y ago
    OK, it gets a couple small details wrong, but the rest appears to be true - that /usr was added for want of disk space and /sbin was for statically linked binaries. The point of passing this along is to show that some ingrained "truths" (ex: sbin is for system binaries!) are just historical artifacts of conditions that no longer apply.
davidw 11y ago
See also: Filesystem Hierarchy Standard: https://wiki.debian.org/FilesystemHierarchyStandard https://wiki.debian.org/FilesystemHierarchyStandard
ChuckMcM 11y ago
Interesting rant. Actually in 1990 people were complaining that SunOS took up too much disk space (well they always complained but whatever). And C (and unix) always had something of a naming / packaging problem. Of course long after the size of disks were "big enough" to hold everything in / putting things on different drives gave you more disk I/O's to play with and improved overall system performance. If you could get small drives today you could play with that yourself but it seems silly to have a 500GB disk mounted on /var/log :-). But more importantly for me over the years was putting the "OS" required user land stuff in one place and the "rest" of it in another place meant I could replace the kernel and userland code independently of restoring home directories and what not. These days I do that by mounting "my" stuff via NFS and making my servers basically completely replaceable with a re-imaging.
DougMerritt 11y ago
It gets the /sbin part wrong. /sbin and /usr/sbin/ did not exist in the 1970s at all, let alone in the early 1970s. I'm not sure exactly which system it first appeared in, but on BSD, which originally was add-ons to the Bell Labs distribution, it was not present in the 1986 4.3 BSD but did appear in the 1993 4.4 BSD. You can verify that, and search for it on other early Unixes, here, for instance: http://minnie.tuhs.org/cgi-bin/utree.pl http://minnie.tuhs.org/cgi-bin/utree.pl
deleted 11y ago
[deleted]

127 points by Somasis 11y ago

deleted 11y ago

[deleted]

The reasons for the complexity are lame, but sometimes there are nice consequences. For instance, on FreeBSD you can pretty much just nuke /usr/local/ and be left with a functional base-system (broken configs notwithstanding).

GutenYe 11y ago

Well, Arch Linux simplify them all, everything is in usr/bin and others just symlink to usr/bin.

vezzy-fnord 11y ago
I believe Fedora was the first to begin this trend.
- johnny22 11y ago
  https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove and people sure did hate on it too.
- 4ad 11y ago
  Solaris did it first.
  - digi_owl 11y ago
    It seems like Fedora is driving Linux towards a half and half between Solaris and OSX. I would not care either way, except choices are being removed or made difficult in the process.
loevborg 11y ago
Nixos (https://nixos.org/nixos/manual/ https://nixos.org/nixos/manual/) goes one step further and eliminates `/bin` and `/usr` further (except for `/usr/bin/env` and `/bin/sh`!), putting all binaries in package-specific directories and constructing a PATH including all individual package `/bin`s.
- digi_owl 11y ago
  You have something similar on Gobolinux, where /System/Links (/System/Index on 015) holds symlinks to whatever is housed in the /Programs directories. BTW, there exist a pair of programs/scripts in Gobolinux that provide the possibility of putting program dirs in arbitrary places. DetachProgram and AttachProgram. The first allow you to move a directory out of /Programs. The second symlinks a detached directory to /Programs. While i have yet to try it, i think these could be used to provide something akin to the /bin /usr/bin split on Gobolinux.
justincormack 11y ago
Simpler still would be everything in /bin. At least one distro does that, forget which.

cremno 11y ago

>I’m still waiting for /opt/local to show up... Well, he doesn't have to wait anymore: https://trac.macports.org/wiki/FAQ#defaultprefix https://trac.macports.org/wiki/FAQ#defaultprefix >Why is /opt/local the default install location for MacPorts?

bobba 11y ago

Can we also address .bash_rc, .bash_profile, .profile, /etc/bash.bashrc, disambiguation. I get tired of instructions advising me to put PATH and other modifiers in .bash_profile when that only works for a login shell. Doesn't work, as needed, if you are actually using Linux as your desktop system.

yes_or_gnome 11y ago
First, it's .bashrc and /etc/bashrc. http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html http://www.gnu.org/software/bash/manual/html_node/Bash-Start... .bashrc - is for non-login shells (not run with --login option). This is where you want to configure your PATH, so all shell invocations behave the same. You'll likely have the PATH modification as the first line, then you may want to source the system rc file (/etc/bashrc), and, usually, you'll have some interactive-only modifications such modifications to PS1. .bash_profile(, .bash_login, or .profile) - is used for login shells. You may have some reason to run some commands (personal MTOD!?). There may be good reason to manipulate PATH here, but I can't think of one. (The rbenv tool from the Ruby community insists using .bash_profile; I don't know why.) Finally, you end by sourcing the .bashrc.
- bobba 11y ago
  Thanks for the clarification and highlighting my point with the comment about rbenv. I think I found the source of my confusion which is (http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html http://www.joshstaiger.org/archives/2005/07/bash_profile_vs....) "An exception to the terminal window guidelines is Mac OS X’s Terminal.app, which runs a login shell by default for each new terminal window, calling .bash_profile instead of .bashrc. Other GUI terminal emulators may do the same, but most tend not to.". That may explain why so many github projects recommend adding PATH and other env variables to .bash_profile.
- thristian 11y ago
  Environment variables are automatically shared from a parent process to its child processes, so typically you'd want to set up your environment in ~/.profile (or ~/.bash_profile) so you only have to do the work once. This includes things like setting $PATH, $LESS, $EDITOR, $LS_COLORS and so forth. On the other hand, things like shell aliases are not automatically shared to child processes, so you need to set them up afresh in every shell you launch. Therefore, ~/.bashrc is the place for those things.

ghshephard 11y ago

I personally like the differentiation between /sbin (71 files) and /usr/sbin (195 files) on OpenBSD and /bin (42 files) and /usr/bin (336 files). I don't know if it's still the case, but at one point, everything required to boot up a system, and get to a ksh prompt, was in /sbin and /bin, and the only purpose for commands in /usr was for user interaction. When mentally modelling the purpose of the commands, it was nice to have that differentiation, particular the "Stuff in /usr is really for the user only, not needed to boot a system." Of course, I have no idea whether that still holds true - but it's still a good starting point.

deleted 11y ago
[deleted]
ben_bai 11y ago
Yes, it's still true. /(s)bin is for booting a minimal system i.e. for maintainance and those binaries are statically linked. /usr/(s)bin is the rest of the base system. /usr/local/(s)bin is for packages/ports.

frik 11y ago

There are/were small Linux distro that fit on a 3.5" floppy diskette. I remember one that required just a single floppy disk to boot and a later version came with a second floppy with additional applications. So the bin /usr/bin split was still useful in the early Linux era (I used such a floppy Linux til 2002 for misc purposes). A starting point: http://superuser.com/questions/130457/what-linux-fits-on-a-floppy-disk http://superuser.com/questions/130457/what-linux-fits-on-a-f...

brandonmenc 11y ago

The original version: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... I make everyone I hire and/or work with read it.

DougMerritt 11y ago
Unfortunate, considering a lot of it is wrong. "Just so" stories (a term from Kipling) are appealing and yet historically incorrect. For instance, /sbin and /usr/sbin/ did not exist in the 1970s at all, let alone in the early 1970s. I'm not sure exactly which system it first appeared in, but on BSD, which originally was add-ons to the Bell Labs distribution, it was not present in the 1986 4.3 BSD but did appear in the 1993 4.4 BSD. You can verify that, and search for it on other early Unixes, here, for instance: http://minnie.tuhs.org/cgi-bin/utree.pl http://minnie.tuhs.org/cgi-bin/utree.pl
- brandonmenc 11y ago
  OK, it gets a couple small details wrong, but the rest appears to be true - that /usr was added for want of disk space and /sbin was for statically linked binaries. The point of passing this along is to show that some ingrained "truths" (ex: sbin is for system binaries!) are just historical artifacts of conditions that no longer apply.

davidw 11y ago

See also: Filesystem Hierarchy Standard: https://wiki.debian.org/FilesystemHierarchyStandard https://wiki.debian.org/FilesystemHierarchyStandard

ChuckMcM 11y ago

Interesting rant. Actually in 1990 people were complaining that SunOS took up too much disk space (well they always complained but whatever). And C (and unix) always had something of a naming / packaging problem. Of course long after the size of disks were "big enough" to hold everything in / putting things on different drives gave you more disk I/O's to play with and improved overall system performance. If you could get small drives today you could play with that yourself but it seems silly to have a 500GB disk mounted on /var/log :-). But more importantly for me over the years was putting the "OS" required user land stuff in one place and the "rest" of it in another place meant I could replace the kernel and userland code independently of restoring home directories and what not. These days I do that by mounting "my" stuff via NFS and making my servers basically completely replaceable with a re-imaging.

DougMerritt 11y ago

It gets the /sbin part wrong. /sbin and /usr/sbin/ did not exist in the 1970s at all, let alone in the early 1970s. I'm not sure exactly which system it first appeared in, but on BSD, which originally was add-ons to the Bell Labs distribution, it was not present in the 1986 4.3 BSD but did appear in the 1993 4.4 BSD. You can verify that, and search for it on other early Unixes, here, for instance: http://minnie.tuhs.org/cgi-bin/utree.pl http://minnie.tuhs.org/cgi-bin/utree.pl

deleted 11y ago

[deleted]