Origins and History of Unix, 1969-1995 (2003)
catb.org
catb.org
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.
That's precisely the author's point: Torvalds interest in free software is practical, not ideological.
If you know a repo I don't have here, let me know
http://www.nesssoftware.com/home/mwc/source.php
(Considered buying Coherent way back in the day)
There is an empty repo by this name in your project so I'm a bit confused whether this one is supposed to be included:
You can read about it here: https://www2.dmst.aueb.gr/dds/pubs/jrnl/2016-EMPSE-unix-hist...
(link is from the github README)
For instance, it's not clear whether it has any overlap with the Unix Heritage Society's repos: https://github.com/TUHS
(edit: although TUHS github presence is decidedly anemic!)
The page also has some Unix history and related links.
This has already happened with things like sound drivers, TCP/IP stacks, firewalling, etc. but will continue upward
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.
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.
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().
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.
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.
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.)
Looking back, it's very unclear to me what commercially viable investments would have changed the overall trajectory of the desktop.
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.
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.
Also, not clear on what Treble means here: Since its adoption in Oreo, Google has be demanding SoC vendors track closer to newer version of the Linux kernel. Source: https://www.xda-developers.com/google-mandating-linux-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.
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.
https://developer.apple.com/videos/play/wwdc2017/707/
You can quickly glace the PDF presentation, page 16.
Basically, the new APIs for userspace networking are pure Objective-C/Swift only.
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.