The main impediment to the strategic force upgrade is a process called "nuclear surety". It's what you think it is: a very comprehensive testing process to ensure that the system can't be accidentally triggered (missiles launched.) Surety is as comprehensive as it can be conceived, which means that no process is ever perfect, but this one has a lot of history behind it such that the probability of an accidental or forced launch is very, very low.

Surety costs significant money, about 65-80% of the cost of upgrading the system. Add to that the general cautiousness of changing the system in any way, and you get the "Holy Cow! You're still using 1960's technology?"

It's not a question of software engineering or identifying a failing project, it's the Federal Acquisition Rules or FAR. Basically, once a project starts to fail, processes start taking over, on top of the processes that were running the project, with processes to replan the milestones, with processes that define processes that augment processes to assist processes that eventually result in executing a process that produces software.

Sure, it's easy to play Monday morning quarterback on how to fix the healthcare.gov website. Then reality sets in when the savant garde in Silicon Valley actually have to work according to the FAR's framework and contracting processes.

For once!

Yes, we do need people who can articulate an idea, even if they use passive voice or "run on" sentences. Every so often, the so-called "clerical" or "average" jobs require the ability to actually form and communicate an idea.

I once had a customer nicknamed "Five Slide Jan". People supporting her thought that her requirement that briefings be five slides in length was onerous, but she had a point: Make your point in five slides. That forces one to be succinct and on target. Unfortunately, there were always the additional 20 or so backup charts, but, still, it changed the organization to focus on the message being delivered.

Gravity slingshots and curvature. It's very ineffecient to travel in a straight line from Earth to Mars.

No, the likelihood of getting bricked is really small, although the likelihood of misaligned or damaged equipment failure is much greater.

"Bricking" is really small because there is always a known, good image that preceded the update. In the case of a failure, these spacecraft go into a "safe hold" mode (there are actually several different safe hold levels). The lowest safe hold level ensures that the operator always has access to a low-level monitor. This monitor allows the operator to select which image is booted, so there's always a way to get back to a known, good state.

The operator can really brick the vehicle if instruments and antennae get misaligned, but that's a cascade failure (multiple things have to go wrong) that could be fixed by a higher safe hold level.

There's a lot of redundancy on these vehicles.

Is it me, or do the vast majority of environmental activists seem to be stuck in an Armageddon scenario infinite loop? To be sure, nuclear energy presents issues, like everything else, but I'm not sure that engaging in maximalist interpretations of all events is helpful.

Consider the United States Navy's nuclear program. Other than the Thresher incident, the USN's nuclear program has had remarkably few incidents or major mishaps (caveat: these reactors are designed to generate power, not weapons material.)

When I install a Linux distro, I generally just adapt to the default desktop environment, although my preference tends to be KDE.

My largest problem with GNOME is not its modularity or architecture, but the shear bulk of repitition of doing a single task. GNOME has become its own worst enemy and a victim of its own success -- open source (check!), lots of options (check! check!), even more options because someone forked (check! check! check! check! check!)...

Glass-Steagall was repealed at the end of the Clinton administration. It's effects were felt during the Bush-43 administration.

My customers ask this question all of the time -- who's better? The answer isn't which is better, but which CAP properties do you want. You want consistency -- go with SQL and get the data model right to optimize performance. You have situations where availability and partitionability are important -- let's develop a matrix of noSQL solutions based on what data you're going to ingest. XML, you say? mongodb is probably the best fit? Trawling over metadata? Key-value stores are better. Etc. Etc.

The one place where there is a substantial difference is geospatial indexing -- noSQL databases appear to do this a lot better than the SQL databases. YMMV, though.

The software wasn't written by the USG, it was written under contract to be delivered to the USG. Subtle difference, but no, the software is not in the public domain because it wasn't written by the USG. See the "Software System Acquisition 101" post below...

Joe Taxpayer doesn't get access to the GWA software or source code as the result of how the FAR rights and data rights work. Moreover, Bo Zhang committed theft from his employer, not Joe Taxpayer.

Software is acquired from a contractor, so the Federal Acquisition Rules and various tailored versions, e.g., DFARS, apply. It is not developed by the USG, unless specifically talking about something that a USG civilian employee (__not__ a contractor) authored.

The government purchases systems, writes contracts to acquire systems. Source code is considered data -- so the applicable FARS and DFARS are technical rights to data. Data rights are negotiated separately from software (system) rights and source code is delivered as part of a separate contract deliverable requirement list (CDRL) item, if the source code is even delivered. In 99.999% of contracts I've seen, source code is never delivered and when it is delivered, the most restrictive data rights are applied.

A lot, though, is changing through the DoD's Open Architecture initiatives (formerly the Navy's Open Architecture Program). Source code is expected to be delivered as a CDRL item with unrestricted rights as the default. And it turns out that the GPL is a version of a unrestricted license (I know because I spent a week with the SFLC and a Navy IP attorney collecting the information), so there's some hope on the horizon.

Bad news for those of you hoping to get a major weapons system's source code: The USG is the owner of the conveyed executable, so only the USG gets the source code.

Software is acquired from a contractor, so the Federal Acquisition Rules and various tailored versions, e.g., DFARS, apply.

The government purchases systems. Source code is considered data -- so the applicable FARS and DFARS are technical rights to data. Data rights are negotiated separately from software (system) rights and source code is delivered as part of a separate contract deliverable requirement list (CDRL) item, if the source code is even delivered. In 99.999% of contracts I've seen, source code is never delivered and when it is delivered, the most restrictive data rights are applied.

A lot, though, is changing through the DoD's Open Architecture initiatives (formerly the Navy's Open Architecture Program). Source code is expected to be delivered as a CDRL item with unrestricted rights as the default. And it turns out that the GPL is a version of a unrestricted license (I know because I spent a week with the SFLC and a Navy IP attorney collecting the information), so there's some hope on the horizon.

Bad news for those of you hoping to get a major weapons system's source code: The USG is the owner of the conveyed executable, so only the USG gets the source code.

Even if the sub reaches crush depth, the reactor itself is very heavily protected. Note that I'm not saying that exposing the reactor core to seawater is impossible, but given all of the safeguards, it's highly unlikely.