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.
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.
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.
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.
> 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
> I don't know what these processor features actually do.
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.
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.
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.
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.
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.
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.
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.
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.
hello,
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€
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.
> 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
[0] https://lore.kernel.org/lkml/20250425084216.3913608-1-mingo@...
[1] https://www.phoronix.com/news/Linux-RFC-Remove-i486-Early-58...
You're making my point for me, in a roundabout way. These are handwavy excuses, not valid reasons.
Those are excuses, in the same way atomics weren't "needed"; cmpxchg is a hardware locked operation that's quite important for lockless algorithms.
> I don't know what these processor features actually do.
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.
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.
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.
NetBSD has a better bundled X.org for legacy systems; the modular one it's for modern ones.
> CMPXCHG8B
So, basicaly, you can't have serious operating system before that?
The operating systems prior were not known for their reliable preemptive multithreading of uncooperative tasks, no.
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.
- Atom n270 netbooks, HN works great under links -g
- Raspberry PI's
- Some RISC-v boards
- Zillions of embedded systems
- Legacy smartphones
32 bit sure but I think you overlooked the x86 part! Only one of those is that, and a sliver of credit for embedded, but that's gotta be rare.
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.
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.
Of course it runs NetBSD! :D