1 |
On Wednesday, 7 August 2019 01:31:03 BST Rich Freeman wrote: |
2 |
> On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor |
3 |
|
4 |
> > Sadly, I think people have thrust additional (IMHO) largely unnecessary |
5 |
> > complexity into the init process just to be able to support more exotic |
6 |
> > installations. |
7 |
|
8 |
I may be wrong but I thought the udev-usr-initrd complexity was deemed a |
9 |
necessity/ when bluetooth input and audio devices became more widespread. The |
10 |
fact systemd gradually mushroomed to take over the OS is another more loosely |
11 |
related story. |
12 |
|
13 |
|
14 |
> > Then, they have said "We want to be consistent in how we |
15 |
> > boot, so we need to use this more complex thing everywhere." To which, |
16 |
> > many greybeards have responded "I don't need nor want that on my simple |
17 |
> > server." |
18 |
|
19 |
This is the main rub of these architectural /solutions/ being pushed onto the |
20 |
wider community by what amounted to corporate lobbyists, for /problems/ many |
21 |
of us never had. |
22 |
|
23 |
> Initramfs is popular because it is way more flexible: |
24 |
> |
25 |
> 1. You can build a fully modular kernel so that you can use the same |
26 |
> kernel on every system but not be loading countless drivers for |
27 |
> hardware most systems don't use, while still being certain of being |
28 |
> able to boot any particular system. |
29 |
|
30 |
Unless you have no use for this. Just as many *Gentoo* users do not need |
31 |
their kernel image blessed by Microsoft, RHL shims and what not. |
32 |
|
33 |
|
34 |
> 2. You have more access to labels/uuids/etc for finding the root |
35 |
> filesystem so that when one of your hard drive fails the kernel |
36 |
> doesn't just dumbly use the next one in sequence, assuming they're |
37 |
> even always identified in the same order. |
38 |
|
39 |
I may be missing something here ... but I think this is not related to the use |
40 |
of an initrd. You probably won't even need a separate bloat-loader like grub2 |
41 |
for this, at least not on UEFI systems. Just add the root PARTUUID on your |
42 |
kernel line, inside the kernel. |
43 |
|
44 |
|
45 |
> 3. You can use "exotic" installations like iscsi and so on, which |
46 |
> seems pretty useful in an enterprise setting. |
47 |
> |
48 |
> > If you /actually/ /need/ a micro installation to make your main |
49 |
> > installation available, then go for it. But if you don't /actually/ |
50 |
> > /need/ a micro installation, well Occam's Razor / Parsimony. |
51 |
|
52 |
I have not performed sociological research to confirm this, but I'd say to |
53 |
those of us identifying with the above statement Gentoo is a good fit. For |
54 |
those in an enterprise setting, there are many other cookie-cutter corporate |
55 |
solutions applicable. |
56 |
|
57 |
|
58 |
> Except then you're tailoring your bootloader to individual systems. |
59 |
|
60 |
Yes, I don't *have* to use Gentoo on a large server farm, put a SLA in place |
61 |
linked to contractual payment thresholds, hack my own monitoring system and |
62 |
get 3 layers of insurance signed off. Tailoring my bootloader(s) is something |
63 |
I do in my home-office environment, including 3 servers. |
64 |
|
65 |
|
66 |
> Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the same |
67 |
> kernel/bootloader/etc works everywhere, vs tailoring their boot |
68 |
> process to every individual host. |
69 |
|
70 |
Yes in (large) corporate deployments. Some of them on Azure too. |
71 |
|
72 |
|
73 |
> > > They're a really elegant solution to the problem. |
74 |
> > |
75 |
> > I wouldn't use the words "elegant" or "solution". "kludge" comes to mind. |
76 |
> |
77 |
> What could be more elegant? It minimizes the complexity of the |
78 |
> kernel, which is why Linus generally prohibits the kernel from having |
79 |
> any more advanced root mounting logic, and why pretty much every Linux |
80 |
> system out there uses one. |
81 |
|
82 |
I think the whole issue is a difference in use cases and where corporate money |
83 |
has been used to provide a narrowly focused solution to address corporate |
84 |
requirements, without particular attention/interest/care to what are |
85 |
statistically edge use cases. Such edge use cases, e.g. separate /usr, no |
86 |
initrd or kernel images signed by Microsoft, different choice of bootloaders, |
87 |
etc. have been more concentrated on Gentoo than the one-size-fits-all binary |
88 |
distros. RHL calls these "bespoke" deployments. Yet when changes in udev |
89 |
brought about the necessity of an initrd in order to keep running a separate / |
90 |
usr fs, I recall quite a number of gentoo user voices in this M/L alone |
91 |
objecting to the changes. What is an edge use case for Fedora, is/was not so |
92 |
much of an edge use case in Gentoo. |
93 |
|
94 |
Gentoo did not *have* to follow upstream changes, but yet again this could |
95 |
probably bring its ultimate stagnation/demise as devs would be spread too thin |
96 |
to keep developing Gentoo in a deviating path from the rest of the Linux |
97 |
trajectory. |
98 |
|
99 |
Having used and still using other binary distros I'm grateful Gentoo's still |
100 |
here, but would really prefer it did not bend itself out of shape to |
101 |
accommodate solutions to problems I and others do not have, or when we do we |
102 |
may not even use Gentoo to solve them. |
103 |
|
104 |
-- |
105 |
Regards, |
106 |
|
107 |
Mick |