1 |
On Tue, Dec 25, 2012 at 7:14 AM, Michael Mol <mikemol@×××××.com> wrote: |
2 |
> |
3 |
> On Dec 25, 2012 3:04 AM, "Canek Peláez Valdés" <caneko@×××××.com> wrote: |
4 |
>> |
5 |
>> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury <redwolfe@×××××.com> |
6 |
>> wrote: |
7 |
>> [ snip ] |
8 |
>> > From what has been happening with the systemd stuff, I do not see what |
9 |
>> > advantages it really offers over the SysV scheme and its successors like |
10 |
>> > OpenRC. Someone enlighten me please? |
11 |
>> |
12 |
>> I wrote the following some months ago; I think nothing much has |
13 |
>> changed since then (I added a couple of comments): |
14 |
>> |
15 |
>> Take this with a grain (or a kilo) of salt, since I'm obviously |
16 |
>> biased, but IMHO this are systemd advantages over OpenRC: |
17 |
>> |
18 |
>> * Really fast boot. OpenRC takes at least double the time that systemd |
19 |
>> does when booting, easily verifiable. In my laptop systemd is twice as |
20 |
>> fast as OpenRC; in my desktop is three times faster. (With a solid |
21 |
>> state hard drive, my laptop now boots even faster). |
22 |
>> |
23 |
>> * Really parallel service startup: OpenRC has never been reliable on |
24 |
>> parallel service startup; its documentation says it explicitly. Some |
25 |
>> will tell you that for them "it works", but just like the guys who |
26 |
>> have a separate /usr and refuse to use an initramfs, they just haven't |
27 |
>> been bitten by the inherent problems of it (just ask kernel developer |
28 |
>> Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just |
29 |
>> broken with parallel service startup. |
30 |
>> |
31 |
>> * Really simple service unit files: The service unit files are really |
32 |
>> small, really simple, really easy to understand/modify. Compare the 9 |
33 |
>> lines of sshd.service: |
34 |
>> |
35 |
>> $ cat /etc/systemd/system/sshd.service |
36 |
>> [Unit] |
37 |
>> Description=SSH Secure Shell Service |
38 |
>> After=syslog.target |
39 |
>> |
40 |
>> [Service] |
41 |
>> ExecStart=/usr/sbin/sshd -D |
42 |
>> |
43 |
>> [Install] |
44 |
>> WantedBy=multi-user.target |
45 |
>> |
46 |
>> with the 84 of /etc/init.d/sshd (80 without comments). |
47 |
>> |
48 |
>> * Really good documentation: systemd has one of the best |
49 |
>> documentations I have ever seen in *any* project. Everything (except |
50 |
>> really new, experimental features) is documented, with manual pages |
51 |
>> explaining everything. And besides, there are blog posts by Lennart |
52 |
>> explaining in a more informal way how to do neat tricks with systemd. |
53 |
>> |
54 |
>> * Really good in-site customization: The service unit files are |
55 |
>> trivially overrided with custom ones for specific installations, |
56 |
>> without needing to touch the ones installed by systemd or a program. |
57 |
>> With OpenRC, if I modify a /etc/init.d file, chances are I need to |
58 |
>> check out my next installation so I can see how the new file differs |
59 |
>> from the old one, and adapt the changes to my customized version. |
60 |
>> |
61 |
>> * All the goodies from Control Groups: You can use kernel cgroups to |
62 |
>> monitor/control several properties of your daemons, out of the box, |
63 |
>> almost no admin effort involved. |
64 |
>> |
65 |
>> * It tries to unify Linux behaviour among distros (some can argue that |
66 |
>> this is a bad thing): Using systemd, the same |
67 |
>> configurations/techniques work the same in every distribution. No more |
68 |
>> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by |
69 |
>> different distros. |
70 |
>> |
71 |
>> * Finally, and what I think is the most fundamental difference between |
72 |
>> systemd and almost any other init system: The service unit files in |
73 |
>> systemd are *declarative*; you tell the daemon *what* to do, not *how* |
74 |
>> to do it. If the service files are shell scripts (like in |
75 |
>> OpenRC/SysV), everything can spiral out of control really easily. And |
76 |
>> it usually does (again, look at sshd; and that one is actully nicely |
77 |
>> written, there are all kind of monsters out there abusing the power |
78 |
>> that shell gives you). |
79 |
>> |
80 |
>> These are the ones off the top of my head; but what I like the most |
81 |
>> about systemd is that it just works, and that it makes a lot of sense |
82 |
>> (at least to me). |
83 |
>> |
84 |
>> Most of systemd features can be implemented in OpenRC, although the |
85 |
>> speed difference will never be eliminated if OpenRC keeps using shell |
86 |
>> files; however, Luca Barbato said that using reentrant busybox the |
87 |
>> speed difference is greatly reduced (I haven't confirmed this, since I |
88 |
>> haven't even installed OpenRC in months). |
89 |
>> |
90 |
>> Now, this set of (IMO) advantages of systemd over OpenRC pile up over |
91 |
>> the advantages of OpenRC over SysV: the most important one (I believe) |
92 |
>> is that OpenRC has dependencies, so a service starts only when another |
93 |
>> has already started. AFAIK, SysV has lacked this since always. |
94 |
>> |
95 |
>> I don't think I have ever heard anyone saying that we should keep |
96 |
>> using SysV; like a lot of Unix legacies, it should just die. OpenRC is |
97 |
>> much better, but it still uses a Turing-complete language (and a |
98 |
>> really slow one) to simply tell services when to start and when to |
99 |
>> stop, and it doesn't reliably keep track of what services are really |
100 |
>> still running (anyone who has ever used the "zap" command in OpenRC |
101 |
>> knows this). |
102 |
>> |
103 |
>> systemd of course has dependencies, a reliable tracking of service |
104 |
>> status (thanks in part to the use of cgroups), and its service files |
105 |
>> can't enter in an infinite loop. |
106 |
>> |
107 |
>> Hope it helps. |
108 |
>> |
109 |
>> Regards. |
110 |
>> -- |
111 |
>> Canek Peláez Valdés |
112 |
>> Posgrado en Ciencia e Ingeniería de la Computación |
113 |
>> Universidad Nacional Autónoma de México |
114 |
>> |
115 |
> |
116 |
> Thank you. I think that may well be the cleanest set of favorable arguments |
117 |
> I've seen for systemd. |
118 |
> |
119 |
> Now, question: could I not create a "/usr" service and make things dependent |
120 |
> on /usr come after it's been mounted? That seems the single, core missing |
121 |
> piece. |
122 |
|
123 |
I'm not going into that. People with far more knowledge, experience, |
124 |
and communication hability than me (Greg, William, Michał, Diego, |
125 |
etc.) have explained why the "separated /usr without initramfs" is |
126 |
broken, and that udev/systemd actually *works* in a separated /usr |
127 |
*without* an initramfs (if you use the --with-rootprefix= configure |
128 |
option, which exists exactly for this), but that's not enough for a |
129 |
lot of folks. |
130 |
|
131 |
To be honest, I don't think nothing will be ever be enough, because |
132 |
they are not listening to technical reasons. Which is fine, I guess; |
133 |
they can now use eudev (which the only thing it does so far to is |
134 |
remove features from plain udev), and with luck their systems will |
135 |
"work", in the sense that the breakage doesn't show in their |
136 |
particular setups, like it happened with plain udev for many. If the |
137 |
breakage shows, I'm pretty sure the eudev fork will be of not help at |
138 |
all, because the problem has never been in udev (nor systemd, for that |
139 |
matter). |
140 |
|
141 |
So, no, I'm not trying to answer if you could "create a "/usr" service |
142 |
and make things dependent on /usr come after it's been mounted". I |
143 |
passed almost this entire thread because it's mostly people still |
144 |
hitting the same dead horse; really, if someone believe the eudev fork |
145 |
is the answer, they should go forth and use it. If there are people |
146 |
who don't want to believe developers like Greg Kroah-Hartman or Diego |
147 |
Pettenò when they basically say that eudev is a joke, why they would |
148 |
believe *me*? And, by the way, Diego doesn't like systemd *at all*. |
149 |
|
150 |
I just replied to Wolfe question because it was really concrete, and I |
151 |
thought I could answer it. I'm not going to hit a dead horse. |
152 |
|
153 |
Regards. |
154 |
-- |
155 |
Canek Peláez Valdés |
156 |
Posgrado en Ciencia e Ingeniería de la Computación |
157 |
Universidad Nacional Autónoma de México |