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.- Raspberry PI's
- Some RISC-v boards
- Zillions of embedded systems
- Legacy smartphones
* 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'm afraid saying it is missing a feature, but unable to say whether that feature is required for anything is what the gpp is complaining about and is an excuse not to support it.
Now if the combobulator transactions with the injunction function to provide the higher level of precision required, then that could be an argument to deprecate the architecture.
So dropping the i80386 wasn't necessary, and saying it was because of the lack of atomic instructions was an excuse, because the real reason was that they didn't want to keep i80386 atomics around.
* People willing to do maintenance (testing, debugging, upstreaming patches etc).
For a many-platform OS like Linux it's probably not that hard to keep an arch supported once the plumbing is in place. It's not like there's new 486 based IC's coming out regularly. But still... someone's gotta do it.
I suspect much "supported" was already in the form of: platform-specific drivers in-tree, arch support in place, all that stuff compiled, done. But at the same time, if you'd take result & run it on real 486 hardware, expect loads of issues.
Software in source format tends to bitrot after testing/use on physical hardware goes away. Binary, less so (but of course other issues there).
So, basicaly, you can't have serious operating system before that?
as always: imho. (!) ...
i remember already many years ago - read: 10+ years - very "common" linux distributions installation medias where provided with kernels which complained about missing the so called "CMOV" instruction - like debian / ubuntu etc. ...
yes, it was easily possible to use either "specialized" distributions or even compile a kernel yourself to run on those CPUs < pentium pro/II/III + ...
which meant: everything up to including pentium (MMX) and AMD K5 ...
i'm not sure: did AMD K6 have those!? i don't remember, wikipedia knows more ... :)
personally i don't care much about hardware which is not able to boot a "vanilla" debian installation medium for its respective hardware-architecture.
just my 0.02€
os2warpman•9mo ago
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•9mo ago
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•9mo ago
terinjokes•8mo ago
In any case, X worked reasonably well; 31 fps in glxgears with llvmpipe. Still a bit too slow for something like alacritty, but at least using herbstluftwm wasn't painful.