If you're looking for alternatives, there is stuff being developed. Google's Fuscia is intriguing, and there are other non-Unix kernels from other organizations in the pipeline. IMHO, the difference this time around is that the web is the new compatibility target. If you design a new OS today and manage to get a full working web browser with javascript and Web Assembly, you'll be in good shape.
There are lots of companies selling JVMs, many of them with extensions, and none of them got sued.
Why? Because they play by the rules, instead of trying to be different.
And at least on those platforms I can make use of proper Java 7 and 8 features, not the cherry picked ones on Android.
Google was pretty much aware that GPL with Classpath exception was only for Java SE, not targeted at embedded deployments, but paying the license required for embedded deployments was too expensive apparently.
According to Gosling, Sun would have sued Google if they still had any money left on the bank, instead Jonathan decided to make the public support announcement, angering quite a few folks internally.
His blog posts are no longer live, but old references are quite easy to find.
Actually regarding OS/2, IBM had lots of blame as well.
They didn't managed the whole situation properly and trying to use OS/2 to get back into the game of selling their own PS2 architecture didn't help win the hearts of the buyers.
I would have had to pay almost 500 € extra, on today's money to get a PC capable of running OS/2 properly, instead of the one I got with Windows 3.1.
[1] They often bundled a CD with lots of free software with their magazine issues, e.g. different distros of Linux, server software, utilities, etc. All free or trial software, usually. I remember they bundled the QNX OS once, and I installed it and tried it on my PC. It was very light and fast, had a GUI too - Photon, IIRC. They might even have bundled BeOS once. I think I tried installing that too, but it did not work on my PC.
OS/2 3.0 (Warp) came out a couple of months before Windows 95. Compared to Windows 95, it was much more stable, but lacked compatibility for Win32 programs.
http://www.filfre.net/2016/08/ibms-new-flavor/
OS/2 was to go along with the PS/2. A update on the PC platform that was much more bespoke IBM compared to the largely assembled from off the shelf parts that was the PC/AT.
>OS/2 was to go along with the PS/2. A update on the PC platform that was much more bespoke IBM compared to the largely assembled from off the shelf parts that was the PC/AT.
Yes, I was aware of those points, that Warp was a late or last version of OS/2 and that IBM tried to make the PC architecture closed with the PS/2 line - after it being originally open with the PC (which was what led to its success as a platform, due to the adoption and all the clones and extension cards and software for it). Had read about it. That doesn't change the fact that Warp had good reviews. Didn't try it out personally though.
However, OS/2 2.0 was only available to those with enough deep pockets to buy a IBM PS/2 Model 35 SLC, back on the city I was living.
There weren't any shops selling OS/2 2.0 boxes without an IBM PC to come along.
Me saving around 500€ on today's money, because I got to use my savings on a no name OEM PC running DR-DOS/Windows 3.1, instead buying an IBM PC with OS/2 2.0?
OS/2 was offered as option instead of IBM PC DOS + Windows.
Actually you just made me search for the model I had as option, the IBM PS/2 Model 35 SLC.
It was a PS/2 model, even if without MCA and the only way to legally get OS/2 2.0, where I was living.
Getting a PC compatible and a OS/2 2.0 box just to try out if something works wasn't an option.
Apple was able to do it, because they sell hardware, not software, but the transition from Classic OS to OSX was hard and rocky even for them and could have failed.
It's a pity, because neither Unix/Linux clones nor Windows are really good and technically sound desktop operating systems from a modern perspective, and it would be possible to develop something way better. As for mobile, I don't know, it's a different thing.
Not to mention the heavy Java push they made for a while, which didn't end up becoming much in the long run but did provide one more way for developers to get their applications onto the platform. And developers like Omni that followed NEXT after their purchase by Apple.
Once it was clear developers were ok with using Objective-C, Java Bridge was shown the door.
In the case of OSes, it is beneficial to formalize these similarities into a single API. As long as the operating systems remain conceptually simmilar, there is no point in unnessasarily fragmenting the API. When there is need to deviate from the common Unix system, Unix-like operating systems have no problem doing so. But there is not strong enough reason to through out the massive amount of investment, both in software and human expertise, that has been built up on the common Unix base.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C. A. R. Hoare, Turing award lecture in 1981,
Actually, despite its syntax, Rust is more closely related to the ML family than the Algol family. The original Rust compiler was written in OCaml and it definitely shows in the algebraic data types, functional idioms, and immutability by default.
More to the point, maybe a new OS could gain meaningful adoption by seeming superficially like Unix while actually taking significant inspiration elsewhere.
Is there any reason to believe less than 100% of the code was new?
QWERTY keyboards, Electronic forms, Combustion engines, Agribusiness refinements, Byte-oriented computers, Genetic technology (outside of GM crops), Building construction/insulation, Monorail and near-sonic trains, Pharmaceuticals, PlayStation, 8086, TDMA, USB, PHP, VHS...
The most common link between them is a low barrier to entry, which has multiple facets.
1. Intellectual Property
If you patent technology, it makes it hard or more expensive for others to license and/or implement it, which leads to a loss of market share unless you completely monopolize the market your product occupies. Any alternative technology which is both cheaper and more ubiquitous will dominate.
2. Cost
More advanced technology is, almost by default, more costly. It is costly for manufacturers to develop a new process to manufacture it, it is more costly for developers to learn to develop new products that use it, and it is more costly for consumers to buy it, both because of the lack of manufacturers and developers for it. It also will inevitably require one to learn a new way to use it.
3. Doesn't address a critical need
If there are two competing technologies, and both provide for the same need, the one that best addresses a need and costs less will win out. If one does not provide for a critical need, it will be left in the dust. Often that "need" is as simple as being faster or easier to operate, but it can also include specific functions.
--
The earlier you are able to introduce a technology, and as long as a newer technology does not beat you on platform support, cost, and critical features, you will remain on top.
Browsers are a good model for how this has changed hands over the years. The barrier for entry is smaller because you can make them for multiple OS platforms fairly easily, but sometimes one would have a monopoly. So to compete with the monopoly, one browser would remove a barrier to entry - cost - and develop new critical features. But then the other competitors could adopt the same changes and compete again.
Another example is Intel x86. Intel tried several times to end the x86 product line. But as the industry refined standards around it, it became too expensive and complicated to try and introduce a complete replacement. It was even forced to adopt features that competitors introduced.
UNIX (and C, since a lot of people lump them together) has stayed around so long because it has a low cost, low complexity, is ubiquitous, can adopt new features easily, and is highly compatible/portable. Even if you have a new critical feature, it can usually just adopt it.
In the end, kernel design has nothing directly to do with how it is adopted by users. Kernel design affects how software developers, and later manufacturers, will use it. And that affects what is left for users to adopt. Nobody really notices a kernel; what they notice is the ecosystem.