[Alupis]

not being familiar with this case -- but from an outside perspective reading the mailing list now, seems Alan introduced a patch that broke userland code -- which is the biggest No-No in kernel hacking, ie. the number 1 rule is don't break userland. Alan appeared to argue userland code was broken and not his patch, which just made Linus mad (as expected). The kernel strives to never break userland, even when userland is relying on legacy and/or broken pieces of kernel code (the idea is to code around the broken parts and provide compatibility until userland changes/fixes their problem -- ie. no kernel change should ever mass-break userland code).

[jff]

> code around the broken parts and provide compatibility until userland changes/fixes their problem

read: provide compatibility indefinitely.

[Alupis]

yes that's the idea. in fact, it was only last year (or maybe 2012) that intel 386 (an almost 30 year old cpu) support was finally dropped. This is how binaries from 20 years ago will still run on today's hardware and kernel with zero modifications. That is a good thing, especially for enterprise.

it's not that they leave security vulnerabilities in, it's that they build compatibility for any software that may expect something to work a certain way, while simultaneously fixing the underlying problem. To software, it should not care what kernel it's running on going forward.