Hey, that's my dad you're talking about! Dad worked on what was then called the J-2X (a different program from the current J-2X) during the Saturn program, and is still working for NASA on the new vehicles.
It also allows you to see who sold your email and/or who has been compromised. I have a personal domain for email, and I use a different address for just about everything (and they're usually pretty unique, so not found by address harvesting). I am now getting a lot of spam at the address I gave to Linux Journal; since they went online-only and I cancelled my subscription, I killed that address.
I also had a year of free credit monitoring with one of the "big three" credit agencies (due to somebody else's database compromise), and now (shortly after the year passed and I didn't agree to pay for continuing monitoring) that address is getting spam. Either they sold it, or their database has been compromised. Either way, it gives me SUCH a good feeling about their reliability!
I switched to XFCE (on Fedora 15). It is similar to the GNOME 2 "look and feel", especially if you spend just a little bit of time moving things around (although the default XFCE "look" isn't bad either).
I work for an independent ISP that wholesales BellSouth (AT&T) DSL service. When we order a 6m down/512k up circuit, the sync rates are up to 8128k down and 512k up. I guess that's because most end users still primarily care about the download speed (as long as Netflix works they're happy I suppose).
When a computer that could display 320x200 video cost $3000+, weighed 30 pounds, and covered a typical desk, your assumption was correct. Now you can (obviously) get a compact, lightweight, and inexpensive general purpose computer instead.
If you run a special-purpose system with no OS, you have to write code to handle everything (communications, interrupt handling, etc.). When you can get enough computing power in a small enough package, it cuts development and maintenance time significantly because you can use a general purpose OS to handle all the normal stuff, develop on a standard system, use standard libraries, etc. If there's a bug in your home-grown, hand developed USB device manager, you could spend days trying to track it down. Odds are, there aren't many bugs in the basic I/O parts of the Linux kernel, but if there are, somebody else has probably found them and you can "yum update" to get the fix.
Why do so many home/small business routers/firewalls run Linux, rather than develop a custom networking OS? Because the CPU and RAM needed to run Linux is cheaper than the development time to write and maintain a custom OS. The same is true of this: if you can get a fast-enough Linux-on-a-stick system for $25, why would you waste time writing your own whole system? "Because you can" is only a valid answer if you are only going to make one device (and even then it probably isn't valid).
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.
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.
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).
- 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.
- I've seen 1.5x1.5 DSL (same base speed as a T1), and even 1.5M metroE.
- Static IP block assignments (for DSL customers that pay for it, or any T1/metroE type connection) are not usually grouped by service (especially since customers move from one service to another, or even have multiple services for redundancy).
How do they expect to tell the difference between latency due to distance and latency due to protocols, encoding, etc.? For example, a local T1 might have round-trip latency in the 3-4ms range, while a DSL to the same location might be 10ms (in fast mode, even higher for interleaved). A dialup connection will be much higher, while a metro-ethernet might be less than 1ms. All those times also assume no congestion along the path.
Since the speed of a signal in single-mode fiber is about.6 c, each 1ms difference in round-trip latency gives a 90km margin of error.
In IT, there is another problem... ever try rebooting a server while logged into it remotely?
Sure, use IPMI serial-over-LAN (for most newer servers) or a serial console server (for the old servers or routers/switches/etc.), and it is no big deal. With IPMI, if there is a problem, you can "hit" the reset or power switch remotely as well (for non-IPMI you can use remote power switches). If you have to deal with Windows servers, you can use KVM-over-IP switches; some vendors with IPMI also have KVM extensions (often via a web interface).
The only "trick" to it is having out-of-band access to the console server and power switch if you are managing routers and switches remotely. I manage a remote network facility where the only way I can lose access is if three different providers (one telco and two cable) are down or if the power is out for an extended period (but I'll know about power as soon as it fails). You have to think through exactly what is connected where when setting it up, but it isn't magic.
Slashdot Mirror
I bet you still drive a car with a four-cycle engine, which is 19th century technology. Your car has some improvements, but nothing much original.
Hey, that's my dad you're talking about! Dad worked on what was then called the J-2X (a different program from the current J-2X) during the Saturn program, and is still working for NASA on the new vehicles.
It also allows you to see who sold your email and/or who has been compromised. I have a personal domain for email, and I use a different address for just about everything (and they're usually pretty unique, so not found by address harvesting). I am now getting a lot of spam at the address I gave to Linux Journal; since they went online-only and I cancelled my subscription, I killed that address.
I also had a year of free credit monitoring with one of the "big three" credit agencies (due to somebody else's database compromise), and now (shortly after the year passed and I didn't agree to pay for continuing monitoring) that address is getting spam. Either they sold it, or their database has been compromised. Either way, it gives me SUCH a good feeling about their reliability!
I switched to XFCE (on Fedora 15). It is similar to the GNOME 2 "look and feel", especially if you spend just a little bit of time moving things around (although the default XFCE "look" isn't bad either).
I work for an independent ISP that wholesales BellSouth (AT&T) DSL service. When we order a 6m down/512k up circuit, the sync rates are up to 8128k down and 512k up. I guess that's because most end users still primarily care about the download speed (as long as Netflix works they're happy I suppose).
When a computer that could display 320x200 video cost $3000+, weighed 30 pounds, and covered a typical desk, your assumption was correct. Now you can (obviously) get a compact, lightweight, and inexpensive general purpose computer instead.
If you run a special-purpose system with no OS, you have to write code to handle everything (communications, interrupt handling, etc.). When you can get enough computing power in a small enough package, it cuts development and maintenance time significantly because you can use a general purpose OS to handle all the normal stuff, develop on a standard system, use standard libraries, etc. If there's a bug in your home-grown, hand developed USB device manager, you could spend days trying to track it down. Odds are, there aren't many bugs in the basic I/O parts of the Linux kernel, but if there are, somebody else has probably found them and you can "yum update" to get the fix.
Why do so many home/small business routers/firewalls run Linux, rather than develop a custom networking OS? Because the CPU and RAM needed to run Linux is cheaper than the development time to write and maintain a custom OS. The same is true of this: if you can get a fast-enough Linux-on-a-stick system for $25, why would you waste time writing your own whole system? "Because you can" is only a valid answer if you are only going to make one device (and even then it probably isn't valid).
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.
But the claim is "accurate to 1km", and latency measurement has a much too large margin of error for that.
Your two solutions don't work:
- I've seen 1.5x1.5 DSL (same base speed as a T1), and even 1.5M metroE.
- Static IP block assignments (for DSL customers that pay for it, or any T1/metroE type connection) are not usually grouped by service (especially since customers move from one service to another, or even have multiple services for redundancy).
How do they expect to tell the difference between latency due to distance and latency due to protocols, encoding, etc.? For example, a local T1 might have round-trip latency in the 3-4ms range, while a DSL to the same location might be 10ms (in fast mode, even higher for interleaved). A dialup connection will be much higher, while a metro-ethernet might be less than 1ms. All those times also assume no congestion along the path.
Since the speed of a signal in single-mode fiber is about .6 c, each 1ms difference in round-trip latency gives a 90km margin of error.
In IT, there is another problem... ever try rebooting a server while logged into it remotely?
Sure, use IPMI serial-over-LAN (for most newer servers) or a serial console server (for the old servers or routers/switches/etc.), and it is no big deal. With IPMI, if there is a problem, you can "hit" the reset or power switch remotely as well (for non-IPMI you can use remote power switches). If you have to deal with Windows servers, you can use KVM-over-IP switches; some vendors with IPMI also have KVM extensions (often via a web interface).
The only "trick" to it is having out-of-band access to the console server and power switch if you are managing routers and switches remotely. I manage a remote network facility where the only way I can lose access is if three different providers (one telco and two cable) are down or if the power is out for an extended period (but I'll know about power as soon as it fails). You have to think through exactly what is connected where when setting it up, but it isn't magic.