"Here's the problem: Some current solutions geared toward
making Linux more usable on very large systems exist, and they've
even been offered to the kernel development group. But they've been
rejected, mainly because they demand tradeoffs that would
hamper Linux performance on small systems. (A scheme that might
allocate a bunch of megabytes of RAM for a special caching
technique wouldn't run too well on a box that only has a couple of
megabytes of RAM, period.)"
"So, when code containing solutions to some big-iron problems
was offered to the kernel group by a well-known three-lettered
hardware vendor, it was rejected. Compounding the problem was that
some in the kernel group didn't even like said solution for large
systems, and other opinions held that SMP-type multiple-processor
systems were a poor answer to the issue of high performance in the
first place. Whether you can guess the three-lettered hardware
vendor or not doesn't matter, because the same problems apply to
all big iron vendors...."
"Last week I was presenting at a conference where I met up with
an executive of the previously mentioned three-lettered company,
who felt stuck between rocks and hard places. The company wanted to
get the most out of its hardware but also wanted to keep in the
good graces of the open source community. The company was concerned
about what to do with its big-iron code that had been rejected.
Most importantly, the company wanted to avoid the use of that awful
four-letter word beginning with "f":
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.