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