"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. I've included the patch in lieu of a diffstat since it's so small."

"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? Sure, current CPUs support 40 physical bits [1 TB] for now so it's all theoretical at this moment. My guess is that CPU makers will first extend the physical lines all the way up to 46-47 bits before they are willing to touch the logical model and extend the virtual space beyond 48 bits (47 bits of that available to kernel-space in practice - i.e. 128 TB). So eventually, in a few years, we'll feel some sort of crunch when the # of physical lines approaches the # of logical bits - just like when 32-bit felt a crunch when physical lines went to 31 and beyond."

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

"When you buy from Apple, you do not get what you paid for. Instead you get exactly what you got suckered into buying."

"I know user interfaces are annoying because you have to think about chips other than your own, but that's life. Other hardware vendors have to do it too. Letting each driver have a different user interface is /unfriendly/ to both and developers users. It's easiest for Intel kernel developers, but that is not our target audience :)"

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

"My concern is that if there's something technological in the 'bleeding tree' that is so valuable to users that distros feel that it's ready 'enough' and that they need to pick it up for their users, we have a flaw in our processes in moving too slowly for users."

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