For a smart guy, when he's wrong he is completely wrong. And any good work he might have done is wiped out by his arrogance. Not to mention he prevented bugs from being fixed.
But here is my favourite bug that cannot be fixed:
Basically, the number of steps on Gnome volume control can't be configurable because apparently there are no situations you would ever want to do that. Except for hardware setups that don't report back volume information...
The worst part about people who respond to bug reports in that way is that for most people, it just intimidates you into thinking you are wrong, and stupid for even asking. It's like an amature trying to beat a lawyer in court, you can't win, even if you're right.
Although in slightly different vein and, strictly speaking, not reported to a public bug tracker, this AMD CPU bug report by Matt Dillon is probably my favourite (link: https://www.dragonflybsd.org/mailarchive/kernel/2012-03/msg0...). Tracking the intermittent problem to the lowest level and blaming the CPU and not the numerous layers above it surely takes guts.
How do you even fix that? Do you have to update every compiler so it checks the generate machine code for that problematic sequence and insert some nop's, or is there a way to update the cpu itself?
You can say what you want about Drepper, but as far as scanf() and siblings are concerned, there is only one one safe way of using them: Not using them. Better write comprehensible reliable code to implement input scanning.
For a smart guy, when he's wrong he is completely wrong. And any good work he might have done is wiped out by his arrogance. Not to mention he prevented bugs from being fixed.
But here is my favourite bug that cannot be fixed:
https://bugzilla.gnome.org/show_bug.cgi?id=650371
Basically, the number of steps on Gnome volume control can't be configurable because apparently there are no situations you would ever want to do that. Except for hardware setups that don't report back volume information...