"This wants doing with a hash not a prayer that '32 slots is enough'."

"My suggestion to you would be to find the comments that were made by the reviewers way back when, and make sure those comments have been addressed. Then, re-request a code review, and promise that you won't abuse, and insult the integrity and impugn the motivations of the reviewers..."

"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."

"Geeze you're picky! If everyone was like you we wouldn't need that nice oops-printing code."

"Wow. 6924d1ab8b7bbe5ab416713f5701b3316b2df85b is a work of art. Is it ascii-art tetris? a magic eye picture? you decide! It looks even more spectacular in gitk."

"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."

"I wasn't even trying to invent a new protocol or anything, I was simply fixing the haphazard mathematical algorithms the clearly non-mathematically-oriented programmers built into those crufty clients."

"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."

"This is Openmoko. If you /don't/ open your Neo, you should probably have your warranty voided ;-)"

"One *major* problem with virtualizers is that they uniformly use an existing CPU identifier, even though they might have their own sets of bugs. This makes it much harder to work around bugs in them."

"I'll stop making predictions about whether this is the last pull request for 2.6.26 or not, but it is an important one. It turns out that we've had a trivial DoS on machines containing PCI devices with bad VPDs. We're entertaining a few options for a scalable, long term fix, but in the meantime, restricting access to the sysfs VPD file seems prudent.

"This reduces native kernel max memory support from around 127 TB to around 120 TB. We also limit the Xen hypervisor to ~7 TB of physical memory - is that wise in the long run?

"These closed lists are a pain. Lots of subprojects have moved their lists to vger.kernel.org in recent months. It gets close to zero spam. Hint."

"The great majority of OpenBSD developers are from outside the United States, and I would guess that most of us prefer not to visit the US now thanks to the murderous foreign policy, authoritarian domestic surveillance, and invasive border control. You'll find few of us there. Personally I've been refusing invitations to go to, or even transit through the United States for about 6 years."

"This statement is not 'preventing' anything, it is merely stating the fact that a very large number of Linux kernel developers feel that closed source Linux kernel modules are harmful for users, companies, and the Linux kernel community overall."