On Fri, 12 Jun 2015 19:37:21 +0200
Laurent Bercot <ska-devel@???> wrote:

> On 12/06/2015 19:01, Steve Litt wrote:
> > The one thing I *do* know is that we need to provide a sd_notify
> > interface, even if it does nothing at all and drops passed
> > information on the floor.
>
> Please don't do this.
> The more you bend to the systemd interfaces, the more it gets a foot
> in the door. By implementing a dummy sd_notify, you acknowledge the
> validity of the interface; you accept that the systemd people have
> created something worth using, and you validate the existence of
> (a part of) systemd.
>
> The thing is, the sd_notify interface is not *too* bad, but like
> the rest of systemd, it is overengineered, too complex, and mixes
> several different things in a monolithic way so that people who are
> trying to actually implement real support for sd_notify are bound
> to reinvent systemd one way or another.
>
> It's absolutely like the old Microsoft "embrace and extend"
> strategy, you know. They get one foot in the door by providing
> something useful, but then pile their own crap onto it, and people
> are already relying on it, so you want to implement support for it,
> and then you're captive, and the only way to be 100%-compatible is to
> use the original product.
>

>   There's a much simpler mechanism that can be used to provide
> readiness notification, and that I suggest in
>     http://skarnet.org/software/s6/notifywhenup.html
> and that is: write a given character on a descriptor, then close that
> descriptor.
>   It doesn't get any simpler than that, it doesn't require linking
> daemons against any library, and it can be made to be compatible
> with *everything*. If a daemon supports that mechanism, it is very
> easy to write a systemd-notify program that would wrap that daemon and
> communicate with systemd via sd_notify to inform it of the daemon's
> readiness, the way s6-notifywhenup does for s6.

>
> Please KISS, and design good interfaces to be adopted, instead of
> letting yourselves get bullied by systemd forcing its interfaces down
> your throats and jumping through hoops to adapt to them. With a
> simpler interface and a trivial wrapper program, the influence of
> systemd only extends to the wrapper program, and not to the daemons
> themselves.

Hi Laurent,

I agree with every single thing you write above, but have one question
for you: What does Devuan do when daemons like cupsd and sshd make
sd_notify calls, and these don't condition the call on sd_notify being
available, and sd_notify cannot be conditionally recompiled out of the
program? Is Devuan going to rewrite every single daemon?

By the way, if there *were* a stub sd_notify, I'd have nothing against
it doing nothing but passing the info to S6-notifywhenup or something
like it.

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key