I asked him, and he said he didn't know where it might be found. He remembers the foot-high printout and the big paper tape, but that's it (he said IBM did most of the writing and NASA patched it, so IBM might have something).

He did tell my sister and me that we used "space-age technology" when we scraped the ice/frost off of the windshield of the old car we each drove in high school. There were some plug-in cards in the LVDC that had some discrete components (a few transistors, resistors, etc.), and they'd periodically get some that failed in the lab. He grabbed several to keep, and put one in the car as an ice scraper because it had a taper on one edge that made it work well.

I will (and thanks).

We all got up early this morning to go watch the landing at the NASA auditorium, and it was standing room only (and I think some people were out in the hall). As much bureaucratic crap as the engineers and scientists have to deal with (some of from being a government agency but lots of it just from being a large organization), you can tell they really do love doing what they get to do.

Yep. Part of the Ares I work was pulling out the J-2X records from the 1970s (worked on as an upgrade to the J-2 used on the 2nd and 3rd stages of the Saturn V) and bringing them up to date. Materials and processes have changed, and that gives lots of room for improvement (just look at the changes in the SSME over 30 years).

The myth that "NASA can't build a Saturn V because they lost the blueprints" is false, but it would be true that they couldn't just go build a Saturn V today. It would be stupid to try to recreate computers from the 1960s, so they'd use modern computers. That would require rewriting the software though, which would require testing and certifying it from scratch.

AFAIK he does not (but I will double-check). That is what he worked on (he points the LVDC out whenever we're at the museum :) ), but I don't think he has anything from it. I believe his memorabilia is all personal stuff (he still has his NASA-issued slide rule from 1962!).

They've been using the same guidance/control system simulation framework since X-33. However, you can't just have a re-usable guidance system for vastly different vehicles. X-33 was a lifting-body (which is an inherently unstable platform), X-34 was a delta-wing (similar to the Shuttle), and Ares I/V were stacked/staged rockets (similar to Saturn, Delta, etc.). They also had vastly different propulsion systems; while the Ares engines were based on existing traditional rocket motors, the X-33 was a linear aerospike, which required completely different control systems.

It isn't like they started from scratch each time (they didn't); it is just that a lot of customization had to be done for each vehicle and propulsion system. If they get the go-ahead to work on the heavy-lift vehicle, they'll start with work done for Ares and evolve it for the new project.

You wouldn't expect the same system to work on a Cesna and a B-2; why would you expect the same system to work on vehicles that have even less in common?

The knowledge isn't all gone just yet. My father worked on the guidance and control systems and simulations for all the Saturns except the first test vehicle, the Apollo-Saturn Telescope Mount, the Space Shuttle Main Engines, and Spacelab (as well as helping others in his group with things like Hubble and Gravity Probe B).

However, your point about the schizophrenic management is correct; since then he's worked on X-33, X-34, Ares I, and Ares V guidance/control systems/simulations, with effectively nothing to show for it. Now he's waiting to see if the White House will ever move on the next heavy-lift vehicle (that Congress already appropriated money for). He's coming up on 50 years working for NASA (45 years in civil service and almost 5 as a part-time contractor).

NASA's biggest challenge has always been funding and the year-to-year budget process. There really should be some way to budget more than one year at a time; that just doesn't work very well for long-term projects.

The same was true of the Constellation project. It was only behind schedule and over budget because the pointy-heads didn't listen to the engineers when setting up the project. From what I understand from some people involved in the planning meetings, it was basically on the schedule they said they needed and possibly even a little under the budget at that point that they said the needed.

Talking about electricity usage and then giving an example of $10/month is meaningless, since there are significant variations in the cost of power. Where I live, $10/month would be a continuous load of 166 watts for 30 days (assuming that it was "idle" 24x7 and all usage was a "drain"); even accounting for cooling load overhead (which of course isn't constant), that would be about 100 watts. I guarantee you my TiVo isn't pulling 100 watts, nor is everything in my entertainment center combined when it is turned off.

TiVo is trying to lower their power usage; the next box they want to introduce is targeted at customers with digital-only cable, so they want to remove the analog tuners and video compression circuitry. IIRC they said that would reduce the power consumption from 32 to 24 watts (as well as cut the box cost by a good bit). However, they have to get an FCC waiver to sell a box with a digital-only cable tuner.

"Upgrade infrastructure. Problem solved." just shows how little you understand. You are talking about infrastructure that was traditionally amortized over decades (telco switches, cable headends, and outside plant) now being amortized over a few years instead. Sure, you can do that, but don't expect to like the price; multi-gigabit routers are not cheap (and it has nothing to do with the memory).

I work for a small ISP in a mid-sized city, and I'd love to see more bandwidth everywhere. However, we can't get gigabit access for our company for a practical cost, much less deliver it to end users. There are real costs involved in running a physical plant that just don't scale up at this time.

In any case, the "download an hour of video in 15 seconds" is somewhat impractical in any case; downloading an hours worth of anything in 15 seconds requires 240 times the bandwidth over streaming it. Over-the-air HD video is up to 19 megabits per second, so the equivalent download would require a 4.6 gigabit/second link (at the end-user side; the server side would have to be many times that). It would also require some type of storage device that can handle 570 megabytes per second, which is an order of magnitude faster than current hard drives.

Also, what is the point of downloading an hour of video in less than an hour? It isn't like you can watch it faster. A decent streaming system should allow you to fast-forward and such, so that shouldn't be an excuse. Let's work on bandwidth for true HD-level streaming first.

I would sure hate to be the test case here. Poor guy got a bucket of blue paint; now he glows in the dark. Never has a problem finding his keys though.

Is there an app for that?

This is pure NRC "look at us, we're better than Japan's oversight" grandstanding. There was no active failure or danger; a bad valve in a redundant cooling system was found during a maintenance shutdown and replaced (that's why they inspect things while the reactor is down). It appears to have been a manufacturing defect, and all similar valves were also inspected after the bad one was found (no other failures were discovered).

This is the same Alabama plant that was shut down due to the recent tornadoes. They lost off-site power and ran the cooling systems on redundant diesel generators without any problem. Obviously the cooling systems worked. This plant had a horrible safety record decades ago and will probably always be under increased scrutiny, but they greatly improved things before bringing the reactors back online. I live about 30 miles east of this plant, and I have no problems with it.

No, they're not (see Fukashima, Japan). Basically, you don't just flip a switch and have a power plant go dark; you have to follow a shutdown procedure that takes both time and power. I don't know the requirements for coal or natural gas plants, but US nuclear plants are required to have multiple backup power sources (IIRC at least two independent diesel generator systems as well as off-site power). If the plant loses one backup power source for more than a certain period, it is required to shut down. IIRC if it loses two, it must shut down immediately (before potentially losing the remaining backups).

I RTFAd, and a few things jump out at me:

- Attacking GoDaddy's trust because Bob Parsons went hunting in Africa to help farmers. Way to bring politics into a supposed technical discussion.

- Confusing management of the DNS root with domain takedowns done at the registrar level.

- Repeated use of "forever", as if certificates don't expire (and protocols never change).

I think DNSSEC could be used to augment SSL security. For example, sites could list valid key IDs in a DNSSEC-signed record. You still use CA-signed certs, but a rogue CA can't also edit your DNSSEC-signed record. It is also much easier to monitor DNS for somebody trying to change something.