1 |
On Sat, Nov 17, 2012 at 10:49 PM, Greg KH <gregkh@g.o> wrote: |
2 |
> On Sun, Nov 18, 2012 at 12:35:22AM -0500, Richard Yao wrote: |
3 |
>> On 11/18/2012 12:19 AM, Greg KH wrote: |
4 |
>> > On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: |
5 |
>> >>> I'm genuinely interested in your goals, in detail, otherwise I would |
6 |
>> >>> not have asked about them. Perhaps I am totally wrong and your fork |
7 |
>> >>> makes sense, perhaps, to me, not. But without knowing such goals, |
8 |
>> >>> there's no way that anyone can get an idea about this. |
9 |
>> >> |
10 |
>> >> I am afraid that I have to disappoint you. If we were using the |
11 |
>> >> waterfall model, I could outline some very nice long term goals for you, |
12 |
>> >> but we are doing AGILE development, so long term goals have not been |
13 |
>> >> well defined. Some short term goals have been defined, but I imagine |
14 |
>> >> that you are already familiar with them. I suggest asking again after |
15 |
>> >> our first tag. |
16 |
>> > |
17 |
>> > I'll ignore the fact that project goals have nothing to do with |
18 |
>> > waterfall or agile, and ask, what are your short-term goals? |
19 |
>> > |
20 |
>> > Why is this an "official" Gentoo project without this being discussed in |
21 |
>> > an open manner? |
22 |
>> |
23 |
>> We are in the process of getting started. If you read my original email, |
24 |
>> you would know that the announcement was supposed to occur relatively |
25 |
>> soon. The reason I sent it was because the Gentoo Council meeting |
26 |
>> required something be sent sooner than we were ready. |
27 |
> |
28 |
> The "announce later, act first" seems like a new move for the Gentoo |
29 |
> Council to be taking. Is this really an official act that the council |
30 |
> is approving? |
31 |
> |
32 |
> Why wait to announce a project that is being hosted on a Gentoo account, |
33 |
> with Gentoo Foundation copyrights on them? I don't understand the |
34 |
> delay. |
35 |
> |
36 |
>> >>> Wait, what? The kmod introduction was deliberate and solves a real |
37 |
>> >>> problem. kmod itself was created _because_ of these issues that had |
38 |
>> >>> been seen and found. It was written for the systemd/udev projects to |
39 |
>> >>> use, and had been worked on for a long time by a number of developers. |
40 |
>> >>> By removing it, you have now negated that solution and we are back to |
41 |
>> >>> the old problems we had before. That doesn't seem very wise to me, does |
42 |
>> >>> it to you? |
43 |
>> >>> |
44 |
>> >>> thanks, |
45 |
>> >>> |
46 |
>> >>> greg k-h |
47 |
>> >> |
48 |
>> >> Having a builtin is a good idea, but the implementation as a mandatory |
49 |
>> >> dependency on kmod is not. The plan is to reintroduce it as an optional |
50 |
>> >> dependency, so that distributions (and Gentoo users) that do not want it |
51 |
>> >> can avoid it. None of us want to force dependencies on others and there |
52 |
>> >> is no need for this one. |
53 |
>> > |
54 |
>> > You do realize that you didn't really drop the dependency at all, right? |
55 |
>> |
56 |
>> kmod does not exist on my system and eudev builds without a problem. |
57 |
> |
58 |
> Are you using busybox to load your kernel modules? Are you saying that |
59 |
> this is something that will be required here? |
60 |
> |
61 |
> Or is this change because you want to use busybox to load your modules? |
62 |
> If so, why not just use mdev instead of udev at all? That's what mdev |
63 |
> was created for, busybox-like systems that don't want the "heavy" udev |
64 |
> on them. |
65 |
> |
66 |
>> I am thinking of writing my own busybox-style code to handle module |
67 |
>> loading in the builtin when the configure script is told not to build |
68 |
>> with kmod. Does this not avoid the dependency? |
69 |
> |
70 |
> So we will now have 3 different Linux kernel loaders floating around? |
71 |
> What's wrong with using kmod in the first place? What does it do that |
72 |
> is so wrong? |
73 |
> |
74 |
> And again, back to my original point above, you have reintroduced the |
75 |
> problem that kmod solved. How is that good? |
76 |
> |
77 |
>> >> With that said, Linux distributions are victims of people continually |
78 |
>> >> trying to reinvent the wheel with no formal planning. |
79 |
>> > |
80 |
>> > Huh? Really? It's as if you think we all are just throwing stuff |
81 |
>> > against the wall and seeing what sticks? We aren't responding to real |
82 |
>> > users, customers, research, history, and competitors? Your dismissal of |
83 |
>> > the people who create the system you are using seems pretty bold. |
84 |
>> |
85 |
>> The result of what the existing people have been doing has been the |
86 |
>> equivalent of throwing stuff against the wall for many of us. |
87 |
> |
88 |
> Really? What, specifically, is wrong with the existing systemd solution |
89 |
> that you have a problem with? Specifics please, otherwise they can't be |
90 |
> fixed. |
91 |
> |
92 |
|
93 |
So I'm pretty sure the concerns were laid out in other threads. |
94 |
|
95 |
1) systemd-udev will require systemd. Stated by the systemd |
96 |
maintainers themselves as a thing they want to do in the future. Some |
97 |
users don't want to use systemd. We could go into detail as to why; |
98 |
but I think that is not as important as one may think. The point is |
99 |
that the desire is there, and thusly there are users who want to make |
100 |
other systems (namely openrc) work. |
101 |
|
102 |
People like openrc. My VMs for instance, boot reasonably quickly. |
103 |
Booting 5 seconds faster may be super duper, but not at the cost of an |
104 |
existing reliable solution. |
105 |
|
106 |
>> We have decided to try doing things ourselves to see if we can do |
107 |
>> better. We think we can. |
108 |
> |
109 |
> That's wonderful, seriously. But why is this suddenly an official |
110 |
> Gentoo project? When did that happen, and why? Why not just do a |
111 |
> "normal" project and if it matures and is good enough, then add it to |
112 |
> the distro like all other packages are added. |
113 |
> |
114 |
> My main point here is the fact that this is now being seen as an act by |
115 |
> Gentoo, the distro / foundation. And that happened in private, without |
116 |
> any anouncement. Which is not good on many levels. |
117 |
|
118 |
I'm unsure on what grounds you disapprove. People start (and abandon) |
119 |
projects often in Gentoo. Suddenly you dislike one such project and |
120 |
object to this practice? Certainly if we had to get some sort of |
121 |
Foundation consensus (for anything) nothing would happen. We can't |
122 |
even get more than 40% of foundation members to vote. |
123 |
|
124 |
> |
125 |
>> > Have you studied the problem area for booting, process monitoring, |
126 |
>> > system isolation, device creation and notification, persistant naming, |
127 |
>> > multiple users with multiple displays, and the like, and found that |
128 |
>> > Linux is lacking in this area? If so, I would love to learn more, as I |
129 |
>> > want Linux, and Gentoo, to succeed. Without knowing the problems you |
130 |
>> > are having, there's no way anyone will ever change. |
131 |
>> |
132 |
>> We already have OpenRC, which has been found to work well on both Gentoo |
133 |
>> Linux and Gentoo FreeBSD. The integration of udev into systemd has |
134 |
>> caused problems for existing OpenRC systems with people being told that |
135 |
>> it is okay to break configurations that users had been told to use over |
136 |
>> well over a decade. Many of us consider that to be unacceptable. |
137 |
> |
138 |
> Part of the goal of systemd is to unify all Linux distros startup logic, |
139 |
> and configuration logic, to make things unified to help a whole lot of |
140 |
> things happen better and faster in the end. It is a move to save |
141 |
> effort, and, is succeeding quite well. If Gentoo does not wish to |
142 |
> participate in this effort, then those of us who are participating in |
143 |
> it, and are Gentoo developers, should be told this so that we can decide |
144 |
> what we wish to do. |
145 |
|
146 |
You presume Gentoo acts as a whole. This is almost never true. Just |
147 |
because we host the project, and gentoo staffs the project, or even |
148 |
that the copyright is on the project, doesn't mean 'we reached a |
149 |
consensus and decided systemd sucks.' Certainly the existing sytemd |
150 |
maintainer in Gentoo doesn't think so. However a number of folks *do* |
151 |
think so, and are willing to put effort into it. I'm unsure why we |
152 |
should prevent them from doing so. |
153 |
|
154 |
For the guy who earlier claimed that forking was great and encouraged |
155 |
it; I am confused as to why it is suddenly discouraged now. |
156 |
|
157 |
> |
158 |
> OpenRC is great, and has worked well for 10+ years. But seriously, it |
159 |
> is creaky in places, and doesn't do much at all compared to what systemd |
160 |
> offers. If Gentoo wants to ignore systemd, it does so at its own peril. |
161 |
> |
162 |
> Oh, and systemd has nothing to do with the /usr issue, don't ever get |
163 |
> that confused. A separate /usr broke a long time ago, systemd just now |
164 |
> shows you how broken your system really was, and you didn't notice it :) |
165 |
|
166 |
I agree I think folks think they can solve this with udev. I think |
167 |
even the early patches to try to 'fix' it are going to teach them that |
168 |
it is perhaps harder than they know. Perhaps they are merely |
169 |
inexperienced, and they will learn from the effort. |
170 |
|
171 |
> |
172 |
>> Anyway, results are what are important. If you are interested in what we |
173 |
>> are doing, then I suggest coming back in a month to see what we have |
174 |
>> produced. |
175 |
> |
176 |
> Why a month? Where did that deadline come from? |
177 |
> |
178 |
> And again, the main question that has never been answered yet, "What are |
179 |
> you trying to do here?" |
180 |
> |
181 |
> thanks, |
182 |
> |
183 |
> greg k-h |
184 |
> |