Indeed. I use "nohup command >output &" (you need the &) when starting a long-running job on a remote system, so that if the ssh connection falls down, "command" will continue to run, and I can consult "output" when I reconnect, perhaps much later.
I do want syslog, but in a separate SRFI.
Lassi:
They should just write all their logs to stdout/stderr like normal programs,
Just logging to stdout/stderr is really not adequate. Syslog lets the application specify an arbitrary number of discrete log streams for different purposes, which can be shared with other copies of the application or indeed completely different applications. Furthermore, the application need not be a daemon: it can be a batch process or an ordinary user program being debugged.
In addition, a severity level (emergency, alert, critical error, error, warning, notification, information, or debugging information) is associated with each message sent. The stream ID and severity, along with the text, are sent by a standard wire protocol to a syslog server (there are a large number of standards-conformant syslog servers). Such servers can be anything from dumb file writers to multiplexers similar to daemontools, but with the above information available to assist selective logging, ignoring, text messaging, or what not.
It's this sort of thing that makes me and others dislike djb's software: he thinks he can reinvent the wheel. Sometimes he can; sometimes his wheel is hexagonal.