Gentoo Archives: gentoo-user

From: "Canek Peláez Valdés" <caneko@×××××.com>
To: Andrew Savchenko <bircoph@×××××.com>
Cc: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Date: Tue, 18 Feb 2014 00:35:49
Message-Id: CADPrc81i2FrQoH8rapEuqqRzg816z96Yvxa0tYZzogo75D5RyA@mail.gmail.com
In Reply to: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie by Andrew Savchenko
1 On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko <bircoph@×××××.com> wrote:
2 > On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote:
3 >> On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
4 >> <volkerarmin@××××××××××.com> wrote:
5 >> > Am 16.02.2014 21:08, schrieb Canek Peláez Valdés:
6 >> >> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
7 >> >> <volkerarmin@××××××××××.com> wrote:
8 >> >> [ snip ]
9 >> >>> or it is an idiotic decision. Because features means complexity.
10 >> >> Yeah, like the kernel.
11 >> >>
12 >> >>> Complexity means bugs.
13 >> >> Bugs get reported, bugs get fixes. Life goes on.
14 >>
15 >> You didn't answered this, did you?
16 >
17 > Bugs are different.
18
19 Bugs are bugs, period. And they get reported and fixed.
20
21 > Bugs in the critical system components are
22 > critical to the whole system.
23
24 Yeah, that's why we have unit testing and QA teams and stable and
25 unstable releases, etc.
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 > That's why critical components should
35 > be as simple and clean as possible.
36
37 Like the kernel? You call that "simple"?
38
39 I'm sorry, but you are (IMO) wrong: critical components should be
40 thoroughly tested and debugged, and have integrated unit testing, and
41 a large enough group of volunteers to test new releases before they go
42 into the general public.
43
44 > SysVinit code size is about 10 000 lines of code, OpenRC contains
45 > about 13 000 lines, systemd — about 200 000 lines.
46
47 If you take into account the thousands of shell code that SysV and
48 OpenRC need to fill the functionality of systemd, they use even more.
49
50 Also, again, systemd have a lot of little binaries, many of them
51 optional. The LOC of PID 1 is actually closer to SysV (although still
52 bigger).
53
54 > Even assuming
55 > systemd code is as mature as sysvinit or openrc (though I doubt this)
56 > you can calculate probabilities of segfaults yourself easily.
57
58 I don't care about probabilities; I care about facts: FACT, I've been
59 using systemd since 2010, in several machines, and I haven't had a
60 single segfault. FACT: almost no bug report in systemd involves a
61 segfault in PID 1.
62
63 >> >> All of them are different tools providing one capability to systemd as
64 >> >> a whole. So systemd is a collection of tools, where each one does one
65 >> >> thing, and it does it well.
66 >> >>
67 >> >> By your definition, systemd perfectly follows "the unix way".
68 >> >>
69 >> >
70 >> > no, it isn't.
71 >> >
72 >> > How are those binaries talk to each other?
73 >>
74 >> dbus, which is about to be integrated into the kernel with kdbus.
75 >
76 > And this is a very, very bad idea. Looks like you don't know matter at
77 > all: to begin with kdbus protocol is NOT compatible dbus and special
78 > converter daemon will be needed to enable dbus to talk to kdbus.
79
80 kdbus uses a different wire protocol than dbus; but for clients that
81 doesn't matter; libsystemd-dbus will offer a compatibility layer (talk
82 about "standard" and "replaceable"), so if your application uses dbus
83 today, it will work with kdbus.
84
85 Of course, new applications will take advantage of the new features of kdbus.
86
87 > The
88 > whole kdbus technology is very questionable itself (and was
89 > forcefully pushed by RH devs),
90
91 Sorry, but it's you who doesn't know the matter at hand: kdbus was
92 (and is) written by Greg Kroah-Hartman, Linus' right hand, and who
93 works for the Linux Foundation.
94
95 > anyway it is possible to disable this
96 > stuff in kernel and guess what will be done on my systems.
97
98 Good for you. Guess what will be done in mine?
99
100 >> > Looks broken. Broken by design. The worst form of broken.
101 >>
102 >> By your opinion, not others.
103 >
104 > That is not just an opinion. There is a science and experience behind
105 > system's design.
106
107 Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand,
108 or Keith Packard of X.org fame? None of them works for Red Hat; both
109 of them know more about Unix and Linux than you and me together, and
110 both of them promote systemd.
111
112 I mean, I myself know a thing or two about computing and Linux, and I
113 promote systemd (and nobody pays me, BTW), but obviously you don't
114 need to believe in my credentials.
115
116 And, no offense, but I will always give more weight to the words of
117 Greg Kroah-Hartman or Keith Packard (to name only two), instead of a
118 random user in gentoo-user.
119
120 There are knowledgeable people who are against systemd. But usually
121 they don't give *technical* sound reasons.
122
123 > And all that science was ignored during systemd
124 > architecture process if there was any at all.
125
126 You should read systemd-devel and Lennart's blog posts before saying
127 something like that. I did.
128
129 Regards
130 --
131 Canek Peláez Valdés
132 Posgrado en Ciencia e Ingeniería de la Computación
133 Universidad Nacional Autónoma de México

Replies