1 |
On Sun, Sep 29, 2013 at 12:58 PM, Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
2 |
> On 2013-09-28 4:17 PM, Neil Bothwick <neil@××××××××××.uk> wrote: |
3 |
>> |
4 |
>> On Sat, 28 Sep 2013 19:04:41 +0000, Alan Mackenzie wrote: |
5 |
>> |
6 |
>>>> I suppose that what I am about to say isn't really relevant, but it is |
7 |
>>>> unfortunate over the past year that people blamed udev specifically |
8 |
>>>> for this. It is true that it does things that don't work if /usr isn't |
9 |
>>>> mounted, but eudev does as well, since it is basically the same code. |
10 |
>>> |
11 |
>>> |
12 |
>>> Who else is there to blame? We are continually being told that a |
13 |
>>> separate /usr is "broken", as though this were some unfortunate act of |
14 |
>>> <insert your deity here>, much like an earthquake. This gets |
15 |
>>> patronising really quickly. (Please note, I'm NOT blaming you here. I |
16 |
>>> appreciate that you're as much victim as Dale or me or anyone else |
17 |
>>> round here.) |
18 |
>> |
19 |
>> |
20 |
>> It's evolution. Linux has for years been moving in this direction, now it |
21 |
>> has reached the point where the Gentoo devs can no longer devote the |
22 |
>> increasing time needed to support what has now become an dge case. |
23 |
> |
24 |
> |
25 |
> So the solution is to give users one MONTH to prepare? Why not 6 months, or |
26 |
> better, a year? What for gods sake is the rush??? |
27 |
> |
28 |
> Where are the links/pointers to the INTERNAL discussions of this decision? I |
29 |
> seriously want to know. If gentoo devs are not willing to provide a 'paper |
30 |
> trail' for how this decision was arrived at, and let others judge their |
31 |
> decisions based on the merits of their arguments, then what does that say |
32 |
> about their true motivations/intentions? |
33 |
|
34 |
The discussion happened in [1], [2], and [3]. And in similar meetings |
35 |
and mailing lists since months ago. |
36 |
|
37 |
[1] http://thread.gmane.org/gmane.linux.gentoo.project/2946 |
38 |
[2] http://www.gentoo.org/proj/en/council/meeting-logs/20130924.txt |
39 |
[3] http://thread.gmane.org/gmane.linux.gentoo.devel/88282 |
40 |
|
41 |
All has been made in the open; if you subscribed to gentoo-dev, or to |
42 |
genoo-project, you would know about this changes since months ago. |
43 |
|
44 |
> Again, I don't have a problem necessarily with what is being decided (no |
45 |
> separate /usr without an initramfs), my problem is with the implementation - |
46 |
> giving us one MONTH before we can expect possible breakage with each and |
47 |
> every update. |
48 |
|
49 |
How much time do you need? Six months? A year? |
50 |
|
51 |
> The other HUGE thing that worries me, and has me seriously considering |
52 |
> switching to FreeBSD NOW, is, maybe there really is a secret, underlying |
53 |
> ulterior motive to force both systemd AND an initramfs for everyone in ALL |
54 |
> use cases. If that is the case, then say so now, and give those of us who do |
55 |
> not want this advanced notice, and I'll just plan on setting my gentoo box |
56 |
> to never update on Nov 1, and start working on learning FreeBSD and if |
57 |
> necessary, pay someone to help me migrate services to it. |
58 |
|
59 |
Read the discussion: the change was proposed by William Hubbs, the |
60 |
OpenRC maintainer. You know, the *other* init system? The change was |
61 |
backed by the council and, it seems, most Gentoo developers, many of |
62 |
whom doesn't use (and some don't like) systemd. |
63 |
|
64 |
No bogeyman here, no grand conspiracy. Read the logs. |
65 |
|
66 |
> But before I do that, I guess due diligence demands that I now go to the |
67 |
> FreeBSD support lists/forums (whatever they use) to confirm that FreeBSD |
68 |
> does NOT and never WILL require an initramfs (preferably the reason being |
69 |
> architectural differences in the kernel itself). Thankfully they have their |
70 |
> own init system, so no worrying about systemd invading there... I hope... |
71 |
|
72 |
systemd, according to its author, will never support *BSD. |
73 |
|
74 |
Regards. |
75 |
-- |
76 |
Canek Peláez Valdés |
77 |
Posgrado en Ciencia e Ingeniería de la Computación |
78 |
Universidad Nacional Autónoma de México |