= phenomenon =
Take an actual i386 computer from say 1994, and try to run the Fedora 17 "i386" release... you can't. Today's Fedora release aren't intended and not optimized for the i386.
= reason =
Traditionally there was the argument to not optimize beyond i386 for 32bit Intel/AMD platforms, because it didn't actually improve anything, and in some cases actually made things slower.
Today that's changed, and we optimizing for the i686 architecture.
= recommendation =
We should call the architecture target by what it actually is: "Fedora Release# i686"
This is not what "i386" means in this context.
http://en.wikipedia.org/wiki/IA-32
"IA-32 (Intel Architecture, 32-bit), also known as x86-32, i386, x86"
All i386 means here is "32bit Intel".
I agree that some people find this confusing.
i686 is not very clear either, as we compile our packages with a clear set of options that are not fully expressed by "i686".
Perhaps we should adopt 'ia32' for all the directories/names/collections? Of course yum/rpm are probibly hard coded to look for 'i386' for repos/etc.
"newish ia32" then? I agree there is no perfect solution, as you say "i686" doesn't really capture what we are trying to communicate either.
That said, "ia32" or "x86" or even "x86-32" does imply more of a correct set of assumptions than does "i386". Is it "more correct" enough to change things?
Replying to [comment:4 joshmule]:
"newish ia32" then? I agree there is no perfect solution, as you say "i686" doesn't really capture what we are trying to communicate either. That said, "ia32" or "x86" or even "x86-32" does imply more of a correct set of assumptions than does "i386". Is it "more correct" enough to change things?
x86-32 is particularly confusing. Is it i386? i686? x32 (which is different altogether)?
I don't think any renaming suggested thus far is "more correct" enough to warrant rebuilding the entire distribution. Anyone willing to drive that change needs to show up with patches to RPM, yum, and everywhere else that needs changes first (compose tools, etc).
While this is entirely a personal pipe dream, I'd probably rather drop 32-bit x86 entirely instead of making a change like this.
FESCo:
(We discuss this few times, but no one came with better ultimate solution).
Login to comment on this ticket.