computer reliability
in [Design]
|
Prev: Dumbed down consumer electronics: Adding DTV channels
Next: Can I run a "brushless DC FAN" backwards?
From: Rich Grise on 2 Aug 2010 18:37 On Sun, 01 Aug 2010 16:52:22 -0700, Richard Henry wrote: > On Aug 1, 4:23�pm, "JosephKK"<quiettechb...(a)yahoo.com> wrote: >> >> Subject: Tech worker: 'Blue screen of death' on oil rig's computer >> >> Gregg Keizer, *Computerworld*, 26 Jul 2010 >> >> A computer that monitored drilling operations on the Deepwater Horizon >> had been freezing with a [BSOD] prior to the explosion that sank the oil >> rig last April, the chief electrician aboard testified Friday at a >> federal hearing. >> >> In his testimony Friday, Michael Williams, the chief electronics >> technician aboard the Transocean-owned Deepwater Horizon, said that the >> rig's safety alarm had been habitually switched to a bypass mode to >> avoid waking up the crew with middle-of-the-night warnings. >> >> Williams said that a computer control system in the drill shack would >> still record high gas levels or a fire, but it would not trigger warning >> sirens, He also said that five weeks before the April 20 explosion, he >> had been called to check a computer system that monitored and controlled >> drilling. �The machine had been locking up for months. �You'd have no >> data coming through." �With the computer frozen, the driller would not >> have access to crucial data about what was going on in the well. >> >> The April disaster left 11 dead and resulted in the largest oil spill in >> U.S. history. >> >> ========== >> >> What can i say? �MS Windows should not be used for safety critical >> systems in any way. MS Windows should not be used for _any_ systems. ;-) > > Old news: > > The Yorktown lost control of its propulsion system because its computers > were unable to > divide by the number zero, the memo said. The Yorktown's Standard > Monitoring Control > System administrator entered zero into the data field for the Remote Data > Base Manager > program. That caused the database to overflow and crash all LAN consoles > and miniature > remote terminal units, the memo said. > > http://gcn.com/articles/1998/07/13/software-glitches-leave-navy-smart-ship-dead-in-the-water.aspx What kind of idiot "programmer" fails to check for a divide-by-zero condition? Maybe I'm O/C, but when I write a program that uses data, I mercilessly limit-check the data - of course, what action to take with bad data would depend on the application. And I certainly wouldn't do it on a Doze platform! <Mr. Yuck icon> Cheers! Rich
From: Rich Grise on 2 Aug 2010 18:39 On Sun, 01 Aug 2010 19:47:37 -0500, Dave M wrote: > Muzaffer Kal wrote: >> On Sun, 1 Aug 2010 16:52:22 -0700 (PDT), Richard Henry >>> On Aug 1, 4:23 pm, "JosephKK"<quiettechb...(a)yahoo.com> wrote: >>>> Found this recently: >>>> >>>> Subject: Tech worker: 'Blue screen of death' on oil rig's computer >>>> >>> Old news: >>> >>> The Yorktown lost control of its propulsion system because its >>> computers were unable to >>> divide by the number zero, the memo said. The Yorktown's Standard >>> >>> http://gcn.com/articles/1998/07/13/software-glitches-leave-navy-smart-ship-dead-in-the-water.aspx >> >> I think the following forum should be of interest to anyone using >> computers: http://catless.ncl.ac.uk/risks > > ----------------------------------------- Waaayyyy too much reading to do > in a reasonable amount of time. If you can point to any documentation > that would be applicable to the subject of this thread, please do so. > I'm not a Windows proponent, but since it's the OS that runs all of the > apps that I need and like, it's the one that I use and prefer until > something much better comes along. On a Linux system, when an app crashes it doesn't take down the whole furshlugginer system. Cheers! Rich
From: Joel Koltner on 2 Aug 2010 19:47 <krw(a)att.bizzzzzzzzzzzz> wrote in message news:qgie565q4vlml8igptmv351sr7539qie36(a)4ax.com... > On Mon, 2 Aug 2010 11:12:26 -0700 (PDT), JeffM <jeffm_(a)email.com> wrote: > No. The OS must not be *able* to be crashed by an application. *WHATEVER* > mischief the application tries to get into. BSODs are usually caused by a bug in the OS itself -- some user mode application makes a system call, and some driver or other part of the OS doesn't check parameters or whatever and -- poof! -- a bug causes a critical bit of memory to be overwritten or some important process table trashed. What people are really saying is that, "those writing device drivers and the OS itself need to be held to a higher standard than those just writing user mode apps," and I'd agree with that. Writing device drivers is also not the kind of thing you usually see beginning programmers do either (there is no, "Windows Device Drivers for Dummies" or "Windows Device Drivers in 24hrs" book out there -- yet). Nevertheless, over time there have been plenty of buggy drivers written by well-known companies that certainly had the resources to do better. E.g., some Creative Labs Sound Blaster drivers would crash and burn on multi-processor PCs, because they didn't bother to appropriate lock and synchronize access to their various queues and other data structures. They had this problem for years, and chose to ignore it because, up until the point that Intel started putting multiple cores on a single IC (and true multi-processing became inexpensive), it was only high-end users and "enthusists" with dual- or quad-CPU motherboards and Creative felt that was a tiny enough market that they could ignore it. :-( ---Joel
From: krw on 2 Aug 2010 20:27 On Mon, 2 Aug 2010 16:47:25 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:qgie565q4vlml8igptmv351sr7539qie36(a)4ax.com... >> On Mon, 2 Aug 2010 11:12:26 -0700 (PDT), JeffM <jeffm_(a)email.com> wrote: >> No. The OS must not be *able* to be crashed by an application. *WHATEVER* >> mischief the application tries to get into. > >BSODs are usually caused by a bug in the OS itself -- some user mode >application makes a system call, and some driver or other part of the OS >doesn't check parameters or whatever and -- poof! -- a bug causes a critical >bit of memory to be overwritten or some important process table trashed. Ok, but that doesn't change the point; *nothing* in user-mode should *ever* crash the OS. This failure was one caused by exactly this (invalid entry). >What people are really saying is that, "those writing device drivers and the >OS itself need to be held to a higher standard than those just writing user >mode apps," and I'd agree with that. Certainly. >Writing device drivers is also not the >kind of thing you usually see beginning programmers do either (there is no, >"Windows Device Drivers for Dummies" or "Windows Device Drivers in 24hrs" book >out there -- yet). Nevertheless, over time there have been plenty of buggy >drivers written by well-known companies that certainly had the resources to do >better. Like M$. How many times have they done kernal mode things in user mode? >E.g., some Creative Labs Sound Blaster drivers would crash and burn >on multi-processor PCs, because they didn't bother to appropriate lock and >synchronize access to their various queues and other data structures. They >had this problem for years, and chose to ignore it because, up until the point >that Intel started putting multiple cores on a single IC (and true >multi-processing became inexpensive), it was only high-end users and >"enthusists" with dual- or quad-CPU motherboards and Creative felt that was a >tiny enough market that they could ignore it. :-( Creative has always ignored reliability. Their products have *always* sucked as badly as M$, or worse. I'm surprised they've survived.
From: JeffM on 2 Aug 2010 20:37
>JeffM wrote: >>APPLICATIONS MUST NEVER CRASH THE OS. >> miso@ sushi.com wrote: >It's really hard to arm chair analyze the BSOD. > You're not keeping up with the thread. ....and the fact that the term even exists and is widely recognized is evidence that that platform is the wrong choice. 1) In 1997, the guided missile frigate USS Yorktown was dead in the water for over an hour because **an app** tried to divide by zero, showing that OS (NT) is unsuitable for mission-critical operations. The point is, on a properly-designed OS, the *application* layer shouldn't be permitted to take down the OS, thereby taking down the entire system it controls. 2) In 2010, the Deepwater Horizon was running NT (again, shown unsuitable for mission-critical operations) and was so unreliable that the operator disabled parts of the system. http://google.com/search?q="Deepwater.Horizon"+DrillWorks+%2BDrillWorks+-inurl:groups+-JeffM&hl=all http://www.oilandgasonline.com/product.mvc/DrillWorksPREDICT-0001 "DrillWorks software operates [only] on Windows 95/98/NT4.0" The logical thing for that multi-billion dollar corp to have done was 1) Stop using the unreliable OS. 2) Select a reliable OS (to which they have the source code). 3) Hire someone to write an app that does the task with the corp RETAINING FULL RIGHTS TO THE SOURCE CODE. This isn't rocket surgery. ....and while Keith criticized my syntax, *he* did get my point. Joel is leaning in the right direction too. >I've had usb soundcards lockup linux in the past. > Well, as an example, there's OpenBSD which is widely known as an extremely stable platform http://google.com/search?q=OpenBSD+Theo+audits ....and if apps are open and written to POSIX standards, they can be run on *many* platforms. ....but, when presented with a life-and-death situation, people who go immediately to *Windoze* are clearly clueless. |