Yeah, no. Maybe that worked in the 80s, back when hardware was weak, and an admin could keep an eye on everything by hand. I dealt with parsing log files more r

Yeah, no. Maybe that worked in the 80s, back when hardware was weak, and an admin could keep an eye on everything by hand. I dealt with parsing log files more recently than that, and it's a never-ending list of annoying bullshit to deal with: * Some stuff logs with syslog and some doesn't. * Formats vary, oh the fun of implementing the different variations. * You have to parse text dates into unix, when whatever wrote the file converted unix to text. It probably lacks milliseconds, which is all kinds of fun in a modern setting where there can easily be a hundred things happening during any second. * Various edge cases. Where exactly does every field in the log file end? Can there be a newline? (yes, guaranteed). Can there be random binary junk (yup, sometimes). * How do you keep track of where you stopped parsing? How do you deal with that the old log might have been removed and a new one with the same name now appeared? * Dealing with compression, log rotation, race conditions. It's simple on the surface. Actually writing a program that deals with all that stuff is bloody annoying, because none of it actually gets what you want done. You typically want to detect important events happening, or graphing something. Instead, 95% of the time goes on mind-numbing minutia dealing with parsing because the system was built for an admin using `tail` and `grep` in the 80s. It wasn't planned for a modern admin maintaining a few dozen computers each of which log multiple megabytes of stuff every hour. Never understood people who complain about journald, because this stuff was a pain in my butt a good decade before journald existed. I certainly don't have any fond memories from dealing with it.