> Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....). Technica

> Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....). Technically indeed. If you try to forcibly disable journald, it causes causes dependency failures that result in you dropping to an emergency prompt. Of course this doesn't stop Lennart Poettering from using the existence of separate but interdependent daemons as 'proof' that systemd isn't a monolithic ball of mud. > I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that should be done in such close connection with systemd. A better approach would be to make rsyslog more than just a syslog daemon and build up a new protocol and storage format with it, with the full intention of standardizing it. (the syslog protocol is a pain in the ass, particularly that hard limit on facility numbers... Fix that first, then roll from there. Make rsyslog treat syslog like Vim treats vi: capable of falling back to compat mode, but better by default.) Agreed. This is what Apple did with asl(3); it's a modern syslog replacement that happens to still support the syslog protocol and syslog(3) APIs. There's no reason a modern logging daemon can't be portable to other systems, too; it shouldn't be doing anything so crazy as to be impossible to run elsewhere, whereas since systemd is an intentionally non-portable kitchen sink, no other UNIX is going to run with journald.