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.
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.
Yes! I don't use my O2 a lot (I think the PSU is flaky, and I'm not super interested in IRIX), but I'm aware of at least https://forums.sgi.sh/index.php, among other similar sites, full of people porting/developing software for IRIX. It's a pretty active community for a 90s workstation platform, the most active one I'm aware of!
It's worth pointing out that Nim is going to cache all of the compilation up to the linking step. If you want to include the full compilation time, you'd need to add --forceBuild to the Nim compiler.
(Since a lot of the stuff you'd use this for doesn't change often, I don't think this invalidates the "point", since it makes "nim r" run very quickly, but still)
There's also the Nim interpreter built into the compiler, "NimScript", which can be invoked like:
#!/usr/bin/env -S nim e --hints:off
echo "Hello from Nim!"
The cool thing is that, without --forceBuild, Nim + TCC (as a linker) has a faster startup time than NimScript. But if you include compile time, NimScript wins.
Yep, always forget about '--forceBuild'.
You can see in the script above the nimcache directory was overriden to tmpfs for the measurement, though. Caching will be helpful in real usecases, of course.
Nimscript is cool but very limited, not being able to use parts of the stdlib taht depend on C. Hope this will change with Nimony/Nim 3.
Yes, Chromium has "native" sandboxing on all those platforms, Windows [0] Linux [1] and MacOS [2].
Chromium uses both seccomp filtering as well as user namespaces (the technology that Docker/Podman use).
The Windows and MacOS sandboxing strategies are more "interesting" because I've seen very few (open source) programs that use those APIs as extensively as Chromium. On Windows, it makes use of AppContainer [3] (among other things), while on MacOS it uses the sparsely documented sandbox API [4], which I think was based on code from TrustedBSD?
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.
reply