1 |
On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
> |
3 |
> A pure udev system is in comparison, much simpler than a systemd system. |
4 |
|
5 |
I don't buy that at all. In systemd you have a unified object model |
6 |
across device nodes, mountpoints, services, and cron jobs. In the |
7 |
alternate model you have completely different implementations of all |
8 |
of those, each with their own configurations and behaviors. |
9 |
|
10 |
> |
11 |
> And that's much of the beauty of OpenRC. Its simple, it achieves the |
12 |
> same goals as Systemd and Upstart, etc, but does so with a lot less |
13 |
> mechanics under the hood, and doesn't clutter up systems with features |
14 |
> you don't need prematurely. |
15 |
|
16 |
OpenRC doesn't achieve MANY of the goals of systemd. Maybe you don't |
17 |
personally care about some of them, but you really can't compare the |
18 |
feature sets at this point. |
19 |
|
20 |
> And there are great benefits from simplicity over complexity. |
21 |
|
22 |
Absolutely. It is great to create a text file and symlink it in a |
23 |
directory named after a service to make that service auto-restart, or |
24 |
have a memory limit, or set an IO priority for that service. It is |
25 |
great to not have to think about anything to have just about all your |
26 |
processes organized into a sensible cgroup hierarchy. It is great to |
27 |
be able to tweak one config file to ensure that users who log out of a |
28 |
system can't leave any processes behind. |
29 |
|
30 |
It is great to be able to tweak something in policykit and change |
31 |
things like who can shut down the system, or who can restart a |
32 |
service. |
33 |
|
34 |
The simplicity of systemd comes from the fact that it has brought what |
35 |
used to be a collection of many independent tools under one roof, and |
36 |
created a converging set of interfaces for all of them. |
37 |
|
38 |
> And a lot of Gentoo is surprisingly simple: Like our use of bash |
39 |
> scripts for recipies to build things, like using rsync to deploy/relay |
40 |
> not just those recipies, but security notices and news items, which |
41 |
> are themselves reasonably simple formats. |
42 |
|
43 |
Well, one thing about Gentoo that certainly isn't simple is our init.d scripts. |
44 |
|
45 |
Compare this: |
46 |
http://pastebin.com/sSDtpF4t |
47 |
|
48 |
With this: |
49 |
http://pastebin.com/Lfn8r7qP |
50 |
|
51 |
Systemd does the job in 10% of the code (and half of it is a comment), |
52 |
and doesn't implement its own service polling and killer script during |
53 |
shutdown independently for every service (not that every init.d script |
54 |
even does this - most of them will just leave orphans behind, and |
55 |
systemd will catch orphans that even the lengthy init.d script for |
56 |
apache misses). |
57 |
|
58 |
> |
59 |
> The only preference I see here is the preference to not have and |
60 |
> install things your system has no use for, which I find an odd |
61 |
> preference to be complaining about, and depending on your system |
62 |
> requirements, that may also be not so much "preference". |
63 |
> |
64 |
|
65 |
And hence my suggestion that we simply get this stuff out of the |
66 |
stage3s in the first place. Then everybody can just pick the |
67 |
implementation that best suits their requirements. |
68 |
|
69 |
If you want to talk about default providers, the most straightforward |
70 |
one to use is systemd. It is what people are going to be used to |
71 |
coming from other distros, it is what every upstream package expects |
72 |
to be running anyway, and it is the simpler tool that does everything |
73 |
that most people want. |
74 |
|
75 |
For people who want a more exotic configuration, there are |
76 |
alternatives, and Gentoo should certainly support using them as long |
77 |
as people care to maintain them. |
78 |
|
79 |
-- |
80 |
Rich |