Okay, two questions then... a) If (some) i386 packages are being built with -march=i486 then they (possibly, I do realize there's only like 2 or 3 new instructions) won't run on a 386 anyway, will they? so shouldn't they be called .i486.rpm? b) If i386 is basically no longer used for anything anyway, shouldn't we actually have no .386.rpm packages and instead have .486.rpm for most stuff with .486/586/686/athlon.rpm for kernel/ssl/glibc? c) If redhat isn't supporting anything below a 686 anyway then why don't they switch all .386 packages all the way up to 686? I know the performance gain isn't stellar, but if the packages are not designed for installation on anything < 686 then there's not much point in _not_ compiling for 686 - the binary packages will be the approx same size anyway and will require the same amount of CDspace/bandwidth. I know someone will say that those packages could be used on a non-686 class CPU, but on a non-686 class CPU you don't want to be using a recent distribution anyway, do you? I have a 350MHz Celeron (which is a 686) and it is already way to slow for any desktop/Xwindows applications (Fedora Core 2 on a Celeron 400 + 192MB ram is basically usable with a light window manager [twm], but that's about the limit). So the class of CPU's which aren't 686, but which could use RHEL4/Centos4 are very limited (aren't they?) to only a minimum core set of server applications... Anyway you get my drift... :) Comments? Well Okay, so maybe it wasn't two :) Cheers, MaZe