Modern Linux can't even scratch a 486 and some Motorola platforms. Or VAX. Heck, I run NetBSD 10.1 vanilla under simh 3.8 for 9front emulated on an amd64 laptop (old Celeron, 2GB). Slow, but enough to play Slashem.

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.

▲

messe 5 hours ago | parent [-]

That's a very limited view of what portability means.

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.

▲

spijdar 5 hours ago | parent [-]

Yeah, NetBSD's support for modern hardware isn't amazing compared to Linux. I love it (and run my personal web server on it!), but the portability thing feels like a meme from the 4.4BSD days, where it ran on basically every workstation platform.

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"?

▲

hulitu 4 hours ago | parent [-]

I don't think Linux "just works" on VAX, Sun4/75, or Alpha.

My experience with Linux on a Sun Sparcstation 20 circa 2000 was that it was slow as hell compared to Net or OpenBSD.

	▲	spijdar an hour ago \| parent \| next [-]
		I was saying that NetBSD works on those older systems, while it either has no support (64-bit POWER) or spotty support (modern ARM) on more modern platforms. I've got netbooting set up for all of them, and it's "useful" for testing, though even a 20 MHz VAX is pain and suffering (12+ hours to generate RSA private keys for SSH). 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...
	▲	messe 4 hours ago \| parent \| prev [-]
		I doubt NetBSD "just works" fully on those systems either. I see a lot of rose tinted glasses when NetBSD portability comes up. Those older systems barely get stress tested, as the system has become too large to be self-hosted on them anymore and has to resort to using cross compilation to build a working base. 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.