Just a thought
If the I386 (or i686, never could figure out why the name change) disk doesn't quite fit on the DVD+, and needs a DVD-, this might put some folks at an inconvenience.
I wonder if the difference between fitting and not fitting is small enough, so that some amount of pruning might make it fit on the DVD+R image. Some ways to prune could be:
a) Create two versions of the DVD, one with all the non-ideographic languages included, and one with the ideographic languares and a subset of the alphabet languages (English, German, French, ...)
b) Find some less used but large package which presumes internet access. It could be downloaded with YUM
c) Tackle the code bloat (oh yah, sure)
David
On Sat, 2011-07-16 at 19:50 -0700, david wrote:
If the I386 (or i686, never could figure out why the name change) disk doesn't quite fit on the DVD+, and needs a DVD-, this might put some folks at an inconvenience.
I wonder if the difference between fitting and not fitting is small enough, so that some amount of pruning might make it fit on the DVD+R image. Some ways to prune could be:
a) Create two versions of the DVD, one with all the non-ideographic languages included, and one with the ideographic languares and a subset of the alphabet languages (English, German, French, ...)
b) Find some less used but large package which presumes internet access. It could be downloaded with YUM
c) Tackle the code bloat (oh yah, sure)
Centos 5.6 X86_64 is on two DVDs. Can not determine if -R or +R. However when installing, disk 2 is never required.
With best regards,
Paul. England, EU.
Always Learning wrote:
Centos 5.6 X86_64 is on two DVDs. Can not determine if -R or +R. However when installing, disk 2 is never required.
I used it on my first and only install. Of course I chose some extra packages, and that is why infrequently used packages are on the disk 2.
Ljubomir
On 07/16/11 7:50 PM, david wrote:
Just a thought
If the I386 (or i686, never could figure out why the name change) disk doesn't quite fit on the DVD+, and needs a DVD-, this might put some folks at an inconvenience.
I wonder if the difference between fitting and not fitting is small enough, so that some amount of pruning might make it fit on the DVD+R image. Some ways to prune could be:
a) Create two versions of the DVD, one with all the non-ideographic languages included, and one with the ideographic languares and a subset of the alphabet languages (English, German, French, ...)
b) Find some less used but large package which presumes internet access. It could be downloaded with YUM
c) Tackle the code bloat (oh yah, sure)
d) use the netinstall CD (or PXE or USB stick), put a repo mirror on a local http server, and install from there.
If the I386 (or i686, never could figure out why the name change)
I think on CentOS/RHEL it's because they dropped support for the 586 & earlier processors. Linux wide there's been a general drop in support for 386 class machines. Something to do with recent versions of glibc and a instruction only present in the 486 and better.
On 07/16/11 7:50 PM, david wrote:
If the I386 (or i686, never could figure out why the name change)
I386 was the original 386 CPU, which ran at speeds from 16 to 33Mhz i486 includes a few additional instructions on the 486 processor, and IIRC, ran at speeds from 25 to 100Mhz i586 is the original pentium, at 60, 66, 90, 100 up to about 133Mhz i686 is the pentium pro and pentium-II, -III, -IV and everything newer.
i686 added a few minor new instructions but also has additional memory management functionality missing from the earlier versions.
its just gotten silly to try and keep backwards support for the early versions of the CPUs that have been obsolete for so long.
really, we should have compiler targets for optimizing on the P4 'netburst' CPUs and another for the core processors as they are all pipelined differently. as it turns out, however, the core 2 and core I3/5/7 do pretty well with pentium-II and -III style optimization strategies, as well as, of course, the x86_64 support.
really, we should have compiler targets for optimizing on the P4 'netburst' CPUs and another for the core processors as they are all pipelined differently. as it turns out, however, the core 2 and core I3/5/7 do pretty well with pentium-II and -III style optimization strategies, as well as, of course, the x86_64 support.
gcc does have compiler flags (read up on -march & -mtune) for optimizing to specific families of Intel CPU's. The problem is that the performance improvement of tuning say an i7 to it's family(-march=corei7) vs a generic i686 tune(-march=i686) is minimal (less then 1% in benchmarks I've seen) and not worth the extra complexity of managing entire branches of packages for specific processor families. It makes sense however for the x86 vs x86-64 as there's some pretty fundamental differences there.
At Sat, 16 Jul 2011 22:31:51 -0700 CentOS mailing list centos@centos.org wrote:
On 07/16/11 7:50 PM, david wrote:
If the I386 (or i686, never could figure out why the name change)
I386 was the original 386 CPU, which ran at speeds from 16 to 33Mhz i486 includes a few additional instructions on the 486 processor, and IIRC, ran at speeds from 25 to 100Mhz
i486's included the FPU on-chip -- i386 either had a separate FPU chip or used a kernel-supplied software FPU emulator (yes, 0.xx and 1.xx kernels had the option of a software floating point math support).
i586 is the original pentium, at 60, 66, 90, 100 up to about 133Mhz
AMD made K6's up to 500mhz -- i586 processors
i686 is the pentium pro and pentium-II, -III, -IV and everything newer.
i686 added a few minor new instructions but also has additional memory management functionality missing from the earlier versions.
its just gotten silly to try and keep backwards support for the early versions of the CPUs that have been obsolete for so long.
really, we should have compiler targets for optimizing on the P4 'netburst' CPUs and another for the core processors as they are all pipelined differently. as it turns out, however, the core 2 and core I3/5/7 do pretty well with pentium-II and -III style optimization strategies, as well as, of course, the x86_64 support.
At 10:31 PM 7/16/2011, you wrote:
On 07/16/11 7:50 PM, david wrote:
If the I386 (or i686, never could figure out why the name change)
I386 was the original 386 CPU, which ran at speeds from 16 to 33Mhz i486 includes a few additional instructions on the 486 processor, and IIRC, ran at speeds from 25 to 100Mhz i586 is the original pentium, at 60, 66, 90, 100 up to about 133Mhz i686 is the pentium pro and pentium-II, -III, -IV and everything newer.
i686 added a few minor new instructions but also has additional memory management functionality missing from the earlier versions.
its just gotten silly to try and keep backwards support for the early versions of the CPUs that have been obsolete for so long.
really, we should have compiler targets for optimizing on the P4 'netburst' CPUs and another for the core processors as they are all pipelined differently. as it turns out, however, the core 2 and core I3/5/7 do pretty well with pentium-II and -III style optimization strategies, as well as, of course, the x86_64 support.
-- john r pierce N 37, W 122 santa cruz ca mid-left coast
Folks My initial post was perhaps mis-stated. I don't have any problem with dropping processors before the Pentium class machines (aka I686), my question was only a naming question.
Why are some RPMs named el6.i386, and some with el6.i686. It must make automated package selection algorithms more difficult.
David
david wrote:
At 10:31 PM 7/16/2011, you wrote:
On 07/16/11 7:50 PM, david wrote:
If the I386 (or i686, never could figure out why the name change)
I386 was the original 386 CPU, which ran at speeds from 16 to 33Mhz i486 includes a few additional instructions on the 486 processor, and IIRC, ran at speeds from 25 to 100Mhz i586 is the original pentium, at 60, 66, 90, 100 up to about 133Mhz i686 is the pentium pro and pentium-II, -III, -IV and everything newer.
i686 added a few minor new instructions but also has additional memory management functionality missing from the earlier versions.
its just gotten silly to try and keep backwards support for the early versions of the CPUs that have been obsolete for so long.
really, we should have compiler targets for optimizing on the P4 'netburst' CPUs and another for the core processors as they are all pipelined differently. as it turns out, however, the core 2 and core I3/5/7 do pretty well with pentium-II and -III style optimization strategies, as well as, of course, the x86_64 support.
-- john r pierce N 37, W 122 santa cruz ca mid-left coast
Folks My initial post was perhaps mis-stated. I don't have any problem with dropping processors before the Pentium class machines (aka I686), my question was only a naming question.
Why are some RPMs named el6.i386, and some with el6.i686. It must make automated package selection algorithms more difficult.
Packages are created by large number of various people for number of different distros. i386 marks packages that will run on older CPU's, i686 packages that will run only on PII and newer CPU's. It is simple as that. Changing everything to i686 would only wreck havoc for distros supporting older CPU's. This would be the jest of the (I am sure more complex) matter.
Ljubomir
On Sunday, July 17, 2011 01:31:51 AM John R Pierce wrote:
I386 was the original 386 CPU, which ran at speeds from 16 to 33Mhz i486 includes a few additional instructions on the 486 processor, and IIRC, ran at speeds from 25 to 100Mhz
Super minor correction: 486SX's at 16 and 20 MHz were available..... And I think a 120MHz variation of 486DX4. And then there was AMD's 5x86 at 133MHz. We have a few embedded boards running controllers that are still running 5x86's at 133MHz; about the same speed as a Pentium 75.
i586 is the original pentium, at 60, 66, 90, 100 up to about 133Mhz
233 is the fastest Pentium MMX I've seen. AMD's K5 and K6 series topped out at 500; they're all i586-class procs. AMD's Geode in same series. Cyrix and later VIA C3-series chips go faster, but are still i586-class chips (up to 1GHz or so, maybe faster). 800MHz embedded C3's have been very popular in the embedded space. And this class of chip is what many people would like to run C5 and C6 (and they are beefy enough to run text mode for either of these, really, since they would mostly be used as network devices with no local GUI).
really, we should have compiler targets for optimizing on the P4 'netburst' CPUs and another for the core processors as they are all pipelined differently.
Very very true. Netburst is very different from Pentium M and Core architectures.
as it turns out, however, the core 2 and core I3/5/7 do pretty well with pentium-II and -III style optimization strategies, as well as, of course, the x86_64 support.
Has to do with Core being descended from Pentium M architecture, which is essentially souped-up Pentium III. The history of Pentium M is a fascinating study.
Lamar Owen wrote:
On Sunday, July 17, 2011 01:31:51 AM John R Pierce wrote: Super minor correction: 486SX's at 16 and 20 MHz were available..... And I think a 120MHz variation of 486DX4. And then there was AMD's 5x86 at 133MHz. We have a few embedded boards running controllers that are still running 5x86's at 133MHz; about the same speed as a Pentium 75.
Actually, 120MHz was AMD's baby and they achieved it with overclocking Bus from 33MHz to 40MHz (VLB only?).
david wrote:
Just a thought
If the I386 (or i686, never could figure out why the name change) disk doesn't quite fit on the DVD+, and needs a DVD-, this might put some folks at an inconvenience.
I wonder if the difference between fitting and not fitting is small enough, so that some amount of pruning might make it fit on the DVD+R image. Some ways to prune could be:
CentOS 6.1 i386(mostly for compatibility sake I think) will come out on 2 DVD-s also, that was already announced around a week ago, so that is already settled.
Ljubomir
-
Always Learning -
david -
Drew -
John R Pierce -
Lamar Owen -
Ljubomir Ljubojevic -
Robert Heller