Funny, most of what you described sums up the Alpha architecture. 8KB pages + huge pages and, initially, only word-addressable memory, no byte access.
(Of course, it only took a few years for this to be rectified with the byte-word extension, which became required by ~all "real software" that supported Alpha)
It's also one of the only architectures Windows NT supported that didn't have 4KB pages, along with Itanium. I've wondered how (or if?) it handled programs that expect 4KB pages, especially in the x86 translation subsystem.
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"?
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. :-)
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.
> At least OpenBSD, when it says it supports a platform, _actually supports that platform_
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.
To add to this: I can appreciate the significance of GNU, especially in early Linux distributions, but the position of "GNU was the real OS, Linux was just the kernel" is also deceptive, IMO.
Sure, a lot of the userspace was GNU, but a lot of it ... wasn't. Things like PAM, the init system, and the network config tools, off the top of my head. A lot of system-specific tools come from "not-GNU", too.
You can't discount how much of early Linux was "GNU", and how big a deal GCC and GNU libc (and the rest!) were, but it's disingenuous in my opinion to call GNU an "operating system" that you just plugged Linux, the kernel, into. Even today, as far as I can tell, there is still not a true GNU system. Guix comes close, in terms of being "GNU-ish", but the most usable Hurd distro (AFAIK!) is Debian, where, again, a lot of components come from Debian, rather than GNU.
And, as you say, modern systems have drifted even further from being GNU. They have lots of GNU components, but so did, say, the Sprite OS, or a lot of 4.4BSD derivatives.
On that note, one of these days I want to make the GNU system as it was imagined a reality. Perhaps with the linux kernel as its kernel, maybe with co-official status with the hurd
For that matter, the "second" version of UNIX ran on a PDP-11/20 with no memory protection or MMU, and there were a few versions after intended to run on similar hardware (LSX, MINI-UNIX).
The PDP-11's MMU option was closer to the 8088's segmentation model I think, but I've never coded either, so dunno really. It does seem like it was possible to port "PDP-11 UNIX" to a lot more platforms than would get "VMUNIX".
Here's a contrarian-squared take: in reality, the question "Is macOS a BSD" is malformed. It makes some sens, but is more confusing than it's worth.
Yes, NeXT was built on Mach, which was itself basically an evolution of the Accent microkernel married with BSD, when BSD was a proper noun.
In fact, NextStep 0.8, the first public "pre-release", has left support in for A.OUT executables. The included ex and vi binaries are indeed A.OUT executables taken straight from BSD! In the very next release, support for A.OUT was removed, leaving only the Mach-O loader.
XNU is not derived from the Mach that NeXT was, though, but from the OSF Mach kernel, which was continued at the University of Utah. The BSD "bits" were selectively copied from the extent continuations of BSD, or rewritten from scratch. The XNU kernel doesn't strongly resemble any particular *BSD tree, to my knowledge.
Darwin's origins are messier, since it looks like it was a direct continuation of the existing NeXT packaging (but only Apple would know for sure). NeXT, very much unlike BSD, split its userland into distinct packages, which were versioned independently. This practice has carried on to this day, where e.g. Darwin's libc is packaged and versioned separately from the kernel and other utilities.
For that matter, for a very brief period of history, Darwin used Debian's dpkg for building and installing packages. Evidence of this stayed until OS X 10.4-ish, in the Darwin releases, but they returned to NeXT style BOM files for package management.
All that to say, does NeXT/macOS have a BSD-like userland? Yes, but so does Chimera Linux. Does the kernel resemble BSD? In some ways yes, but in many ways no, it's very semantically different.
And is it descendant from BSD? Again, "yes", but it also doesn't really "come" directly from BSD anymore than, say, OSF/1 did. There's no specific BSD it forked from, and no specific point at which it ever really looked like BSD, in terms of userland, packaging, or kernel semantics.
So I think the question just doesn't make much sense to ask.
- Darwin has no direct BSD ancestor. Unlike {Net,Free,Open}BSD and the more obscure ones (Bitrig, anyone?) there was never a point in time where it directly "connects" to the BSD lineage. The other BSDs all can trace their repositories back to CSRG's BSD.
- Darwin isn't stored or built like a BSD. The BSDs have massive monorepos containing all of the source, traditionally checked out to /usr/src, while Darwin is split into many independently versioned packages, (usually) compiled with Project Builder/Xcode.
Yes, the C API is derived from and supposed to resemble BSD, and much of the userspace was copied from a BSD-derivative (this has grown over time, as Apple (and the BSDs) replaced GNU utilities).
But that's why I would call macOS/Darwin "BSD-like" or "BSD-derived" rather than "a BSD".
Also, this isn't meant to be taken too seriously. I just like "OS taxonomy", and I think macOS/Darwin is distinct enough to qualify as a separate species ;-)
Yeah, I probably went too far in saying it's just the userland, but I'll insist it's more complicated than saying it was based on 4.4BSD-Lite2. I haven't done a proper deep dive yet, but I can tell that it wasn't strictly based on the Lite2 release. Take a look at XNU 123.5's (OS X 10.0) kern/tty.c:
You'll also see the source has been reorganized, with e.g. the VFS source being regrouped into bsd/vfs, instead of being left in bsd/kern. This coincidentally mirrors how OSF/1 was organized (no other source relation though, just an interesting observation):
This file had to be reimplemented by all of the BSDs. In this case, this version appears distinct from the FreeBSD and NetBSD versions I can find.
If you grep around for the `NeXT` ifndef/ifdefs in XNU, too, you'll see some code of which some appears to have been copied/adapted from the NeXT source tree, itself derived from Mach/CMU sources. (and 4.3BSD ;-)
I say all this to draw attention to the ways XNU differs from BSD, which is pretty interesting, at least to me.
Most ideas people have aren't original, but the original ideas people do have come after struggling with a lot of unoriginal ideas.
> They are original to me, and that feels like an insightful moment, and thats about it.
The insight is that good ideas (whether wholly original or otherwise) are the result of many of these insightful moments over time, and when you bypass those insightful moments and the struggle of "recreating" old ideas, you're losing out on that process.
The modern MUSH forks do generally support telnet, but yes -- as a 29 year old who's been pathologically obsessed with "MUD archeology" off and on, I'll confirm -- historically, most MUDs did not do any sort of Telnet negotiation.
Further, most older clients did not anticipate any kind of Telnet negotiation from the server, and will print garbage to the screen if connecting to modern MUSHes that do. (I've tested tinywar, vt, and that one VMS client...)
MUCKs never, to my knowledge, implemented telnet, though. They barely support ANSI escapes, nevermind Telnet. :-)
Funny, I've always found it interesting how "on point" it was...
Granted, yeah, we never (or haven't yet) really transitioned to running "full legacy software" inside the browser, or at least it's not common place. That said, I've seen people compile Wine to wasm, Linux to wasm, and lots of other things to wasm, and run em in a browser. Many of the "fake" demos could be done for real now.
The one aspect that remains thoroughly farcical is an equivalent of Wine for OS X/Cocoa good enough to run a web browser. :-(
[edit] And asm.js kind of died on the vine. Not sure how to feel about that one. Wasm could he described as an evolution of the same idea, but in a lot of ways it's something entirely different.
reply