Debian still having trouble with merged /usr • Hacker News Board

Re: Debian still having trouble with merged /usr

#221

Post by felixgallo » Wed, Apr 06, 2022, 4:09 PM UTC

PaulDavisThe1st wrote: post #203

felixgallo wrote: post #202

Earlier quoted context omitted.

This is not correct. Separate /bin and /sbin were so that Unix systems could start with a small, minimal, clean root disk that could be read only or effectively read only. The /usr partition was sometimes mounted separately, but this was more for proper organizational/systems design division than it was for disk space reasons. This is still a useful division in many Unix systems today (e.g. IOT) where starting from a…

Rob Landley doesn't agree: http://lists.busybox.net/pipermail/busybox/2010-December/074...

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. The separation of concerns, not the disk space, was a driver for why we did it that way.

Re: Debian still having trouble with merged /usr

#222

Post by rektide » Wed, Apr 06, 2022, 4:19 PM UTC

Beltalowda wrote: post #195

WhyNotHugo wrote: post #148

Earlier quoted context omitted.

Yeah, ideas and projects are often dismissed due to coming from the systemd group. For this very reason, I'm rather bothered that gummiboot was renamed into systemd-boot. It's a very simple, nice tool, that's usable in plenty of non-systemd environments... but the naming just makes it unpopular with the crowd that doesn't like systemd.

I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. I'd still be hesitant to use it to be honest, as systemd has on several occasions broke people's systems and the response was "you're holding your phone^H^H^H^H^H systemd wrong". We…

Systemd-boot is a dream. Why anyone would tolerate or think grub2 is an acceptable piece of software is beyond my understanding.

grub.cfg used to be human editable, but has evolved & morphed into some massive gnarly twisted mess of inscrutible noise that only multiple layers of shell scripts can output. It's become a write-once-read-never disaster.

And if i recall it's not even live. You still have to install that config.

Systemd-boot (nee gummiboot).is such a huge breath of fresh air. Simple senisible plaintext entries that one cam modify in any old text editor, which have immediate effect. It's so pleasant & simple.

Alas debian doesnt seem to ship any hooks for updating systemd-boot with kernel updates. There's a shell-script to write/remove the entries but one has to go write their own hook & figure out the variables to marshal into the script's arguments. Please Debian!

Re: Debian still having trouble with merged /usr

#223

Post by rektide » Wed, Apr 06, 2022, 4:21 PM UTC

throw0101a wrote: post #217

Beltalowda wrote: post #195

Earlier quoted context omitted.

I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. I'd still be hesitant to use it to be honest, as systemd has on several occasions broke people's systems and the response was "you're holding your phone^H^H^H^H^H systemd wrong". We…

> I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. The tight coupling of systemD is a popular criticism of it.

And this is another fine case demonstrating how very very wrong that criticism is.

All in all extremely few systemd subsystems require systemd. Systemd's pid1 requires only one subsystem, journald, which one can mostly disable/defang if they really dislike it.

It's much more like a monorepo than monolith. There's standard practices & libraries between the projects- unit files, ability to ask for machine readible outputs, others. But these cross cutting concerns mostly get compiled in. The actual interdependencies between subsystems are few & far between. Feels like the critics dont really understand what they are trying to criticize.

Re: Debian still having trouble with merged /usr

#224

Post by monocasa » Wed, Apr 06, 2022, 4:22 PM UTC

gompertz wrote: post #200

voidfunc wrote: post #180

Earlier quoted context omitted.

I always understood it as statically linked binaries that could be used regardless of the state of the rest of the system.

Both /bin and /sbin are generally statically linked. So you're not wrong; but primarily sbin is intended to mean "executed by root" above all else.

Looking through my /bin and /sbin, none of the files are statically linked.

Re: Debian still having trouble with merged /usr

#225

Post by rektide » Wed, Apr 06, 2022, 4:29 PM UTC

zh3 wrote: 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).

Bind mount your small system's /usr to /lower, mount your bigger /upper, and use overlayfs to combine them.

Looking forward ro some blog posts discussing how to support this use case; it's a good one. I think usr-merge is so much more managable though that it's totally worth doing.

Re: Debian still having trouble with merged /usr

#226

Post by gompertz » Wed, Apr 06, 2022, 4:31 PM UTC

monocasa wrote: post #224

gompertz wrote: post #200

Earlier quoted context omitted.

Both /bin and /sbin are generally statically linked. So you're not wrong; but primarily sbin is intended to mean "executed by root" above all else.

Looking through my /bin and /sbin, none of the files are statically linked.

Hrmm what distro? I haven't looked in sometime, maybe something changed (Slackware here). My understanding was static linkage in boot related folders was to minimize chance of accidentally losing a library/dependency and breaking booting.

Re: Debian still having trouble with merged /usr

#227

Post by SkittyDog » Wed, Apr 06, 2022, 4:37 PM UTC

0des wrote: post #155

netheril96 wrote: post #152

Earlier quoted context omitted.

You wouldn’t exist in that world.

Why?

I believe he's implying that your embryo would not have passed the fitness tests, and so would have been destroyed. So you wouldn't exist.

Your parents might have conceived again, and had another child who did pass, to whom they gave the same name. But that child wouldn't be you.

Re: Debian still having trouble with merged /usr

#228

Post by marcosdumay » Wed, Apr 06, 2022, 4:44 PM UTC

zozbot234 wrote: post #44

hashhar wrote: post #31

Earlier quoted context omitted.

Not everything is a binary. Also having everything system specific live under a single path means easy backups, easy immutable trees that can be A/B swapped for seamless and online updates with easy rollbacks. No more wondering where the various tools live since everything lives in /usr/bin and more.

The original point of a non-merged /bin (and /sbin) was to contain essential binaries for system recovery and early boot, that should be available even when a separate /usr/ partition is not yet mounted. Keep in mind that the approach of booting from initrd is quite non-idiomatic and used only for convenience wrt. a generic distro install; you're generally meant to recompile your kernel so that it can mount / directl…

Nowadays a network files protocol fits inside the system initializing ROM, so all of those old issues are moot and we have completely different problems to optimize for.

Re: Debian still having trouble with merged /usr

#229

Post by monocasa » Wed, Apr 06, 2022, 4:44 PM UTC

gompertz wrote: post #226

monocasa wrote: post #224

Earlier quoted context omitted.

Looking through my /bin and /sbin, none of the files are statically linked.

Hrmm what distro? I haven't looked in sometime, maybe something changed (Slackware here). My understanding was static linkage in boot related folders was to minimize chance of accidentally losing a library/dependency and breaking booting.

Looked at both Debian and Redhat.

Re: Debian still having trouble with merged /usr

#230

Post by nybble41 » Wed, Apr 06, 2022, 4:53 PM UTC

athrun wrote: post #184

ngc248 wrote: post #49

Earlier quoted context omitted.

>> As for "tyranny of the minority" - I hope to never see that phrase again. Protections for minorities in democracies exist for a very good reason. I digress, but how are these protections an inherent feature of democracies. Even in a democracy (most democracies are representation democracies) people can vote for policies which may discriminate against people. This would be again democracy in action.

they are a feature of _liberal_ democracies. In a liberal democracy, it is understood that the will of the majority is not the only thing that matters. For example, having the majority vote to strip a minority from their religious freedoms is not OK.

The irony is the good parts of "democracy" aren't actually the democratic bits at all, but rather a basic respect for civil liberties (a.k.a. natural laws) which are subject to neither democratic votes nor authoritarian decrees. The key is not to lose sight of the fact that what the majority wills is not always right.

This is why attempts to impose democracy from outside tend to fail. Giving people the vote doesn't automatically lead to respect for their fellow citizens' civil liberties, which is much more fundamental.