From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a83c46b54bacb7f6 X-Google-Attributes: gid103376,public From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co Date: 2000/02/01 Message-ID: <2000Feb1.154122.1@eisner>#1/1 X-Deja-AN: 580503635 References: <3894A823.92EC75D1@bondtechnologies.com> <874b7r$mj9$1@nnrp1.deja.com> <38967537_1@news.jps.net> X-Trace: news.decus.org 949437685 7094 KILGALLEN [216.44.122.34] Organization: LJK Software Reply-To: Kilgallen@eisner.decus.org.nospam Newsgroups: comp.lang.ada Date: 2000-02-01T00:00:00+00:00 List-Id: In article , "Mike Silva" writes: > Firstly, shortening the development process by catching more errors quicker > is a Good Thing. Secondly, I can imagine plenty of scenarios where software > and/or hardware glitches can be captured, corrected in some manner (even if > via restart) and logged in a running pacemaker, to be analysed later, > perhaps resulting in the loading of improved code into the device (I believe > this is possible -- it certainly should be!) I doubt the possibility of a mechanism that would load improved code but decline to load degredated code. The most that can be said for the mechanism is that it can load "different" code :-).