[SOLVED] cpu optimisations and slackware - Any '486 users?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
You can stuff a very functional server machine and even a trimmed-down desktop in 2 GB of hard disk. Look for the various threads on "small slackware" on this forum.
Eric
Indeed
Quote:
Originally Posted by df
/dev/root ext4 7.4G 2.4G 4.6G 35% /
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
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.
...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.
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:
Quote:
Originally Posted by ls -al /mnt/slackware/mirror/slackware/l/slang1-1.4.9-i486-1.tx*
We have all forgotten the bios hard disk limitations of the time.
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.
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.
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.
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.
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.
It's just a shame to buy an AthlonXP because it's so much better than a Pentium, and then shackle yourself to the limits of the pentium's forerunner. Worth changing distribution for? Well, I'm thinking about it. Particularly as the AthlonXP begins to show it's age, it's nice to liberate it a little more.
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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.