The rocket appears to be unstable, which is to say that the center of gravity is behind the center of pressure. Looking at the pictures, it's not
too surprising. The vehicle is too short vs. it's diameter, and the flared base isn't big enough to stabilize it (i.e. not big enough to push the Cp
back behind the Cg of the vehicle).
I imagine that Carmack etc. knew that it was aerodynamically unstable and counted on active feedback controls to compensate, which was
their primary mistake. By doing so, they greatly increased the critical complexity of the system, which is to say they increased the number of
things that would kill the vehicle if any one of them failed.
This isn't a scaled up Estes rocket; analyzing it as one is a mistake.
As other replies have pointed out, "real" rocket launch vehicles are aerodynamically unstable or only stable over limited ranges of flight. Even if this sized rocket could have been made aerodynamically stable, they are building towards larger vehicles and in particular, vertical takeoff vertical landing which absolutely requires full 3 axis stabilization and control authority.
Think the DC-X VTVL experimental test rocket. Carmack has alluded repeatedly to it being a dynamics and flight operations precursor to what he's trying to do.
The PDF for the study is hosted on IBM's website... I'd be willing to bet that it was IBM that commissioned the study. Anybody know?
**begin sarcasm** What a big suprise that would be if a study funded by IBM finds that their Linux solutions perform better than Windows and Sun! **end sarcasm**
Their numbers on Solaris are whacko.
To establish my background (and biases), I've been a UNIX sysadmin for 15 years primarily on Sun, but including most other UNIX variants and a little Windows. I'm currently at a Sun VAR, so I have an idea about how to price Sun boxes and software.
First of all, it will take about 1 CPU to meet their Processing Unit definition. When your basline comparison unit is less than 1 CPUs worth of effort, comparing using Sun enterprise class systems is ridiculous. They're not intended to replace a stack of 1U servers; they're there for the one application which needs 99.5% uptime or better and doesn't split across clusters of independent systems. The Sun 1U servers (Intel or SPARC architecture) are $1k each including OS, not this ridiculous $12.5K per CPU that they ascribe to software costs.
My opinion: this is a sly slam on Sun made to look like a boost of Linux.
A number of years ago, SGI loaned a Reality Engine (large, multi-cabinet graphics system) to be demoed at a Case for Mars space conference in Boulder, CO. It rode in a large truck from California to Boulder.
When it arrived, it was discovered that nobody had bothered to strap it in for the trip. The boxes were duly opened. The cabinets were found to be bent over out of vertical by several inches, with all the cards and such inside similarly misaligned, and fairly obvious backplane damage as a result.
I missed most of the post-mortem, but my wife and a friend got to do the inspection and I heard parts of the call to SGI...
I was watching a 2 hour Discovery special on the Mars Society Canadian habitat project last night, and I couldn't decide if these guys are visionaries or crackpots.
A little of both. I am both a MS member (not active in the current technical program, though) and an independent engineer and space mission designer, and your criticisms are fairly well aimed here.
One some levels, the organisation was impressive, with tons of construction material being airdropped onto an island. The last drop shed it's 'chute and wrecked the construction crane and some other material. Brought up on a diet of space opera (and Junkyard Wars), I expected them to swing into action with a "can do!" plan. What actually happened was that the project manager and society head had a falling out over safety, the construction team walked off, a new architect had to be flown in, and a long debate over what to do next ensued. OK, they did get it all sorted eventually, but the attitude of some of the team really surprised me. After all, this was an "opportunity" rather than a problem (to use management parlance), but some of them seemed to think that it was better to play it safe, call the whole thing off, and try again the next year. Uh, guys, a manned Mars mission wouldn't have that luxury.
Accurate assessment, but really just points out what the Mars Society is and isn't.
It's a volounteer organization, fundraising focus, and PR organization trying to do some real field and technical work (on a shoestring) to advance the cause of manned Mars missions. It's not a professional engineering or space mission operations team. The lack of experience shows a lot. The lack of trained personel shows a lot. The lack of ability to select workers for the absolute best in their field shows a lot... a lot of people forget how selective NASA has been able to be in the past. Volounteer organizations have to make do with whoever shows up.
The plus side... they can deploy a base on a remote island in the Canadian arctic and operate it for a summer for about what it takes to keep two of the fifty seats in Mission Control in Houston staffed 24x7 year round, or deploy one to Utah for about the same amount. Useful things to do.
And then there were the mock EVA suits that they were using, that were - to be brutally frank - kiddie playtime stuff, being mostly trash can lids and plastic tubing. They were quite honest about this, saying that the idea was merely to try out a lot of activities in the suits to try and predict the problems we'll encounter on Mars. Problem was, they failed to apply lessons that we already know, and started with circa 1950's technology. The big problems were that the helmets fogged up (duh), that it's hard to get items out of your own pockets (so you need mirrors on your wrists, which they knew that NASA suits already have but didn't put on their own suits) and that it's hard to read dim LCD screens through a fogged up helmet.
Fair assessment of the first pass suits.
There have been some pretty lively flame wars over the suits on Usenet and other discussion areas. You're not alone in pointing out the problems with the alpha version suits. The suits basically were mostly impaired by ongoing lack of time and budget to engineer them. They were a rush job done by three harried volounteers in Boulder with almost no budget.
That said, they did discover some useful things about mobility and operations with them. Some of those discoveries were rediscoveries of things that NASA learned already, but there wasn't time to avoid. Some of them were new. One thing NASA really didn't record well was the planning and support cycle for planetary EVA operations; one of the things the Mars Society *has* done well was to videotape and study all of that. Right now, there's only one group with any current, active experience planning and supporting planetary EVA operations, and it's not NASA. The operational lessons are being properly recorded by real psychologists and operations engineers and should be retained by the aerospace community this time around, we all hope.
It's important to note finally on this topic that the suits are an alpha test version. The two stations are going to be operated on an ongoing basis, and it's intended that the fidelity of the simulation increase over time: better suits, better gear, more realistic remote support, etc. There are some lessons that these early suits won't learn, but there are many that they can. As long as we eventually get to all of them, it's a reasonable program.
I really do want to be enthusiastic about the Mars Society, but I can't help but feel that it's a big talking shop and mutual support society for very frustrated people who really wish that some serious money would get put into a Mars mission. It's hard to criticize them for doing something, but it's also hard to take Mars Society seriously when they seem to be more like a Disney Space Camp group having a fun vacation rather than doing bona fide boundary pushing experimentation.
If these were people hanging around on vacation, that might be a fair criticism. But it takes an enormous amount of volounteer labor to make these things happen: tens of thousands of volounteer hours a year have gone into the Arctic and now Desert stations, for several years now. People aren't goofing off or lying around being lazy, they're doing the real work that building these things and operating them takes.
There are lots of things wrong with the Mars Society at one level or another, but it's not a summer camp. This was demonstrated when the parachute failed to open at Devon Island (for which I am eternally embarrassed... I believe I was the first person to suggest to Bob that they use paradrops for the equipment, though I had nothing to do with the actual operation to do it or build the base). That was demonstrated a couple of days ago when two members survived a plane crash on their way to the Desert station... we nearly lost Devo's guitarist there, damnit.
Say, like an Sun E10000 or Sun E15000 which costs a ton more than that IBM server quoted (for about the same power)...oh yeah, and Sun won't let you buy one unless you order a service contract... meaning, they come with a repair man.
In those cases, when you're paying for a Mainframe, you're getting a mainframe. Also, fairly, with the IBM systems running native OSes, big SGI and HP boxes, etc.
What Sun is pointing out is that the behaviour of the Linux-in-VM systems from IBM appears to be inferior of that of an equivalent cluster of standalone Linux servers, which costs immensely less than the S/390 box and is easier to maintain.
At the time I write this, there are three testimonials from people who say they evaluated or ran these IBM Linux on Mainframe/VM systems posted in the overall commentary, and all of them are relatively negative. I have no personal experience with that, but going by both the theoretical issues and the posted testimonials, I have to lean towards Sun being right on this one.
As a disclaimer, I'm a heavily Solaris/SPARC oriented user and admin, and have specified and built multi-E10K sites. I appreciate Beowulf clusters and similar large Linux/FreeBSD/etc clusters but haven't built one yet.
To get equivalent safety, working with LOX will cost 10 times as much.
Um, no, not really. First of all, high grade peroxide costs $0.50/lb for 70% grade in tankcar load quantities or larger, and $10/lb or so for 97% grade commercially concentrated (you can distill 90%+ yourself from 70%, but it requires significant processing equipment and has non-zero risk associated). LOX is cheaper than beer ($0.10/lb or less in large bulk quantities).
Second of all, handling liquid oxygen and nitrogen grade cryogenics is pretty easy. LOX is used in nearly all hospitals for their oxygen feeds; there's usually a LOX tank out in the parking lot somewhere. You have to avoid using organic materials in the piping, but it's handled by relatively low-trained truckers distributing it, in tanker truckload quantities, moved around cities with little hassle or hazmat risk, every day. It has risks, and must be properly respected, but is not a problem.
High-test peroxide is also subject to self-deomposition and detonation in extreme cases.
We have lively regular debates about the merits of various propellants in online forums like
sci.space.policy and
sci.space.tech.
Talk to professional rocket engineers and nobody is even vaguely afraid of LOX. It's not everybody's first choice, but it's not a bad one.
Peroxide isn't the worst choice by far (FLOX, Liquid Fluorine, Nitrogen Tetroxide, Liquid Ozone, Chlorine PentaFluoride all are far farworse). But LOX is a really good choice.
This reminds me of a story I heard once where someone described a method of using SMTP itself as a backup mechanism.
Basically you tar/zip/whatever up all your files and email them to a non-existant address. The SMTP server will try to redeliver for like 5 days, and eventually bounce the message back to you.
There used to be an (imfamous) backup method called the UUCP Loop backup. You emailed your files (uuencoded crypted tarfile of the stuff) to host1!host2!host3!host4!host5!host6!host7!host8!yo urhost!yourself
You had to chose a path that took acceptably long, of course, to ensure there being 1-2 in flight at any time.
Fine. Go find a processor that's space qualified and yet capable of doing this sort of thing reliably. Most embedded platforms won't survive the radiation, let alone the head conduction problems...
See the RAD750 CPU and embedded computer family at:
BAE Systems.
It's true that you probably don't want to use off the shelf CPUs in deep space (though many of them will do acceptably well; the typical deep space radiation environment is not so bad, if you don't fly during high solar flare times and can put up with a few resets from time to time). But there are plenty of space-rated components for those who know where to look and have the $$$. It's not bleeding edge, but it's not that far back either.
Re:Sometimes scientists are just too anal. . .
on
Mice Headed for Mars?
·
· Score: 1
Look, no one needs to "prove" that traveling to Mars at 1MG would be a good idea. Anyone halfway attuned to the issues could rattle off 20 good reasons for doing this in no more than 60 seconds.
What's more, this won't "prove" anything. It will offer *support* for the above mentioned good reasons, none of which anybody questions in the first place.
What reasons would there be for NOT making the trip at 1MG?
There's only one really, and it's one of pure practicallity. To travel to Mars at 1MG you must, by *definition*, accelerate at 1MG for the entire duration of the trip!
As opposed to boosting out of Earth orbit, coasting most of the way at no fuel cost and braking when you get there.
You appear to have missed the option of boosting out of Earth orbit, coasting the distance there and braking to stop when you get there, but spinning your spacecraft (usually tethered to a counterweight, in most scenarios) en route to create centrifugal force pseudo-gravity. This is in fact one of the key features of the Mars Direct mission architecture, and is at least seriously considered for all of the other manned Mars mission architectures in the last decade or so.
This project is a Big Deal. Whether mammals can survive for indefinite periods (or long but finite periods) at Mars gravity makes a huge difference in if or how we approach going to Mars. It's a question that is fundamental to long term planning of Mars missions, and due to delays in the Space Station's centrifuge NASA wasn't even going to be able to start looking at it until 2009, we think.
It seems to me that Free Software according to the FSF is a philosophy. To feel guilty about using free software and to think that whoever wrote it somehow deserves a reward seems to me to be contrary to the reason they wrote the sotware to begin with. Using it and contributing to it if you can is one thing, but feeling like you owe them money is another altogether.
I think you're confusing "freely redistributable" with "free of charge".
Open Software's objective is to make computer related intellectual property common property as much as possible. That is a good thing.
It's not a stated objective to have people always starving, or even going unrewarded for their work.
Some of the forms of those rewards are public accolades, some of them the companies that (still) make money doing Open Source software hiring people, but there's nothing wrong with donations to programmers in general. Some might not want it, but that doesn't mean none of them do.
So how come it is OK for MAPS to claim copyright and charge for access to community-submitted data
They're claiming what is the equivalent of a compilation copyright. They aren't copyrighting the individual reports; they're copyrighting the whole database etc.
The need to charge for it is presumably related to the need to pay for the tens of people, computers, major network bandwidth used to provide that "free" info to you... RBL stopped being run by volounteers years ago, it didn't scale. If you don't like it, form your own free RBL-like list and solicit nominations, etc... but you will run out of money and life in a few years, like they have.
At the risk of flaming, I ask everyone to please take a look at this diagram if you really think the Space Shuttle wings are "large," or that they could conceivably weigh anything remotely close to half of the vehicle's weight. The fuel, on the other hand, weighs many times more than the entire ship plus payload. There's just no comparison between a passive lifting body and fuel. To quote Pulp Fiction, "it aint the same ball park and it aint the same league, it aint even the same fuckin' sport!"
You're going riiight past it. *launch* weights don't matter a bit for landing. What you're trying to land is the empty weight (plus any returned-to-the-earth payload).
The tradeoff is wings (empty weight) versus fuel (and slightly larger tanks) to land with. You need fuel for say... slowing from 50 meters per second (free fall speed of your empty rocket) to 0 and hover for a bit, from an altitude of 500 meters or so for engine ignition. That works out to about 20 seconds of thrust, at an average of
something like 1.25 Gs, or 250 meters per second of velocity change. About 6-10% of the landed mass in fuel, perhaps.
If you don't think wings weigh 6-10% of the landed mass of an aircraft or glider or glide-landing spacecraft, you need to research more. They're typically 9-15% of the weight, including the control surfaces and such.
Weapons-grade fissionable materials in themselves are relatively easy to make. Any nation that has the know-how to build a nuclear reactor can build a breeder reactor to make weapons-grade uranium. The technology required to make the actual bomb, though, is pretty difficult to figure out.
This is exactly backwards. Bomb design is, though not exactly kindergarden stuff, actually fairly simple and easy if you know where to look to find the right info to work with. It's manufacturing the special materials in quantity which is hard and expensive.
Around 1970, the Department of Energy (and specificaly Edward Teller) did a threat analysis program called variously
The Third-Country Experiment
or
The n-th Country Experiment.
They took three brand new physics PhDs with no specific course work or training in nuclear physics and told them to design a bomb using only open source materials. This they did, designing a compact (1-ton), reliable (was analyzed by professionals and determined to have essentially full reliability / functionality, though one was not manufactured to test) weaponized plutonium implosion device, in 18 months time. So there's been a demonstration that it can take as little as less than 5 man-years effort.
The Space Shuttle has been using the "nice friendly atmosphere" to land without fuel for about the last 20 years. Nobody has to prove it can be done, it's just a matter of doing it at commercial cost. Landing on thrust will always mean using additional takeoff fuel to lift the landing fuel (and itself), which must increase the cost because fuel costs more than nothing. There's no reason to insist on vertical landing; we have airports! You wouldn't need to carry any more landing fuel than it takes to make a couple extra passes at the runway in case of trouble. Why are people so attached to the idea of using thrust to lower the rocket all the way to the ground when gliding is freely available?
Very simple answer:
Why are you carrying wings all the way to orbit and back which are only useful on landing? Wings are heavy, and expensive to engineer, build, and protect from re-entry heat.
Professionals argue back and forth about the relative advantages of powered versus aero-glide landing all the time. It's very clear that at best, it's very close between the two options. Extra fuel requires just slighly larger tanks and restartable rocket motors, which isn't all that hard. The numbers can work out either way.
For more info, and to re-start the perpetual flamewar, Usenet's
sci.space.policy
is a good place to look (or sci.space.tech, but I moderate it, and hesitate to push outside conversations into the moderated group...).
I just want to know how it's going to carry enough fuel for takeoff AND landing, and still be able to lift its own weight.
Fuel efficiency for rocket motors is measured by a quantity called Specific Impulse, or Isp. This is roughly described as the length of time you will get one pound of thrust for, if burning one pound of fuel. Typical values for professional engines are 250-330 seconds, for hydrogen/oxygen engines 400-450 seconds. Model rockets are 80-180 seconds depending on the fuel.
You only need a little bit more thrust than weight to take off and hover. Space launch rockets typically launch with thrust of 1.2 to 1.3 times their weight. For low altitude demonstrators, if you have half your takeoff weight in fuel (low for a space launcher, typical for a cheap demo) then you should be able to hover for 3-5 minutes or do low altitude flights and then land with not much less endurance.
You missed the Imperium Games edition and Far Future Enterprises (aka Marc Miller Rides Again) edition currently going nowhere.
T, MT, and TNE were all Game Designers Workshop products. GDW went down some years ago, when the collecting card games industry took off, roughly. Oweing a bunch of us for contributions, too, though not nearly as badly as IG screwed people.
My impression, based on Steve's report on his website, is that there's gotta be financial chicanery going on with his ex-CFO. Steady fundamentals but a lack of closed accounting periods equals something rotten in Denmark. This would be unlike what took GDW down (fundamentals faded as industry changed) or IG (never had 'em to start with...).
>>The difficulty of guidance and control is overrated.
...but should not be underestimated, either.
While I agree you're doing this right to make
it work (for your application), you did show
us quite a number of stability failures in
the video slideshow...
RTG Plutonium is Pu-238, with a much shorter 89 year halflife (Pu-239's is 24,000 years). Pu-238 is generally considered not fissile. Other isotopes used have included Ce-144, Cm-242, Sr-90, Po-210; Pu-238 has the longest lifetime of those and that led to its being the standard for all RTGs flown by the US since 1964, though some other experimental units with other isotopes were tested in the 60s and 70s.
Heat output is roughly inversely porportional to halflife (how much of it decays in a given time period?).
Um...you probably didn't get any mail from them because they hadn't yet been taken off the RBL. The test account was in no way RBL protected. Come on, man, that's obvious.
When this all started, I hopped over to YesMail's site looking for info on what their actual business practices were. It stated they were a confirmation-requireing opt in only service. So I created a new test account and signed it up for some stuff I might be interested in. Filled out the web form. Got a response saying they would email me a confirmation. Nada, so far. Either they aren't actually requiring confirmations or their outbound mail is borken at the moment. I haven't gotten any of the stuff I signed up for either, which might indicate the latter, but I can clearly and honestly state they are not successfully doing confirmation emails at the moment.
Slashdot Mirror
This isn't a scaled up Estes rocket; analyzing it
as one is a mistake.
As other replies have pointed out, "real" rocket
launch vehicles are aerodynamically unstable
or only stable over limited ranges of flight.
Even if this sized rocket could have been made
aerodynamically stable, they are building towards
larger vehicles and in particular, vertical
takeoff vertical landing which absolutely requires
full 3 axis stabilization and control authority.
Think the DC-X VTVL experimental test rocket.
Carmack has alluded repeatedly to it being
a dynamics and flight operations precursor to
what he's trying to do.
Their numbers on Solaris are whacko.
To establish my background (and biases),
I've been a UNIX sysadmin for 15 years
primarily on Sun, but including most
other UNIX variants and a little Windows.
I'm currently at a Sun VAR, so I have an
idea about how to price Sun boxes and software.
First of all, it will take about 1 CPU to
meet their Processing Unit definition.
When your basline comparison unit is less
than 1 CPUs worth of effort, comparing using Sun
enterprise class systems is ridiculous.
They're not intended to replace a stack
of 1U servers; they're there for the one
application which needs 99.5% uptime or
better and doesn't split across clusters
of independent systems. The Sun 1U servers
(Intel or SPARC architecture) are $1k each
including OS, not this ridiculous $12.5K
per CPU that they ascribe to software costs.
My opinion: this is a sly slam on Sun made
to look like a boost of Linux.
A number of years ago, SGI loaned a Reality Engine (large, multi-cabinet graphics system) to be demoed at a Case for Mars space conference in Boulder, CO. It rode in a large truck from California to Boulder.
When it arrived, it was discovered that nobody had bothered to strap it in for the trip. The boxes were duly opened. The cabinets were found to be bent over out of vertical by several inches, with all the cards and such inside similarly misaligned, and fairly obvious backplane damage as a result.
I missed most of the post-mortem, but my wife and a friend got to do the inspection and I heard parts of the call to SGI...
A little of both. I am both a MS member (not active in the current technical program, though) and an independent engineer and space mission designer, and your criticisms are fairly well aimed here.
Accurate assessment, but really just points out what the Mars Society is and isn't.
It's a volounteer organization, fundraising focus, and PR organization trying to do some real field and technical work (on a shoestring) to advance the cause of manned Mars missions. It's not a professional engineering or space mission operations team. The lack of experience shows a lot. The lack of trained personel shows a lot. The lack of ability to select workers for the absolute best in their field shows a lot... a lot of people forget how selective NASA has been able to be in the past. Volounteer organizations have to make do with whoever shows up.
The plus side... they can deploy a base on a remote island in the Canadian arctic and operate it for a summer for about what it takes to keep two of the fifty seats in Mission Control in Houston staffed 24x7 year round, or deploy one to Utah for about the same amount. Useful things to do.
Fair assessment of the first pass suits.
There have been some pretty lively flame wars
over the suits on Usenet and other discussion areas. You're not alone in pointing out the problems with the alpha version suits. The suits basically were mostly impaired by ongoing lack of time and budget to engineer them. They were a rush job done by three harried volounteers in Boulder with almost no budget.
That said, they did discover some useful things about mobility and operations with them. Some of those discoveries were rediscoveries of things that NASA learned already, but there wasn't time to avoid. Some of them were new. One thing NASA really didn't record well was the planning and support cycle for planetary EVA operations; one of the things the Mars Society *has* done well was to videotape and study all of that. Right now, there's only one group with any current, active experience planning and supporting planetary EVA operations, and it's not NASA. The operational lessons are being properly recorded by real psychologists and operations engineers and should be retained by the aerospace community this time around, we all hope.
It's important to note finally on this topic that
the suits are an alpha test version. The two stations are going to be operated on an ongoing basis, and it's intended that the fidelity of the simulation increase over time: better suits, better gear, more realistic remote support, etc. There are some lessons that these early suits won't learn, but there are many that they can. As long as we eventually get to all of them, it's a reasonable program.
If these were people hanging around on vacation, that might be a fair criticism. But it takes an enormous amount of volounteer labor to make these things happen: tens of thousands of volounteer hours a year have gone into the Arctic and now Desert stations, for several years now. People aren't goofing off or lying around being lazy, they're doing the real work that building these things and operating them takes.
There are lots of things wrong with the Mars Society at one level or another, but it's not a summer camp. This was demonstrated when the parachute failed to open at Devon Island (for which I am eternally embarrassed... I believe I was the first person to suggest to Bob that they use paradrops for the equipment, though I had nothing to do with the actual operation to do it or build the base). That was demonstrated a couple of days ago when two members survived a plane crash on their way to the Desert station... we nearly lost Devo's guitarist there, damnit.
Get better soon, Frank and Matt!
In those cases, when you're paying for a Mainframe, you're getting a mainframe. Also, fairly, with the IBM systems running native OSes, big SGI and HP boxes, etc.
What Sun is pointing out is that the behaviour of the Linux-in-VM systems from IBM appears to be inferior of that of an equivalent cluster of standalone Linux servers, which costs immensely less than the S/390 box and is easier to maintain.
At the time I write this, there are three testimonials from people who say they evaluated or ran these IBM Linux on Mainframe/VM systems posted in the overall commentary, and all of them are relatively negative. I have no personal experience with that, but going by both the theoretical issues and the posted testimonials, I have to lean towards Sun being right on this one.
As a disclaimer, I'm a heavily Solaris/SPARC oriented user and admin, and have specified and built multi-E10K sites. I appreciate Beowulf clusters and similar large Linux/FreeBSD/etc clusters but haven't built one yet.
Um, no, not really. First of all, high grade peroxide costs $0.50/lb for 70% grade in tankcar load quantities or larger, and $10/lb or so for 97% grade commercially concentrated (you can distill 90%+ yourself from 70%, but it requires significant processing equipment and has non-zero risk associated). LOX is cheaper than beer ($0.10/lb or less in large bulk quantities).
Second of all, handling liquid oxygen and nitrogen grade cryogenics is pretty easy. LOX is used in nearly all hospitals for their oxygen feeds; there's usually a LOX tank out in the parking lot somewhere. You have to avoid using organic materials in the piping, but it's handled by relatively low-trained truckers distributing it, in tanker truckload quantities, moved around cities with little hassle or hazmat risk, every day. It has risks, and must be properly respected, but is not a problem.
High-test peroxide is also subject to self-deomposition and detonation in extreme cases.
We have lively regular debates about the merits of various propellants in online forums like
sci.space.policy
and
sci.space.tech.
Talk to professional rocket engineers and nobody is even vaguely afraid of LOX. It's not everybody's first choice, but it's not a bad one.
Peroxide isn't the worst choice by far (FLOX, Liquid Fluorine, Nitrogen Tetroxide, Liquid Ozone, Chlorine PentaFluoride all are far farworse). But LOX is a really good choice.
There used to be an (imfamous) backup method called the UUCP Loop backup. You emailed your files (uuencoded crypted tarfile of the stuff) to host1!host2!host3!host4!host5!host6!host7!host8!y
You had to chose a path that took acceptably long, of course, to ensure there being 1-2 in flight at any time.
See the RAD750 CPU and embedded computer family at:
BAE Systems.
It's true that you probably don't want to use off the shelf CPUs in deep space (though many of them will do acceptably well; the typical deep space radiation environment is not so bad, if you don't fly during high solar flare times and can put up with a few resets from time to time). But there are plenty of space-rated components for those who know where to look and have the $$$. It's not bleeding edge, but it's not that far back either.
You appear to have missed the option of boosting out of Earth orbit, coasting the distance there and braking to stop when you get there, but spinning your spacecraft (usually tethered to a counterweight, in most scenarios) en route to create centrifugal force pseudo-gravity. This is in fact one of the key features of the Mars Direct mission architecture, and is at least seriously considered for all of the other manned Mars mission architectures in the last decade or so.
This project is a Big Deal. Whether mammals can survive for indefinite periods (or long but finite periods) at Mars gravity makes a huge difference in if or how we approach going to Mars. It's a question that is fundamental to long term planning of Mars missions, and due to delays in the Space Station's centrifuge NASA wasn't even going to be able to start looking at it until 2009, we think.
I think you're confusing "freely redistributable" with "free of charge".
Open Software's objective is to make computer related intellectual property common property as much as possible. That is a good thing. It's not a stated objective to have people always starving, or even going unrewarded for their work.
Some of the forms of those rewards are public accolades, some of them the companies that (still) make money doing Open Source software hiring people, but there's nothing wrong with donations to programmers in general. Some might not want it, but that doesn't mean none of them do.
They're claiming what is the equivalent of a compilation copyright. They aren't copyrighting the individual reports; they're copyrighting the whole database etc.
The need to charge for it is presumably related to the need to pay for the tens of people, computers, major network bandwidth used to provide that "free" info to you... RBL stopped being run by volounteers years ago, it didn't scale. If you don't like it, form your own free RBL-like list and solicit nominations, etc... but you will run out of money and life in a few years, like they have.
You're going riiight past it. *launch* weights don't matter a bit for landing. What you're trying to land is the empty weight (plus any returned-to-the-earth payload).
The tradeoff is wings (empty weight) versus fuel (and slightly larger tanks) to land with. You need fuel for say... slowing from 50 meters per second (free fall speed of your empty rocket) to 0 and hover for a bit, from an altitude of 500 meters or so for engine ignition. That works out to about 20 seconds of thrust, at an average of something like 1.25 Gs, or 250 meters per second of velocity change. About 6-10% of the landed mass in fuel, perhaps.
If you don't think wings weigh 6-10% of the landed mass of an aircraft or glider or glide-landing spacecraft, you need to research more. They're typically 9-15% of the weight, including the control surfaces and such.
This is exactly backwards. Bomb design is, though not exactly kindergarden stuff, actually fairly simple and easy if you know where to look to find the right info to work with. It's manufacturing the special materials in quantity which is hard and expensive.
Around 1970, the Department of Energy (and specificaly Edward Teller) did a threat analysis program called variously The Third-Country Experiment or The n-th Country Experiment. They took three brand new physics PhDs with no specific course work or training in nuclear physics and told them to design a bomb using only open source materials. This they did, designing a compact (1-ton), reliable (was analyzed by professionals and determined to have essentially full reliability / functionality, though one was not manufactured to test) weaponized plutonium implosion device, in 18 months time. So there's been a demonstration that it can take as little as less than 5 man-years effort.
See: The Nuclear Weapons FAQ by Carey Sublette and the newsgroup alt.war.nuclear
Very simple answer:
Why are you carrying wings all the way to orbit and back which are only useful on landing? Wings are heavy, and expensive to engineer, build, and protect from re-entry heat.
Professionals argue back and forth about the relative advantages of powered versus aero-glide landing all the time. It's very clear that at best, it's very close between the two options. Extra fuel requires just slighly larger tanks and restartable rocket motors, which isn't all that hard. The numbers can work out either way.
For more info, and to re-start the perpetual flamewar, Usenet's sci.space.policy is a good place to look (or sci.space.tech, but I moderate it, and hesitate to push outside conversations into the moderated group...).
Fuel efficiency for rocket motors is measured by a quantity called Specific Impulse, or Isp. This is roughly described as the length of time you will get one pound of thrust for, if burning one pound of fuel. Typical values for professional engines are 250-330 seconds, for hydrogen/oxygen engines 400-450 seconds. Model rockets are 80-180 seconds depending on the fuel.
You only need a little bit more thrust than weight to take off and hover. Space launch rockets typically launch with thrust of 1.2 to 1.3 times their weight. For low altitude demonstrators, if you have half your takeoff weight in fuel (low for a space launcher, typical for a cheap demo) then you should be able to hover for 3-5 minutes or do low altitude flights and then land with not much less endurance.
You missed the Imperium Games edition and Far Future Enterprises (aka Marc Miller Rides Again) edition currently going nowhere.
T, MT, and TNE were all Game Designers Workshop products. GDW went down some years ago, when the collecting card games industry took off, roughly. Oweing a bunch of us for contributions, too, though not nearly as badly as IG screwed people.
My impression, based on Steve's report on his website, is that there's gotta be financial chicanery going on with his ex-CFO. Steady fundamentals but a lack of closed accounting periods equals something rotten in Denmark. This would be unlike what took GDW down (fundamentals faded as industry changed) or IG (never had 'em to start with...).
>>The difficulty of guidance and control is overrated.
...but should not be underestimated, either.
While I agree you're doing this right to make
it work (for your application), you did show
us quite a number of stability failures in
the video slideshow...
No, it's not.
RTG Plutonium is Pu-238, with a much shorter 89 year halflife (Pu-239's is 24,000 years). Pu-238 is generally considered not fissile. Other isotopes used have included Ce-144, Cm-242, Sr-90, Po-210; Pu-238 has the longest lifetime of those and that led to its being the standard for all RTGs flown by the US since 1964, though some other experimental units with other isotopes were tested in the 60s and 70s.
Heat output is roughly inversely porportional to halflife (how much of it decays in a given time period?).
Um...you probably didn't get any mail from them because they hadn't yet been taken off the RBL.
The test account was in no way RBL protected. Come on, man, that's obvious.
When this all started, I hopped over to YesMail's site looking for info on what their actual business practices were. It stated they were a confirmation-requireing opt in only service. So I created a new test account and signed it up for some stuff I might be interested in. Filled out the web form. Got a response saying they would email me a confirmation. Nada, so far. Either they aren't actually requiring confirmations or their outbound mail is borken at the moment. I haven't gotten any of the stuff I signed up for either, which might indicate the latter, but I can clearly and honestly state they are not successfully doing confirmation emails at the moment.