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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
