Just to clarify for other readers, you post makes it sound like "NASA Doesn't do much" at NASA ARC.

I work at ARC, and it's a wonderful research facility! In just my short time here I've been involved with groups doing pioneering work in computer science and robotics, supercomputing, avionics, aviation safety, cockpit design, UAVs (for science, not war!), earth science, biology, astrophysics, planetary discovery, and so much more!!

NASA Kepler, which just found a "twin" earth (Google: Kepler 22-b) was begun here, and the science operations are still performed here.

Quite a lot of great stuff comes out of NASA Ames, for a very small overall price tag.

About 10 years ago I was at the VAB when all 4 orbiters were at KSC. There are only 3 bays in the Orbiter Processing Facility, and at the time the fourth shuttle was usually in Palmdale on a maintenance rotation. On the rare occasion where all four were at KSC, one had to be left in a corner somewhere waiting for it's turn in an OPF bay.

So, as I walked into the VAB (which is essentially a 50 story open bay, with a lot of open space) off on the left is Discovery, engines out, parked in the corner with a huge tarp suspended over it to protect it from stuff falling from above. It looked a little forlorn over there - literally "parked with a sheet over it". It was sort of surreal, because it was like seeing someones old project car in the corner of their garage, except it was an orbiter.

Anyways, even in this sort of storage you wouldn't be able to fly it again. The engineering and manufacturing infrastructure which supports the shuttle has been dissolved or is in the process of being dissolved. The physical orbiter was only a small piece of that infrastructure, which ran the gamut of things from trajectory analysts, simulators, manufacturing facilities for tanks, a control center staffed by trained personnel, etc. etc. It's not like pulling an aircraft out of storage, restoring it, and flying it. The space industry and space systems are still very specialized and rely on significant amounts of engineering, specialized equipment, and specialized knowledge on the part of the engineers and technicians supporting a particular system. Hopefully that will change soon.

I'd take it more as the white room crew making a patriotic statement than a religious reference. In many of the employees, there is a pretty significant sense of national service, both on the part of the government and contractor employees. I would say the majority of employees (at least the ones I worked with, who were mainly engineers) were primarily motivated by things other than a paycheck, which in most cases was smaller than a similar private sector position.

One interesting thing about the "God" reference - I'm not particularly religious, but to some it was not all about the science and engineering when there are people onboard. I've worked manned and unmanned launches. When there are people you actually know and work with daily onboard, it's got a whole different sense about it - and it would cause religious feelings to well up in some people who ordinarily were fairly agnostic.

Hi all; I actually work for NASA as an IT Security guy.

While I can't answer specifics about this incident, you should remember that a great many things done by NASA are "General Science", and the data output from them is specifically and consciously made public.

It's possible that the FTP server is meant to be serving those files "to the public".

Why FTP instead of SFTP? Usually when you choose to make data public to the world, you don't bother implementing crypto on the data. And just because it's available via FTP for distribution, does not mean insecure FTP was used to *place* the data on the server.

You're quite right, actually. I didn't really want to go into all that detail with my post though, and knowing the "average" IT guy I think I'm still safe saying that they'd say "Hey, that should be in a datacenter!". ;)

Before everyone gets all spun up on government waste, inefficiency, etc - I'd like to point out that numbers like these are never accurate. (For the record, I work for the feds, in the IT field).

The problem with "The feds have X datacenters" as a metric is that various audits occur at different times and by different auditors. These auditors almost always have differing definitions for what a datacenter actually is.

In one audit, a group can come through and define "Datacenter" as a big room where servers are co-located and services run on behalf of others. They'll find 2 at my center. Then a year later, a different group comes in and defines "Datacenter" as anywhere that more than 5 computers are running and left on all night. They'll find 200 at my center. Yes, this actually happened! The auditors came through dozens of science labs, found project servers sitting in the labs, and labeled each lab a datacenter.

Now here is the trick to why the statistics are complete mush. A normal IT guy would walk through the lab and say "Hey, that server should be in a datacenter!" -- but the auditors make the reverse conclusion. "Hey, this lab is a datacenter".

Yes, there is waste in the federal sphere and we absolutely need to take action to be more efficient at all levels. However, this article is basically pushing a number that came from someones' imagination, and pretending it's meaningful.

Duh, how could I not think of a prompt + whitelist. :P

Then again, that presents the "NoScript" problem. While techies generally tend to use noscript, I pretty much see non-techies clicking "Temporarily allow all this page" on every page they visit that "doesn't work right" without even looking at the URL lists. So, a prompt to whitelist content would probably just get the same treatment. Better than status quo I suppose, but not a panacea either.

Wouldn't this feature also kill things like OpenID and other "Single Sign On" services?

If one strace's the chrome flash plugin process one discovers that in 10 seconds it issues 56,000 system calls -- 53,000 (95%) of them are useless gettimeofday() calls

Per my co-worker: That's probably why flash sucks so bad on MacOS. Apple won't give them the time of day!

She didn't make it up, she quoted a senior official - the Boeing payload manager at KSC (Mike Kinslow). This is the first public mention that I've seen, but it is in the planning stages (as a recent addition, which is why this is the first public mention of it).

One of the well documented problems is that if you cut wood that is "too wet" then the brake will activate, thinking that it's hit flesh.

So really the article should say "Each time you cut wood that's too damp (which you have no way to determine beforehand) you pay $169 to replace the blade and brake". That puts into focus why some woodworkers who know how to be careful do not WANT the safety feature.

So what DO you do when the battery charger bursts into flames on orbit?

I'll reinforce your point here. Knowing something about the fire response strategy on ISS you do the following:

1) If you actually are lucky enough to witness the charger burst into flames, remove the power from it, hit the fire alarm, put on a mask, and expend a CO2 based fire extinguisher on it. The mask keeps you from asphyxiating yourself with the extinguisher.

2) If you don't physically see what happens (which is most likely, ISS is big and some modules may go unattended for hours) - the combustion products will trip off a cabin smoke detector in the module. That will stop ventilation inside the module and ring the alarm. In most cases, this will put out a fire in zero g - fires tend to smother themselves without gravity to force convection currents.

Meanwhile, not having any knowledge other than a smoke alarm from a module, the crew will converge in a safe haven in the vehicle away from the fire. Two (of the 6) may go forward to investigate with masks, fire extinguishers, and a hand held device to detect combustion products (mainly so they know if they are entering a lethal pocket of CO or other gases). Hopefully the module isn't a total fog of combustion products - if it is, the crew is likely to isolate it and leave it. If you don't know what the fire source is (because you can't see it), it may well end up that the entire module ends up getting powered down to ensure an electrical fire isn't being fed. This of course has some pretty serious ramifications as well - shutting down power to a module is not a simple event to reverse (since all the computers, cooling, lights, etc. go down with it). It's likely that collateral damage to a module's systems would happen if that were done.

Even if you do understand what happened and know it's out, the harmful gases from burning plastic aren't going to just go away on their own, they have to be scrubbed out with deployed fans and special canisters. It would take weeks to clean up.

Fighting a fire in a closed environment is very different than something you would do in your home. In zero gravity, most of the control is by prevention - don't use flammable materials, stop ventilation on a detected fire so it doesn't spread, don't use things that generate poison air when they burn, etc. Even a minor fire that many of us have encountered at one time or another (smoked electronics, plastic bag on fire, etc.) would be an extremely serious event in space. That's why so much time is spent making sure equipment conforms with fire prevention standards.

Sounds like an excellent idea for foreign espionage. Set up a private shell company, then invite a bunch of former officials who know exactly how the real systems work, to get together in a hotel you've bugged and start pretending they're responding to a cyber attack of some sort.

Official1: "Call the NSA Task force Orange, tell them to begin operation Stork."
ForeignAgent: (making notes) Operation Stork.... NSA... means X..."