With respect, I think we're all missing the point. My test was not conclusive. But it is clear that slackware is no longer aimed at 486 machines (If they exist) so it's foolish to retain the backward compatibility. That, I think, is the material point.

On hard disks: A booted Linux doesn't need bios, so linux can live above the 1023 cylinder limit. Booting requires the bios to be able to find the first sector in the boot drive, and this gets complicated with an incompatible drive, particularly one running chs. If someone has to replace the hard drive, they're already foolish to retain the 486 or 586 pc.

For an old box (e.g. the 486 firewall), systems like kevux, damnsmallinux which use uclibc suggest themselves. Linuxfromscratch suggests itself, now being automated to build, light clean and configurable.

On recompiling the whole distro: don't, if you want my advice. But make slackware-13.2 (which will have fresh versions) i686, and clean the ancient crud out of the kernel. This user's advice.

A good test if someone wants to go at it, is to boot an idle box on a i486 kernel, make some kernel using
time make
then boot on an i686 kernel similarly set up and make the exact same kernel in the same way. I haven't heard anyone say i486 will be faster. I'm not demanding that i686 will be faster. I just think it might be.

Indeed
Thats my fully functional 32bit KDE installation. I havent got split system partitions. In an XFCE installation, i could also make room for swap in 2GB as IIRC those weight 1.6 to 1.8 GB

...but that would require recompiling the whole distro...not all packages are recompiled between each release -- there are many packages that just remain still. I know WindowMaker floated along for some time (before its recent return to activity) without being able to be compiled on any modern box.

The cruft was cleaned out with Slackware 13. All of the packages were compiled for the new 64-bit version, and the 32-bit ones were recompiled at the same time.

Not all 32bit ones were recompiled, not even with the 13.0 --> 13.1 huge jibjpeg and libpng rebuild.
eg:

With respect, that's just you. You've also apparently forgotten the trivial solution: create a small primary partition for /boot at the beginning of the disk when the Slackware installer invites you to perform your partitioning.

Also, having fun with find. All packages that where made more than 1000 days ago says:

Please keep in mind that compilation for the 486 target is not just to make Slackware run on an actual i486 processor.

There are many CPU types that are not supported by the 686 target, one of those being the Via C3 processor which powers the Mini-ITX board inside my media box (running Slackware of course). And that computer is not limited at all in its hard drive configuration - it sports an internal 80 GB disk and a big external one. It is a natural platform for Slackware to be installed on and I would not do myself a favour by rebuilding the next Slackware for the 686 target.

Eric

Also packages still compiled for i386!

I was remembering the anguished threads on old forums where lilo wouldn't boot and everything was correct. Then people would realise it wasn't finding sector zero on the disk. That was the bit that stuck. What you say about a /boot partition is correct - once you can find sector zero on it. That was inclined to be the stumbling block.

I also am running an Athlon on one of my main machines and I performed some benchmarks with BZIP2 compiled for the i486, i586, and i686 architecture (but mtune'd to i686). I was working with Slackware 13.1 on a 2.6.35 kernel compiled for i686. I used the stock i486 stdlib, stdio, and cstring (dependencies of BZIP2) -- so admittedly my results do not fully reflect the benefits accrued from switching the entirety of Slackware over to a newer architecture, but it does tend to corroborate that the gains are minimal.

uname -a
Linux tesla 2.6.35-smp #1 Tue Aug 3 13:36:12 EDT 2010 i686 AMD Athlon(tm) Processor AuthenticAMD GNU/Linux

BZIPPING a 150Mb file (repeated 3 times and averaged)
i486
user 0m2.755s
sys 3m56.937s
total 3m59.692s (100%)

i586
user 0m14.368s
sys 3m42.086s
total 3m56.454s (101.4%)

i686
user 0m14.096s
sys 3m42.145s
total 3m56.241s (101.5%)

I have in the past benchmarked some media applications such as FFMPEG and MPlayer and noticed improvements of about 10% using i686 architecture; but then I always compile those applications and libraries from source anyway (and recommend doing so to anyone making extensive use of them).

Try 64-bit.