1 |
On Thu, Dec 27, 2012 at 10:00 AM, pk <peterk2@××××××××.se> wrote: |
2 |
> On 2012-12-27 02:14, Canek Peláez Valdés wrote: |
3 |
> |
4 |
>> I really think that's the crux of the matter Pandou: udev/systemd |
5 |
>> serves to the wants of the many. The eudev fork serves to the wants of |
6 |
> |
7 |
> systemd+udev serves the "large mass" (users of mainly Fedora and other |
8 |
> distros using systemd) that doesn't care/know computers. |
9 |
|
10 |
Well, yeah, that's the point. I want to install Gentoo in my mother's |
11 |
PC, and never have to go to her house because someting broke. |
12 |
|
13 |
>> a very few which really don't want an initramfs, when it has a lot of |
14 |
>> technical advantages. It has some problems, of course, but we can |
15 |
>> solve those, and solve the problem *in the general case*. Which is the |
16 |
>> one that it's important ant interesting. |
17 |
> |
18 |
> It's unimportant and uninteresting on the terms that |
19 |
> Poettering/Sievers/Greg KH put forward, for us that wants control and |
20 |
> does not want an all singing and dancing system (incl. "kitchen sink"). |
21 |
> In my opinion the init system should be completely independent of the |
22 |
> kernel with a well defined, generic, interface so that the user can |
23 |
> choose and pick whatever pieces he/she wishes to run his system. Think |
24 |
> "Lego" (as in small, well defined pieces that fit together in any way |
25 |
> the user sees fit)... |
26 |
|
27 |
And how's that changed? If you want control, you will *always* have |
28 |
control. The source code is out there; what more control do you need? |
29 |
|
30 |
>> my wishing luck to the eudev fork (which, BTW, Greg also did). The few |
31 |
> |
32 |
> The way I read Greg's "good luck" was that it had quite a bit of a |
33 |
> sarcastic tone... Was there really any need for him to say anything at |
34 |
> all? I've previously had a lot of respect for Greg but this made me |
35 |
> think quite a lot less of him... |
36 |
|
37 |
That's how you choose to interpret it, and I'm pretty sure it was not |
38 |
the way Greg said it. |
39 |
|
40 |
>> of us who *dare* to praise udev/systemd get an incredible amount of |
41 |
>> crap for it. We are nothing but fanbois or, in your words, "udev has |
42 |
>> become like the cosmos: everything there is, and ever shall be." |
43 |
>> Really? I didn't knew that. |
44 |
> |
45 |
> You really sound like a fanboy... And I don't mean that in a derogatory |
46 |
> way; it's just how I see your writing... |
47 |
|
48 |
It does sound derogatory... |
49 |
|
50 |
>> Maybe we are doing it wrong. But as far as i can see, we are only |
51 |
>> expressing our opinion on technical grounds. We are not calling names |
52 |
> |
53 |
> Your opinions (technical or not) doesn't matter to me since (it seems) |
54 |
> you have a very different goal than me with your system. I want you to |
55 |
> enjoy whatever system you use but you shouldn't try to force that same |
56 |
> system on to me. In that regard I see the eudev fork as a saviour. |
57 |
|
58 |
What *I* am forcing on *anyone*? How could *I* force *anything* on |
59 |
*anyone*? I'm just stating why I believe udev/systemd is a nice |
60 |
solution to the general problem. That's all: I'm not a developer, I'm |
61 |
not a distro planer; I'm not in any way capable to enforce anything on |
62 |
anyone. |
63 |
|
64 |
And I, if I'm allowed to repeat it, have never called names on anyone. |
65 |
I'm just stating my opinion; how could you twist that into the idea |
66 |
that I'm trying "to force that same system on to me"? Really? |
67 |
|
68 |
> These are the technical grounds that I've seen you state: |
69 |
> |
70 |
> * fast boot time |
71 |
> Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to |
72 |
> XDM for me. The few seconds that it takes to boot from grub to login is |
73 |
> of no matter (to me). |
74 |
|
75 |
It matters to me. A lot. Specially in my laptop (I follow |
76 |
vanilla-sources unstable, so I reboot relatively often), in my media |
77 |
center (same reasons). In my servers certainly the hardware |
78 |
initialization phase is longer; but (IMO) that makes even more |
79 |
important the speed gains from grub to userspace. |
80 |
|
81 |
Please, understand that my above (↑) reasons doesn't mean I don't care |
82 |
of yours, or that you are wrong. It only means that our reasons are |
83 |
different, and then perhaps the proper thing to do is to agree to |
84 |
disagree. |
85 |
|
86 |
> * parallel service startup |
87 |
> Nice to have but still irrelevant, see above. Sequential is also |
88 |
> preferred from a trouble shooting perspective. Furthermore I like having |
89 |
> the ability to stop a particular daemon if there something that needs |
90 |
> fixing (pushing "I" when booting). |
91 |
|
92 |
Relevant for me, see above. And that's another thing I hate about the |
93 |
shell init scripts; problems get "workarounded" instead of properly |
94 |
fixed. If there is a problem at boot time *it should be fixed where |
95 |
the problem lives*, not "workarounded" with shell hackery. |
96 |
|
97 |
Again, please understand that my above (↑) reasons doesn't mean I |
98 |
don't care of yours, or that you are wrong. It only means that our |
99 |
reasons are different, and then perhaps the proper thing to do is to |
100 |
agree to disagree. |
101 |
|
102 |
> * "simple service unit files" |
103 |
> Simplicity is fine but to accomplish the same in your simple "service" |
104 |
> file as in the example you brought forward (sshd) you need to hide a lot |
105 |
> of stuff elsewhere. Not for me thanks, I'm a control freak. |
106 |
|
107 |
I'm not; let the machines do the work. The least I have to think about |
108 |
my system, the better; I care only for it to work. |
109 |
|
110 |
Again, please understand that my above (↑) reasons doesn't mean I |
111 |
don't care about yours, or that you are wrong. It only means that our |
112 |
reasons are different, and then perhaps the proper thing to do is to |
113 |
agree to disagree. |
114 |
|
115 |
> * good documentation |
116 |
> I haven't read it so I won't touch this. Not a technical point though, |
117 |
> more of an opinion. Although I agree that good documentation is very |
118 |
> nice to have. |
119 |
|
120 |
Common ground. |
121 |
|
122 |
> * "Really good in-site customization" |
123 |
> If I choose to upgrade a daemon, I should be interested in what changes, |
124 |
> if any, that brings in configuration in order to not have any surprises |
125 |
> later. If you think that's a good thing, that really sounds like you |
126 |
> would be doing the OpenRC equivalent of: |
127 |
> 'etc-update --automode -5' |
128 |
|
129 |
But that's the beauty of systemd; I don't have to do *anything*. If |
130 |
the original unit file gets updated, my customization gets updated to. |
131 |
Again, I don't need to do anything. |
132 |
|
133 |
Again, please understand that my above (↑) reasons doesn't mean I |
134 |
don't care about yours, or that you are wrong. It only means that our |
135 |
reasons are different, and then perhaps the proper thing to do is to |
136 |
agree to disagree. |
137 |
|
138 |
> * control groups |
139 |
> As I understand it, this depends on someone writing config files for the |
140 |
> individual daemons. Noone is stopping Gentoo devs or anyone else from |
141 |
> writing such. And I would, again, prefer to go through a good manual or |
142 |
> a "howto" and do it myself so that I can understand the consequences, if |
143 |
> I would want it. |
144 |
|
145 |
It's a little more difficult than "writing config files", in OpenRC's |
146 |
case. To begin with, you need to check if there is cgroup support. |
147 |
|
148 |
Again, please understand that my above (↑) reasons doesn't mean I |
149 |
don't care about yours, or that you are wrong. It only means that our |
150 |
reasons are different, and then perhaps the proper thing to do is to |
151 |
agree to disagree. |
152 |
|
153 |
> * unification |
154 |
> I've tried quite a few distros over the years (starting with Redhat in |
155 |
> the late 90'ies) and Gentoos OpenRC is by far the most sane system I've |
156 |
> come across. Never going back to Redhat hell thank you! Standardizing |
157 |
> the interfaces is fine but it's not ok to force a whole "kitchen and |
158 |
> sink" solution in order to "satisfy" as many as possible. This is not |
159 |
> the Gentoo way, as I understand it. Gentoo is all about choice. |
160 |
|
161 |
And who has taken any choice from you? Even if systemd became the |
162 |
default init system in Gentoo, you will be able to install OpenRC |
163 |
always. Even if there is no ebuild, you'll be *always* able to do |
164 |
"./configure && make && make install". Nobody is taking choices from |
165 |
anyone. I just want udev/systemd to work fine in Gentoo (which it |
166 |
does) and not having to install OpenRC if I don't need it (which I |
167 |
need to use my overlay right now). |
168 |
|
169 |
I just want *my* choice to be a 1st class citizen in Gentoo; right now |
170 |
it's not. If Gentoo is (as you say) "about choice" (which, BTW, I |
171 |
don't agree 100%), then I should be able to use systemd without OpenRC |
172 |
without me needing to use an overlay, shouldn't I? |
173 |
|
174 |
Again, please understand that my above (↑) reasons doesn't mean I |
175 |
don't care about yours, or that you are wrong. It only means that our |
176 |
reasons are different, and then perhaps the proper thing to do is to |
177 |
agree to disagree. |
178 |
|
179 |
> * "you tell the daemon *what* to do, not *how* to do it" |
180 |
> It's good if you don't want to learn about what things you install and |
181 |
> understand what the consequences are of different choices, in the config |
182 |
> files. I run very few daemons on my desktop machine so it's not so time |
183 |
> consuming to read up on/fix things etc. If I ever were to run a full |
184 |
> blown server (esp. connected to the "net") with lots of daemons I would |
185 |
> be very hesitant to use any pre-configurations, seems suicidal to me. |
186 |
> The only usage I see here of "declarative" scripts are when you don't |
187 |
> care about what the machine is doing. |
188 |
|
189 |
I think you are gravely mistaken in this last point: you can learn |
190 |
*all* the things you can from systemd as in OpenRC. The source is out |
191 |
there, nothing is "hidding". |
192 |
|
193 |
But, one last time, probably the best thing to do is to agree to |
194 |
disagree; your answers to my technical points are all basically "I |
195 |
don't wanna/I don't like it/I don't care about it"... which is |
196 |
perfectly fine, but I can retort each and everyone with a mirror |
197 |
argument. |
198 |
|
199 |
So, yeah, let's just agree to disagree |
200 |
|
201 |
Regards. |
202 |
-- |
203 |
Canek Peláez Valdés |
204 |
Posgrado en Ciencia e Ingeniería de la Computación |
205 |
Universidad Nacional Autónoma de México |