That's 2 families, not 2 operating systems. If you can tell me with a straight face that Debian, FreeBSD, and iOS are the same thing, then we're really not having the same conversation.
Unix is Unix is Unix. Compared to the diversity that is out there even now, and far more so, to that which _was_ out there 25y ago, all Unixes are the same OS, yes.
They are all one because the differences between them are trivial compared to their similarities. It doesn't matter if the kernel is monolithic or modular, or if the filesystem is case-preserving but not case-sensitive (NT, macOS). These are hidden technical details.
But most people now have only SEEN Unix and nothing else, so they think that these trivial implementation details -- like what is the default shell, or where are libraries kept -- are important differences. They aren't. They're unimportant decorative details.
When I talk about diversity, let's talk about some real non-xNix OSes I have owned, used, and worked with.
Assumption: shells
Imagine an OS with no shell. No command line at all. Shells are not a given. The idea of typing commands in text at a keyboard, hitting Return to send it for evaluation, getting an answer back, and acting according to that: that is an assumption, and it is one that came from 1960s mainframes.
The slightly more subtle idea that your input is sent character by character, and changing those can interrupt this -- e.g. Ctrl+C to cancel -- that's an assumption, too. It's from 1970s minicomputers, and indeed, the modern version is from one specific company's range: the Digital Equipment Corporation PDP series. The "enhanced" keyboard layout? Not IBM: DEC. The 6-dot-3 then 8-dot-3 letter filename thing? DEC. Filename plus extension at all? DEC.
Alternatives: classic MacOS. Atari TOS/GEM. ETH Oberon. Apple NewtonOS. Psion EPOC16 and EPOC32.
Assumption: configuration held in text files
Config files are an assumption. I have used multiple OSes with no config files at all, anywhere. Not hidden: nonexistent. The idea of keeping config in the filesystem is an artifact of one design school.
Other alternatives to it have included:
- a single global database, part of the OS, not visible in the filesystem at all.
- multiple databases, implemented as different parts of the OS design. One inside the kernel, one inside the filesystem structures of the OS.
- per-app databases, managed by OS APIs. So you don't write files or choose a format: you call the OS and give it things to store, or ask it what's there.
The upshot of these latter two kinds of design is that you get facilities like connecting a storage medium to the computer, and all its programs and data are instantly accessible to the user -- in menus, as associations, whatever. And when you eject a medium, it all neatly disappears again, reverting to previous values where appropriate.
Best example: classic MacOS.
Assumption: there is a filesystem. This is an integrated indexing system that stores data in blocks of auxiliary storage, where they can be found by name, and the OS will read data from them into RAM.
Filesystems are an assumption. Hierarchical filesystems are a bigger one.
Alternatives:
All data is in primary storage (IBM OS/400, AKA IBM i.)
Or, media can contain databases, managed by the OS but not accessible by name (Apple NewtonOS).
Or, the primary storage is objects in RAM, and saving to disk is accomplished by snap-shotting entire system state to auxiliary storage. (Example: Xerox Smalltalk.)
Or, the primary storage is lists of values in RAM, and as above, disks are mainly used for import/export and for holding state snapshots. (Example: Lisp machines.)
When you take a long view, in historical context -- not the narrow parochial one of the last decade or two -- then yes, these are all different implementations of near-identical Unix systems. You've seen one Unix, you've seen 'em all.
What we have today is a biculture: various flavours of Unix, and NT. That's it nothing else.
There used to be a verdant, rich forest here. Now, there is just a plantation, with fruit trees and pine trees. You're pointing at apple trees and pear trees and saying "look, they're different!" And at plums (and cherries and damsons and peaches) and oranges (and lemons and grapefruit and limes).
Well, yes they are, a little bit. But look deeper, and there are hard fruit, stone fruit, citrus fruit, nuts. But all deciduous broadleafed hardwoods.
There used to be creepers and vines and lianas and rattan, and grasses and orchids and bromeliads and ferns, and giant herbs, and little parasitic things, some with vast flowers, and mosses and lichens and liverworts.
There was a forest, and it's gone, and no, you cannot persuade me that a neat tidy little orchard with a handful of fruit trees is the same thing.
I would argue that the more CS education has become about training people to perform the jobs of the present (and thus work in the languages and systems of the present), it has become a kind of Unix training ground. There is certainly now a whole generation of programmers and CS graduates who never got to experience these other systems, and perhaps know very little about them (CS doesn't like to teach its own history).
I have argued elsewhere on this forum that the environment is ripe for completely new OSes, and that we have advantages over this "previous era." The first is the wide adoption and availability of data interchange formats (think JSON, XML, hell even TCP/IP) that were not as common / didn't exist in the heady days of RiscOS or classic Mac. This gets a new OS much further in the "compatibility problem." Our current "App Culture" also absolves us of the need for true application compatibility. For example, so long as your new OS has a somewhat standards-compliant web browser (no small task), you get perhaps up to 90% of the capabilities most people need.
Another factor is that, while our hardware has really fit itself to C and Unix in often frustrating ways, we have RISCV on the horizon. And though all the writing online about it seems to revolve around getting *nix systems to run (boring), there is enough openness for people to experiment without 40 years of cruft getting in the way.
People really should be asking "what is the point of an operating system? What is actually needed here?" A glance in the direction of Lisp machines or Smalltalk or Oberon would provide a lot of guidance in that regard.
I still believe that one day we can move past the teletype metaphor.
There's a myriad of interesting OSes which run a Linux kernel. Containers, for one (such as Docker). Qubes, for another. Third, Tails. Fourth, NixOS. And so on, and so forth. These 4 examples might each run a Linux kernel, but they each have very different design goals and aims.
I'm much more concerned about the lack of diversity in hardware space... specifically, the lack of open hardware.
That's 2 so far. 2.5 if I'm being generous.
Do keep going, would you?