Bruce Beach has more to say to his critics (1999-04-19) : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I received this link in my inbox. It is a lengthy web page, which I have not had a chance to read yet. I'm just passing it along to all those that are interested. <:)=

-- Sysman (, April 20, 1999


Sysman, he took a bunch of us out of context to make up those quotes. I don't know what more can be said about Beach that I and others have not already said - he projects software failure modes into hardware and makes a hash of the whole thing. Shucks, go see for yourself how he doctored higgs.

-- Paul Davis (, April 20, 1999.

Lots of effort in that site.

My own opinion:

Test it. Test the whole system, and all inputs/ouputs you can identiy.

If it works adequately for the purpose you need in the time frame you need it to operate, consider it compliant. Be ready with a backup or emergency procedure in case something else goes wrong in ral world use.

Test the next one.

Repeat until you are finished with the process. Then go to the next process. There are, in my opinion, too many "tricks" twisted logic and errors/missing information in the fundemental design of thne processes and control systems to try to "logic" through and reliably eliminate a system as "not affected by dates" (or certify a system as compliant) based on "good design" or "best practice" alone.

If you try to use design logic alone, or vender certification alone, without adequate testing to verify your assumptions and the information given to you, you must admit that you are running the risk of failure next year.

-- Robert A. Cook, PE (Kennesaw, GA) (, April 20, 1999.

Beach needs to crawl into his hidey-hole and stay put until 2008 or so. Or maybe even time to jump on the unix date problem.

-- Mutha Nachu (---@gogettum,moleboy!.com), April 20, 1999.

Cook says "lots of effort on that site"

hrumph-yeah right-like the effort of squeezing out a shit thats too big!

I'm all for sensible preps, and I GI; but this beach-nut (beech nut?) is just too much!

Let's not let the kooks make us all look bad!

--a GI a day will make y2k go away!--

-- Long time Lurker (, April 20, 1999.

Beach seems to have quite a following including prominent engineers and software designers. The defects Beach are concerned about are real, the only question is magnitude and consequence. One failure of a critical component can kill a person, possibly thousands. The information on his website should not be dismissed so easily by the Yourdon pollannas.

-- a (a@a.a), April 20, 1999.


They will never listean. Come 1/1 it won't matter. OK.

-- David (C.D@I.N), April 20, 1999.

Gary North is right. This is one of the most significant issues to be resolved. I like the style of this response. It takes an extremely technical issue and breaks the responses down to understandable segments that can be easily found instead of asking the reader to be floundering around reading 40 pages trying to find the answer. Mr. Beach would never make a good politician. He tries to make himself understood. These responses demonstrate the need for contingency plans. How many fixed systems are not fixed due to a failure to recognize the potential problems caused by these unexpected clock functions?

-- Steve (, April 20, 1999.

I'm with Flint on this one. The Beach thing does not make a lot of sense to me.

This is not my area of expertise so maybe my opinion is wrong. However, the SECONDARY clock thing sounds a lot like Bemer's digits. You haven't heard a lot about Bemer recently. There's a reason.

I'm heading out for 7-11 donuts, who wants some?

-- cory (, April 20, 1999.


>The information on his website should not be dismissed so easily by the Yourdon pollannas.<

Cory is hardly a "Yourdon pollanna" (sic). :)

Mr. Beach should NAME THE SYSTEM AND/OR PROVIDE THE CHIP NUMBERS. If it's that big of a problem and threat, he OWES IT TO SOCIETY TO DO THIS. PERIOD.

Repeat: PERIOD. I'm SICK of this "confidential source" bullcrap. If it's that important to our safety, and he was really serious about it, HE WOULD REVEAL THE HARD DETAILS.

There's a world of difference between "theoreticals" and practical reality. Yes, it's theoretically possible than an EEPROM could be programmed with a few bogus bytes due to incomplete erasure before the process (one of his original contentions). But in practice, any EEPROM that had code faulty enough to cause a problem in it would be detected almost immediately upon initial testing.

Look at a typical embedded program. We'd have to assume that the faulty bytes were _precise _selected values which would (a)fail to initialize the RTC/"secondary clock" properly, BUT (b) NOT cause the system to crash. Assume a string of 3-4 precise machine byte instructions, each of which has 256 different possibilities.

Do the math; the odds of this are about on the same order as you spontaneously changing race or sex as you read this.

Theoretically possible? Sure. Practically possible? You're more likely to see Klingons land in Washington and ask for Tang(tm). :)

- Stephen (

-- Stephen M. Poole, CET (, April 21, 1999.

Typo correction, which in this case, is quite significant: I meant to say EPROM, not _EE_PROM. They're two different animals.

That's what I get for typing in a hurry when I haven't had my morning coffee yet.

-- Stephen M. Poole, CET (, April 21, 1999.

Moderation questions? read the FAQ