That newfangled Journal thing - some thinking required

Yeah, except sometimes it's like poo-pooing people who try to reinvent bicycle wheels. Or people who try to put a CVT on a bicycle, or eliptical gear-wheels. None of them are better at all. In fact the bicycle wheel is one of the strongest per weight human structures ever designed. And it's cheap and easy to fix! But yet some people keep trying to add on carbon struts and such and sell it as better...

In this case, using a structured format means creating code that knows about the structured format. Now you've either got to do something gross like add all the journald interfaces to the kernel, or you have to do something else gross like add a big library between the emitting code and the fwrite() call.

You want to get the logged data out of the process space immediately, and the reason you want to do that is that in the crash scenario, you want to know what was happening at the time of the crash, not 2 seconds earlier when the buffering got last pushed.

Meanwhile, you want other systems to be able to tell what's logged, so you want to be able to watch the datastream as it's landing on disk. With a binary format all of this gets fairly complicated. Everyone has to link in this clunky library, or (worse) go through another daemon so that you have another place to lose buffers when the expected failure happens, to handle which is the first driver for adding logging.

So you have to have a clunky library and it has to be race condition free with its binary format, and it has to be carefully vetted to handle all unexpected binary structures correctly, or else tail -f becomes a security attack surface -- well it does regardless but at least if you carefully vet it the probability of a problem is decreased.

And the benefit of all of this is.. what exactly?