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
  • 72,889
einpoklum
  • 9,515
  • 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