Loading ...
Sorry, an error occurred while loading the content.

[techbooks] REVIEW: "Deadline Y2K", Mark Joseph

Expand Messages
  • Rob Slade, doting grandpa of Ryan and Tr
    BKDLNY2K.RVW 990428 Deadline Y2K , Mark Joseph, 1999, 0-312-20202-4, U$24.95/C$34.99 %A Mark Joseph %C 175 Fifth Ave., New York, NY 10010 %D 1999 %G
    Message 1 of 1 , Jun 11, 1999
    • 0 Attachment
      BKDLNY2K.RVW 990428

      "Deadline Y2K", Mark Joseph, 1999, 0-312-20202-4, U$24.95/C$34.99
      %A Mark Joseph
      %C 175 Fifth Ave., New York, NY 10010
      %D 1999
      %G 0-312-20202-4
      %I St. Martin's Press
      %O U$24.95/C$34.99 212-674-5151 fax 800-288-2131 www.stmartins.com
      %P 294 p.
      %T "Deadline Y2K"

      First of all, I have to say that after the halfway (or maybe two
      thirds) point, I really got into this book. The action is tense,
      interesting, and well thought out. The geeks save the day, even
      outclevering the semi-evil capitalist.

      That said, I'll go back to the opening I originally intended to use
      for this review:

      The Bad News is that Joseph figures we're all gonna die, or a
      reasonable facsimile thereof.

      The Good News is that Joseph gets so much else wrong that, based on
      the fact that he predicts disaster, we'll probably have a fairly easy
      time of it. The author has a deep, profound, and abiding lack of
      understanding of Y2K.

      The one concept he does seem to understand is that the most serious
      Y2K problems arise from the interconnected nature of modern systems,
      and the fact that small problems, added, multiply themselves. This is
      good, and is used to good effect at times in the story.

      The list of negative accomplishments is rather longer. Lets start
      with stereotypes. We have magic bullet Y2K fixing software. We have
      the traditional, mythical salami scam. We have the hygienically
      challenged genius hacker. (Who starts out as a completely
      irresponsible flake, and suddenly transforms into a dedicated,
      managerial, recruiting, social worker.) We have the multi-millionaire
      tycoon having his bagel every morning and shooting the breeze with the
      boys from the old 'hood. (This is the same guy who alienates his wife
      and kid by never having time for them.)

      Then there are specific technical errors. The credit card companies
      hit the Y2K wall in 1997 because of expiration dates, and therefore
      have generally dealt with the issue. There will not be a sudden
      collapse of the credit card system in the hours just before midnight,
      December 31, 1999. (In fact, a large number of failures in the book
      happen in the last few hours of 1999, rather than months or years
      before, or slightly after.) The failures of old GPS (Global
      Positioning System) terminals that will happen in August of 1999 have
      a very vague and conceptual relation to Y2K in that the problem
      results from a "number of weeks" field that is limited to ten bits.
      It has nothing to do with a sudden change of format.

      And I have no idea why you need to calculate dates in order to tell
      the difference between O positive and O negative blood.

      Then there are the more general mistakes. One platform definitely
      does not fit all: it is highly unlikely that a single IBM mainframe
      could accommodate all the control programs from a power utility, civic
      infrastructures, telecommunications companies, and transit
      authorities. (Nobody snuck a VAX or a UNIX box into the mix anywhere?
      Besides, I understand that the New York subway still has drivers. But
      you could check with Bombardier ...) It is also unlikely that a
      single mainframe could handle the processing load required to run all
      of them concurrently. (We will ignore, for the moment, the likelihood
      of a small band of geeks being able to fulfill all the checking that
      large corporations were unable to do. *And* get it to run right the
      first time they do a smoke test ...)

      There is no reason that someone supplying utility software would have
      any need to access full bank data records. Yes, there is a T-4, and,
      yes, it is bigger than a T-1 or T-3. But almost nobody uses that
      designation: it just isn't that useful in discussing the bandwidth
      bundles that are provided.

      And I don't care what von Neumann said, a data file, even a very large
      data file, is *not* the same as code. Yes, if someone was careless, a
      very large data file could possibly overrun its bounds and crash a
      system, but there would be no difference between a store completely
      restocking and a store starting up for the first time, now would there
      be?

      Joseph's dialogue is readable, although not particularly great. His
      characterizations could use some work. At one point (page 166)
      someone goes from being "amused and thrilled" to being ready to "die
      of anxiety" in the space of one sentence, with nothing happening in
      the interim.

      Entertaining, yes, but only after you get through the annoying bits at
      the beginning.

      copyright Robert M. Slade, 1999 BKDLNY2K.RVW 990428

      ====================== (quote inserted randomly by Pegasus Mailer)
      rslade@... rslade@... slade@... p1@...
      It is bad to suppress laughter;
      it goes back down and spreads to your hips.
      http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

      ------------------------------------------------------------------------

      eGroups.com home: http://www.egroups.com/group/techbooks
      http://www.egroups.com - Simplifying group communications
    Your message has been successfully submitted and would be delivered to recipients shortly.