North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: Networking Pearl Harbor in the Making
- From: Robert Bonomi
- Date: Mon Nov 07 15:05:53 2005
> Subject: RE: Networking Pearl Harbor in the Making
> Date: Mon, 7 Nov 2005 11:11:52 -0500
> From: "Hannigan, Martin" <firstname.lastname@example.org>
> > On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote:
> > >
> > > It's an argument for vendor diversity.
> > No it is an argument for code base diversity (or better
> > software engineering).
> > Vendor diversity doesn't necessarily give you this, and you
> > can get this with
> > one vendor.
> How so? Haven't we recently seen an across the board bug in
> multiple version of $vendor code?
Excerpt from "Logic 101 -- Introductory Logical Reasoning":
"Can" does not mean the same thing as "will".
And, thus, the fact that one vendor has an across-the-board bug does _not_
mean that the same situation exists at =all= vendors..
The bug in multiple versions ov $vendor's code was directly attributable to
those 'multiple versions' all being derived (at different points in time,
and/or for different deployment niches) from the same primary 'code base'.
Note: "code base", *singular*. The problem existed in the core code, so,
naturally, it was present in all the varients of that *single* core.
> > Vendor diversity might be a good idea, but for other reasons.
> Sure. There are more reasons than one to do it. I was specifically
> pointing out that code diversity is a good one - and not forgetting
> associated cost and economic impacts as mentioned in a later followup.
Vendor diversity does *not* _guarantee_ diversity in code-base.
You have to *explicitly* spec/check/test for code-base diversity, to ensure
that you have code-base diversity.
It is _possible_ to get code-base diversity with multiple purchases from a
It is _possible_ to have a single common code-base among purchases from
The "probability" of getting things with different code-bases -- *without*
*actually*checking*for*it* -- is higher if you purchase from multiple
manufacturers/vendors, rather than from a single one.
"Higher probability" != "guaranteed" Hence the need to explicitly check,
if said diversity is a requirement.