> The patch however sneakily removes the chance ...

If they haven't tested on other processors, should they leave code in because it has a "chance" to work on something else? I think both sides of this question could be legitimately argued so I wouldn't jump to calling it "evil".

What do you mean `"chance" to work`? If the CPU claims to support an instruction, it's perfectly fine to treat it as supporting the instruction.

So patch it. That's the point of free software: the freedom to modify it to your needs.

This is why a bug is reported, when it is patched, the bug will be closed. This is the point of a bug tracker in a free software project: document the current issues that need to be solved or improved.

Well the patch certainly met Intel's needs (a nice little performance bump over its ascendant rival) ... and since someone with a keen eye spotted it, now the rest of us can submit a patch to correct that. But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well.

In this scenario, is not each self-serving patch strictly an improvement? It's at least arguable that a back-and-forth competition to provide improvements serves everyone well.

> But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well.

In large FOSS projects you have enough eyes on those patches to ensure they actually converge towards some (unbiased) optimum.

That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?

about 3 months ago, in a code audit.