Keeping the fires burning
All this talk of dropping support is very negative. Linux actually supports all kinds of old hardware – it just might need a little coercion.
When 386 support was slated for removal, so too was support for 387 math coprocessor emulation, required by 486SX chips (which lacked the floating point unit of their DX brethren). This was granted a reprieve, since it didn’t really complicate other subsystems like the 386 code did, and there was some hardware still in production that required math emulation. That feature is still around today, so you can see that code is only dropped from the kernel when there is good reason. Just being old is not enough.
Unfortunately kernel support is far from the end of the story. Distros are free to choose the optimisations to build into their packages, and since there’s not a great deal of 20-year-old PC hardware still in operation, most distros now require some modern CPU features. Debian no longer supports what it designates i486 or i586 architectures (the first Pentiums). So the previous two pages won’t really help you if you’re looking to run Linux on hardware from before around 1997. Confusingly, for traditional reasons, Debian and other distros’ 32-bit builds are still denoted i386, even though they won’t work on a 386. It’s actually pretty hard to get mainline Linux going on a 486 – check out the tour de force from a couple of years ago at http://yeokhengmeng. com/2018/01/make-the-486-great-again – but some distros do cater for antique hardware. You can of course compile your own packages for such silicon, using a distro such as Gentoo or Linux from scratch, but you’ll need to set up a cross-compilation environment on a more powerful machine first, since compiling stuff on Bronze Age hardware is just going to end in tears. Incidentally, it hasn’t been possible to compile
Firefox (or any other major web browser) on a 32-bit system for some time – compiling and linking such large applications tends to run up against the 4GB limit sooner or later. Arch Linux 32 provides packages for three different architectures – Pentium 4, i686 and i486 (although most graphical applications aren’t available in the latter). If you want to go really deep, look into compiling a kernel specifically for your hardware – there’s no point having multiprocessor support on a single-core system, after all. You can optimise the compiler for a particular processor family and build the drivers you need straight into the kernel image. You can also take out any modules you don’t need if space is a concern. Again, you’ll probably want to do the actual compiling on a faster, probably 64-bit, system. Setting up a 32-bit chroot or systemd-nspawn container (if you want to be new age about it) is reasonably straightforward – have a Google.
Even on powerful hardware, some users prefer lightweight or even console-based applications. So if you’re prepared to learn some funky keyboard shortcuts and new ways of working, there’s all manner of things you can still run on archaic systems. Consider using a lightweight window manager such as Openbox or i3 (or the Wayland-powered Sway, intended to be a drop-in replacement for i3) instead of a full-blown desktop environment. By this stage it feels silly recommending that people check the downloadable DVD, but Antix is indeed obtainable that way (as well as from its website at https://download.tuxfamily.org/antix/docsantix-19/faq/index.html) and ships with a number of lightweight desktop configurations. The default uses ICEWM together with Rox (which handles desktop icons, if you’re still into that). Without installing anything, it’s possible to switch to Fluxbox or the ultralight JWM instead. It’s possible to demote your window manager to
the status of ‘thing that moves terminal windows around’, or do away with it and run everything at the console (or indeed through the Emacs text editor). The Midnight
Commander file manager is easier to get to grips with than you might think, and once you become accustomed to it, managing files graphically seems somewhat clumsy.
Media in 32 bits
You may have seen Mplayer and other video players have the glorious ability to render movies as ASCII art (even in colour). This isn’t something you’ll want to do on old hardware, as decoding video (and figuring out which character best represents each segment) takes an awful lot of CPU power. However, playing audio through a console application is perfectly feasible. You can play MP3S directly with mpg123, or you can run a TUI (Text User Interface) player such as cmus (https://cmus. github.io) to play all manner of audio files and manage playlists. A setup that has proven very popular is to use
MPD (Music Player Daemon) to act as a server and control that with a frontend such as the catchily titled
ncmpcpp, which can manage your audio library and is extendable via all manner of plugins. MPD also works great on a headless server connected to some nice speakers. You can control it from your home network through desktop frontends, mobile apps (such as
Mpdroid on Android) or a web interface.
We covered the Suckless tools, which include but are not limited to an ultralightweight terminal (St), window manager (Dwm) and even console-based video editors
(Blind) in LXF254. These all have minimal dependencies and use minimal resources, but the learning curve is a little steep if you’re coming from desktop luxury land. Oh, and how could we fail to mention the Javascript-free joys of browsing the web from the console with the likes of Lynx (whose development started in 1992, making it probably the oldest web browser still in use today).
To try a lightweight desktop on LMDE, we’d start with ICEWM, you can install that with:
$ sudo apt install icewm
Log out, and when you log in choose that. In our experiments it used just a little over 200MB of RAM. It might look dated at first, but you’ll find plenty of themes online to jazz it up, and it’s too configurable to discuss in the space remaining. Change to the Infadel2 (sic) theme by right-clicking on the desktop to bring up the menu, and choosing it from the Themes sub-menu. ICEWM provides luxuries that window managers alone don’t, including a dynamic programs menu, system pager, and the ability to shut down without typing anything in. What it does not provide, however, is a friendly tool for changing monitor resolutions, so if you’re stuck at low resolution open up a terminal, query your resolutions and set the desired one with:
$ xrandr -q
$ xrandr -s 1920x1080
You can add this to your startup or make custom menu entries for multiple resolutions of monitors, or configure pretty much anything you like by editing configuration files. It’s a lot of work to configure everything, but the rewards are great. Check the ICEWM FAQ at https://ice-wm.org/faq to get started.
If you want a lightweight distro that comes with a decent out-of-the box setup, in the same vein as Antix, but you have the luxury of a 64-bit system, check out Arch Labs (https://archlabslinux.com) powered by Arch Linux. If you want yet more suggestions for 32-bit machines, check out Bunsenlabs, the distro that inspired it. That’s powered by the Openbox window manager and Debian 9, currently. But a new release is in the works, so keep your eyes peeled. Who knows, maybe we’ll include it on another virtual DVD soon (do I detect a tone of sarcasm here? – Ed).
ENCOUNTERING PROBLEMS “There are other problems you’ll encounter running on old hardware. For a start many of them don’t support booting from USB.”
Those trusty 32-bit CPUS are vulnerable to the speculative execution attacks that have kept on coming since January 2018. These were mitigated (albeit some months later than their 64-bit counterparts) in the kernel, but the associated fixes led to some hard-to-squash bugs. The dearth of 32-bit hardware in the hands of people capable and willing to fix these means that doing this will be the new normal.
A 32-bit system, it is said, may only address 4GB of memory. This would be fine for a machine that’s not doing anything challenging, but would not make for a particularly enjoyable modern desktop experience. Gnome and Chromium with a few tabs open will chew that up in no time, but there are countless lightweight alternatives that better suit such hardware. That 4GB limit is generally something of a misnomer, since most chips and chipsets produced after the millennium (and a few Pentiums from before) ship with the Physical Address Extension (PAE). This allowed larger physical page addresses, meaning that through the wonders of virtual pages, up to 64GB could be used. This comes with the caveat that a single process may only address 4GB. You can see if you’re running into memory trouble or resorting to swap space (also detectable by the sound of hard drives being thrashed) by running:
$ free -h
Pay heed to the old adage “free memory is wasted memory”. Programs will use any free space they can for buffers and cache, and some system monitors don’t report this explicitly. If you can find compatible memory, your motherboard can fit it and your BIOS supports it, then boosting your RAM past 4GB might grant your old machine a new lease of life, although it’s not going to work miracles. PAE support was introduced with Windows XP, but was removed in Service Pack 2 due to driver incompatibilities. Later 32-bit versions of Windows (even though they use PAE) still limit the address space to 4GB (of which you can use about 3.2GB), which is where the myth arose from.
Many distributions now require PAE support to boot. Most processors advertise this feature to the OS (for example in the flags stanza of /proc/cpuinfo), but some do not. Some Pentium-m chips support PAE, but are shy to admit it. In order to use it on such devices, it’s necessary to boot the kernel with the forcepae parameter. You can add this at boot time by pressing e at the GRUB boot menu, or make the change permanent by editing /etc/default/grub, regenerating your GRUB configuration. If you don’t have a Pae-enabled processor there are still options, including Debian (and derivatives such as LMDE and Antix). If you would like (and your processor supports) a Pae-enabled kernel in Debianbased distros, it’s a simple matter of:
$ sudo apt install linux-headers-686-pae linux-image686-pae
Some packages, particularly those related to multimedia and number crunching, greatly benefit from SSE2 (which superseded SSE and MMX) extensions. These were introduced (at the consumer level) with some 32-bit Pentium 4 chips in 2000, but did not feature in AMD chips until the Athlon 64. Not that we cared, but in 2014 Adobe started to require SSE2 for its Flash plugin. All over the world people trying to browse flashy websites on 32-bit Athlon-based hardware were met with messages about a crashed plugin (Didn’t it always
do that? – Ed). Affected users resorted to installing old versions of the plugin, opening them up to who knows what kind of horrors. On some distributions SSE2 is explicitly required, while on others some programs – web browsers in particular – will fail annoyingly without it. Official builds of Chrome and Firefox require SSE2, although some distributions may build the latter without that requirement–who needs hardware acceleration?
There are other problems you’ll encounter running on old hardware. For a start many of them don’t support booting from USB. You can get around this using the Plop Boot Manager, which you can install to a hard drive, CD-ROM or even a floppy, and can then hand over to the bootloader on the USB. You may also run into problems with graphics, even before you get to the desktop. If the screen goes hopelessly blank after the GRUB menu then you have a graphics problem.
Prehistoric pixel pushers
Most distros use a kernel modesetting (KMS) driver to talk to your graphics card (and make the boot sequence high resolution). Support for old graphics cards on Linux is generally good, but there is some weird hardware out there, particularly the hobbled onboard graphics found on laptops and desktops from the millennium, which will force you to boot with the nomodeset parameter. Some of this hardware is supported through out-of-tree drivers, for example the Openchrome driver hopes to bring mainline KMS support the S3/VIA chipsets. For now a userspace driver is available, which for the last four years, has been maintained single handedly by Kevin Brace.
In 2006 VIA stopped providing open source drivers. Curiously, around this time AMD launched its radical open source driver strategy. The old proprietary fglrx (aka Catalyst) driver was phased out in favour of the open source Radeon (and Radeonsi) and later the AMDGPU stack. There’s no supported way of using the Catalyst driver on a modern distro – it requires old kernel and X.org versions. The Radeon driver supports most hardware that used to be handled by Catalyst, and supports cards from as far back as the 7000 series (launched in 2000). Older hardware, such as the nostalgia-inducing ATI Rage 128 (from 1996) still see their drivers updated occasionally by committed enthusiasts. Nvidia at one stage provided an open source (though unpopular) driver for early Geforce devices, but stopped supporting it a decade ago when the reverse-engineered Nouveau driver became suitably mature. In early 2019 Nvidia stopped supporting 32-bit operating systems, so if you’re still using its proprietary driver on a 32-bit machine it will stop working very soon. Help is at hand though. The Nouveau driver works out of the box with an awful lot of legacy (and modern) hardware. And we must credit Nvidia for finally releasing firmware and device specs to help this project.
Switching from the proprietary to the free driver should be quite straightforward. If you installed the drivers through Mint’s Driver Manager or Ubuntu’s Driver tool, then just flip the switch there. Otherwise uninstall the Nvidia drivers using your package manager. Check for any files blacklisting the Nouveau driver in /etc/ modprobe.d, and for good measure create a file there (such as /etc/modprobe.d/blacklist-nvidia)
blacklisting the proprietary driver through the edicts: blacklist nvidia blacklist nvidia-drm blacklist nvidia-modeset
Do write in and let us know how you get on with your old hardware, there’s all kinds of quirks you might run into that we haven’t covered here. Buggy BIOSES (and having to make a FREEDOS disc to update them), bad ACPI implementations (by which trying to suspend your machine will result in a terrible outcome) and, our personal favourite, unreliable clocks, are all challenges that might await you. But we hope they don’t, and that everything works out just fine.