1 |
On Tue, Feb 18, 2014 at 10:36 AM, Andrew Savchenko <bircoph@×××××.com> wrote: |
2 |
[...] |
3 |
> Bugs are not equal. They differ in at least two dimensions: |
4 |
> significance depending on the component affected and severity of the |
5 |
> bug itself. |
6 |
|
7 |
I've never said that they don't have different significance, severity |
8 |
or scope. I said that all bugs are bugs (which is a tautology), and |
9 |
that you only need to fix them once to go on. |
10 |
|
11 |
>> > Bugs in the critical system components are |
12 |
>> > critical to the whole system. |
13 |
>> |
14 |
>> Yeah, that's why we have unit testing and QA teams and stable and |
15 |
>> unstable releases, etc. |
16 |
> |
17 |
> Every decent project has QA and unit tests one way or another. But |
18 |
> the larger project is, the more bugs it has. And I do not want bugs |
19 |
> in PID 1, that's why it should be small and sound, not bloated (even |
20 |
> with some components split as separate binaries) and broken by design. |
21 |
|
22 |
Of course the larger a project is the *potential* number of bugs |
23 |
increases, but so what? With enough developers, users and testers, all |
24 |
bugs are *potentially* squashed. |
25 |
|
26 |
That's the important thing; you should not emasculate a project just |
27 |
to keep it "simple" under *your* definition of simple; have you looked |
28 |
at most of systemd code? It's actually pretty small and simple, and |
29 |
with well defined interfaces and boundaries. |
30 |
|
31 |
>> > If Libreoffice or browser |
32 |
>> > segfaults, some data may be lost and inconvenience created, but the |
33 |
>> > system will continue to run. If PID 1 segfaults — everything is |
34 |
>> > lost, you have a kernel panic. |
35 |
>> |
36 |
>> And the world will end? The same happens if the kernel has an error. |
37 |
> |
38 |
> Kernel has mature error correction infrastructure (Oops handling) and |
39 |
> much wider community. |
40 |
|
41 |
And systemd has a *much* wider community than any other init system. |
42 |
So it can handle a larger code base. |
43 |
|
44 |
>> > That's why critical components should |
45 |
>> > be as simple and clean as possible. |
46 |
>> |
47 |
>> Like the kernel? You call that "simple"? |
48 |
> |
49 |
> Don't mix user space and kernel space, please. There are |
50 |
> more secure by design micro kernels out there (like Hurd), but |
51 |
> they're out of the scope of this discussion. |
52 |
|
53 |
I'm not mixing kernel/user space; I'm saying that critical components |
54 |
don't need to be "simple"; they need to be *reliable*. |
55 |
|
56 |
>> I'm sorry, but you are (IMO) wrong: critical components should be |
57 |
>> thoroughly tested and debugged, and have integrated unit testing, and |
58 |
>> a large enough group of volunteers to test new releases before they go |
59 |
>> into the general public. |
60 |
> |
61 |
> You're pointing to valid issues, but not to the whole picture. |
62 |
|
63 |
I just have a different point of view for the bigger picture. |
64 |
|
65 |
> Critical components should _start_ from good design, sound modular |
66 |
> architecture and _then_ with QA and testing. You're omitting the most |
67 |
> important stuff, though. |
68 |
|
69 |
But systemd has a *good* design, a modular architecture (that's why |
70 |
it's splited in dozens of, you know, modules), and *besides* it has QA |
71 |
and testing. |
72 |
|
73 |
I'm not omitting nothing; I just don't share the same opinion as you |
74 |
as to what constitutes a good design. And this is debatable; with |
75 |
design, nothing is absolute. |
76 |
|
77 |
>> > SysVinit code size is about 10 000 lines of code, OpenRC contains |
78 |
>> > about 13 000 lines, systemd — about 200 000 lines. |
79 |
>> |
80 |
>> If you take into account the thousands of shell code that SysV and |
81 |
>> OpenRC need to fill the functionality of systemd, they use even more. |
82 |
> |
83 |
> If that code will fail, this wouldn't be critical at system level. |
84 |
> Thus scope of fatal error is limited. |
85 |
|
86 |
Also in systemd, since most of its code is not critical (again; |
87 |
logind, datetimed, localed, etc., failing, has no impact whatsoever on |
88 |
the rest of the system). |
89 |
|
90 |
>> > Even assuming |
91 |
>> > systemd code is as mature as sysvinit or openrc (though I doubt this) |
92 |
>> > you can calculate probabilities of segfaults yourself easily. |
93 |
>> |
94 |
>> I don't care about probabilities; I care about facts: FACT, I've been |
95 |
>> using systemd since 2010, in several machines, and I haven't had a |
96 |
>> single segfault. FACT: almost no bug report in systemd involves a |
97 |
>> segfault in PID 1. |
98 |
> |
99 |
> You need facts? Here is one for you (systemd-208): |
100 |
> http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg |
101 |
|
102 |
I've never said there was no segfaults; I said I had not a single one. |
103 |
Also, there are also segfaults for SysV, and for OpenRC, and for |
104 |
almost any other software out there. |
105 |
|
106 |
The important thing is the ratio of segfaults. Again, search for |
107 |
yourself in the case of PID 1 in systemd. And yeah, it will be larger |
108 |
than SysV, but SysV has, what, 40 years of existence? systemd has 4. |
109 |
|
110 |
>> >> > Looks broken. Broken by design. The worst form of broken. |
111 |
>> >> |
112 |
>> >> By your opinion, not others. |
113 |
>> > |
114 |
>> > That is not just an opinion. There is a science and experience behind |
115 |
>> > system's design. |
116 |
>> |
117 |
>> Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, |
118 |
>> or Keith Packard of X.org fame? None of them works for Red Hat; both |
119 |
>> of them know more about Unix and Linux than you and me together, and |
120 |
>> both of them promote systemd. |
121 |
> |
122 |
> I respect Greg for most of his work, but this doesn't mean he is an |
123 |
> oracle we need to adhere to. But in FOSS reputation is not that |
124 |
> important, though clean technical reasons are. |
125 |
|
126 |
You are twisting my motives to mention Greg; you said "There is a |
127 |
science and experience behind system's design"; but apparently you |
128 |
only care about the experience that supports your point of view. As a |
129 |
counter argument I mentioned Greg and Keith because both of them have |
130 |
a *LOT* of experience on Unix/Linux, and they support systemd. |
131 |
|
132 |
>> > And all that science was ignored during systemd |
133 |
>> > architecture process if there was any at all. |
134 |
>> |
135 |
>> You should read systemd-devel and Lennart's blog posts before saying |
136 |
>> something like that. I did. |
137 |
> |
138 |
> I read that blog. No valid reason were found (if we're comparing |
139 |
> systemd to what is outside of systemd's world, not only to bare |
140 |
> sysvinit). But what I found it that blog is a lack of thorough |
141 |
> project design (it looks like many components were added by the fly |
142 |
> without preliminary planning) and a lot of religious statements. |
143 |
|
144 |
Again look [1]. To me, that's a "thorough project design", and |
145 |
flexible enough that it has allowed to integrate more and more |
146 |
features in the four years since it was written. |
147 |
|
148 |
You don't agree with that? That's fine, but the design is there. |
149 |
|
150 |
We can agree to disagree if it's sound or it isn't. |
151 |
|
152 |
Regards. |
153 |
|
154 |
[1] http://0pointer.de/blog/projects/systemd.html |
155 |
-- |
156 |
Canek Peláez Valdés |
157 |
Posgrado en Ciencia e Ingeniería de la Computación |
158 |
Universidad Nacional Autónoma de México |