"The _real_ bug is clearly in the hardware design that allows you to brick those things without apparently even having a lock bit. I'm hoping Intel doesn't treat this as just a software bug. Some hw designer should be thinking hard about which orifice they put their head up in."

"The C standard will eventually support concurrency (they are working on it), and it will almost inevitably be a horrible pile of stinking sh*t, and we'll continue to use the gcc inline asms instead, but then the gcc people will ignore our complaints when they break the compiler, and say that we should use the stinking pile-of-sh*t ones that are built in.

"The delta cache was really a huge hack that just turned out rather successful. It's been hacked on further since (to do some half-way reasonable replacement with _another_ hack by adding an LRU on top of it), but it really is very hacky indeed."

"The default value should be 'off', unless it's _needed_ by people. Have you guys looked at the size of the kernel lately? Bloat is bloat. Just because it's conditional is not an excuse."

"If a reporter doesn't respond to say 'it's still open', it needs to be closed. It doesn't matter one whit whether there has been developer action on it or not. We cannot keep old reports open - it's a total waste for developers to even _look_ at anything that is more than roughly a month old and hasn't been verified to be still be an issue."

"Looking at the code it's apparently because I'm not an optimistic enough dad. But hey, if you had three pre-teenage girls, you might not be all that optimistic either."

"Excuse me for not exactly being a huge fan of 'security lists' and best practices. They seem to be _entirely_ based on PR and how much you can talk up a specific bug. No thank you."

"I'd have assumed that 64-bit is starting to be the norm for people who live on the edge, but perhaps I'm just out of touch?"

"Here's a hint: next time I claim some code of yours is buggy, either just acknowledge the bug, or stay silent. You'll look smarter that way."

"I don't care what anybody else says - x86 is *so* totally dominant, that other architectures have to live with the fact that 99.9% of all drivers are written for and tested on x86. As a result, anything else is 'theory'. Are some drivers good and are careful? Yes. Are most?

"This code doesn't get merged. It doesn't get merged before 2.6.26, and it doesn't get merged _after_ either. Rewrite the code, or not. I don't care. I'll very happily not merge crap for the rest of my life."

"You really need to realize that reality is messy, and things cannot be pefect. You also need to realize and *understand* that aiming for 'good' is actually much BETTER than trying to aim for 'perfect'. Perfect is the enemy of good."

"We've always had some pending/unresolved issues, and I think that as our tracking gets better, there's likely to be more of them. A number of bug-reports are either hard to reproduce (often including from the reporter) or end up without updates etc.

"I realize that getting the POWER people to accept that they have been total morons when it comes to VM for the last three decades is hard, but somebody in the POWER hardware design camp should (a) be told and (b) be really ashamed of themselves."

"The question on the table is [...] whether we should let ndiswrapper continue using GPLONLY symbols. Quite frankly, my position on this has always been that the GPLv2 explicitly covers _derived_ works only, and that very obviously a Windows driver isn't a derived work of the kernel.