1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 02/09/2016 04:17 AM, Rich Freeman wrote: |
5 |
> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric |
6 |
> <kentfredric@×××××.com> wrote: |
7 |
>> |
8 |
>> A pure udev system is in comparison, much simpler than a systemd |
9 |
>> system. |
10 |
> |
11 |
> I don't buy that at all. In systemd you have a unified object |
12 |
> model across device nodes, mountpoints, services, and cron jobs. |
13 |
> In the alternate model you have completely different |
14 |
> implementations of all of those, each with their own configurations |
15 |
> and behaviors. |
16 |
|
17 |
Perhaps that's because each of those things should not actually be |
18 |
considered the same object type. That sort of design may be convenient |
19 |
to users, but is more akin to treating everything like a nail when you |
20 |
have a hammer. |
21 |
|
22 |
Also note that in the 'alternate' model, each of the above is handled |
23 |
by a different tool. It's obvious that using a combination of |
24 |
different tools will result in different conceptualizations of each of |
25 |
those parts in a system. I see little benefit in a single project |
26 |
pretending to understand everything about each of them. |
27 |
|
28 |
> |
29 |
>> |
30 |
>> And that's much of the beauty of OpenRC. Its simple, it achieves |
31 |
>> the same goals as Systemd and Upstart, etc, but does so with a |
32 |
>> lot less mechanics under the hood, and doesn't clutter up systems |
33 |
>> with features you don't need prematurely. |
34 |
> |
35 |
> OpenRC doesn't achieve MANY of the goals of systemd. Maybe you |
36 |
> don't personally care about some of them, but you really can't |
37 |
> compare the feature sets at this point. |
38 |
> |
39 |
>> And there are great benefits from simplicity over complexity. |
40 |
> |
41 |
> Absolutely. It is great to create a text file and symlink it in a |
42 |
> directory named after a service to make that service auto-restart, |
43 |
> or have a memory limit, or set an IO priority for that service. It |
44 |
> is great to not have to think about anything to have just about all |
45 |
> your processes organized into a sensible cgroup hierarchy. It is |
46 |
> great to be able to tweak one config file to ensure that users who |
47 |
> log out of a system can't leave any processes behind. |
48 |
> |
49 |
> It is great to be able to tweak something in policykit and change |
50 |
> things like who can shut down the system, or who can restart a |
51 |
> service. |
52 |
> |
53 |
> The simplicity of systemd comes from the fact that it has brought |
54 |
> what used to be a collection of many independent tools under one |
55 |
> roof, and created a converging set of interfaces for all of them. |
56 |
|
57 |
If I didn't know any better I'd say this reads like shilling. Firstly, |
58 |
there's a real problem if you're depending on a daemon restarting |
59 |
itself. Why is it stopping in the first place? If it's stopping, |
60 |
something wrong is happening and restarting it *isn't* going to fix it. |
61 |
|
62 |
Existing permission systems handle a lot of cases. *kit (logind, is |
63 |
more like it) has some extra things to make it a bit more granular. |
64 |
It's mostly unneeded complexity. The biggest benefit logind brings to |
65 |
a system is multi-seat capability. |
66 |
> |
67 |
>> And a lot of Gentoo is surprisingly simple: Like our use of bash |
68 |
>> scripts for recipies to build things, like using rsync to |
69 |
>> deploy/relay not just those recipies, but security notices and |
70 |
>> news items, which are themselves reasonably simple formats. |
71 |
> |
72 |
> Well, one thing about Gentoo that certainly isn't simple is our |
73 |
> init.d scripts. |
74 |
> |
75 |
> Compare this: http://pastebin.com/sSDtpF4t |
76 |
> |
77 |
> With this: http://pastebin.com/Lfn8r7qP |
78 |
> |
79 |
> Systemd does the job in 10% of the code (and half of it is a |
80 |
> comment), and doesn't implement its own service polling and killer |
81 |
> script during shutdown independently for every service (not that |
82 |
> every init.d script even does this - most of them will just leave |
83 |
> orphans behind, and systemd will catch orphans that even the |
84 |
> lengthy init.d script for apache misses). |
85 |
|
86 |
This is a dishonest comparison. You're comparing a declarative |
87 |
configuration file with a Turing-complete scripting language. If we're |
88 |
going by SLOC, we would need to also consider all the C code that |
89 |
systemd uses to *act* on said declarative file. One could argue that |
90 |
rc scripts in this case are a lot of repetition, and that'd be |
91 |
correct. There's nothing stopping rc scripts from becoming similar to |
92 |
systemd's unit files. It'd be akin to our eclass system. But why is |
93 |
this important? OpenRC supports cgroups, so if a daemon isn't reaping |
94 |
its children correctly, a bug needs to be filed, either on the package |
95 |
providing the script or on OpenRC itself. |
96 |
> |
97 |
>> |
98 |
>> The only preference I see here is the preference to not have and |
99 |
>> install things your system has no use for, which I find an odd |
100 |
>> preference to be complaining about, and depending on your system |
101 |
>> requirements, that may also be not so much "preference". |
102 |
>> |
103 |
> |
104 |
> And hence my suggestion that we simply get this stuff out of the |
105 |
> stage3s in the first place. Then everybody can just pick the |
106 |
> implementation that best suits their requirements. |
107 |
|
108 |
I can get behind that. This dodges all sorts of arguments regarding |
109 |
initial installations. There's still the issue of the virtual, |
110 |
however; would we add sys-fs/udev to p.mask in non-systemd profiles to |
111 |
clarify the decision, or make eudev the default choice in the virtual? |
112 |
I think we can all agree on making it an additional step in the |
113 |
handbook, but the default is still at hand. |
114 |
> |
115 |
> If you want to talk about default providers, the most |
116 |
> straightforward one to use is systemd. It is what people are going |
117 |
> to be used to coming from other distros, it is what every upstream |
118 |
> package expects to be running anyway, and it is the simpler tool |
119 |
> that does everything that most people want. |
120 |
> |
121 |
> For people who want a more exotic configuration, there are |
122 |
> alternatives, and Gentoo should certainly support using them as |
123 |
> long as people care to maintain them. |
124 |
|
125 |
This is the same argument other distros used before they switched |
126 |
completely to systemd. When has Gentoo ever been about marching to the |
127 |
beat of other distros? Are you advocating for following what others do |
128 |
simply because it's popular? |
129 |
|
130 |
We have nothing to gain by making systemd the default init system, and |
131 |
it would tick off a considerable portion of our userbase, even with it |
132 |
being changeable. It's one thing to put it on the live media, or even |
133 |
as part of (a flavor of) a stage4, but to push for it being a default |
134 |
across the board on a standard install is a bit much. |
135 |
|
136 |
The e-mails I've seen from you in this thread seem out of the |
137 |
ordinary. Has the systemd team been talking with you, or people from |
138 |
other distributions urging for Gentoo to switch? |
139 |
|
140 |
To clarify, there's nothing wrong with systemd as a choice. It's |
141 |
special enough that it has its own set of profiles. I think that's |
142 |
enough, and creates a workable path for both. |
143 |
|
144 |
For this thread, it seems that we need to do something similar with |
145 |
eudev. sys-fs/udev already comes with the systemd profile, and eudev |
146 |
fulfills all the same needs. Maybe we should speak with our users and |
147 |
find out just how many people are using systemd-udev intentionally |
148 |
rather than going along with it as a default, and their reasoning for |
149 |
doing so. The same could go for eudev. Not so much for numbers |
150 |
(because unlike Debian, we have nothing comparable to popcon), but to |
151 |
see where people are standing on it. |
152 |
|
153 |
- -- |
154 |
Daniel Campbell - Gentoo Developer |
155 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
156 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
157 |
-----BEGIN PGP SIGNATURE----- |
158 |
Version: GnuPG v2 |
159 |
|
160 |
iQIcBAEBCAAGBQJWueRSAAoJEAEkDpRQOeFw7DYP/i4hqRWuhSVUZsAXE8DX9GAa |
161 |
vapYjX43fb5S5BzgqS5KVbRWUdDUQNAghyy9kywPUFjjQRArzTF+xX3EmBhj5rUG |
162 |
Agar+BB3fGh19NbvMtwoJ3C+eHBw7aNGkmlj65vpMOmOnZ/7lDZNU0PbZ4GtDdmp |
163 |
FoQ2ooR5+TAV7xZaMRf5liwcptMcIPrOhksvUWtzRPhFjGyJLRtg60xO6hxC5Zc0 |
164 |
yF+hrO8/QNnqIvKn5u1sXAx3GyRE2UZtPX+Fad6Z376gH+8T7CtbqjLT1rxIZedd |
165 |
CYLusg/AdENLsS6EVy6KN5exIH1oAeAqWwtiUS88VURzP7QY7TA3RbCPVVgCFe0M |
166 |
kM2J5JZqlrdCxG935zEk3kiO9dtW4wBQNbjyLD7G3PCkWWnv2eZsP+lk+pFQlIvw |
167 |
+Sfbb4nrtusSu8MYkeLnAQJ3oyt8qYUQN0Ip07Y/5h+3pKizMi/A2NVjLdoH35tx |
168 |
KXnpy5LPYn7Hk7UrVGPdgNQC/GckRcIAgwjH90fvO2cOAV6pdcPAR/VYxaodQeWZ |
169 |
AUZdT6ksmuZuhfBgZBEU2X2ilEVZsDI22egjz5/+FCDZjr2c56cURCP6+GXcW4ao |
170 |
LaM/OoTmHkEQSG4PVTSNE6wXN9lrVx5v/TvH9vDjdViugdzOUHyt58gXiC+Bk8wA |
171 |
XD8LH56ilZGFcoJWdmSR |
172 |
=Ggkl |
173 |
-----END PGP SIGNATURE----- |