0

I'm reading this document about the move towards merging /bin into /usr/bin:

The historical justification for a /bin, /sbin and /lib separate from /usr no longer applies today. (More on the historical justification for the split, by Rob Landley) They were split off to have selected tools on a faster hard disk (which was small, because it was more expensive) and to contain all the tools necessary to mount the slower /usr partition. Today, a separate /usr partition already must be mounted by the initramfs during early boot, thus making the justification for a split-off moot. In addition a lot of tools in /bin and /sbin in the status quo already lost the ability to run without a pre-mounted /usr. There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose.

but if I understand this correctly, the reasonable course of action for removing the root-vs-/usr split is to just merge all of /usr "back" into the root folder, i.e. have /bin, /share, /local, a merged lib/ and so on.

Why merge in the other direction, maintaining an artificial path element which no longer makes sense?

muru
  • 69,900
  • 13
  • 192
  • 292
einpoklum
  • 8,772
  • 19
  • 65
  • 129
  • I think you're missing the point. The distinction being made in `/bin`/`/lib`/`/share` is not the one that is relevant now. The relevant distinction is now read-only vs writable. There's `/usr` that's supposed to be read-only except for package updates, there's `/var` for writeable part. – muru Apr 06 '22 at 16:20
  • Because the requirement for `/bin` (available early, on a fast small disk) is no longer a requirement. `/bin` should go away, but old programs and scripts should not be broken. – waltinator Apr 06 '22 at 16:24
  • @waltinator: You're not answering the question I asked. – einpoklum Apr 06 '22 at 16:31
  • 1
    @muru: Not sure how I'm missing the point. There's no problem having a writable `/var` in an otherwise non-writeable root filesystem - with a mount. – einpoklum Apr 06 '22 at 16:32
  • @einpoklum Because you're focusing on the wrong thing - `/var`. Having a writable `/var` isn't the point. Having all your readonly stuff nicely sequestered in corner of the filesystem (`/usr`) is. Then `/usr` at any given point in time represents (to a degree) a set of packages each at some given version. Upgrading, adding, removing or any other package manipulation then is essentially swapping sets of `/usr` around. You can't swap around something when you have a mounted writable directory in it, so having all your readonly stuff spread all across `/` is useless for this world-view. – muru Apr 06 '22 at 18:07
  • Of course, there are still problems like `/etc`, `/usr/local`, etc., but `/etc` can be worked around to a degree and the people who're interested in these operations aren't those who will be using `/usr/local`. – muru Apr 06 '22 at 18:08
  • @muru: 1. You bring up an example, then chide me for discussing it. 2. `/usr` would not represent a set of packages, since packages include files outside of `/usr`, and files which can and do get altered. You're trying to argue on the basis of a world which doesn't exist and the merge is supposed to comply with. – einpoklum Apr 06 '22 at 19:29
  • @einpoklum 1. Well, in a discussion about usrmerge, it hardly makes sense to focus on what's not getting merged, obviously. When given an example, then, you should be looking at the `/usr` aspect of it. 2. Yes, thank you for restating my last comment. But `/usr` does represent the vast majority of those files, and for many packages, *all* of them. – muru Apr 07 '22 at 00:37

0 Answers0