On Mon, Jun 4, 2018 at 1:46 PM, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus <jeff.bac...@gmail.com> wrote: > > > > > > > > On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer <fwei...@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. > 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 > 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. > 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 possible. > > > 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 corrected. jeff -- Jeff Backus jeff.bac...@gmail.com http://github.com/jsbackus
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2ZHT6DR7O4VXMJB55I7M64KYLVHCYY4W/
