To expand a bit on what I wrote earlier - now it's finally condensed into something resembling a coherent thought.
Suppose, with SystemD running they decided to break normal syslog calls. Ie, they made it so that a program could not call syslog, but instead had to use a SystemD call. Given the way they are prepared to ride roughshod over anything that's in the way, it's not inconceivable that they'd try. As a developer, you now have to sprinkle your code (or add a routine) to wrap every logging call with a "if systemd then ... else syslog" block. Devs might start moaning a bit about that, so then the next logical step is to add to libsystemd all the code needed to be able to log on non-systemd systems - so an application only needs to use the systemd logging call. It might start off as just a simple "if systemd then ... else syslog" routine, but then they can change it to just incorporate the logging from systemd altogether. So now there's a bit of systemd, the much reviled logging system, that's now infiltrated the system. OK, it's a bit made up, and I don't think even Poettering cold get away with deprecating the existing syslog call - force EVERY binary to change to not use syslog ? But it's an example of the process I could see them being happy to use to infiltrate their code onto systems, only "to be helpful" of course. I'm sure others could come up with more likely functions they might have a go at. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
