Slashdot Mirror
Losing Track of Nuclear Materials
As it so happens, I know a bit about accounting for nuclear materials at DOE facilities, since I've written a system to do just that (not the one in question, fortunately for me). There's a good basic description of the flawed inventory system available from a Russian site. It's a custom application built on Windows NT and SQL Server, and the application itself was almost certainly not written by Microsoft but by some consulting firm hired by the Department of Energy. (I don't know that it wasn't Microsoft who did the consulting, but it would surprise me.)
So rather than being a "risks of Microsoft software" story, this is a story in general about the risks of highly complex, closed-source code.
About ten minutes after Little Boy turned Hiroshima into an ex-city, the U.S. realized the importance of tracking the raw materials for nuclear weaponry. Enriched uranium and plutonium, primarily, but also many other materials that are fissionable or can be used in nuclear weapons. (Incidentally, you can possess uranium ore in its natural state without a Nuclear Regulatory Commission license - only if you try to enrich it do you run into problems. :)
Accounting of U.S. nuclear materials is handled through a system/organization called NMMSS, the Nuclear Materials Management and Safeguards System. This database was started in the Days of Yore, when men were men and computers were room-sized with lots of blinkenlights. This database was originally designed to accept 80-column punch-cards - lots and lots of punch-cards. Each punch-card could be part of an inventory received from some U.S. facility that handled nuclear materials, or part of a transaction indicating the transfer of nuclear materials from one facility to another, or any other data that needed to be entered into the database.
At the end of the day, the system would grind over the data entered, looking for problems. For instance, facility X says they sent 10 kilos of plutonium to facility Y, and facility Y says they received 9 kilos of plutonium from facility X - red flags go up, alarms ring, troops are dispatched.
The system has been modernized once or twice, and modified many, many times to take account of changing developments in nuclear science ("hey, this isotope can be used in making super-bombs - better track it too!"), changing regulations, and changing technology. But no one wants to screw it up, so modifications are always the minimum needed. So today, DOE facilities don't send punch-cards anymore - they can send their information via encrypted email or secure dial-up connections. But the data transmitted is still in 80-column formats, a legacy of the punch-cards. Each facility runs some sort of inventory system which tracks things at their facility, and submits various reports up the chain to NMMSS. It's all computerized - but there are massive legacies of the predecessor systems.
After the end of the Cold War and Soviet break-up, the U.S. DOE starting sweating about poor Russian control of nuclear materials. The U.S. has sent significant assistance to the former Soviet Union to aid them in accounting for and tracking materials that could be used in building nuclear weapons. The U.S. has also purchased a large amount of "excess" nuclear material from the former U.S.S.R., and the U.S. and Soviet inventory systems are at least partially merged now - at least some Soviet facilities submit inventory reports to NMMSS now, and so transactions of materials between U.S. and Russian facilities can be handled much the same way as transactions between two U.S. facilities. Naturally the U.S. donated their custom facility inventory software, which was probably developed at extraordinary expense, running on NT and SQL Server.... and now we're back to the original article.
At this point you know as much as I do. I don't know what flaw caused the loss in inventories that was described in the article, whether it was a flaw in SQL Server or the custom application written on top of it. I do know that any significant inventory loss would almost certainly be detected elsewhere in the chain -- NMMSS would note that the inventory was X kilograms one month, (X-Y) kilograms the next month, and wonder what happened, even if no one at the actual facility did. So my suggestion is to take the $1 billion estimate in the article with a grain of salt. Probably the flaw isn't that bad, probably it occurred in a repeatable manner and the data can be found or reconstructed (there are many checks and safeguards built-in to all of these systems to detect errors or attempted fraud). The most probable "attack" against the inventory system was a bad employee, attempting to divert nuclear material for financial gain. But the safeguards should suffice to detect systemic errors as well.
This is the first reference I could find on Google. If you search, you will find others. These are the largest, documented, publicized nuclear fuel thefts.
http://www.arabmedia.com/jnucler.html
[snip]
The most notorious instance, fully uncovered by the American intelligence in 1967, involved the Israeli theft of several hundred pounds of enriched uranium from the U.S. Nuclear Material and Equipment Corporation (NUMEC) facility in Apollo, Pennsylvania with the alleged help of its American director, Zalman Shapiro.4 While the evidence was not sufficient to convict the principal involved, there was a "clear consensus" within the CIA that the nuclear materials in question had been diverted to Israel and used by the Israelis for nuclear weapons manufacture.5 Indeed, Shapiro was known to have maintained extraordinarily intimate relations with the Israeli government and its nuclear scientific community during his tenure at NUMEC. Other known instances of Israeli theft of nuclear materials include hit-and-run tear-gas attacks by the Israelis against uranium-laden trucks belonging to the government of France, their former nuclear benefactor.
British nuclear cargo was similarly hijacked by individuals suspected of working for Israeli intelligence. A fourth instance involves the temporary seizure of a ship registered to what was then West Germany, from which 200 tons of yellowcake (uranium used as nuclear fuel) subsequently disappeared, an instance the U.S. intelligence has also attributed to Israel.
[snip]
it was actually trackn~1.dll
The problem is not that the code didn't get peer review (how many people would actually search through this looking for bugs and report ones they found? Would anyone else actually want to use this?), but that it didn't get redesigned for clarity. Something like this should be reworked to the point where everything is obviously correct.
Apparently, this has been going on for about 10 years.
From the actual story:
By [the Russians'] calculations, an enormous amount of Russia's nuclear material... would disappear from their accounting records if Russia were to use the flawed U.S. software program for 10 years.
Please, please, please read what you're writing about before you write about it!
-- Old Man Kensey
The report states quite clearly that the bug was in SQL Server 6.5. Of course, it's near impossible to build large scale software without bugs, but at least open source software could in theory be debugged by the end user.
It depends on the isotope. Po-209, for example, has a half-life of 105 years.
Right, but they use the hot isotope for a reason. If you use a slower-decaying isotope, you reduce the probability that the initiator will produce a neutron at the critical instant when it is needed.
You want the polonium to be spewing out alpha particles constantly, to maximize the probability that the system will produce that one critical neutron exactly when it is needed.
Pu 239 has a half-life of approximately 24,000 years, so for all practical purposes it is stable and doesn't need to be rotated.
However, inside each weapon is a small device called the initiator. The initiator is made of beryllium and polonium-210, and is inserted in the center of the plutonium sphere.
When the bomb is detonated, the plutonium sphere implodes, crushing together and mixing the beryllium and polonium. The polonium gives off alpha radiation, and beryllium emits neutrons when hit by alpha radiation. One reference says that the number of neutrons given off by the initiator is around five or six. All it takes is one neutron to start the fission chain reaction.
The initiator only has a few microseconds to emit the necessary neutrons. It's considered to be one of the most critical and difficult aspects of nuclear weapon design. A great deal of information has been published about nuclear weapon design, but information about initator design is never published.
Polonium has a half-life of only 138 days. So, even though the plutonium itself decays very slowly, it is the initators that must be regularly replaced.
Somebody is going to set up... eh fuck it.
--
A plutonium bomb (implosion device) is a complex design. There are a lot of things that can go wrong.
A U-235 bomb (gun device) is considerably simpler, but inefficient in its use of fissionable material.
Someone who got their hands on a sizable quantity of highly enriched uranium could easily build a nuclear weapon.
Mea navis aericumbens anguillis abundat
You are correct that an implosion device can use uranium or plutonium.
I'll have to check out Project Urchin.
Mea navis aericumbens anguillis abundat
Most likely the problem lies in how MSSQL os called. over 95% of database errors I come across are due to the database being called incorrectly or just purely crap code. (And having visual basic used for the frontends doesn't help either.) The problem lies when a client flakes out during a database process because the programmers are morons. instead of issuing a simple change Column A to "text" where look1=look2 and letting the server do all the hard work you get these visual basic programmers that havent a clue about SQL having a damned loop changing things one item at a time. causing a huge load on the SQL server and making everything horribly unstable. (Gee, we are issuing database locks like mad over and over increasing our chances to have collisions.)
WE use a product called Novar for our traffic and billing here, and it's the worst written software on the planet. (Their 1.0 product was better than the 2.0) and every problem we have with the database can be linked back to the application and it's shoddy programming. (by my detective work, they wont admit it.)
I hate to support MS but in this case I highly doubt that MSSQL is causing any problems like this.
Do not look at laser with remaining good eye.
I don't think that opening the code is automatically a bad thing, but in this case I don't think it would help too much. Open source code improves when people look at it, and people look at it when they use it and have problems with it. This was a custom system written for exactly one customer, and you can bet the DOE could have (and maybe did) get the source code if they wanted to. Making this system open source wouldn't have helped much since there really wouldn't be enough eyes looking at it to make the bugs shallow. In the worst case, the only people looking for flaws would be the people with something to gain from the flaws - black hats. You really only want something to be open source if you can be sure that there will be enough white hats contributing to balance out that risk, or if it's a program that has very minimal security implications, like gEdit or something like that.
That's assuming that the problem really was in the custom app and not in NT or MSSQL, but I assume any bugs where MSSQL quietly "disappears" certain information would be common knowledge by now...
Your right to not believe: Americans United for Separation of Church and
I'd like to apologize for the missing nuclear materials. See, the uranium & whatnot was piping hot, and you know how similar hot uranium and hot grits look.. So I accidentally poured hot uranium down my pants.
Thank you.
I was in college in the mid-1980's. College itself was an interesting experience. Coming straight from conservative, agricultural, clean country into liberal, urban, polluted university was a shock.
I remember when the US "invaded" Grenada. What a weird day (and day after) that was. Quite a view university folks were in fear of a nuclear exchange of some kind.
Oh, and my graduation was marred by a two hour commencement address by Herb Marcuse who told us how we had nothing to look forward too. There were no jobs because of Reagan. We would catch aids because of Reagan. We would have to wear gas masks because of Reagan's pollution. We would be arrested by Reagan's brownshirt thugs. Nuclear conflagration was inevitable. Gaagh!
A Government Is a Body of People, Usually Notably Ungoverned
> The editorial says "Microsoft software," but it almost certainly isn't.
What they meant was, it's Microsoft software in spirit, if not in the flesh.
--
Sheesh, evil *and* a jerk. -- Jade
for the curious, what is that secret city called? do you have any other references to learn more about it?
i am fascinated.
it's a feature. This way, the US can actively reduce both nuclear stockpiles without the hassle of a treaty. =)
---------The early bird gets the worm, but the second mouse gets the cheese.
There's been a well known bug in TrackNuclearShit.DLL since Win 3.11, and MS has refused to patch it.
I think if you upgrade to IE 4.1 128 bit security, then disable javascript, but be sure to install MSN wallet software, then things work.
UNLESS, you're on SP 3 Win NT 4, at which point install the ATI drivers for the All in wonder card from a command line ONLY. Then remove the card with some BBQ tongs and put it in a shed. Do not look at the card for 3 weeks, then quickly put it back in wrapped in tinfoil. Turn the computer upside down. Leave it along for 8 minutes, then quickly apply mayonnaise to the front panel.
There, that should do it.
Modern nuclear explosives use electronic neutron generators. They do not wear out.
do a search for mc4380
You might also want to check out the nuclear weapons databook by hansen & friends.
enough is too much
Not quite right.. The reason the plutonium bombs (Little Boy and Trinity) were implosion devices is because they were initially afraid they couldn't scare up enough plutonium, and because having a totally sub-critical bomb was prolly a bit safer.. You can build a gun-type from any supra critical amount of either, and a implosion type from any slightly sub critical mass of either.
Otherwise how do you explain Project Urchin?
.sig: Now legally binding!
http://www.findarticles.com/m1111/n1782_v297/21281 407/p1/article.jhtml
Just a fun article . . .
So does this mean that data about radioactive materials itself has a half-life? No wonder I can't remember my college physics classes! All my memories decayed!
I have zero tolerance for zero-tolerance policies.
Constitutionally Correct
In addition to supposed lost Russian nuclear material, actual lost US nuclear weapons and accidents are equally worrisome and more common than anybody realizes, with over a dozen VERY major incidents detailed here. There's even a monument to the 1957 Broken Arrow incident in New Mexico. If you've got $20 to blow, you can even get a nostalgic guided tour of all these Broken Arrow events narrated by Batman himself, Adam West.
Any nation [...] can build a breeder reactor to make weapons-grade uranium.
If you don't have the first clue what you're blathering about, kindly shut the hell up.
Clue: Open Source does not mean that everyone has access to the source. GPL-style free software licenses mean that those who can get a binary can get the source for free, which in this case would've been a good idea. Then the facility in question could've found and fixed the bug long ago.
Or would you rather confidential government systems be running a closed-source solution like NT and not know who's getting what data from them?
(Well, there goes any chance of this getting up above -1 - criticizing Microsoft is a sure way to attract 'troll' and 'flamebait' ratings.)
-RickHunter
The same reason why companies have to spend tons of money doing inventory. If machines get moved around, or *lost*, or missplaced, etc, then if that hardware is important to the company, then they'll need to higher people to sort out the mess. Nuclear data is REALLY REALLY important, and since it's sort of missplaced, they're going to have to do a lot of sorting out. Not everything can be sorted out with simple perl scipts.
F-bacher
James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
I also fully agree that since no rogue nation has ever detonated a bomb in downtown Manhattan, it is obvious that it can never happen. History proves that it is completely impossible, so we should just stop sweating it.
So if somebody stole material that was recovered, it would be a one time deal.
Sure, I mean, why should we really care, since if they blew up Jerusalem once, they couldn't possibly do it twice. We'd track that software bug right down in that case. All those people killed in the blast and subsequent radiation posioning can rest easy in the knowledge that at least the same bug won't be exploited again. Probably.
Microsoft product has a 'bug' that causes nuclear materials to get 'lost;' don't you realize what this means?! MICROSOFT IS NOW A NUCLEAR POWER! So much for antitrust legislation. Ok, kids, important safety tip: If a Microsoft License inspector leaves his briefcase at your office, RUN!
Vintage computer games and RPG books available. Email me if you're interested.
perl -e 'print "a nuclear bomb\n";'
It does when you're dealing with what is patently a piece of Safety-Critical software. I spent a little while working on railway signalling software, and the whole methodology is meant to eliminate this sort of vulerability.
Microsoft wrote a dodgy database server and a leaky OS. But they didn't make the decision to use those products as the basis for a piece of S-C software. They didn't write the software, design the SP's, build the data abstraction layers, create the failsafe routines.
What I find disturbing in particular is: where was the testing? Where was the useage simulation? How did a piece of software which turned out to have data integrity issues ever get a Safety Certificate?
For the Jubilee Line extension signalling, we didn't just limit development to ADA, there was a specified subset of permitted constructs, there were function point limits, a specified compiler, a specified runtime environment, there was rigorous analysis, code inspection, traceability, self-correcting feedback, three copies of everything which all had to match or the system stopped. There were no less than 3 teams of independent testers.
And even then it took a very long time to get the Safety Case signed off.
Microsoft shouldn't produce flaky tools, no question. But the very serious culpability here lies not with the creators of the shoddy toolset but with those who chose to implement a Safety-Critical application using these shoddy tools, and those who passed it for use.
Basic professional skill no. 1: know the right tools for the job in hand
TomV
When I was in high school in the mid-1980s, the idea of a massive nuclear exchange between the US and USSR seemed very real. We had all grown up with the assumption that a nuclear World War was just around the corner.
Now we're more concerned with the rogue state or terrorist nuclear weapon.
I wonder if someone even 10 years younger than I am can understand how much things have changed?
** The opinions expressed here are my own, and do not reflect those of my employers - past, present, or future**
Now I may be taking the minority opinion, but this actually doesn't sound like a big deal. Just because the computer loses, say, 120 kilos of U-235 or something does not make the uranium disappear. To this to be a problem, somebody has to actually steal the materials. I don't think that anyone out to steal weapon's grade nuke fixin's are going to be so concerned about a software glitch or rely upon one.
Also, most nuclear materials can be tracked to their point of manufacture even after they've been assembled into a bomb and detonated. You find the core, you can analyze the left overs and know which plant, US or Russian or god knows who, manufactured the stuff. So if somebody stole material that was recovered, it would be a one time deal.
Finally, if theft and purchase of nuclear materials are so common, the plans so easy to attain, customs so easy to bypass, why hasn't some "rogue nation" detonated a bomb in downtown Cleveland? or Jerusalem? or Kennebunkport? Shipments have only been intercepted a few times, no terrorists have ever threatened to use nukes, and the only 2 countries that we (the US of Absolute Stupidity) have a major beef with, N. Korea and Iraq, that claim to be developing nukes haven't. What are we worrying about? Oh, and the greatest threat isn't theft, it's assembly. The response time on the guards at our main plant is fast enough to prevent escape, but not fast enough to stop someone from barricading themselves inside, dragging out some material and all the fixin's to a workshop and whipping up a Grade-A 100 megaton party popper. Who needs to escape? Turn the entire mid-west into a glass parking lot.
"Life's funny sometimes." "And sometimes it isn't." --Cat's Cradle
I agree. Open source is great, but its not the answer for *everything*. Open source zealots are just as bad as closed source zealots (but has nothing to do with Protoss Zealots). The point is, you need to know when to use it and when not to. The balance is the key here...
--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
But it sure wasn't Office Space. Office Space even references the other movie they took the idea from.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
The editorial says: "Russia reported both problems to Los Alamos, which subsequently verified the defects, as did Microsoft."
So why was Microsoft involved in verifying the problems, if it has nothing to do with Microsoft software?
The software seems to be a custom app using MS Access 97 and Visual Basic running with Windows NT and Microsoft SQL Server. It may be a bug in the app itself, or a bug in the underlying software, or both. Nothing I saw really gives a clear indication.
Weapons-grade fissionable materials in themselves are relatively easy to make. Any nation that has the know-how to build a nuclear reactor can build a breeder reactor to make weapons-grade uranium. The technology required to make the actual bomb, though, is pretty difficult to figure out.
Getting the material is actually not as straightforward as you imply. Breeder reactors do not output weapons grade material. The stuff needs to be processed so that it contains the same fissionable isotope at a very high purity. Separating a substance which is chemically the same and differs only by weight is tricky. The weight difference is not that much (several neutrons in a nucleus with over 200 particles). It is very energy intensive and the machinery needed to do it needs to be very precise.
Also, as you state, making the bomb is not just two hemispheres of matter surrounded by a soccerball of explosives. Yet another case of the movies putting irrational fears into the public consciousness.
In conclusion, no part of making a nuclear weapon is "easy". It is an incredibly complex operation that would be difficult to hide.
Remember, You are unique...just like everyone else.
Want to try reading some more reliable sources? According to this MIT "Nuclear Economics" course material: See also Section III of this US Air Force paper, which says:
Sensitive information in your company/government (my emphasis)
The key here is the information, which is secret, not the software that processes it.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Actually, not even a cigarette. Knowing the source code doesn't compromise security per se, provided that the coders can distinguish their arse from a hole in the ground and didn't hard code database access information into the code.
Look at encryption. Software like GnuPG and to a lesser degree PGP are open source. The algorithms applied are well documented and accessible to anybody.
Can you crack a GPG encrypted message? Not likely and it doesn't matter at all. Because security is not in the algorithm, but depends entirely on the key, possibly the chosen algorithm and the precaution of the sender and receiver.
Security through obscurity is about as dumb as it comes.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
science is a religion
I think open source is great, and something the government should be using for non-confidential or lower classified systems.
-
I've had enough abrasive sigs. Kittens are cute and fuzzy.
This is exactly backwards. Bomb design is, though not exactly kindergarden stuff, actually fairly simple and easy if you know where to look to find the right info to work with. It's manufacturing the special materials in quantity which is hard and expensive.
Around 1970, the Department of Energy (and specificaly Edward Teller) did a threat analysis program called variously The Third-Country Experiment or The n-th Country Experiment. They took three brand new physics PhDs with no specific course work or training in nuclear physics and told them to design a bomb using only open source materials. This they did, designing a compact (1-ton), reliable (was analyzed by professionals and determined to have essentially full reliability / functionality, though one was not manufactured to test) weaponized plutonium implosion device, in 18 months time. So there's been a demonstration that it can take as little as less than 5 man-years effort.
See: The Nuclear Weapons FAQ by Carey Sublette and the newsgroup alt.war.nuclear
Where's the meat of these reports? It's interesting to note that in all cases safety systems worked as required. No nuclear events were recorded although contamination did occur when the casings of weapons were breached and the material spread over the area of the accident. Some of the accidents cited are EXTREME events that push the maximum credible accident design limits.
I'm wondering if the lack of recent incidents is the result of reports still being classified or if we have increased our safeguards.
My experience aboard fast attack submarines has always left me with a good feeling about the degree of paranoia the military holds for these devices. They were treated with enormous respect and the security precautions surrounding them always impressed me. It sure was a pain in the butt. I felt the people whose job involved the care of these weapons understood the meaning of what they were doing and carried out the extreme work rules because, ultimately, they made sense.
Even looking over the history of the Naval nuclear power program you can see that, as our understanding of the dangers of radiation became more sophisticated we also became increasingly diligent in the handling of radioactive materials and in the reduction of radiation exposure. I looked at my old service records and I note that my total radiation exposure while in the service was under 50 mili-REM. Granted, I picked up the Parche in new construction, but I still did maintenance in the Reactor Compartment for years after criticality. We worked VERY hard to limit radiation exposure.
My feeling on the report cited is that the people who wrote it were fundamentally anti-nuclear and wanted to use existing reports to make things look bad/incompetent.
Accidents happen, even in zero-defects programs. (Maybe BECAUSE of the zero-defect program psychology). It's good to see that safeguards designed into the weapons worked.
Wheee, just as Dubbya takes over, the news media becomes exactly as technologically illiterate as the president himself!
"The Russians found that over time, as the computer program is used, some files become invisible and inaccessible to the nuclear accountants using the system, even though the data still exist in netherworld of the database."
Oooh, next they'll tell us that there's no such thing as user or computer error, it's instead the magic pixies in the machine going on strike that brings down the software!
"Kurchatov scientists discovered a fatal flaw in the Microsoft software donated to them by the Los Alamos National Laboratory."
In a word, duh... However, Los Alamos (and a good deal of the military) doesn't *use* Microsoft products, except in the case of laptops, etc, non mission critical machines... Half of them are using Unix or whatnot, OS's that have been time tested as reliable and suited to mission critical applications...
And being that they use software that is essentially time tested, it *has* to be screwups on the part of the Russians, because if such a flaw exists in the software, they would not be a major risk for distribution of weapons grade nuclear fuel, *WE* would...
Whoever wrote that article for the Washington Post should go back to covering dog shows and the occasional visit of pandas to the Washington Zoo... Or perhaps he should take that up as a career revision...
Former Minuteman launch officer and president of the center for defense information? They don't program or use computers other than for entering launch trajectories and confirming launch codes, they just turn the little keys, right?
Just because you can mod me down, doesn't mean you're right. Shoes for industry!
We're sorry, your nuclear inventory has changed and Windows Office XP will now shut down. Please contact Microsoft support to obtain a new product activation key.
Just because you can mod me down, doesn't mean you're right. Shoes for industry!
It's not very stable though, the core's it generates tend to glow in the dark.
On another topic, why don't companies bombard radioactive waste with neutrons to make it break down?
--
--hongpong.com
This is exactly why I, dictator of a small island country, instruct my military to get all our nuclear bomb-related software from Freshmeat.
You don't know adrenaline til you guide a nuclear missile with gnuke 0.913 (unstable).
Sure... it's a bug. Or, could it have been put there intentionally as an aid to the US government's unofficial trading and sale of weapon materials?
Or, maybe I've watched too much X-files.
You're welcome to send your check back to your congressional representative, with directions to return it to the US Treasury and a request regarding how you think it ought to be spent.
Of course, you won't do that...
Whatever happened to JonKatz?
I've seen plenty of bad apps written with the VB/SQL Server combination, and very few good ones, so it wouldn't suprise me that they did something dumb, like put the RI in the front-end code, or neglect to use tranactions.
I would suspect that a lack of proper RI has resulted in orphaned records, which could fit their (wierd) explanation of the problem.
www.lucernesys.comHorizon: Calendar-based personal finance
I agree. It sounds like the database may have a flawed relational key structure. In such a case, certain data entry errors for a parent record can cause related child records to become "lost". The child records are likely still there, but are not related to the intended parent.
More broadly, there are likely to be 2 implied issues with this software:
1. If the software is 10 YO, it is likely that it was written with less than full attention to modern relational principles, such as database normalization , application partitioning, etc.
2. It is certain that the database was changed, ported (*), etc. over its 10 year life. It is again certain that the changes were less than optimal. Some probably even introduced errors.
* - If the application is 10YO, it is certain that it was NOT written for NT/SQL Server, as SQL Server is not a 10YO application.
It probably will make sense for the database to be reviewed and rebuilt. In general, applications should be reviewed and re-engineered periodically.
It's kind of like the DeCSS fiasco: once the technology gets out, there's nothing you can do to put it back in the bottle.
But at least you can't write a nuclear bomb in six lines of perl. Or can you?
Toronto-area transit rider? Rate your ride.
What's really scary is that former weapons developers for the USSR are providing consulting services for other nations. Pakistan, anyone?
Weapons-grade fissionable materials in themselves are relatively easy to make. Any nation that has the know-how to build a nuclear reactor can build a breeder reactor to make weapons-grade uranium. The technology required to make the actual bomb, though, is pretty difficult to figure out. It's kind of like the DeCSS fiasco: once the technology gets out, there's nothing you can do to put it back in the bottle. Thankfully, everyone (so far) who has the tech wants to keep it private. Hope the servers they store the info on aren't running Windows!
If you can't rely on state workers like me, then who can you trust?
..it's a feature! It demonstrates the phenomena of radioactive decay in its code.
Just like the stuff it's supposed to track.
What you are talking about is not reasonable. No matter how careful a programmer is, no matter how much testing the code goes through, no matter how many experts scan through the code, there is always the possiblity of a bug or design flaw. It cannot be expected that code written in the real world for use on real devices will be 100% fault tolerant. The same goes for anything else.
Why do you think there are so many problems with getting good, decently priced healthcare in the US? It is exactly because the doctors have to pay settlements in the millions if they make a very small mistake or a dying patient doesn't survive a very risky surgery (which the patient and family were informed of the risks). What is the result of this? Doctors/hospitals have to pay massive malpractice insurance premiums. HMOs were created, which makes getting serously ill worse, because your provider will hide possible treatments, refuse to pay for critical operations, use accountants to make decisions that only doctors should. And so on, and so on...
That is just for finacial liability. How would it be if an industry were criminally liable for not being 100.00000% perfect and 100.00000% successful at everything? I imagine it would end up like this: most of the people who are knowledgeable would run away screaming from their job, realizing they could not possibly live up to the standard and would end up in jail. Then you would only be left with clueless idiots, arrogant bastards, and con-artists. After a short time, the idiots and bastards would be in jail because they made some sort of mistake, and the con-artists would be in the Bahamas or somewhere with the millions of dollars they stole from desperate organizations trying to fill in the essential gaps in labor caused by this law. What does that leave us with? Nothing! Because we are talking about critcal industries, what would happen? I don't want to find out.
People or organizations should be punished if they hide problems or don't use resonable care, however saying that someone must be punished for everything that goes wrong is complete idiocy and shows total disregard for reality.
What does this mean:
;///////////////////////////////////////////////// /
The Russians found that over time, as the
computer program is used, some files become
invisible and inaccessible to the nuclear
accountants using the system, even though the
data still exist in netherworld of the database.
If the data still exists in the "netherworld"
(!?) of the database, then why will they have
to go through a billion dollar physical re-
inventorying process?
Well alot of things are open source. PGP is open source. does that mean everyone can just go in and read your messages? no.
open source does not mean open data.
Catapultam habeo. Nisi omnem pecuniam tuam mihi dabis, ad tuum caput saxum immane mittam.
Nuclear Inventory for Dummies by Broken Arrow Corp.
I'm not drunk, I just have a speech impediment. And a stomach virus. And an inner ear infection.