On 12/06/2015 19:46, Steve Litt wrote:
> 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?

Short answer: yes. That's exactly the point of a distribution, as
Katola says.

A bit longer answer: it doesn't even have to be hard. You don't have
to rewrite anything - just patch; it shouldn't be too difficult to
edit out the parts calling sd_notify.
Even better, suggest alternative software that you don't have to
patch. cupsd and sshd have been infected by systemd? Well, maybe you
should inform the users, and provide similar functionality in a
systemd-free way. Isn't that the goal of Devuan? sshd servers are
not lacking. As for printing servers, I don't know, but I'd be surprised
if cupsd was the only possibility.

And if it actually is the only possibility, then we have a bigger
problem than just sd_notify: it means that monopolies exist in free
software - real, existing monopolies, albeit more inconspicuous than
systemd's obvious attempts at a monopoly - and it is taking away from
users' freedom. And that is what needs to be fought first and foremost.

I firmly believe that in 20ish years, we have lost most of the awareness
of what free software is and what it means. If we cannot actually dive
into the code and take out what we don't want, then it's de facto not
free software anymore, no matter the reason. systemd is proprietary
software despite its licensing because it's too complex to be tinkered
with at an individual level, it's controlled by a company, and it uses
embrace and extend methods to establish market domination. But I don't
think sshd and cupsd are there yet - they can still be worked with. Same
with most daemons that have already succumbed to the sirens of sd_notify.
And I certainly hope that those are few and far between.


> 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.

The issue is complex because it's both technical and ideological.

Stubbing the sd_notify client, i.e. writing a library that daemons can
link against, is easier because it doesn't depend on anyone else than
the person writing it - but it is ideologically worse because it gives
ground to systemd, and does nothing to incentivize daemon writers to
stop usingthe sd_notify API.

Encouraging daemon writers to use another API and providing a wrapper
to make daemons using the simpler API work with the sd_notify mechanism
is clearly the better ideological solution, and also technologically
preferable because more compatible with other notification frameworks;
but it's harder, because it requires communication with daemon authors,
and the systemd proponents have more communication power than we do
(read: $$$). But I think authors can be convinced if we show that our API
is simpler to use and will work under any framework, systemd included.

If there were a stub sd_notify, I'd rather have it output the info in
the simplest possible format so that it can then be used by *any*
notification reader, and so that it's actually easier for a daemon author
to output the notification directly than to call sd_notify(). I'm a bit
uncomfortable treading these grounds, because it's technical talk that
ultimately has a political goal, and I don't like to mix the two, but
when stubbing is involved it's unfortunately unavoidable.

--
Laurent