G'day Penners, >>I see the 1/1/00, but what's wrong with flying on 12/30/99? The computers >should know what they're doing in any case until the stroke of midnight on >12/31.> One of the chaoplexity dimensions we should consider in this is that it ain't the same date everywhere. Electricity plant, communication sources, data base locations etc etc could all be in 2000 while it is is still 1999 beneath the clouds beneath you. And another is that it is quite possible that failures invisibly occurring on 1/1/00 will manifest themselves days or weeks later. And if a chip deeply embedded in some New Zealand circuit is being the butterfly, an awful lot of consequent thunderstorms will have been blowing away infrastructure by the time the USofA greets the new year. A colleague (name of Bill Fisher) once told me about such a case. Do any propeller-heads out there remember the TOPS-10 business? TOPS-10 was a fine operating system with one unanticipated flaw - a memory overload problem that would confuse the date memory. The problem was diagnosed in advance, but tens of thousands of code locations were involved. Nevertheless, they thought they'd fixed it. Until the world's eastern-most PDP10 (then in Australia) went down - all the world's PDP10's followed according to time zone. The trouble with writing code is that the best way to do it is to pour it all out, and then test it. Well, you can't test for every scenario - you can't even imagine every scenario. Shit happens under complexity, and it will be mounting unpredictable shit under chaos. Bags of uncertainty, and, no doubt, lots of money under beds for a while. We could replace the world's digital network and all electric aplliances and plant (and of course there's a goodly dose of opportunism about on the part of the doomsayers). Or we could expect a gradual litany of problems throughout January 2000. Keep safe, I reckon - from 31/12/99, and a couple of weeks after that. Cheers, Rob.
