1 |
On 11/17/2012 11:35 PM, Greg KH wrote: |
2 |
> On Sat, Nov 17, 2012 at 11:25:11PM -0500, Richard Yao wrote: |
3 |
>> On 11/17/2012 11:19 PM, Greg KH wrote: |
4 |
>>> On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: |
5 |
>>>> On 11/17/2012 10:29 PM, Greg KH wrote: |
6 |
>>>>> I see an "entertaining" fork of udev on github at the moment (-ng, |
7 |
>>>>> really? What happens when someone wants to fork that, -ng-ng? Be a bit |
8 |
>>>>> more original in your naming please, good thing I never trademarked |
9 |
>>>>> "udev" all those years ago, maybe I still should...) |
10 |
>>>> |
11 |
>>>> That was a placeholder name. If you checked before you sent your email, |
12 |
>>>> you would see that we had settled on eudev. |
13 |
>>> |
14 |
>>> The name change still doesn't make it any less "entertaining" :) |
15 |
>>> |
16 |
>>> What does the "e" stand for? |
17 |
>> |
18 |
>> That is a common question. Someone associated with Canonical suggested |
19 |
>> that e stand for embedded. Others consider the "eu" prefix to be the |
20 |
>> greek root for "true". Honestly, we don't care. It is just a name. |
21 |
> |
22 |
> I wouldn't pick "embedded" as the embedded world is now using systemd as |
23 |
> it meets their requirements much better than anything else :) |
24 |
|
25 |
As far as I know, they are using busybox. |
26 |
|
27 |
>>>>> But, along those lines, what is the goal of the fork? What are you |
28 |
>>>>> trying to attempt to do with a fork of udev that could not be |
29 |
>>>>> accomplished by: |
30 |
>>>>> - getting patches approved upstream |
31 |
>>>>> or: |
32 |
>>>>> - keeping a simple set of patches outside of the upstream tree and |
33 |
>>>>> applying them to each release |
34 |
>>>> |
35 |
>>>> The goal is to replace systemd as upstream for Gentoo Linux, its |
36 |
>>>> derivatives and any distribution not related to RedHat. |
37 |
>>> |
38 |
>>> Wait, really? You want to replace systemd? Then why are you starting |
39 |
>>> at udev and not systemd? |
40 |
>>> |
41 |
>>> What is wrong with systemd that it requires a fork? All other distros |
42 |
>>> seem to be participating in the development process of systemd quite |
43 |
>>> well, what is keeping Gentoo developers from also doing the same? |
44 |
>>> |
45 |
>>> What are your goals, specifically, in detail. |
46 |
>> |
47 |
>> Is there any way that the answer to your inquiry would result in a |
48 |
>> productive conversation where you would not attempt to dictate what we do? |
49 |
> |
50 |
> I'm genuinely interested in your goals, in detail, otherwise I would |
51 |
> not have asked about them. Perhaps I am totally wrong and your fork |
52 |
> makes sense, perhaps, to me, not. But without knowing such goals, |
53 |
> there's no way that anyone can get an idea about this. |
54 |
|
55 |
I am afraid that I have to disappoint you. If we were using the |
56 |
waterfall model, I could outline some very nice long term goals for you, |
57 |
but we are doing AGILE development, so long term goals have not been |
58 |
well defined. Some short term goals have been defined, but I imagine |
59 |
that you are already familiar with them. I suggest asking again after |
60 |
our first tag. |
61 |
|
62 |
A consequence of being open source means that everyone can see what we |
63 |
do, so people are able to send us their opinions on things that have not |
64 |
been officially announced, much like this project. |
65 |
|
66 |
>>>>> I understand the bizarre need of some people to want to build the udev |
67 |
>>>>> binary without the build-time dependencies that systemd requires, but |
68 |
>>>>> surely that is a set of simple Makefile patches, right? And is |
69 |
>>>>> something that small really worth ripping tons of code out of a working |
70 |
>>>>> udev, causing major regressions on people's boxes (and yes, it is a |
71 |
>>>>> regression to slow my boot time down and cause hundreds of more |
72 |
>>>>> processes to be spawned before booting is finished.) |
73 |
>>>> |
74 |
>>>> See the following: |
75 |
>>>> |
76 |
>>>> https://github.com/gentoo/eudev/issues/3 |
77 |
>>> |
78 |
>>> You moved from an explicit to an implicit dependency. It's not |
79 |
>>> inspiring any sense of confidence from me that there is an understanding |
80 |
>>> of how things work here. |
81 |
>>> |
82 |
>>> Seriously, the codebase you are working with isn't that large, or |
83 |
>>> complex, at all. To go rip stuff out, only to want to add it back in |
84 |
>>> later, wastes time, causes bugs, and goes against _any_ software |
85 |
>>> methodology that I know of. |
86 |
>> |
87 |
>> I can say the same about the manner in which these changes were |
88 |
>> introduced. Ripping them out to get the codebase back into a state from |
89 |
>> which we are comfortable moving forward is the only sane way of dealing |
90 |
>> with them. |
91 |
> |
92 |
> Wait, what? The kmod introduction was deliberate and solves a real |
93 |
> problem. kmod itself was created _because_ of these issues that had |
94 |
> been seen and found. It was written for the systemd/udev projects to |
95 |
> use, and had been worked on for a long time by a number of developers. |
96 |
> By removing it, you have now negated that solution and we are back to |
97 |
> the old problems we had before. That doesn't seem very wise to me, does |
98 |
> it to you? |
99 |
> |
100 |
> thanks, |
101 |
> |
102 |
> greg k-h |
103 |
|
104 |
Having a builtin is a good idea, but the implementation as a mandatory |
105 |
dependency on kmod is not. The plan is to reintroduce it as an optional |
106 |
dependency, so that distributions (and Gentoo users) that do not want it |
107 |
can avoid it. None of us want to force dependencies on others and there |
108 |
is no need for this one. |
109 |
|
110 |
With that said, Linux distributions are victims of people continually |
111 |
trying to reinvent the wheel with no formal planning. At some point, |
112 |
someone has to enforce a form of structure where further change occurs |
113 |
in a well defined manner and change because we can is rejected as being |
114 |
pointless. That is what we want and that is what we feel that our users |
115 |
want. |