On Jun 6, 2015 10:06, "Lamar Owen" <lowen at pari.edu> wrote: > > On 06/06/2015 03:38 AM, Toni Spets wrote: >> >> If you think it this way, why bother with the i686 build at all? Your dual core 2010 vintage Intel Atom D510 can run 64-bit CentOS 7 anyway. This is why dropping SSE2 requirement would be benefitical as it would allow running it with a larger amount of x86 CPUs that can't run the 64-bit variation at all. >> > > Older Xeon systems that are non-64bit capable are one set of possible targets. If PAE is disabled, Pentium M is likewise a good target (we're running Windows 7 Pro here on some Dell Latitude D610's with reasonable performance; CentOS would run on these quite well, as they are single-core 2GHz Pentium M with 2GB of RAM and somewhat reasonable ATI X300 video, if PAE isn't required). Of course, NetBurst Xeon is a performance pig, but a non-profit that has an older but high-quality server with NetBurst Xeon in it might not have the discretionary funds to obtain a similar quality system with a more modern and power-efficient CPU; they'll run it until it breaks and it's no longer discretionary to replace it. > > Pentium M on the other hand performs very well at 2GHz. We have a number of D600's, but they are just not quite up to the task of running Win7 reasonably well. That era, 2004 or so, seems to be the break-point for boxes that are still very usable running modern workloads. D600's still make excellent service laptops for things requiring serial ports (like our datum SSU-2000 timeserver with a PRS45A cesium primary refclock). I have a couple of D600's parked at a co-lo just for that sort of troubleshooting purpose where RS-232 is still needed, and another D600 running the software for our Advin Pilot EPROM programmer, which needs a parallel port connection (I did mention specialty hardware before.....). > > The part not addressed in this is getting the 2 main windowing systems to work well in such 'constrained' environments as neither KDE or gnome think such hardware worth dealing with issues on (if it works great if it doesn't tough from previous experience trying to get help). So you are ending up having to customize more and .more to the point it isn't really centos anymore. >> Surveying CentOS 6 users who run the i686 version on non-SSE2 CPUs would also give some sort of indication how many potential users are going to be left out and would need to change their enterprise grade distribution to something else when EOL hits. > > > I'm still running a 32-bit CentOS 5 install due to some proprietary software that is not available yet in a 64-bit form. Keeping up to date with security fixes while running this software will become increasingly difficult, but when a hardware vendor doesn't or didn't provide 64-bit driver modules what exactly are you supposed to do for specialized hardware that is expected to be in production for 15 years? (Yes, 15 years, per the grant proposal language.....) > > >> >> My specific use case isn't really worth CentOS 7. I don't think I would ever *really* run anything useful on a 12 year old laptop, it was just the only x86 system I still have around. The CPU generation itself, however, isn't completely useless for some other tasks. > > > I'm finding that laptops from the 2004-2006 era are really robust and seem to continue to just work and do their job sufficiently well to where my employer, a 501(c)(3) not-for-profit public foundation, is having difficulty getting donations of anything dual-core or better, and funding just isn't there yet to roll in newer stuff. So the dozen or so D610's we have running Windows 7 get heavy use, and our few Core Duo Dell Inspiron 640M's and 9400's are still workhorses. Hmph, I just last fall upgraded from a Dell D830 as my primary laptop, and I still use the D830/M4300's I have as CentOS 7 machines that are quite reasonable performers. I'd love to get a dozen or two D830/M4300's donated, as long as they still have good video or are Intel video D830s. > > Most end users don't need anything more powerful than a Core 2 Duo T8300 or similar for most tasks. > > I'll end this post with the following excerpts from a couple of still-in-production machines just to give an indication of how old things can really get in production in linux-land: one here, and one at a client, both of which are locked at the versions indicated due to various issues, mostly having to do with hardware support (no, neither of them are directly exposed to the internet, and, yes, the client knows how badly they need to upgrade, as do we.... but, both machines are doing their respective jobs, doing them well, and in these particular cases the time won't be funded to upgrade until they actually break...): > > +++++++++++++++++++ > [root at webcam4 root]# uname -rsvp > Linux 2.4.22-1.2129.nptl_24.rhfc1.at #1 Fri Dec 12 20:11:09 EST 2003 i586 > [root at webcam4 root]# cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family : 5 > model : 8 > model name : AMD-K6(tm) 3D processor > stepping : 12 > cpu MHz : 300.694 > cache size : 64 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr > bogomips : 599.65 > > [root at webcam4 root]# cat /etc/redhat-release > Fedora Core release 1 (Yarrow) > [root at webcam4 root]# > +++++++++++++++++++ > [lowen at intra1 lowen]$ uname -rsvp > Linux 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 unknown > [lowen at intra1 lowen]$ cat /proc/cpuinfo > processor : 0 > cpu : 586 > model : AMD-K6(tm) 3D processor > vendor_id : AuthenticAMD > stepping : M > fdiv_bug : no > hlt_bug : no > f00f_bug : no > fpu : yes > fpu_exception : yes > cpuid : yes > wp : yes > flags : fpu vme de pse tsc msr mce cx8 syscr pge mmx 3dnow > bogomips : 999.42 > [lowen at intra1 lowen]$ cat /etc/redhat-release > Red Hat Linux release 5.2 (Apollo) > [lowen at intra1 lowen]$ > +++++++++++++++++++ > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150606/496a5dca/attachment-0008.html>