This can be kind of read as the “anti-plan9” philosophy: rather than moving away from task-specific syscalls towards using general filesystem interfaces for everything, sendsyslog(2) makes the opposite move, taking something that was once done with general-purpose interfaces and making a task-specific interface for it.
I generally use the daemontools multilog solution anyways, log to stdout (which you should probably have open) then let another program handle all the loggy things. I have found syslog so fundamentally broken it always causes more problems than its worth. Perhaps that is the rules changing Theo is referring to? People wanting to use syslog despite it being complete crap?
This can be kind of read as the “anti-plan9” philosophy: rather than moving away from task-specific syscalls towards using general filesystem interfaces for everything, sendsyslog(2) makes the opposite move, taking something that was once done with general-purpose interfaces and making a task-specific interface for it.
I generally use the daemontools multilog solution anyways, log to stdout (which you should probably have open) then let another program handle all the loggy things. I have found syslog so fundamentally broken it always causes more problems than its worth. Perhaps that is the rules changing Theo is referring to? People wanting to use syslog despite it being complete crap?