On Fri, 16 Nov 2018 22:11:17 +1300
Daniel Reurich <daniel@???> wrote:

> Hi Devuan followers, fans and friends,
>
> Debian as of the upcoming Buster release looks to be implementing a
> merged /usr by default. At this stage there is no plan to make it
> forced... but you never know what happens when their Technical
> Committee suddenly decides it's an issue they need to force a
> decision on...
>
> So... for Devuan, do we want to default to a merged /usr in our coming
> release of Beowulf or are we going to resist another pointless
> rearranging of the deck chairs...
>
> Keen to get some feedback on this

Back in the what, 1970's, the Unix guys
split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
by separating out statically compiled stuff used in the earliest boot.
But then initramfs made these separate directories unnecessary, so why
in the world would we continue the split?

Well, maybe because initramfs is a PITA many people choose to avoid.
When things go wrong, it's the ultimate black box. And I'm very scared
that one day Poettering/Redhat/Freedesktop.org will corner the market
on initramfs makers, will make them systemd only, sans-systemd distros
who have completed the merge will have the choice of backing out the
merge or going to systemd.

Initramfs (or initrd before it) is the ultimate black box. You can't
get your normal voltmeter probes in there: You need to use special
stuff that's hard to use. You can init the hard disk with /bin/bash,
but not the initramfs. Oh, and not even the /bin/bash if the merge
happens.

Here's some info on dracut, the most prevalent initramfs maker:

https://www.techradar.com/news/software/operating-systems/what-on-earth-is-dracut-1078647

Oooh, notice they say dracut is "based on udev events". If you're
avoiding systemd, and Redhat has taken over udev, what could
*possibly* go wrong?

Here's some recommended reading on "the merge":

https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/

https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

The gist of the preceding links is "hey, other programs conflate early
with late boot programs, so don't blame us for doing it too. Oh, and by
the way, most of those conflaters, like udev, are under our control.
Conflation is another form of entanglement, but don't blame us."

For those using ext4, assuming a kernel with ext4 compiled in, without
need for root disk lvm, encryption, and raid, the init system can
immediately use the static executables in /sbin to mount necessary
disks and then go about the rest of the boot.

Systemd loves to brag about their boot time, but on a system with ext4
drivers compiled into the kernel, a separate /sbin guaranteed on the
root partition, and minimal use of udev in the boot (you *could* run it
as a daemon, in parallel, using runit), boots would be quick indeed.
Switch-root, killall5, and all the other stuff done before disks begin
to mount, goes away.

I vote against "the merge".

SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr