5 ms·

> It is because on old Unix systems there frequently wasn't enough space to store /usr on the root disk. It was really a single system in 1971 that kicked off

> It is because on old Unix systems there frequently wasn't enough space to store /usr on the root disk. It was really a single system in 1971 that kicked off this trend. Originally /usr was for user files, like /home is today (do you'd have /usr/dmr, /usr/ken, etc.) / and /usr were two physical disks, and at some point the / disk (a 1 or 2MB disk IIRC) was full to they put some things from /bin in /usr/bin as a hack. And it's "stuck" since then. This is why /usr has such a weird name, because it was intended for user files (/system, /software, /additional or something would make more sense, abbreviated to /sys, /sw, or /add of course). Initially Unix was a quickly developing system for internal use, but it was actually used and there was often some tension between "do the right thing" vs. "don't break too much". Some of the weird things in C are due to that as well (e.g. &'s precedence being a good example). I guess some other systems that ran Unix ran in to similar problems, but by the time unix started to gain some adoption in the mid to late 70s disks were larger too, so I don't know if it was ever really needed beyond that initial research unix system used only internally at Bell Labs. I believe they updated the disks on the original Unix system not too long after this making this hack superfluous, but they kept it for compatibility (and because it might be useful again in the future).

hyperdimension 5y ago
Is that also where /usr/share got its name for application data? Data that's shared among the rest of the users, as opposed to in their respective homedirs?
- cellularmitosis 5y ago
  share is for architecture-independent data (ie data which is “shared” by all architectures). Executable binaries are not shared, but things like man pages are.
  - bodyfour 5y ago
    I believe it dates back to the heyday of diskless workstations. It was commonplace to have dozens of workstation machines getting their OS files over NFS from a central server. Thus why the (per-machine, read-write) /var became standardized. Earlier /usr contained a mix of writable things (like /usr/log). Now it was important to make /usr something that could be NFS mounted read-only by a bunch of NFS clients. There were also UNIXes that ran on multiple architectures, like SunOS on 68k and SPARC. In theory, you could have them both use the same read-only /usr/share mount and save some resources on the server. I say "in theory" because I don't know how many sites ever implemented this in practice. There were definitely places that supported mixed-architecture diskless fleets, but I'm unsure how many of them were committed to keeping the OS version pinned between them... or how many then went through the extra work to make /usr/share a separate mountpoint. I'm sure some people did it, but it's not something I remember seeing personally. Still, I feel it's somewhat useful to help humans understand what parts of a package are CPU-specific and which aren't. Probably good that it's lived on.
- slim 5y ago
  I think /usr/share is linux specific. so much later
  - valleyer 5y ago
    It exists on BSDs as well. (No idea who did it first.)
    - bodyfour 5y ago
      I think the first place I saw it was on SunOS 4, but not sure if that was the first. Definitely existed pre-Linux
      - usr1106 5y ago
        Around 1990 I used Unix clusters. Not only 68000 Sun mixed with SPARC, but also the other Unix workstation vendors. There was a lot of NFS and also completely diskless machines. /usr/share always meant it's architecture-independent and can be used by machines of any architecture.
xenadu02 5y ago
I am so happy to see that this correct explanation has finally spread. When I first started posting on HN the standard response you would get was the retcon explanation like the parent comment or even more nonsensical ones like "usr == UNIX system resources". At the time cursory searching could not find any actual explanations for this. I started a deep dive into Usenet history and reaching out to folks who knew the history, looking for scraps of info in old Unix books, etc and found the correct explanation as you posted. It was entirely an ad hoc solution to running out of disk space. /usr got moved to the second disk. When root got full again they moved some large binaries to /usr/bin. When the /usr disk got full the user home directories were the easiest thing to move so they moved to /home on a third disk. Every other explanation is purely post-hoc rationalization. Since then I've been pointing it out when the topic comes up and I am happy that general knowledge of the actual history has started to spread. Note: I am not taking credit for this, many other people have been correcting the story both before and after me. I'm just glad the true story is seeping into the collective tech community. Sometimes misinformation or incorrect "facts" seem to linger no matter how many times and how many people correct them... but this makes me hopeful that misinformation can be corrected.
- danmur 5y ago
  Your comment makes me want to make up some new nonsense and try to spread it in here. I'll restrain myself though :)

hyperdimension 5y ago

Is that also where /usr/share got its name for application data? Data that's shared among the rest of the users, as opposed to in their respective homedirs?

cellularmitosis 5y ago
share is for architecture-independent data (ie data which is “shared” by all architectures). Executable binaries are not shared, but things like man pages are.
- bodyfour 5y ago
  I believe it dates back to the heyday of diskless workstations. It was commonplace to have dozens of workstation machines getting their OS files over NFS from a central server. Thus why the (per-machine, read-write) /var became standardized. Earlier /usr contained a mix of writable things (like /usr/log). Now it was important to make /usr something that could be NFS mounted read-only by a bunch of NFS clients. There were also UNIXes that ran on multiple architectures, like SunOS on 68k and SPARC. In theory, you could have them both use the same read-only /usr/share mount and save some resources on the server. I say "in theory" because I don't know how many sites ever implemented this in practice. There were definitely places that supported mixed-architecture diskless fleets, but I'm unsure how many of them were committed to keeping the OS version pinned between them... or how many then went through the extra work to make /usr/share a separate mountpoint. I'm sure some people did it, but it's not something I remember seeing personally. Still, I feel it's somewhat useful to help humans understand what parts of a package are CPU-specific and which aren't. Probably good that it's lived on.
slim 5y ago
I think /usr/share is linux specific. so much later
- valleyer 5y ago
  It exists on BSDs as well. (No idea who did it first.)
  - bodyfour 5y ago
    I think the first place I saw it was on SunOS 4, but not sure if that was the first. Definitely existed pre-Linux
    - usr1106 5y ago
      Around 1990 I used Unix clusters. Not only 68000 Sun mixed with SPARC, but also the other Unix workstation vendors. There was a lot of NFS and also completely diskless machines. /usr/share always meant it's architecture-independent and can be used by machines of any architecture.

xenadu02 5y ago

I am so happy to see that this correct explanation has finally spread. When I first started posting on HN the standard response you would get was the retcon explanation like the parent comment or even more nonsensical ones like "usr == UNIX system resources". At the time cursory searching could not find any actual explanations for this. I started a deep dive into Usenet history and reaching out to folks who knew the history, looking for scraps of info in old Unix books, etc and found the correct explanation as you posted. It was entirely an ad hoc solution to running out of disk space. /usr got moved to the second disk. When root got full again they moved some large binaries to /usr/bin. When the /usr disk got full the user home directories were the easiest thing to move so they moved to /home on a third disk. Every other explanation is purely post-hoc rationalization. Since then I've been pointing it out when the topic comes up and I am happy that general knowledge of the actual history has started to spread. Note: I am not taking credit for this, many other people have been correcting the story both before and after me. I'm just glad the true story is seeping into the collective tech community. Sometimes misinformation or incorrect "facts" seem to linger no matter how many times and how many people correct them... but this makes me hopeful that misinformation can be corrected.

danmur 5y ago
Your comment makes me want to make up some new nonsense and try to spread it in here. I'll restrain myself though :)