1 |
On Wed, Dec 26, 2012 at 4:19 PM, Kevin Chadwick <ma1l1ists@××××××××.uk> wrote: |
2 |
> On Tue, 25 Dec 2012 02:01:13 -0600 |
3 |
> Canek Peláez Valdés <caneko@×××××.com> wrote: |
4 |
> |
5 |
> To the OP of this OT sub-thread. The main difference for me is OpenRC |
6 |
> removes some of the symlink mess and uncertainty compared to for |
7 |
> example debians init. I very much like OpenRC but my fav is still |
8 |
> OpenBSD that tries to minimise the number of files/folders to be |
9 |
> potentially locked down and is very transparent and quick to follow |
10 |
> through. |
11 |
> |
12 |
>> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury |
13 |
>> <redwolfe@×××××.com> wrote: [ snip ] |
14 |
>> > From what has been happening with the systemd stuff, I do not see |
15 |
>> > what advantages it really offers over the SysV scheme and its |
16 |
>> > successors like OpenRC. Someone enlighten me please? |
17 |
>> |
18 |
>> I wrote the following some months ago; I think nothing much has |
19 |
>> changed since then (I added a couple of comments): |
20 |
>> |
21 |
>> Take this with a grain (or a kilo) of salt, since I'm obviously |
22 |
>> biased, but IMHO this are systemd advantages over OpenRC: |
23 |
>> |
24 |
>> * Really fast boot. OpenRC takes at least double the time that systemd |
25 |
>> does when booting, easily verifiable. In my laptop systemd is twice as |
26 |
>> fast as OpenRC; in my desktop is three times faster. (With a solid |
27 |
>> state hard drive, my laptop now boots even faster). |
28 |
>> |
29 |
> |
30 |
> The usual statistic cited is 2 seconds but systemd can increase the |
31 |
> time dramatically or be a complete no go on embedded systems with |
32 |
> limited cpu and/or ram. Percentages of a section of the bootup is just |
33 |
> playing games like often used by annoying marketing departments. You |
34 |
> will save more boot time by switching to xfce from KDE/Gnome with |
35 |
> stronger arguments for doing so. |
36 |
> |
37 |
>> * Really parallel service startup: OpenRC has never been reliable on |
38 |
>> parallel service startup; its documentation says it explicitly. Some |
39 |
>> will tell you that for them "it works", but just like the guys who |
40 |
>> have a separate /usr and refuse to use an initramfs, they just haven't |
41 |
>> been bitten by the inherent problems of it (just ask kernel developer |
42 |
>> Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just |
43 |
>> broken with parallel service startup. |
44 |
>> |
45 |
> |
46 |
> Not only that but is seen by many to be pointless except to minute |
47 |
> speed gains and a cause of various problems such as increased |
48 |
> difficulty in determining where a problem occurs. |
49 |
> |
50 |
>> * Really simple service unit files: The service unit files are really |
51 |
>> small, really simple, really easy to understand/modify. Compare the 9 |
52 |
>> lines of sshd.service: |
53 |
>> |
54 |
> |
55 |
> But require reading documentation to understand with no other external |
56 |
> gain, unlike shell. |
57 |
> |
58 |
>> |
59 |
>> * Really good documentation: systemd has one of the best |
60 |
>> documentations I have ever seen in *any* project. Everything (except |
61 |
>> really new, experimental features) is documented, with manual pages |
62 |
>> explaining everything. And besides, there are blog posts by Lennart |
63 |
>> explaining in a more informal way how to do neat tricks with systemd. |
64 |
>> |
65 |
> |
66 |
> That explains why I see so many asking for help. The documentation may? |
67 |
> be complete but is terrible. Like LVM it is spread out into many |
68 |
> illogical files that would require a non existent sitemap to find. |
69 |
> OpenBSD is renowned for it's excellent documentation and note that it's |
70 |
> openssl pages are consolidated. |
71 |
> |
72 |
>> * Really good in-site customization: The service unit files are |
73 |
>> trivially overrided with custom ones for specific installations, |
74 |
>> without needing to touch the ones installed by systemd or a program. |
75 |
>> With OpenRC, if I modify a /etc/init.d file, chances are I need to |
76 |
>> check out my next installation so I can see how the new file differs |
77 |
>> from the old one, and adapt the changes to my customized version. |
78 |
>> |
79 |
> |
80 |
> Nothing new, OpenBSD does similar. Completely aside from this |
81 |
> discussion. |
82 |
> |
83 |
>> * All the goodies from Control Groups: You can use kernel cgroups to |
84 |
>> monitor/control several properties of your daemons, out of the box, |
85 |
>> almost no admin effort involved. |
86 |
>> |
87 |
> |
88 |
> The OpenBSD list pointed out the double forking argument to be |
89 |
> technically pointless. |
90 |
> |
91 |
> http://marc.info/?l=openbsd-misc&m=135314269712851&w=2 |
92 |
> |
93 |
>> * It tries to unify Linux behaviour among distros (some can argue that |
94 |
>> this is a bad thing): Using systemd, the same |
95 |
>> configurations/techniques work the same in every distribution. No more |
96 |
>> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by |
97 |
>> different distros. |
98 |
>> |
99 |
> |
100 |
> So why was /etc/inittab removed for something that takes much more |
101 |
> effort to configure. |
102 |
> |
103 |
>> * Finally, and what I think is the most fundamental difference between |
104 |
>> systemd and almost any other init system: The service unit files in |
105 |
>> systemd are *declarative*; you tell the daemon *what* to do, not *how* |
106 |
>> to do it. If the service files are shell scripts (like in |
107 |
>> OpenRC/SysV), everything can spiral out of control really easily. And |
108 |
>> it usually does (again, look at sshd; and that one is actully nicely |
109 |
>> written, there are all kind of monsters out there abusing the power |
110 |
>> that shell gives you). |
111 |
>> |
112 |
> |
113 |
> Then you don't have a great deal of experience in init systems. |
114 |
> |
115 |
>> These are the ones off the top of my head; but what I like the most |
116 |
>> about systemd is that it just works, and that it makes a lot of sense |
117 |
>> (at least to me). |
118 |
>> |
119 |
>> Most of systemd features can be implemented in OpenRC, although the |
120 |
>> speed difference will never be eliminated if OpenRC keeps using shell |
121 |
>> files; however, Luca Barbato said that using reentrant busybox the |
122 |
>> speed difference is greatly reduced (I haven't confirmed this, since I |
123 |
>> haven't even installed OpenRC in months). |
124 |
>> |
125 |
> |
126 |
> So basically you like systemd because it does not follow the unix |
127 |
> philosohy of many small independent tools to be more than the sum of |
128 |
> it's parts and systemd absolutely unarguably does complicate the code |
129 |
> **REQUIRED** to boot using many external and other questionably desired |
130 |
> features as justification. |
131 |
> |
132 |
>> Now, this set of (IMO) advantages of systemd over OpenRC pile up over |
133 |
>> the advantages of OpenRC over SysV: the most important one (I believe) |
134 |
>> is that OpenRC has dependencies, so a service starts only when another |
135 |
>> has already started. AFAIK, SysV has lacked this since always. |
136 |
>> |
137 |
>> I don't think I have ever heard anyone saying that we should keep |
138 |
>> using SysV; like a lot of Unix legacies, it should just die. OpenRC is |
139 |
>> much better, but it still uses a Turing-complete language (and a |
140 |
>> really slow one) to simply tell services when to start and when to |
141 |
>> stop, and it doesn't reliably keep track of what services are really |
142 |
>> still running (anyone who has ever used the "zap" command in OpenRC |
143 |
>> knows this). |
144 |
>> |
145 |
>> systemd of course has dependencies, a reliable tracking of service |
146 |
>> status (thanks in part to the use of cgroups), and its service files |
147 |
>> can't enter in an infinite loop. |
148 |
>> |
149 |
>> Hope it helps. |
150 |
>> |
151 |
>> Regards. |
152 |
> |
153 |
> Enough time has been wasted on systemd including my own so start a new |
154 |
> thread that I can ignore from now on please or better still accept |
155 |
> that systemd is dividing and not unifying the unix community. Once you |
156 |
> realise that re-question everything else. |
157 |
|
158 |
I didn't started the thread, Wolfe did. I just answered his question |
159 |
from my point of view. |
160 |
|
161 |
And, what community is being divided? Fedora,OpenSuse, and Arch use |
162 |
systemd by default. Gentoo derivative Exherbo recommends it as init |
163 |
system. It works great on Gentoo and Debian. I understand it even |
164 |
works in Ubuntu. systemd has done more to unify the Linux ecosystem |
165 |
than a lot of other projects in the last 20 years. |
166 |
|
167 |
And, really, I don't care about OpenBSD. I worked with it for three |
168 |
years; it's a nice toy Unix. But for serious work (server, desktop and |
169 |
mobile) I prefer Linux, and in my case (except for my phone, that uses |
170 |
Android) I run Gentoo+systemd in all my machines. You don't have to |
171 |
agree with that, is my personal preference. |
172 |
|
173 |
So it's great if you believe that the OpenBSD init system is similar |
174 |
in features to systemd; but even if it's true (which I seriously |
175 |
doubt), I care only about Linux, and from my point of view, systemd is |
176 |
one of the best things to happen to it. |
177 |
|
178 |
Regards. |
179 |
-- |
180 |
Canek Peláez Valdés |
181 |
Posgrado en Ciencia e Ingeniería de la Computación |
182 |
Universidad Nacional Autónoma de México |