On Thu, 12 Dec 2002, Tesla 13 wrote: > Hello John, > > >What on earth do you hope to gain? > > Even if I don't gain anything, I just don't want my binaries to run on a > bloody 386 SX. Period. If procinfo shows 91% idle (as it does on my Athlon), then how much is there to gain? 10% of 9% is bugger-all. > > >It will takes days, maybe weeks on a single machine. > > gcc + glibc + kernel takes a mere 3 hours on my system to compile (2.66 GHz > P4 OCed to 3.0, monolithic kernel). The list of RPM packages I run is aroung > 200. So the whole process does not take more than 10-12 hours on my machine > to complete. Did you build OpenOffice.org? XFree takes a while too. Much more than glibc, gcc & the kernel. > > >I don't know of any such documentation, it's years since I last saw > >someone suggest it. > > Does this mean no one is using a P4 or are they moving their binaries > between their P4 systems and 386 SX'es? Linux distros work almost on > anything and I doubt this is suitable for the newer generation of CPUs. I think that, on reflection, most people reckon it's a waste of time. > > It really does not matter. > > >I don't think it will be as reliable as Red Hat Linux either, > >because you will be exercising some of the very newest features of gcc. > > The system looks stable and performs real fast. Never experienced any > trouble. However, I need 2nd opinion in case I missed something. In my experience, that might mean that there's a problem that hasn't bitten you yet. If you were on the Limbo list, you would have discovered that some problems bite some folk and not others. Many years ago, I had a program that worked well under test conditions (including stress testing) and fell about all over the place when real users got at it. A major Australian bank had a similar problem in the late 80s. It introduced the latest version of IMS and lost its ATM network for two days. It wasn't for the lack of testing, it was just that they had now way (even in retrospect) of producing the problems that occurred in the live environment in testing. _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list
