computer reliability
in [Design]
|
Prev: Dumbed down consumer electronics: Adding DTV channels
Next: Can I run a "brushless DC FAN" backwards?
From: Grant on 8 Aug 2010 18:36 On Sun, 08 Aug 2010 13:11:05 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >On Sun, 1 Aug 2010 19:47:37 -0500, "Dave M" ><dgminala4444(a)mediacombb.net> wrote: > >>Muzaffer Kal wrote: >>> On Sun, 1 Aug 2010 16:52:22 -0700 (PDT), Richard Henry >>> <pomerado(a)hotmail.com> wrote: >>> >>>> 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. >> >>Also, the BSOD can be attributed to Windows malfunction or misconfiguration, >>a hardware failure, or application software failure or misconfiguration. I >>haven't heard whether the actual cause of the BSOD was ever determined. >>Until that can be known, you can't put the blame on the OS. At any rate, >>the brunt of the blame should rest on the computer tech, since, apparently, >>the problem was never resolved. > >Do you truly use anything that is not replicated in another OS? >> >>As to the the Yorktown issue, that problem was most likely an application >>software deficiency, not the OS. Any software developer worth 10% of his >>pay will trap and handle bad data entry occurrences, which is what that was. >>If the application software calculates and attempts to use a zero value in a >>calculation it should detect that and handle it so as not to crash either >>the OS or the application. > >Just the same, an OS that crashes over that is not worthy of the >appelation OS. Try, throw, catch exceptions is relatively new in programming. But... MSFT's latest MSIE-9 demo code source has an empty exception handler. So, ignoring the available error handling language constructs is as bad as using the wrong language. Management possibly think they're doing the right thing, but the reality is that code works with empty exception handlers, as long as you don't test those exceptions :( AFAIR the compiler doesn't report unhandled exception for an empty handler. So it all looks good for the reports. Fails in reality? Grant.
From: Grant on 8 Aug 2010 18:40 On Sun, 08 Aug 2010 13:16:44 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >On Tue, 03 Aug 2010 22:44:32 GMT, nico(a)puntnl.niks (Nico Coesel) >wrote: > >>"Dave M" <dgminala4444(a)mediacombb.net> wrote: >> >>>Muzaffer Kal wrote: >>>> On Sun, 1 Aug 2010 16:52:22 -0700 (PDT), Richard Henry >>>> <pomerado(a)hotmail.com> wrote: >>>> >>>>> 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. >>> >>>Also, the BSOD can be attributed to Windows malfunction or misconfiguration, >>>a hardware failure, or application software failure or misconfiguration. I >>>haven't heard whether the actual cause of the BSOD was ever determined. >>>Until that can be known, you can't put the blame on the OS. At any rate, >>>the brunt of the blame should rest on the computer tech, since, apparently, >>>the problem was never resolved. >> >>I agree here. In my experience Windows can run very reliably (uptime >>>1 year) if you have proper hardware. > >Can and usually does are not the same. I would bet that i can run XP >for 1 year at a crack so long as i do not do nay updates (which always >require a reboot). In linux i have done nearly a year, but power >failure got in the way, and i could keep the system completely up to >date. You wont get a year's uptime on WinXP if you *use* the system, and Win7 still needs regular rebooting to keep it happy. Larger memory and faster CPUs hide the issues for longer these days. And, MSFT is planning to build safe rebooting into the next windows version. That is, one may hit the reset switch and the system will reboot *without losing user data*. So much for MSFT uptime. Linux only needs a reboot to install a new kernel, and, there's an optional way around that too (see kexec). Grant.
From: Grant on 8 Aug 2010 18:42 On Sun, 08 Aug 2010 13:22:54 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >On Mon, 02 Aug 2010 11:00:07 +1000, Grant <omg(a)grrr.id.au> wrote: > >>On Sun, 01 Aug 2010 16:23:33 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >> >>> >>>Found this recently: >>> >>>++++++++++ >>> >>>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. >> >>Related story in latest comp.risks says they turned off the alarm >>system at night so workers could sleep and not have to wake up for >>the frequent false alarms at 3:30 :( >> >>Grant. > >Kind of a clue that some serious things were let to just slide. If i >managed a $100 million rig and there was some sloppy and safety >critical software like that, the programmer would be on the rig >troubleshooting it 24/7. And maybe his boss to boot. But that's the point, no? Lots of places take the same risks, yet they're only found out after disaster strikes. Risk management :( I suppose BP and their contractors are still in front, if not, they'll call on the govts to fix things, like the failing banks did. We live in corrupt times. Grant.
From: JosephKK on 11 Aug 2010 00:44 On Mon, 09 Aug 2010 08:36:07 +1000, Grant <omg(a)grrr.id.au> wrote: >On Sun, 08 Aug 2010 13:11:05 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: > >>On Sun, 1 Aug 2010 19:47:37 -0500, "Dave M" >><dgminala4444(a)mediacombb.net> wrote: >> >>>Muzaffer Kal wrote: >>>> On Sun, 1 Aug 2010 16:52:22 -0700 (PDT), Richard Henry >>>> <pomerado(a)hotmail.com> wrote: >>>> >>>>> 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. >>> >>>Also, the BSOD can be attributed to Windows malfunction or misconfiguration, >>>a hardware failure, or application software failure or misconfiguration. I >>>haven't heard whether the actual cause of the BSOD was ever determined. >>>Until that can be known, you can't put the blame on the OS. At any rate, >>>the brunt of the blame should rest on the computer tech, since, apparently, >>>the problem was never resolved. >> >>Do you truly use anything that is not replicated in another OS? >>> >>>As to the the Yorktown issue, that problem was most likely an application >>>software deficiency, not the OS. Any software developer worth 10% of his >>>pay will trap and handle bad data entry occurrences, which is what that was. >>>If the application software calculates and attempts to use a zero value in a >>>calculation it should detect that and handle it so as not to crash either >>>the OS or the application. >> >>Just the same, an OS that crashes over that is not worthy of the >>appelation OS. > >Try, throw, catch exceptions is relatively new in programming. > Only over 20 years old, i was using constructs of that nature by 1987. Plus, i think it was standardized in "C" in 1999. Plus "assert" goes all the way back to K&R days. >But... > >MSFT's latest MSIE-9 demo code source has an empty exception handler. > >So, ignoring the available error handling language constructs is as >bad as using the wrong language. Management possibly think they're >doing the right thing, but the reality is that code works with empty >exception handlers, as long as you don't test those exceptions :( > >AFAIR the compiler doesn't report unhandled exception for an empty >handler. > >So it all looks good for the reports. Fails in reality? > >Grant. Wouldn't know, i don't expect to ever test MSIE-9.
From: Paul Keinanen on 11 Aug 2010 01:20
On Tue, 10 Aug 2010 21:44:47 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >On Mon, 09 Aug 2010 08:36:07 +1000, Grant <omg(a)grrr.id.au> wrote: >>Try, throw, catch exceptions is relatively new in programming. >> >Only over 20 years old, i was using constructs of that nature by 1987. >Plus, i think it was standardized in "C" in 1999. Plus "assert" goes >all the way back to K&R days. Nested exception handling is nothing new, there was a complete chapter about it in the VAX/VMS Architecture Handbook from the mid 1970's. |