- 1 Fedora x86 (Intel/AMD/VIA 32 bit)
- 1.1 Contact Info
- 1.2 Introduction
- 1.3 Targets
- 1.4 Accomplished
- 1.5 People
- 1.6 History
- 1.7 Supported Hardware
- 1.8 Release Notes
- 1.9 Tips
- 1.10 Known Runtime Issues
- 1.11 Known build issues
- 1.12 Notes for application developers and package maintainers
- 1.13 Submitting builds
- 1.14 Packages under review
- 2 Get Involved with Fedora x86
Fedora x86 (Intel/AMD/VIA 32 bit)
- IRC: freenode.net
- Regular IRC meetings: TBD
- Mailing List:
The X86 architecture has been built from the very beginning of Red Hat Linux, but is no longer the primary build target with X86_64 replacing it. This change has happened over the last decade, and the lack of attention by most developers has left the system not as used as before.
This page and targeting is aimed at trying to fix this problem.
short term goals
- Determine if there are enough active members to be viable.
- Determine which bugs for x86 are outstanding
- Determine what deliverable will be for next release.
- To be decided
long term goals
- Determine which hardware will be supported for release after next.
- To be decided
- To Be Filled out by Team
The x86 architecture itself has a long and storied history which are better outlined in the IA-32 and X86 Wikipedia articles. Because of the fact that the name of the architecture is confusing with ia64 not being ia32 with a 64 bit bus, and similar items, Fedora has either used i386 or x86 to refer to the architecture.
Currently only later models in the i686 architecture are supported:
- Intel: Pentium II and above.
- AMD: ???
- VIA: ???
How much of the maintenance problems are due to the PAE feature for supporting more than 4 GiB of physical RAM? How much of the use cases would be affected if PAE were not supported at all, or if more than 4 GiB were tolerated but just unused? What if the limit on supported physical RAM were 8 GiB, or something else towards the low end but still more than 4 GiB?
How much of the maintenance problems are due to supporting more than 2 or 4 CPUs? Hyper-threading?
Running a i686 user-space application under a 64-bit x86_64 kernel is moderately pleasant. The application gets around 3.9GiB of address space, and shared libraries are placed at the high end, just below the stack, and with only 1 page of guard zone between each. This avoids the i686 default fragmentation of putting shared modules at 0x40000000, while increasing the exposure to damage by malware due to predictable layout of address space. Some applications would accept such a tradeoff, particularly in well-managed constrained environments.
Known Runtime Issues
- BZ#1375732 Anaconda reclaim space is broken on x86
Notes for application developers and package maintainers
As of 2017-07-12 there should be no need for a maintainer to do a regular build, they are automagically processed through the primary koji.
Packages under review
Get Involved with Fedora x86
Bugs should be reported against their prospective packages as per standard Fedora process and block the x86 tracker bug. Other methods may be added by x86 team later.