Interesting.
So, it could be that a subset of the Grumpy-The-FSDb-Can't-Do-Anything-Right could be suffering from the effects of a malfunctioning computer. bhakan had issues with nags and FSD strikes that seem, now, to have cleared. And, while I've had the occasional nag, it was nothing like what he was complaining about.
Note that whatever self-diagnostics run on the computer that was replaced, it wasn't good enough to catch a bad comp. And that could imply that there might be other malfunctioning computers that have different things wrong in there. Which might explain, well, some (but I'm sure, not all) of the complaints around here.
Hmm.. I'm a getting to be retired these days, but, when I was designing hardware for telecom, for that hardware we had factory diagnostics, out of service diagnostics, in-service diagnostics, and background diagnostics. The general idea was kind of like that bit about a tree falling in the woods: If there was a failure, one should be able to catch it.
As time went on I've run into systems where, well, there might be an error bit somewhere that wasn't monitored by software; in fact, given the push to get hardware out the door, there might be a lot of those error bits. Usually the logic is that if something does go bad on Device A, it would very likely make Device B fail in an obvious way. Hence, if Device B failures are what you monitor, then, in principle, one doesn't have to monitor Device A. Which is nice when it works and saves development time. But only works well when it's failures that one knows about. (As compared to the unexpected ones that one doesn't.)
And I don't want to get into the area where hardware designers don't even put diagnostic hardware into the design. Silent failures, anybody?
As if we don't have enough trouble getting things to work right. Hmm...