Skip to content

Comment on 40 Years of Unix

Comments

Multics: carefully engineered, fail.

Unix: small and hacked together, success.

Plan 9: carefully engineered, fail.

I'm not sure what the lesson is here... there's that "worse is better" essay... maybe it's that when great engineers let their hair down, they do much better?

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.

Multics didn't "fail"; rather, the Bell Labs guys decided they didn't want to work on it any more and went off to do their own thing. Multics eventually reached a useful state and was in use in various places (by such customers as the US DoD) until around 2000, when the last Multics system was taken offline. However, Multics ran on an extremely small set of expensive Honeywell computers, which is why it did not reach great prominence.

Plan 9 lacks adoption for an entirely different reason. It is very portable, and in the earlier days (~1995) ran on Suns, SGIs, Alphas, some 68k machines, and the PC. As non-PC hardware has become less widely-used, the other ports were not kept updated. However, compilers exist for the MIPS, 68k, ARM, AMD64, Alpha, x86, SPARC, and PowerPC architectures, and it is not particularly difficult to port to a new machine. Unfortunately, Plan 9 was only available via closed license until 2000. Had it been given freely from the earliest days, it very likely could have taken what is now Linux's place as the primary free OS.

The reason UNIX is so widespread is because it was the right solution at the right time. It was freely available to universities and, like Plan 9, pretty easy to port. The interface was simple yet powerful, and the introduction of pipes meant you could write stupid programs, then chain them together for powerful functionality. It really served to end the days of "One OS per Computer" and the kind of monolithic programs one found on such systems as VMS, where every program was an island.

The original Unix was put together in a thoughtful fashion with an eye to both hardware efficiency and powerful features. However, it was unfortunately written before networks and graphical interfaces became widespread--those portions were "hacked on" later, giving us network sockets and X, two systems often considered the worst parts of Unix.

I've always been a fan of Gall's Law: http://en.wikipedia.org/wiki/Galls_law

Your link is broken—it needs an apostrophe after "Gall".

Regarding "Unix: small and hacked together, success."

My favorite part was:

"He allocated one week each to the four core components of operating system, shell, editor and assembler."

Now that is a productive four weeks!

Maybe the lesson is, if you don't have a working prototype after four weeks, you're doing it wrong. At least when it comes to software. I mean, if that's what it takes for one guy to bang out the first draft of Unix...

Maybe you should leave yourself a bit more time if you're not ken. Then again, maybe not.

Unix - Keep It Simple and Scalable (KISS)

Maybe that engineers are better at engineering than managers are at managing?

AboutSource Built by g1lg1l

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