On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus <jeff.backus@gmail.com> wrote:
>
>
>
> On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer <fweimer@redhat.com> wrote:
>>
>> On 06/04/2018 05:55 PM, Jeff Backus wrote:
>>>
>>> Would you please provide more detail on what problem or problems we are trying to solve? Is this purely for efficiency reasons?
>>
>>
>> Mainly developer efficiency. There will be fewer test suite problems due to excess precision (a bunch of packages carry patches which introduce -ffloat-store on i686 to work around them). Packagers will not have to figure out a way how to build for compatibility with non-SSE2 systems (which some upstreams do not support anymore).
>>
>> Furthermore, the divergence from downstream is troubling to Red Hatters for various reasons. (Red Hat Enterprise Linux 7 already underwent a similar change.)
>>
>
> Thanks for the insight. Yes, I can see the advantages. However, have things really gotten so bad that it justifies ejecting part of the community? Yes, a minor part of the community, but a part of the community none the less. As you mentioned, the excess precision issue has a known work around. And for packages where upstream does not support non-SSE2, packagers can raise a flag with the x86 SIG. If there isn't enough interest or bandwidth to add support for non-SSE2 systems, then I think it is perfectly reasonable to add a note in the package description and move on. I believe packages such as Dark Table already do this?
You're describing the status quo today.
> Until (unless?) we have data indicating that this is a major drain on community resources, I'd push back on a change that actively excludes part of the community. Now, if we do have data indicating that supporting non-SSE2 systems with the i686 architecture is a not-insignificant burden on the community, then I ask that this proposal be updated to include a solution that allows us to not push out part of the community, e.g. Ajax's i586 suggestion.
How about data that indicates it's less performant for other usecase
applications? There are a number of situations where 32-bit binaries
would possibly be preferable, such as limited memory VMs, etc.
However, because the tuning is aimed at hardware that is so old, the
performance is worse. Or if we're looking at multi-lib situations,
what if a 32-bit application that requires a 32-bit library happens to
be built with SSE2 enabled? The application can benefit from the
hardware, but the libraries the OS provides cannot. That is an odd
mix.
At some point in time, a determination needs to be made on when to
move on and take advantage of advances in computing hardware.
Continuing to not leverage newer 32-bit hardware seems folly.
> Not trying to be quarrelsome. I understand the desire to focus efforts, however, I hope we can also appreciate the concerns of those of us with currently supported hardware that would be affected by this proposal.
We should really stop using the word "support" here. It implies that
an entity, the Fedora project in this case, is responsible for keeping
it working or treating it as a regression if it does not work. That
is not an accurate description of the situation. We should talk about
i686 hardware as community maintained, which implies the onus is on
those that want it to work to get it to work. One could say "but
Fedora is a community project" and they'd be completely correct but
"support" has too much baggage to use with Fedora in general.