Quoting Rowland Penny (rpe...@samba.org): > 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
