I'm sure this is true, and that there will always be a (likely disproportionately) loud group of complainers, many of whom will forget about their complaints. I haven't really publicly complained about Tahoe before, and I don't intend on whining about it again. But...
It's fine. I'm not going to rail about how it's unusable, or say that it makes me want to gouge out my eyes, or whatever. But it's enough to dissuade me from ever wanting to buy another Mac, if I have the option of using a desktop Linux system.
That's a pretty big caveat. But those curved window borders and the rounded widgets in e.g. the settings menu are kind of awful. Not unusable. But every time I open a terminal and I deal with the choice of either having obscene padding around my content or seeing a few pixels of my prompt's corners shaved off, I get just a little more irritated, and a little less likely to pick up my Macbook the next time I'm deciding which device to use.
Good UI for tools, physical or digitial, should reduce the friction between picking it up and using it for something, that's the problem at the core of design. With the small caveat that sometimes technically good but perhaps unethical design solves stupid business problems well, like deliberately making chairs uncomfortable to keep traffic moving through a busy cafe, or making anti-homeless benches, design should not dissuade you from using something you purchased to solve other problems; it's unprincipled.
When I was 20, I preordered a pixel 2 after watching the launch presentation from my university library. One of the "bonuses" for doing so was Google's new headset you put your phone in for a VR experience, along with a new controller.
This "Daydream" only lasted a few years (in software support), but it was a pretty good physical implementation of the "strap your phone to your face for budget VR" concept. I used it more than I'd care to admit for watching movies on a virtual big screen. It'd always give me a big headache between the eyes after an hour and a half, but it was fun every now and again.
A day at the fair.
It even convinced me to buy an Oculus CV1 when those were being heavily discounted!
I never ended up using the CV1 as much as my Daydream, which is saying something. The appeal of VR just isn't that great to me. It's something I find myself wanting to do maybe once or twice a year. Now, never, since the CV1 only ever worked well with Windows, and I can't be bothered to keep a Windows install exclusively for VR (I've tried and failed multiple times with the Linux runtimes).
Not nearly enough drive to deal with base stations, wires, or controllers. And even with the newest headsets that do away with all those, not worth the cash or effort to put on, or the space the headset takes up. Not for "once a month" trips to the fair.
It's insane to me that Meta dumped so much cash into VR. Their fever dream of working in VR gives me a sense of dread and migraine just thinking about it...
What this doesn't really address to me is why DR-DOS. That documentation uses a lot of flowery language to say nothing or close to nothing.
I'm too young to have used DR-DOS in anger (so I may be missing some key feature), but it seems like the entire point of DR-DOS would have been its source code legacy and accumulated feature set.
Here, my immediate question is why not FreeDOS? I'd guess it was system requirements, but according to the documentation DR-DOS 9 requires 2 MB of RAM minimum and a 386!!
I have used a DR-DOS 7 that was set up with a nice task switcher, between terminate-and-stay-resident programs ( not true concurrent processing ).
This setup started WP5.1, a spread sheet -- I think Lotus123, and a graphics editing program. I think it switches using cntrl and the F keys, similar in feel to how a linux machine switches consoles.
I think at the time this was set up, only DR-DOS could do the task switching. I don't know if that is still true.
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.
It's fine. I'm not going to rail about how it's unusable, or say that it makes me want to gouge out my eyes, or whatever. But it's enough to dissuade me from ever wanting to buy another Mac, if I have the option of using a desktop Linux system.
That's a pretty big caveat. But those curved window borders and the rounded widgets in e.g. the settings menu are kind of awful. Not unusable. But every time I open a terminal and I deal with the choice of either having obscene padding around my content or seeing a few pixels of my prompt's corners shaved off, I get just a little more irritated, and a little less likely to pick up my Macbook the next time I'm deciding which device to use.
reply