As if the pro-systemd side was the only one with activist fans who don't understand the actual situation.
Oy... you still don't get it. For some reason those favoring systemd have been given a pass.
I guess it is because a few distros have used it and people who support systemd who are not listening far outnumber those who have opposed systemd and stated logical reasons or noted issues.
As a result, the burden of proof rests on anyone opposing the introduction of systemd.
Because the burden of proof rests on those opposing the introduction of systemd; it doesn't even matter if some are fanatical, because it has zero net affect.
The problem is the rational arguments showing that the status quo is better than systemd are just getting ignored and not being addressed.
ACID and that it'll be easily corrupted in a crash but never quite manage to explain how the plain text log doesn't have the same problem.
Plain text logs have risk of corruption as well, but unlike text-based logs, binary logs are fragile.
I would say it's true that the same can happen to both --- they both have risks of corruption, BUT the binary logs are much more likely to have debilitating corruption.
One byte out of place, and the entire file tends to become unusable, or systems that need to consume the logs break and can't read the rest of the logfile.
When a text-based log has a corruption issue; generally, it will mean a few lost log entries -- the write operations are fairly atomic. It doesn't matter that they aren't transactional, because text-based log storage is not as fragile as a binary file format that must be well-formed, or your log-reading tool goes KaBoomb.
With regards to logs; it only makes sense to refer to ACID compliance, when there is a relational transaction structure that must be preserved to recover the log entry. Generally with a text-based logfile, EVERYTHING that is relevant to the log entry goes to a single log line and gets written all at once, so this is really robust and hard to beat.