Note that the above referenced "retroactively aborted" rant was not directed at Kay. It was instead directed at some unnamed developer who had set up kernel log handling in Debian with a "dd bs=1 if=/proc/kmesg of=/var/run/klogd/kmsg", which was copying the kernel log one byte at a time to a FIFO (presumably because something reading the log was better able to deal with a FIFO than whatever strange semantics /proc/kmesg has).
Kay had then made /proc/kmesg semantics somewhat weirder, by not blocking but instead returning 0 when the available buffer wasn't big enough to read into; normally, returning 0 to a read indicates that the file has been closed, while if there simply isn't data available yet the call is supposed to block until it is.
So Linus was asking Kay to fix the issue, but also making an aside about how stupid it is to try to read one byte at a time from the kernel.
Now, there was the other incident you mention, in which Linus did get upset enough at Kay for not responding very well to a big report, but this one was not that; he was merely asking Kay to fix a bug, and cursing out some unnamed other developer for having done something as dumb as byte-at-a-time reads.
Not really defending either side here. I find Linus excessively caustic on these issues, and Kay a bit too unwilling to admit when he needs to fix a bug. I feel like Lennart gets way more hate than he deserves; he can be a bit difficult to work with sometimes, but it's crazy how some people think that he's single handedly out to destroy the Linux ecosystem.
I run a lot of software originally written by Lennart (Avahi, Pulse, systemd, heck, I recently even started using ifplugd on systems that still needed to use ifupdown but we wanted to respond properly to network cables being connected and disconnected), and find that it tends to be higher quality, more well designed, and more stable than a lot of the other code in the stack. Due to the fact that much of it changes the "traditional" way that systems worked to a very different but friendlier way, there tend to be a few integration issues along the way for early adopters; if you don't want such integration issues, it's probably best to use a stable distro like RHEL/CentOS or Debian Stable, rather than a quickly updating distro that ships code that's not yet ready for primetime like Ubuntu, Fedora, or Debian testing/unstable.