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