On Fri, 12 Jun 2015 19:37:21 +0200 Laurent Bercot <ska-de...@skarnet.org> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng