1 |
On Tue, Feb 9, 2016 at 9:44 AM, Daniel Campbell <zlg@g.o> wrote: |
2 |
> |
3 |
> On 02/09/2016 05:44 AM, Rich Freeman wrote: |
4 |
> |
5 |
> If you go with systemd, you have to like or agree with |
6 |
> every change they make or every design decision on everything. |
7 |
|
8 |
There is a bit of irony in suggesting this in a discussion that |
9 |
started with eudev, which is proof that you don't have to agree with |
10 |
every decision they make on everything. |
11 |
|
12 |
> I see where you're coming from, but there are situations where you |
13 |
> really *do* want that server to stay down. |
14 |
|
15 |
Of course, and auto-restarting a daemon is completely optional systemd behavior. |
16 |
|
17 |
>> |
18 |
>> Sure, systemd has more lines of code internally, but the difference |
19 |
>> is that instead of having a bazillion independent bash scripts |
20 |
>> maintained by different people at different levels of QA, you have |
21 |
>> a single codebase that almost all distros share that is maintained |
22 |
>> to a higher level of QA. Features are implemented once there |
23 |
>> instead of a million times in various shell scripts. |
24 |
> |
25 |
> And that's where something like eclasses (but for rc scripts) could be |
26 |
> used to consolidate all the redundancy. As far as I can tell we |
27 |
> already implement something similar with the built-in functions that |
28 |
> rc scripts are expected to have. The thing is, do we want to go in the |
29 |
> direction of declarative files and the limitations that come with |
30 |
> that? The complexity would then have to be migrated to the daemon |
31 |
> manager itself instead of the scripts. |
32 |
|
33 |
No need to go down that road. Somebody already wrote it for you. :) |
34 |
|
35 |
> No matter how you look at it, |
36 |
> managing daemons is non-trivial and rather complex. Most people aren't |
37 |
> going to touch unit files *or* rc scripts unless they're developers, |
38 |
> and most developers will read documentation. If anything, a developer |
39 |
> will have more control over how their daemon is handled in the rc |
40 |
> script. They would have to read systemd's C code or its plethora of |
41 |
> unit options to set it up 'just right' to achieve the same. |
42 |
|
43 |
That sounds like suggesting that in order to edit my postfix |
44 |
configuration I need to reverse engineer the software. |
45 |
|
46 |
You just grep the manpage for whatever you're looking for. I'll give |
47 |
you two guesses as to what this option does: |
48 |
|
49 |
IOSchedulingClass= |
50 |
Sets the IO scheduling class for executed processes. Takes |
51 |
an integer between 0 and 3 or one of |
52 |
the strings none, realtime, best-effort or idle. See |
53 |
ioprio_set(2) for details. |
54 |
|
55 |
>> |
56 |
>> The only reason we had OpenRC is that EVERYBODY was rolling their |
57 |
>> own service managers, and OpenRC was better than the alternatives. |
58 |
>> I think that was great, but everybody else has moved on. |
59 |
> |
60 |
> Do you consider OpenRC a project that's not useful anymore? |
61 |
|
62 |
I don't personally think it is useful, but I have no objections to |
63 |
people who do find it useful maintaining it. |
64 |
|
65 |
I think we're better off getting back onto common ground, which is choice. |
66 |
|
67 |
|
68 |
-- |
69 |
Rich |