At 10:02 AM 9/27/01 -0400, mlw wrote:
>"D. Hageman" wrote:
>> I agree with everything you wrote above except for the first line. My
>> only comment is that process boundaries are only *truely* a powerful
>> barrier if the processes are different pieces of code and are not
>> dependent on each other in crippling ways. Forking the same code with the
>> bug in it - and only 1 in 5 die - is still 4 copies of buggy code running
>> on your system ;-)
>
>This is simply not true. All software has bugs, it is an undeniable fact.
Some
>bugs are more likely to be hit than others. 5 processes , when one process
hits a
>bug, that does not mean the other 4 will hit the same bug. Obscure bugs kill
>software all the time, the trick is to minimize the impact. Software is not
>perfect, assuming it can be is a mistake.
A bit off topic, but that really reminded me of how Microsoft does their
forking in hardware.
Basically they "fork" (cluster) FIVE windows machines to run the same buggy
code all on the same IP. That way if one process (machine) goes down, the
other 4 stay running, thus minimizing the impact ;).
They have many of these clusters put together.
See: http://www.microsoft.com/backstage/column_T2_1.htm
From Microsoft.com Backstage [1]
OK so it's old (1998), but from their recent articles I believe they're
still using the same method of achieving "100% availability". And they brag
about it like it's a good thing...
When I first read it I didn't know whether to laugh or get disgusted or
whatever.
Cheerio,
Link.
[1]
http://www.microsoft.com/backstage/
http://www.microsoft.com/backstage/archives.htm