Technically not. It can run it. Was slow? Yes, but my Am386DX40 keep working fine from 1991 to 1996. Running DR-DOS 6, MS-DOS 6.11, Windows 3.1 and finally Windows 95. And, of course, I could play DooM 2 on it. At some point, I got a math copro. Finally, my father upgraded the machine with an AMD 486DX5 133MHz.
It was two generations old at that time but still a lot of fun: it could run a lot of games (incl. DOOM, of course), programming (largely Turbo Pascal 7), and some word processing under Windows 3.11.
I didn't bother with Win95, though.
I've been using it up until 1999, when I finally got a then-modern computer with Windows 98. But in some ways MS-DOS felt more capable - I really knew what each file is for, what computer is doing, etc. I.e. the entire machine is fully comprehensible. You really don't get it with Windows unless you're Russinovich or something.
So in a way 386 was a peak computer for me
The 386DX/386SX distinction was the external databus (32-bit on the DX, 16-bit on the SX)
DX was “Double word eXternal", SX was “Single word eXternal”. Neither had an FPU builtin, and there were corresponding 387DX and 387SX coprocessors.
Then Intel used the same naming split (despite the abbreviations not applying) for high-end vs low-end of the 486 where the DX had a builtin FPU and the SX required a “487SX coprocessor” to get an FPU (which IIRC was internally just a 486DX processor which went into a separate “coprocessor slot” which just bypassed the “main” processor when populated.)
Neither had FPUs... Closest you can get is RapidCAD (which is really a 486DX adapted to 386 bus, IIRC it uses a 'jumper' for the 387 slot.)
For 386, the difference between SX and DX was whether it was a 16 or 32 bit data bus.
Where things can get more curious, is that some early 386 motherboards actually took a 287 instead of a 387...
I could try to upgrade to the mighty Am486DX5 at 133. I managed to get one, but I need to mod the MBO to give the low voltage required by it. The MBO it's prepared to it, but don't have populated the regulator...
Eh... I think the Linux kernel + your choice of libc/userland has it beat these days.
https://www.theregister.com/2012/12/12/linux_no_longer_runs_...
I was at a talk celebrating NetBSD's 30th anniversary. I wrote about it:
https://www.theregister.com/2024/04/17/30yo_netbsd_releases_...
They're well aware of this.
But as Linux edges closer to dropping 32-bit x86 completely -- most distros already have -- I think NetBSD may suddenly regain some relevance in this specific area.
There's also a new initiative to improve its jails facility:
On portability on compilers, plan9/9front it's unbeatable. Do you now Go compiling from any OS to any arch? The same here, but just for an OS obviously. Albeit I can still run Golang under i386, and tools like Rclone under 9front i386. That's really cool.
Driver support for a niche SoC? Good luck getting NetBSD on before Linux. The sheer amount of SoCs supported by the Linux kernel dwarfs anything NetBSD has to offer.
Like sure, it runs on my VAX, my Sun4/75, and my Alpha box, but it doesn't run on my POWER9 workstation nor does it run my Amlogic A311D ARM device (at least in a usable capacity), and I couldn't even get i.MX 8M running. I didn't try super hard, to be fair, but why would I burn cycles getting an OS with less peripheral support running when Linux "just works"?
My experience with Linux on a Sun Sparcstation 20 circa 2000 was that it was slow as hell compared to Net or OpenBSD.
FWIW, Linux does work fine on the Alpha, it's just slow. Both NetBSD and Linux have busted framebuffers on my workstation, which has a 3DLabs graphics chipset. Having acceleration enabled causes Linux to output pure garbage, and NetBSD to kernel panic. The CPU performance is surprisingly okay, though. About half the performance of an original Raspberry Pi, in pure integer math...
Linux is busted on my SPARC box though, not because of the system itself, but a bug in the Weitek 2000A CPU. It was an aftermarket part from Weitek, and in order to retrofit an 80 MHz CPU into a system with discrete MMU and cache chips that expect a 40 MHz single-issue RISC processor, it adds a funky on-chip cache, branch-predictor, and instruction prefetcher.
Details on specifics are ~impossible to find nowadays, but the word on Usenet was that chips made before 1995 are no good for Linux. My limited testing with a '93 chip corroborates this. I really ran into this while building a new Sprite [0] distribution, where I learned this chip makes tons of spurious page faults from the branch predictor hitting bogus instructions, which causes the Sprite (and Linux?) kernel to freak out. This corroborates the Usenet reports for random signal 11s killing processes on Linux...
Doesn't effect NetBSD, though. I think this [1] code is why (replaces the bogus fault address with the process counter) but I'm not sure. I have a partial fix for Sprite's kernel which allows userspace to boot up and work, and have networking fixed, but if you sneeze it kernel panics and murders the Sprite-bespoke filesystem, so testing has been a slog. :-)
[0] https://en.wikipedia.org/wiki/Sprite_(operating_system)
[1] https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/spar...
At least OpenBSD, when it says it supports a platform, _actually supports that platform_, and the system is stable enough that it can build itself.
I always thought it was cool OpenBSD compiled on each arch itself. IIRC, there is or was a rack of servers, each with a unique architecture that all built their respective release files. The various targets could help catch arch-specific bugs leading to more portable code.
VAX was always last and the slowest, which was part of why VAX support was dropped some time ago.
Edit: It might be cool to make a higher-spec TMS9900 home brew system.