The minimum requirements for a portable OS on 32 bit hardware really doesn't need to be anything more than:
* 32 bit CPU
* relatively recent toolchain support
* MMU
* memory, storage, I/O
In the last couple of decades, we've added as a requirement:
* atomic operations
The i80386 didn't have atomic operations, so after gcc 4.1.2, the decision was made to drop i80386 support from gcc. Dropping i80386 from Linux simplified MP code because of the lack of these instructions.
But other than these requirements, what does the i80486 processor not do that newer processors do? People who don't know any better like to talk about the amount of maintenance and testing that's required to support an older processor, but I think most of those people are either repeating old tropes or are misattributing issues. Sure, cleaning up pre-PCI code is one thing, but attributing that to the i80486 is a little misleading.
Do people really sit around and worry about whether their code will compile and run on SuperH, for instance? Heck, no. So does that mean we can't have a modern OS running on SuperH systems without all this testing and maintenance? Well, maybe this "maintenance" is a bit of a myth, because not only do we have a modern OS, but we have many thousands of open source programs that compile and run on SuperH, even without their authors necessarily knowing that SuperH even exists.
My point is that there may be good reasons for a commercial focused kernel / OS to no longer support older CPUs, but let's not buy in to the handwavy BS they use to try to justify the changes. They can be honest and just say they want to clean up and remove things that don't have many users.
sillywalk · 51m ago
> what does the i80486 processor not do that newer processors do
TSC (time stamp counter) and CX8 (CMPXCHG8B) hardware support"[0][1]
I don't know what these processor features actually do. Also from [0] it looks like it is also removing the floating point emulation code for CPUs without hardware floating point support e.g. 486-SX
My first computer was a Gateway2000 486/DX 33MHz. I think it was the same one that Linus developed on. It had a programmable keyboard, and a 14.4 modem. You had to enter the video card clock timings manually to run X.
I installed the SLS linux distribution on about 50 3.5 inch floppy disks. I think disk 33 was corrupt. Programming was such an adventure back then. I miss those days.
wormius · 4h ago
Haha i had a 486/dx2-66 laptop and my first try using linux was in 1997 with Debian Bo, IIRC. Downloading over 28.8 modem (maybe it was 56k at that point?) took a LOOOOOONG time, and then trying to get XFree86 to work was no luck with that chipset, even thought it was an IBM computer. It didn't help that the only source of info was the computer itself so getting online in text mode with a usenet client to ask questions and then try to reboot and fail and getting back online etc.
It's amazing how far we've come with video drivers.
sound drivers on the other hand.
os2warpman · 6h ago
While the kernel supports 486, we need to be honest with ourselves.
Anything older than a Pentium II/III based on the 440-series platform is "supported" not "Supported (green checkmark emoji)".
On an actual, physical i486 systems, you run into so many problems that it is unusable.
Even on embedded systems where a 486 core was thrown into a SoC and "modern" I/O was bolted on you often spend more time troubleshooting problems than you would spend moving the entire product to a newer architecture.
terinjokes · 4h ago
I just reinstalled Gentoo this past weekend on an IBM ThinkPad with a Pentium 4/M and 256MiB of RAM, and even there it's probably "supported" not "Supported (green checkmark emoji)".
Most of Linux worked, to it's credit, though I needed to tweak libata for some IDE controller quirks presumably lost in the PATA driver transition in 2.6.20. VTs worked fine and KMSCON worked well, once I loaded the radeonfb driver in initrd.
Where it noticibly falls apart is trying to being up X11, as the driver stack in X11 and Mesa have bitrotten (and in Mesa's case, removed, and no one is looking at mesa-amber from what I understand). A lightweight tiling manager and urxvt was enough for it to crash the whole system.
anthk · 3h ago
NetBSD has a better bundled X.org for legacy systems; the modular one it's for modern ones.
snovymgodym · 4h ago
Is there much use of 32-bit only x86 hardware in the wild anymore? Genuinely curious, I wouldn't be surprised if there was since it was so ubiquitous for a decade or two.
anthk · 3h ago
- Atom n270 netbooks, HN works great under links -g
- Raspberry PI's
- Some RISC-v boards
- Zillions of embedded systems
- Legacy smartphones
rhelz · 5h ago
Ah the good old days. I remember one of my computer architecture/compiler professors at Purdue chiding us for trashing Intel, pointing out that the 486 was quite comparable in performance to the snazzy new RISCs which were in fashion.
anthk · 3h ago
Bye ao486 support then. There's NetBSD at least; and the future Hyperbola BSD, among FreeDOS. Altough if you want something close to Unix' philosphy, with LIFO like pipes but with words, get a Modern FreeDOS Forth for a 486.
* 32 bit CPU
* relatively recent toolchain support
* MMU
* memory, storage, I/O
In the last couple of decades, we've added as a requirement:
* atomic operations
The i80386 didn't have atomic operations, so after gcc 4.1.2, the decision was made to drop i80386 support from gcc. Dropping i80386 from Linux simplified MP code because of the lack of these instructions.
But other than these requirements, what does the i80486 processor not do that newer processors do? People who don't know any better like to talk about the amount of maintenance and testing that's required to support an older processor, but I think most of those people are either repeating old tropes or are misattributing issues. Sure, cleaning up pre-PCI code is one thing, but attributing that to the i80486 is a little misleading.
Do people really sit around and worry about whether their code will compile and run on SuperH, for instance? Heck, no. So does that mean we can't have a modern OS running on SuperH systems without all this testing and maintenance? Well, maybe this "maintenance" is a bit of a myth, because not only do we have a modern OS, but we have many thousands of open source programs that compile and run on SuperH, even without their authors necessarily knowing that SuperH even exists.
My point is that there may be good reasons for a commercial focused kernel / OS to no longer support older CPUs, but let's not buy in to the handwavy BS they use to try to justify the changes. They can be honest and just say they want to clean up and remove things that don't have many users.
TSC (time stamp counter) and CX8 (CMPXCHG8B) hardware support"[0][1]
I don't know what these processor features actually do. Also from [0] it looks like it is also removing the floating point emulation code for CPUs without hardware floating point support e.g. 486-SX
[0] https://lore.kernel.org/lkml/20250425084216.3913608-1-mingo@...
[1] https://www.phoronix.com/news/Linux-RFC-Remove-i486-Early-58...
I installed the SLS linux distribution on about 50 3.5 inch floppy disks. I think disk 33 was corrupt. Programming was such an adventure back then. I miss those days.
It's amazing how far we've come with video drivers.
sound drivers on the other hand.
Anything older than a Pentium II/III based on the 440-series platform is "supported" not "Supported (green checkmark emoji)".
On an actual, physical i486 systems, you run into so many problems that it is unusable.
Even on embedded systems where a 486 core was thrown into a SoC and "modern" I/O was bolted on you often spend more time troubleshooting problems than you would spend moving the entire product to a newer architecture.
Most of Linux worked, to it's credit, though I needed to tweak libata for some IDE controller quirks presumably lost in the PATA driver transition in 2.6.20. VTs worked fine and KMSCON worked well, once I loaded the radeonfb driver in initrd.
Where it noticibly falls apart is trying to being up X11, as the driver stack in X11 and Mesa have bitrotten (and in Mesa's case, removed, and no one is looking at mesa-amber from what I understand). A lightweight tiling manager and urxvt was enough for it to crash the whole system.
- Raspberry PI's
- Some RISC-v boards
- Zillions of embedded systems
- Legacy smartphones