Thinking about the implications of your program being successful
Recently, some of our Red Hat Enterprise Linux systems started mailing us a message from cron once an hour:
mcelog: warning: record length longer than expected. Consider update.
There are two things wrong with this message. The first is a RHEL
bug; Red Hat should have made sure that this cron job didn't bombard
sysadmins with unimportant messages by, for example, redirecting
standard error to
(This is sadly a general problem that RHEL has; there seem to be any number of cron entries that will spray you with email if you let them, and some of them are installed by default.)
The second, though, is that the author of
mcelog hasn't thought
through the implications of it being a successful Linux program, which
it clearly is. In Linux, your program is a success if it's important
enough to be packaged by distributions and even more of a success if
they start installing it by default, as has happened with
on at least RHEL.
When your program is packaged and installed by Linux distributions, ie when it is a success, it is essentially pointless to suggest to people that they install an updated version by hand; it just doesn't happen. Sysadmins won't don't do that unless we absolutely have to, and most other users are just going to look at you blankly at the very suggestion. Once a program comes from a distribution package, that's pretty much it; either the distribution updates it or no one does.
mcelog became a success, this message was a perfectly sensible
suggestion; people were building their own copy anyways, so telling
them to update it was fine. But the more successful
the more that people got it from their distribution instead of by
building it themselves, the more the suggestion turned into something
that almost no one was going to follow and thus became useless noise.
(In practice the net effect of this message was to get me to run '
-e mcelog' on the affected machines.)