On Sun, Aug 7, 2016 at 11:12 AM, Kurt Van Dijck
<dev.kurt_AT_vandijck-laurijssen.be> wrote:
>> Date: Fri, 5 Aug 2016 13:34:31 +0200
>> From: Hadrien LACOUR <hadrien.lacour_AT_openmailbox.org>
>>
>> On Fri, Aug 05, 2016 at 08:26:42AM -0300, Marc Collin wrote:
>> > I got introduced to s6-rc [0] lately.
>> > Do you guys have any experience with it?
>> >
>> > [0] http://skarnet.org/software/s6-rc/
>> >
>>
>> When I compared daemontools, runit and this one, I thought it was the best.
>> Nice comparison: http://skarnet.org/software/s6-rc/why.html
>
> besides hating things, I'd share my findings/arguments.
>
> During my experience, I learned to dislike init system with static
> configuration. sinit (and probably a few others) at least allow you to
> do things the way that the environment requires, based on conditions
> that may not be supported in your init system, opposed to what is
> commonly agreed as the best approach on a desktop.
>
> Service dependency is not the job of the init system, each service
> should be able to determine for itself if it lacks dependencies.
> You should not copy this information to the init system, as it will not
> be able to deal with all corner cases for your service anyway.
> Importing service dependencies does:
> * not speed up booting, since you just have to start things in the right order.
> systemd does not boot (fast) based on dependencies, but on service
> start order declarations (relative to other services)
> * hide problems where your service does not properly deal with a failing
> service.
> Service dependency definitions also suffer from incomplete views on the
> system. It can only work if its perfectly defined, which unevitably does
> not work when a GUI programmer creates a nice program. He cannot import
> it into such (dependency based) init system. I've met those guys, it
> just doesn't work, without disliking such people!
>
> Service monitoring on the other hand is, IMO, always required.
> In normal operation, you simply don't want to manually restart a service
> when the service failed for some reason. Just launch the process again!
>
> Based on these findings, I wrote rund [0], inspired by sinit.
> It addresses my concerns, and performs better than systemd for booting,
> footprint, RAM usage, monitoring, modification by regular programmers,
> and operator intervention.
How do you handle udev problems? I loathe systemd on account of
it's lack of modularity (all in one process mainly for political takeover
reasons) and idiotic binary logging. I'm not sure you're right about it
being unreasonable to try to abstract the dependency stuff but it sure
should not all be in the same pid.
I'm still running it though, because it doesn't seem actually broken at
the moment and it seems like getting rid of it would probably break
hardware via udev.
Britton
Received on Sun Aug 07 2016 - 21:58:35 CEST