Earlier quoted context omitted.
Adding to this historical reasoning, it is to be noted that in traditional Unix, /usr was pretty much the equivalent of /home in Linux systems: the parent directory for user home directories, i.e. 'usr'. The existence of /usr/bin can probably be explained by the reasoning that, just like nowadays Linux systems often have a really big /home partition, early Unix systems eventually ran out of space for whatever volume…
Careful, you'll attract computing historians who will want to tell you that "usr" actually stands for "UNIX system resources"
Debian still having trouble with merged /usr
271–280 of 310 posts
Re: Debian still having trouble with merged /usr
#272Just in case anyone is wondering why we had (or used to have) /bin and /sbin directories as well as /usr/bin /usr/sbin here is my understanding of it. It is because on old Unix systems there frequently wasn't enough space to store /usr on the root disk. Therefore /usr was a separate disk which might not be available during boot. This meant that you needed to put all the binaries you needed for boot in /bin and /sbin…
Old Unix guy here: That is my understanding as well. But then the question becomes, why not get rid of /usr?
To avoid breaking backward compatibility.
Re: Debian still having trouble with merged /usr
#273I wish most *Unixes would go the Gobo Linux route with a Program, Users, System, Data, Mount file hierarchy that is just symlinks under the hood to the old hierarchy
Other than that:
* /Users == /home
* /Data == /var
* /Mount == /mnt (?)
so what do we get by breaking the world?
Re: Debian still having trouble with merged /usr
#274Earlier quoted context omitted.
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.…
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 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.
Re: Debian still having trouble with merged /usr
#275Earlier quoted context omitted.
Adding to this historical reasoning, it is to be noted that in traditional Unix, /usr was pretty much the equivalent of /home in Linux systems: the parent directory for user home directories, i.e. 'usr'. The existence of /usr/bin can probably be explained by the reasoning that, just like nowadays Linux systems often have a really big /home partition, early Unix systems eventually ran out of space for whatever volume…
Careful, you'll attract computing historians who will want to tell you that "usr" actually stands for "UNIX system resources"
You could ask Ken Thompson (/usr/ken) himself to verify. ;-)
Re: Debian still having trouble with merged /usr
#276I've always liked the /usr distinction, with systems set up so they will at least boot without /usr mounted (at an absolutely minimum, a statically linked /bin/sh is enough to get a command prompt). This is particularly valuable for setups where a large number of PCs can mount /usr read-only from a remote server (we run quite a number of diskless x86 amd ARM systems like this).
You could even ship the initramfs and kernel using tftp.
Then the diskless systems just need enough storage for a bootloader like uboot or tianocore.
Re: Debian still having trouble with merged /usr
#277Re: Debian still having trouble with merged /usr
#278Re: Debian still having trouble with merged /usr
#279Earlier quoted context omitted.
> the tiranny of the majority had flaws (but to me is mostly unavoidable due to the natural economies of scale it grants). In a different context, this is a source of frustration for me as a (partially) blind person advocating accessibility for blind people. The world is designed around the assumption, correct for most people, that people have the high-bandwidth, low-latency sense of sight. And that does lead to the…
First of all I think Eugenics would/will quickly lead to something akin to runaway selection: people will make increasingly absurd decisions mainly driven by status markers / perceptual drift and the human race will breed itself into some mad corner. So I don't believe Eugenics is ever going to do what even its most ardent supporters imagine. Second of all the human race does not have some over-arching goals we need…
You need to realize we are currently implementing eugenics, we just don't know what our goals are.
There's two types of eugenics, positive and negative, based on the root of postulate. A positive eugenics program selects *for* specific qualities like hair color. Negative eugenics selects *against* deleterious phenotypes.
You still need to exercise caution. For example, selecting against depression may be long term bad because the real thing we need to do is reform society to reduce depression. But there are some things, like being born with a disability, that have obvious impact outside of a functioning society that it seems reasonable to select against them.
W.r.t. the parent comment to yours, I'm conflicted; I've spoken to people and seen how many issues they have getting accomodation. If people were forced to care, making interfaces for blind people would be pretty easy. But many people refuse to care.
The idea of genetic drift due to lack of selective pressure has been studied (recently, and in a way not connected to racism) and was pretty grim. Unfortunately due to the connotations eugenics typically carries it has remained poorly investigated.
Re: Debian still having trouble with merged /usr
#280Just in case anyone is wondering why we had (or used to have) /bin and /sbin directories as well as /usr/bin /usr/sbin here is my understanding of it. It is because on old Unix systems there frequently wasn't enough space to store /usr on the root disk. Therefore /usr was a separate disk which might not be available during boot. This meant that you needed to put all the binaries you needed for boot in /bin and /sbin…
Old Unix guy here: That is my understanding as well. But then the question becomes, why not get rid of /usr?
I just don't understand, if people want to merge /usr and /, why they insist on keeping the gratuitous /usr prefix. It can all just be rolled up into / : /bin, /sbin, /share, /lib, /include, /share, /src and so on.