1 |
On Mar 18, 2012 8:48 AM, "Canek Peláez Valdés" <caneko@×××××.com> wrote: |
2 |
> |
3 |
> On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras <realnc@×××××.com> |
4 |
wrote: |
5 |
> > On 17/03/12 13:53, Alan Mackenzie wrote: |
6 |
> >> |
7 |
> >> Hello, Nikos. |
8 |
> >> |
9 |
> >> On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: |
10 |
> >> |
11 |
> >>>> Happy Computer Users, systemd is on your horizon. |
12 |
> >> |
13 |
> >> |
14 |
> >>> No, we don't. I hope systemd arrives soon. It's the best init |
15 |
system I |
16 |
> >>> ever saw. |
17 |
> >> |
18 |
> >> |
19 |
> >> What's so good about it? What will it do for me? |
20 |
> >> |
21 |
> >> I have this horrible sneaking suspicion that it will be more |
22 |
complicated |
23 |
> >> than /sbin/init + OpenRC, just like udev + initramfs is more |
24 |
complicated |
25 |
> >> than udev, and CUPS is more complicated than classical lpr. |
26 |
> >> |
27 |
> >> Why do you find it so good? |
28 |
> > |
29 |
> > |
30 |
> > No idea. I only posted this because the OP didn't say what's bad about |
31 |
> > systemd :-) I really don't know I should care whether my system runs |
32 |
OpenRC |
33 |
> > or systemd. |
34 |
> |
35 |
> Take this with a grain (or a kilo) of salt, since I'm obviously |
36 |
> biased, but IMHO this are systemd advantages over OpenRC: |
37 |
> |
38 |
> * Really fast boot. OpenRC takes at least double the time that systemd |
39 |
> does when booting, easily verifiable. In my laptop systemd is twice as |
40 |
> fast as OpenRC; in my desktop is three times faster. |
41 |
> |
42 |
> * Really parallel service startup: OpenRC has never been reliable on |
43 |
> parallel service startup; its documentation says it explicitly. |
44 |
> |
45 |
> * Really simple service unit files: The service unit files are really |
46 |
> small, really simple, really easy to understand/modify. Compare the 9 |
47 |
> lines of sshd.service: |
48 |
> |
49 |
> $ cat /etc/systemd/system/sshd.service |
50 |
> [Unit] |
51 |
> Description=SSH Secure Shell Service |
52 |
> After=syslog.target |
53 |
> |
54 |
> [Service] |
55 |
> ExecStart=/usr/sbin/sshd -D |
56 |
> |
57 |
> [Install] |
58 |
> WantedBy=multi-user.target |
59 |
> |
60 |
> with the 84 of /etc/init.d/sshd (80 without comments). |
61 |
> |
62 |
> * Really good documentation: systemd has one of the best |
63 |
> documentations I have ever seen in *any* project. Everything (except |
64 |
> really new, experimental features) is documented, with manual pages |
65 |
> explaining everything. And besides, there are blog posts by Lennart |
66 |
> explaining in a more informal way how to do neat tricks with systemd. |
67 |
> |
68 |
> * Really good in-site customization: The service unit files are |
69 |
> trivially overrided with custom ones for specific installations, |
70 |
> without needing to touch the ones installed by systemd or a program. |
71 |
> With OpenRC, if I modify a /etc/init.d file, chances are I need to |
72 |
> check out my next installation so I can see how the new file differs |
73 |
> from the old one, and adapt the changes to my customized version. |
74 |
> |
75 |
> * All the goodies from Control Groups: You can use kernel cgroups to |
76 |
> monitor/control several properties of your daemons, out of the box, |
77 |
> almost no admin effort involved. |
78 |
> |
79 |
> * It tries to unify Linux behaviour among distros (some can argue that |
80 |
> this is a bad thing): Using systemd, the same |
81 |
> configurations/techniques work the same in every distribution. No more |
82 |
> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by |
83 |
> different distros. |
84 |
> |
85 |
> * Finally, and what I think is the most fundamental difference between |
86 |
> systemd and almost any other init system: The service unit files in |
87 |
> systemd are *declarative*; you tell the daemon *what* to do, not *how* |
88 |
> to do it. If the service files are shell scripts (like in |
89 |
> OpenRC/SysV), everything can spiral out of control really easily. And |
90 |
> it usually does (again, look at sshd; and that one is actully nicely |
91 |
> written, there are all kind of monsters out there abusing the power |
92 |
> that shell gives you). |
93 |
> |
94 |
> These are the ones off the top of my head; but what I like the most |
95 |
> about systemd is that it just works, and that it makes a lot of sense |
96 |
> (at least to me). |
97 |
> |
98 |
> Most of systemd features can be implemented in OpenRC (although the |
99 |
> speed difference will never be eliminated if OpenRC keeps using shell |
100 |
> files). My question is: why bother? systemd is already here, it |
101 |
> already works, and it's actually supported in Gentoo. |
102 |
> |
103 |
> But again, remember that I'm biased: I keep an overlay to run Gentoo |
104 |
> systems with only systemd; no OpenRC, no baselayout, no SysV. You guys |
105 |
> can try it if you want: |
106 |
> |
107 |
> http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ |
108 |
> |
109 |
> Usual disclaimer: I take no responsibility if using my overlay results |
110 |
> in your systems asploding. That said, I'm using it on all my machines |
111 |
> without a hitch. |
112 |
> |
113 |
> Regards. |
114 |
|
115 |
Interesting... |
116 |
|
117 |
However, what if the service is complex? For example, I created a |
118 |
"gatewall" service which, upon boot, initializes : |
119 |
|
120 |
* Routing tables and the RPDB |
121 |
* ipset |
122 |
* iptables |
123 |
|
124 |
while ensuring that upon shutdown, the settings of the above are |
125 |
(optionally) saved. |
126 |
|
127 |
How do I specify such intelligence? |
128 |
|
129 |
Rgds, |