My point was simply to stress, that what the early Unix developers did was a reflection of the challenges they faced at the time, and that the lessons they learned reflects that. There are no dogmatic and universal Unix rules with a permanent truth value forever and in all ways of doing computing.
Nobody said there were, but you were completely misguided. Piping is a key feature of Unix, and nobody would suggest removing it today. The key principles of Unix are not "to be obeyed" simply because they are rules that you are meant to follow. They are principles that emerged from development (like piping) which became a "way" that people follow because they make sense.
No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless.
Of course not. Just because a daemon died before finishing its log entry doesn't mean the log file can't be read. journalctl is quite good at dealing with such corruptions.
If moving the goalposts is the best that you can accomplish, then surely we cannot progress this conversation past this point. There are many things which can happen to a log file besides truncation.
Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read.
Not a problem; all the standard Linux text tools like "grep" and "tee" work great together with journalctl through the basic concept of piping.
They don't work without journalctl. And this is relevant because text logging (which does work without journalctl) is a second-class citizen to the binary logging. This is the part of the binary logging which is completely unacceptable. If only one of the logs is going to be accurate, it must be the log which I can read without special tools. Indeed, with a filesystem debugger or even a filesystem editor, if necessary.
It is a very Unix way of dealing with such "problems".
False. You only say that because you do not understand the Unix Way, which includes preference for flat and human-readable files. You are praising one particular tree while cutting down the forest.
Not having the right tools in the box is simply a shameful thing for a paid SysAdmin.
In the real world, where things sometimes do not go according to plan, it does not make sense to tie myself to proprietary tools. This point has been proven time and again, again, in the real world. Your coulda woulda shoulda nonsense is just that; journald coulda woulda shoulda made text logging as important as binary logging, and then the chief objection to it would not even exist. But arrogance has led its development otherwise. Presumably this will be fixed and eventually, with some snarky bullshit comments about how it's for the fogeys thrown in as a means of avoiding any personal responsibility for the bad decision in the first place.
It is so trivial to read and analyze journal log files on other computers or through a boot media.
I find your lack of imagination typical, but disturbing. It is, of course, the mindset which led to systemd, so I am anything but surprised to see it here.