You've apparently never actually been an artist. They need to eat too, you know. While you're right that artists like to create and to share, they also like to be compensated for their efforts, so that they can continue to create and share their work.
Whether or not it's ethical for the heirs of an artist to demand compensation as well is a separate question. But it sounds like it wasn't about dollars in this case, so much as control over how the Daleks were portrayed, and whether that portrayal was what Terry Nation would have wanted.
That's the great thing about oxygen and hydrogen, they're relatively safe and easy to work with.
The problem with LOX and LH2 is that they're cryogenic propellants, which means you either need massive amounts of insulation (and even then you've got problems), massive amounts of pwoer for refrigeration, or you need to accept an extremely short propellant storage life. That's why LOX/LH2 is popular for launch vehicles (very short duration flight) and not for satellites (up to 12-15 years lifetime these days). Satellites prefer propellants that are 'storable', i.e. they can be kept at non-cryogenic temperatures. That's where hydrazine comes in: it's non-cryogenic and has extremely good performance. Hence its prevalence for on-orbit applications. The catch, of course, is that it's toxic, corrosive, and a pain to work with. That's why non-toxic storables like H202 are such a hot research topic.
Nothing serious except that it could cause some real problems with some of the optics on the station, or perhaps it was the solar panels.
That would likely be the case with any propellant, not just hydrazine. The concern there is contamination of sensitive optical surfaces. Anything that can leave deposits on the surface of a lens or solar array coverglass is extremely undesirable. That's the same reason that spacecraft manufacturers have to be careful to build their satellites out of materials that exhibit a low amount of outgassing in vacuum environments.
Actually, I think you'll find that both the Delta and Titan launch vehicles use variants on N2O4/Hydrazine engines on some of their stages. Admittedly, the Titan was recently retired. But AFAIK there are still a few late-model Delta 7xxx's sitting around waiting to be used.
As far as the shift to non-toxics goes, in addition to the shuttle OMS thrusters there are plenty of US spacecraft that use either bi-proplleant N2O4/hydrazine, or mono-propellant hydrazine. Hydrazine is pretty much the standard for liquid propellants when it comes to on-orbit thrusters (for transfers, station-keeping, and momentum dumping). You are correct that the Europeans tend to use hydrazine in launch vehicles much more than the US does. But both use it extensively in their satellites.
I love PostgreSQL. I support Open Source. But I have to say: perhaps you shouldn't have forced a switch to PostgreSQL if it didn't actually meet all of your (and more importantly your company's) needs. Sounds like SQL Server was the better solution in this case.
Uh, hate to break it to you, but plenty of US satellites (and probably launch vehicles as well) use those exact same chemicals. They are the classic propellant mixture for high performance bi-propellant propulsion systems. There's been a push lately to move to so-called 'non-toxic storable propellants', such as high-concetration hydrogen peroxide. But there's a slight performance hit involved, plus a lot of cost in process changes, so it hasn't really caught on so far.
With the Space Shuttle still grounded, the new generation of American boosters still being developed, and demand for reliable launching rockets building up around the world, the prospect of having a huge already-constructed supply of giant boosters built by the most experienced and reliable rocket engineers on earth has been embraced around the world.
I say: Yeah right! The shuttle hasn't launched a satellite in years, let alone a commercial payload. And the 'new generation' of American boosters aren't 'still being developed', they exist right now: the Pegasus and Taurus (Orbital Sciences Corp) at the low end of the market, and the EELVs, i.e. Delta IV and Atlas V (Boeing and Lockheed respectively), at the high end of the market (NASA 'next-gen' launch vehicle will most likely be one of the EELVs). Yet Boeing and Lockheed both claimed they couldn't get sufficient commercial launch contracts for their EELVs, and thus jacked the price up on the DOD launches they were slated to do. Even Pegasus and Taurus launches are rare. Why? Because the cost a crapload! Launch costs can be a significant fraction (up to 50%) of the cost of a satellite. Commercial contractors are launching on Russian rockets because they can do it for 1/5 to 1/10 of the price of a US launch.
The only 'next-gen' launch vehicle likely to put a dent in that anytime soon is SpaceX's Falcon, which promises launch costs on the order of $6M. If they can actually pull it off, Falcon has the potential to be a game changer in the launch market. Until then, cheap Russian launches are the way to go.
You'd expect anything other than a chorus of complaints from/. crowd? Infringing our freedoms in the name of bogus security measures strikes a sour note.;-)
Punisher was so-so. I had high hopes for it, but frankly the old Dolph Lundgren version was about as good. Thin plot, sketchy characterization, and John Travolta all combine to make a movie that just wasn't all that engrossing.
...I could be happy in lots of different roles: web apps, database programming, application programming, I think I could adapt to most things.
Sure, but you have to remember what a resume is for. A resume is essentially a marketing tool - it's a way to get a potential employers attention so that they will bring you in for an interview. Employers wade through a lot of resumes, and they will use anything they can to filter out the chaff. If you are sending a resume for a specific job, your objective should reflect that job. If you don't care what you do, don't put an objective. But realize that you will then be more likely to get filtered out. Both overspecification and underspecification can lead you to miss out on jobs - the trick is to find the right balance. Which is cliched, and not necessarily that helpful, but unfortunately the truth.
Lose the objective, unless you are prepared to be unemployed until you not only find the job that matches your objective
This can be a bit of a double-edged sword. Having found myself in a position where I was wading through a couple of hundred resumes looking for potential interview candidates, I discovered that the objective was my first line filter. You are correct that you will miss out on jobs that don't match your objective. But you will also miss out on jobs if you don't list an objective.
Here's an example: let's say I'm trying to hire an embedded systems programmer. I will immediately discard resumes that give an objective of, say, database programmer (their skills likely don't match, and more importantly they don't want the kind of job I'm trying to fill). Resumes without an objective will go to the bottom of the stack - they may be embedded programmers, they may be DB programmers, but either way, I don't know and don't have time to waste finding out. Folks with embedded programmer or something similar as their objective immediately go into the pool of potential interview candidates. They get filtered further based on what else is on their resume, and eventually I'll bring in a bunch to actually interview. The guys with no objective may get a look-in if I can't find enough satisfactory folks in the embedded programmer pile, but otherwise they're SOL.
Personally I think that it's important to have an objective statment, but that objective should reflect what you actually want to do, and not be just some generic statement like "A job as a computer programmer in an environment where I am challenged and constantly learning new things." That statement tells me nothing. Something that tells me what kind of work you want to do is useful. In software it might be DB vs embedded vs web apps. In the aerospace industry it might be CFD vs structural analysis vs systems engineering. Just my 2c.
You, my friend, need to sit down and catch up on your Neal Stephenson reading. In particular, you need to cozy up with one or both of the books in the Baroque Cycle (Quicksilver or The Confusion), and educate yourself about what the European aristocracy actually consisted of, and how they interacted with the wealthy merchants. You could of course just go and pick up a few history books, but Stephenson has been nice enough to condense a lot of information into a couple of volumes, and to wrap it in an engrossing plotline with entertaining characters. Plus, he's practically a demi-god amongst the/. set, so you'd be doing good things for your geek cred as well.
Thank you for pointing this out. IMHO Tsiolkovsky doesn't get anywhere near enough credit for his genius. Not only did he come up with the idea of the space elevator, he did seminal work on the theory of rocketry (including developing what amounts to the most fundamental formula in propulsion, the "rocket equation": mf = mi*e^(-dv/[g*Isp]) ), developed a number of ideas about space stations, and came up with the idea of solar sails. All of this in the late 1800s, before heaver-than-air aircraft existed, let alone spacecraft. As always, the Wikipedia has more info.
The problem is that you only get that 1 second lag when the satellite is in range of a ground station. We don't have ground stations everywhere, so most satellites spend a large percentage of their orbit out of contact and operating autonomously.
those honors belonged to Rational Corporation (a company whose products were so unstable that it made Windows 95 look good)
Which I've always thought was exceedingly bad advertising. Either
They don't use the Rational Unified Process (if not, why not?) or
They use the Rational Unified Process (or parts thereof) and still managed to produce a bad product
If even the people who are touting some magic software process can't use it to generate decent software then what hope is there for all the other software devs out there that have even less familiarlity with the process?
Process is all well and good, but unless it produces good product, it's pointless. By the same token, once I see the folks at SEI use CMM or their "Personal Software Process" to actually produce a decent piece of software I might actually be convinced that said processes are worthwhile. Until then, it's all just hot air.
You can't control innocent people... but you can control criminals. What do you do with a large group of innocents that you want to control? You make them criminals. You pass so many ridiculous and confusing laws that it's impossible for one to lead any kind of reasonable life on the good side of the law.
I'm not sure if she originated it or not, but a speech roughly similar to the above appeared in Ayn Rand's "Atlas Shrugged".
ESR was trying to show the contrast between open and closed development. It doesn't really matter what platform Apache runs on. What matters is that it is open, has a much larger market share than IIS, and is hacked less. That refutes Microsoft's attempts to paint open source software as inherently less secure.
Uh, not to nitpick or anything, but didn't you recently lose a Mars probe? Admittedly, Beagle II wasn't lost to a metric/imperial error, but it was lost (and since the reasons are presently unknown, it could be something just as silly as the metric/imperial error).
Having said that, you're right about the fact that it's about time for the US to join the 21st century, and ditch the imperial system.
Thiokol engineers specifically warned against operating the O-rings that caused the Challenger mishap in very cold weather (i.e. weather with temperatures that exceeded the design values for the shuttle). They gave these warnings because they did not have sufficient data to be confident that the O-rings would work at those low temperatures, and (IIRC) even had some data that tentatively indicated that the O-rings would fail at low temps. NASA ignored these warnings, and chose to operate the shuttle in a flight regime outside of the specified design envelope.
The fragility of the RCC tiles that led to the Columbia mishap was well known. Several studies pointed out that allowing impacts to these tiles was dangerous. In fact, I have heard from a friend who works with some of the original shuttle design engineers that the shuttle external tank was specifically designed to prevent the chunks of falling ice that caused the Columbia mishap precisely because they knew that the RCC was fragile. NASA later chose to change the tank design to one that was much more susceptible to creating ice fragments. Again causing a situation in which the original design assumptions were violated, and failure resulted.
Bottom line: neither Columbia or Challenger were caused by a lack of knowledge when it came to material properties, but rather an active decision to violate the known design envelope. This kind of action might be excusable in a test flight program that is truly "pushing the envelope" (and even then, I'd expect to see much more in the way of ground testing first), but is certainly not acceptable in an operational program (which is how NASA portrayed the shuttle after the first few flights).
DC-X was not intended as a shuttle replacement (although a derived concept, dubbed "Delta Clipper", did compete for the X-33 contract). DC-X was funded by what was then called BMDO (The Ballistic Missile Defense Organization, the successor to SDIO), and is now called the Missile Defense Agency (MDA).
The DC-X was a one-third-size experimental vehicle, built by McDonnell Douglas under a 22-month, $58 million contract. The DC-X prototype's goals were to verify vertical takeoff and landing, demonstrate subsonic maneuverability, validate airplane-like supportability and maintainability and demonstrate the rapid prototyping development approach. The DC-X suborbital prototype was to be followed by the DC-Y orbital prototype, three times taller, five times heavier (empty) and over twenty-five times heavier fully fueled and loaded. The goal of the orbital Delta Clipper was to put 20,000 pounds of payload into Low Earth orbit (LEO) or 10,000 pounds into polar orbit.
They managed a total of 12 launches, with the final (NASA-run) one resulting in destruction of the vehicle due to mistakes made by the ground crew which prevented one of the landing legs from deploying correctly.
The "official" blame for killing DC-X was that they couldn't build a composite fiber fuel tank big enough, but the real problem was the $billions that Boeing and Lockheed (or Rockwell, at the time) would have lost in support contracts for the Space Shuttle, which probably weighed heavily on the consciences of some Alabama, Washington and Florida congress critters also.
You are here confusing the X-33 program, which was run by NASA and built by Lockheed, with the DC-X program. DC-X died because NASA didn't like it. The X-33 program was indeed killed partly as a result of their inability to build a "conformal" composite propellant tank, as well as severe cost over-runs and a growing realization that it would never carry any significant payload. However, the X-33 design was significantly different than the DC-X/Delta Clipper design, and in many ways pushed the technological envelope much further (which was a major cause of their later over-runs). Why NASA picked the Lockheed design (which was essentially just some marketing material at that point) over the Delta Clipper (which had flight-tested actual hardware) as the winner of the X-33 contract has always been a mystery to me.
And the failures were both catastrophic faliures were due to material properties, not to technology.
That was my point - the parent post's contention that Rutan has it easier because tech has improved is bogus, because the tech hasn't changed a whole lot. The failures in the shuttle were things that would happen even if you were to build a new shuttle today. The "material properties" failures were essentially a result of NASA pushing the materials outside of their design envelope. THat is an operational mistake, not a technological one.
Just to add another data point: the DC-X program, which was our last best hope for cheap access to space, cost around $50M. It was an unmanned tech demonstrator that I don't think was even capable of achieving suborbital altitudes. And even then it was a miracle that it cost as little as it did. DC-X used to be my yardstick for low-cost aerospace programs, but I guess I'm going to have to start using SpaceShipOne/WhiteKnight/TierOne now:-)
Also, they are designing to a much smaller scope than the space shuttle.
Right. Scaled Composites was sensible enough to pick a task that was doable, and that can be used as a stepping stone to bigger, better craft. NASA chose to build a shuttle that tried to be all things to all people, and is not really scalable to anything else. In addition, the things that have resulted in catastrophic failures with the shuttle are not the result of "older" technology - the tech in those areas hasn't developed at anywhere near the same pace that, say, microprocessor tech has advanced.
Slashdot Mirror
Whether or not it's ethical for the heirs of an artist to demand compensation as well is a separate question. But it sounds like it wasn't about dollars in this case, so much as control over how the Daleks were portrayed, and whether that portrayal was what Terry Nation would have wanted.
The problem with LOX and LH2 is that they're cryogenic propellants, which means you either need massive amounts of insulation (and even then you've got problems), massive amounts of pwoer for refrigeration, or you need to accept an extremely short propellant storage life. That's why LOX/LH2 is popular for launch vehicles (very short duration flight) and not for satellites (up to 12-15 years lifetime these days). Satellites prefer propellants that are 'storable', i.e. they can be kept at non-cryogenic temperatures. That's where hydrazine comes in: it's non-cryogenic and has extremely good performance. Hence its prevalence for on-orbit applications. The catch, of course, is that it's toxic, corrosive, and a pain to work with. That's why non-toxic storables like H202 are such a hot research topic.
Nothing serious except that it could cause some real problems with some of the optics on the station, or perhaps it was the solar panels.
That would likely be the case with any propellant, not just hydrazine. The concern there is contamination of sensitive optical surfaces. Anything that can leave deposits on the surface of a lens or solar array coverglass is extremely undesirable. That's the same reason that spacecraft manufacturers have to be careful to build their satellites out of materials that exhibit a low amount of outgassing in vacuum environments.
As far as the shift to non-toxics goes, in addition to the shuttle OMS thrusters there are plenty of US spacecraft that use either bi-proplleant N2O4/hydrazine, or mono-propellant hydrazine. Hydrazine is pretty much the standard for liquid propellants when it comes to on-orbit thrusters (for transfers, station-keeping, and momentum dumping). You are correct that the Europeans tend to use hydrazine in launch vehicles much more than the US does. But both use it extensively in their satellites.
I love PostgreSQL. I support Open Source. But I have to say: perhaps you shouldn't have forced a switch to PostgreSQL if it didn't actually meet all of your (and more importantly your company's) needs. Sounds like SQL Server was the better solution in this case.
Uh, hate to break it to you, but plenty of US satellites (and probably launch vehicles as well) use those exact same chemicals. They are the classic propellant mixture for high performance bi-propellant propulsion systems. There's been a push lately to move to so-called 'non-toxic storable propellants', such as high-concetration hydrogen peroxide. But there's a slight performance hit involved, plus a lot of cost in process changes, so it hasn't really caught on so far.
I say: Yeah right! The shuttle hasn't launched a satellite in years, let alone a commercial payload. And the 'new generation' of American boosters aren't 'still being developed', they exist right now: the Pegasus and Taurus (Orbital Sciences Corp) at the low end of the market, and the EELVs, i.e. Delta IV and Atlas V (Boeing and Lockheed respectively), at the high end of the market (NASA 'next-gen' launch vehicle will most likely be one of the EELVs). Yet Boeing and Lockheed both claimed they couldn't get sufficient commercial launch contracts for their EELVs, and thus jacked the price up on the DOD launches they were slated to do. Even Pegasus and Taurus launches are rare. Why? Because the cost a crapload! Launch costs can be a significant fraction (up to 50%) of the cost of a satellite. Commercial contractors are launching on Russian rockets because they can do it for 1/5 to 1/10 of the price of a US launch.
The only 'next-gen' launch vehicle likely to put a dent in that anytime soon is SpaceX's Falcon, which promises launch costs on the order of $6M. If they can actually pull it off, Falcon has the potential to be a game changer in the launch market. Until then, cheap Russian launches are the way to go.
You'd expect anything other than a chorus of complaints from /. crowd? Infringing our freedoms in the name of bogus security measures strikes a sour note. ;-)
Punisher was so-so. I had high hopes for it, but frankly the old Dolph Lundgren version was about as good. Thin plot, sketchy characterization, and John Travolta all combine to make a movie that just wasn't all that engrossing.
Exactly. I see this being instrumental in preventing the frequent flyer program from taking off ;-)
(and yes, the second pun is also intended... )
Sure, but you have to remember what a resume is for. A resume is essentially a marketing tool - it's a way to get a potential employers attention so that they will bring you in for an interview. Employers wade through a lot of resumes, and they will use anything they can to filter out the chaff. If you are sending a resume for a specific job, your objective should reflect that job. If you don't care what you do, don't put an objective. But realize that you will then be more likely to get filtered out. Both overspecification and underspecification can lead you to miss out on jobs - the trick is to find the right balance. Which is cliched, and not necessarily that helpful, but unfortunately the truth.
This can be a bit of a double-edged sword. Having found myself in a position where I was wading through a couple of hundred resumes looking for potential interview candidates, I discovered that the objective was my first line filter. You are correct that you will miss out on jobs that don't match your objective. But you will also miss out on jobs if you don't list an objective.
Here's an example: let's say I'm trying to hire an embedded systems programmer. I will immediately discard resumes that give an objective of, say, database programmer (their skills likely don't match, and more importantly they don't want the kind of job I'm trying to fill). Resumes without an objective will go to the bottom of the stack - they may be embedded programmers, they may be DB programmers, but either way, I don't know and don't have time to waste finding out. Folks with embedded programmer or something similar as their objective immediately go into the pool of potential interview candidates. They get filtered further based on what else is on their resume, and eventually I'll bring in a bunch to actually interview. The guys with no objective may get a look-in if I can't find enough satisfactory folks in the embedded programmer pile, but otherwise they're SOL.
Personally I think that it's important to have an objective statment, but that objective should reflect what you actually want to do, and not be just some generic statement like "A job as a computer programmer in an environment where I am challenged and constantly learning new things." That statement tells me nothing. Something that tells me what kind of work you want to do is useful. In software it might be DB vs embedded vs web apps. In the aerospace industry it might be CFD vs structural analysis vs systems engineering. Just my 2c.
Only in a non-competitive market - which is usually caused by government regulations preventing other companies from offering solutions.
You, my friend, need to sit down and catch up on your Neal Stephenson reading. In particular, you need to cozy up with one or both of the books in the Baroque Cycle (Quicksilver or The Confusion), and educate yourself about what the European aristocracy actually consisted of, and how they interacted with the wealthy merchants. You could of course just go and pick up a few history books, but Stephenson has been nice enough to condense a lot of information into a couple of volumes, and to wrap it in an engrossing plotline with entertaining characters. Plus, he's practically a demi-god amongst the /. set, so you'd be doing good things for your geek cred as well.
Thank you for pointing this out. IMHO Tsiolkovsky doesn't get anywhere near enough credit for his genius. Not only did he come up with the idea of the space elevator, he did seminal work on the theory of rocketry (including developing what amounts to the most fundamental formula in propulsion, the "rocket equation": mf = mi*e^(-dv/[g*Isp]) ), developed a number of ideas about space stations, and came up with the idea of solar sails. All of this in the late 1800s, before heaver-than-air aircraft existed, let alone spacecraft. As always, the Wikipedia has more info.
The problem is that you only get that 1 second lag when the satellite is in range of a ground station. We don't have ground stations everywhere, so most satellites spend a large percentage of their orbit out of contact and operating autonomously.
Which I've always thought was exceedingly bad advertising. Either
- They don't use the Rational Unified Process (if not, why not?) or
- They use the Rational Unified Process (or parts thereof) and still managed to produce a bad product
If even the people who are touting some magic software process can't use it to generate decent software then what hope is there for all the other software devs out there that have even less familiarlity with the process?Process is all well and good, but unless it produces good product, it's pointless. By the same token, once I see the folks at SEI use CMM or their "Personal Software Process" to actually produce a decent piece of software I might actually be convinced that said processes are worthwhile. Until then, it's all just hot air.
I'm not sure if she originated it or not, but a speech roughly similar to the above appeared in Ayn Rand's "Atlas Shrugged".
ESR was trying to show the contrast between open and closed development. It doesn't really matter what platform Apache runs on. What matters is that it is open, has a much larger market share than IIS, and is hacked less. That refutes Microsoft's attempts to paint open source software as inherently less secure.
Uh, not to nitpick or anything, but didn't you recently lose a Mars probe? Admittedly, Beagle II wasn't lost to a metric/imperial error, but it was lost (and since the reasons are presently unknown, it could be something just as silly as the metric/imperial error).
Having said that, you're right about the fact that it's about time for the US to join the 21st century, and ditch the imperial system.
Yes.
Thiokol engineers specifically warned against operating the O-rings that caused the Challenger mishap in very cold weather (i.e. weather with temperatures that exceeded the design values for the shuttle). They gave these warnings because they did not have sufficient data to be confident that the O-rings would work at those low temperatures, and (IIRC) even had some data that tentatively indicated that the O-rings would fail at low temps. NASA ignored these warnings, and chose to operate the shuttle in a flight regime outside of the specified design envelope.
The fragility of the RCC tiles that led to the Columbia mishap was well known. Several studies pointed out that allowing impacts to these tiles was dangerous. In fact, I have heard from a friend who works with some of the original shuttle design engineers that the shuttle external tank was specifically designed to prevent the chunks of falling ice that caused the Columbia mishap precisely because they knew that the RCC was fragile. NASA later chose to change the tank design to one that was much more susceptible to creating ice fragments. Again causing a situation in which the original design assumptions were violated, and failure resulted.
Bottom line: neither Columbia or Challenger were caused by a lack of knowledge when it came to material properties, but rather an active decision to violate the known design envelope. This kind of action might be excusable in a test flight program that is truly "pushing the envelope" (and even then, I'd expect to see much more in the way of ground testing first), but is certainly not acceptable in an operational program (which is how NASA portrayed the shuttle after the first few flights).
From here:
They managed a total of 12 launches, with the final (NASA-run) one resulting in destruction of the vehicle due to mistakes made by the ground crew which prevented one of the landing legs from deploying correctly.The "official" blame for killing DC-X was that they couldn't build a composite fiber fuel tank big enough, but the real problem was the $billions that Boeing and Lockheed (or Rockwell, at the time) would have lost in support contracts for the Space Shuttle, which probably weighed heavily on the consciences of some Alabama, Washington and Florida congress critters also.
You are here confusing the X-33 program, which was run by NASA and built by Lockheed, with the DC-X program. DC-X died because NASA didn't like it. The X-33 program was indeed killed partly as a result of their inability to build a "conformal" composite propellant tank, as well as severe cost over-runs and a growing realization that it would never carry any significant payload. However, the X-33 design was significantly different than the DC-X/Delta Clipper design, and in many ways pushed the technological envelope much further (which was a major cause of their later over-runs). Why NASA picked the Lockheed design (which was essentially just some marketing material at that point) over the Delta Clipper (which had flight-tested actual hardware) as the winner of the X-33 contract has always been a mystery to me.
That was my point - the parent post's contention that Rutan has it easier because tech has improved is bogus, because the tech hasn't changed a whole lot. The failures in the shuttle were things that would happen even if you were to build a new shuttle today. The "material properties" failures were essentially a result of NASA pushing the materials outside of their design envelope. THat is an operational mistake, not a technological one.
Interestingly enough, his name isn't 'Bert Rutan'. Thankfully, it's not 'NASA' either. It's 'Burt Rutan'
Just to add another data point: the DC-X program, which was our last best hope for cheap access to space, cost around $50M. It was an unmanned tech demonstrator that I don't think was even capable of achieving suborbital altitudes. And even then it was a miracle that it cost as little as it did. DC-X used to be my yardstick for low-cost aerospace programs, but I guess I'm going to have to start using SpaceShipOne/WhiteKnight/TierOne now :-)
Right. Scaled Composites was sensible enough to pick a task that was doable, and that can be used as a stepping stone to bigger, better craft. NASA chose to build a shuttle that tried to be all things to all people, and is not really scalable to anything else. In addition, the things that have resulted in catastrophic failures with the shuttle are not the result of "older" technology - the tech in those areas hasn't developed at anywhere near the same pace that, say, microprocessor tech has advanced.