Quoting Adam Borowski (kilobyte@???):

> Systemd is bad, but dropping the pretense that following the needs of _one_
> particular stone-age PDP install is sound design is not bad.

It would be illogical to assert that the only conceivable justification
for separate /usr was Thompson & Richie's 1971 need to spread a UNIX
system across a pair of 1.5MB KR05 disk packs. I hope you're not
asserting that?

I would hope and expect that, 46 years further on, people would be
implementing that split to further their 2017 needs, not Thompson &
Richie's 1971 ones.

> Of course, as always our dear Lennart does it wrong (it'd be much better to
> follow Hurd instead and use /bin /sbin /lib), but it doesn't make split /usr
> without an initrd any better.

Watch the goalposts, folks: There's about to be moved. A moment ago,
Adam was asserting that a /usr split no longer makes sense. He's about
to switch arguments on the fly, asserting instead that it doesn't make
sense as a _distro policy goal_. Observe the switcheroo:

> Today, any system where you can realistically install a general-purpose
> distribution has multiple GB of disk space. There's no gain to put / and
> /usr on separate filesystem....

The second sentence doesn't really make sense, and is demonstrably untrue
in isolation (as I will illustrate below). However, I'll bet if I
challenged it, Adam would fall back on the first sentence, and frame the
discussion as about 'install[ing] a general purpose distribution'. Et
voila, goalpost relocation!


Distributions are often obliged to make one size fit all, one policy not
suck overmuch for all installing users. I, on the other hand, am not.

I want my system's primary /bin and /sbin contents (specifically, the
utilities for fsck, partitioning, backup, restore, mkfs, and similar) to
be functional even if /usr for some reason cannot be mounted, or cannot
be relied upon, at bootup. Where some of those utilites have been IMO
erroneously compiled to have dynamic dependencies on /usr by distro
packages, I create local $FOO-static packages to replace them.

A normally quiescent / partition (given that, on my servers, I mount
/usr, /var, and /home from other filesystems) is highly unlikely to
be exposed to filesystem damage, and there is significant value in
knowing that it will be usable by the superuser to repair, remake,
backup, and restore the other filesystems. And yes, if that were not
possible for some reason, I could doubtless PXE boot a maintenance ISO
and use that instead -- but it's nonetheless worth some small amount of
care and work to me to ensure that / can be used that way under pretty
much all circumstances, and I consider that a normal expectation for
a Unix system that I see no reason to cease expecting.

And I expect my server systems to be able to boot with simple boot
chains that includes kernels locally compiled by me appropriately to my
system's specific hardware and needs, eliminating the need for an
initramfs -- because I prefer that architectural simplicity.


Objections that my approach doesn't scale to general-purpose
distribution installers are unresponsive to my point. What I state is
that I have what I consider a rational use-case for separate /usr
without an initramfs for my server systems, and it's irrelevant to my
point whether Devuan or any other distribution decides to facilitate
creation of that specific configuration out of the box. I didn't _say_
this is something distro installers should do. All I said is that
people claiming 'there's no gain' to such a configuration are grossly
mistaken.

(To reiterate what I said before: I am in no way addressing matters of
policy of this or any other distribution.)


> I don't get why you'd want to keep moving things around on the real
> system if you can isolate it into initrd.

OK, I believe you, Adam. You don't.