FYI. Please discuss this on the devel list.
-------- Forwarded Message -------- Subject: F29 System Wide Change: i686 Is For x86-64 Date: Mon, 4 Jun 2018 10:35:34 +0200 From: Jan Kurik jkurik@redhat.com Reply-To: devel@lists.fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org, devel-announce@lists.fedoraproject.org
= Proposed System Wide Change: i686 Is For x86-64 = https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
Owner(s): * Florian Weimer <fweimer at redhat dot com>
Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
== Detailed description == Currently, the i686 RPM packages are built in such a way that they are compatible with very old i686 systems, such as the Pentium III. The only addition over the i686/Pentium Pro baseline is a requirement to support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs. Furthermore, there are reports that the i686 kernel does not run stable on old hardware which is not x86-64-capable ( https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject.org/th... ). This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs.
== Scope == * Proposal owners: Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the new compiler flags. Except for mstackrealign, there is substantial experience with this configuration downstream.
* Other developers: Other developers can enable SSE2 optimization in their packages if they want, where this has been a compile-time option only.
* Release engineering: https://pagure.io/releng/issues/7543 #7543
** List of deliverables: TBD
* Policies and guidelines: i686 is no longer a primary architecture. The Packaging Guidelines do not currently require support for non-SSE2 x86 systems, so no change is required there.
* Trademark approval: N/A (not needed for this Change)
== Detailed description == Currently, the i686 RPM packages are built in such a way that they are compatible with very old i686 systems, such as the Pentium III. The only addition over the i686/Pentium Pro baseline is a requirement to support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs.
Based on what data?
Furthermore, there are reports that the i686 kernel does not run stable on old hardware which is not x86-64-capable ( https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject.org/th... ).
On some, not all.
This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs.
On which x86 CPU families will Fedora continue to work? I think this change should have been discussed on the x86 SIG mailing list first, as it essentially goes against what the SIG had been trying to do and deprives it of its purpose.
On 06/04/2018 02:39 PM, Alexander Ploumistos wrote:
== Detailed description == Currently, the i686 RPM packages are built in such a way that they are compatible with very old i686 systems, such as the Pentium III. The only addition over the i686/Pentium Pro baseline is a requirement to support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs.
Based on what data?
The mirror data I've seen, but it's really outdated at this point.
This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs.
On which x86 CPU families will Fedora continue to work?
Based on this proposed change, you will need an x86-64-capable CPU.
Thanks, Florian
On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs.
On which x86 CPU families will Fedora continue to work?
Based on this proposed change, you will need an x86-64-capable CPU.
That's not how I read the proposal. No reason a P4 shouldn't work if all you're requiring is SSE2+FXSR, right?
- ajax
On 06/04/2018 05:07 PM, Adam Jackson wrote:
On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs.
On which x86 CPU families will Fedora continue to work?
Based on this proposed change, you will need an x86-64-capable CPU.
That's not how I read the proposal. No reason a P4 shouldn't work if all you're requiring is SSE2+FXSR, right?
It will probably work, but it's more of a happy accident than a deliberate decision. I would still suggest it if it were incompatible with Pentium 4 CPUs without x86-64 support. (The fewer of these Netburst power guzzlers are running, the better, to be honest.)
Certainly, I don't see us jumping to long mode, doing the computation there, and jumping back, so it's hard to imagine that anything more than SSE2 (you need fxsr for SSE2 for the context switch AFAICS anyway) will be required by the i686 user space in the future.
Thanks, Florian
On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote:
On 06/04/2018 05:07 PM, Adam Jackson wrote:
On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs.
On which x86 CPU families will Fedora continue to work?
Based on this proposed change, you will need an x86-64-capable CPU.
That's not how I read the proposal. No reason a P4 shouldn't work if all you're requiring is SSE2+FXSR, right?
It will probably work, but it's more of a happy accident than a deliberate decision. I would still suggest it if it were incompatible with Pentium 4 CPUs without x86-64 support. (The fewer of these Netburst power guzzlers are running, the better, to be honest.)
Certainly, I'm no netburst fan either. But the last[*] 32-bit-only Intel chip was Yonah (Core 1), which went out of production in 2008- ish, so there's about seven years worth of CPUs between the introductions of SSE2 and AMD64. So this isn't eliminating the possibility of extant i686 kernels, which "will need an x86-64-capable CPU" might otherwise imply.
[*] - Ignoring Quark, as the rest of the market did.
- ajax
Once upon a time, Adam Jackson ajax@redhat.com said:
Certainly, I'm no netburst fan either. But the last[*] 32-bit-only Intel chip was Yonah (Core 1), which went out of production in 2008- ish, so there's about seven years worth of CPUs between the introductions of SSE2 and AMD64.
I think you are missing a some of The Atom chips that are 32-bit only; there are versions that were released as late as 2010 that don't support 64-bit (I don't know when they were discontinued). Whether that's a target for Fedora i686, I don't know.
* Chris Adams [04/06/2018 10:58] :
I think you are missing a some of The Atom chips that are 32-bit only; there are versions that were released as late as 2010 that don't support 64-bit (I don't know when they were discontinued).
You're thinking of the Lincroft series of Intel CPUs: http://www.cpu-world.com/CPUs/Atom/Intel-Atom%20Z650%20AY80609007296AA.html http://www.cpu-world.com/CPUs/Atom/Intel-Atom%20Z670%20AY80609007293AA.html
They were introduced in 2011 and EOL-ed in 2013.
Emmanuel
On Mon, Jun 4, 2018 at 11:52 AM, Adam Jackson ajax@redhat.com wrote:
On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote:
On 06/04/2018 05:07 PM, Adam Jackson wrote:
On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs.
On which x86 CPU families will Fedora continue to work?
Based on this proposed change, you will need an x86-64-capable CPU.
That's not how I read the proposal. No reason a P4 shouldn't work if all you're requiring is SSE2+FXSR, right?
It will probably work, but it's more of a happy accident than a deliberate decision. I would still suggest it if it were incompatible with Pentium 4 CPUs without x86-64 support. (The fewer of these Netburst power guzzlers are running, the better, to be honest.)
Certainly, I'm no netburst fan either. But the last[*] 32-bit-only Intel chip was Yonah (Core 1), which went out of production in 2008- ish, so there's about seven years worth of CPUs between the introductions of SSE2 and AMD64. So this isn't eliminating the possibility of extant i686 kernels, which "will need an x86-64-capable CPU" might otherwise imply.
Yeah, I have a handful of i686 hardware newer than 2001 that runs pretty well.
jeff
On Mon, Jun 04, 2018 at 04:04:30PM +0200, Florian Weimer wrote:
only addition over the i686/Pentium Pro baseline is a requirement to support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs.
Based on what data?
The mirror data I've seen, but it's really outdated at this point.
There are currently about 275,000 IP address checking in with x86_64 systems every day. and 25,000 x86_32. So it's about 11:1.
However, that includes systems going back to FC6; if we looked at just recent releases it'd be even more tilted. (I don't have a quick way to break that out at my fingertips, but could ask for it if it's really helpful.)
On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs.
Based on what data?
The mirror data I've seen, but it's really outdated at this point.
There are currently about 275,000 IP address checking in with x86_64 systems every day. and 25,000 x86_32. So it's about 11:1.
Here's a breakdown as arch percentage over time:
https://twitter.com/mattdm/status/1003701941724172295
Looks like the 50:50 point was about five years ago.
On 4 June 2018 at 14:18, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs.
Based on what data?
The mirror data I've seen, but it's really outdated at this point.
There are currently about 275,000 IP address checking in with x86_64 systems every day. and 25,000 x86_32. So it's about 11:1.
Here's a breakdown as arch percentage over time:
https://twitter.com/mattdm/status/1003701941724172295
Looks like the 50:50 point was about five years ago.
For F26,F27,F28 for the first 150 days of the year:
Days: 150 X86_32: 3769.4 avg/day X86_64: 159540 avg/day Ratio (32/64) 0.0236267 (1:42)
The reason is that the majority of i386 users are not moving off of dead/old releases. For the month of May
Avg/day release 28623.7 epel6 16009.2 epel5 4043.37 f25 3318.53 f20 2759.2 f08 2127.8 f23 1589.63 f27 1401.7 f22 1371 f26 1277.53 f21 1056.33 f28 874.2 f24 733.8 f14 562.533 f19 509.067 f11
In comparison, x86_64 is mostly living on the latest release: [smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018 | awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk '{print $1/30, $2}' 671455 epel7 605436 epel6 87367.4 f27 60159.7 f28 37857.6 epel5 34421.4 f26 27011 f25 19115.4 f23 14292.2 f24 8627.47 f22 6603.3 f20 5863.47 f21 1413.37 modular_f28 1091.87 f19 868.833 f18
The 30 is because only 30 days of May have been analyzed. [And yes there are still many Fedora 08 systems showing up for x86_32]
Personally I think the number of those systems which are running Pentium III hardware with the latest OS are probably already on this mailing list.. I expect that they would also be looking at only needing to support a small subset of the software since running GNOME/KDE with usually 128->512 MB of RAM is not possible. It also would probably want a very stripped down installer since anaconda is aimed at 'current' hardware... probably something like the images that ARM-32 makes.
On Mon, Jun 4, 2018 at 3:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 4 June 2018 at 14:18, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs.
Based on what data?
The mirror data I've seen, but it's really outdated at this point.
There are currently about 275,000 IP address checking in with x86_64 systems every day. and 25,000 x86_32. So it's about 11:1.
Here's a breakdown as arch percentage over time:
https://twitter.com/mattdm/status/1003701941724172295
Looks like the 50:50 point was about five years ago.
For F26,F27,F28 for the first 150 days of the year:
Days: 150 X86_32: 3769.4 avg/day X86_64: 159540 avg/day Ratio (32/64) 0.0236267 (1:42)
The reason is that the majority of i386 users are not moving off of dead/old releases. For the month of May
Avg/day release 28623.7 epel6 16009.2 epel5 4043.37 f25 3318.53 f20 2759.2 f08 2127.8 f23 1589.63 f27 1401.7 f22 1371 f26 1277.53 f21 1056.33 f28 874.2 f24 733.8 f14 562.533 f19 509.067 f11
In comparison, x86_64 is mostly living on the latest release: [smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018 | awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk '{print $1/30, $2}' 671455 epel7 605436 epel6 87367.4 f27 60159.7 f28 37857.6 epel5 34421.4 f26 27011 f25 19115.4 f23 14292.2 f24 8627.47 f22 6603.3 f20 5863.47 f21 1413.37 modular_f28 1091.87 f19 868.833 f18
The 30 is because only 30 days of May have been analyzed. [And yes there are still many Fedora 08 systems showing up for x86_32]
Personally I think the number of those systems which are running Pentium III hardware with the latest OS are probably already on this mailing list.. I expect that they would also be looking at only needing to support a small subset of the software since running GNOME/KDE with usually 128->512 MB of RAM is not possible. It also would probably want a very stripped down installer since anaconda is aimed at 'current' hardware... probably something like the images that ARM-32 makes.
Very good point!
And wow! Fedora 08 was quite some time ago... :)
On Mon, Jun 4, 2018 at 3:08 PM, Jeff Backus jeff.backus@gmail.com wrote:
On Mon, Jun 4, 2018 at 3:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 4 June 2018 at 14:18, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
>support long NOPs, for Intel CET. However, the majority of >installations of i686 packages is for use on x86_64 systems, as >multi-lib RPMs. Based on what data?
The mirror data I've seen, but it's really outdated at this point.
There are currently about 275,000 IP address checking in with x86_64 systems every day. and 25,000 x86_32. So it's about 11:1.
Here's a breakdown as arch percentage over time:
https://twitter.com/mattdm/status/1003701941724172295
Looks like the 50:50 point was about five years ago.
For F26,F27,F28 for the first 150 days of the year:
Days: 150 X86_32: 3769.4 avg/day X86_64: 159540 avg/day Ratio (32/64) 0.0236267 (1:42)
The reason is that the majority of i386 users are not moving off of dead/old releases. For the month of May
Avg/day release 28623.7 epel6 16009.2 epel5 4043.37 f25 3318.53 f20 2759.2 f08 2127.8 f23 1589.63 f27 1401.7 f22 1371 f26 1277.53 f21 1056.33 f28 874.2 f24 733.8 f14 562.533 f19 509.067 f11
In comparison, x86_64 is mostly living on the latest release: [smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018 | awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk '{print $1/30, $2}' 671455 epel7 605436 epel6 87367.4 f27 60159.7 f28 37857.6 epel5 34421.4 f26 27011 f25 19115.4 f23 14292.2 f24 8627.47 f22 6603.3 f20 5863.47 f21 1413.37 modular_f28 1091.87 f19 868.833 f18
The 30 is because only 30 days of May have been analyzed. [And yes there are still many Fedora 08 systems showing up for x86_32]
Personally I think the number of those systems which are running Pentium III hardware with the latest OS are probably already on this mailing list.. I expect that they would also be looking at only needing to support a small subset of the software since running GNOME/KDE with usually 128->512 MB of RAM is not possible. It also would probably want a very stripped down installer since anaconda is aimed at 'current' hardware... probably something like the images that ARM-32 makes.
Very good point!
And wow! Fedora 08 was quite some time ago... :)
It was, and it was used as a long time as a base image for VMs somewhere, which is probably where a lot of those numbers are coming from. It would be really interesting if we could see a breakdown of VM vs raw metal, as I am guessing a whole lot of the i686 is VM traffic. I know I have at least 4 of those VMs per release checking in just for kernel testing bits. For a long time there was also a trend of people running 32bit guests wherever they could to reduce memory footprint.
-- Jeff Backus jeff.backus@gmail.com http://github.com/jsbackus
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/...
On Mon, Jun 4, 2018 at 2:18 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs.
Based on what data?
The mirror data I've seen, but it's really outdated at this point.
There are currently about 275,000 IP address checking in with x86_64 systems every day. and 25,000 x86_32. So it's about 11:1.
Here's a breakdown as arch percentage over time:
https://twitter.com/mattdm/status/1003701941724172295
Looks like the 50:50 point was about five years ago.
Thanks! Very helpful to see x86_32 compared to ARM. Trajectory is very important, but laying that aside, x86_32 a) significantly larger than both ARM arches combined, and b) roughly 10% of the "user base".
jeff
On Mon, Jun 4, 2018 at 2:01 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 04, 2018 at 04:04:30PM +0200, Florian Weimer wrote:
only addition over the i686/Pentium Pro baseline is a requirement to support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs.
Based on what data?
The mirror data I've seen, but it's really outdated at this point.
There are currently about 275,000 IP address checking in with x86_64 systems every day. and 25,000 x86_32. So it's about 11:1.
However, that includes systems going back to FC6; if we looked at just recent releases it'd be even more tilted. (I don't have a quick way to break that out at my fingertips, but could ask for it if it's really helpful.)
Thanks for the data. 25k is still a pretty healthy number. :) I realize that there are a lot of unknowns in the data, so it is difficult to draw any hard conclusions, but 25k is still much larger than 0. Splitting into i686 into i586 and i686 would give more insight into who still needs non-SSE2... Probably hurts my argument, though. :)
jeff
On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
Thanks for the data. 25k is still a pretty healthy number. :) I realize
Yeah, absolutely. And it's likely that those mirror numbers undercount, because not every system checks in daily, and then there's also NAT.
But, my gut feeling is that about half of those are not using a current release _anyway_. Honest question: do you think that 12k would still count as a healthy number? I mean, it's not peanuts. But maybe it'd be better served by a Fedora remix (or similar) specifically targetting older and low-powered systems?
that there are a lot of unknowns in the data, so it is difficult to draw any hard conclusions, but 25k is still much larger than 0. Splitting into i686 into i586 and i686 would give more insight into who still needs non-SSE2... Probably hurts my argument, though. :)
Soooooo.... this is the kind of thing that more a detailed hardware census could really help us with!
On Mon, Jun 04, 2018 at 10:07:55PM -0400, Matthew Miller wrote:
But, my gut feeling is that about half of those are not using a current release _anyway_. Honest question: do you think that 12k would still count as a healthy number? I mean, it's not peanuts. But maybe it'd be
Ooh, I should read whole threads before replying. (Thanks, Smooge!) Looks like it's more like 4k than 12k.
On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
Thanks for the data. 25k is still a pretty healthy number. :) I realize
Yeah, absolutely. And it's likely that those mirror numbers undercount, because not every system checks in daily, and then there's also NAT.
But, my gut feeling is that about half of those are not using a current release _anyway_. Honest question: do you think that 12k would still count as a healthy number? I mean, it's not peanuts. But maybe it'd be better served by a Fedora remix (or similar) specifically targetting older and low-powered systems?
Good question. I think it would be more productive to think in percentages instead of raw numbers, in this case. There are a lot of FOSS projects out there that would love to have 12k users. :)
Certainly, I would consider 10% a healthy number when talking about portion of user base. I would even argue that 1% is still a healthy number, particularly with regard to decisions that have a reasonable chance of disenfranchising those affected. While I hate seeing people leave a community, I wouldn't be able to defend 0.1%. So, somewhere in there is my general boundary.
Now cost changes all of that, of course. Obviously if 75% of our effort is going to please 10%, then 10% isn't a healthy number.
Clearly effort is going into enabling Fedora to work on non-SSE2 systems by teams invested in the success of Fedora in general and not the success of non-SSE2 systems in particular. I just don't know how to quantify it.
Based on Smooge's awesome numbers, it looks like x86_32 is in the 2.3% range. It would be interesting to see how this stacks up to AArch64 and other secondary arches. Unfortunately, what complicates things is how x86_32 is so intertwined with x86_64.
To your point re: a remix, that is an option we've discussed within the SIG and is one we are open to exploring. A remix wouldn't resolve issues introduced by enabling SSE2 by default, unless we maintained a parallel set of packages e.g. i586 (which I've already been warned about. :) )
that there are a lot of unknowns in the data, so it is difficult to draw any hard conclusions, but 25k is still much larger than 0. Splitting into i686 into i586 and i686 would give more insight into who still needs non-SSE2... Probably hurts my argument, though. :)
Soooooo.... this is the kind of thing that more a detailed hardware census could really help us with!
Yes, I would agree :)
On 5 June 2018 at 12:49, Jeff Backus jeff.backus@gmail.com wrote:
On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
Thanks for the data. 25k is still a pretty healthy number. :) I realize
Yeah, absolutely. And it's likely that those mirror numbers undercount, because not every system checks in daily, and then there's also NAT.
But, my gut feeling is that about half of those are not using a current release _anyway_. Honest question: do you think that 12k would still count as a healthy number? I mean, it's not peanuts. But maybe it'd be better served by a Fedora remix (or similar) specifically targetting older and low-powered systems?
Good question. I think it would be more productive to think in percentages instead of raw numbers, in this case. There are a lot of FOSS projects out there that would love to have 12k users. :)
Certainly, I would consider 10% a healthy number when talking about portion of user base. I would even argue that 1% is still a healthy number, particularly with regard to decisions that have a reasonable chance of disenfranchising those affected. While I hate seeing people leave a community, I wouldn't be able to defend 0.1%. So, somewhere in there is my general boundary.
Now cost changes all of that, of course. Obviously if 75% of our effort is going to please 10%, then 10% isn't a healthy number.
Clearly effort is going into enabling Fedora to work on non-SSE2 systems by teams invested in the success of Fedora in general and not the success of non-SSE2 systems in particular. I just don't know how to quantify it.
Based on Smooge's awesome numbers, it looks like x86_32 is in the 2.3% range. It would be interesting to see how this stacks up to AArch64 and other secondary arches. Unfortunately, what complicates things is how x86_32 is so intertwined with x86_64.
It is also complicated in that most of the large sites using aarch64 and arm32 do so in ways which make them uncountable. They will have 'thousands' of nodes but all of them use an internal mirror so we see them as only 1..
The other issue is that the arm/aarch64 have active upstream help from people who are building the boards. There isn't any such support on the x86_32 side with the manufacturers getting to the point of saying "here is $20.00 and an ebay link.. buy at least a pentium iv or v please. " The question that the x86 group needs to figure out is how many of the 3800 active systems are going to not have SSE2.
To your point re: a remix, that is an option we've discussed within the SIG and is one we are open to exploring. A remix wouldn't resolve issues introduced by enabling SSE2 by default, unless we maintained a parallel set of packages e.g. i586 (which I've already been warned about. :) )
that there are a lot of unknowns in the data, so it is difficult to draw any hard conclusions, but 25k is still much larger than 0. Splitting into i686 into i586 and i686 would give more insight into who still needs non-SSE2... Probably hurts my argument, though. :)
Soooooo.... this is the kind of thing that more a detailed hardware census could really help us with!
Yes, I would agree :)
So it would probably be a lot more detailed than other sites are running. I looked at the popcorn data and they seem to count whether an OS is i386 or amd64 not if the CPU is pentium iii. Neither did any of the other OS census programs.
On Tue, Jun 5, 2018 at 1:55 PM Stephen John Smoogen smooge@gmail.com wrote:
On 5 June 2018 at 12:49, Jeff Backus jeff.backus@gmail.com wrote:
On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
Thanks for the data. 25k is still a pretty healthy number. :) I realize
Yeah, absolutely. And it's likely that those mirror numbers undercount, because not every system checks in daily, and then there's also NAT.
But, my gut feeling is that about half of those are not using a current release _anyway_. Honest question: do you think that 12k would still count as a healthy number? I mean, it's not peanuts. But maybe it'd be better served by a Fedora remix (or similar) specifically targetting older and low-powered systems?
Good question. I think it would be more productive to think in percentages instead of raw numbers, in this case. There are a lot of FOSS projects out there that would love to have 12k users. :)
Certainly, I would consider 10% a healthy number when talking about portion of user base. I would even argue that 1% is still a healthy number, particularly with regard to decisions that have a reasonable chance of disenfranchising those affected. While I hate seeing people leave a community, I wouldn't be able to defend 0.1%. So, somewhere in there is my general boundary.
Now cost changes all of that, of course. Obviously if 75% of our effort is going to please 10%, then 10% isn't a healthy number.
Clearly effort is going into enabling Fedora to work on non-SSE2 systems by teams invested in the success of Fedora in general and not the success of non-SSE2 systems in particular. I just don't know how to quantify it.
Based on Smooge's awesome numbers, it looks like x86_32 is in the 2.3% range. It would be interesting to see how this stacks up to AArch64 and other secondary arches. Unfortunately, what complicates things is how x86_32 is so intertwined with x86_64.
It is also complicated in that most of the large sites using aarch64 and arm32 do so in ways which make them uncountable. They will have 'thousands' of nodes but all of them use an internal mirror so we see them as only 1..
The other issue is that the arm/aarch64 have active upstream help from people who are building the boards. There isn't any such support on the x86_32 side with the manufacturers getting to the point of saying "here is $20.00 and an ebay link.. buy at least a pentium iv or v please. " The question that the x86 group needs to figure out is how many of the 3800 active systems are going to not have SSE2.
To your point re: a remix, that is an option we've discussed within the SIG and is one we are open to exploring. A remix wouldn't resolve issues introduced by enabling SSE2 by default, unless we maintained a parallel set of packages e.g. i586 (which I've already been warned about. :) )
that there are a lot of unknowns in the data, so it is difficult to draw any hard conclusions, but 25k is still much larger than 0. Splitting into i686 into i586 and i686 would give more insight into who still needs non-SSE2... Probably hurts my argument, though. :)
Soooooo.... this is the kind of thing that more a detailed hardware census could really help us with!
Yes, I would agree :)
So it would probably be a lot more detailed than other sites are running. I looked at the popcorn data and they seem to count whether an OS is i386 or amd64 not if the CPU is pentium iii. Neither did any of the other OS census programs.
I think this is a red herring. We have no concrete plans around an improved hardware census and the goals of such a service aren't to count how many 32-bit x86 installs we have anyway. It's fine to discuss this, but it should be done in a separate thread. Likely from the viewpoint of justifying an i586 effort by the x86 SIG.
It should not have any bearing on the proposed Change though. With no set timeframe for even having people to drive forward with the idea for a hardware census tool, let alone software actually written to do it, involving that in this discussion is kicking the can down the road indefinitely.
josh
On Tue, Jun 5, 2018 at 1:54 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 5 June 2018 at 12:49, Jeff Backus jeff.backus@gmail.com wrote:
On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller <
mattdm@fedoraproject.org>
wrote:
On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
Thanks for the data. 25k is still a pretty healthy number. :) I
realize
Yeah, absolutely. And it's likely that those mirror numbers undercount, because not every system checks in daily, and then there's also NAT.
But, my gut feeling is that about half of those are not using a current release _anyway_. Honest question: do you think that 12k would still count as a healthy number? I mean, it's not peanuts. But maybe it'd be better served by a Fedora remix (or similar) specifically targetting older and low-powered systems?
Good question. I think it would be more productive to think in
percentages
instead of raw numbers, in this case. There are a lot of FOSS projects
out
there that would love to have 12k users. :)
Certainly, I would consider 10% a healthy number when talking about
portion
of user base. I would even argue that 1% is still a healthy number, particularly with regard to decisions that have a reasonable chance of disenfranchising those affected. While I hate seeing people leave a community, I wouldn't be able to defend 0.1%. So, somewhere in there is
my
general boundary.
Now cost changes all of that, of course. Obviously if 75% of our effort
is
going to please 10%, then 10% isn't a healthy number.
Clearly effort is going into enabling Fedora to work on non-SSE2 systems
by
teams invested in the success of Fedora in general and not the success of non-SSE2 systems in particular. I just don't know how to quantify it.
Based on Smooge's awesome numbers, it looks like x86_32 is in the 2.3% range. It would be interesting to see how this stacks up to AArch64 and other secondary arches. Unfortunately, what complicates things is how
x86_32
is so intertwined with x86_64.
It is also complicated in that most of the large sites using aarch64 and arm32 do so in ways which make them uncountable. They will have 'thousands' of nodes but all of them use an internal mirror so we see them as only 1..
Good point. Does this affect x86_64, as well?
The other issue is that the arm/aarch64 have active upstream help from people who are building the boards. There isn't any such support on the x86_32 side with the manufacturers getting to the point of saying "here is $20.00 and an ebay link.. buy at least a pentium iv or v please. " The question that the x86 group needs to figure out is how many of the 3800 active systems are going to not have SSE2.
re: upstreams - Agreed. Clearly we are on borrowed time.
re: SSE2 - Agreed. We might be able to do some clever filtering with Bugzilla to get an idea...
To your point re: a remix, that is an option we've discussed within the
SIG
and is one we are open to exploring. A remix wouldn't resolve issues introduced by enabling SSE2 by default, unless we maintained a parallel
set
of packages e.g. i586 (which I've already been warned about. :) )
that there are a lot of unknowns in the data, so it is difficult to
draw
any hard conclusions, but 25k is still much larger than 0. Splitting into i686 into i586 and i686 would give more insight into who still needs non-SSE2... Probably hurts my argument, though. :)
Soooooo.... this is the kind of thing that more a detailed hardware census could really help us with!
Yes, I would agree :)
So it would probably be a lot more detailed than other sites are running. I looked at the popcorn data and they seem to count whether an OS is i386 or amd64 not if the CPU is pentium iii. Neither did any of the other OS census programs.
Thanks for looking. It's unfortunate, but not surprising.
On Mon, Jun 4, 2018 at 7:20 AM, Florian Weimer fweimer@redhat.com wrote:
= Proposed System Wide Change: i686 Is For x86-64 = https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
Owner(s):
- Florian Weimer <fweimer at redhat dot com>
Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
== Detailed description == Currently, the i686 RPM packages are built in such a way that they are compatible with very old i686 systems, such as the Pentium III. The only addition over the i686/Pentium Pro baseline is a requirement to support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs. Furthermore, there are reports that the i686 kernel does not run stable on old hardware which is not x86-64-capable ( https://lists.fedoraproject.org/archives/list/x86@lists.fedo raproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/ ). This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs.
Would you please provide more detail on what problem or problems we are trying to solve? Is this purely for efficiency reasons?
jeff
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, Florian
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?
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.
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.
jeff
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.
josh
On Mon, Jun 4, 2018 at 1:46 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
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.
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
On 2018-06-04 9:55 am, Jeff Backus 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?
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.
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.
jeff
On 06/04/2018 06:55 PM, Jeff Backus wrote:
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?
The cost of i686 support is not insignificant. Most of that happens upstream (like features only getting accepted when there's an i386/i686 implementation). There's little we can do about that, but:
In fedora, we are also a point of contact for weird bugs which someone needs to triage. I really don't want to do that, but due to the lack of secondary architectures, I'm often forced to because i686 breakage brings development on architectures which I actually care about to a halt.
I can justify this work if it helps downstream (so that we can be confident that customers will be able to run their legacy software going forward). But with the current divergence in build flags, it is fairly questionable whether my work can deliver such a benefit, and that is frustrating.
Thanks, Florian
Can someone explain me *real quick* what is the multilib good for? - or more precisely, why whould anone run 32-bit software on x86_64 OS?
From what I googled, it look like everyone does it yet nobody explains why :D
--
Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat
On Wed, Jun 6, 2018 at 8:09 PM, Florian Weimer fweimer@redhat.com wrote:
On 06/04/2018 06:55 PM, Jeff Backus wrote:
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?
The cost of i686 support is not insignificant. Most of that happens upstream (like features only getting accepted when there's an i386/i686 implementation). There's little we can do about that, but:
In fedora, we are also a point of contact for weird bugs which someone needs to triage. I really don't want to do that, but due to the lack of secondary architectures, I'm often forced to because i686 breakage brings development on architectures which I actually care about to a halt.
I can justify this work if it helps downstream (so that we can be confident that customers will be able to run their legacy software going forward). But with the current divergence in build flags, it is fairly questionable whether my work can deliver such a benefit, and that is frustrating.
Thanks, Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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.or g/archives/list/devel@lists.fedoraproject.org/message/SJ57YL A5XHOYJAAZR3RZBSOPOR4KEO53/
Am 07.06.2018 um 11:50 schrieb Michal Schorm:
Can someone explain me *real quick* what is the multilib good for? - or more precisely, why whould anone run 32-bit software on x86_64 OS?
From what I googled, it look like everyone does it yet nobody explains why :D
* https://www.winehq.org/ * software outside the distribution
Because sometimes the software I'm developing needs to link with a proprietary library that is only available as 32 bit library.
It's a lot rarer than it used to be but there are still a few databases that I work with that don't have 64 bit libraries.
Or indeed just because our customers want a 32 bit version of our software so we have to be able to build and test it, though we're on the verge of trying to drop most 32 bit support now.
Tom
On 07/06/18 10:50, Michal Schorm wrote:
Can someone explain me *real quick* what is the multilib good for? - or more precisely, why whould anone run 32-bit software on x86_64 OS?
From what I googled, it look like everyone does it yet nobody explains why :D
--
Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat
On Wed, Jun 6, 2018 at 8:09 PM, Florian Weimer <fweimer@redhat.com mailto:fweimer@redhat.com> wrote:
On 06/04/2018 06:55 PM, Jeff Backus wrote: 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? The cost of i686 support is not insignificant. Most of that happens upstream (like features only getting accepted when there's an i386/i686 implementation). There's little we can do about that, but: In fedora, we are also a point of contact for weird bugs which someone needs to triage. I really don't want to do that, but due to the lack of secondary architectures, I'm often forced to because i686 breakage brings development on architectures which I actually care about to a halt. I can justify this work if it helps downstream (so that we can be confident that customers will be able to run their legacy software going forward). But with the current divergence in build flags, it is fairly questionable whether my work can deliver such a benefit, and that is frustrating. Thanks, Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-leave@lists.fedoraproject.org <mailto:devel-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html <https://getfedora.org/code-of-conduct.html> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SJ57YLA5XHOYJAAZR3RZBSOPOR4KEO53/ <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SJ57YLA5XHOYJAAZR3RZBSOPOR4KEO53/>
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/...
On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm mschorm@redhat.com wrote:
Can someone explain me *real quick* what is the multilib good for? - or more precisely, why whould anone run 32-bit software on x86_64 OS?
In my case, there are a couple of games that are either older, or just not provided in 64bit so I need a few 32bit libraries in order for the kids to play them.
Thanks, Richard
Michal Schorm mschorm@redhat.com writes:
Can someone explain me *real quick* what is the multilib good for? - or more precisely, why whould anone run 32-bit software on x86_64 OS?
Among other reasons, 32-bit code can be smaller and faster than 64-bit code for some applications. When trying to stuff many containers or VMs into one server, disk and memory space might be overriding considerations. There might be old code that isn't 64-bit aware yet, and the cost of fixing it might not be justified, especially if there's an on-disk data format that's 32-bit-centric, or if the authors are unavailable. Building only 32-bit code cuts your QA time in half if you have to support both 32 and 64 bit hosts. You might have optimizations written in 32-bit assembly, or libraries that are only available as 32-bit versions. Or you may rely on someone else's 32-bit code that is closed source, or abandoned.
That doesn't even touch on the continued need for 32-bit embedded platforms, where 32-bit things on a 64-bit host can be used as a "cross development" system.
On Wed, Jun 6, 2018 at 2:09 PM, Florian Weimer fweimer@redhat.com wrote:
On 06/04/2018 06:55 PM, Jeff Backus wrote:
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?
The cost of i686 support is not insignificant. Most of that happens upstream (like features only getting accepted when there's an i386/i686 implementation). There's little we can do about that, but:
In fedora, we are also a point of contact for weird bugs which someone needs to triage. I really don't want to do that, but due to the lack of secondary architectures, I'm often forced to because i686 breakage brings development on architectures which I actually care about to a halt.
Makes sense. Are these bugs mostly related to instruction set, size of int, or something else? (more for my curiosity, don't spend time looking)
I can justify this work if it helps downstream (so that we can be confident
that customers will be able to run their legacy software going forward). But with the current divergence in build flags, it is fairly questionable whether my work can deliver such a benefit, and that is frustrating.
Yes, I I'm sure it is! I can appreciate the desire to consolidate configurations.
jeff