On Tue, Feb 9, 2016 at 9:44 AM, Daniel Campbell <z...@gentoo.org> wrote:
>
> On 02/09/2016 05:44 AM, Rich Freeman wrote:
>
> If you go with systemd, you have to like or agree with
> every change they make or every design decision on everything.
There is a bit of irony in suggesting this in a discussion that
started with eudev, which is proof that you don't have to agree with
every decision they make on everything.
> I see where you're coming from, but there are situations where you
> really *do* want that server to stay down.
Of course, and auto-restarting a daemon is completely optional systemd behavior.
>>
>> Sure, systemd has more lines of code internally, but the difference
>> is that instead of having a bazillion independent bash scripts
>> maintained by different people at different levels of QA, you have
>> a single codebase that almost all distros share that is maintained
>> to a higher level of QA. Features are implemented once there
>> instead of a million times in various shell scripts.
>
> And that's where something like eclasses (but for rc scripts) could be
> used to consolidate all the redundancy. As far as I can tell we
> already implement something similar with the built-in functions that
> rc scripts are expected to have. The thing is, do we want to go in the
> direction of declarative files and the limitations that come with
> that? The complexity would then have to be migrated to the daemon
> manager itself instead of the scripts.
No need to go down that road. Somebody already wrote it for you. :)
> No matter how you look at it,
> managing daemons is non-trivial and rather complex. Most people aren't
> going to touch unit files *or* rc scripts unless they're developers,
> and most developers will read documentation. If anything, a developer
> will have more control over how their daemon is handled in the rc
> script. They would have to read systemd's C code or its plethora of
> unit options to set it up 'just right' to achieve the same.
That sounds like suggesting that in order to edit my postfix
configuration I need to reverse engineer the software.
You just grep the manpage for whatever you're looking for. I'll give
you two guesses as to what this option does:
IOSchedulingClass=
Sets the IO scheduling class for executed processes. Takes
an integer between 0 and 3 or one of
the strings none, realtime, best-effort or idle. See
ioprio_set(2) for details.
>>
>> The only reason we had OpenRC is that EVERYBODY was rolling their
>> own service managers, and OpenRC was better than the alternatives.
>> I think that was great, but everybody else has moved on.
>
> Do you consider OpenRC a project that's not useful anymore?
I don't personally think it is useful, but I have no objections to
people who do find it useful maintaining it.
I think we're better off getting back onto common ground, which is choice.
--
Rich
