"SfR Fresh" - the SfR Freeware/Shareware Archive

Member "mpdist-3.7.1/Data/NewsDigest" of archive mpdist-3.7.1.tar.gz:


As a special service "SfR Fresh" has tried to format the requested source page into HTML format using source code syntax highlighting with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. That can be also achieved for any archive member file by clicking within an archive contents listing on the first character of the file(path) respectively on the according byte size field.
    1 From swan!bbn.com!nic!bunny!husc6!rutgers!tut.cis.ohio-state.edu!ucbvax!CSL.SRI.COM!risks Thu Jul  5 10:07:45 EDT 1990
    2 Article 85 of comp.risks:
    3 Path: swan!bbn.com!nic!bunny!husc6!rutgers!tut.cis.ohio-state.edu!ucbvax!CSL.SRI.COM!risks
    4 >From: risks@CSL.SRI.COM (RISKS Forum)
    5 Newsgroups: comp.risks
    6 Subject: RISKS DIGEST 10.14
    7 Message-ID: <CMM.0.88.646701765.risks@hercules.csl.sri.com>
    8 Date: 29 Jun 90 23:22:45 GMT
    9 Sender: daemon@ucbvax.BERKELEY.EDU
   10 Reply-To: risks@csl.sri.com
   11 Organization: The Internet
   12 Lines: 208
   13 Approved: risks@csl.sri.com
   14 
   15 RISKS-LIST: RISKS-FORUM Digest  Friday 29 June 1990   Volume 10 : Issue 14
   16 
   17         FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS 
   18    ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
   19 
   20 Contents:
   21   RISKS WILL BE ON VACATION (RISKS Forum)
   22   Hubble (Dimitri Mihalas via Mark Bartelt)
   23   Re: "Unbreakable Math Code Finally Broken" (Richard A. Schumacher)
   24   More on the Risks of searching the Lexis fulltext database (Peter D. Junger)
   25   Re: info on carpal tunnel syndrome (Terry Kane)
   26 
   27 The RISKS Forum is moderated.  Contributions should be relevant, sound, in good
   28 taste, objective, coherent, concise, and nonrepetitious.  Diversity is welcome.
   29 CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
   30 (otherwise they may be ignored).  REQUESTS to RISKS-Request@CSL.SRI.COM.
   31 TO FTP VOL i ISSUE j:  ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
   32 cd sys$user2:[risks]<CR>GET RISKS-i.j <CR>; j is TWO digits.  Vol summaries in 
   33 risks-i.00 (j=0); "dir risks-*.*<CR>" gives directory listing of back issues.
   34 ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
   35 
   36 ----------------------------------------------------------------------
   37 
   38 Date: Fri, 29 Jun 1990 13:34:45 PDT
   39 >From: RISKS Forum <risks@csl.sri.com>
   40 Subject: RISKS WILL BE ON VACATION
   41 
   42 for the next three weeks.  There might be an issue or two, but don't bet on it.
   43 Keep sending in the good stuff in any case.  Thanks.  The Management
   44 
   45 ------------------------------
   46 
   47 Date: Fri, 29 Jun 90 13:20:14 EDT
   48 >From: Mark Bartelt <sysmark@orca.cita.utoronto.ca>
   49 Subject: Hubble
   50 
   51 [This is a message from Dimitri Mihalas (dmihalas@altair.astro.uiuc.edu).
   52 Mark Bartelt, Canadian Institute of Theoretical Astrophysics]
   53 
   54 in case you have not heard: from a reliable inside source i found out that the
   55 problem with ST is that the SOFTWARE driving the polisher was defective. the
   56 corrections for spherical aberration were put in with the wrong sign.
   57 consequently the mirror is not corrected for sph. abb., but has an added dose
   58 of it.
   59  
   60 the error was not detected during testing because no test with collimated
   61 light was ever done. (editorial remark: unthinkable!) apparently this was
   62 a $30M economy measure in the face of the Challenger accident. likewise
   63 none of the optics were ever tested in vacuum. the primary was and is
   64 "perfect" relative to the specified curve; but alas the specification
   65 was wrong. sigh.
   66  
   67 from my amateur astronomer days (does that include 1990?) i recall that
   68 spherical aberration is EASY to detect with the foucault test, which is
   69 done with a pinhole, not collimated light. it is hard to believe that
   70 ANYONE could have made such a blunder..
   71  
   72 the only reason that people know this much is that the same software
   73 was used for AXAF. the errors there were so huge as to be immediately
   74 noticeable, and when the software was corrected, the mirror was "perfect".
   75 i don't know whether the information from axaf was available prior to
   76 the launch of ST, but it seems that it had to be. in which case one
   77 wonders why PE didn't issue a "hold everything!".
   78  
   79 the future: no chance of bringing the whole telescope down for a refit.
   80 best plan is to design compensating optics into the lightpath for future 
   81 instruments: relatively easy to do. but that will still take 3-5 years.
   82  
   83 i suppose it's "win a few, lose a few..." but i personally think that
   84 nasa, the government, and the people should stick it into PE and TURN
   85 it hard until they agree to refund the cost of the mistake and of the repairs.
   86 i'm sick of seeing defense and defense-related contractors get away
   87 with bloody murder and just get fatter and fatter on the profits.
   88  
   89 back to theory
   90 dimitri
   91 
   92 ------------------------------
   93 
   94 Date: 28 Jun 90 18:02:18 GMT
   95 >From: schumach@convex.UUCP (Richard A. Schumacher)
   96 Subject: Re: "Unbreakable Math Code Finally Broken"
   97 References: <CMM.0.88.646532535.risks@hercules.csl.sri.com>
   98 
   99 Y. Radai <RADAI1@HBUNOS.BITNET> writes:
  100 >  So the statements that an impenetrable code has been broken and that
  101 >organizations need to change their cryptographic systems because of this
  102 >achievement seem a wee bit exaggerated.
  103 
  104 On the other hand, the NPR report mentioned that the Bank of England
  105 was planning to use a 150 digit number as a key in a new transaction
  106 processing system, but changed it to something "much larger" when
  107 they learned of the 9th Fermat prime factoring.
  108 
  109 ------------------------------
  110 
  111 Date: 29 Jun 90 16:25:00 EST
  112 >From: junger@cwru.cwru.edu
  113 Subject: More on the Risks of searching the Lexis fulltext database
  114 
  115         A while back I sent to RISKS an (itself rather buggy) description of a
  116 bug that turned up in the Lexis/Nexis database when I was doing date delimited
  117 searches in the library containing the fulltext opinions of the United States
  118 Supreme Court.  A representative of Mead Data Central--the owner of the
  119 Nexis/Lexis service--has since contacted me to explain the nature of the bug
  120 and to assure me that it will be corrected on June 30.
  121 
  122         In the first place, it appears that the bug is _not_ in the
  123 basic software that searches through the database for cases decided on,
  124 after, or before a specified date.  Secondly, it is clear that the bug
  125 did _not_ cause me to miss any cases that I should have located, it just
  126 turned up some additonal cases that were not decided within the period
  127 that I was searching.  That is the good news.
  128 
  129         The bad news is that the problem relates to the way that the
  130 Lexis/Nexis system parses dates in the database and that the proposed
  131 fix will work only until the year 2000, at which time a new variant of
  132 the bug should cause real havoc.
  133 
  134         Here is a corrected version of the type of search that exposed
  135 the bug:
  136 
  137         Entitlement and date(aft 12/31/39 and bef 1/1/50)
  138 
  139 That search, when conducted in the Supreme Court file, should find all
  140 opinions, and only those opinions, decided by the United States Supreme
  141 Court during the decade of the 1940's that contained the word
  142 `entitlement'.  (Lexis warned me that it assumed that I meant after
  143 12/31/1939 and before 1/1/1950.)  As it happens, there are no cases that meet
  144 those criteria.  But Lexis reported that it had found a dozen or so
  145 cases--cases that did contain the word `entitlement' but that were
  146 decided in the 1960's, 70's, and 80's.
  147 
  148         It seems that a couple of months ago Mead Data Central decided
  149 to include the argued-date as well as the decided-date within the date
  150 field, and it is this enhancement that caused the bug.  The fix that
  151 will be implimented this Saturday is to once again exclude the
  152 argued-date from the date field.
  153 
  154         Since cases are not always decided in the same year that they
  155 are argued, including the argued-date in the date field will, of course,
  156 cause some cases to be reported as occurring in two different decades,
  157 which would be a nuisance.  But that is only a miniscule part of the
  158 bug.  The real problem occurs because some cases are argued on more than
  159 one date, so that the argued-date field would appear in the database as,
  160 say:  "argued June 22-23, 1980" and the decided date field as: "July 3,
  161 1980)."  At first glance that would not seem to cause any problem.  And
  162 it wouldn't, except for the fact that the Lexis system parses the date
  163 fields in the same way that it parses user input, and thus concludes
  164 that "June 22-23" means "June 22-1923".  Thus our hypothetical case
  165 would have a date of July 3, 1980 (which is after December 31, 1939) and
  166 would also have a date of June 22, 1923 (which is before January 1,
  167 1950).  If that case--decided, you will recall, in 1980--contains the
  168 word `entitlement' it will turn up in my search for cases in the decade
  169 of the 1940's, and in my searches in the 1950's, and in the 1960's, etc.
  170 
  171         I can understand why the system parses user input so as to
  172 interpret 1/1/50 as 1/1/1950--but I never dreamed that a system would
  173 parse its own data.  According to the people at Mead Data Central,
  174 however, their system parses the data fields in exactly the same way
  175 that it parses user input.  It seems that the Lexis/Nexis database
  176 contains texts--especially news reports--with dates in the form
  177 "nn/nn/nn". Today those dates are parsed as "nn/nn/19nn", but what is
  178 going to happen in the year 2000?
  179 
  180         It would seem that ambiguous data in the data base will be much
  181 harder to find and fix than a software bug.
  182 
  183 Peter D. Junger, CWRU Law School
  184 
  185 ------------------------------
  186 
  187 Date: 29 Jun 90 19:36:47 GMT
  188 >From: tok@stiatl.UUCP (Terry Kane)
  189 Subject: Re: info on carpal tunnel syndrome (CTS)
  190 
  191 I am a long time sufferer of CTS.  The first symptoms I recall were during
  192 high school, nearly twenty years ago, but it was not properly diagnosed
  193 until I was in excruciating pain, dropping things, not sleeping because
  194 my hand was burning at night and more, all about four years ago.
  195 
  196 Tests said that I had "a very mild case"!?  That reassuring info did not
  197 make my hand better.  I used splints, Motrin, ice until I finally insisted
  198 on the carpal tunnel relief operation.  That was two years ago, this month,
  199 but I still have recurrences - especially when I meet the same RISK which
  200 pushed my CTS over the edge: using a MOUSE.
  201 
  202 The typical mouse promotes all the bad habits that can result in CTS symptoms.
  203 One typically rests the heel of the palm on the mouse, and press the chord
  204 keys - frequently with constant pressure (on Apple's mice, the required
  205 pressure is substantial for me, and their new mouse reqlly aggravates the
  206 problem with its stylized, aerodynamic "look").  I cannot use a mouse to this
  207 day without suffering a "mouse hangover".
  208 
  209 Track balls are better for me, but I still would rather avoid them.
  210 
  211 I am really looking forward to _getting_my_hands_on_ ;-) a touch screen.
  212 I've seen some very nice ones with quite satisfactory resolution!
  213 
  214 And please - If you think that you might have CTS - don't waste time.
  215 			See Your M.D.
  216 
  217 Terry Kane, Sales Technologies, Inc, Atlanta, GA  (404) 841-4000
  218 
  219 ------------------------------
  220 
  221 End of RISKS-FORUM Digest 10.14
  222 ************************
  223 
  224