The Linux Kernel May Finally Phase Out Intel i486 CPU Support

[caligula]

You should stop trolling and stop cargoculting bloat and this proprietary software mindset of planned and short term obsolescence into free software. Please, just uninstall Linux and go back to Windows. This kind of mindset is not welcome here. 486 is well within capability to host current-day Apache webserver and even do real-time playback of mp3 encoded media. As proven here https://www.youtube.com/watch?v=4qSziR6sD8Q

80486 era software used to take advantage of sound acceleration hardware. E.g. wavetable synthesis. Yea, a 100 Mhz 486 can decode MP3, but does it need to? No. Many Adlib and MIDI compositions actually sound pretty decent. An excellent example is the soundtrack of the original UFO/XCOM.

[caligula]

The Geode LX was heavily used in network motherboards (see also PC Engines Alix) and in the OLPC XO laptop. Geode LX had various levels of features so one would have to precisely check if they will be unsupported or not.

FWIW, both Alix and APU1 are already EOL. OLPC perhaps started the trend of ultraportables, but has been a failure right from its launch.

[rmoog]

80486 era software used to take advantage of sound acceleration hardware. E.g. wavetable synthesis. Yea, a 100 Mhz 486 can decode MP3, but does it need to? No. Many Adlib and MIDI compositions actually sound pretty decent. An excellent example is the soundtrack of the original UFO/XCOM.

I have more or less what you describe. The machine in question is an arcade system for showcasing DOS-era games, but it does have a Gentoo system on another partition that I regularly maintain. The purpose of that Gentoo in there is to provide a much more capable system than FreeDOS to do 2 tasks:
1. Download stuff into the computer, because that cannot be done on FreeDOS due to various issues with hardware, drivers and FreeDOS TCP/IP stack.
2. Test if everything is working correctly - the 2 Pentium 3s (yes, this is a dual socket setup), the huge RAM, CDROM, Voodoo framebuffer, AWE wavetable, DRAM-backed soundfonts, temperatures to see if the system doesn't overheat under full load (yes, Coppermine-era motherboards do have thermometers supported by Linux as crazy as it sounds), ISA sound playback, everything.

I can't shake the feeling that my system is going to get axed one day as well and I'm understandably not happy about Linux' scope of support slowly creeping towards that point.

[jabl]

I recall my first Linux box was a 486dx2-66. Back then the CPU was actually sort-of ok. And yes, it could play an mp3, though mpg123 took something like 80% of the CPU time. The bigger problem was that it had only 8 MB RAM, after I launched Xfree86 and an xterm there was very little left. Netscape Navigator was barely usable due to heavy swapping. My next Linux box was a PPRO200 with a whopping 64 MB RAM, and Linux flew on that machine.

That being said, I'm sure a modern Linux kernel wouldn't be happy with that little RAM.

[kneekoo]

And to be honest, i don't think there is any reason to keep supporting anything 32bit anymore. Kernel 6.1 should be more than enough to support any 32bit-only hardware at this point. Being LTS means it will be getting security bug fixes for quite some time, and 32bit cpus are ancient and weak for modern distros anyway. But of course plenty of crybabies will scream if any developer suggests such a thing this soon, even though only a tiny niche of Linux users still use 32 bit distros....

All existing hardware has "32-bit CPUs" simply because they can run 32-bit software. RAM-limited PCs are better off with 32-bit software, to save RAM. I just checked Amazon.com and they have over 2000 results (in late 2022!) for laptops with 2GB or 4GB RAM - many of them with ChromeOS or Windows 10/11, so they're not ancient hardware. Many, if not all, don't have a RAM upgrade option. It's downright insulting towards consumers, but they're cheap enough that people still buy them.

So stop acting like a smartass and rather throw crap at PC manufacturers for perpetuating this nonsense. Go tell a kid to ask his parents to buy a new laptop with more RAM, and see how that works. It's easier to just install 32-bit software to lower the RAM usage. It won't run as fast as 64-bit software, but it will run well enough. It won't run every browser, but Firefox and Chromium still have 32-bit builds.

[rmoog]

I recall my first Linux box was a 486dx2-66. Back then the CPU was actually sort-of ok. And yes, it could play an mp3, though mpg123 took something like 80% of the CPU time. The bigger problem was that it had only 8 MB RAM, after I launched Xfree86 and an xterm there was very little left. Netscape Navigator was barely usable due to heavy swapping. My next Linux box was a PPRO200 with a whopping 64 MB RAM, and Linux flew on that machine.

That being said, I'm sure a modern Linux kernel wouldn't be happy with that little RAM.

8MB RAM will not cut it because you won't be able to even decompress and load the kernel into RAM, unless you go to really extreme measures and cut down the config. The least I could get is 64MB RAM VM to boot kernel 4.x.

[abufrejoval]

Didn't read all the posts here to see if that point was already mentioned: most of the 80486 CPUs still running today seem to be the management engines inside the first generation Core CPUs. And those were supposed to run Minix, which should still be a good option for anyone who can't afford the bloat of current systems.

I started running Microport Unix on my 80286 and even my 386 and 486 systems were more likely to run a System V variant than Linux or 386BSD. Or they were running a µ-kernel OS that took a lot of inspiration from QNX and was developed at GMD/Frauhofer in Germany (unfortunately closed source, otherwise Linux would have never happened). I ported X11R4 to a TIGA 34020 based TIGA EISA bus graphics card at the time, too.

Mostly I remember how fast they felt compared to say a Z80 system or a PDP11/34 but these days I can't see how anything that can't manage a true color 4k screen with a good browser, office or editor performance is worth keeping around. A PI4 is already stuggling there, a Jetson Nano manages, a Jasper Lake Atom does rather well at near €100 for a bare bone.

I'd dare say that a kernel rebuild on an 80486 takes longer than working minimum wage to pay for the Atom.

I think I ran VMware on a later 80486, one that supported the 486SL System Management Mode... that was pretty cool, because I'd secretly always wished I could afford a VM/370 under my desk.

I see tons of sentimental value, nobody actually testing if such a system even boots. If you're not sure the code can be relied on to be functional, it should be retired.

[uxmkt]

Does anyone have an idea how sinfully slow those 486's are by a modern standards? I mean, for real?!

My i686-class museum piece has around 300 points as per the Passmark. A Ryzen 7950X of today has 64000ish(!) points. And yet, the vintage PC only feels like 1/10 of the performance of something modern. And when I look at the single-thread rating at Passmark, it suddenly comes all together.

[uxmkt]

Here's a video from 2018 where some madman was running gentoo on a 486. 32 seconds to boot the kernel, 11 minutes to run through init.

14s for the kernel. The rest is spent in "Caching [some nonsense]". Which feels utterly stupid. Either a cache (for whatever) should be built whenever there was a change (e.g. font list, normally done after a round of package updates have completed), or, when such cache is not persistent, should gradually fill as items get used and added to it (like the in-kernel buffer/inode cache does). But having an explicit cache-making stage at boot is just meh.

[sinepgib]

What do you mean "finally"? Let me guess. Rust doesn't run on i486? Who would've thought a language that requires 3 compilers (GCC to make LLVM, LLVM and GCC to make Clang, and LLVM with Clang to finally beget Rust) to stand on its own legs can't run on a humble i486. I'm utterly shocked.

1. Rust is self-hosted.
2. While I don't think anybody ever tried running binaries built by Rust on i486, cross-compiling solves the "compiler can't run on a humble i486" problem.
3. The proposal to drop i486 has nothing to do with Rust.