Who's Afraid of Systemd?
Now that systemd is uneventfully running the latest releases of major distributions like Debian, Fedora, and Ubuntu, you might imagine that opposition to it is melting away -- but you'd be wrong. Instead, the rumors are as common as ever. Devuan, the anti-systemd fork of Debian, is still trudging towards a release while making the same arguments as ever. Devuan's home page asks: Have you tried to opt-out of the systemd change in Debian and stay with sysvinit? You will quickly notice that "Debian offers no choice." Yet a search quickly unearths instructions for making an install image without systemd and for removing systemd from your system.
Nor does the claim that systemd violates the Unix design principles stand up under scrutiny. Systemd is actually a general name for a series of related, similarly structured commands. From this perspective, systemd conforms to the principle of one program doing a single function in much the same way as the Linux kernel or a command line shell does. It is a suite of programs, not a single monolithic one. Systemd may not be ideal, but systems continue to boot and function the way they are supposed to.
In fact, not only are the most common anti-systemd arguments easily discounted, but they are surrounded by a vagueness that raises suspicions. Wild claims are made without any attempt at substantiation. The result is an air of secrecy and danger that, however appealing and reminiscent of freedom-fighting that it might be, does nothing to justify the anti-systemd rhetoric or make it plausible. Devuan's mailing list mostly shows the same dozen or so posters, and has raised only 7934 Euros. Supporters sound as though they are doing more fear-mongering than constructive effort.
Nor does the claim that systemd violates the Unix design principles stand up under scrutiny. Systemd is actually a general name for a series of related, similarly structured commands. From this perspective, systemd conforms to the principle of one program doing a single function in much the same way as the Linux kernel or a command line shell does. It is a suite of programs, not a single monolithic one. Systemd may not be ideal, but systems continue to boot and function the way they are supposed to.
In fact, not only are the most common anti-systemd arguments easily discounted, but they are surrounded by a vagueness that raises suspicions. Wild claims are made without any attempt at substantiation. The result is an air of secrecy and danger that, however appealing and reminiscent of freedom-fighting that it might be, does nothing to justify the anti-systemd rhetoric or make it plausible. Devuan's mailing list mostly shows the same dozen or so posters, and has raised only 7934 Euros. Supporters sound as though they are doing more fear-mongering than constructive effort.
The problem I have with journald is that it makes handling the logs more complicated, without providing any benefit compared with alternative solutions. The alleged benefits (e.g. binary logs) are already implemented in all other systems, and those implementations are more thought-through than those of the SystemD-team, as each development team can focus on polishing a single tool rather than a beowulf of programs (this is the Unix-philosophy in a nutshell). Storing logs as binary files, for example, is either done using logrotate (for archiving in compressed files) or by forwarding selected parts of the syslog stream to a database (for future analysis).
Therefore, the only way to make useful log analysis with JournalD is to configure it to forward everything to regular syslog, and add your regular analysis tools to the syslog stream. This means that in a system with both log analysis and SystemD, journald is an extra step in your pipeline which doesn't contribute with any functionality. In addition, this means that all logs (which are generated as text) must be converted into binary only to be re-converted back to text before being forwarded to analysis tools.
Now you're probably saying that tools can read the binary files straight-up in order to make things more efficient. This is true, but the problem is that there are programs which log to their own logfiles, rather than passing their logs via the syslog functionality. This means that the log analysis solution must still be capable of handling text files. This means that you must have support for both the binary format and the text format, rather than (as with other solutions) just handling text files. This (once again) increases complexity without adding any value, which is bad.
Tl;dr: Fuck Journald.