Separate /bin and /sbin were so that Unix systems could start with a small, minimal, clean root disk that could be read only or effectively read only. The /usr partition was sometimes mounted separately, but this was more for proper organizational/systems design division than it was for disk space reasons.
This is still a useful division in many Unix systems today (e.g. IOT) where starting from a known-good minimal image and then layering filesystems on top can help reduce complexity and prune the debugging tree.
It's not surprising that the ibm/redhat/systemd/freedesktop crowd doesn't care about this stuff, but it's unfortunate.
Peace to Rob, but disagree with his recollection and the motivation. This was a very active topic in the early commercial Unix days as POSIX etc. were being formulated. It was very common to keep a tar backup of / and to separate out your /usr mount not because you didn't have space on /, but because you wanted to be able to lose/upgrade/etc. / without impacting /usr, and perhaps to move/copy /usr to another machine. The separation of concerns, not the disk space, was a driver for why we did it that way.
Well you are wrong. All of that was a retcon after the fact. Ask the folks from Bell Labs because that's where the story comes from:
/usr meant Users. Duh.
They had one disk because disks were expensive. The disk got full, they got a second one, so they moved /usr to the second disk.
Then the root disk got even more full and they moved some binaries to /usr/bin purely for disk space reasons.
Then /usr got full but by this time it was too baked in to change so they invented /home and moved user home directories there on yet a third disk.
Union mounts and other such solutions hadn't been invented yet. It was entirely an ad hoc solution to an immediate problem. This is simply a historical fact. I don't know where the urge to retcon a bunch of justifications for it comes from.
> Then /usr got full but by this time it was too baked in to change so they invented /home and moved user home directories there on yet a third disk.
This does not align with my memory at all. /home came much later. Both AIX and SunOS/Solaris had it early, but not anywhere near as early as the / and /usr split.
I started using Unix (as a sysadmin and systems programmer) in about 1986, and my recollection is closer to Rob's.
1. Never used tar(1) for backups till much later, always dump(1),
2. Never wanted to separate backups or upgrades of / and /usr, but always wanted and needed to do that for /usr/local and wherever we put home dirs in those days (which I don't recall right now).
3. The / and /usr thing was definitely explained to me in terms of disk space, more by comparison with the VMS system I was also managing which had 1MB drives. But I was too late to have "been there".
It's entirely possible that there were multiple rationales/retcons at various stages, maybe in serial or parallel; we could all be right. My 'been there' is also from ~1986 (AT&T 3b2, 300 baud acoustically coupled to an AAA-30). That said, the idea of / immutability and /usr variability was highly valued for its systems encapsulation properties for many decades, regardless of how we got there. As others in this thread have indicated, it's still considered valuable for that reason in space-constrained and security-critical domains (e.g. IOT).
Separate /bin and /sbin were so that Unix systems could start with a small, minimal, clean root disk that could be read only or effectively read only. The /usr partition was sometimes mounted separately, but this was more for proper organizational/systems design division than it was for disk space reasons.
This is still a useful division in many Unix systems today (e.g. IOT) where starting from a known-good minimal image and then layering filesystems on top can help reduce complexity and prune the debugging tree.
It's not surprising that the ibm/redhat/systemd/freedesktop crowd doesn't care about this stuff, but it's unfortunate.