Mixed feelings

Firstly, I'm not sure I share the author's conviction that syslog is profoundly broken. Drastically changing core tools in a system administrator's toolkit is something that needs to happen from time to time, but the very change itself will have a negative impact, as well as numerous unforseen consequences, and the justification will have to be a compelling one. The article mentions message source validation, log rotation, and uneven disk usage due to chronological log rotation as drawbacks of the current rsyslogd system. None of these things require a wholesale replacement of the tool or even its output format. The cryptographic hash chain also seems to be a solution in search of a problem; the primary problem with the kernel.org compromise AFAIK was overly permissive access policies, and log files are only a small part of the post-mortem forensics. I'm far too young to be against all changes to the world for any reason, but the issues presented in the proposal seem to be tangential to the changes in journald itself.

Secondly, the rigid bidirectional coupling between systemd and journald smells very bad to me. I like systemd because it is actually good at decoupling things and being filesystem-centric, two traits that are held up as integral parts of good UNIX design. Systemd's site-specific overrides that can exist independently of unit files in software distributions, configuration of system policy by symlink manipulation, and a restricted declarative unit language with easily-modelled semantics are points in its favour. However, journald is a step backwards; this bidirectional coupling just creates a monolithic entity with questionable design, and this decision does not come with any justification. Conceptually a logging service ought to exist independently of a service manager, though the service manager could be highly dependent on the unique feature set of a logging system. Similarly, the telescreen-like inability to turn it off instead of merely turning it down is just downright bizarre, and I can't think of any good reason for that. Monitoring systems should be passive; I should be able to remove journald from my system entirely and suffer no loss of functionality. This is a key design principle of just about every other logging system out there.

Unique and globally-namespaced identifiers for different classes of events together with machine-readable key-value tags are an excellent idea, and definitely serve as a good justification for making this change, but I'm not sure about using UUIDs. The use of Java-style reversed domain name prefixes has compelling advantages over UUIDs, because 8fa69db4-0a89-4c7b-b715-7e7ea93233c7 doesn't exactly roll off the tongue, nor is it at all memorable. On the other hand, I could potentially search for "journald bad sector event" and discover that the tag for this message is "org.kernel.blockdev.media.bad_sector". I can then search for that string online and find far more posts, log fragments, cross-references, and diagnostic scripts referencing that particular kind of event than I would find just searching for a UUID, since people are far more likely to remember the text string and cite it in discussion groups than they are to post a UUID. The only disadvantage to this style of identifier given in the article is that it is inefficient and that namespaces would have to be explicitly managed. This focus on execution efficiency and namespace collisions comes from a programmer's perspective, not from a system administrator's perspective, and far more system administrators will have to deal with this system than programmers will have to maintain journald's implementation. That, and, there is of course the old quote about sins being committed in the name of efficiency.

Finally, I wish the authors would choose a different name than "The journal". That word is already taken in the sysadmin's lexicon: a journal is a filesystem data structure, for heaven's sake. Then again, databases refer to journals as logs, so I suppose I can't get too upset about systemd referring to logs as journals :)

(FWIW I'm a programmer, not an administrator as such)