I think the argument is really about transferablilty of skills. I already know how to manipulate compressed files because I have to do that in other places. And once you realize logs are just text files, I can immediately transfer all my skills of dealing with text files to dealing with logs.

But now I have to learn another set of tools (or at least another command to convert it to text files). It's not really a huge issue (I'm not really a systemd hater), but there can be a bit of dread when all the tools move off of standard formats, like simple text files, to custom formats, requiring you to learn idiosyncrasies of lots of different packages.

(And the reverse is true. Knowing how to use journalctl only helps me with systemd, and nowhere else. It's a piece of knowledge helpful in only one area that I cannot transfer anywhere else)

I think this is exactly it. Journalctl doesn't resemble any tools I already know, so I have to look up how to use it each time. Binary logs aren't the problem; we have had those for ages (e.g lastlog). I just wish journalctl were a little more familiar.

> Journalctl doesn't resemble any tools I already know

What about "tail"?

I think you can pump all the journal log files to a text file and then open them in emacs and start writing Python to analyze ;)

It's also just a really good tool for reading logs. Sure, it's always possible to cobble something together that merges a bunch of text logs and orders entries by date, but with journalctl that's just what it does and it's as simple as `journalctl -u spam -u eggs -u spam`.

journactl makes it _possible_ to read the log TFTFY.

> I know that it can be achieved without binary logs, but does any popular distribution implement compression out of the box?

Are you saying that since distros don't optimally configure a program out of the box, we should scrap and replace the whole program instead of just fixing its default configuration?

> we should scrap and replace the whole program instead of just fixing its default configuration?

Loads of distributions assisted that upstream works out of the box with systemd. That way the work is shared across distributions. Not sure why you make such a strange suggestion. Loads of work has been saved thanks to systemd. So much more is shared across distributions it's kind of crazy to look back.

I was talking about rsyslog there, not systemd.

> I was talking about rsyslog there, not systemd.

It's not at all clear what you're talking about, honestly. First you talk about distributions, then a vague "we", then some weird "scrap and replace" nonsense. No idea who you mean with a sentence such as "we scrap and replace rsyslog". It really makes no sense, if there's a developer that works on rsyslog the work will continue. Distributions might change a default, but it didn't seem to be about distributions.

To make things a bit clearer I talked about all the benefits of having systemd across distributions, plus how the work is shared. This because you seemed to not understand the benefits that systemd has for distributions, in response to the "since distros don't optimally configure a program out of the box". Again, with systemd work it often allowed things to be done upstream. Configuring things in a distribution is a waste of time, previously distributions often wrote their own init scripts.

One person specifically mentions that it's nice when stuff is good by default. Complaining that it's some fault of the distribution completely misses the point: systemd allows stuff to be shared across distributions! No need to complain that either the default wasn't ok, the init script had a bug, etc. It's shared by default. Similarly, once a mistake is found, the bugfix can be made in one place.

That's the nice bit. Your weird comment isn't clear at all, plus completely misses what's nice about systemd for distributions.