Quoting Rowland Penny (rpenny@???):

> Can anybody explain the bad points of doing the merger ?
> I ask this because everything I can find says it is a good thing, but
> they said systemd was a good thing ;-)

This topic has been obscured by a massive amount of special-pleading and
rationalisation. I'll merely address my _own_ view reflecting my local
policy as a Linux server administrator (not purporting applicability to
Devuan or Debian or desktop computing, or anything else).

Text below (drafted impromptu while-u-wait) serves as my rejoinder to
several frequently-cited Web pages, primarily those from the
Freedesktop.org and Fedora people, that make arguments I deem some
combination of disingenuous and incompetent, FWIW. Said pages are
liberally quoted (usually verbatim) in the 'Objection' paragraphs.

(Strictly speaking, what follows will not argue against any distribution
'doing the merger'. It merely articulates that *I* will be un-doing
any such merger impinging on my local systems from distro defaults,
or similar, and why.)


My view: I need the contents of /bin, /sbin, /lib, and /lib64
to be functional if /usr for any reason cannot be, or is not, mounted,
because the role of those subtrees on my systems is to house tools the
superuser might need for backup, recovery, system repair, and system
diagnosis (collectively, 'rescue') in the absence of /usr.


Objection: But Rob Landley reminded us at
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
that that isn't why Thompson and Richie invented the /usr split in 1971.

Answer: True enough, but also blatantly, blazingly, and somewhat
insultingly-to-our-intelligence irrelevant. It's what generations of
sysadmins have found the /usr split useful for _since_ not long after
1971, and the split's origin in an ancient PDP-11 two-disk-pack kludge
is amusing but has no bearing on more than four decades' subsequent best
practices.


Objection: But your /usr-less system won't work properly because
of udev rules invoking binaries from /usr/bin, libs in /usr/lib, and/or
data files in /usr/share, e.g., for udev-pci-db/udev-usb-db, PulseAudio,
NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch,
gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip,
multipath, Argyll, VMWare, etc.

Answer: My server systems' basic backup, recovery, system repair, and
system diagnosis utilities aren't dependent on the latter (mostly)
GNOME/freedesktop crud. If my systems _were_ dependent on, e.g.,
LVM, and I found it depended on components in /usr, I'd recompile those
packages locally to remove what I regarded as a build error. Likewise,
no udev rules on _my_ server systems depend on /usr. Moreover, I'm
sufficiently unhappy with udev that I'm currently testing migration away
from it to reduce system complexity and protect security.


Objection: The roles of a proper minimal system is better filled by an
initrd.

Answer: I elect to run a simplified system without initrd, and greatly
prefer that nothing on my server systems require one.. Moreover, I'm
sufficiently unhappy with udev that I'm currently testing migration away
from it to reduce system complexity and protect security. mdev's
looking promising. (And no, I don't care if it's popular, as long as
it's popular with me.)


Objection: The role of a proper minimal rescue system is better filled
using an initrd. Thus, the alleged historical justification no longer
applies.

Answer: That is an opinion I happen to not share. I elect instead to
run a simplified system locally configured to run without initrd, and
greatly prefer that nothing on my server systems require one. I'd in
fact consider any system breakage in the absence of an initrd a critical
bug, and would fix that immediately.


Objection: It makes no sense for a Linux distribution in 2018 to
default to supporting operation without initrd.

Answer: Possibly so, yet utterly irrelevant to my server systems, which
follow Rick Moen policy, if required overriding distro policy: My local
system, my local rules. (By the way, that's called 'system
administration'. Try it, some time.)


Objection: How are you so sure that nothing in your /bin, /sbin, /lib,
or /lib64 files needed for backup, recovery, system repair, and system
diagnosis doesn't depend on /usr?

Answer: Because I checked. 'ldd' isn't rocket science, y'know. And,
if something I relied on for the indicated 'rescue' functions did suffer
such a dependency, I would fix that, if necessary by recompiling
statically.


Objection: Why would you consider something as antediluvian as static
binaries in 2018?

Answer: Because I'm serious that those tools need to work with or
without availability of /usr, and highly reliable operation for critical
tools is more important than a small amount of extra binary footprint.
Also, I didn't say I wanted to resort to static binaries. I said I'd
_even_ resort to static binaries, rather than rely on binaries needed
for 'rescue' purposes that break in the absence of /usr.


Objection: The root directory hasn't been minimal in decades.

Answer: Speak for yourself, freedesktop.org/GNOME apologist. It still
is on my systems.


Objection: Separate /usr hasn't been consistently standard, e.g.,
/bin was a symlink to /usr/bin on many Unixes.

Answer: I don't give a rat's ass. It's standard on mine.