So pipe it to a file and operate on that. Or give the broken tool /dev/stdin as its filename. Or give it a fifo as a filename and "journalctl | /path/to/fifo.
> All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.
For those who insist on that, yes. Most of them will presumably have logrotate set up anyway, so it's hardly more complexity. Or you can run a syslog, and trivially set up systemd to forward the log entries to that.
Meanwhile the rest of us will enjoy the ability to do things like specify a start and end time with command line switches when trying to find stuff in the log, filter by priority, filter by user, filter by pid. seeing only data since last boot, get the journal as JSON instead of having to rely on brittle text parsing of entries that contains less information.
Regarding the last point, here's an example of an entry from journalctl -o json-pretty:
So pipe it to a file and operate on that. Or give the broken tool /dev/stdin as its filename. Or give it a fifo as a filename and "journalctl | /path/to/fifo.
> All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.
For those who insist on that, yes. Most of them will presumably have logrotate set up anyway, so it's hardly more complexity. Or you can run a syslog, and trivially set up systemd to forward the log entries to that.
Meanwhile the rest of us will enjoy the ability to do things like specify a start and end time with command line switches when trying to find stuff in the log, filter by priority, filter by user, filter by pid. seeing only data since last boot, get the journal as JSON instead of having to rely on brittle text parsing of entries that contains less information.
Regarding the last point, here's an example of an entry from journalctl -o json-pretty: