Slashdot Mirror
X Prize and John Carmack
Anonymous Coward writes "ABC News is running a story ostensibly about the X Prize but in reality they only talk about John Carmack and his teams efforts to win the prize (or at least compete). Quote: 'Some people have commented that I am trying very hard to make aerospace like software, and that's the truth," he says. "If we looked at what we do in software, if we could only compile and test our program once a year, we'd never get anything done. But that's the mode of aerospace.' "
I just hope that they value a quality assurance process more then the typical software engineer. In a game like this you would not be able to release version 2.0.
--
Go calculate something
Aerospace like software, eh?
"Crap, the rocket is not ready and the deadline for launch is tomorrow!"
"Bah, launch it anyways and we'll release a patch later!"
Burn the land and boil the sea, you can't take the sky from me
"Effectively, I stopped buying Ferraris and turbo-charging them and started building rocket ships," Carmack says.
Yeah, I hate it when I have to put off buying Ferraris.
Trolling is a art,
Programmer: Ooops, wrong condition on the 'if' statement. I'll just reboot the rocket's computer and test again! ... what rocket?
Flight director (emerging from flaming debris): Errr
Carmack says: Some people have commented that I am trying very hard to make aerospace like software, and that's the truth
Unfortunate analogy?
Why not develop and test their spaceship mostly via computer simluation. That's Carmack's strong suit anyway. Besides, I'd love to get my hands on that sort of simulator. Though I'd probably need a beowulf cluster...
I read the internet for the articles.
Some people have commented that I am trying very hard to make aerospace like software, and that's the truth
Gives a whole new meaning to "blue screen of death", doesn't it?
It should be noted that they're only carrying show notes, and that the interview with John Carmack was actually carried out by TechTV's Tech Live, and was run last night at 8 PM EST, and again twice this morning.
It will air again tonight at 6 PM EST.
"Mod, mod, mod...and another troll bites the dust."
"We have liftoff!" == "Excellent!"
"Our trajectory is acceptable for re-entry"=="Accuracy!"
"Our rocket landed, and it's data storage is still intact"=="Perfect!"
* luckyguesser almost dodged John_Cormack's rocket.
The power of Christ compiles you.
A Random Blog
When he says Aerospace Software, he really means adding net jetpacks to Doom and allowing them to be used outside earth's atmosphere... you guys are interpreting this all wrong!
Pls No Negative Modding!
Indeed, conventional rocket design is pretty brute-force. Big engine, hunking mechanical control systems with minimal intelligence.
Given the capabilities of modern IT, it makes much more sense to use software as the core of the system, in the same was as software is the core of a device like the Segway, or the stair-climbing robot, or the telescopes that consist of a thousand small mirrors, not one large one.
Rocket science has not changed significantly since 1950, and needs a rethink. I believe this project is a solid approach that has good chances of succeeding, and if so, will redefine the way we conceive of this kind of engineering project in the future.
Ceci n'est pas une signature
Dude, it's this.
If he wins, I wonder if the ships' lifecycle will resemble those of his games?
I can see it allready:
1) Carmack devises a ship that excells in performance, but requires very costly componenets in order to deliver on its full functionality.
2) After a years' worth of excellent operational records, other countries license the engine design and build their own ships off of it
3) 2 years after launch a thriving Spaceship MOD community is launching new ships into space every couple of months....
What about the twinkie? - Dr. Peter Venkman, PHD
Duh.
.sigs are for post^Hers.
The crew hopes to launch the real deal at the White Sands Missile Range in New Mexico.
This, I have known for a while: I have a buddy that works in WSMR's flight safety group. I'm looking forward to it. I'm hoping that I'll get to watch. *crossed fingers*
However, John's attitude of build a little, test a little isn't just a software attitude. It's the old Xplanes or NACA (pre NASA) attitude towards aeronautics.
For those of you that still use usenet, go check out the sci.space.* heirarchy. You'll find that John's a contributor there, but he's empathetically not the first to espouse such views. However, I know of none that have compared it to software development like he did in this interview.
Do you know why the road less traveled by is littered with the bones of the unwary?
Somehow, "my software crashed" lacks that ominous feel that "my software crashed" has...
Then != Than
And yeah, parent post is a troll.
.sigs are for post^Hers.
Moderators, please watch for these signs:
* Claims that a server like abcnews.com, cnn.com, microsoft.com, etc is "slowing down"
* Anonymous Coward posts with no reference to the poster's true identity
* Lines like so he can cart around cocket parts
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
Dick Rutan.
Read the article for once people instead of knee-jerk reacting to an analogy.
Carmack merely wants to improve the method by which rockets are constructed. He says he starts small and builds his way up, rather than constructing the rocket and control system and then working for six months to work out the problems.
This is a well-known software development technique, and I don't see why it wouldn't be generalizable to other fields. If anything it should inspire more confidence in the creator at least.
We were building a satellite with upload-code capability, and were facing a deadline, so we ran the numbers.
We had a very slow uplink, maybe 300 baud (packet overhead and protocol turn-around time included). And we had a lot of code. The satellite was visible only for maybe 8 minutes out of every 90 minute orbit, so unless we had ground stations positioned all around the world and synchronized, we were effectively limited to about 30 baud long-term average. And we had a lot of code.
What's worse is we figured that the radiation environment would reset the satellite every so often... this was fine in normal operation, but would kill an upload. It would be almost statistically impossible to upload the entire code without an upset.
So, we all got back to work.
Eventually, we got good code and launched the satellite. Unfortuantly, the rocket flew off-course and was blown up by the range safety officer -- the satellite ended up in the water. Our company also made bouys (functionally, they are similar concept satellites), so the debate was always whether we should load the regular code or the bouy code into the satellites. We didn't try to figure out the code-uplink case for "underwater".
HIV Crosses Species Barrier... into Muppets
What most of these articles tend to obscure is that NASA flights and X-Prize flights are really doing different things. NASA is directed almost entirely at orbital spaceflight and beyond. The X-Prize is directed at sub-orbital flight. The physics of orbital spaceflight effectively require the use of large, multi-stage rockets with very high speeds. Sub-orbital flight does not. The X-Prize appears to be aimed at opening up the sub-orbital domain, which has been largely neglected so far.
We got where we are in the aircraft industry by using contests and prizes. It motivates people who aren't established in the industry (or to join an unestablished industry) to try out their ideas, and accept the risks for the chance of a huge reward (and hopefully not 'the great reward'). Think of it as a way of short-circuiting the old-boys network.
Also, you can be sure people are going to die because of this. People died trying to get to Asia, cross the Atlantic, get to the north pole, discover redioactivity, (nearly died) to discover electricity, and create trains, automobiles and airplanes. Why do you think this advance will cost less than most of the others? That's the nature of the game. Now as far as general destruction, that's easy, too. Launch over deserted land or over water, and you'll minimize the risk to uninvolved individuals.
Ultimately, advancement requires risk. Large, established organizations are adverse to risk, leaving two options: slowed (or stalled) innovation, or introduction of players willing to take risks. I personally would like to see something more advanced than the space shuttle, and at the rate NASA is going, I'll be waiting another decade or three for them to do that.
Sure I'm paranoid, but am I paranoid enough?
This will spur private research and investment in space technology. That's a good thing. We can't count on NASA to do it, they just don't have the budget to do much anymore.
Early development should be done by private groups since they're more flexible and agile. Then once a technology is established, larger bodies (NASA perhaps) could use their vast experience to manage/maintain. Despite the failings of NASA, they are still quite good at what they do. I doubt there are many other groups that can manage end-to-end some of the space applications that NASA does.
Of course, if the contest were to see who could make portable, inconspicuous nukes, that would be a different story.
.sigs are for post^Hers.
The tricky part is that I don't think tests done with small rockets will necessarily give you a good idea of how the big rocket will perform. If that were the case, all we'd really need is to buy a model rocket kit from Wal-Mart and just build it 20x bigger.
But software design would benefit from being more like aerospace design. Aerospace can't afford the test-patch-test-patch cycle that software goes through. Before we send our designs off to be built, we had better be damn sure they will work. We can't just decide to bolt a wing on later if the orginial doesn't work--it's too expensive and the consequences of a failure are too great. Accurate computer modeling is rapidly becoming the engineer's best friend.
I fucking shudder to think of the average software developer deciding that his skills can carry over into engineering. Like the parent said, QA in the software community at large is sadly lacking. I don't understand why programmers get away with it. From an engineer's perspective, it just looks like shoddy design or laziness. Is it just that software is so intangible, and losses due to bad code are hard to quantify? Is it that we're just used to buggy software and it doesn't occur to us that it could be otherwise?
(Frustration brought to you by:
Sobig: Bogging Down My Company's Network Since Early This Week
and
Win2k SP Four: Breaking Third Party Software So You Don't Have To.)
-Carolyn
Like Daddy always said: if you can't dazzle 'em with brilliance, baffle 'em with bullshit.
You call it a holy war, I call it English. The English language is being eroded gradually by ignorance.
There's a reason for having two words, then and than. It's preferrable to have exact words that aren't dependent upon context. If we just toss out "than", and exclusively use "then", our language will become even less precise.
Some other common mistakes that really suck:
confusing "your" with "you're"
confusing "their" with "they're"
adding unnecessary apostrophes to plural words - Dog's and Cat's...
Just because some people have forgotten or were never taught how to write the language they speak doesn't mean that we should just dumb it down completely. Taken to the extreme, we could just back all the way up to grunts and growls.
.sigs are for post^Hers.
I admire and respect Carmack's space program. He is doing a number of innovative things.
His program of building control systems and then big rockets is mentioned in the article. It's unfortunate that so far whenever they've tried to launch a rocket the computer has immediately crashed -- but they seem to have a handle on why this is happening and the current computer construction and mounting system is far better than the previous ones. He also has a tremendous amount of telemetry, and analyzes the inevitable failures exhaustively.
They is now using a fairly innovative mix of medium-strength hydrogen peroxide and some fuel to power the rocket. Other people (and Armadillo, previously) have used highly purified hydrogen peroxide, but that is hard to get (and expensive) in the quantities that they need. This mixed monopropellant has a higher specific impulse, too.
They are using a innovative final recovery system -- the ship lands nose first on a long aluminum cone that crushes to absorb energy. Unique, cheap, and innovative -- if funny-looking.
The thing I like the most, though, is his website http://www.armadilloaerospace.com (it will surely be slashdotted for the next couple of days.) Carmack is religious about posting the results of the last weeks efforts, warts and all. It appears that he receives substantial insight from people responding to these progress reports (apparently the mixed monopropellant research was instigated by somebody posting results of German WW2 torpedo experiments.) This kind of openness is quite rare in aerospace research.
Anyway, all the best to Carmack et al. I think that Rutan's Spaceship One project may win the X prize, but maybe not -- his system depends on a lot of planning and simulation being accurate, whe re Armadillo can respin the project many ways if things don't work out the first (or second) try.
thad
I love Mondays. On a Monday, anything is possible.
...wouldn't necessarily be a bad idea.
Yeah, but damn if that code wouldn't be perfect.
Think to the bad old days of batch processing, where you handed your code to one of the engineer/sysadmin/priests, who would feed it to the system when the system was done doing its current work. You might not get the results of the build+run for 24 hours after submitting it. And you wouldn't get another chance for another 24 hours.
So, before you handed in the code, you would read it. Because the smallest typo would set you back another 24 hours. You would try to prove -- formally, mathematically -- that it was correct, because a simple logic error ("oops, wrote ==, wanted to write !=") would set you back 24 hours, and doing the proofing was faster than waiting an additional day.
Maybe they "got nothing done" back then, but when that software was finished, it was good.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Burt can win this. If I had to put my money on someone at this point, I's put it on him. He is a great designer and organizer. As an EAA'er myself, I have a lot of respect for him.
That said, he is having the same problem he had with his helicopter/SSTO project. He doesn't have an engine yet, and time is running pretty short for development. He has two contractors bidding, but the timeline is so tight, that more than one or two major development hiccups will screw the pooch for his project. White Knight and SSO are great looking, and the concept is sound, but it took 3 years to design a decent engine for the x-15, and I have a feeling that designing one for a ship designed for the same flight profile as the x-15 will have similar problems. Don't hand him the check just yet.
"Curiosity killed the cat, but for a while I was a suspect."- Steven Wright
Obviously, you never worked on the software portion of an aerospace project.
I know from personal experience that the test-patch-test-patch cycle is alive and well in all the software products produced by the aerospace corporations that I have worked at.
The design of the product like a airplane or ship or whatever itself might need alot of upfront resources, but I will tell you that there are multimillion dollar maintenance contracts on aerospace software maintenance. Fixing bugs that got by QA.
This is for the software. Not the hardware.
And yes, these are Engineers. And there is a QA process, its just that it seems software is much more complex and is therefore much harder to test.
Most historians think the Russian model of aerospace development was more successful than the American model. The Russians built fully functional rockets and did virtually no testing. That led to very fast improvements and now they're the only nation still launching humans into space. The Americans did incremental testing, only building full test flights in the final stages and you know where their human space flight ended up.
Aerospace problems are a lot harder than software problems, but unlike software, you can't share aerospace. You can't make a web page, have your achievements downloaded, and leave a lasting impression on people by building a rocket prototype. It ends up being done for yourself, isolated. Except for one or two blog articles no-one thinks about it.
never let John Carmak write systems that peoples lived depend on.
The Kruger Dunning explains most post on
His name is: Phillip Screwdriver.
A Good Intro to NetBS
I see a lot of skeptics replying, "Carmack is wrong headed, if you screw up a rocket, it crashes, it's not just a compile bug". Many of these comments seem to be suggesting that we should go back to the "old school" style of programmer that thought & planned his code before submitting, instead of relying on the feedback of a compiler.
This is based on the completely false assertion that code will be better / more bug free if you "think harder". It ignores that in the past 30 years of programming we have learned the value of feedback in the software development thought process.
The idea that somehow if I spend more time in a chair planning the solution that the solution will be better if I evolve my way to it is some sort of romantic vision of how solutions to tough problems are actually solved. This could be seen as a version the "prove the code works" vs. "test the code" debate. Or that proofs follow from the axioms. I counter that usually it's a process of some rather messy creativity, trial, and error.
In programming in the large, we have generally learned that "phased" approaches to software development (known as waterfall) tend not to work very well because they de-emphasize the feedback that occurs downstream in the development process. To contrast, an incremental approach enables smaller steps to be delivered , and minimizes the impact of erroneous assumptions discovered downstream in the development.
In programming in the small, development is a form of communication between the computer and the developer. The computer is designed to tell us where we are wrong, we just need to tell it exactly what to expect: for this we have compilers and test cases. Compilers can't catch everything.
Now, this is not suggesting that today's style of "let's see if it compiles!" development is appropriate for aerospace. That is the unfortunate effect of feedback & incremental approaches - it makes programming easier, even for people that shouldn't be doing it. These people "program by accident", and just meander through their code until it does the job, sort of. This is not a reflection of the incremental approach in the hands of an experienced developer that "programs on purpose", that understands what he or she is doing at every step of the way.
Aerospace development isn't "amateur hour", and the incremental approach will just make professionals all the more productive.
-Stu
Do you write an entire program before compiling it and testing it? Of course not, no one does. That's what J.C. is suggesting, that incremental development can be done in Aerospace.
I figured they'd just point a rocket launcher at the ground and take off that way...
chuk