> (...) the direct challenge to the discourse of “free software” that Torvalds himself had never been interested in mounting. (...) “Free software because it works better” easily trumped “Free software because all software should be free”.
I think Torvalds would decidedly have not been interested in that thesis. For example, while git has proven more popular and is probably now technically superior to its chief predecessor BitKeeper, Linus would have been content to continue using that proprietary tool had it not been for the reverse engineering "incident" of 2005 that led to git's conception.
Linus appears driven instead by pragmatism, making use of what is practically available - proprietary or open - while building that which is not, should the path be clear in how to do so.
If anyone is interested, I made a catalogue of UNIX-repos that I found online, I setup a gitlab account for all of it, with automated mirroring, here is the link https://gitlab.com/users/UNIX-history/projects
The interesting thing about the second-system/third-system distinction is that it gives a strong impression that no one really knew exactly what an operating system should be until various examples were built. Arguably, that leaves open the possibility that further forms of OSes exist but aren't easily found due to the difficulty of putting together a system.
So many layers are now built on top of the OS that it seems the most obvious way it will continue to grow is by gradually subsiding abstraction layers above that are so common, you'd never not want them.
This has already happened with things like sound drivers, TCP/IP stacks, firewalling, etc. but will continue upward
*NIX, drives most of the world and is the reason why we exist the way we do today. It's also the reason why Google, Apple and other smaller outfits exist today.
Agreed mostly, although I imagine VMS would have filled roughly the same ecological niche had UNIX not carried the day.
Or maybe that's just optimism that something would have survived Microsoft's onslaught. The days when it looked like Windows was going to rule the world were quite dark.
Absent Unix or a class of operating systems coming out of a similar tradition, the operating systems that came out of the minicomputer era (VMS, AOS/VS, OS/400, etc.) would presumably have maintained their roles to some degree absent Unixes displacing them. And it's very hard to see Windows NT not largely winning out in such a world. As you suggest, it was a close thing as it was and a lot of people thought Scott McNealy was tilting at windmills for not buying into Windows inevitability.
Of course, that raises the question of what about open source in that world. I'm not sure it was in any sense inevitable that open source would have played out as it did. Although absent widespread open source adoption it is hard to see how the Internet would have grown as it did.
What specific features of VM/CMS are you thinking of when you say that?
If anything, I would say it is the other way around. The classic MVS filesystem is more hierarchical than the classic CMS filesystem (when I say "classic", I mean ignoring newer innovations such as SFS, BFS, HFS and zFS). The components of MVS dataset names resemble directories, even though they are mostly (but not entirely) just a naming convention. By contrast, the classic CMS filesystem (pre-SFS/BFS) has an essentially flat namespace on each minidisk – its file naming is closer to PC-DOS 1.0 than to Unix. So, even though both filesystems are quite remote from Unix, the MVS filesystem is a little bit closer to Unix's than the CMS filesystem is.
Also, if you compare the support for multitasking on MVS to VM/CMS, I think you'll find that MVS is closer to Unix. A single MVS operating system image has multiple address spaces (processes) each containing one or more tasks (threads). By contrast, VM/CMS works by running a single-tasking operating system (CMS) in separate virtual machines on top of a hypervisor (although more recent CMS versions have added "application multitasking" which is roughly equivalent to threads). Although neither is exactly the same as the Unix model of processes and threads, MVS is much closer to Unix than VM/CMS is in this area. Given that, it is actually much easier to implement the Unix process model on top of MVS than on top of CMS, which I suspect is why MVS OpenEdition / z/OS Unix System Services comes with a full-featured fork() implementation (which passes the Unix conformance test suite), while CMS OpenExtensions' fork() isn't really fork() at all, it is actually vfork() pretending to be fork().
I've not used CMS, though I have used, long ago, MVS.
My understanding is that CMS followed in its genesis and development spirit a bit more of the Unix development mode. It was more popular among (at least some) users, and as I understood it, a bit of an ugly stepchild / embarrassment to IBM, who considered MVS the more buttoned down, business-oriented, product.
This is based on some long-ago, hazy, second-hand accounts, mind.
I agree with your recollections in that VM/CMS had culturally more in common with Unix, even though technically they had very little in common at all. In the 1970s through 1980s, VM/CMS saw a lot of use as a research computing platform, there was a lot of scientific software available for it. VM/CMS was used as a development platform by many groups within IBM, when some other platform was the target–for example, developers writing the AS/400 operating system, OS/400, wrote their code and compiled it under VM/CMS and then transferred it to AS/400 for execution/testing. (Later they moved to AIX instead; OS/400 is somewhat unusual in being an operating system that has never been self-hosting, never been able to compile itself.)
VM/CMS tended to get new features added to it organically, because some user or team felt the need and just implemented it; the product direction of MVS was much more tightly controlled by IBM management. So VM/CMS was the birthplace of IBM's mainframe email products, peer-to-peer networking (used for the BITNET academic network), the REXX programming language, pipelines (inspired by Unix pipelines but different), etc. Many of those features were later ported to MVS.
In the early 1980s, IBM planned to ship workstations running VM/CMS, hoping that academic/scientific users and developers used to VM/CMS on a central mainframe would like to run it on their desks. This plan never really took off, in part because a lot of those users were already moving to Unix, and Unix workstations had a better price-performance ratio; if Unix wasn't around, maybe IBM's plan would have been more successful.
Thanks, yes, that corresponds to my recollection of the story.
Unix in many ways is the result of its development model, and the "scratch an itch" nature of it, by people capable of scratching those itches. VM/CMS seemed to follow in that same tradition, and as such, addressed (an admittedly technical) end-user community needs in ways that a "delivered" system, in the sense of the providers and users being generally distinct communities, doesn't.
I don't know that VM/CMS would have filled that niche, but it seems that it might have. Having used VMS and Unix, the former, though often compared to Unix, strikes me as far more a "delivered" product. There was a time in my life I could spell DCL (also JCL), and even write some basic utilities in both. That's long since passed.
The capabilities of a Unix shell are far more friendly to ad hoc development and needs -- I'll gin up new scripts or shell functions all the time in ways that just didn't flow from the other languages.
(Now, if I'd picked up, say, REXX, I might feel differently, though I'm really not sure.)
Many are still around to some degree. OS/400 is now IBM i. MVS is now z/OS (for IBM mainframes). OpenVMS as you say. Most of the operating systems that were originally written for minicomputers aren't radically different in fundamental design from Unix and Windows NT.
My suspicion is that, absent Unix or something that followed a similar historical trajectory, these OSs would have had a longer run as non-legacy products, the landscape would have been even more fractured than it was with the Unix wars, and Windows would have become more dominant in the server space than it eventually became.
The question I really don't know the answer to is whether, given the rise of the mainstream Internet, an open source operating system and infrastructure software necessarily would have followed. Or would the world look very very different.
While it's true that Dave Cutler incorporated many ideas from VMS into Windows NT... they are very different beasts with very different code bases. Not even related in the same way that, say, Unix and Linux are.
For the average person, Linux didn't and doesn't offer any compelling advantages for the desktop and had some potential disadvantages depending upon how it was used. Arguably, there are fewer good reasons to not use Linux any longer, but the desktop OS is increasingly irrelevant to most people anyway.
Looking back, it's very unclear to me what commercially viable investments would have changed the overall trajectory of the desktop.
On iOS, ChromeOS, Android, the kernel is irrelevant.
The fact that they run some variation of UNIX is a pyrrhic victory.
Apple and Google can change the kernel to whatever they want, as long as they keep the iOS Kit APIs, Web APIs and Android Java Frameworks.
Mostly only those writing device drivers would actually notice the difference.
As an example where it is going, the new iOS 11 network APIs are not supported on BSD sockets, and Treble kind of moves Android into a pseudo micro-kernel model.
This line of thinking doesn't really make any sense.
Both Apple and Google had plenty of options to chose from when laying the foundation for their operating system. Ultimately, in both cases, a *nix won out. Allowing BSD sockets inside the iOS Sandbox doesn't mean much of anything.
If the POSIX APIs aren't used, there is little value in actually having an UNIX like kernel.
Project Treble is much more than just having a newer Linux kernel, it also defines kernel and hardware abstractions via HDL (HAL Definition Language) using Binder as IPC mechanism, with each abstraction using its own daemon. All very un-UNIXy and more in line with a micro-kernel design, in some ways similar to what is being done in Fucshia.
Google and Apple had little options regarding free (gratis) OSes.
Also when Google bought Android, it was already using Linux.
UNIX winnig has little value if no one is actually calling POSIX APIs, rather Cocoa, UI Kit, Java, NDK, Web APIs.
Both Apple and Google have taken steps in their last OS versions to diminish the set of allowed POSIX calls.
Metal and new network APIs on Apple's side, killing process that don't obey the NDK stable API and Fuchsia on Google's side.
> the new iOS 11 network APIs are not supported on BSD sockets
How much of this can we attribute to technical incompetence on the part of implementers?
A substantial networking feature where BSD sockets don't "just work" is a very bad smell to me. It says to me that the code or concept may be half baked, like they couldn't bother to think it through or don't understand what good layering looks like.
It can be a deliberate design decision and also one informed by incompetence and a poor sense of layering. I don't presently have time to look at this link (I will get back to it) but that is my current impression.
