[ale] Maddog’s take on recent Red Hat source distribution changes

[Steve Litt]

Jon "maddog" Hall said on Sun, 20 Aug 2023 17:47:31 -0400

>I would also like to say something about the logs being in ASCII as
>they were in the early days of Unix.
>
>When I was at DEC we had a friend of mine put forth a proposal for
>binary log files instead of the ASCII files that were being generated.
>  His proposal was a mechanism that detected if there was any new
> information
>coming from the error routines.  If there was not he would simply
>increment the count of the error message and put a time stamp on it.
>This reduced the amount of data that was generated from the error
>routines.
>
>He then wrote an "error formatter" program which could take the errors
>being generated and reconstruct them into what would have been
>generated from the ASCII strings.  The program could also let you form
>windows of when you are interested in seeing the error messages
>formatted.
>
>The benefit of all this was that the straight ASCII error messages
>would often be generated so fast on the servers of that day (much less
>today) that they would fill up the file system and create even more
>problems (including lost error messages).

First, as long as text logs are an option, which I understand they are
with systemd, I have no problem with a binary log option.

I see the benefit of machine efficency, even with modern day muscular
equipment. I run OpenBox on a 12 thread 3.5Ghz processor with 48GB Ram
and a 1TB NVMe; a machine that could easily handle the worst that KDE
and Gnome could throw at it. 

Of course, there's a tradeoff. Text logs are easier to deal with after
the facts, binary logs I would imagine are more resource efficient. So
for my desktop computer text logs are the way to go. If I fielded a
server on a 10Gbit line that constantly served to 100,000 clients, I'd
strongly consider binary.

As long as binary logs are a systemd option, not requirement, and as
long as they remain that way, I have no problem with the binary log
option.

SteveT