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.
Stuff does get stuck in the pipes now and then. I'll bet K25 at Oak Ridge has tons of uranium lost in the plumbing. How do you really know if material has been hijacked or should be written off as lost as a result of the inefficiencies of the production process? Can you really inventory this stuff or are there a lot of statistical assumptions built in to the software that could be exploited by a knowlegeable insider?
>The technology required to make the actual bomb, though, is pretty difficult to figure out.
;-)
Not really. Once you have the enriched uranium (for an ordinary fission device), all you really have to do is to merge it beyond critical mass in a short amount of time.
For instance, take two pieces of enriched uranium with a total mass over the critical limit, but each one below the limit. Then place them at separate ends in a steel cylinder 1 m apart. Attach some chemical explosive on both ends of the cylinder and weld the cylinder shut. Now, when you detonate the explosives (simultanously), the uranium pieces will crash into each other and instantly form a critical mass - Kaboooom...
Not exactly rocket science
This is really being blown out of proportion quite a bit. People need to understand that this is the government/military we are talking about. That means that there is a paper trail a mile long that goes along with this system. Just because this system may have lost track of something does not mean its unacountable. I have an uncle who actually audits nuclear weapons and is called in to investigate when they are 'misplaced'. Surprisingly this happens more regularly than you would think. In every case its a matter of human error where data has either been entered in wrong or material has been placed somewhere other than where it should have been. How are these discrepencies found? You go back and look at all the paper work.
Paper still runs the government/military. Everythign is checked and rechecked and entered into systems that probably don't talk to each other in any way. This story is being blown way out of proportion.
They may not be Free, and they might even cost you money, but no scientist would ever trust a closed source binary for important work.
-NuclearArchaologist posting as anonymous with broken cookies and without his password :(
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
--
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
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.
That's "the true north strong and free" to you, eh. Learn the frickin national anthem before you bother with the map. (j/k:)
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
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.
I'll reprogram it, I'm a Techie Prima Donna. Just give me a night and lots of cola and I'll have that thing TWEAKED OUT! (Running in Linux and programmed in Perl and MySQL of course.)
And when I'm finished, I'll frag your brains out from that same machine!
Know what I like about atheists? I've yet to meet one that believes God is on their side.
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
Ah, the ActiveX method. Did that web page just nuke your hard disk? No problem, the code was signed. Your data is gone, but at least you know who to blame.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
...and let me tell you, the guy's right on the mark. Microsoft was NOT the contractor for the app.
:-)
All of the DOE's software (at least, anything used by anybody with a normal security clearance) is written by a 3rd party -- which usually themselves subcontract. In fact, there are firms in the DC area with mulit-million dollar revenues that do nothing but "bottom feed" on DOE contracts -- that is, do less than 49% of the paid work (or whatever the margin is for that project).
Further, most of these are ENVIRONMENTAL companies, not IT shops, since they wouldn't know enough about, say, ground water remediation to make a front end database app anyway.
So am I surprised? Not really. Especially since we're dealing with a government agency.
46. The Hobo smiles, his eyes glaze over, and he burps. "Beware the man who has lived longer than the Wasteland."
It's pronounced "Guh-nuke-ular".
F.O.Dobbs
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.
SQL Server does (and did) support RI. The problem is it doesn't support cascade updates/deletes without triggers. (I think even to this day.) The RI (foreign key) rules kick in before the triggers. So if you want to have cascade updates/deletes you need to not use foreign keys.
Now if you mess up the triggers that control cascade updates/deletes and RI, then you get into the orphaned records situations.
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.
You're thinking about tritium, which is used to enhance the power of weapons (adding a fusion reaction to the normal fission reaction, an "H-bomb"). Tritium has a half-life of 12 years, so has to be changed from time to time.
Plutonium has a long half-life.
Nukes: A Lesson From Russia
By Bruce G. Blair
Although the United States spends nearly $1 billion every year to help
Russia protect its vast storehouse of nuclear weapons materials from
theft or sale on the black
market, few Americans know how this aid helps strengthen America's own
nuclear safeguards.
Russian experts at the Kurchatov Institute, the renowned nuclear
research center in Moscow, recently found what appears to be a critical
deficiency in the internal
U.S. system for keeping track of all bomb-grade nuclear materials held
by the Energy Department -- enough material for tens of thousands of
nuclear bombs.
Kurchatov scientists discovered a fatal flaw in the Microsoft software
donated to them by the Los Alamos National Laboratory. This same
software has been the
backbone of America's nuclear materials control system for years. 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. Any insider
who understood the software
could exploit this flaw by tracking the "disappeared" files and then
physically diverting, for a profit, the materials themselves.
After investigating the problem for many months, the Russians came to
believe that it posed a grave danger and suspended further use of the
software in Russia's
accounting system. By their calculations, an enormous amount of Russia's
nuclear material -- the equivalent of many thousands of nuclear bombs --
would disappear
from their accounting records if Russia were to use the flawed U.S.
software program for 10 years.
Then, in early 2000, they did something they didn't have to do: They
warned the United States, believing that an analogous risk must exist in
the U.S. system.
Although neither Los Alamos nor the U.S. Department of Energy has
publicly acknowledged the possibility that innumerable files on American
nuclear materials might
have disappeared, the Russian warning caused shock waves at the highest
levels of the Energy Department.
Unlike the Russians, who did not throw away their manual records of
their nuclear stockpile -- the infamous shoe box and hand-receipt system
that U.S. assistance
was intended to supersede -- the United States has long since discarded
its old written records. To reconstruct a reliably accurate accounting
record, the Energy
Department may need to inspect all of America's nuclear materials -- a
huge task that could cost more than $1 billion and still might not
detect the diversion of some
material, should it have occurred.
The importance of the goodwill and trust that had grown up between
American and Russian nuclear experts over years of working together in
this area is clear. When
the Russian scientists first discovered the computer flaw, the initial
reaction in some high-level Moscow circles was to suspect an American
Trojan horse, a bug
planted deliberately to undermine Russian security. After complaints by
their Russian counterparts, scientists at Los Alamos suggested that the
Russian scientists
instead use a later version of the same program. Kurchatov then
discovered the upgraded program not only contained the same bug (though
much less virulent) but
also had a critical security flaw that would allow easy access to the
sensitive nuclear database by hackers or unauthorized personnel.
But trust overrode suspicion. The Russians concluded that the glitches
were innocent errors, not devious traps. Thus, they feared the U.S.
database, unbeknown to
Americans, was not only prone to lose track of nuclear materials but was
also accessible to unauthorized users. Russia reported both problems to
Los Alamos, which
Nuclear, no... a fork bomb, maybe...
--
"It's tough to be bilingual when you get hit in the head."
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
I worked at a nuclear fuel manufacturing and research eastablishement for a several years, during which time there was a big press story about radio-active material going missing.
What was being missed (by the reporters, not the research organisation), was that this was entirely expected.
(a) Heavy metals weigh a lot, so a little missing sounds like a lot
(b) When you saw a preice of metal in half, thereis a small qunatitiy of metalic paticles, shavings if you like, that cannot be weighed and accounted for, caught in oil traps etc.
Over a period of years, this means that an establishment will receive more material than it sends out.
RG
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!
But AOL might not like the G infront of a series of words.... don't try Knuclear-Tracker either: adobe seems to tracking down "K" groups...
Wheeeee
My commencement (last June) was by Bill Cosby. He didn't blame Reagan for anything.
"When I'm singing a ballad and a pair of underwear lands on my head, I hate that. It really kills the mood."
When I'm singing a ballad and a pair of underwear lands on my head, I hate that. It really kills the mood.
-Tom Jones
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
My girlfriend went to a Catholic school, and in an attempt to not scare the children, they were told they were practicing fire drills instead of nuclear attack drills. So all these kids were being taught that in case of fire, crawl under your desk and hide...
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.
I always wondered how the Libyan Nationalists were able to get their hands on all that plutonium for Doc Brown.
Suddenly I don't like the way the last week's userfriendly.org is leading.
Another one with a half-baked grasp of history 8-(
the plutonium bombs (Little Boy and Trinity) were implosion devices
I assume "Little Boy" was just a typo, and to nit-pick, "Trinity" was the name of a test of a device called "Gadget".
because they were initially afraid they couldn't scare up enough plutonium
Your logic escapes me. They were worried about Pu shortage, so chose implosion ?
There was no shortage of Pu, and there was no real concern over this past the very early days. Once a production reactor was on-line (i.e. not just the early Chicago pile), Pu was more readily available than HEU. After all, Pu extraction is relatively simple. Under war conditions, where operator safety goes out of the window, it's almost easy. There was continued concern over HEU production, and this led to the implosion designs being continued with
explain Project Urchin?
I can't. I've never heard of "Project Urchin". "Urchins" were developed in the Manhattan project, but not under a project of that name. Is Urchin something else ?
Why is an Urchin significant to a Pu shortage anyway ? You need an initiator as a neutron source, but they're not a specific component that's only required by one particular configuration. The Urchin concept isn't revolutionary (although making a workable one is hard). It's even too obvious to be patentable (although not by the USPTO's standards). India used them (called "Flower") in their early '70s tests. If you believe the kooks (I don't), even the German bomb design (sic) used a Po/Be urchin.
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.
Was he not?
Count on an actor to deceive is all I have to say.
Stop the brainwash
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
Sort of like that penny shaving thing they did in Office Space. I'd rather have 1 trillion pennies than weapon grade nuclear material, though.
F-bacher
James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
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.
maybe it's like the early MS Management Console where if your config got lost you had to type the ip addresses in via a 4 box ip entry widget
.oO0Oo.
cut and paste? forget it
They did introduce backing it up later but it was already too late for my neighbour who spent Friday afternoon all Friday Night and into Saturday morning typing in the 200 ip addresses and Virtual Host Names his IIS was hosting.
You can't buy entertainemnt like that...
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
It's actually a pretty easy fix. In Explorer, if they go to View->Options they need to choose the "Show All Nuclear Stockpiles" option.
That one tripped me up too until I read about it in the tips section of "PC World Domination" magazine.
perl -e 'print "a nuclear bomb\n";'
At first sight, the fact there are still 'failures' does indeed look bad (and it's certainly not inherently *good*).
But the point of the Safety-critical approach is no to eliminate all failures (though minimising them is good). The main thing is to make sure that all possible failures are mitigated if they DO occur - so if the system loses a train, say, it needs to stop enough of the network to maintain safety at all times. It's about restricting to certain modes of failure, safe modes. There's a gulf of difference between:
And how comes the piccadilly gets trains through at an interval of 1-2 mins but the Jubilee can't do better than 3mins?
Well, as originally designed, JLE was to have been the first 'moving block' railway, using braking-distance approaches similar to what we do in a car. But when the govt decided the JLE would be the sole means of getting the The Dome (tm), this moved our delivery date forward by about 3 years. So, with the timescale of the safety certification process, JLE had to be delivered in fixed-block form (traditional only-one-train-per-chunk-of-track stuff). Moving-block was intended to run at about 1 train a minute, why the fixed-block compromise, arrived at late, was restricted to 3 minutes I'm not sure.
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
We American's like our superiority over other countries. Im sure we would like to have nuclear materials that aren't accounted for, so that we could still have the most big bombs while promoting the destruction of nuclear weapons. Maybe someone suggested that when coding up our custom "nuke-tracker" that it "accidentally" lose track of some of our weapons. That way we could claim that we have less of the stuff than we really did!
Of course this all backfires when you forget about these "features" and send the software over to Russia. Not to mention that they are kind enough to point out the "feature" and bring it to attention. Makes you wonder.
While you were living in fear and practicing duck and cover, I was wishing I could go on a field trip to Moscow.
I'm not quite old enough for the duck-and-cover days (although I did enjoy The Atomic Cafe)
I wasn't talking about a paralyzing fear, but more about the zeitgeist, the spirit of the times. People make certain assumptions about the way the world is, and I think that those have changed quite a bit in a relatively short span of time. When someone talks about "the nuclear threat" today, they mean something very different from what those words meant back in the 80s.
** The opinions expressed here are my own, and do not reflect those of my employers - past, present, or future**
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
It's actually a way of radically cutting down on the half-life of radioactive material. And it was working very well too, let me say , until some disgruntled, unpaid engineer started to calculate on the half-life of plutonium:
Hey, wait a minute, it says here that after 10 years we should still have 500kg of plutonium in here instead of only five?
So, we have now termina- ah, fired the engineer and taken a restock of plutonium, and are pleased to say that none whatsoever is missing. Hey! You, letgo that can. Shoo.
As a further safety measure to avoid anything like this happening in the future, we are moving the aforementioned application to a windows XP/Access XP platform.
Thank you for your time and god help.
---
Really, this is starting to freak me. There have been attempts to smuggle radioactive material out of Russia before, and now there's no telling what is missing?? Ok, I'm gonna go make me a bombshelter now.
sigfault
Did they look between the sofa cushions?
-- In the future, everyone will code Perl for 15 minutes. --
Actually, that should be "a nuclear bomb in six lines of perl"
If you're a zombie and you know it, bite your friend!
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.
The alternative is that everyone and their brother gets to scour the code for a flaw? I think open source is great, and something the government should be using for non-confidential or lower classified systems. Open Source is fine for secret applications too. In this case, it's the data that are secret, not the software! There's a big difference.
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
Not really. Once you have the enriched uranium (for an ordinary fission device), all you really have to do is to merge it beyond critical mass in a short amount of time.
Fortunately, you're grossly wrong, having left out essential stuff. Unfortunately, the Web provides all this info to the interested reader willing to do a gbit of research.
1Alpha7
Live to be Moderated
Or it would be, if the halflife of both were in the same realm. I think plutonium has a half life of hundreds of years (the number 10000 rings a bell).
science is a religion
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.
It's not very stable though, the core's it generates tend to glow in the dark
And it can't be easily 'rm -f'-ed; you have to store it in a remote directory until a few thousand years pass and it just decays away... or maybe we can put it on a spaceship and shoot it off and away from our planet...
====
If all comedy comes out of tragedy, let the killing begin...
====
"white bread, redneck, chicken-shit, motherfucker" -- Dr. Dre on "Straight Outta Compton"
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
"The Former Russian Republics are all cash strapped."
What are Former Russian Republics? I know only one Russia. There are former soviet republics. Anyway your post is naive.
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).
does any body know how long weapon grade plutonium remains weapon grade? my understanding is that the material must be continually rotated.
Any nation with a coal-fired power plant has access to nuclear materials. And I quote:
...the recovery of the uranium-235 released by coal combustion from a typical utility anywhere in the world could provide the equivalent of several World War II-type uranium-fueled weapons. Consequently, fissionable nuclear fuel is available to any country that either buys coal from outside sources or has its own reserves. The material is potentially employable as weapon fuel by any organization so inclined. Although technically complex, purification and enrichment technologies can provide high-purity, weapons-grade uranium-235.
Funny that no one is worried about keeping track of any of this weapons material.
-nukebuddy
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.
> perl -e print a nuclear bomb in six lines of perl. Or can you?; perl: No match.
Then again, the fact that it's not matching any nuclear bombs is probably good...
________________________________________________
________________________________________________
suwain_2
LOS ALAMOS DATABASE PROGRAM COMPROMISED!
Joe Writer
LOS ALAMOS, NEW MEXICO (CNN) -- Kevin Johnson, an expert in Windows 95 security hired by the Los Alamos National Laboratory, completes his investigation of the Los Alamos database server. (picture, left)
The nuclear database at Los Alamos laboratory has always been kept absolutely secret, never sold or traded with other countries such as China or Japan. Lately, it has been, from the reports of many personnel on the base -- disappearing.
Kevin Johnson, a former Microsoft technical support agent and certified Windows 95 security expert, who was recently hired to investigate these reports, says otherwise. "I cannot understand the level of incompetence involved here. It's almost as though they don't know how to sign on AOL!"
Johnson says that the problems can be traced back to Los Alamos not using the Windows NT operating system, which many claim to be more "stable and secure." By not using this "operator thingymadinger", Johnson says, they've been at risk.
After an extensive audit of the computer's security, which took between five and ten minutes, Johnson found this snippet of cryptic, hacker code hidden in a ".pl" file, hidden away in their "Startup" folder:
"#!/usr/bin/perl
# m4d pr0pz t0 fr4u 4nd m1n1-m3
# - dr 3v1l th3 skr1pt k1dd13
sub sleepytime {
sleep(31536000);
doExec();
}
sub doExec {
exec("del c:/losalamosdb.txt");
exec("del c:/permissionstable.txt");
sleepytime();
}
doExec(); # h4w h4w h4w!"
"At first, I just thought it was another maintenence program," Johnson reported to Major Weston, who maintains the 'shiny thing.' "But upon closer inspection, I noted the word "PERL," which seemed to be an in-reference to 'Unix', an obsolete, non-Microsoft operating system."
He telephoned his drinking buddy, Mitch, who explained to him that PERL was in fact a "programming language" used by "Linux web solution hackers."
While Johnson's report was not fully released to the public, sources speculate that he most likely "removed the drevil.pl file" and "uninstalled the hacking program called ActivePerl."
The FBI is currently seeking all users of "Mozilla" that have accessed the state-of-the-art "Personal Web Server", used for remote, secure access of sensitive files on the same computer, for questioning.
Do you like German cars?
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
How many data flow diagrams do you think these programmers created before writing the code? Survey says.......?
Laws affecting technology will always be bad until enough techies become lawyers.
- formal methods
- rigorous multiply redundant testing (i.e. parallel testing teams)
- requiring all components to conform to the above two conditions
- yet more testing
So what the hell were they doing incorporating a bunch of bloatware that was never ever intended to be used for safety-critical applications in the first place.--
Nic
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.
has a bug that over time loses track of bomb-grade nuclear materials even though their location is still in the database, and that this feature can be used to divert the materials for profit unbeknownst to the nuclear accountants.
"That's not a bug, that's a feature!" said the guy from tech support.
I guess it all depends on your point of view, doesn't it?
Toronto-area transit rider? Rate your ride.
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.
Be pedantic all you want, I didn't know the difference...
Oh yes,
the difference is that the Warhead is "Ready to Bomb" ! Yeah, no more "Bomb it yourself " Guides.8)
It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
Actually, they'd need to do both a physical inventory and a reconstruction of the original data. If the quantities didn't match, they'd need to investigate whether someone might have been taking advantage of the flaw in the software.
IF I HAD KNOWN IT WAS HARMLESS, I WOULD HAVE KILLED IT MYSELF.
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?
Well, if you consider stories like the boy who built his own breeder reactor, you really have to ask yourself if worrying about plutonium is really an issue these days? If somone like that can at least begin to make uranium and plutonium in his back yard, I have a feeling that all the scary terrorists out there already have a nice litle stockpile already...
"Your superior intellect is no match for our puny weapons!"
The Former Russian Republics are all cash strapped. We should have (in the past) or at the very least, NOW made arrangements to infuse cash into their economies in exchange for the Plutonium
:P.
Wait, didn't we already infuse the former USSR with our advanced capitalist ideals? Seems to me the USofA were buidling McDonald's restaurants in the USSR while the Russians were trading nukes on the black market market to the highest bidder
The Former Russian Republics are all cash strapped. We should have (in the past) or at the very least, NOW made arrangements to infuse cash into their economies in exchange for the Plutonium. We'd have it over here, or could decide where/how to warehouse it, and they'd have much needed cash to continue the Capitalist and Democratic reforms we are pushing as the resolution to the Cold War. I'd give up MY $600 tax rebate to sleep better knowing the Plutonium wasn't being siphoned away to 3rd world powers that we don't trust... $1.35 TRILLION would have gone a long way toward buying that fissionable material!
I wasn't talking about how things are, but how they should be. Strict liablilty just seems like another way of saying: "We don't want to put any real effort to fix any problems, so we'll lay the blame in the easiest place." Anything could be considered extremely dangerous--driving over 50 mph, pumping gasoline, or even soda pop. Does that mean the manufacturer should be responsible everytime there is a 100 car pile-up on the freeway, someone throws a burning cigarette down at a gas pump, or a stupid old lady shakes up a bottle of 7-UP that explodes?
From what I understand (at least in the US were I'm from), all of the industries you mentioned have governing agencies that regulate what companies are allowed to do. They have the power to shut down a company or even put people in jail that aren't following proper safety procedures. So if the corresponding agency is doing it's job, it's industry should be reasonably safe.
What about software that wasn't written for use in such industries? Does this mean everyone writing software should be concerned about strict liabilty hanging over their heads? Both the BSD and GNU licenses have clauses that say they have no warranties, however from what I've heard it sounds as though some company can just install the software and the original author is responsible reguardless of any warranties because of strict liability! Is it the programmer's/software company's responsiblity to make sure their software isn't installed in a nuclear plant, hostpital, or airline? That kind of situation cannot be anticipated by an open source developer. Because the software is freely distributed, they don't have much control where it goes or how it is used. The same can be said of many software companies too. It is quite unreasonable that they be expected to control every aspect of how their software is used--and I'm not just referring to use in said industries-- if they become liable for this, they will become liable for every possible misuse of their software. "Someone used Mr. X's version of ftp to illegally copy music? Let's send Mr. X to jail!"
Just wait until you or your loved contracts an easy to cure, but serious illness, and you cannot afford even basic treatment, I think your tune would change.
It may work that way in communist countries pretending to be free market (like the United States), but in real capitalist societies, if companies behave this way (especially those that disregard the public safety), large groups of people form to raise(9) on such places. Most people don't tolerate that kind of crap--unless they've been beaten down by some evil power, and no amount of laws can protect them if that is the case.
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.
Broken Arrow "I don't know what is worse, the fact that we lost a nuclear weapon, or that it happens so often, we have a name for it." - "The conclusive proof that intelligent life exists elswhere in the universe, lies in the fact that nobody has bothered to contact us." --unknown
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?
That is totally inexcusable. Dealing with nuclear issues is done so under strict liability - no foul ups permitted. Think that is crazy?? Think that is too much to be expected of a company?
What is an acceptable error rate for heart surgeons? What is an acceptable error rate for airplane systems? Let me illustrate with airlines what Strict liability really means.
Do you know that in 1999 there were 5,645,179 departures from large air hubs alone? (http://www.bts.gov/publications/airactstats/) A failure rate of only %.001 (that is one thousandth of a percent) would mean 56 airplanes would crash EVERY YEAR!!! Companies that make software for issues that are so dangerous that they have millions of lives at stake should be finacialy and criminally liable for any mistakes they make that put anyone in danger.. --EOM
Jesse Wolfe Sr. Manager Systems Integration
Sorry to say your wrong - but your wrong.
If you ever study law you will study the tort issues of Strict Liability. Strict Liability laws mandate that companies that deal in extremely dangerous businesses (Extremely dangerous businesses could be considered flying people through the air, nuclear industries, fireworks - see below for my rebuttal on medical issues) are fully liable for any injury without exception or fault. For example, if nuclear waste is being stored, and every possible safety precaution is taken that could be imagined, and something goes wrong - the company is liable. period - thats it, there is no legal argument the company can make. Even if someone malicously tampers with the container and that person is injured - that person can hold the company liable. If you think this is idoitic, or untrue, reply back in this thread and I can provide a ton of links on cases involvig strict liability.
By being a software company that takes on the job of writing systems for industries with such Strict Liabilty issues, you should be CLEAR that your software will be held to the same regard. Any company that engages in a Strcit Liability industry is aware of the expected 100% success rate and the risk (and cost) of even being %.0001 wrong must be considered the risk and cost of doing business.
I will admit that the heart surgeon example was off topic a bit in hindsight, but I included it to further prove the importance of 100% success in certain industries Medicine is particularly tricky, But if a heart surgeon screws up (forgets to clamp a vessel or something) he is liable for malpractice, yeah yeah.. it raises rates - but wait until the surgeon srews up on a loved one and your tune will change.
Let's face the truth here, in a capitalist society - companies will reduce the cost of operating as much as possible at all times. If Strict Liability laws weren't in place, companies would provide the lowest cost safety precautions that they felt would allow them to say "hey... we tried!!" in court after they radiated / burnt / crashed / drowned 1000 people.
Jesse Wolfe Sr. Manager Systems Integration
You think that bug is an accident? It is all part of the CIA plot to leech material from our nuclear program so that they can sell it covertly around the world to fund their clandestine operations. Don't be naive! A secret has been revealed, not a bug. I'm sure they didn't write about the log file that is written describing exactly what item's have been 'lost'.
On another note, I have parcels of land for sale on the moon. Contact me and I'll tell you where to wire your money...
Omnisciently,
Darth
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.