True, useless might be a bit over the top.

It sort of okay when you only have one system that does binary logs, but what if you have 5 or 10, each with their own log format and little tool that I need to pipe the log file through?

The binary logs also assumes that you actually know where stuff is or that you're not going to look across multiple systems in one go. If you're large enough you'll have logstash/splunk or something similar where you have already de-binarized the log and this become less of an issue.

But for may of us doing a "grep <something> 2014-04-*.log" is something that's just natural and we come a bit hostile if you're trying to take that away.

That being said I think systemd might have a way of just giving you the log in plaintext.

Not all tools operate on stdin. For that matter, this doesn't fix the millions of people and organisations who will have custom tools and processes.

All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.

> Not all tools operate on stdin.

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:

  {
        "__CURSOR" : "s=56750fa36ad94eb99c00e7fd6854c400;i=2;b=2f533403d7a041e7a389e3a7090942de;m=172e6e4;t=4f7c809a2f61d;x=79a98b8a5116658a",
	"_SYSTEMD_CGROUP" : "/system/cron.service",
	"_SYSTEMD_UNIT" : "cron.service",
	"SYSLOG_FACILITY" : "10",
	"SYSLOG_IDENTIFIER" : "CRON",
	"_CMDLINE" : "/USR/SBIN/CRON",
	"MESSAGE" : "pam_unix(cron:session): session closed for user root",
	"SYSLOG_PID" : "2398",
	"_PID" : "2398",
	"_SOURCE_REALTIME_TIMESTAMP" : "1398345421294046"
  }

Pipe that into http://stedolan.github.io/jq/ and you could do things.

Seems like unnecessary bloat and decoding overhead. I can get all the same detail from a single line.

> All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.

Actually, they won't. Because journald has the relevant functionality built-in -- that is, it can automatically stream out the logs in any format you choose, including ones understood by rsyslogd, and if you really just don't like journald, you can just turn off it's storage and turn it into nothing but a shim.