Skip to content

Comment on 40 Years of Unixparent

Comments

The lesson to be learned is, surely, the same one as we should have learned from the web: creating small pieces, loosely coupled is the best way to build large systems. Ecosystems, not clocks.

To add to that:

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."

http://en.wikipedia.org/wiki/Galls_law

With respect to Multics, unix would run on smaller computers. Moore's Law means we keep getting those, so whatever can get a foothold on them has an advantage. The question of "why unix?" instead of one of the other small OS at the time is less clear. Luck may have played a part.

With respect to Plan 9, it had to compete with unix which was already established.

Note that during this time, another OS also became popular: DOS. Like unix, it ran on smaller hardware (actually, even smaller than unix could run on... giving DOS a foothold advantage denied unix). And clearly, DOS had some luck with respect to all the other small OS available at that time, being put on the IBM PC. There were two other OSes available for the PC (CP/M and UCSD p-System). Why did DOS win there? I don't know, but it was much cheaper, and possibly, MS BASIC compatibility had a role. Before the IBM PC, personal computer manufacturers would tout "MS BASIC" compatibility as a benefit because it gave users access to existing software.

Once you establish a platform with applications, it's hard to beat you. People don't want the platform - they want the applications. It's a network effect.

By targeting low-powered hardware, you can get established ahead of others, so that by the time the hardware has grown powerful enough to support a "real OS", you have already won. It's a disruptive innovation.

A little more than a collection of small pieces... they need to be able to work together in standard ways.

Absolutely, although of course looking at the web, it's clearly not fatal if those standards aren't properly adhered to by some members of the ecosystem, just very annoying, time-consuming and expensive.

That requirement is implied by the "ecosystem" bit. And it's important to note that the need to work together is not a requirement for careful interoperability design. It just means you need to do simple stuff that's easy to understand.

That doesn't explain why Plan 9 failed, it's really a better version of Unix but it never caught on.

Plan 9 was intended as a "research operating system". Unix actually fulfilled a need at the time - a better multi-user "mini" OS.

"Better" isn't enough to gain traction. You need to provide something completely new.

Better can be enough, if it's ENOUGH better. The rule of thumb is that something has to be at least twice as good to replace a similar but already functioning system (the real costs of retraining and lost productivity during the changeover can almost never be accurately calculated, that's why there is the rule of thumb). For an academic view, see "The Fable of the Keys" http://www.utdallas.edu/~liebowit/keys1.html about qwerty vs Dvorak; and the version that was expanded into a book about Dvorak, Microsoft, and the internet http://www.amazon.com/Winners-Losers-Microsoft-Stan-Liebowit... .

ADDED: And Christensen in "Innovator's Dilemma" http://www.amazon.com/Innovators-Dilemma-Revolutionary-Busin... shows how slight improvements can gradually replace something that was originally better.

There was unlucky timing - it got upstaged by this thing called "Linux" that appeared around the same time.

Never caught on doesn't mean it failed.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.