The problem with putting all your syslogs on a remote system is that it can eat quite a bit of bandwidth. I honestly haven't seen any systems actually configured for remote syslog in my time in the industry. In contrast, sending a single hash to a central single-purpose server every hour doesn't raise any bandwidth issues.
This whole project was motivated by the administrators' inability to trust the kernel.org syslogs after the breakin. It's always a good sign when a project solves a real problem that some smart people encountered.
> Haven't we seen this story enough times to see the pattern? The tool will
> be minimal, just for quick use by UNIX diehards to shut them up, while all
> 'serious' use will be expected to be through the API/library.
I agree that there is a lot of DBUS-itis and shared-library-itis out there, especially from the GNOME devs. (The GNOME devs have done a lot of good work as well, but I have to call it like I see it.) But I don't think this falls into that category.
As long as 'logger' continues to work, and there is some way to cat the syslog to a file, it will be as easy to use syslog on the command line as it ever was. I mean, syslogd has been a daemon and syslog(2) has been an API since the seventies; you can hardly complain that Lennart is adding yet more daemons and APIs to the system. If you add a FUSE interface that exposes a writable file named /var/log/syslog that has all the log entries, it's as scriptable as it ever was.