systemd's syslogd replacement supports JSON output

This is of course exactly the killer feature that would convert me into a true systemd believer. The only thing better would be to have an ASN.1 representation of the logs as the native format, for the sake of portability. After all, if you don't have tools to analyze your logs for you, you might as well not even have logs.

There some competing trends in the *nix world today.

On the one hand, there are some huge, monolithic packages like Xorg that have split in to many smaller, more independent packages.

On the other hand, we have something like systemd absorbing ever more functionality, becoming more monolithic with feature bloat.

I am personally more in favor of having many small, simple tools that each do one function well and can be easily integrated together, and understood independently of each other, rather than going the monolithic route.

To me, systemd is one gigantic step backwards from this vision, even if it has some (or even many) good ideas.

A quick look into systemd reveals that it's comprised of multiple components. For example the journal service is a separate daemon. What part of this does not align with your vision?

EDIT: looks like the "monolithic" myth has already been busted: http://0pointer.de/blog/projects/the-biggest-myths.html

I would say the distinction between systemd and older systems is that systemd follows the "better is better" mantra of design, while older systems follow the "worse is better" mantra of design. Older systems often feel like quick hacks. For example SysV init is a collection of init scripts. Yeah it is "simple" in that the init service itself is simple, but writing the scripts themselves is anything but simple, and they are brittle as well. How often have you seen init scripts failing during startup or boot? And why must you write daemon management code over and over again your init scripts? All this does is pushing complexity out of the init service and into the scripts. Systemd is taking complexity upon itself so that the scripts can be simple.

Which is easy for you to state, were it not for the fact that the "simple service" is broken in various ways.

Let's start with the implementation-specific brokenness. I configured a log host with rsyslog. Rsyslog's configuration format, as well as documentation, is completely abysmal. And once in a while, rsyslog would use 100% CPU for no reason. A quick strace reveals that it keeps reading or writing to a file descriptor, but getting EAGAIN as error. Looks like a bug to me. And oh yeah, there's a race condition in rsyslog with regard to privilege lowering, so that sometimes it would great directories owned as root, and then it would lower its privilege, and then it would be unable to write to its own created directory. Just great.

The above are all fixable. But what bothers me more is that syslog is entirely unauthenticated. Any process can write to syslog, claiming that it is any process. A malicious user can write a syslog entry saying that "init[1]: the system is unstable. please reboot now!". As an administrator, you will not be able to tell whether the message actually came from init (or PID 1) or not. A quick look at systemd's journal mechanism reveals systemd at least has thought about these problems: http://www.freedesktop.org/software/systemd/man/systemd.jour.... It would log the process's PID, UID, GID and more, and the sender is unable to fake that.

Lennart, please add the f*ng mail reader in there already and be finished with it.