Slashdot Mirror
Nuclear Materials System Not Buggy, Says Microsoft
Darkmeat writes: "Saw this on ZDNet. Looks like SQL Server was causing some problems in nuclear databases in Russia." Another similar story at Yahoo. This is a followup to this story detailing the problems.
Read the original e-mail piece. It's long, but it's well worth the read.
There a numerous issues in this article that are significantly "re-formulated" our left out - and that actually matters a lot in this case.
This article gives the impression (in my oppinion) that it is disputable wether the flaws were serious at all, and it seeks to give the impression that microsoft offered help which the russians refused.
If you read the longer original transcript, you will see that there were several other significant flaws found in 7.0 which made it unusable, and that the fix microsoft offered was "upgrade to 7.0".
The original transcripts ends with the russians expressing their deepest concern and surprise over microsoft actually suggesting them to fiddle with numeric formats etc. in order to work around real bugs that show up in SQL server.
I'm all for M$ bashing - when they deserved to be bashed (and there are plenty of areas where they deserve this). But in this case, the article is nothing more than anti-M$ propoganda.
No. The article is either pro-Microsoft spin couched as innefectual criticism or profoundly incompetently written. If you check the referenced source material you'll find that, in fact, there were severe bugs related solely to Microsoft's SQL Server which have not only compromised the Russian nuclear tracking system, but even more severely compromised the American nuclear tracking system. What is worse, the Russians were wise enough to keep their manual system intact as a check, despite ridecule from their American colleagues. The United States, on the other hand, has had no manual system or check of any kind in place. Verifying the American stockpiles will cost on the order of a Billion US Dollars and will not detect any material which has already been diverted.
Los Alamos has verified the bugs, both in the version of SQL server the Russians were using and in the version Microsoft recommended they upgrade to.
Microsoft spin and apologist propoganda aside, this fiasco is real, has truly shocking and horrifying security implications for the entire planet, and is absolutely inexcusable. Of course, inexcusable lapses on the part of Microsoft and the quality of their proprietary products is hardly new or surprising, but it remains news so long as their shoddy products continue to dominate the market through marketing misrepresentation and public ignorance of the facts.
The Future of Human Evolution: Autonomy
A complete synopsis of the email exchange released by the Center for Defense Information reveals that the flaws in Microsoft's SQL server were serious, and seriously affected both the American and Russian systems for tracking nuclear materials.
Nuclear material may or may not have been misplaced or diverted. What is certain, however, is that currently neither country has complete track of its materials as a direct result of the aforementioned software bugs in Microsoft's SQL server, and the cost of reinventorying the materials will cost on the order of one billion US dollars for the United States alone. Furthermore, if materials have been diverted from within the US inventory, the diversion will not be identified by the reinventorying methods available. This situation is unambiguously a result of the problems both teams have had with Microsoft's SQL server, coupled with the fact that the bugs weren't identified until the project was well underway.
You may deny, deny, deny as much as you like, but the public record is clear and unambiguous, and, once again, the fault lies squarely on Microsoft's incompetent shoulders.
The Future of Human Evolution: Autonomy
From the article:
Murchie said the bug was a minor problem in Microsoft's instructions for using the software and has been resolved. "It was not a product flaw."
From Neal Stephenson's essay, "In the Beginning was the Command Line":
Commercial OSes have to adopt the same official stance towards errors as Communist countries had towards poverty. For doctrinal reasons it was not possible to admit that poverty was a serious problem in Communist countries, because the whole point of Communism was to eradicate poverty. Likewise, commercial OS companies like Apple and Microsoft can't go around admitting that their software has bugs and that it crashes all the time, any more than Disney can issue press releases stating that Mickey Mouse is an actor in a suit.
Hmm. Perhaps our Russian friends are excercising a bit of well earned scepticism.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Drops one transaction in a thousand? What if instead this was installed at a major bank -- like a Federal Reserve or a National Bank?
A year or so of "dropping" 1 in 1,000 transactions could be quite a sum.
Hmmm...if any banks out there are looking for SysAdmins to implement an MS SQL Server solution -- I'm available!
--
Charles E. Hill
Learning HOW to think is more important than learning WHAT to think.
I ran a SQL Server 6.5 database that handled 7GB of data a month and processed around 21 billion transactions on that data, then countless more on the "rolled up" summaries. We had a general ledger to reconcile with and I think we would have noticed missing records if they occured every 1000 transactions. SQL 6.5 was a pain in the ass and 7.0 is a lot better. It still has some problems, but I think these reported "bugs" are more bad programmers than bad server software.
--- Don't be a player hater: I meta-mod ALL negative mods as Unfair.
I've used SQL Server for years... not because I want to, but because the company I work for prefers it. I've never seen such a problem of dropping every 1000 transactions. But there is one particular thing about this story that bugs me (no punn intended)... if the bug isn't in Microsoft's software, as they contend, then why did they tell the Russians to upgrade to a newer version to solve the problem???
---
Developers: We can use your help.
Further, Microsoft didn't offer a fix, as far as the document goes, they offered a workaround, that the russians rejected because it would mean changing about 5MB of source code.
Check the document, it's a long read, but it certainly looks like Microsoft is lyin^H^H^H incorrect.
www.lucernesys.comHorizon: Calendar-based personal finance
This doesn't really seem to shed any light on the previous articles about this. Is this just another excuse to slap Microsoft around a little bit?
--
Do not taunt Happy Fun Ball(TM)
It appears (we had no access to the source, so I can't do better than that) that if you have a complex select statement, with several nested sub-selects, you can get SQL Server into a state where it caches the query plan (roughly, the "compiled version") of some of the sub-queries from one execution to the next. This query plan sometimes acts as if it (incorrectly) includes information derived from other sub-queries as if it was constant. If in a subsequent use the value of these stored "constants" has changed, the where-clauses can fail, causeing the loss of rows in the result set.
We went several rounds of reporting it to MS, bogged down on the "can you produce a simple case that exihibits the problem" phase, and wound you instituting coding guidlines to break such queries into multiple peices using temporary tables.
Consequently I know that there are at least some bugs that are not seen by most users, and am more willing to credit this report than I was before I heard the keywords "SQL server" "complex queries" and "missing data".
-- MarkusQ
M$ just wants to acquire the resources to take on AOL-Time-Warner-Amazon...
Be part of the world's largest collaborative work of art: http://www.paintthemoon.org
I wonder how stable Windows CE for Nuclear Warheads(R) is. Of course we should expect a Mushroom Cloud of Death(TM) instead of a BSOD, though...
http://www.themeparks.ie
"It's operating as intended", Bill Gates chuckles to himself as he closes the view port on his ever growing stockpile of weapons-grade nuclear material.