from Hacker News

Understanding the bin, sbin, usr/bin, usr/sbin Split [pdf]

by Somasis on 5/15/15, 10:45 PM with 25 comments

• by bobba on 5/16/15, 3:53 AM

  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.

• by ghshephard on 5/16/15, 4:40 AM

  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.

• by cremno on 5/16/15, 3:04 AM

  >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

  >Why is /opt/local the default install location for MacPorts?

• by frik on 5/16/15, 7:56 AM

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

• by egwynn on 5/15/15, 11:48 PM

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

• by ChuckMcM on 5/16/15, 3:33 PM

  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.

• by brandonmenc on 5/16/15, 8:09 AM

  The original version:

  http://lists.busybox.net/pipermail/busybox/2010-December/074...

  I make everyone I hire and/or work with read it.

• by GutenYe on 5/16/15, 2:54 AM

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

• by DougMerritt on 5/16/15, 6:43 PM

  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

• by davidw on 5/16/15, 12:28 PM

  See also: Filesystem Hierarchy Standard:

  https://wiki.debian.org/FilesystemHierarchyStandard