Traffic at Rome's main railway station was disrupted for the fourth day on Tuesday 12th October as trains were rerouted and cancelled due to a malfunctioning new computer system. The station was shut down at the weekend for installation of the new command system and apparently it didn't work properly when passengers arrived Monday. Arrivals have been delayed up to 2 hours and departures by up to 50 minutes (or infinity) Source: International Herald Tribune, Wednesday Oct 13, p2 Prof. Peter Ladkin Ph.D. http://www.rvs.uni-bielefeld.de University of Bielefeld, Germany
The Washington DC Metro has had rampant failures among its electronic relays, and as a result has been running the entire system manually since April 1999. The relays had a life expectancy of 70 years, having been installed in the 1970s, with an expected malfunction rate of one every 50 years. Although the source of the premature aging is still unknown, it has been decided to replace all 20,000 relays with new ones -- which is expected to permit resumption of automatic operation by May 2000. [PGN-ed, Source: http://www.washingtonpost.com/wp-srv/local/daily/oct99/metro15.htm] "In December, a train was told to go 45 mph on a stretch of track with a 15 mph speed limit. In February, a train was directed to travel at 0 mph when it should have been ordered to move at 15 mph. And in March, a train was halted when it got a red, or stop, signal, but the rail ahead was clear, and it should have received a green signal to proceed." [Typo in 20,000 fixed in archive copy. PGN]
We recently flew from Montreal to Washington by way of Detroit (an interesting way for the deregulated market to deal with our fuel resources). A few minutes after the scheduled departure time in Detroit, the captain informed us that there would be a delay while a technician was summoned to deal with a malfunctioning computer. After inspection of the situation, it was determined that we would take off as soon as the twenty-minute shutdown procedure had been carried out. "We are allowed", said the captain "to take off even if this backup computer is not working". There was no explanation of why the builder of the aircraft would have gone to the expense of including an unnecessary computer. This may have been a quite benign situation and the policy entirely reasonable - I am not qualified to judge it - but I couldn't help wondering who did the allowing. It wasn't hard to imagine some bean counter weighing dollars against safety and deciding that such cases should be resolved in favor of expediency. Since this was an A320, reputed - fairly or not - to depend very heavily, if not excessively, on computers to stay in the air, it didn't encourage a sense of security. I would be grateful for enlightenment from someone who understands the issues. Julian Olson <firstname.lastname@example.org>
AP reports that a Y2K glitch has caused 2000 new vehicle registrations in the state of Maine to bear the classification "horseless carriage". Apparently, the DMV software misread the 2000 model year as 1900, and it is hardwired to classify any vehicle with a model year before 1916 as a horseless carriage. http://www.mercurynews.com/breaking/docs/024281.htm
The following item was reported in the UK's Silicon.Com weekly round-up: The US government admitted this week that it had accidentally issued more visas for foreign high-tech workers than it had intended - 20,000 to be precise. Why? Because of a computer glitch. Irony once again rears its ugly head and slaps the authorities around the face with a wet fish.
I'm sure that others have also pointed these out, but there are some errors in the source you used for the information on the train crash. > The latest head-on collision occurred at the same Signal 109 near Ladbroke > Grove in Western London as the collision that occurred two years ago (almost > to the day). The Ladbroke Grove crash happened on the same line, but some distance away from the Southall crash of two years previously. Signal 109 was not involved in that incident, but has been involved in near-misses recently. > The train had an Automatic Train Protection System, but it was > switched off because it was ``not operational''. Its operation might have > helped, although it reportedly would not by itself have prevented the > accident. The Great Western train from Cheltenham did have ATP which was disabled, but it would have made absolutely no difference, as the Great Western train had a green signal. At the very last minute a signal operator has noticed that the Thames commuter service had passed SN109 at danger (red), and changed SN120 to red for the Great Western service, but this was moments before the collision, far too late for even the best braking systems to have made any difference. The Thames Trains service did not have ATP. Sources for the above are the BBC News website, the *Independent* newspaper, and many hours of TV coverage (being a regular traveller on the line).
Observatory magazine (http://www.ulo.ucl.ac.uk/obsmag/) reports a NASA press release dated 11 Sep 1998 11 on the Mars Climate Orbiter which originally said: "It is 7.6 feet (25 metres) high, 6.4 feet (21 metres) deep, and 5.4 feet (18 metres) wide". This press release (http://mars.jpl.nasa.gov/msp98/news/news23.html) is still on-line but was last edited only a few days ago. Perhaps if this unconventional conversion from Imperial to Metric units had been noticed sooner, the mission might have survived? Clive Page, Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. +44 116 252 3551
We've seen many stories, over the years, of information leaking via Word documents. Perhaps the most amusing such story is reported in Salon magazine. According to http://www.salon.com/tech/log/1999/10/12/microsoft_report/index.html, Microsoft's annual report was written on a Macintosh computer...
http://www.thestandard.com/articles/mediagrok_display/0,1185,6870,00.html Cyberwarfare: The Business Opportunity Grab your digital trench coat - and your business plan. The U.S. has announced that it will enter the cyberspook business in earnest by establishing a new center to combat (and practice) online espionage. On its face, this was not a business story, and outlets played it straight, allowing generals and senators to speak gravely of cyberwarfare. But between the martial drumbeats, a few hints fell to the effect that this initiative could help U.S. businesses in a big way.
It is now finally clear to me what all the hysteria about Y2K is really all about. It is not about stingy COBOL programmers using two BCD bytes instead of four in WORKING STORAGE. It is not about embedded systems collapsing, rendering our traffic intersections, our satellite systems, and other vital technologies useless. It is about the latest in a long debilitating line of systemware products from Redmond, Washington, USA. This week I received the WinNT Magazine newsletter, with an introduction from Paul Thurrott, who describes himself as a "recovering Windows 2000 (Win2K) beta tester". Thurrott is largely positive about this monster, but does add that hardware requirements "have risen from a lowly Pentium to a 300MHz Pentium II with 128MB of RAM" and winds up by saying: "But I suspect that when the Win2K beta ends, a lot of testers are going to find themselves balking at the upgrade, at least for the short term. Suddenly, that wonderful ugly duckling we know as NT 4.0 doesn't look so bad after all." It just dawned on me - namely that the great, great majority of PC users world-wide are home computer enthusiasts, and the great, great majority of these enthusiasts use their computer primarily - or even exclusively - to access the Internet, and that they demonstrably do not need anywhere near the kind of machine necessary to run Win2K to do that, and that they don't need Win2K at all. And it dawned on me further that this would hardly change anything. Home computers running 16 bit operating systems might be perfectly capable of rendering an enjoyable cyber experience, and I believe Compaq and Netscape have shown that if one only wants to surf the net that one does not need an operating system - and one certainly does not need Windows - at all. But it would be quite unrealistic to assume that the market analysts and spin doctors in Redmond have suddenly, after decades of incredibly clumsy successes, suddenly got it all wrong. A gray shadow of unreality creeps closer, hovering, threatening, foreboding, and I can literally feel it. Here we have an operating system destined to be one of the greatest and most bugged monsters of all time offering us literally nothing most of us will ever need and forcing us, moreover, to upgrade our hardware at a great expense - and all of this is _for naught_, all of this gives 95%+ of the world's computer users absolutely _nothing_ - and yet we all know how things are going to go in the long run anyway, don't we? The boggle continues. Ballmer insisted Windows 95 would run on a 386 with 4MB RAM. I knew he had to be crossing his fingers behind his back and so I went out and bought a machine with a Pentium and a walloping 16MB RAM and it turned out I was right. Yet the quantum leap from a 386 and 4MB to a Pentium and 16MB is nothing compared to the leap expected now. I have for several years run courses in NT programming using first the NT 4 Shell Technology Update and then NT 4 itself, with MSVC running on top, with only 32MB RAM installed on low-end Pentium machines, and we have never had a hitch. We have of late attempted to demonstrate Win2K on classroom machines with far faster processors and many times the RAM and had to abandon our efforts. Windows 2000 simply peaks the CPU meter even in idle and then calmly stands still. I keep thinking about that comment from Microsoft that another RISKS reader recounted to me: "that's not the way we do things at Microsoft - when it gets too slow we just throw more hardware at it." And for those of you that followed the ripples from these forums in the Daily Telegraph's Connect supplement, yes my company today does have that "Windows Explorer" replacement mentioned there, and it does not consume a quarter of a megabyte on disk as its Redmond counterpart, but only 26KB. 26,624 bytes. As one user wrote to us: "I can finally throw that Microsoft Windows Explorer in the trash bin where it belongs." It is important to realize that our conditions were not better than Redmond's - quite on the contrary. We did not have access to, or ever consider availing ourselves of a staff several times the size of Redmond's. We did not work long hours in our offices and sleep on our futons as one is expected to do in Redmond. We just wrote the program. Like anything else we write. And over a time span considerably more realistic than Redmond used for Windows Explorer. Bloat is not unavoidable. Bloat is not a necessary evil. Bloat is always, has always been, and will always be a totally indefensible blot on computer science. I fail to see how anyone - even a band of zonked-out Microserfs - can take what was almost an operating system - NT - almost totally based on, if not identical with DEC's VMS, and systematically turn it into the biggest, most bloated bug farm in the history of computer science - and, for every turn in the road, for every day and week that went by, not _improve_ the code and make the system run _faster_, but literally _ruin_ the code and make the system run _slower_, or run not at all. I truly think that the ordinary laws of logic, of human intelligence, somehow fail to apply in the Pacific Northwest, and am starting to facetiously wonder if David Lynch wasn't onto something after all. Is Laura really Melinda French? Doesn't WHG3 have the faintest resemblance to her father, and SB a bit too much in common with Kyle's night porter? For those fanatics who said all along we should leave the big cities, that people would drop like flies in droves from the hypothermia - I am beginning to wonder. For the first time I am getting scared of the Millennium - and not for the COBOL bug, but for the Redmond Millennium Bug. The wife is now negotiating with the realtors at Prayer Lake to see if they will part with some of their precious real estate and thereby help save a few more lives. PS. Anyone who wants a further peek at this "Explorer killer" of ours to see for themselves that it really can be done is welcome to drop a line at the address below. We'll send along a complimentary copy. Rick Downes, Radsoft Laboratories http://www.radsoft.net
I've had a number of experiences making me wary of route planners, though not as dramatic as those reported in 20.62 (which I have not personally verified). Most curious are the can't get there from here journeys. The latest impossible trip I booked, ultimately with the assistance of a real travel agent, was from Indianapolis USA to Glasgow Scotland on Northwest/KLM. According to Expedia, you can't do that. According to Northwest's online booking, you can't do that. Well, of course, both appear to use the same Microsoft software. I'll grant that going to Glasgow via Amsterdam isn't the shortest way, but it is certainly possible and the only way you are going to get there on Northwest/KLM. I know you can get there from here because I've gone there from here more than once. In the same way that Internet search engines leave me wanting to know the scope of their database, harvesting policies, and details of their indexing and retrieval machinery, travel planning services leave me wanting to know more of their route planning machinery. Why though? I certainly don't worry about the algorithms my local human travel employs. It isn't about the imperfectness of the search. A human agent won't always find the optimal flight either...the first time around at least. You see, the human doesn't need a perfect search algorithm because the human agent has that amazing exception handling code known as called common sense. If the electronic travel agent has no common sense to spot suspicious results from an imperfect algorithm. When faced with a possible failure, it should should solicit help from the most convenient repository of common sense, the user. In this case, letting me tell it "Yo! Expedia! Here is a hint: Amsterdam is Northwest/KLM's main European hub. Maybe try a route through there?" would have done wonders. But not in the World According to Microsoft where users are idiots and Wizards claim a monopoly on common sense. I want smart software, but if I can't have that, I want dumb software that knows it is dumb and comes to me for help, not dumb software that thinks it is smart and tells me lies it believes to be true.
I noticed in RISKS-20.62, item 17... "Where do you want to be *mis*directed today?" ... > From: Laurel, Maryland > To: Baltimore-Washington International Airport, Maryland > Driving Distance: 5865.1 miles > Time: 9 day(s) 3 hour(s) 22 minute(s) > > Driving Directions ... > 36:35 Turn left onto Local road(s) (4543.1 mi) > 219:22 Arrive Baltimore-Washington International Airport, Maryland And then I noticed in RISKS-20.62, item 18 (yes, the next item [NO COINCIDENCE THERE! PGN])... "Maybe Microsoft owns stock in Canada?" ... > Summary > From: Hastings, Minnesota > To: Saint Charles [St. Charles], Minnesota > Driving Distance: 6758.6 miles > Time: 9 day(s) 17 hour(s) 30 minute(s) > > Driving Directions ... > 50:43 Turn left onto Local road(s) (SE 4543.1 miles) > 233:30 Arrive Saint Charles [St. Charles], Minnesota Can someone tell me -- is it really 4543.1 miles from the actual location indicated to *BOTH* St.Charles, Minnesota *AND* to Baltimore-Washington Airport? Or, similarly - if someone has the detailed directions for the first (abridged) example - do you actually end up at the same location just before the last leg? (For both of these, we would need the unabridged directions from the first example to see if the previous location was "At Bay Bulls, turn right onto S-10".) And might this location be the easternmost reachable point in North America by car? If so, this appears to be an implementation of that well-known solution to driving in the wrong direction; just drive around the world. Of course, once you run out of roads, it's clear that (1) you really can't just keep going, and (2) after all that driving, you must be at least close. Just take the local roads for that last little bit. Chris Smith <email@example.com>
Ira J. Rimson notes that printer software delivered on CD-ROM includes a utility to copy the printer drivers so they can be installed on systems that lack a CD-ROM and asks, > Am I missing something obvious here? The manufacturer is probably assuming that the customer has at least one computer with a CD-ROM, but that the printer may be used by other computers -- presumably on a network -- that lack a working CD-ROM drive. The CD-ROM probably includes drivers for a variety of operating systems, as well as PDF copies of the manual, sample images, etc. etc. CD-ROM mastering costs are quite low (on the order of $0.50 each for 10,000 copies and one-week turnaround). I suspect that adding a floppy distribution would add about $2 or more to the manufacturing cost without adding anything substantial to the overall usability of the product. So, from my point of view, it seems like a nice gesture on HP's part, rather than a chicken/egg problem. Martin Minow <firstname.lastname@example.org> [Many other similar comments. PGN]
I received a mailing from Bell Atlantic yesterday which was entitled, "Important Notice for our Brattleboro (254, 257, 258) Exchange Customers." It starts out: Because of growth in the number of telephone lines in your local calling area, your exchange will be changed from rate group 6 to 7, and rates will be affected as described below. Under the Vermont tariff (P.S.B. - Vt. - No. 20 Part A, Section 5.1.3) exchanges are classified by rate groups according to the number of telephone lines in the local calling area.... The problem is that I don't live in Brattleboro. I don't even live in Vermont. It would appear that a Bell Atlantic DB Admin searched for all Bell Atlantic telephone numbers starting with 254, 257 and 258, regardless of area code. How much do you think they wasted in postage and printing costs to send out all those bogus notices? How many hours are going to be wasted by customer service representatives answering questions about them? And why didn't somebody realize that the number of notices being sent out was more than the number of customers which could fit in three exchanges? I spoke to a very friendly Bell Atlantic customer service representatives who said that she didn't know exactly how widespread the problem was, but she confirmed that at the very least it went out incorrectly to all Massachusetts "254" customers. On the bright side, she confirmed that it also went out to all the people who were supposed to receive it. She also said she thought the mailing created "job security" for people like her. The unamusing thing about all this is that our telephone rates go up to pay for stupid blunders like this one. Jonathan Kamens
Recently I received a new credit card by mail, as an old card was soon to expire. The envelope was strangely mangled: both the outline of the credit card and the embossed numerals and letters on the card were clearly impressed in the envelope and the three layers of paper between envelope and credit card. My best guess: someone must have taken an impression of the credit card through the envelope! (The pressure must have been high, as even the black paint on the embossed numerals and letters had partially been transferred to the enclosed letter.) Needless to say, I called the credit card company and cancelled the credit card before it became active. I offered to send in the mangled envelope, but the representative said she wouldn't know what to do with it, and that she had not heard of any similar case. The risks: 1) This way of transportation is unsafe: credit card information can be captured in transit with primitive means; at least some cardboard would be needed to make sure that cards can not be imprinted through the envelope. 2) There seems to be no information gathering and warning system in place to stop new scams (possibly with high criminal energy) in its tracks. And the non-risk: unencrypted credit card transmissions might be *comparatively* safe, after all...
CALL FOR CONTRIBUTIONS The International Conference on Dependable Systems and Networks (FTCS-30 and DCCA-8) New York City, NY June 25-28, 2000 http://www.dependability.org Conference Submission Deadline: November 5, 1999 Workshop Submission Deadlines: see http://www.dependability.org The International Conference on Dependable Systems and Networks represents a new beginning in the field of dependable computing, as well as the continuation of long-established traditions. Formed from the combination of two established conferences - the International Symposium on Fault-Tolerant Computing (FTCS) sponsored by the IEEE Computer Society and the Working Conference on Dependable Computing for Critical Applications (DCCA) sponsored by IFIP WG 10.4 - this inclusive conference is designed to capture the wide range of activities in this increasingly important technical area. The conference scope spans system, software, hardware, and network issues. Major topics include, but are not limited to, Architectures for Dependable Computer Systems; Transaction Processing; Fault Tolerance in Distributed, Mobile, and Real- Time Systems; Safety-Critical Systems; Dependability of High- Speed Networks and Protocols; Quality of Service; Fault Tolerance in Multimedia Systems; Software Reliability, Fault Tolerance, Testing, Validation, and Verification; Dependability Modeling and Prediction; and Dependability in VLSI. For information and submission deadlines about the events comprising the International Conference on Dependable Systems and Networks, check http://www.dependability.org . Conference General Chair: T. Basil Smith (USA) email@example.com Conference Program Chairs: Doug Blough (USA) firstname.lastname@example.org Karama Kanoun (France) email@example.com Workshop on Dependability despite Malicious Faults Program Chair: Yves Deswarte (France) firstname.lastname@example.org Workshop on Dependability of e-business Systems Program Chair: Nick Bowen (USA) email@example.com Workshop on Dependability of IP Applications, Platforms and Networks Program Chair: Yennun Huang (USA) firstname.lastname@example.org
Please report problems with the web pages to the maintainer