Live data from Hacker News

Debian still having trouble with merged /usr

lwn.net

271–280 of 310 posts

Re: Debian still having trouble with merged /usr

#271
post #183

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"

[deleted]

Re: Debian still having trouble with merged /usr

#272
post #89

Just 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?

> why not get rid of /usr?

To avoid breaking backward compatibility.

Re: Debian still having trouble with merged /usr

#273

I 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

Why rename? How does that benefit us? The only real difference gobo offers is separating program and system files, but I'm not even sure what the difference is there.

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

#274

Earlier 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…

> 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.

Re: Debian still having trouble with merged /usr

#275
post #183

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"

Nice backronym, but /usr/ken (etc.) in v6 shows that /usr was originally a user disk.

You could ask Ken Thompson (/usr/ken) himself to verify. ;-)

Re: Debian still having trouble with merged /usr

#276
post #198

I'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).

Can you not use an initramfs to support mounting an ro NFS root?

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

#278
post #244

Earlier quoted context omitted.

I think /usr/share is linux specific. so much later

It exists on BSDs as well. (No idea who did it first.)

I think the first place I saw it was on SunOS 4, but not sure if that was the first. Definitely existed pre-Linux

Re: Debian still having trouble with merged /usr

#279
post #74

Earlier 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…

Why?

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

#280
post #89

Just 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?

This.

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.

Post reply on HN