Re:NASA and the Military, two peas in a pod
on
The Future of NASA
·
· Score: 1
Absolutely. The Military doesn't need any of the 15 billion of NASA's budget. NASA desperately needs some of the Military's 300 Billion budget.
I still think Bush is using this, as did Reagan, as cover for their 'Star Wars' SDI missle defense system -- but so what? Better (cheaper) access to space is better access to space.
From the NASA side: Correct, the military does not need NASA for technology or funding. They do need NASA for cover.
As long as there is a civilian space agency, the military can 'hide in plain site' their use of space. For an example, the 'Clementine' mission to the moon was a technology demonstrator for the military -- but since it had a 'science' purpose, it raised no alarm at all.
And this is really not a problem. The original moon mission had a side-goal of developing heavy boosters for nuclear missles. As you point out, militarizing space is a battle already lost.
Sadly, getting to the moon the first time was more about funding large boosters for nuclear weapons than it was about science.
NASA's purely 'civilian' science applications (Hubble, Mars, 'Mission to Planet Earth', even the space shuttle) have ALWAYS taken a back seat to the Military's applications and funding (spy satellites and ICBM's)
What we need are launch systems that provide a low cost per pound to earth orbit. That was the promise of the Space Shuttle, a promise it was unable to fulfill by the time it was built.
If it takes military dollars to fund development of those systems, or it takes a "Mission To The Moon" to get public backing for the needed funds, so be it. Even if the real use of those launch vehicles is to launch a useless and very expensive 'Star Wars' SDI (missle defense) system -- or 'beat the Chinese', or whatever -- having less-expensive access to space will enable many different civilian NASA applications in the future.
Just because his current reasons are bogus, doesn't mean it's a bad idea.
Lord Hunter is entirely correct. I also have worked on the TMS.
Accident management, and emergency response inside the tunnel is a big deal. The system is designed to allow fire engines, emergency medical, and tow-trucks access to accidents inside the tunnel.
It may be the most expensive 8-miles of highway ever built, but it's built under some of the most expensive land in Boston. It was built without destroying a single home. It was built by digging out underneath an existing operational highway, without taking down that highway first.
It was built through some of the most awful landfill -- containing ships from the 1700's and 1800's. Much of Boston's current land was created by allowing docks to silt-up, sinking a boat or two to stabilize the silt, building the dock longer, and then using the resulting 'new land' for building. Big Dig had to cut through some of this muck without disturbing the buildings built on either side.
I've seen the 'extreme engineering' series referred to elsewhere -- the Hong Kong Airport covered more space and cost less, but they didn't have the limitations placed on the Big Dig project.
It was awfully expensive at $15 Billion. In some ways, it had to be that expensive. And I'm sure it will add to Boston's economic future. Much easier and faster access to the airport. Reduced traffic downtown. I'm honored to have a small part in it.
Any pr0n site i've visited (just out of curiosity, you understand) has usually resulted in LOTS of pop-ups at the time (usually when I try to leave the page), and then LOTS of unsolicited email a day later, some of which is impossible to un-register from.
It would be nice if they would post a source for this chip. I found one in Great Britain, but they don't seem to take credit cards. Even so, chip is 8 british pounds, programmer board is 38 british pounds.
It's a reality that people don't know what they want until they see it.
Thus, closely following strict standards can slowly get you something that they (your customer) will want to have fixed, even if it is exactly what they SAID they wanted in the first place -- Where a Q&D approach will more quickly get that first product -- which still needs to be fixed -- out the door to them.
The Extreme Programming technique tries to address these limitations, and they have some successful approaches which are very slowly being adopted. But in my experience in several software engineering areas -- NASA, IRS, Transportation Systems -- Q&D wins.
Part of the answer is that the size and complexity of software has continued to increase, allowed by the increasing speed and lower cost of hardware.
The result has been that our software has grown faster than our ability to insure it won't crash. The tools and languages have been evolving along with the size of programs being written -- and have not yet caught up.
There is also a tendency in software developers and the companies that hire them to try to add value by stretching the limits of what the earlier people have done. Windows is a prime example of this -- continuing to evolve and incorporate pieces of Browsers, Email, etc. The amazing thing is that crashes in this chaotic environment don't happen more often.
Finally, part of the answer is that stuff from the past (legacy stuff like 'C', Unix and the Windows API) rarely gets thrown away, instead it gets built upon. It would be expensive to throw it away, so people try to fix the warts as they find them. This approach is good, as it lets us continue to re-use solutions that worked. But it has the side effect of preserving some of the more crash-prone aspects of code ('C' string overflows, not checking Unix system calls, etc.)
NASA has for several years been trying to get 'IP in Space' to be practical. This approach overlooks an important aspect, which is that bandwidth to space is difficult and expensive. That's why we don't have it now.
There is a reason the Deep Space Network (DSN) requires huge antennas and depends on line of site, and has a very low bandwidth (~300 baud) -- that's what it takes to get the message through. Adding relay Spacecraft nodes to improve visibility of target Spacecraft is a good idea, but more expensive than just building the target Spacecraft. And using up more of that precious (expensive!) bandwidth in packetizing protocols just increases the expense.
NASA built the world's first ground wide area network (the DSN) to support Gemini and Apollo -- and it does not use TCP/IP. Nasa launched the TDRS satellites (ala Arthur C. Clarke) to provide communication relays for earth satellites to DSN -- and THEY don't use TCP/IP. Currently, we NEED the efficiencies provided by the simple DSN network protocol.
Maybe one day, launch weight to orbit will be less important, or we'll have super high efficiency and low cost transmitters and receivers and processors so we'll have 'spare' bandwidth to apply to this flexibility. But that day is not now.
We use the 'understand C++' tool (www.SCITools.com) to provide a window into 1.5 million lines of C and C++ code. You configure this tool by telling it the subdirectory trees of your source code, and this tool builds a database of every file, object, line of source. It then provides both textual and graphical navigation tools for your code, including dependency trees.
It has an integrated editor with syntax highlighting, and shows what code is #ifdef'ed out.
I don't work for the company, but I've found the tool very useful. For your purposes, it should help locate where mods should be done, and what mods to do differently based on your different compilers and platforms. There are versions that run on Windows and Unix -- I use the Windows version, and 'point' it at my Windows and DEC VMS code.
Slashdot Mirror
Absolutely. The Military doesn't need any of the 15 billion of NASA's budget. NASA desperately needs some of the Military's 300 Billion budget.
I still think Bush is using this, as did Reagan, as cover for their 'Star Wars' SDI missle defense system -- but so what? Better (cheaper) access to space is better access to space.
From the NASA side: Correct, the military does not need NASA for technology or funding. They do need NASA for cover.
As long as there is a civilian space agency, the military can 'hide in plain site' their use of space. For an example, the 'Clementine' mission to the moon was a technology demonstrator for the military -- but since it had a 'science' purpose, it raised no alarm at all.
And this is really not a problem. The original moon mission had a side-goal of developing heavy boosters for nuclear missles. As you point out, militarizing space is a battle already lost.
Sadly, getting to the moon the first time was more about funding large boosters for nuclear weapons than it was about science. NASA's purely 'civilian' science applications (Hubble, Mars, 'Mission to Planet Earth', even the space shuttle) have ALWAYS taken a back seat to the Military's applications and funding (spy satellites and ICBM's) What we need are launch systems that provide a low cost per pound to earth orbit. That was the promise of the Space Shuttle, a promise it was unable to fulfill by the time it was built. If it takes military dollars to fund development of those systems, or it takes a "Mission To The Moon" to get public backing for the needed funds, so be it. Even if the real use of those launch vehicles is to launch a useless and very expensive 'Star Wars' SDI (missle defense) system -- or 'beat the Chinese', or whatever -- having less-expensive access to space will enable many different civilian NASA applications in the future. Just because his current reasons are bogus, doesn't mean it's a bad idea.
Lord Hunter is entirely correct. I also have worked on the TMS.
Accident management, and emergency response inside the tunnel is a big deal. The system is designed to allow fire engines, emergency medical, and tow-trucks access to accidents inside the tunnel.
It may be the most expensive 8-miles of highway ever built, but it's built under some of the most expensive land in Boston. It was built without destroying a single home. It was built by digging out underneath an existing operational highway, without taking down that highway first.
It was built through some of the most awful landfill -- containing ships from the 1700's and 1800's. Much of Boston's current land was created by allowing docks to silt-up, sinking a boat or two to stabilize the silt, building the dock longer, and then using the resulting 'new land' for building. Big Dig had to cut through some of this muck without disturbing the buildings built on either side.
I've seen the 'extreme engineering' series referred to elsewhere -- the Hong Kong Airport covered more space and cost less, but they didn't have the limitations placed on the Big Dig project.
It was awfully expensive at $15 Billion. In some ways, it had to be that expensive. And I'm sure it will add to Boston's economic future. Much easier and faster access to the airport. Reduced traffic downtown. I'm honored to have a small part in it.
Any pr0n site i've visited (just out of curiosity, you understand) has usually resulted in LOTS of pop-ups at the time (usually when I try to leave the page), and then LOTS of unsolicited email a day later, some of which is impossible to un-register from.
It would be nice if they would post a source for this chip. I found one in Great Britain, but they don't seem to take credit cards. Even so, chip is 8 british pounds, programmer board is 38 british pounds.
It's a reality that people don't know what they want until they see it. Thus, closely following strict standards can slowly get you something that they (your customer) will want to have fixed, even if it is exactly what they SAID they wanted in the first place -- Where a Q&D approach will more quickly get that first product -- which still needs to be fixed -- out the door to them. The Extreme Programming technique tries to address these limitations, and they have some successful approaches which are very slowly being adopted. But in my experience in several software engineering areas -- NASA, IRS, Transportation Systems -- Q&D wins.
Part of the answer is that the size and complexity of software has continued to increase, allowed by the increasing speed and lower cost of hardware.
The result has been that our software has grown faster than our ability to insure it won't crash. The tools and languages have been evolving along with the size of programs being written -- and have not yet caught up.
There is also a tendency in software developers and the companies that hire them to try to add value by stretching the limits of what the earlier people have done. Windows is a prime example of this -- continuing to evolve and incorporate pieces of Browsers, Email, etc. The amazing thing is that crashes in this chaotic environment don't happen more often.
Finally, part of the answer is that stuff from the past (legacy stuff like 'C', Unix and the Windows API) rarely gets thrown away, instead it gets built upon. It would be expensive to throw it away, so people try to fix the warts as they find them. This approach is good, as it lets us continue to re-use solutions that worked. But it has the side effect of preserving some of the more crash-prone aspects of code ('C' string overflows, not checking Unix system calls, etc.)
NASA has for several years been trying to get 'IP in Space' to be practical. This approach overlooks an important aspect, which is that bandwidth to space is difficult and expensive. That's why we don't have it now. There is a reason the Deep Space Network (DSN) requires huge antennas and depends on line of site, and has a very low bandwidth (~300 baud) -- that's what it takes to get the message through. Adding relay Spacecraft nodes to improve visibility of target Spacecraft is a good idea, but more expensive than just building the target Spacecraft. And using up more of that precious (expensive!) bandwidth in packetizing protocols just increases the expense. NASA built the world's first ground wide area network (the DSN) to support Gemini and Apollo -- and it does not use TCP/IP. Nasa launched the TDRS satellites (ala Arthur C. Clarke) to provide communication relays for earth satellites to DSN -- and THEY don't use TCP/IP. Currently, we NEED the efficiencies provided by the simple DSN network protocol. Maybe one day, launch weight to orbit will be less important, or we'll have super high efficiency and low cost transmitters and receivers and processors so we'll have 'spare' bandwidth to apply to this flexibility. But that day is not now.
We use the 'understand C++' tool (www.SCITools.com) to provide a window into 1.5 million lines of C and C++ code. You configure this tool by telling it the subdirectory trees of your source code, and this tool builds a database of every file, object, line of source. It then provides both textual and graphical navigation tools for your code, including dependency trees.
It has an integrated editor with syntax highlighting, and shows what code is #ifdef'ed out.
I don't work for the company, but I've found the tool very useful. For your purposes, it should help locate where mods should be done, and what mods to do differently based on your different compilers and platforms. There are versions that run on Windows and Unix -- I use the Windows version, and 'point' it at my Windows and DEC VMS code.