I think the statement is poorly worded. Perhaps a better formulation is that a monoculture carries a special kind of risk (it also holds benefits to a business of course). Same is true in politics where having a strong ruling party and an enfeebled opposition is not healthy. You need some external energy into the system to keep it on its toes.

Wasn't there some kind of issue with a leap second sending machines (Linux machines?) off the deep end years ago (and all about the same time)? Conceptually, if you're running a mix of OSs, then there's much less chance of something undiscovered wiping out your entire infrastructure.

There was a story I heard that when working on the avionics for one of their planes, Boeing mandated three separate CPU architectures, with the code developed by three different, isolated, teams, using three different toolsets (languages and runtimes) to minimize the risk of some Unknown Unknown commonality taking them all out. Dunno what actually happened. Could be completely folklore.

> What sort of argument is this. We need multiple political parties. Therefore, our existence is important even if we secure insignificant votes?

Yes, it keeps userland code honest if you follow the published API and not a specific behaviour. See for example the fsync() saga on Linux:

* https://lwn.net/Articles/752063/

* https://news.ycombinator.com/item?id=19238121

* https://news.ycombinator.com/item?id=19119991

It's the same reason why porting to obscure CPUs can be useful: DEC Alpha was never popular, but supporting it kind of forced Linux to be 64-bit clean in some ways, so when amd64 came along there was already a bunch of infrastructure in place.

And having 'external parties' that are not part of the same 'tribal structures' and same zeitgeist / group think can allow for experimenting of ideas.

Thanks a lot for the lwn article suggestion.

Dave Cutler(Windows NT) too found the DEC support to be a safety test for cleanliness.

Considering that Cutler worked at DEC for 17 years, where he was instrumental in the creation of VMS, I'm not surprised.

> It's the same reason why porting to obscure CPUs can be useful: DEC Alpha was never popular, but supporting it kind of forced Linux to be 64-bit clean in some ways, so when amd64 came along there was already a bunch of infrastructure in place.

Nitpick (and you didn't necessarily imply otherwise), but x86-64 was a latecomer to 64-bit ports in Linux. SPARC I think was next after Alpha, and MIPS, PARISC, IA64, PowerPC at least all came before x86-64 was merged.

Wasn't the Alpha port the first chip it was ported to back in the 1990's? I know the Amiga people did their own thing but I don't think it was ever properly merged back upstream

First 64-bit CPU, second CPU of course after 386. Which I guess you mean.

I mean you can't "port" something to its first CPU. You'd be writing it for that CPU initially

Imagine an OS specific bug that could lead to failure. Now imagine you're using that single OS everywhere.

monoculture is bad, especially for security