Hacker News Reader

Comment by IMMUNISE | Hacker News Reader

The history of /usr and /home are pretty amusing too:

'When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).' - http://lists.busybox.net/pipermail/busybox/2010-December/074...

View on HN

I found it funny that random decisions from 60s, 70s, 80s still have repercussions on how we use computers today, because backwards compatibility beats cleanliness every time.

Be right back, solving some Windows backslash and CRLF issues.

It’s not just software. A mechanical engineer once explained to me that the size of the Space Shuttle was influenced by the width of a Roman road, which was influenced by the width of two horses walking side-by-side.

It's a fun myth but it's not true. The SRBs for the Space Shuttle were designed to satisfy their mission criteria. While any similarity between US rail widths today and Roman roads is due more to happenstance than a direct result.

https://www.snopes.com/fact-check/railroad-gauge-chariots/

> What's True: The standard U.S. railroad gauge is similar in width to the wheel spacing of Roman chariots.

> What's False: That similarity is based much more on coincidence and inherent physical limitations than a direct line of imitation.

The width of chariots/wagons/car/trains doesn't vary all that much, not compared to stuff like sailing ships.

But the Space Shuttle SRBs have a considerably larger diameter (3.7m compared to 1.435m rails) so it's more likely due to civil engineering standards: you can only transport something so big until you need to take down power lines and cut down trees.

The Falcon 9 has the same diameter and it was explicitly chosen because it's the maximum transportable by road.

Um, nope. The choice of railroad gauge was a historical artifact: in the beginning, everyone had a different gauge, then we had like 15 gauge standards and "standards", and one of them eventually prevailed (through British administrative fiat). The choice was not due to an inherent superiority of this particular gauge, but due to a campaign by George Stephenson. From there, it was mostly network effect: popularity breeds popularity.

Gauge is, most of all, a tradeoff between construction costs (tunnels, bridges, cuttings, oh my! Every additional inch of the gauge gets real expensive in Actual Terrain; ditto for train stations: narrow gauge can fit many more tracks next to each other), and between operating costs (wider gauge cars can be wider _and_ higher, as they're inherently more stable; thus, more cargo on same number of cars).

( ObXkcd: https://xkcd.com/927/ )

On another note, human intelligence is limited by the width of the birth canal.

Interestingly, some distros have undone/are undoing the usr split, fedora around 2012 and Debian still ongoing, see https://wiki.debian.org/UsrMerge and its associated links

On NixOS:

    % find /bin /usr
    /bin
    /bin/sh
    /usr
    /usr/bin
    /usr/bin/env

/usr and /bin are only there to provide sh and env for compatibility with shell scripts.

If nothing is in /bin or /usr/bin, where do proggies live? And what does your path look like?

In the Nix store (/nix):

    % which cp
    /run/current-system/sw/bin/cp

Each package has its own path in the nix store:

    % readlink $(which cp)
    /nix/store/l96gc2qb8ysnf5hcq1hp5a3r6x905rf4-coreutils-8.31/bin/cp

The current system and previous systems also live in the store (Nix has atomic upgrades/rollbacks). Each system can be seen as a package with symlinks to binaries, man pages, etc. in the store. More information about the motivation behind Nix's approach can be found in Nix Pill 1:

https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t...

In NixOS, they are probably under some directory with a random name.

This is the OS where each binary runs with a different path and library path, with only the programs it needs (on the versions it needs) linked there.

Yes, the UsrMove project. It is great leadership to go to the trouble to fix things like this. https://fedoraproject.org/wiki/Features/UsrMove

Why are they going from /bin to /usr/bin instead of /usr/bin to /bin ? I would have thought they could flatten things out.

A goal of Fedora was to have a "snapshottable" /usr that includes as much as possible (all?) of the generic OS files. That is, multiple machines running the same OS can have a shared /usr, and everything machine-specific in the other dirs.

See https://fedoraproject.org/wiki/Features/UsrMove#Why_don.E2.8...

> Myth #11: Instead of merging / into /usr it would make a lot more sense to merge /usr into /.

> Fact: This would make the separation between vendor-supplied OS resources and machine-specific even worse, thus making OS snapshots and network/container sharing of it much harder and non-atomic, and clutter the root file system with a multitude of new directories.

https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...

Weird edge cases where /usr is mounted, such as a read only network drive

Arch too, https://www.archlinux.org/news/binaries-move-to-usrbin-requi...

Character encodings using shift/unshift bytes were born out of serial transmission.

... Also check out those ^Zs at EOF, will ya.

Because there's this "never touch a running system" fear, deeply rooted in our industry.

The whole "move fast and break things" is a big lie, because you know that in that way, the system works, newer changes will break countless systems/scripts/etc

Also because doing the same thing over and over again "[because X for X in (consistency, security, esthetics, whatchamacallit)]" grows old fast - and by the time it's been fixed and running again, X is no longer there, or it's been totallty twisted out of the intended shape.

You are both correct.

There is a risk of change.

There is a risk of stasis.

I think the latter is a much lesser risk, assuming the "works" in "if it works" is indeed correct. After all, sure, /usr has a funny history, but in practice it doesn't really bother anyone.

That could be the case. One example of the cost of stasis: the / vs /usr requirement in the FHS might stop or complicate future technical possibilities that use the filesystem (packaging systems, distros, copy on write snapshots etc) from being possible. Sure it's a low cost in this instance, but there's always a cost.

It's one more thing people have to learn. For that reason it imposes an ongoing cost.

The CS department at UT Austin added a /lusr mount for locally-compiled software like the GNU tools; putting /lusr/bin at the start of your path made all of the various systems behave more or less alike.

Pronounced "loser".

/home came much later. I don't think they ever had it at bell labs.

usr stands for Unix System Resources, not user.

That's a backronym. It was originally short for user.

http://bitsavers.trailing-edge.com/pdf/bellLabs/unix/Prelimi...

See page 9.

Reply on news.ycombinator.com