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

"I just imported ix(4), a driver for the Intel 82598EB 10 Gigabit Ethernet adapters. It is based on Intel's ixgbe FreeBSD driver, with many local changes for OpenBSD.

"The driver is fully-operational and survived some long-time tests, had to work on borrowed hardware from another company since Intel didn't provide us any cards. It is currently not sure how to maintain the driver in the future without having cards in the project. John Ronciak from Intel told me told me that they don't have more cards to give away. It is purely a business case issue; a lot of customer have asked for FreeBSD, they got two cards, but nobody asked for an OpenBSD driver. He told me that they're doing the right for their customers. But of course I could still buy them on the open market."

"This is a case where you really should be scared, so FUD is completely appropriate."

"This is a bugfixed version of 2.6.26-rc5-mm2, which was a bugfixed version of 2.6.26-rc5-mm1. None of the git trees were repulled for -mm3 (and nor were they repulled for -mm2). The aim here is to get all the stupid bugs out of the way so that some serious MM testing can be performed. Please perform some serious MM testing."

"Development is really fast right now, because of the hackathon in Edmonton. We are testing as much as we can before we commit, but as always during these hackathon processes we really depend on our user community -- to track our changes and help spot the occasional bug we accidentally introduce. We are developing really fast and hard; please help us by testing really fast and hard too."

"I don't think I do want to have my own series of patches, because TuxOnIce doesn't remove or rework swsusp or uswsusp, but sits along side them. I'm not trying to mutate swsusp into TuxOnIce, because that would require a complete rework of swsusp from the ground up (TuxOnIce does everything but the atomic copy/restore and associated prep/cleanup differently)."

"That's quite buggy and would have generated so many runtime warnings in a 'developer' setup (rofl) that I look at Documentation/SubmitChecklist and just weep."