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.
Interesting this use case wasn't covered in the mailing list post, I too experienced this exact reason for them being split in the early 90s. In that era, a lot of university terminals were very low end (small disks) - they mounted shares if they ran as Netware clients as well, not just Unix/Linux/BSD. Some of them only had boot floppies.
This was one of those few cases were the split was necessary. You could ship a very small initrd via bootp (or floppy, or much later, CDROM), and once it came up it could mount /usr over NFS. In case there were problems with the NFS mount, you still had some utilities in /bin for troubleshooting. The alternative was 'remote root NFS', where the root filesystem itself was NFS, and any network problems hosed the machine entirely. Trying to attach some alternative troubleshooting tools into a thin-terminal, or customize the bootp server to boot a troubleshooting image just for the one malfunctioning box, was a lot more painful than just shipping troubleshooting tools in /bin.
> 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.
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.
Doesn't this seem backwards? Given that the usr prefix doesn't mean anything anymore, wouldn't it make more sense to just put everything in /bin and keep /usr/bin as a symlink for backwards compatibility and eventually drop it?
To be fair there is a useful difference between /usr and /opt being that /usr and /usr/local are prefixes so software designed to be installed in a prefix can commingle sanely.
/opt is for programs that don’t follow any sort of FHS and need to be installed in their own world. Google Chrome and Mathematicia come to mind.
/opt/local makes total logical sense as the counterpart to /usr/local.
> A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store.
[Insert obligatory xkcd quote about competing standards.]
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.
env hasn't always been in /usr/bin. I've worked on systems (probably SunOS 4.something) that had /bin/env but not /usr/bin/env. But you're unlikely to run into any reasonably modern Unix-like system that doesn't have /usr/bin/env .
Quick summary:
The advantage of "#!/usr/bin/env INTERP" is that it will use the first INTERP in the user's $PATH.
The disadvantage is that it will use the first INTERP in the user's $PATH.
If neither /bin/sh nor /usr/bin/env are standard but both are defacto standards, then where is the relative value of `#!/usr/bin/env sh` over `#!/bin/sh` ?
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.
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.
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.
Page sizes on the PDP-11 are 8kb. Its successor the VAX had 512b pages. I don't think there's any PDP-11 heritage there. The filesystem organzation has more to do with disk sizes than the pdp-11. Also the pdp-11 wasn't a microcomputer but a minicomputer.
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).
Yes, /bin is a directory where the bind[1] command can be used to multiplex/union other directories on top. The / directory in general is built this way as a virtual top directory, with the disk root being stored on /root and being bound over /.
Platform-specific files are stored in /$architecture and binaries in /$architecture/bin. Shell scripts are stored in /rc/bin. For the home directory, traditionally, this style is reversed so your shell scripts would be in $home/bin/rc.
The namespace for any process can be enumerated, so in my default shell, I can see which directories are currently bound (and how) on /bin:
pro's of using 9p, /bin is where everything goes but you can bind any directory to it. so no worrying about running out of disk space since you can mount more disks.
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.
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.
The email is space-stuffed meaning it was probably written with format=flowed[1] (you can tell because there are spaces appended to hard-wrapped lines). That RFC was invented precisely for the purpose you mention: hard wrap lines in "dump" plain text clients, but allow "intelligent" clients to soft-wrap according to their own display width.
This email would display at full-width in a client that respects format=flowed (many modern email readers, except for, notably, Outlook and Gmail). But as others have pointed out, this is literally just the plain text of the email wrapped in a <pre> tag, so you get the hard line breaks.
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.
In Firefox's reader mode, click the "Aa" icon in the left-sidebar and you'll see -><- and <--> icons for changing the line length. Click <--> a couple times.
You're not wrong, but this is plaintext in its purest form. It's literally just plaintext wrapped in a <pre> tag. They don't use any CSS on the site, besides the very infrequent `style` tag. This is more common with the type of people who use text-based browsers like lynx. (edit: As another comment says, note they use 80 chars)
But as someone who has bash aliases for extracting text from a website so I can read it in my terminal (or page it with `less -r`), yes, this is something that bugs me too.
[+] [-] teddyh|6 years ago|reply
[+] [-] gravitas|6 years ago|reply
[+] [-] JdeBP|6 years ago|reply
[+] [-] peterwwillis|6 years ago|reply
[+] [-] rjsw|6 years ago|reply
The /bin and /sbin directories would be on the boot partition/disk and would contain the programs needed to get to multiuser state.
I still use multiple partitions, even on a 1TB disk.
[+] [-] Lammy|6 years ago|reply
https://www.freebsd.org/cgi/man.cgi?hier(7)
[+] [-] throw0101a|6 years ago|reply
> 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
It can also be used to create a hierarchy:
* https://github.com/freebsd/freebsd/tree/master/etc/mtree
[+] [-] oftenwrong|6 years ago|reply
I believe Arch takes it further and combines /bin and /sbin (and /usr/sbin) by symlinking them to /usr/bin.
[+] [-] gweinberg|6 years ago|reply
[+] [-] oat_bravo_nap|6 years ago|reply
https://fedoraproject.org/wiki/Features/UsrMove
https://wiki.debian.org/UsrMerge
[+] [-] kseistrup|6 years ago|reply
[+] [-] the_af|6 years ago|reply
[+] [-] saagarjha|6 years ago|reply
Wait no more, MacPorts installs to this by default.
[+] [-] Spivak|6 years ago|reply
/opt is for programs that don’t follow any sort of FHS and need to be installed in their own world. Google Chrome and Mathematicia come to mind.
/opt/local makes total logical sense as the counterpart to /usr/local.
[+] [-] Fnoord|6 years ago|reply
> A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store.
[Insert obligatory xkcd quote about competing standards.]
[1] https://nixos.org/nixos/about.html
[+] [-] jt2190|6 years ago|reply
Edit: No, I’m wrong. /opt/<provider name>/...
https://www.softwarecollections.org/en/docs/guide/#sect-The_...
[+] [-] ape4|6 years ago|reply
https://fedoraproject.org/wiki/Features/UsrMove
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] peterwwillis|6 years ago|reply
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.
[+] [-] _kst_|6 years ago|reply
See also my Stack Exchange answer on the advantages and disadvantages of the "#!/usr/bin/env ..." convention: https://unix.stackexchange.com/a/29620/10454
Quick summary: The advantage of "#!/usr/bin/env INTERP" is that it will use the first INTERP in the user's $PATH. The disadvantage is that it will use the first INTERP in the user's $PATH.
[+] [-] catalogia|6 years ago|reply
[+] [-] duckerude|6 years ago|reply
[+] [-] beefhash|6 years ago|reply
You would be correct about that. And that sucks.
[+] [-] kyuudou|6 years ago|reply
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.
[+] [-] lmm|6 years ago|reply
[+] [-] ipnon|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] aap_|6 years ago|reply
[+] [-] cbm-vic-20|6 years ago|reply
[+] [-] santiagobasulto|6 years ago|reply
[+] [-] tyingq|6 years ago|reply
[+] [-] smcl|6 years ago|reply
edit: Clearly I'm missing something in the linked article because I'm being downvoted. Could someone show me what I'm missing?
[+] [-] 0xdeadb00f|6 years ago|reply
[+] [-] QuesnayJr|6 years ago|reply
[+] [-] ainar-g|6 years ago|reply
[+] [-] henesy|6 years ago|reply
Platform-specific files are stored in /$architecture and binaries in /$architecture/bin. Shell scripts are stored in /rc/bin. For the home directory, traditionally, this style is reversed so your shell scripts would be in $home/bin/rc.
The namespace for any process can be enumerated, so in my default shell, I can see which directories are currently bound (and how) on /bin:
[1] http://man.cat-v.org/9front/1/bind[+] [-] skrebbel|6 years ago|reply
It's like having fond memories of Hillary Clinton's inauguration speech.
[+] [-] nmz|6 years ago|reply
Also, gobolinux tries to mimic this behavior as well. https://www.gobolinux.org/
[+] [-] rhizome|6 years ago|reply
[+] [-] dang|6 years ago|reply
2015: https://news.ycombinator.com/item?id=9554134
2012: https://news.ycombinator.com/item?id=3519952
(Links for the curious. Reposts are ok after a year: https://news.ycombinator.com/newsfaq.html)
[+] [-] Jaruzel|6 years ago|reply
---
[1] https://en.wikipedia.org/wiki/Linux_Standard_Base
[+] [-] remmargorp64|6 years ago|reply
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|6 years ago|reply
[+] [-] fulldecent2|6 years ago|reply
[+] [-] Taniwha|6 years ago|reply
[+] [-] wjdp|6 years ago|reply
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?
[+] [-] gpanders|6 years ago|reply
This email would display at full-width in a client that respects format=flowed (many modern email readers, except for, notably, Outlook and Gmail). But as others have pointed out, this is literally just the plain text of the email wrapped in a <pre> tag, so you get the hard line breaks.
[1]: https://joeclark.org/ffaq.html
[+] [-] peapicker|6 years ago|reply
[+] [-] rhizome|6 years ago|reply
[+] [-] acoard|6 years ago|reply
But as someone who has bash aliases for extracting text from a website so I can read it in my terminal (or page it with `less -r`), yes, this is something that bugs me too.