On Wednesday, 7 August 2019 01:31:03 BST Rich Freeman wrote: > On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor
> > Sadly, I think people have thrust additional (IMHO) largely unnecessary > > complexity into the init process just to be able to support more exotic > > installations. I may be wrong but I thought the udev-usr-initrd complexity was deemed a necessity/ when bluetooth input and audio devices became more widespread. The fact systemd gradually mushroomed to take over the OS is another more loosely related story. > > Then, they have said "We want to be consistent in how we > > boot, so we need to use this more complex thing everywhere." To which, > > many greybeards have responded "I don't need nor want that on my simple > > server." This is the main rub of these architectural /solutions/ being pushed onto the wider community by what amounted to corporate lobbyists, for /problems/ many of us never had. > Initramfs is popular because it is way more flexible: > > 1. You can build a fully modular kernel so that you can use the same > kernel on every system but not be loading countless drivers for > hardware most systems don't use, while still being certain of being > able to boot any particular system. Unless you have no use for this. Just as many *Gentoo* users do not need their kernel image blessed by Microsoft, RHL shims and what not. > 2. You have more access to labels/uuids/etc for finding the root > filesystem so that when one of your hard drive fails the kernel > doesn't just dumbly use the next one in sequence, assuming they're > even always identified in the same order. I may be missing something here ... but I think this is not related to the use of an initrd. You probably won't even need a separate bloat-loader like grub2 for this, at least not on UEFI systems. Just add the root PARTUUID on your kernel line, inside the kernel. > 3. You can use "exotic" installations like iscsi and so on, which > seems pretty useful in an enterprise setting. > > > If you /actually/ /need/ a micro installation to make your main > > installation available, then go for it. But if you don't /actually/ > > /need/ a micro installation, well Occam's Razor / Parsimony. I have not performed sociological research to confirm this, but I'd say to those of us identifying with the above statement Gentoo is a good fit. For those in an enterprise setting, there are many other cookie-cutter corporate solutions applicable. > Except then you're tailoring your bootloader to individual systems. Yes, I don't *have* to use Gentoo on a large server farm, put a SLA in place linked to contractual payment thresholds, hack my own monitoring system and get 3 layers of insurance signed off. Tailoring my bootloader(s) is something I do in my home-office environment, including 3 servers. > Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the same > kernel/bootloader/etc works everywhere, vs tailoring their boot > process to every individual host. Yes in (large) corporate deployments. Some of them on Azure too. > > > They're a really elegant solution to the problem. > > > > I wouldn't use the words "elegant" or "solution". "kludge" comes to mind. > > What could be more elegant? It minimizes the complexity of the > kernel, which is why Linus generally prohibits the kernel from having > any more advanced root mounting logic, and why pretty much every Linux > system out there uses one. I think the whole issue is a difference in use cases and where corporate money has been used to provide a narrowly focused solution to address corporate requirements, without particular attention/interest/care to what are statistically edge use cases. Such edge use cases, e.g. separate /usr, no initrd or kernel images signed by Microsoft, different choice of bootloaders, etc. have been more concentrated on Gentoo than the one-size-fits-all binary distros. RHL calls these "bespoke" deployments. Yet when changes in udev brought about the necessity of an initrd in order to keep running a separate / usr fs, I recall quite a number of gentoo user voices in this M/L alone objecting to the changes. What is an edge use case for Fedora, is/was not so much of an edge use case in Gentoo. Gentoo did not *have* to follow upstream changes, but yet again this could probably bring its ultimate stagnation/demise as devs would be spread too thin to keep developing Gentoo in a deviating path from the rest of the Linux trajectory. Having used and still using other binary distros I'm grateful Gentoo's still here, but would really prefer it did not bend itself out of shape to accommodate solutions to problems I and others do not have, or when we do we may not even use Gentoo to solve them. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
