> Bravo for not throwing out usable old hardware! Looks like some D-Link DIR320 router box outperforms them, but it's just too much trouble to use that die-hard-shinked distros built for them, run through hassle of reflashing etc. Aha, and not being able to seamlessly upgrade them to a decent box if needed. > (Sorry, just had to go > there--I collect old computers like candy. Except I don't eat them. > But I digress. Offtopic: dual Socket8 PentiumPro box with 8 SIMM slots populated to get 128MB RAM, running CentOS 5 right here. Had to retire a dual Pentium(Original) just because of the troubles we're talking here about. On topic: It's usually too much trouble to run an old box. Too much to remember, find an old manual online or play with jumpers. SIMMs of more than 4MB per stick (to get 32MB with 4 slots, you need 8M per stick) are 'rare' (and all SIMMs are rare), the DIMM requirements are hard to satisfy (single bank - otherwise seeing half capacity, sometimes extra rare 5V DIMMs needed). SIMMs ABSOLUTELY DO NEED a memtest before the machine goes to production. Usually a HDD header is really 40pin (not 39pin like modern) - key pin is to be cut out. Or you need an old 40wire IDE cable. The machine has problems even with 40GB HDD's (32GB limit). Old HDD that came with the box also does need a night of MHDD or Victoria. And finally - you spent two to three hours plus a night of memory and disk testing. And you get what? Reliability is low even with a night of testing. Worn out bearings on CPU cooler require a new cooler which costs (may be) more than the box (especially if the box is free). 32MB SIMM memory leaves nearly nothing for the disk cache - the box is slow. You can't upgrade it easily via yum - it needs 64MB+. Et cetera. Once we had lots of them, but I won't seek for one If needed. For me a Pentium-II box with ATX PSU in ATX case (thus semi-easily upgradeable), DIMM slots is a minimum now. What usage scenarios left? 1)Hardware hackers loving old hardware and willing to spend their time to run it; 2)Some countries having no money or access to new hardware; 3)Embedded, industrial and similar specials; Do we really need it after all? There are doubts. > I notice mesa is in there--according to the wiki page, the mesa > package contains cmov instructions, so it'll have to be rebuilt too. > I'll play around with that later today in mock and see what happens. I don't remember why it was rebuilt, but according to: http://mirror.centos.org/centos-5/5.6/os/i386/CentOS/ ... mesa-libGL-6.5.1-7.8.el5.i386.rpm 26-Apr-2010 19:59 9.6M ... It's built with i386 arch tag so it shouldn't need rebuild. > Yep! That's exactly what I've been doing. I set up a lightweight > "base" system kickstart that I can use over PXE to quickly install a > thin system (while the hard drive is in the i686 system) in about five > minutes. Even less if a script does a: 1)fdisk on a target drive 2)mkfs.ext3 3)mount 4)cp -aR /installed/and/ready/filesystem/converted/to/i586/already /on/a/formatted/hdd/mount 5)grub-install > Then I install the kernel, downgrade packages, and slap it in > the test box. It takes about 20 minutes to set up, maybe 30 if I'm > having a bad day. If hardware is alive and in a box already ;-) > I'll probably need to trim the kickstart down a > little more, but it works like a charm. I was doing 'rpm -e' until I got something like 730MB. Was hard to go further. Minimal install gives you various crap like irda-tools for example. Kudzu depends on a haldaemon. The haldaemon depends on dbus. The latter two bring about 50MB of unneeded libs with them AFAIR. But I like kudzu. There's a lvm2-monitor from lvm2 package. I don't need one, but mkinitrd depends on it and we need mkinitrd to update kernels. You could rip sendmail, but you'd lose LSB compliance. And remember, it's a wrong way. This way we'd end up building our own, another Linux distro for firewalls. But we're here because of upstream compliance and upgradeability to a more decent box if need arises WITHOUT ANY MIGRATION/REINSTALL. > Building the i586 kernel is probably the most time consuming bit of > the whole process, but once you get it to build once you don't need to > do it again, baring security updates. Even then, it seems it's a > fairly simple process. Buildscript exists somewhere, but I couldn't find it yesterday. Write a patch for a rpm SPEC file to do necessary things to kernel tree like copying i686 .config to .i586, changing target CPU to -M586 etc. 1)wget a_new_kernel_src.rpm 2)rpm -i 3)patch -pX /on/a/rpm/SPEC/file </to/include/our/patch 4)rpmbuild wait until a gazillion of individual patches are applied (offtopic - this time I won't be against RHEL6 prepared-and-intergrated kernel source tree) 5)copy a built RPMs where needed 6)rebuild repo metadata On a lightly loaded server (4-core Q6600, SCSI disk subsystem) it doesn't take enormous time. > Memory is a problem, definitely. My test machine has 76MB of free RAM. Not really. Try to get s 'Super7' motherboard with VIA chipset. AT and ATX supply, can run AMD K6-2 and (some of them) K6-3, can take more or less standard DIMMs (2 slots!), UDMA33, AGP, USB1.1 header. > (If I were unlazy enough to put in a discrete video card, that would > go up to 80MB). Integrated video is a bad idea IMHO. That time a memory bandwidth was very limited. And an intergated video card uses it a lot. > It will run X. Jornada 720 will run X :-) Funny project by the way. It's a pity I don't like cross-compiling. > Forget Firefox. ;) It takes 650MB on my current desktop. Why so much? But (to compare) I've seen (on a windoze machine) a Google Chrome with 11 tabs open taking 1100MB. Nobody seems to care. They install 4GB just because it's cool. Then run 32bit OS while asking stupid questions like 'why it doesn't see my full 4gig of ram' but NOT asking 'why I need 4gig of ram' in the first time. > The laptop might perform better--it has a > whopping 192MB (!) of RAM for an AMD K6 400Mhz. IIRC, it's running > Debian with XFCE right now, so it's usable. No Firefox anyway. > > P.S. For happy owners for IBM/Cyrix CPUs. They carry the necessary > > instructions for an i686 kernel to boot successfully AFAIR. I was > > surprised. It's a pity they run too hot to be reasonably used. > > Really? That's interesting. I have an IBM 6x86 (PR 150) I can plug > into my test box. I'll have to play around with that. I had a box with one. I've downgraded the kernel and OpenSSL, set it up and it was running for half a year. Then the fan failed and the CPU overheated - the system hanged. I decided to replace the one with Pentium-166 - the could run hot but *passive*. The box would boot kernel and hang somewhere after 'mounting root'. I almost broke my head seeking for a problem and found UNdowngraded glibc*.i686. Later I set up a test box for that CPU. It booted a stock i686 kernel. > I have a lot more CPUs than motherboards. I gave them away to children. Couldn't find a better use for a bugged P-75's > On 6/5/11, Karanbir Singh <mail-lists at karan.org> wrote: > > [snip] > > The hard part is > > just identifying where the resources are being used and what is the > > minimum we want to deliver for. I don't think 128 or even 256M of ram is > > an unreasonable minimum. Atleast for step-1. It would take ages to install anyway. So no one would use it anyway. Then why fixing? > I don't know what "modern" i586 systems have (VIA, etc), but I do know > that a lot of the old systems have trouble breaching the 64MB barrier. 32MB SIMMs are very rare. And with (rare) 16MB SIMMs you can get 64MB. Right. > My test box came with 16MB of RAM; by some miracle, I had a few SIMMs > in the big tub of parts under the bed (memory from my *486sx* I think) > and I bumped it up to 80MB total. 2 sticks of 32MB each from 486sx? Can't believe it! 4MB it much more plausible. > As Dmitry mentioned, it's great for > a filesever/router. Even a simple static web server if you wanted to > go there--but don't use Apache, use something like Lighttpd instead. Typical setup is: 1)Firewall,NAT 2)Squid with very small RAM cache for www filtering 3)dnsmasq for DHCP server and DNS relay (could do TFTP too!) 4)Samba for WINS server and to solve 'master browser' issues. 5)ejabberd jabber server for an internal chat and remote support 6)openvpn for remote support 7)quagga also for remote support 32MB, 2 NICs, about 16MB swapped. Everyone's happy. > Iirc, the memory minimum for the text-mode installer is 64MB. On a CentOS 5? AFAIR it's 128MB. Anyway I won't install directly on an old box. Best regards, Dmitry Mikhailov