Quoting mett (mett@???):

> by the way, what do u think about
> what is written on that page regarding
> logging?
>
> http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html
>
> I was thinking if there is a better
> way of logging, might be worth to try it.

You asked the above of Tom <wirelessduck@???>, not me, but I'll
take a swing at it, anyway.

1. I respect author Jonathan de Boyne Pollard, quite a bit. He's
always learned, but also cranky and sometimes eccentric: I don't
mean 'eccentric' as derogation, but sometimes I have doubts about his
sense of perspective.

2. The page's comments about 'syslog()" are probably (my surmise)
directed specifically at the primordial Syslog implementation that
Linux inherited from BSD, e.g., his repeated complaint that syslog()
'UDP for its remote-logging transport'. That was true _early_ in the
history of Syslog, but was later remedied, and that limitation was never
true of the rsyslog fork.

3. Here we get to the perspective problem: He doesn't like the fact
that 'syslog()' first mixes incoming log streams and then follows
rulesets to separate them back out again, calling that a 'waste of time
and effort'. (This trait is also shared by Syslog's main successors,
rsyslog and syslog-ng.) In part to avoid that 'waste', he urges that
processes just log to stderr -- which by implication would then need to
be picked up by something. He has in mind Daniel J. Bernstein's
daemontools (which he approves of, generally) or equivalent _or_ some
other receiver. (For the most part, he's pushing daemontools.)

Jonathan's entitled to his opinion, of course, but some of us actually
_like_ the facilities that Syslog-derived logging daemons provide, and
don't consider their mixing-then-unmixing oddity all that wasteful.
It might oo _might not_ be the ideal design if one were starting from
scratch in 2018 to design logging infrastructure, but I for one am
disinclined to throw away the entire well-developed administrative
scheme just because it _might_ have been done differently and the
results _might_ have been better.

That's not to say I'd refuse somthing better than rsyslog (or
syslog-ng_, just that it'd have to be _very significantly_ better before
I'd bother trying it. (Your mileage may differ.{tm})