We are now relying on more hardware 64bit features, 64bit types for scalability and more. There is minimal interest in 32bit platforms.
As a result, we should deprecate 32bit architectures from our build outputs.
Metadata Update from @firstyear:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None
- Issue assigned to firstyear
- Issue set to the milestone: 1.4 backlog
- Issue tagged with: Easyfix, Investigate
Please be careful with this decision. 32-bit platforms are very common on the ARM architecture.
The Raspberry Pi, Beaglebone Black, etc. all 32-bit. There are 64-bit ARM platforms available but they are far less mature -- eg. 64-bit platform software for the Raspberry Pi 3 is recent and limited:
These Fedora Project images for the latest release (26) are all 32-bit: https://arm.fedoraproject.org/
Small ARM boards are used in production as small network servers: they are cheap to provision and simple to reason about as dedicated standalone devices. eg. separate physical machines have good fault isolation properties and can trivially have separate dedicated access credentials.
389 is a network service that currently fits that deployment model.
The problem with this @xtopher Is that we are starting to rely more on 64bit atomics - which on non-64bit platforms will fall back to mutexes to protect these. In general our addition of 64bit types will also affect performance on these platforms regardless of atomic types.
None of the development team today currently uses 32 bit architectures for testing or development, so as well these platforms are not given the attention they need to make them at least "tolerable". As it stands today, the 32bit build can not be as performant as the 64bit one, and there is little interest to make it so. The majority of our target market is not running small embedded systems, but x86_64 dedicated systems.
Really, it comes down to resources and interest. Today, the team does not have the resources not the interest in working to support a platform that we have little demand for.
If community members wanted to step up and help us with testing on 32bit or helping with development on this, it would really add to the argument to maintain this support. But today that's just not there :(
While this is an upstream decision, you probably better to advertise it on a general Fedora devel list so that those who are interested in 32-bit version would notice it.
In addition, for Fedora you'd need to run a Change process to announce limiting 389-ds builds to 64-bit archs. Probably the same needs to be told to Debian people.
Which fedora devel list do you think would be best to put this on?
I was already discussing thing with @tjaalton so debian/ubuntu is aware, and I'm the maintainer for Gentoo, so I think we should be okay on that front.
This would not be effective for some time, so it's not a sudden decision or process, we have time to make sure it's communicated clearly. 1.3.x will continue to support 32bit arches, it's likely this will affect 1.4.x and future releases.
Main Fedora devel@ list, of course. https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/
Changes need to be announced and this would constitute a system-wide change because it would cause FreeIPA to be unavailable as well on 32-bit platforms. Same to dogtag. See https://fedoraproject.org/wiki/Changes/Policy for details.
Well, first the ds team has to actually agree on this :) this is currently my proposal that we SHOULD deprecate it not that we WILL. :)
So lets see what we decide, then we can get this process underway.
note that 22.214.171.124 fails to build on non-x86 32bit architectures:
sparc64 failed some tests..
to comment on this ticket.