1 |
On 01/01/12 15:12, Olivier Crête wrote: |
2 |
> Hi, |
3 |
> |
4 |
> On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: |
5 |
>> I have been working with robbat2 on solutions to the separate /usr issue |
6 |
>> (That is why I have specifically cc'd him on this email) |
7 |
>> which will allow people to not use an initramfs. If we migrate |
8 |
>> everything off of the root fs to /usr, all of those solutions become |
9 |
>> moot. On the other hand, if we don't migrate, we run the risk of |
10 |
>> eventually having our default configuration not supported by upstream. |
11 |
> I think the general consensus among other distros is that initramfs is |
12 |
> the new /. Many core elements of the Linux system will start installing |
13 |
> themselves in /usr, starting with udev, so we won't have a choice |
14 |
> anyway. Also, I doubt it's currently possible to boot a Gentoo system |
15 |
> without /usr mounted anyway. |
16 |
"initramfs is the new /" ... and no one asked if maybe that doesn't |
17 |
really make sense? |
18 |
|
19 |
That people are now actively working on forcing one big system partition |
20 |
is annoying, but I really don't see the need to add a layer or two of |
21 |
complexification just because, well, why not. |
22 |
|
23 |
> |
24 |
>> 1) Start migrating packages along with upstream and have everyone who |
25 |
>> has a separate /usr (including me by the way) start using an initramfs |
26 |
>> of some kind, either dracut or one that we generate specifically for |
27 |
>> gentoo. The reason I suggest the initramfs, is, unfortunately if we |
28 |
>> migrate everything, nothing else would work. |
29 |
> I also don't see a good reason to not adopt dracut, |
30 |
Make it work and I'll reconsider it, until then genkernel wins by default. |
31 |
> re-implementing |
32 |
> something that already works and is maintained by a competent upstream |
33 |
> seems wasteful to me. I really don't see why people resist using an |
34 |
> initramfs so much. |
35 |
What does it add, apart from time to the boot process? For some setups |
36 |
(like my notebook with luks+lvm) there's no reasonable way around it, |
37 |
but on my desktop it's worse than useless. |
38 |
> |
39 |
> The udev/kmod/systemd/dracut effort to standardise the base userspace of |
40 |
> Linux is probably scary for quite a few Gentoo-ers as it means that the |
41 |
> end result of an installed Gentoo system will be less differentiated |
42 |
> than it was before. But it still is a step in the right direction as |
43 |
> most of these standardized pieces are much better than what we currently |
44 |
> have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 |
45 |
> and unmaintained upstream shows that even a relatively large |
46 |
> distribution like us can't maintain a competitive base system solution, |
47 |
Eh what? |
48 |
|
49 |
As part of the OpenRC upstream I find it weird that you call it a fiasco |
50 |
when it works better than the other "solutions" and had about 10 commits |
51 |
in the last 48 hours alone. |
52 |
|
53 |
I don't see an advantage in replacing a known-good solution with some |
54 |
random stuff that mostly doesn't work yet just because it's the future. |
55 |
|
56 |
|
57 |
> adopting the udev/kmod/systemd way will allow us to use all the work |
58 |
> that they are doing and instead concentrate on making a better system. |
59 |
> |
60 |
"Better" means no lennartware to me. I want to be able to fully debug |
61 |
init script failures, which systemd makes very hard to impossible. On |
62 |
some machines I have changes in the startup that would mean having to |
63 |
hack up something in C and hope that it doesn't crash init for systemd |
64 |
(what the bleeeep?) |
65 |
|
66 |
Please don't try to bring the GnomeOS vision of having MacOS without |
67 |
paying for it to my computing experience ... |