5 ms·

> It is not wrong to not do something that benefits others. The patch however sneakily removes the chance that the features existing and working on the competi

by acqq 7y ago

> It is not wrong to not do something that benefits others. The patch however sneakily removes the chance that the features existing and working on the competing processors are properly detected and used. In free software it’s clearly evil.

ori_b 7y ago
So patch it. That's the point of free software: the freedom to modify it to your needs.
- smcl 7y ago
  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.
  - jlg23 7y ago
    > 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.
    - alacombe 7y ago
      That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?
      - jlg23 7y ago
        about 3 months ago, in a code audit.
  - randallsquared 7y ago
    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.
- segfaultbuserr 7y ago
  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.
luser1024 7y ago
> 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".
- Dylan16807 7y ago
  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.

by acqq 7y ago

ori_b 7y ago

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

smcl 7y ago
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.
- jlg23 7y ago
  > 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.
  - alacombe 7y ago
    That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?
    - jlg23 7y ago
      about 3 months ago, in a code audit.
- randallsquared 7y ago
  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.
segfaultbuserr 7y ago
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.

luser1024 7y ago

> 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".

Dylan16807 7y ago
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.