>> Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job. > Unless those sys

>> Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job. > Unless those system specific things are systemd specific things, then all people do is complain. According to you. Although, again, I continue to assert that most people understand that libc is the correct place for this. >A reply to one of my other comments: >> Systemd is not a platform. And not every Linux runs systemd. >Another reply: >> Didn't know linux also means systemd. > You're not wrong, updating daemon WOULD make perfect sense and solve this problem in a single place. People would rather argue and fight than solve real problems though. Again, libc is not a homogenous library. glibc need not be implemented the same on all linux systems. Implementing daemon(3) semantics could be done either via systemd or not, as makes most sense on a given linux platform. glibc already does this for other things. The criticism that this makes or assumes all of linux == systemd doesn't apply. Either way, we'll never know, because the systemd devs did not even bother to try being good actors, here. They're ignoring libc entirely in favor of pushing systemd dependencies up the stack. edit: I want to take this a little bit farther: The idea that systemd devs have to push a bad engineering decision (to tightly couple low-level platform details) onto upstream code with no abstractions, which they are being heavily criticized for, was somehow necessary to avoid misguided criticism they might have received for trying to do this the right way, is simply a wrong argument that doesn't make sense.