The jump to 3.x was a more or less arbitrary decision made by Linus because the 2.6 version numbers were getting very large. Switching to 3.x should basically be the same as any other kernel upgrade, possibly with some additional issues with software that assumes things about the form of the kernel version number. There shouldn't be any distros holding back from upgrading; in fact Ubuntu 12.04 uses a 3.2 kernel.
I don't think that he is arguing the the GIL isn't a limitation, just that the fundamental limitation it imposes can't be removed without also changing the threading model or the garbage collector. It's really impossible run threads in parallel with any sort of performance when they're all constantly generating a huge amount of cache coherency traffic by updating reference counts.
In general at least the two processors with the conflict will either have to block for a bit or switch to another hardware thread when write conflicts are occurring. There are lots of architecture tricks people pull to try to mitigate the impact but the reality of the matter is frequently mutating shared state (e.g. reference counts) makes it extremely difficult to have good performance with threads running in parallel.
I believe his argument is that it would reduce thrashing between the caches. With the GIL ownership of a cache line containing the reference count for any given object will only have to be transfered at most once per timeslice. If multiple threads were concurrently accessing a python object it would be ping-ponging back and forth between caches much more frequently.
EDIT: Also, "stop whatever they are doing to synchronize the dirty cache lines with RAM," is not a very good way to describe what is going on, often times you don't have to hit RAM at all, the caches just synchronize between each other. It is still pretty bad for performance though.
The issue is not that they aren't distributing the parser generator, it's that they're not distributing the grammars that are the input to the generator.
Actually, both popular mobile operating systems have a POSIX-y system programming interface under the hood. Whether application developers can get at it is a different matter.
Because that's not what rm does. Changing it would be breaking all sorts of standards. Many, many things depend on rm simply unlinking files. Why don't you use a different program if you would like to have some sort of trashbin behavior?
There appears to be a bug in recent versions of Chrome that erroneously disables hardware acceleration on machines running OSX with ATI video cards. It seems that they decided to blacklist multisampling on these machines because of a driver bug but ended up disabling all hardware acceleration.
Just curious, do you actually think that the author or any of the people here don't recognize that the libc and coreutils (for most distributions) come from the GNU project? I don't understand why people insist on being so pedantic about the GNU/Linux thing.