
Understanding the bin, sbin, usr/bin, usr/sbin split (2010) - rohitpaulk
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
======
teddyh
For quite some time it was common for workstations to have a bare-bones OS
installed on their small hard drives, but for /usr to be mounted via NFS to a
large server with a large disk. This also, for a long time, justified the
split.

~~~
JdeBP
See
[https://utcc.utoronto.ca/~cks/space/blog/unix/DisklessUnixAn...](https://utcc.utoronto.ca/~cks/space/blog/unix/DisklessUnixAndUsr)
and the comment by Greg A. Woods.

~~~
korethr
In that article, he discusses mounting the machine-specific /etc (and the base
root fs implied thereby) via NFS. I recall playing with the design for a small
group of diskless of linux worstations (which I never actually built, because
there was nothing I actually needed it for, it was just a fun idea). My design
didn't mount root via NFS, but rather, each machine was supposed to be
entirely stateless, booting from the network with PXE, getting a minimal
rootFS and kernel from tftp, and then mounting /usr and /home via NFS.

I don't recall if these boxen were then supposed to act as X-terminals, with
only GUI display happening locally, and all execution happening on another box
on the network, or if that was its own hey-wouldn't-it-be-cool-to-build-this-
useless-but-nifty-thing-I-don't-need kind of project.

~~~
tristor
I did an academic clustering project at one point with Cluster Knoppix, which
booted over TFTP much like this. Shared data for the calculations was mounted
with a script via NFS, and everything else was memory resident/stateless via
PXE boot of a Live image.

------
Lammy
Tangentially related, one of my favorite FreeBSD manual pages: hier(7)

[https://www.freebsd.org/cgi/man.cgi?hier(7)](https://www.freebsd.org/cgi/man.cgi?hier\(7\))

~~~
throw0101a
See also mtree(8):

> _The default action, if not overridden by command line options, is to
> compare the file hierarchy rooted in the current directory against a
> specification read from the standard input. Messages are written to the
> standard output for any files whose characteristics do not match the
> specification, or which are missing from either the file hierarchy or the
> specification._

* [https://www.freebsd.org/cgi/man.cgi?mtree](https://www.freebsd.org/cgi/man.cgi?mtree)

It can also be used to create a hierarchy:

* [https://github.com/freebsd/freebsd/tree/master/etc/mtree](https://github.com/freebsd/freebsd/tree/master/etc/mtree)

------
oftenwrong
Recent Debian and Ubuntu systems symlink (by default, possibly with
exceptions) /bin, /sbin, and /lib* to their counterparts in /usr. Older
systems may be able to perform the merge by installing the "usrmerge" package.

I believe Arch takes it further and combines /bin and /sbin (and /usr/sbin) by
symlinking them to /usr/bin.

~~~
the_af
Do you know in which Ubuntu version this showed up? I just tested on my Ubuntu
16.04 (I know, I know) and they are not symlinked.

~~~
oftenwrong
I believe Ubuntu started being usrmerged-by-default in 19.04 (Disco Dingo),
although the release notes do not mention it.

On 16.04 you can usrmerge your system by installing the usrmerge package:

[https://packages.ubuntu.com/xenial/usrmerge](https://packages.ubuntu.com/xenial/usrmerge)

------
saagarjha
> I'm still waiting for /opt/local to show up...

Wait no more, MacPorts installs to this by default.

~~~
cosarara
I wonder what the next step is then. /local? /usr/opt?

~~~
Spivak
RedHat actually has /var/opt and /etc/opt which, while odd, makes some sense
since /opt is a free-form /usr and still needs variable space and configs.

~~~
rhizome
and which preserves the functional separations between the hier elements and
doesn't require changing any backup procedures.

------
ape4
Effort to clean it up: UsrMove

[https://fedoraproject.org/wiki/Features/UsrMove](https://fedoraproject.org/wiki/Features/UsrMove)

------
peterwwillis
And this has led to de facto standards, like '#!/bin/sh' is a 'standard' shell
shebang, but not POSIX; if you want your script to be portable, you have to
use '#!/usr/bin/env sh'. _env_ is forever in '/usr/bin' probably because it
first came about after new tools started moving to '/usr'. And I don't think
_env_ 's file path is even in POSIX, it's just a de facto standard.

Another fun fact is that _execve()_ (which executes shebangs) only allows a
single argument to the shebang program. Meaning if you use '#!/usr/bin/env
sh', you can't specify arguments to 'sh' in the shebang. In any case, the name
of the file being executed is appended as an additional argument at the end of
the shebang.

~~~
kyuudou
There's some debate about this if I recall correctly from the last deep dive I
did about the pros and cons of it.

If I am writing a script that needs to be _that_ portable, then I'll use
#!/usr/bin/env sh but otherwise /bin/sh will work in all the cases I need it
to.

Since bash's path might vary more, I might consider calling env to locate it
then more often.

~~~
naniwaduni
If you're writing a script that needs to be _that_ portable, you're doomed
anyway and you might even find the autoconf manual's "Limitations of Shell
Builtins" section useful.

------
ipnon
The PDP-11 became super influential because it was the first machine that had
seemingly unbound performance for its price, compared to any computer from the
60s or 50s. This gave programmers the freedom "write to their hearts content,"
leading to the innovations of Unix and the C programming language. Compare it
to how modern web developers write entirely in the application domain, giving
no regard to operating system or machine constraints. I'm proposing that the
PDP-11 gave a similar feeling to programmers who had been restricted before,
to a programming process that today seems as streamlined as carving
hieroglyphics with a pickaxe.

Eventually though the new programs started pushing up against the limits of
the PDP-11. I propose that virtually anything that seems like magic in Unix or
C, from filesystem organization to page sizes, traces its origin directly back
to the PDP-11.

We are still living in the world of microcomputers, no matter how far we may
seem to have ventured away.

~~~
musicale
Wasn't UNIX originally hacked together in assembly language on an already-
obsolete PDP-7 that was sitting around unused?

And according to Dennis M. Ritchie, the B language that preceded C was also
first implemented on the PDP-7, whose auto-increment memory cells "probably"
inspired Ken Thompson to create B's ++ and -- operators.

------
santiagobasulto
Great story, I love these! Personally I always thought that the difference
between `bin` and `sbin` was that `sbin` contained binaries with _Superuser_
privileges (hence the `s` at the beginning).

~~~
tyingq
The s is for "statically linked". Binaries that run early enough in the boot
process that /usr/lib might not be there yet.

~~~
dredmorbius
Sources I find claim "system binaries":

[http://www.linfo.org/sbin.html](http://www.linfo.org/sbin.html)

~~~
ben_bai
Yes.

My system does it like this.

    
    
        /bin - static linked basic user commands
        /sbin - static linked system commands (incl. important daemons)
        /usr/bin - dynamic linked user commands
        /usr/sbin - dynamic linked system commands and system daemons
        /usr/local/bin - user commands installed via package
        /usr/local/sbin - system commands installed via package

------
ainar-g
IIRC, they got rid of all this in Plan 9. /bin was where binaries go. /usr was
for user data. There were also /proc, /net, and probably /tmp?

~~~
skrebbel
This Plan 9 nostalgia weirds me out. It never happened! It was vaporware all
along!

It's like having fond memories of Hillary Clinton's inauguration speech.

~~~
icedchai
I installed Plan 9 once back in the 90's. It certainly exists, it just never
reached mass levels of acceptance.

~~~
blaser-waffle
I installed it in the mid-2000s to be cool.

I'd say it's closer to the DMC DeLorean: short production run, works but has
short comings, more of a meme than an actual commodity.

It's not vaporware though, they definitely delivered something that works.
It's just that there wasn't a good reason to use it compared to other options.

------
dang
2016:
[https://news.ycombinator.com/item?id=11647304](https://news.ycombinator.com/item?id=11647304)

2015:
[https://news.ycombinator.com/item?id=9554134](https://news.ycombinator.com/item?id=9554134)

2012:
[https://news.ycombinator.com/item?id=3519952](https://news.ycombinator.com/item?id=3519952)

(Links for the curious. Reposts are ok after a year:
[https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html))

------
Jaruzel
I am sure that one of the original aims of the Linux Standard Base Project[1]
was to fix and simplify the default file system hierarchy, but researching it
now, it seems that they've backed away from doing anything drastic.

\---

[1]
[https://en.wikipedia.org/wiki/Linux_Standard_Base](https://en.wikipedia.org/wiki/Linux_Standard_Base)

------
remmargorp64
The confusing and nonsensical (not immediately obvious by typing ls and
reading) folder structure in unix/linux/etc has always been one of my biggest
complaints with it as an operating system.

I consider it to be a warning about the importance of refactoring and renaming
things sooner rather than later, because the longer that something sticks
around, the more dependencies it develops and the harder it is to change.

------
bcoughlan
How does the terminal work in Unix? Well, in 1869...
[https://www.linusakesson.net/programming/tty/](https://www.linusakesson.net/programming/tty/)

------
fulldecent2
In my life we will probably never have a man on the moon and never replace
POSIX.

------
Taniwha
minor nit - initrd/initramfs don't really precede linux

------
wjdp
What is with the insistence of (in-paragraph) hard line breaks on documents
still?

I put this page into Firefox's reader mode and I get lines breaking all over
the place as it's now got a mix of soft and hard line breaks.

Should presentation of line length not be up to the client?

~~~
peapicker
It it a <pre> formatted section from an old usenet post with 80 char line
length... often on usenet posts were specially formatted with whitespace
chars. Usenet display tools almost always use PRE and preserve that using
monospace fonts to preserve the full possibilities of the information
transfer.

~~~
cpach
It’s from a mailing list, not Usenet.

