Paula Gordongreenspun.com : LUSENET : TB2K spinoff uncensored : One Thread |
Recently, I dropped a quick note to Paula Gordon. What prompted my missive? Crusing through an earlier thread, I reread her 1999 Christmas Day remarks. Gordon essentially provided her riff on a tired TB 2000 argument, to wit, "GIs have a better grasp of the Y2K problem because of their experience, intelligence, insight, ability to grasp the 'big picture,' etc."My counterpoint was simple. In my opinion, the serious Y2K pessimists were often disaffected, middle class, white Americans who possessed a negative attitude about modern culture, society and institutions. This predisposition made it easy to believe the myth of a Y2K apocalypse. In fairness, some of the serious pessimists were very bright and well educated. Y2K, however, serves as an excellent example of how an initial bias can distort the thinking process. Hey, even smart people can be wrong.
Unfortunately, the pessimists also attracted members of the lunatic fringe like Bruce Beach. Burying school buses as shelters does not strike me as entirely sane. This made it easy to dismiss those concerned about Y2K, rather than realize some pretty normal folks had simply jumped to the wrong conclusion.
I do not think Gordon a lunatic... but rather an example of how an educated person can be totally fooled by a complex phenomena. With her post-Y2K work, she reminds of the post Copernican astronomers who stayed busy "proving" the sun really revolved around the earth. (chuckle)
In response to my email, Gordon sent me a perky paragraph where she explained how delighted she was to live in a free society where opinions can differ. It was another delicious irony. While the serious pessimists were talking about a dark government Y2K conspiracy, the same government was content to let them froth endlessly. I guess evil Orwellian governments just aren't what they used to be. (chuckle)
Gordon is a good example of an old rule: No matter how silly or farfetched your idea, you can find a PhD somewhere who agrees with you. The challenge of Y2K was not finding "experts" who agreed with you. It was staying objective about the problem. With her comments, it's pretty clear Gordon lost her scientific objectivity somewhere alon the trail.
-- Ken Decker (kcdecker@att.net), July 31, 2000
how delighted she was to live in a free society where opinions can differThis is her justification for writing all the stuff that was totally wrong? She was claiming the president and government were in effect scamming the country into believing that nothing was wrong while she claimed it would all fall apart because of mbedded anything?
Where it her accountability for her actions?
No wonder young people think it is ok to do whatever thay want and expect no repercutions for their actions. After all, all they have to do is make an excuse.
In the next ten years we will see the results of the lack of self discipline and the "freedom" that is presumed to override (what used to be) normal social mores.
It is getting to the poijnt where a person is ashamed to be an american, rather than proud to be one.
The "Ugly American" has come home with his behavior.
The gap is widening in more ways than peoples financial status, the gap between acting like a member of the human race and an animal (living by instincts alone) is getting wider every day. The media, of course plays onanything that selss so they push behavior to the limit too.
EX-TREME! DO ANY AND ALL THINGS EXTREME! That is the buzzword of the day.
The years of the gangbangers brought on the sale of "gangbanger" clothing and movies, justifying the behavior. Little Tommy middleclass dressed up and got to pretend to be a gangbanger, only problem was, some went beyound pretending. Adds on kid's TV show preteen girls with their hands on their pelvis, dancing, legs spread thrusting out their crotches. These are what little Tommie and Tammie middleclass see between the rugrats and "sponge bob in square pants!"
The only way "madison ave" is going to stop pushing back social limits is if we write them and let them know it is not acceptable. Hit them in the pocketbook, refuse to buy products that are sold at the expense of exploiting children.
What does this have to do with Paula G?
Same difference, if she and others like her "get away" with doing wrong, then how would kids, even adults be diswaded from doing wrong, if nothing is done when they do something wrong? Self discipline? People being responsible for their own actions? Why would they? They don't even know what the limits are? As long as they can get away with doing whatever they choose, what is to stop anyone from doing whatever the hell they please? Nothing. And we, as a society, are seeing the results of that right now.
Today more emphises is placed on "how" a person is caught doing something wrong than the wrong they did in the first place. Like a conversation I heard where these people were talking about their DWI's, they were complaining that they were illegally stopped, that they should not have been charged, how corrupted the police were for sitting by the neighborhood bar at closing time. No mention of the fact they they were (all three) way over the legal limit to drive, no regret that they could have caused an accident or even killed someone, no, no, it was all about how they should have "gotten away" with drinking and driving and breaking the law. It's amazing how those who don't get causgt and hurt or kill someone are always sorry, wish they could take back what happened ~~~ after they have done it.
The point being with these three who were talking just might have been stopped from hurting or killing someone by being stopped as they were.
Personally I think Paula Gordon should be held accountable for what she said and did about Y2K.
Perhaps a few letters to the institution that employs her might be called for.
-- Cherri (sams@brigadoon.com), July 31, 2000.
Ken,Objectivity and Government Grants are rarely found in the same room together. Paula Gordon is a typical academic who has discovered the keys to the system and will ride that horse until it collapses. Where the hell is Bill Proxmire when you need him?
Oh, and careful what you say about Mr. Beach. Hawk is touting him
-- Ra (tion@l.1), July 31, 2000.
as Secretary of Transportation in the new Nader Cabinet.
-- Ra (tion@l.1), July 31, 2000.
How's this for free speech; Paula Gordon is an ignorant brainless twit.
-- Maria (anon@ymous.com), July 31, 2000.
Cherri,How about trying decaf? (chuckle) Paula Gordon lives in the academic world. At present, the only "sin" in academe is to lack political correctness. In my reading, Gordon has never been politcally incorrect... just wrong. While truly sad, the administration at Georgetown probably cares little about how wrong Paula Gordon was... only that she managed not to offend women, persons of color or the physically and mentally challenged. Personally, I think Gordon missed the brass ring. If she had touted Y2K as a plot to reestablish a paternal political hierarchy in the U.S., she'd probably have an endowed chair in women's studies by now.
As for Hawk, forgive me if I don't worry overmuch.
-- Ken Decker (kcdecker@att.net), July 31, 2000.
Gordon is not on the faculty of GWU. She is "attached" and uses their facilities.At blame for the Y2k fiasco there also is her associate, Stuart Umbleby who Dr. Dooddo Carmichael once mentioned measured Y2k awareness in Vienna while on leave. He asked people he met what they "thought" about Y2k. That was circa late 1997. Later, Umbleby wrote drivel similar to Gordon, Carmichael and Robert Theobold. Clearly all of them were well trained in the methodology of finding grant money in Pork Barrels.
They also know something about Academia. After a few months goes by, the only thing you have to tell people about Y2k will be: "Oh yes, I studied that for some time and all the possible ramifications. Luckily for all of us, things were not as bad as they looked. But now I"m doing Global Warming and you know I have a White Paper that I'm about to release......."..........
-- cpr (buytexas@swbell.net), July 31, 2000.
Ken, you are way too kind. When Paula replied about the right to free speech, she in her own little PC way was dissin' you. Instead of meeting the challenge to defend her cause, she opted to a quick huff (no logical agrument).I agree with Cherri. She should be held accountable, especially in the academia environment. This is the same twit "challenging" our children, "teaching" the finer points of logical persuasion. Instead she's probably teaching them how to feel better about themselves, the dumbing down of America starts with the instructors.
-- Maria (anon@ymous.com), July 31, 2000.
I disagree with Cherri and Maria on this one. Paula is responsible only for herself and any family obligations she's assumed. To believe that she's responsible for the thinking of others is similar, IMO, to believing that McDonalds tried to intentionally burn someone by allowing them to buy hot coffee.Even if Paula WERE teaching, we could tell the difference between the teachers with the PhD's when *I* went to University. They were more concerned with research than teaching.
-- Anita (Anita_S3@hotmail.com), July 31, 2000.
IF Dr. Gordon is tenured, she has no academic accountability.
-- Lars (lars@indy.net), July 31, 2000.
Lars, make that no academic credibility.
-- Ra (tion@l.1), July 31, 2000.
In response to my email, Gordon sent me a perky paragraph where she explained how delighted she was to live in a free society where opinions can differ.This doesn't include the right to differ with the facts. This isn't an academic problem, this is primarily a private sector problem [in my experience]. It is a money and greed problem. But then you may be a willing participant; and I don't want to insult any of you.
-- DB (Debunker@nomore.xxx), July 31, 2000.
Caveat emptor.Oh, Anita, if memory serves the McDonald's case involved a restaurant that had been warned several times about serving coffee the temperature of molten lava. There apparently were other factual elements not included in the folklore version of the story. Though this came from a friend at Georgetown Law so who knows? (chuckle)
In general, unless someone can prove Gordon engaged in fraud, she's pretty much entitled to her opinion. As for accountability in academia, I don't think Gordon was teaching anyone. My money says she's one of the new generation of academic policy wonks who is trying to ply her way into a inside-the-beltway think tank. Mark my words, she'll show up somewhere writing more "white papers."
-- Ken Decker (kcdecker@att.net), July 31, 2000.
Decker:I said: I don't want to insult any of you.
I think that I said what you said. The above remark was for you.
DB
-- DB (Debunker@nomore.www), July 31, 2000.
Anita, So she knows how to prevent legal liability for her actions, but what she wrote was "I think I smells something...could that possibly be burning? in a semi0crowded theatre.The sad thing is, she probably has "the credentials" to teach anywhere.
Which I think is rather sick, considering what others are required to do to be able to.
Jusy how does she have "this job" where she can prove her inability to know what is going on, and she gets apid for it? How do I get one like that?
-- Cherri (sams@brigadoon.com), July 31, 2000.
Cherri: Forget it, you are way too stupid to get paid for such a job. Now, getting "apid" (laid???), that's another story...
-- WD-40 (wd40@squeak.not), August 01, 2000.
Personally I think Paula Gordon should be held accountable for what she said and did about Y2K.I would agree with that, Cherri, but only if it has been proven that the embedded systems issue was a hoax. The seeming lack of embedded systems problems at rollover could also mean that embedded systems that needed to be fixed prior to rollover were fixed.
-- Had (to@or.hoax?), August 01, 2000.
Ra, you are confused. The real Hawk doesn't even know who Bruce Beach is, so you must have been deceived by his troll.
-- (been there @ done. that), August 01, 2000.
I would agree with that, Cherri, but only if it has been proven that the embedded systems issue was a hoax. The seeming lack of embedded systems problems at rollover could also mean that embedded systems that needed to be fixed prior to rollover were fixed.
-- Had (to@or.hoax?), August 01, 2000.BBBBBBuuuuuttttt.....how could that be? There were "billions and billions" of chips in a min. of 20-40 mill. systems (refer Dave Hall, St. Leon the Kapp and Harlan Smith).
And it was the argument of every doomer/pessimist from Yourdon, North, Hyatt to Hardin that "they couldn't /were not" being fixed.
YET.........NOTHING HAPPENED aside from a handful of reported errors mostly in time reporting/logging. NOTHING.....repeat..NOTHING "MISSION CRITICAL".
As for Gordon's PRIVATE "REPORTS". BULL SHIT. IF SHE HAD ***ANY THING** ANYTHING AT ALL....SHE WOULD BE SCREECHING TO THE WORLD THAT SHE HAD "PROOOOOOOOOF".
THIS IS A *TYPICAL* ACADEMIC CONSULTANT PLOY: **BLOW A PROBLEM WAY OUT OF PROPORTION ....THEN GET A "GRANT" TO "STUDY" THE "PROBLEM".
PAULA GORDON HAS HAD A MESSAGE DELIVERED:
NO SALE
-- cpr (buytexas@swbell.net), August 01, 2000.
YET.........NOTHING HAPPENED aside from a handful of reported errors mostly in time reporting/logging. NOTHING.....repeat..NOTHING "MISSION CRITICAL".Maybe those mission-critical embedded systems were fixed pre-CDC, Charlie.
http://www.csis.org/html/y2ktran2.html#dejager
And then, finally, point number 4 is that we have a problem even bigger than the software problem. It's bigger. We have no idea how much bigger. We have no idea, really, how much the impact is going to be. We have an embedded system problem. And anybody who says that we don't have enough evidence about embedded system problems should pay attention to General Motors.
They are not a consulting group, I'm sure you're aware. They described their problem as catastrophic. Their words, not mine. They took a plant which they were going to shut down, and instead of shutting it down they rolled the clock forward. And when they rolled the clock forward, their assembly line -- the robotics -- stopped. They just stopped.
-- Had (to@or.hoax?), August 01, 2000.
By Jove, I do believe you have nailed it. People became aware there might be problems. They tested, and found some. They fixed them. They told us the problems were fixed.They also missed some, and had to fix them later. They did so.
-- Flint (flintc@mindspring.com), August 01, 2000.
CSIS also EXITED Y2k long before 1/1/2000 with the usual '3 day storm".Now,,,,,,,,,,,,why Flint fails to mention all the Doomzies who told him before 1/1/2000 "they can't fix them all" amazes me. Hyatt and Yourdon, North and "Mr. CEO" all swore up and down Fix on Failure 'NO WAY'.
FRANKLY...Most of y2k HYPE WAS HYPE but 'embedded' was BULL SHIT.
-- buytexas (buytexas@swbell.net), August 01, 2000.
FRANKLY...Most of y2k HYPE WAS HYPE but 'embedded' was BULL SHIT.http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001qGO
Nov. 22, 1999
Secretary Daley Urges Vigilance on Y2K Problem
Secretary of Commerce William M. Daley today urged American businesses to redouble their efforts to test for year 2000 computer problems that are hidden away in a variety of machines other than computers. Thorough testing of these "embedded systems" is a wise safety measure, Daley said.
"Ferreting out all the Y2K connections in the systems that run manufacturing plants, provide services to consumers, and control a host of operations that we all rely on is a tough job. We urge businesses to be especially vigilant in testing embedded systems," Daley said.
Embedded systems use computers or computer chips to control, monitor or augment a process. Such systems are found in everything from elevators to manufacturing plants.
The Commerce Department's National Institute of Standards and Technology and Century Corp., a computer consulting firm, have assessed the range of testing methods industry is using.
They conclude that it is possible that many important systems have not been tested adequately. NIST strongly recommends that all critical systems be tested literally from end to end.
"Managers of these systems should, as a last resort, rely on assurances from suppliers and others that the individual components of a system are Y2K compliant," Daley said. "I want to reinforce the message that I and others, including the President's Y2K Council, have been delivering about taking appropriate actions in readiness and contingency planning," he said.
A research article that includes guidelines for testing embedded systems by NIST and Century Corp. is available on the NIST web site at www.nist.gov/y2k/embeddedarticle.htm.
As a non-regulatory agency of the U.S. Department of Commerce's Technology Administration, NIST strengthens the U.S. economy and improves the quality of life by working with industry to develop and apply technology, measurements and standards through four partnerships: the Measurement and Standards Laboratories, the Advanced Technology Program, the Manufacturing Extension Partnership and the Baldrige National Quality Program.
-- (Nov@22.1999), August 02, 2000.
The NIST report followed by commentary from Cherri, Flint and others.http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001qX4
-- More background (on@embedded.systems), August 02, 2000.
To Cheri, W.D. Had, Ra and Flint, etc. The question originally posed, was if crisis came to summation, how long would it take for the Government to move? Now let my personal experience, take the steering wheel. Case in point: Three years ago, they shut down the Chief's Club. Some other activity was supposed to move into those quarters. Those quarters were coveted by many, but it was ordained those spaces would go immediately this one command. The spaces still sit, unoccupied, by the new regime. Building is not, has not, been ready for three years. Now, might you doubt, my doubt, even though you possess expertise, in your chosen field? Can you see my doubt?
-- Oh God! (theycan'tget@up.com), August 02, 2000.
The chance of stand-alone 'chips' failing was very, very small. As for embedded systems, their risk of failure varied depending on how complex the system was and what industry one is talking about. Someone who had done testing and found no embedded systems problems in one sector might not know of the potential risk in others.http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001PeC
Microcontrollers are small devices, common in almost all electronics, that have their instructions burnt in at time of manufacture and cannot be reprogrammed like software. They may have some spare addressable memory that can have a date field added but a mere one in 10,000 of these will fail and these will be impossible to identify.
Most of these devices don't even know what planet they are on, let alone the date, said Kyte.
The second category is microprocessors, programmable devices that execute code. These can be at risk if they have a real time clock mounted or communicate with a clock. Less than one quarter of a per cent without clocks are at risk, but around seven per cent with some time dependency will have problems as the clock ticks over into the next century. Only two per cent will continue to have problems once reset.
Finally, large scale embedded systems are most at risk, with more than 35 per cent expected to be non compliant. Typically found in manufacturing, oil and healthcare environments, but can even encompass things like traffic light controllers or aircraft systems. They typically include common PC components although often run proprietary or even site specific applications.
On the embedded systems side, a capital expenditure, Kyte advises users of one get around.
Talk to your chief financial officer. If it costs $1,000 to replace a device, how much should be spent on investigation? Replacement may be more tax efficient, he said.
James Duggan, research director at Gartner said he believed the three areas likely to be worst affected by problems in embedded systems are the oil industry, telecommunications and power grids. He said things such as aircraft were well used to protecting against a single point of failure and were in good shape, though that did not apply equally to the systems that maintained aircraft fleets.
-- Most were not at risk (but@some.were), August 03, 2000.
OH PUHLEEEEEESE....CHERRY'S NONSENSE AGAIN....NOTHING HAPPENED DID IT???
Answers
This is a damn fine piece of work. The most realistic, accurate, fully descriptive and easily understandable summary of the problem I have seen in my 18 months of Y2K research. Although it is not likely to change the approach of those responsible for the readiness of their systems, it may help to wake up some of the public who still don't get it. Any sane person with half of a brain who honestly dedicates 5 minutes of their full attention to reading this should be able to understand why we still have a very high likelihood of many system failures coming soon. The hard part is trying to find people who are still sane, half at least a half of a brain, and are willing to spend 5 minutes reading this. Nonetheless, it is a good one to print and give it one last shot with those who are at least willing to read it. Thanks.
-- Hawk (flyin@high.again), November 24, 1999.
This report that was just released (NIST reports to the Secretary of Commerce) and is the reason that Secretary of Commerce Daley JUST came out and stated the potential problem with embedded systems.He asked folks to check into their systems and make any corrections before 1/1/2000 as if it was a simple problem to correct.
Ray
-- RAy (ray@totacc.com), November 24, 1999.
It is a terrible piece of misinformation and cut and paste from outdated websites that has been posted in the receint past.It is a case of a politicial jumping on the Y2K bandwagon and having his IT write about systems he obviosly has no background in. Most of it is familiar, been around for years, and even seems to have a hint of Bruce Beach's 3rd clock involved.
The methods for finding and fixing the embedded systems are not realistic, or even reasonable.
I'm afraid there are going to be a bunch of "new" websites popping up now that every politician or entity jumps on the "awareness" bandwagon and wants to show that they are "hip" to Y2K.
Be prepared for lots of "new" reports that look familiarily like the stuff on old websites, even the stuff doomers have debunked.
Geeze, RTCC...Real Time Clock Calender? No such animal.
-- Cherri (sams@brigadoon.com), November 24, 1999.
Hawk,This is a damn fine piece of work. The most realistic, accurate, fully descriptive and easily understandable summary of the problem I have seen in my 18 months of Y2K research. It would help to have at least half a brain to see that it is cut and pasted and not understood in the least by the guy who wrote it.
-- Cherri (sams@brigadoon.com), November 24, 1999.
Hmmm, this information doesn't square with Factfinder's assessment. I guess it goes to show us that Factfinder just doesn't have all the facts.Cherri,
In the oil biz... I've got remediators out there telling me that people like you are just blowing smoke, because they've been out there doing the job. Lots of them will fail. No one knows just what the ramifications of failure will be. They expect at least some systems (maybe most or all) to shut down. One thing is for sure. You don't know what you're talking about. The above article is yet another example to prove it. Was this the article and info that prompted the Sec of Commerce to make his plea for more new testing??? I don't know for sure, but something caused him to do so. Meanwhile, Cherri have a nice rollover.
-- R.C. (racambab@mailcity.com), November 24, 1999.
Cherri,I have sent the following e-mail to Gary Fisher & Mike Cherry. If and when I receive a reply I'll post it here.
I am writing in regards to your article on NIST EMBEDDED SYSTEMS AND THE YEAR 2000 PROBLEM located at the URL site http://www.nist.gov/y2k/embeddedarticle.htm.
This article was pasted on a thread on the Ed Yourdon bulletin board. The following was an answer in regards to this article by a woman who is a proclaimed expert on embedded chips and systems. I would be interested if you could clarify anything for those of us who would like to know what the actual facts are on this complicated and highly debatable subject. It is a "wild card" in the Y2k scene and has either been over-hyped or under-played. Any light that you can shed on this subject would be greatly appreciated.
Anxiously awaiting your reply
Sincerely,
Cary McXXXXXXXX
Copy of Cherri's reply was attached
-- Cary Mc from Tx (Caretha@compuserve.com), November 24, 1999.
The report states: "We recommend that manufacturers' statements of Year 2000 compliance or readiness be used only as a last resort to make any determinations since a manufacturer's definition of compliance or readiness may not meet the requirements of a particular environment."Many folks out there are using vendor statements as their total embedded system remediation effort. Pretty scary
-- Brian Bretzke (bretzke@tir.com), November 24, 1999.
Cary:Please let us know what their response is. If they debunk Cherri's criticism, then it will let us all know that Cherri is someone not to be listened to. If not, then Cherri has credibility.
-- haha (haha@haha.com), November 24, 1999.
It would help to have at least half a brain to see that it is cut and pasted and not understood in the least by the guy who wrote it.-- Cherri (sams@brigadoon.com), November 24, 1999.
Do you have any idea what the NIST is? No, I suppose not. That's okay, though; all a reader has to do is read the article and then your response to see who is missing more than half a brain.
-- Steve Heller (stheller@koyote.com), November 24, 1999.
HaHa,I hope you realize what a dim-witted polly you are. If you don't have any thing of substance to add please refrain. For all we know Cherri rides on the back of a garbage truck collecting trinkets.
National Institute of Standards and Technology
NIST program questions: Public Inquiries Unit, (301) 975-NIST, TTY (301) 975-8295. NIST, 100 Bureau Drive, Gaithersburg, MD 20899-0001. NIST is an agency of the U.S. Department of Commerce's Technology Administration
EMBEDDED SYSTEMS AND THE YEAR 2000 PROBLEM
Gary E. Fisher Computer Scientist National Institute of Standards and Technology Gaithersburg, Maryland
"Here is all the Credibility you need.......
-- kevin (innxxs@yahoo.com), November 24, 1999.
Thanks Alerting...Question: Why is Cherri even acknowledged after all the info. we've read to the contrary of this denial polly position?
This is just another confirmation that embedded systems are a huge threat and the situation will take infinitely longer to fix than three days.
-- PJC (paulchri@msn.com), November 24, 1999.
Cherri,for us to take your above statement with any seriousness at all, you must provide us with your background bio, and write a critique essay of this NIST paper. With facts to back up your claims, not simply "this is old news, this has been debunked" etc. If it's old news and has been debunked, show us by whom and why.
-- (PutUP@r.shut.up), November 24, 1999.
All --First, let me state that *I* thought it was a pretty good article. Well written, and at a level that the 'non-geek' segment of society could understand. Wasn't loaded up with a lot of jargon.
Second, the term "Real Time Clock Calendar" may not be one used generally in the industry. This is apparently an attempt by the authors to include all the myriad devices that serve this sort of function.
Third, in response to Cherri's comments, I don't know if Cary Mc will get a response to his letter, but here is a little experiment you may try on your own. Just as a way for you to take your own measure of Cherri's worth as a 'self-proclaimed' expert.
Go to your favorite web browser. Find your favorite search tool. Using that tools methods for searching for *Exact matches including all terms given*, do a search for "Real Time Clock Calendar". Just using this, looking for an item that Cherri claims
"Geeze, RTCC...Real Time Clock Calender? No such animal."
I found over 500 entries for companies that include this term as an *EXACT MATCH* on their website. Most of the entries (I didn't read all, just 3 or 4 selected at random), are for companies that make chips.
This is a simple test, and you don't have to be a 'Real-time embedded expert' to do it. However, in my opinion, it absolutely gives the lie to Cherri's claims of 'expertise' in the area.
In other words, IMHO, she's blowing smoke up our butts, for reasons know only to herself. I sure fail to see why someone would do this. Or, I suppose, it could be a case of true ignorance. Sort of, "Well, *I've* done two projects and *I* never used no such thing, which, since *I* am *GOD* that no such thing ever got done, anywhere by anybody." Of course, that pretty much shoots down her claims of 'expertise' too.
-- just another (another@engineer.com), November 24, 1999.
PutUP,You said to Cherri, "for us to take your above statement with any seriousness at all, you must provide us with your background bio, and write a critique essay of this NIST paper."
I couldn't agree with you more. I'm very tired of Cherri's terse posts that provide zero facts and only arrogant innuendos of her "expertise". Its way past time that she begin to let everyone know why she is the "expert" and we should listen to her.
So Cherri, what are your credentials? Do they supercede NIST or the IEEE field's of knowledge and their IT industry prestige? If I hear no reply from you substantiating your credentials, I will be forced to come to the conclusion that you are only inflated by an ego that has no basis in reality, and that further posts regarding the Y2k embedded chip problem by you, must be totally discounted by all.
As I said before, if and when I recieve a reply from Gary Fisher and/or Mike Cherry, I will post it to the board.
-- Cary Mc from Tx (Caretha@compuserve.com), November 24, 1999.
I think the problem is that Cherri has been brainwashed by the no- problem crowd at deBUNGy. <:)=
-- Sysman (y2kboard@yahoo.com), November 24, 1999.
Here's an example of real-time clock calendar (RTCC) from a manufacturer at http://www.rigelcorp.com/51 5ctk.htm"The R-515JC also has CAN, Controller Area Network with the physical layer on-board. The board comes standard with 32K RAM and 32K EPROM, but will accept up-to 512K RAM and 128K EPROM. There is a Y2K Real Time Clock / Calendar (RTCC) which may be populated as well as a battery back-up system for both the RAM and RTCC. The processor supports 10-bit A / D, as well as having 48 I / O lines, 3 16-bit timers and a watchdog timer."
Cherri has wasted enough of our time. Lets move on.
-- (PutUP@r.shut.up), November 24, 1999.
You want Cherri to do a 'critique essay'??Give me a break.....what a double standard. Less than 1% of any of the stuff posted here by the extremist doomers in any way could be labelled 'critique essay' quality. Most of it is stuff along the lines of 'Y2k cannot be fixed.....we're all gonna die!!'
The fact is, most chips do NOT care about what calendar date it is. They do not calculate time differences by means of a calendar date. Any chip that did use this method would have to have an external means of setting the time or else it would be useless anyway.
Without an external interface to change the time, what good would it be? Would the chips internal clock be set to the correct time as it was being made in the factory.....wouldn't make sense......the factory does not know in what time zone the chip would be used in when they make it. Also, during down times, the chip would not function leading the internal clock to stop. Therefore it would not roll over to '00 until possibly a few months or even many years after the calendar roll-over date.
Very few chips or systems care about the actual dates. Some that do care are in things such as traffic lights and elevators that actually have some use in knowing the difference between a weekday and a weekend.
Certainly there will be some surprises and some exceptions that have to be dealt with. However in plants and factories where this could cause great danger they have always had to deal with with such potential problems......we've already seen a lot of explosions and fires for example at chemical and oil processing facilities so far this year.....and we will see a few more as a side-effect of Y2K. However it will not ALL collapse.
I've said it before and I'll say it again.......by and large, the professionals and engineers that know these systems are not freaking out about the rollover....they have some concerns and they are prepared to manage any problems just as they have done for decades. This extreme fear of embedded chips is not based on fact but rather is a smokescreen used by those that would champion fear-mongering as a way to try and 'prove' their end-of-the- world belief system one way or another.
Now rather than sulk off in the corner shouting 'Polly' to try and silence me, can anyone give me some specific examples of chips or systems in a chemical or oil facility that WILL fail because they use the calendar date in their calculations?? Good luck, you might as well try to find the elusive unicorn!!
-- Craig (craig@ccinet.ab.ca), November 24, 1999.
Cherri,
Are you ever going to write the essay for Cory Hamasaki that you promised us?
Sincerely,
Stan Faryna
Ready for Y2K? Got 14 days of water, food, way to keep warm and cook?
http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl? msg_id=001o cfCooperative Preps : Have you checked out the deals we can get on preps?
One time deal on a inexpensive grain mill
http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl? msg_id=001q SwWater filters for less than suggested retail
http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl? msg_id=001q T8Gas masks, potassium iodide, solar ovens, etc
http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl? msg_id=001q TKAladdins: the kerosene lamp for readers
http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl? msg_id=001p 1v
-- Stan Faryna (faryna@groupmail.com), November 24, 1999.
Bottom line: Do NOT relax about preping, not yet.
-- Lilly (homesteader145@yahoo.com), November 24, 1999.
Cherri? Any non-perjorative, substantive rebuttals to the responses above? I, for one, am curious and still open-minded on this issue... - scott-
-- Scott Johnson (scojo@yahoo.com), November 24, 1999.
Cherri NEVERS offers ANYTHING of substance!!! NEVER!!! NEVER-EVER!!!! NEVER-EVER-NEVER-NEVER!!!!!!!! Only terse posts equivalent to, "It ain't so. 'Cause I don't want it to be so."
Plus, she appears to be the model for the expression, "ditsy broad".
-- King of Spain (madrid@aol.cum), November 24, 1999.
Kevin you dumbass:I'm looking to debunk Cherri, idiot. Read my post.
-- haha (haha@haha.com), November 24, 1999.
Uhm Jackass Kevin:By the way, where in my post did you see anything to imply that I'm a polly or I don't believe in preparing for possible Y2k problems? Where is that stated in my post? And don't try to change the subject. You're caught reading your own opinion into my post. Is asking a valid question indicative of a polly mentality? Or can't someone ask a valid question on this board, buttwipe?
Bottom line dear butthole Kevin: Don't put words into my mouth, jackass.
-- haha (haha@haha.com), November 24, 1999.
While the more pessimistic-minded are asking for Cherri's credentials, I will ask, politely, once again for R.C.'s credentials and that he "prove" them (in the same way that Dan the Power Man was asked for and provided proof).And R.C., I don't believe I had an answer to my query asking for clarification on you early August 1999 post about potential problems with the 9/9/98 date issue.
-- Johnny Canuck (j_canuck@hotmail.com), November 24, 1999.
HaHa........... cool your heels a little. The mere suggestion of Cherri having credibility at the expense of National Institute of Standards and Technology left you hanging. The majority of us here know the extent of Cherri's experience and knowledge can easily be copied on the back of a matchbook. by the way i'll take back the polly notion earlier............ ;-)
-- kevin (innxxs@yahoo.com), November 24, 1999.
Kevin:Ok, sorry. For the record, I found Cherri's post lacking in facts. I WANT to believe that things will go well, but Cherri certainly didn't prove her position too well. Hope that clears it up. Sorry for the name-calling everyone. And everyone have a great thanksgiving holiday.
-- haha (haha@haha.com), November 24, 1999.
[OK, I'll take a crack at this.Executive summary: Misuse of the date by embedded systems poses potential problems. The practical extent of this potential must be determined through proper testing. Some systems are difficult to test properly.]
INTRODUCTION
Embedded systems control much of the infrastructure of the industrialized world. If not properly addressed, problems related to the Year 2000 transition will degrade embedded systems and therefore have negative effects in the infrastructure. The most commonly recognized problem occurs when the date supplied by the real-time clock calendar (RTCC) contains a 2-digit year. This may cause a problem on or after midnight, December 31, 1999, when the date rolls over to January 1, 2000.
In those systems with this date problem, any software layer in control of the embedded system may interpret the 00 in the date as 1900, not 2000, which can potentially throw off time or date computations. 00 may also be rejected as an invalid year. In these cases, embedded systems with such problems may not operate as designed and thus cause control problems or malfunctions. If the embedded system is involved in a mission-critical or safety-critical system, there may be severe repercussions due to an embedded system failure. Proper testing is the most reliable way to identify potential embedded system Year 2000 problems. This article describes issues andpriorities for testing these systems.
[Translation: If the system has a RTC AND if the code uses the date from that RTC AND if the code uses that date incorrectly AND if the result is a functional (not cosmetic) problem AND if the system is critical AND if the functional problem is not easily addressed (depending on the details of the system and the failure), THEN we have a problem. OK, we know this.]
BACKGROUND
There are two primary areas where embedded systems typically have date problems: 1) the calculation of elapsed times, and 2) date information transmitted from one embedded system to another or to an external system.
[This might be misleading. Incorrect calculations might cause trouble. If date information is simply transmitted, that shouldn't be a problem. If the code receiving the transmission doesn't use it properly, that's just a miscalculation by someone else.]
The elapsed time problem centers on two methods for performing these calculations. One may use date information and the other may not. In method one, elapsed time is computed by subtracting a start time from an end time, e.g., 12:15 p.m. 12:00 noon = 15 minutes. If the elapsed time rolls over midnight, then the start and end dates are also required to complete the calculation, e.g., 12/30/99 12:15 a.m. 12/29/99 12:00 midnight = 15 minutes. At midnight on December 31, 1999, the rules change. In a 2- digit year, 99 becomes 00 and the computation is now 01/01/00 12:15 a.m. 12/31/99 12:00 midnight = ? One of several answers may result depending on how the date computation was carried out. On a system programmed to recognize 00 as 2000, thecomputation may be performed correctly. On many embedded systems, this may not be the case. It is impossible to say what the answer will be since the program controlling the embedded device may not be available.
[Yes, very true. This is typically a one-time bug, since it happens only on the single calculation spanning the rollover *from the perspective of the embedded clock*. However, in most such systems the actual date is irrelevant, and never set. This all depends on the system. Many such elapsed-time systems don't even have a battery for the RTC, since the real time is not important, only the interval. The failed calculation can still happen, but *when* it will happen could be anytime within a 100-year period. So this isn't a y2k problem UNLESS the date is ALSO used for some other purpose that requires it to remain synchronized with the real time and date (such as logging).]
The second method of elapsed time calculation relies on an epoch, or base date, and a time counter, which is added to the epoch to arrive at a particular date and time. An example of this method is presented elsewhere in this report.
[But this approach doesn't really use the date, so doesn't necessarily present a danger.]
Another problem of Year 2000 testing stems from three areas where date information is transmitted between devices. The first area concerns proprietary data encoding used in many embedded devices built as single units operating with other embedded devices from the same manufacturer. In these cases, the data passed from one embedded device to another cannot be read by testing instruments that were not specifically made by the same manufacturer for testing the devices in question. Third party testing instruments often do not detect the presence of dates in data transmissions that are encoded in proprietary codes. Hence, if a date is not detected, the embedded device may not be tested according to the testing policies used by some large organizations.
[Confusing! Yes, date data can be encoded in proprietary protocols, difficult to interpret. But the problem doesn't lie with the SOURCE of the date, it lies in the USE of the date. We don't really care WHERE the date came from, since that's not where the error lies. There is no functional date error until the date is misused in a calculation or decision. Even if we can read the encoded date data, this is STILL no guarantee that the receiving device makes any use of it at all. So if there is a problem, it lies with the receiver's use of the date, not with the source or encoding of the date.]
The second area involves the windowing solution used in remediation. In windowing, a pivot year is defined to express the interpretation of 2- digit years that belong in the 20th or 21st centuries. For example, a pivot year of 1950 states that all 2-digit years in the range 50 to 99 belong in the 20th century and all 2-digit years in the range 00 through 49 belong in the 21st century. If a sending device uses 1950 as the pivot year, but a receiving device uses a different pivot year, say 1990, then problems arise in the interpretation of the 2-digit years transmitted as part of a date. The sending device may see 89 as belonging in the 20th century, but the receiving device may decide that it belongs in the 21st century, thus throwing any date and time calculations off by a wide margin. The effects of this problem may be exhibited immediately as a failure if future dates are involved in the computations.
[No, this doesn't stand up to examination. I think the writer is lost. Windowing is a technique for expanding a 2-digit year to a 4- digit year by applying a pivot year. In the above example it's explicitly stated that the transmitted date is 2 digits. Yes, it's possible that the transmitter expanded the date one way, and the receiver another. Since the transmitter is only sending a 2-digit year, there is no reason for the transmitter to window that year unless it USES that year for something. The receiver does his own expansion, and uses the year for something else. If either (or both) sides use an incorrect pivot year and expand improperly, whichever side does so risks an error. But the communication between devices is not involved in any way! If the transmitter windows the year and transmits a *4-digit* year, then the receiver expects a 4-digit year and there is no confusion (though the year may be incorrect). If only the receiver does the windowing, then the transmitter has no window, which perforce cannot be different!]
The third area is based on the premise that repairs may have been made to an embedded device to correct its date and time processing, but the repairs may not have been made or may not have been made in a compatible way to a device receiving information from the repaired device. This can happen in systems where one embedded system controls or synchronizes the operation of other embedded devices, even if not all of the embedded devices have real-time clock calendars.
[I think I'd need an example to know what that paragraph is talking about. Certainly if the sending device is modified to send a larger year size, the receiving device must be modified to *accept* this new size. Otherwise NOTHING will be communicated. It's a well known truism that an interface MUST be agreed on by both sides.]
The effect is that data properly formatted to correct for the Year 2000 problem do not line up with the format expected by the receiving embedded device. For example, an embedded device may transmit a 4- digit year to a device that only understands 2-digit years. A corollary to this problem is the data offset problem whereby the last 2 digits of the year may appear to be valid to the receiving device, but the rest of the information is pushed off alignment by the 2 extra digits representing the century in the expanded date. This situation may not be caught immediately and may have long-term consequences weeks or months after the data becomes corrupted.
[But not very likely! Most embedded devices are acting in real time, and corrupting an interface (such that communications are garbled) is almost always instantly obvious. Also, give some credit for at least minimum competence to those involved. Even a child understands that teamwork implies that everyone follow the same rules.]
There are several layers in which date and time can come into play in an embedded system. These might include the application software controlling the embedded device, the interface between the real-time clock calendar and the operating system on the embedded device, and data transfers between embedded systems and other devices or external systems. An exhaustive check would include each standalone embedded device and all connected embedded devices or external sources of dates in an on-line end-to-end test. In some cases, such as in the interface between the real-time clock calendar and the operating system, special-purpose testers may be required.
[Whoa! Beyond the truism that all parties must agree on a common interface, whatever code uses the date in a calculation or decision must window that date, either explicitly (by expanding it to 4 digits) or implicitly (with logic that says IF current time is before prior time, do something reasonable). The task is to find where the date is USED, and make sure rollover won't lead to a wrong calculation or decision. The on-line end-to-end test can be used both t0 FIND who uses the date, and to make sure all such uses are done properly.]
THE PROBLEMS OF TESTING EMBEDDED SYSTEMS
Embedded systems testing is not an easy task to accomplish. Various factors play into this including the following:
Unknown embedded devices located in sealed units and components within components.
Devices with known problems that have not yet been remediated.
Difficulty in working on embedded devices because of the environment, such as those located within hazardous areas.
Hard-wired embedded components that cannot be replaced due to design issues or lack of replacement parts.
Firmware or software that has been patched, but not documented.
Lack of source code for software used in the embedded device.
Lack of a means of setting date and time, i.e., no apparent real- time clock calendar or no data entry mechanism.
[While this is all true, no effort has been made here to address the incidence of such issues. How many systems are unknown? How much date functionality lies in hazardous areas? And so on. Listing all possible problems doesn't tell us how common they are. You could make a HUGE list of all the things you could run into if you fell asleep at the wheel. But making that list longer doesn't increase the odds of falling asleep!]
Date usage that is not apparent and consequently overlooked.
This last factor is especially pernicious since many embedded devices use real-time clock calendars that were developed during the 1960s, 70s, 80s, and early 90s when the date and time were used as a single string consisting of year, month, day, hours, minutes, seconds, etc. in the form YYMMDDhhmmss. Using this type of embedded device, calculating elapsed times required the use of the date in addition to time. Later devices provided the date in the form of an epoch or base date, and a counter of elapsed units of time, typically seconds, since the epoch. For example, with a base date of 01/01/80 and a counter with the value 31,536,000 seconds, we couldcompute the date as 01/01/81. Elapsed time calculations using the counter were performed with a straightforward subtraction of the start count from the end count. The date played no part in elapsed time calculations.
[Well, no. The actual RTC hardware has individual registers containing year (2 digits), month, day of month, hours, minutes, and seconds. The operating system or application decides what to do with the values in these registers. The OS or app can create a string, or a count since the epoch, or anything else it damn well pleases. HOW it does so is hardware-independent, a function SOLELY of the software. If the hardware year source ONLY provides 2 digits, and if the year is used in a calculation then that year must be windowed explicity or implicitly. And even if the epoch and a counter is used, the counter must be STARTED based on the 2-digit year from the hardware. Windowing cannot be avoided if the hardware only supplies a 2-digit year.]
Embedded devices that do not apparently use dates in elapsed time calculations are being ignored in some embedded systems testing. This is a major oversight in the testing process since there are still embedded devices in existence that do not use the epoch and counter method, but the older date and time method.
[As I said, the epoch method requires windowing to set the original second count when the device is powered up and the OS initializes. Second, the REPRESENTATION of the time/date is totally irrelevant to the USE of the time/date. How obvious it is that a given device uses the date has NOTHING to do with the internal bit representation used for the date. And third, whether overlooking devices that make nonobvious use of the date is a *major* problem depends on how common such "hidden functionality" is. And it isn't very common. The author here really doesn't understand what's going on under the hood.]
TESTING EMBEDDED SYSTEMS
The elapsed time problem and the data transmission problems often cannot be detected in standalone device testing. Unless the tester has designed cases to test specifically for these situations, there is no guarantee that experimental end-to-end testing will detect these problems.The most accurate way to find Year 2000 problems in embedded systems is to perform on-line end-to-end testing. This is not likely to happen for several reasons.
[Very true. If a device is connected to other devices, testing must be performed on all of the connected devices. This is what Gartner called a Large Scale Embedded System. Fixes may only apply to a small part of the system, but the entire system must be tested.]
Because there are so many embedded systems in existence, not every system can be tested before January 1, 2000. In addition, testing individual or connected embedded systems and external sources of dates is a very complex proposition. The fear of damaging systems in an on-line test is probably the greatest deterrent to performing embedded systems tests, but there are methods that can be used to provide a sense of the risk involved in not testing. A suggested method entails triage by assigning a very high priority to those embedded systems in mission-critical or safety-critical applications.
[Yes, this has been done. And not all embedded systems are anywhere near this complicated or interconnected. And type-testing widely used devices is an effective method, and need not be done in situ (which may be dangerous).]
A confusing aspect of the embedded system problem is that embedded systems with real-time clocks are often used to monitor and control other embedded systems that may or may not have their own RTCC. If the controlling system fails because of a Year 2000 problem, then the controlled devices fail by definition. The question remains, did the controlled device fail due to the controlling device failure, or did it fail due to a problem in its own RTCC? There is no way to know without testing.
[If ALL the controlled devices fail at once, I'd start looking at the controller. if ANY of the controlled devices continues to operate correctly, I'd look at the controlled devices that failed.]
Some guidelines to use in testing embedded devices and sources for dates include the following:
1.Test embedded systems individually and also in concert with other embedded systems and external sources of dates in on-line end-to-end tests. In end-to-end tests, be aware of synchronization issues where multiple embedded devices are controlled by an external device or other embedded system. If complete end-to-end testing is not possible, individual subsystems can be tested to minimize any risk of system downtime.
2.Physically check for the existence of a real-time clock calendar. We recommend that manufacturers' statements of Year 2000 compliance or readiness be used only as a last resort to make any determinations since a manufacturer's definition of compliance or readiness may not meet the requirements of a particular environment.
[Not my reading, exactly. Read the available failure reports or the warnings at the websites of the manufacturers. They explain what goes wrong under what circumstances. The don't try to define "compliance" or "readiness". They say, "This device does THIS". It's up to you to decide whether the documented failure mode is critical to you.]
3.Physical testing can be accomplished through several means appropriate to the device in question. This may be accomplished through external testing instruments, signal analyzers, or test software designed specifically to look for date problems.
4.An indirect method of end-to-end testing involves setting machine test parameters and observing how the functioning of the machine changes after the embedded system senses these settings. If unexpected results occur, one or more devices may have problems.
5.Embedded systems can communicate or interoperate with other devices or with external date sources, such as PCs, workstations, databases, user input, or LANs and WANs. The data transfers between the embedded system and the external devices, users, or systems must be checked to determine if dates are being sent to or from the device in question.
[Vendors are, despite what's said here, an excellent source of such information.]
6.Both mainframe and embedded systems should be tested including devices with identical model numbers, even if they were manufactured recently.
[Easy for them to say. And maybe, somewhere, there may be a case where there is a real bug and no way to distinguish the device from apparently identical devices. The industry practice is to clearly label every firmware version. Software gets slipstreamed.]
7.Mainframe and embedded system date length compatibility should be tested though 10/10/2000. This is a primary situation in which modifying an embedded system by moving from a 2-digit to 4-digit year may cause problems in alignment of the data read by an application program. Experience in conducting embedded systems repairs found this situation to be one of the major causes of problems after fixes were effected.
[I can well believe it. You don't change interfaces lightly.]
8.Different platforms may use different time and date formats and different methods of computing date/time measurements. Therefore, interactions between different types of platforms should be tested.
[Well, these are being tested just by normal operation, if formats differ. I guess this applies to changing whole platforms that communicate with other platforms. Changeouts at that level should NEVER be tested on-line, and test coverage must be complete.]
In any of these cases, if a date or real-time clock calendar, or access to either, is found, the next step is to proceed to remediation.
[Huh? You remediate if you find errors. The mere presence of a RTC is no guarantee of error.]
CONCLUSION
The task of finding, testing, and fixing embedded systems with Year 2000 problems is a complex issue. If an organization waits to perform these tasks after December 31, 1999, then the costs can be much greater. These costs can include repairing collateral damage to systems and equipment from cascading problems and the expense in time and resources needed to find the real cause of the problem. Since there is no way to determine what combinations of factors will actually cause a failure, it may be difficult to determine when a failure has actually occurred. If a determination can be made, it may be possible to fix the problem if repair parts and technicians can be located, and the environment is amenable to making the repairs.
Testing embedded systems can be costly and time consuming, but it must be done. Not all systems have to be tested immediately. The priority should be placed on mission-critical and safety-critical systems. Each embedded system should be tested individually and in concert with interoperating systems and external sources of dates. Testing can be accomplished by looking for and physically testing existing real-time clock calendars, date processing routines in application software, device drivers that process dates, and dates from other external sources that may be communicating with the device under test through local and wide area networks. Applying the guidelines described in this article may give organizations a means of achieving a high degree of confidence in their systems.
[First, most of what's said here is common sense. Testing is important. Start with the most critical systems. The actual bugs can be hard to find in Large Scale Embedded Systems.
However, NOTHING in this article addresses the scope of the problem, only the nature of the problem for the worst cases (most complex systems). We can't logically conclude that we're in Big Trouble because hard things are hard, without knowing:
1) How numerous are these hard problems?
2) How severe are the failure modes we're talking about? This depends on both the nature of the failure and the use to which the system is put.
3) How many such problems have already been resolved? We know GM's assembly lines are working now, for example. A lot has been accomplished.
The article makes some mistakes, but it's pretty good. Just bear in mind that the purpose of this article is to address the issue of testing embedded systems. A clearer understanding of the *nature* of (part of) the problem doesn't contribute toward any understanding of the *size* of the problem. Which is not addressed here.]
-- Flint (flintc@mindspring.com), November 24, 1999.
37 days.
-- Jack (jsprat@eld.~net), November 24, 1999.
Jack,
Fortunately, we don't have to fix Y2K. The calendar is SUPPOSED to change to the year 2000 after december of this year. It's the computers and programs and chips we have to fix. Y2K isn't broken.
-- walt (walt@lcs.k12.ne.us), November 24, 1999.
-- cpr (buytexas@swbell.net), August 03, 2000.
OH PUHLEEEEEESE....CHERRY'S NONSENSE AGAIN....NOTHING HAPPENED DID IT???
Good thing cpr wasn't responsible for making sure those embedded systems that needed repair did get repaired. He apparently believes none of it needed to be fixed, not even some of the complex embedded systems often found in manufacturing.
This is from something cpr's friend Cherri posted last year:
http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001PeC
SNIP
Microcontrollers are small devices, common in almost all electronics, that have their instructions burnt in at time of manufacture and cannot be reprogrammed like software. They may have some spare addressable memory that can have a date field added but a mere one in 10,000 of these will fail and these will be impossible to identify.
Most of these devices don't even know what planet they are on, let alone the date, said Kyte.
The second category is microprocessors, programmable devices that execute code. These can be at risk if they have a real time clock mounted or communicate with a clock. Less than one quarter of a per cent without clocks are at risk, but around seven per cent with some time dependency will have problems as the clock ticks over into the next century. Only two per cent will continue to have problems once reset.
Finally, large scale embedded systems are most at risk, with more than 35 per cent expected to be non compliant. Typically found in manufacturing, oil and healthcare environments, but can even encompass things like traffic light controllers or aircraft systems. They typically include common PC components although often run proprietary or even site specific applications.
SNIP
-- The risk wasn't widespread but (it@was.real), August 03, 2000.
-- The risk wasn't widespread but (it@was.real), August 03, 2000..xxxxxxxxxxxxxxxx
"The risk wasn't widespread but ..." COULD HAVE FOOLED ME. EVERYONE OF THE DOOM PROPHETS AND ZOMBIES .........said 'can't be fixed'.
Now is "wasn't widespread". HOW ABOUT Dale (IEEE's Y2k man) "grossly exaggerated"????????
GROSSLY EXAGGERATED =======> HYPE.
-- cpr (buytexas@swbell.net), August 05, 2000.
*laugh* all the insult to me by those who did not agree with me, Not being able (or having the talant) to disprove a negitive didn't help me try to get the facts across. Odd that just before rollover people were screaming that there were too many embeddeds in inaccessable places to get fixed in time, now they are claiming they were fixed. Yea...right!By the logic of those who deridded me, I have been proven right :o)
-- Cherri (sams@brigadoon.com), August 05, 2000.
You're right, Cherri. But, you still CAN'T SPELL. And, we haven't DERIDDED ourselves of you yet.
-- cpr (buytexas@swbell.net), August 06, 2000.
I don't think I posted that.
-- cpr (buytexas@swbell.net), August 06, 2000.
"The risk wasn't widespread but ..." COULD HAVE FOOLED ME. EVERYONE OF THE DOOM PROPHETS AND ZOMBIES .........said 'can't be fixed'.Now is "wasn't widespread".
By saying the risk wasn't widespread, I was referring to something pointed out many times last year -- that the real risk was to embedded systems associated with high-level processes and not with the however many billions of chips there are out there.
I wasn't concerned last year about 'chips' in calculators, fax machines or cars. My concerns were with the smaller number of embedded systems used in areas such as these...
http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001PeC
SNIP
Finally, large scale embedded systems are most at risk, with more than 35 per cent expected to be non compliant. Typically found in manufacturing, oil and healthcare environments, but can even encompass things like traffic light controllers or aircraft systems. They typically include common PC components although often run proprietary or even site specific applications.
SNIP
-- The risk wasn't widespread (but@it.was.real), August 06, 2000.
Personally I think Paula Gordon should be held accountable for what she said and did about Y2K.And just what would that entail Cherri? A whipping? Jail time? Public dunkings? And who should do the holding of responsibility? The government?
That is about the creepiest thing I've ever seen you write.
-- Uncle Deedah (unkeed@yahoo.com), August 06, 2000.
Yes, more than a third of large scale embedded systems were noncompliant in some respect. Some of these respects were functional, and required remediation. But for perspective, bear in mind that there is almost surely not a single large scale embedded system in use anywhere without bugs in it. These bugs cause temporary problems on a continuing basis, and we live with this.Also, I suspect Paula Gordon is indeed being held accountable for her actions. Even in acadamia, one's career is hardly boosted by getting married to an issue that's both demonstrably irrelevant and obsolete. Unless she can transform her efforts into something someone cares about, she'll go nowhere.
-- Flint (flintc@mindspring.com), August 06, 2000.
Unk, to a certain degree we all must insist that P. Gordon be held accountable for her actions/mistakes, just as we are in our chosen professions. When you eat at the public trough, you must be sent to your room for bad manners. Flogging, dunking, incarceration? Nah. Flint said it right. In the end her chosen peer group will dish out the proper punishments.
-- Ra (tion@l.1), August 06, 2000.