On Mon, Jun 4, 2018 at 1:46 PM, Josh Boyer <jwboyer(a)fedoraproject.org>
On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus
> On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer <fweimer(a)redhat.com>
>> 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
> 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.
Yes, I am arguing in favor of the status quo.
> 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
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
I agree that this is a valid use case. The i586 arch would be reasonable
compromise, depending on the amount of effort required to split i686.
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.
Agreed. I'm just arguing for choosing a path that excludes as few users as
> 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.
Good point, and, yes, I should have used a more precise term. Secondary
arches definitely fall under the purview of 'community maintained'. I stand