1 |
On Mon, 17 Feb 2014 18:35:34 -0600 Canek Peláez Valdés wrote: |
2 |
[...] |
3 |
> >> >>> Complexity means bugs. |
4 |
> >> >> Bugs get reported, bugs get fixes. Life goes on. |
5 |
> >> |
6 |
> >> You didn't answered this, did you? |
7 |
> > |
8 |
> > Bugs are different. |
9 |
> |
10 |
> Bugs are bugs, period. And they get reported and fixed. |
11 |
|
12 |
Bugs are not equal. They differ in at least two dimensions: |
13 |
significance depending on the component affected and severity of the |
14 |
bug itself. |
15 |
|
16 |
> > Bugs in the critical system components are |
17 |
> > critical to the whole system. |
18 |
> |
19 |
> Yeah, that's why we have unit testing and QA teams and stable and |
20 |
> unstable releases, etc. |
21 |
|
22 |
Every decent project has QA and unit tests one way or another. But |
23 |
the larger project is, the more bugs it has. And I do not want bugs |
24 |
in PID 1, that's why it should be small and sound, not bloated (even |
25 |
with some components split as separate binaries) and broken by design. |
26 |
|
27 |
> > If Libreoffice or browser |
28 |
> > segfaults, some data may be lost and inconvenience created, but the |
29 |
> > system will continue to run. If PID 1 segfaults — everything is |
30 |
> > lost, you have a kernel panic. |
31 |
> |
32 |
> And the world will end? The same happens if the kernel has an error. |
33 |
|
34 |
Kernel has mature error correction infrastructure (Oops handling) and |
35 |
much wider community. |
36 |
|
37 |
> > That's why critical components should |
38 |
> > be as simple and clean as possible. |
39 |
> |
40 |
> Like the kernel? You call that "simple"? |
41 |
|
42 |
Don't mix user space and kernel space, please. There are |
43 |
more secure by design micro kernels out there (like Hurd), but |
44 |
they're out of the scope of this discussion. |
45 |
|
46 |
> I'm sorry, but you are (IMO) wrong: critical components should be |
47 |
> thoroughly tested and debugged, and have integrated unit testing, and |
48 |
> a large enough group of volunteers to test new releases before they go |
49 |
> into the general public. |
50 |
|
51 |
You're pointing to valid issues, but not to the whole picture. |
52 |
Critical components should _start_ from good design, sound modular |
53 |
architecture and _then_ with QA and testing. You're omitting the most |
54 |
important stuff, though. |
55 |
|
56 |
> > SysVinit code size is about 10 000 lines of code, OpenRC contains |
57 |
> > about 13 000 lines, systemd — about 200 000 lines. |
58 |
> |
59 |
> If you take into account the thousands of shell code that SysV and |
60 |
> OpenRC need to fill the functionality of systemd, they use even more. |
61 |
|
62 |
If that code will fail, this wouldn't be critical at system level. |
63 |
Thus scope of fatal error is limited. |
64 |
|
65 |
> > Even assuming |
66 |
> > systemd code is as mature as sysvinit or openrc (though I doubt this) |
67 |
> > you can calculate probabilities of segfaults yourself easily. |
68 |
> |
69 |
> I don't care about probabilities; I care about facts: FACT, I've been |
70 |
> using systemd since 2010, in several machines, and I haven't had a |
71 |
> single segfault. FACT: almost no bug report in systemd involves a |
72 |
> segfault in PID 1. |
73 |
|
74 |
You need facts? Here is one for you (systemd-208): |
75 |
http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg |
76 |
|
77 |
> >> > Looks broken. Broken by design. The worst form of broken. |
78 |
> >> |
79 |
> >> By your opinion, not others. |
80 |
> > |
81 |
> > That is not just an opinion. There is a science and experience behind |
82 |
> > system's design. |
83 |
> |
84 |
> Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, |
85 |
> or Keith Packard of X.org fame? None of them works for Red Hat; both |
86 |
> of them know more about Unix and Linux than you and me together, and |
87 |
> both of them promote systemd. |
88 |
|
89 |
I respect Greg for most of his work, but this doesn't mean he is an |
90 |
oracle we need to adhere to. But in FOSS reputation is not that |
91 |
important, though clean technical reasons are. |
92 |
|
93 |
> > And all that science was ignored during systemd |
94 |
> > architecture process if there was any at all. |
95 |
> |
96 |
> You should read systemd-devel and Lennart's blog posts before saying |
97 |
> something like that. I did. |
98 |
|
99 |
I read that blog. No valid reason were found (if we're comparing |
100 |
systemd to what is outside of systemd's world, not only to bare |
101 |
sysvinit). But what I found it that blog is a lack of thorough |
102 |
project design (it looks like many components were added by the fly |
103 |
without preliminary planning) and a lot of religious statements. |
104 |
|
105 |
Best regards, |
106 |
Andrew Savchenko |