This page is using the term "multitouch" a full year earlier. And even if Apple were the first to use the term, they didn't trademark it before it became a more generic term, used on synaptics touchpads as mentioned.

It's possible they went with 2.6.32 because they hope it will be ABI compatible with the RHEL 6 kernel.

Full Disclosure: I work for Red Hat, but these opinions are my own and not representative of RHT.

The Kernel is the only thing in there that ISN'T from RedHat

This is wildly misleading. Almost everything Red Hat ships in Enterprise Linux is not from Red Hat. Projects like GCC, RPM package manager, Gnome, Glibc, KDE are all too big for Red Hat to develop on its own. The only things I can think of that are completely from Red Hat are layered products like Directory Server or projects where Red Hat has maintainership and majority contributions, like NetworkManager.

Having said that, I can't think of a kernel contribution report in recent years where Red Hat was not #1.

Apparently to call it a "new" kernel TFA feels they should have started entirely from scratch.

To call it a "new" kernel it has to be something less than nine months old.

"Fine tuning" could be anything from tweaking some compiler settings to actually patching things in the kernel.

They patched quite a few things, but at the same time thought it important to be as close to mainline as possible. Here's the lowdown from Chris Mason over at LWN:

Hi everyone,

One of the goals of this kernel was to stay as close to 2.6.32.stable as we could. The sources are here in git, they won't be rebased:

http://oss.oracle.com/git/?p=linux-2.6-unbreakable.git;a=...
git://oss.oracle.com/git/linux-2.6-unbreakable.git
The main differences from mainline:

*) semtimedop optimizations. I posted these to the list a while ago, and Manfred took things in a less complex direction. He was waiting for me to fully benchmark the less complex version, but we ran out of time in the release cycle and had to focus on other things. Oracle hammers on the IPC lock, so these made a big difference, and now I finally have time to properly benchmark his approach against mine.

*) Ocfs2
*) Small lock contention fixes
*) Receive packet steering
*) A large update to RDS (this is in a different package)
*) A patch to list msi irqs for each device in sysfs. A modified irqbalance uses this to keep irqs on numa local cpus.

There are other bits and pieces, but we resisted the urge to pile things in.

The solid state disk access number came on a huge machine, and the improvements came from getting rid a lock in the driver and enabling it for softirq affinity code without taking any of the request locks.

Over the next 12 months we'll be getting an update prepared to a new mainline version, and trying to hammer on upstream kernels as much as we can to reduce our patch count even more.

-chris

What is the next big problem?

You could try your hand at the other unsolved Millenium Prize Problems.

Don't you mean, the Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act, aka the USA PATRIOT Act?

I was just talking about this with my friend yesterday. She said that someone on the bus just looks over at a woman on her cell phone, and that another rider gave her the dirtiest look until he spoke up and said, 'please put away your cell phone' My friend thought the guy was rude, but I thought he was justified. Cell phones seriously irritate me. That's one good thing about riding the subway.