The case for the /usr "merge"...

Issues and / or general discussion relating to Puppy

Moderator: Forum moderators

Post Reply
User avatar
mikewalsh
Moderator
Posts: 6163
Joined: Tue Dec 03, 2019 1:40 pm
Location: King's Lynn, UK
Has thanked: 795 times
Been thanked: 1983 times

The case for the /usr "merge"...

Post by mikewalsh »

Morning, gang.

Even as a mod, I wasn't too sure where to put this, but I settled on "Users" because it's a 'current' topic, and whether we like it or not, it's going to impact future generations of Puppies, since they're based around existing mainstream releases. So it merits being in a well-used, visible section of the Forum.

--------------------------------------------

I wasn't even aware of this until I began to participate in the ongoing thread in the Fossapup64 section of the 'Mainline Puppy Distros' forum....."New Fossapup64".

During the course of this thread, mention was made of the way in which certain parts of the Linux filesystem are now being re-implemented. So; I asked:-

@dimkr :-

This business of /bin, /sbin, /lib & /lib64 now being merely sym-links to their counterparts in /usr; was this inspired by the way Void Linux does things, or is this a "sea-change" across the whole Linux landscape?

I haven't run a mainstream distro for several years, so I really have no idea what's been happening across the wider community. If this IS a community-wide change, I have to assume it was initiated by the RedHat/Fedora team, since they appear to be at the leading edge of most of the sweeping changes that seem to have been occurring over the last decade or so.....

:?:

Mike. ;)

To which came back the reply:-

dimkr wrote: Thu Oct 20, 2022 6:51 pm
mikewalsh wrote: Thu Oct 20, 2022 6:36 pm

is this a "sea-change" across the whole Linux landscape?

Most distros, especially those that use systemd (= the majority) have changed. It's possible to build a Puppy without those symlinks, but so many packages will be broken - it's not worth it IMO.

I got curious about this, and did a wee bit of research. It was indeed implemented by that bastion of the oft-perceived-as-idiotic at RedHat, Lennart Poettering.....although in this particular case, I CAN see the sense behind the logic.

--------------------------------

Turns out this was originally mooted around 12 years ago, so it's been in active discussion & development for all that time. This article over at freedesktop.org - the guys responsible for a lot of inter-distro/platform interoperability - states the reasoning very well:-

"The Case For The Usr Merge"

There's an interesting side-link in this article......explaining the original, historical reason for why this "split" between / and /usr occurred in the first place. It all dates back to when Dennis Ritchie & Ken Thompson were developing Unix back at the very tail end of the 60s.....and what happened when they upgraded from their original development machine - a PDP-7 - to a newer PDP-11.

The following is a transcript of a discussion between developers Rob Landley and David Collier in the course of developing an applet for detecting file-system types:-

"You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969?
Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5
megabytes each) for storage.

When the operating system grew too big to fit on the first RK05 disk pack (their
root filesystem) they let it leak into the second one, which is where all the
user home directories lived (which is why the mount was called /usr). They
replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and
wrote files to those new directories because their original disk was out of
space. When they got a third disk, they mounted it on /home and relocated all
the user directories to there so the OS could consume all the space on both
disks and grow to THREE WHOLE MEGABYTES (ooooh!).

Of course they made rules about "when the system first boots, it has to come up
enough to be able to mount the second disk on /usr, so don't put things like
the mount command /usr/bin or we'll have a chicken and egg problem bringing
the system up." Fairly straightforward. Also fairly specific to v6 unix of 35
years ago.

The /bin vs /usr/bin split (and all the others) is an artifact of this, a
1970's implementation detail that got carried forward for decades by
bureaucrats who never question _why_ they're doing things. It stopped making
any sense before Linux was ever invented, for multiple reasons:

1) Early system bringup is the provice of initrd and initramfs, which deals
with the "this file is needed before that file" issues. We've already _got_ a
temporary system that boots the main system.

2) shared libraries (introduced by the Berkeley guys) prevent you from
independently upgrading the /lib and /usr/bin parts. They two partitions have
to _match_ or they won't work. This wasn't the case in 1974, back then they
had a certain level of independence because everything was statically linked.

3) Cheap retail hard drives passed the 100 megabyte mark around 1990, and
partition resizing software showed up somewhere around there (partition magic
3.0 shipped in 1997).

Of course once the split existed, some people made other rules to justify it.
Root was for the OS stuff you got from upstream and /usr was for your site-
local files. Then / was for the stuff you got from AT&T and /usr was for the
stuff that your distro like IBM AIX or Dec Ultrix or SGI Irix added to it, and
/usr/local was for your specific installation's files. Then somebody decided
/usr/local wasn't a good place to install new packages, so let's add /opt!
I'm still waiting for /opt/local to show up...

Of course given 30 years to fester, this split made some interesting distro-
specific rules show up and go away again, such as "/tmp is cleared between
reboots but /usr/tmp isn't". (Of course on Ubuntu /usr/tmp doesn't exist and
on Gentoo /usr/tmp is a symlink to /var/tmp which now has the "not cleared
between reboots" rule. Yes all this predated tmpfs. It has to do with read-
only root filesystems, /usr is always going to be read only in that case and
/var is where your writable space is, / is _mostly_ read only except for bits
of /etc which they tried to move to /var but really symlinking /etc to
/var/etc happens more often than not...)

Standards bureaucracies like the Linux Foundation (which consumed the Free
Standards Group in its ever-growing accretion disk years ago) happily
document and add to this sort of complexity without ever trying to understand
why it was there in the first place. 'Ken and Dennis leaked their OS into the
equivalent of home because an RK05 disk pack on the PDP-11 was too small" goes
whoosh over their heads.

I'm pretty sure the busybox install just puts binaries wherever other versions
of those binaries have historically gone. There's no actual REASON for any of
it anymore. Personally, I symlink /bin /sbin and /lib to their /usr
equivalents on systems I put together. Embedded guys try to understand and
simplify..."

It cracks me up, the bit about the bureaucrats just continuing to blindly implement - as a henceforth, rigorously-followed "standard" - what amounted to a colossal, temporary "workaround" (which would no doubt have been corrected later on) wihout ever trying to understand why this happened in the first place! As Rob Landley says here, " 'Ken and Dennis leaked their OS into the
equivalent of home because an RK05 disk pack on the PDP-11 was too small' goes
whoosh over their heads. "

And so the current re-implementation, it appears, is just attempting to correct a decades-old balls-up, and to restore interoperability between Linux and the current crop of Unix-based commercial systems out there. Which is in fact a laudable goal, and to be commended. It does, however, mean that much current Puppy-specific software will need to be re-written - or at the very least, "tweaked" - if it's going to continue to work with successive newer Pups over time....

Just thought y'all might like to understand why all this is happening. :)

Mike. ;)

User avatar
greengeek
Posts: 1384
Joined: Thu Jul 16, 2020 11:06 pm
Has thanked: 535 times
Been thanked: 192 times

Re: The case for the /usr "merge"...

Post by greengeek »

I am in favour of the typical Puppy chaos.

I used to wonder why the Linux filesystem was so Ph**kd up but now i see this as a protection.

It's harder for malware to operate if the filesystem is a wilderness.

However - I also see benefit in creating a Puppy that is sweet, clean and simple.

But there is now no chance that Puppy will shrink towards a single version. We are desperate, disparate and discordant. (Probably should have been called Cat Linux - Every attempt at cat herding is resisted by the users :-) )

User avatar
user1234
Posts: 415
Joined: Sat Feb 26, 2022 5:48 am
Location: Somewhere on earth
Has thanked: 156 times
Been thanked: 90 times

Re: The case for the /usr "merge"...

Post by user1234 »

Wait, Wait, Wait!! I don't understand this! What are you particularly saying, explain in brief. You write so long posts, and I, I read these very long posts abd then forget what it was all about! Just confirming if I got it right
1. /usr was introduced because the developers of unix couldn't fit their OS on a single disk.
2. Since then, both / and /usr are introduced in the unix and likes, without actually understanding what /usr was actually introduced for.
3. Now, the linux developers want to sym-link /bin, /lib, et ce tera to their /usr counterparts (or maybe vice-versa).
4. Doing this will harm the installed programs' integrity (maybe because of libraries not being found, or else I don't know why?)
Now, if I understood everything rightly, then why would sym-links harm? And why do these people want to sym-link / and /usr, while keeping both wouldn't harm anything? After reading this post, what I've definitely understood is that I particularly don't know anything about linux :shock: :roll:.

PuppyLinux 🐾 gives new life to old computers ✨

Post Reply

Return to “Users”