How many of those fire extinguisher deaths are caused by *untrained* operators? I would guess all of them. You don't have untrained operators working in an ICU or at a rocket test site. The more critical the rocket test, and the more chaotic the environment, the more important checklists become. I'm sure the same is true in an ICU. The idea that checklists slow down complex operations is, quite simply, wrong. They usually have a negligible impact on speed, and can often speed things up. Frequently the order on the checklist was chosen for efficiency -- doing things out of order works, and is equally intuitive, but slower. You spend less time thinking about what to do next. You never stop to wonder whether you remembered to do a step, and then wasting time going back to check a setting.
I would *not* advocate making such things legally mandatory -- there's simply too much inertia to laws, and they're likely to be either so vague they're useless or so detailed they interfere. However, having the people involved write and use checklists for the things they're doing becomes very important as the complexity rises.
Part of the benefit of checklists is that you can pause things. If patient 37 needs a bunch of things done, but none of them have to get done *right* *now*, and then patient 14 develops an emergency, you can put down the checklist and rush to the other patient. After the emergency, you return -- and you're far less likely to forget a step or repeat a step, since the nurse was checking them off while the doctor did them. You can't be a slave to a checklist any more than you can assume any other tool is always appropriate. Part of the job of the skilled operator is to know when to ignore the checklist. Decisions to ignore the checklist should *always* be conscious decisions, not forgetfullness.
When well implemented, checklists run very smoothly. If the list itself and the procedure for using it are well understood and familiar, the time cost is minimal and often negative -- you'll never have to stop and think for long about what needs to be done next, because as soon as you start to the person with the list will start reading the next step. More importantly, missed checklist steps result in substantial time losses in the future -- the reduced infection rates mentioned in the article don't just save lives, they reduce the amount of time spent dealing with infections.
Good use of checklists is not something where the benefits marginally outweigh the costs. The benefits, in a medical context or elsewhere (my personal experience is with rocket engine testing), can *massively* outweigh the costs -- and frequently there simply aren't any costs you could reasonably chalk up to the use of the checklist aside form the time spent writing it in the first place (which is recouped very, very quickly).
In my experience with rocket engine tests, both professionally and as a hobby, I've seen checklists be invaluable tools. I've seen them catch problems that were irrelevant, ones that would have resulted in loss of data, ones that would have resulted in incorrect operation, and ones that had direct safety impacts. However, the problem you describe is very, very common. The simplest solution is quite effective, and they discuss it in the article (but fail to mention how amazingly important it is). You need the person who is responsible for reading the list and making sure each item happens to *not* be the one doing it.
In the article, the nurses follow the checklist and stop the doctors if a step gets missed. At an XCOR Aerospace rocket test, at any given time there is someone whose sole responsibility is reading the checklist (who that is may change through the day, but there always is such a person, and who it is is always clearly defined). In both cases, the person with the checklist has the authority to stop whatever is happening and correct the situation. When I test my hobby rocket motors, the test crew is much more limited (usually two or three people, compared to at least six and often many more at XCOR). As a result, the person reading the checklist is usually also doing things on it. Mistakes are more common, and it's not uncommon to set down the checklist and just do things for a while.
That separation of roles is simple, yet highly effective. Obviously it's a bit hard in a single-pilot airplane. But, in a situation where it's at all possible, it's well worth doing. There are a number of reasons it helps, but one of the simplest is important: the reader can hold the checklist binder with their thumb pointing at the last step completed, since they don't have to use that hand to actually do anything. In the medical case, you're actually making checks on a piece of paper that goes into the file, but the idea is the same.
As an aside, having the checklist be unfamiliar is a bad thing -- mistakes and confusion are much more common after a checklist change. The fix lies in how you use the checklist, not what it says. The reaction to hearing the next step on the list read needs to be "yep, I've already got the tools in my hand" or "oh, right, nearly forgot that" -- not "wait, what was that? Oh, right I was already doing that." If you do that, people will be more inclined to ignore the checklists, because they interfere with operations.
What basis do you have for saying that legalizing drugs like meth would cause more problems? I'm happy to accept that those drugs are bad, and it would be nice if no one used them. But, arguing that they should therefore be banned requires that the ban be effective. Every piece of data I know of says the effectiveness of such bans is minimal at best. Legalization clearly causes some harm reduction, even in the case of dangerous drugs: less organized crime associated with them, cleaner and more consistent product, less disease transmission from dirty needles, etc. So, on what basis do you believe that prohibition causes less harm than no prohibition?
(As I said in another post, I tend to agree with you -- legalize marijuana and the psychedelics, but not stimulants and opiates. However, I'm not at all sure that belief is correct, and I'd like to see more data on the subject.)
[...] cocaine, LSD, or heroin, because of the strength of the addiction of those drugs [...] than less-or-non-addictive drugs (like pot, alcohol, cigarettes, etc).
Your categories are rather flawed there. Nicotine is far more addictive than LSD, marijuana, or alcohol, and arguably more so than cocaine and heroin. LSD is less addictive than any of the others (well, basically tied with marijuana). Alcohol is not particularly addictive in modest quantity, but if consumed in large quantities is quite strongly addictive -- in fact, it's the only drug on your lists where the withdrawl can kill you.
The current legal status of various substances has little or nothing to do with how harmful or addicting they are.
Do you have a basis for either of those statements? There is plenty of literature to support the idea that different psychedelics have different effects. Furthermore, I know of no reason to believe LSD itself is bad (contaminants, maybe, but I think LSD tends to be one of the cleaner street drugs). Contaminants would be less of an issue with legal, regulated drugs. The same things that make LSD and shrooms similar (though not the same) in effects make them similar in terms of dangers (ie nearly nonexistant with both).
I say legalize both of them. Along with marijuana. And also most of the other psychedelics -- 2CB, DMT, 5Meo-DMT, and most of their relatives. I'm undecided on the amphetamine-based ones. For the non-psychedelics, like stimulants and opiates, I'm undecided but lean towards not yet -- legalizing things with substantial overdose potential is not an idea I like, though I'd be willing to convinced by data that said the risks were lower with legalization than without.
Why? You won't find any child porn there. The article isn't all that detailed or informative (it would be better with more data), but you won't find anything illegal or offensive there.
You're right, the author is completely delusional about development costs, ground support, and a number of other things. I was speaking more to the general design problem, since the original article is so far off base as to not be worth much discussion.
Lox being heavy is a good thing. In general, tank mass is related to mass stored and pressure * volume. For pump-fed rockets the structural constraints are substantial enough that it taking less space (denser) doesn't help the tank mass that much, but it does make it smaller and reduce drag. More density Isp is always helpful. Also, LOX isn't particularly reactive. It will readily support combustion, but it won't corrode or oxidize or otherwise interact with most tank materials. You do need to build with safety in mind and not mix LOX and organic materials, but it won't react with your tanks like N2O4, nitric acid, peroxide, and some of the exotic oxidizers can. It's really quite tame in many respects. As for loading, companies like XCOR (who I've worked for) and Armadillo have demonstrated very rapid propellant loading of modestly sized vehicles.
Using cryo propellants probably requires no more ground support than the tanker truck you're filling from and a hose to connect it (LOX tankers are normally operated at modest positive pressure, so if you're willing to wait a little you can even avoid a pump; if you're not, order a tanker that comes with a transfer pump).
There's not enough publicly known about the Scaled accident to make informed comments in any detail. However, I doubt the specific tank technology had anything at all to do with it. I expect the problem was caused by plumbing errors (trapped volume warming up, for example), contamination (nitrous + oil can make detonable mixes), or something else similar. From a safety and operations standpoint, my personal opinion is that N2O is easier for small systems (eg, the hybrids I build and the Lynx RCS thrusters XCOR is building), and LOX for large systems. LOX is also noticeably higher performance.
Exact performance changes with altitude depend somewhat on gas properties. The easiest way to get good numbers is with a numerical solver program like cpropep (web version, be warned it's a bit finnicky to use). At 30kft you're at about 1/4 atm pressure, so you can operate with a nozzle that expands to about 1/4 the pressure of a sea-level capable nozzle. (In general, nozzles are overexpanded at ignition, since the higher altitude performance dominates the optimization. Flow separation at low altitude tends to limit exit pressure to ~ 1/2 ambient, or somewhat lower with work.) Towing to 30kft should be fairly straightforward. 40kft may be a little harder, but is unlikely to present any real challenges. 60-70kft is probably within reason if you have some reason to believe development costs are justified.
(For more perspective on general SSTO capability, it's worth noting that there have been stages built with SSTO performance levels, but never used as such. I believe the S-II second stage of the Saturn V is one such, though I'd have to look up details. A modified configuration of a Shuttle ET plus 6 main engines (3 don't provide enough thrust to get it off the ground) could make orbit with a small but nonzero payload. The reason SSTO hasn't been done (aside from 1.5 STO in Atlas) is not that it's impossible, but that there hasn't been a strong economic case for doing it.)
I'm well aware of the numbers; I've looked at them in some detail. IAA Rocket Engineer, though trajectories and whole-vehicle performance aren't something I've focused on.
If you make grossly optimistic assumptions about mass ratios and engine performance, it's plausible. The problem is that 7kps is a *lot* harder than 2kps. If you don't require wings, then the problem isn't that bad. The original Atlas missile demonstrated the required performance. It had one set of tanks, a central engine optimized for vacuum, and two outer engines for additional liftoff thrust. It dropped the outer engines, but didn't drop any tankage, and could just barely make orbit with a small payload. Performance requirements for an air-launched vehicle are somewhat easier, but only somewhat. It's the wings and landing gear and such that are the problem -- those things are heavy.
Air resistance normally eats about 1.5 kps of delta-v. More for small launchers, less for big ones. More for LH2 fuelled vehicles, less for dense propellants. Even once you get rid of most of the air, add some altitude, and add a couple hundred m/s of velocity, it's still a hard problem. That exponential in the rocket equation is obnoxious.
Note that I am not at all claiming it's impossible. I'm merely saying that given only modest improvements over the current state of the art (ie, amounts of R&D it's reasonable to assume for such a project), it can't be done with an economically interesting payload. Given a much longer time scale and improvements to the state of the art, it might be more interesting. Time will tell...
I agree with almost everything you say, with a couple minor exceptions. Mild cryogens like LOX and methane aren't at all hard to deal with, even in lightweight structures. Highly reusable carbon fiber tanks are still not readily available, but they appear to be within range of a reasonable R&D effort. Lightweight aluminum or fiberglass tanks are readily available. Hard cryos (LH2) are an entirely different story, because the insulation is difficult.
320 seconds vacuum Isp isn't a big deal for a closed-cycle pumped LOX/hydrocarbon engine, especially with a vacuum optimized nozzle (which a craft designed to launch at high altitude from a carrier plane would use). Of course, that *is* a substantial R&D effort, especially if you insist that your pumps be turbopumps. It's just not an unreasonable goal for LOX/kerosene, and LOX/methane will do substantially better (340s+) at some cost in density (methane is 420 kg/m^3 vs 850-1000 for denser fuels). For comparison, the SpaceX Merlin engine gets 304s vacuum Isp on an open-cycle pumped engine capable of atmospheric operation (LOX and RP-1 kerosene).
That said, single stage or single stage plus tow plane to orbit on a winged vehicle is not reasonable for the forseeable future if you insist on economically interesting payload sizes.
You want to look at Bigelow Aerospace. By the time companies like XCOR and Virgin are offering orbital rides, Bigelow is quite likely to have an orbiting hotel for your destination. Note that Bigelow has a launch listed on the SpaceX manifest. They're quite serious, and well funded. They don't always get as much press, because they don't make hot flamey stuff, but they're just as important.
Sharing reproductions is not necessarily copyright infringement. Copyright infringement is usually not a criminal matter. Using correct and precise terminology is important to having an informed debate, as opposed to losing without the debate happening by letting your opponents set the terms.
Why is it that geeks have no trouble using the precise, correct terms when writing code, but so commonly fail to transfer that precision to other areas where it is equally important?
Just remember - prioritizing is one thing, but it's a slippery slope to peer exclusion.
Not really. Prioritize who you request data from, but not who you send it to. If all incoming requests are treated equally, but you only request from the optimal peers, you get all the benefits without any of the omgcensorship fud.
They develop an intuition for quantum mechanics, but that intuition is not based on analogy to previously known things. Developing that intuition is hard, though obviously not impossible. Dijkstra isn't saying you can't understand radical novelties; he's saying that attempting to shoehorn them into bad analogies doesn't help that understanding. I'd say that's rather obviously the case with quantum mechanics.
You use 2-3 ion engines, so that the net thrust is along the axis between the two bodies, but none of the engines are aimed directly at the asteroid. The loss in efficiency is minimal, even if you're fairly close to the asteroid. For example, aiming 5 degrees off axis results in less than 0.5% efficiency penalty.
For starters, it's worth worrying about asteroids that would merely destroy a city rather than end life as we know it. And, if you spot them early, there are a number of techniques that could deflect them. With plenty of time to work, small changes in velocity can cause large changes in position years in the future -- turning an impact into a near miss. This is especially true if there is a close approach to another body before the impact, as small changes in position at the approach turn into larger changes in velocity.
If you only need a tiny course correction, there are plenty of options. A gravitational tug, for example (put a spacecraft near the asteroid, use ion engines to maintain position, and let gravitational forces pull the asteroid toward the ship, and vice versa). That lets you use an ion engine to nudge the asteroid without solving the problems of landing on it or grabbing it. If you can get away with even less total impulse, you can simply paint a large portion of it white and let light pressure from the Sun do the work for you.
Things like large rocket engines and nuclear blasts are crude, blunt instruments; if you have warning, a more subtle approach is appropriate.
Modern SRAMs usually use fewer transistors than that. 6T SRAMs are common, for example. They use a pair of inverters to store the state (4 transistors) and a pair of transistors to connect the inverters to the data lines (6 total). The write operation then involves a drive signal with more power than the inverters, thus forcing the state change.
I think you could build one from components if you had data about the memristance function. Start with a voltage controlled resistance element (Gxxx) connected to the two exposed terminals. Add a hidden element of a current controlled current source, sensing on the VCR element, injecting current into a hidden capacitor. The voltage on that capacitor is proportional to the total charge that has passed through the memristor device. The exposed VCR element senses voltage on the hidden capacitor, and uses an interpolated table of resistance vs voltage rather than a linear relationship.
That doesn't capture the hysteretic behavior of the current devices, which stop integrating at the some limiting points, but it's a starting point. You could add such behavior with a few more hidden components (back-to-back ideal zeners across the hidden cap, for example), though getting the right behavior might be a little tricky.
Rockets don't push off from the air at all. The exhaust of a rocket is locally supersonic (and therefore *much* faster than the speed of sound in air), so any back pressure has no impact on thrust. For a rocket operating in air, therefore, there is air pressure on the front of the rocket that isn't balanced on the back, and the imbalance is exactly equal to the nozzle exit area. (Thrust and drag are normally considered independently.)
The performance of a rocket is usually measured as specific impulse (Isp), or how much impulse is generated per unit of propellant burned. In English units, it's usually given as lb*s impulse per lb propellant, and cancelled to seconds (alternately, lb of thrust per lb/s of propellant consumption). This hides a unit of g (cancelling pounds force with pounds mass, which differ by g). Merlin gets a vacuum Isp of 304s. Converting to metric units, that's 2982 m/s (or 2982 N * s / kg), which is the average axial speed of the exhaust. That exhaust speed is independent of atmospheric pressure or lack thereof. However, in an atmosphere, the thrust is reduced by ambient pressure * nozzle exit area, resulting in a reduction in Isp and *effective* exhaust velocity to 275s or 2700 m/s.
(In an attempt to clean up the units, most US rocket engineers and engineering texts now distinguish pounds force and pounds mass, as lbf and lbm respectively. Isp in seconds has hung on, though, even though it's a bastardized mix of units.)
Working backward from those numbers, the difference in thrust from vacuum to atmospheric pressure of 13400 lbf inplies a nozzle exit area of 13400 lbf / 14.7 psi (atmospheric pressure) = 911 in^2, for a nozzle exit diameter of 34 inches, which sounds about right (I don't see actual dimensions listed anywhere).
Hopefully that makes it a little clearer. The key to understanding rocket nozzles is that supersonic flows behave almost nothing like subsonic flows. That's why they have that convergent-divergent shape; they're a de Laval nozzle.
The data sheet says max axial load at MECO is 5g, and at SECO 3-5g depending on mission. They specify a design load factor of 6g.
If you want the slopes of the curves, you can work out estimates from published data. Takeoff mass is 333,400kg. Vacuum thrust is 5.56MN; multiplying by the Isp ratio, that suggests a liftoff thrust of 5.03MN, or about 1.5g at liftoff (seems I misremembered).
Liftoff Isp of 275s equates to 2700m/s, so to produce 5.03MN thrust it burns 1860 kg/s of propellant. That'll give you the start of the curve and total propellant mass; the Isp and thrust increase with altitude (rockets perform better in a vacuum), so the middle portion of the curve is a little hard to pin down without better data about the flight path.
Apparently it's pretty easy to snoop on a random person's phone records over there. How many employees have snooped on someone less noteworthy -- a friend, a possibly cheating spouse, etc.? Are there policies in place to catch more mundane privacy invasions and fire those people as well, or does it only matter if the person in question is politically relevant?
Slashdot Mirror
How many of those fire extinguisher deaths are caused by *untrained* operators? I would guess all of them. You don't have untrained operators working in an ICU or at a rocket test site. The more critical the rocket test, and the more chaotic the environment, the more important checklists become. I'm sure the same is true in an ICU. The idea that checklists slow down complex operations is, quite simply, wrong. They usually have a negligible impact on speed, and can often speed things up. Frequently the order on the checklist was chosen for efficiency -- doing things out of order works, and is equally intuitive, but slower. You spend less time thinking about what to do next. You never stop to wonder whether you remembered to do a step, and then wasting time going back to check a setting.
I would *not* advocate making such things legally mandatory -- there's simply too much inertia to laws, and they're likely to be either so vague they're useless or so detailed they interfere. However, having the people involved write and use checklists for the things they're doing becomes very important as the complexity rises.
Part of the benefit of checklists is that you can pause things. If patient 37 needs a bunch of things done, but none of them have to get done *right* *now*, and then patient 14 develops an emergency, you can put down the checklist and rush to the other patient. After the emergency, you return -- and you're far less likely to forget a step or repeat a step, since the nurse was checking them off while the doctor did them. You can't be a slave to a checklist any more than you can assume any other tool is always appropriate. Part of the job of the skilled operator is to know when to ignore the checklist. Decisions to ignore the checklist should *always* be conscious decisions, not forgetfullness.
When well implemented, checklists run very smoothly. If the list itself and the procedure for using it are well understood and familiar, the time cost is minimal and often negative -- you'll never have to stop and think for long about what needs to be done next, because as soon as you start to the person with the list will start reading the next step. More importantly, missed checklist steps result in substantial time losses in the future -- the reduced infection rates mentioned in the article don't just save lives, they reduce the amount of time spent dealing with infections.
Good use of checklists is not something where the benefits marginally outweigh the costs. The benefits, in a medical context or elsewhere (my personal experience is with rocket engine testing), can *massively* outweigh the costs -- and frequently there simply aren't any costs you could reasonably chalk up to the use of the checklist aside form the time spent writing it in the first place (which is recouped very, very quickly).
In my experience with rocket engine tests, both professionally and as a hobby, I've seen checklists be invaluable tools. I've seen them catch problems that were irrelevant, ones that would have resulted in loss of data, ones that would have resulted in incorrect operation, and ones that had direct safety impacts. However, the problem you describe is very, very common. The simplest solution is quite effective, and they discuss it in the article (but fail to mention how amazingly important it is). You need the person who is responsible for reading the list and making sure each item happens to *not* be the one doing it.
In the article, the nurses follow the checklist and stop the doctors if a step gets missed. At an XCOR Aerospace rocket test, at any given time there is someone whose sole responsibility is reading the checklist (who that is may change through the day, but there always is such a person, and who it is is always clearly defined). In both cases, the person with the checklist has the authority to stop whatever is happening and correct the situation. When I test my hobby rocket motors, the test crew is much more limited (usually two or three people, compared to at least six and often many more at XCOR). As a result, the person reading the checklist is usually also doing things on it. Mistakes are more common, and it's not uncommon to set down the checklist and just do things for a while.
That separation of roles is simple, yet highly effective. Obviously it's a bit hard in a single-pilot airplane. But, in a situation where it's at all possible, it's well worth doing. There are a number of reasons it helps, but one of the simplest is important: the reader can hold the checklist binder with their thumb pointing at the last step completed, since they don't have to use that hand to actually do anything. In the medical case, you're actually making checks on a piece of paper that goes into the file, but the idea is the same.
As an aside, having the checklist be unfamiliar is a bad thing -- mistakes and confusion are much more common after a checklist change. The fix lies in how you use the checklist, not what it says. The reaction to hearing the next step on the list read needs to be "yep, I've already got the tools in my hand" or "oh, right, nearly forgot that" -- not "wait, what was that? Oh, right I was already doing that." If you do that, people will be more inclined to ignore the checklists, because they interfere with operations.
What basis do you have for saying that legalizing drugs like meth would cause more problems? I'm happy to accept that those drugs are bad, and it would be nice if no one used them. But, arguing that they should therefore be banned requires that the ban be effective. Every piece of data I know of says the effectiveness of such bans is minimal at best. Legalization clearly causes some harm reduction, even in the case of dangerous drugs: less organized crime associated with them, cleaner and more consistent product, less disease transmission from dirty needles, etc. So, on what basis do you believe that prohibition causes less harm than no prohibition?
(As I said in another post, I tend to agree with you -- legalize marijuana and the psychedelics, but not stimulants and opiates. However, I'm not at all sure that belief is correct, and I'd like to see more data on the subject.)
[...] cocaine, LSD, or heroin, because of the strength of the addiction of those drugs [...] than less-or-non-addictive drugs (like pot, alcohol, cigarettes, etc).
Your categories are rather flawed there. Nicotine is far more addictive than LSD, marijuana, or alcohol, and arguably more so than cocaine and heroin. LSD is less addictive than any of the others (well, basically tied with marijuana). Alcohol is not particularly addictive in modest quantity, but if consumed in large quantities is quite strongly addictive -- in fact, it's the only drug on your lists where the withdrawl can kill you.
The current legal status of various substances has little or nothing to do with how harmful or addicting they are.
Do you have a basis for either of those statements? There is plenty of literature to support the idea that different psychedelics have different effects. Furthermore, I know of no reason to believe LSD itself is bad (contaminants, maybe, but I think LSD tends to be one of the cleaner street drugs). Contaminants would be less of an issue with legal, regulated drugs. The same things that make LSD and shrooms similar (though not the same) in effects make them similar in terms of dangers (ie nearly nonexistant with both).
I say legalize both of them. Along with marijuana. And also most of the other psychedelics -- 2CB, DMT, 5Meo-DMT, and most of their relatives. I'm undecided on the amphetamine-based ones. For the non-psychedelics, like stimulants and opiates, I'm undecided but lean towards not yet -- legalizing things with substantial overdose potential is not an idea I like, though I'd be willing to convinced by data that said the risks were lower with legalization than without.
Why? You won't find any child porn there. The article isn't all that detailed or informative (it would be better with more data), but you won't find anything illegal or offensive there.
You're right, the author is completely delusional about development costs, ground support, and a number of other things. I was speaking more to the general design problem, since the original article is so far off base as to not be worth much discussion.
Lox being heavy is a good thing. In general, tank mass is related to mass stored and pressure * volume. For pump-fed rockets the structural constraints are substantial enough that it taking less space (denser) doesn't help the tank mass that much, but it does make it smaller and reduce drag. More density Isp is always helpful. Also, LOX isn't particularly reactive. It will readily support combustion, but it won't corrode or oxidize or otherwise interact with most tank materials. You do need to build with safety in mind and not mix LOX and organic materials, but it won't react with your tanks like N2O4, nitric acid, peroxide, and some of the exotic oxidizers can. It's really quite tame in many respects. As for loading, companies like XCOR (who I've worked for) and Armadillo have demonstrated very rapid propellant loading of modestly sized vehicles.
Using cryo propellants probably requires no more ground support than the tanker truck you're filling from and a hose to connect it (LOX tankers are normally operated at modest positive pressure, so if you're willing to wait a little you can even avoid a pump; if you're not, order a tanker that comes with a transfer pump).
There's not enough publicly known about the Scaled accident to make informed comments in any detail. However, I doubt the specific tank technology had anything at all to do with it. I expect the problem was caused by plumbing errors (trapped volume warming up, for example), contamination (nitrous + oil can make detonable mixes), or something else similar. From a safety and operations standpoint, my personal opinion is that N2O is easier for small systems (eg, the hybrids I build and the Lynx RCS thrusters XCOR is building), and LOX for large systems. LOX is also noticeably higher performance.
Exact performance changes with altitude depend somewhat on gas properties. The easiest way to get good numbers is with a numerical solver program like cpropep (web version, be warned it's a bit finnicky to use). At 30kft you're at about 1/4 atm pressure, so you can operate with a nozzle that expands to about 1/4 the pressure of a sea-level capable nozzle. (In general, nozzles are overexpanded at ignition, since the higher altitude performance dominates the optimization. Flow separation at low altitude tends to limit exit pressure to ~ 1/2 ambient, or somewhat lower with work.) Towing to 30kft should be fairly straightforward. 40kft may be a little harder, but is unlikely to present any real challenges. 60-70kft is probably within reason if you have some reason to believe development costs are justified.
(For more perspective on general SSTO capability, it's worth noting that there have been stages built with SSTO performance levels, but never used as such. I believe the S-II second stage of the Saturn V is one such, though I'd have to look up details. A modified configuration of a Shuttle ET plus 6 main engines (3 don't provide enough thrust to get it off the ground) could make orbit with a small but nonzero payload. The reason SSTO hasn't been done (aside from 1.5 STO in Atlas) is not that it's impossible, but that there hasn't been a strong economic case for doing it.)
I'm well aware of the numbers; I've looked at them in some detail. IAA Rocket Engineer, though trajectories and whole-vehicle performance aren't something I've focused on.
If you make grossly optimistic assumptions about mass ratios and engine performance, it's plausible. The problem is that 7kps is a *lot* harder than 2kps. If you don't require wings, then the problem isn't that bad. The original Atlas missile demonstrated the required performance. It had one set of tanks, a central engine optimized for vacuum, and two outer engines for additional liftoff thrust. It dropped the outer engines, but didn't drop any tankage, and could just barely make orbit with a small payload. Performance requirements for an air-launched vehicle are somewhat easier, but only somewhat. It's the wings and landing gear and such that are the problem -- those things are heavy.
Air resistance normally eats about 1.5 kps of delta-v. More for small launchers, less for big ones. More for LH2 fuelled vehicles, less for dense propellants. Even once you get rid of most of the air, add some altitude, and add a couple hundred m/s of velocity, it's still a hard problem. That exponential in the rocket equation is obnoxious.
Note that I am not at all claiming it's impossible. I'm merely saying that given only modest improvements over the current state of the art (ie, amounts of R&D it's reasonable to assume for such a project), it can't be done with an economically interesting payload. Given a much longer time scale and improvements to the state of the art, it might be more interesting. Time will tell...
I agree with almost everything you say, with a couple minor exceptions. Mild cryogens like LOX and methane aren't at all hard to deal with, even in lightweight structures. Highly reusable carbon fiber tanks are still not readily available, but they appear to be within range of a reasonable R&D effort. Lightweight aluminum or fiberglass tanks are readily available. Hard cryos (LH2) are an entirely different story, because the insulation is difficult.
320 seconds vacuum Isp isn't a big deal for a closed-cycle pumped LOX/hydrocarbon engine, especially with a vacuum optimized nozzle (which a craft designed to launch at high altitude from a carrier plane would use). Of course, that *is* a substantial R&D effort, especially if you insist that your pumps be turbopumps. It's just not an unreasonable goal for LOX/kerosene, and LOX/methane will do substantially better (340s+) at some cost in density (methane is 420 kg/m^3 vs 850-1000 for denser fuels). For comparison, the SpaceX Merlin engine gets 304s vacuum Isp on an open-cycle pumped engine capable of atmospheric operation (LOX and RP-1 kerosene).
That said, single stage or single stage plus tow plane to orbit on a winged vehicle is not reasonable for the forseeable future if you insist on economically interesting payload sizes.
You want to look at Bigelow Aerospace. By the time companies like XCOR and Virgin are offering orbital rides, Bigelow is quite likely to have an orbiting hotel for your destination. Note that Bigelow has a launch listed on the SpaceX manifest. They're quite serious, and well funded. They don't always get as much press, because they don't make hot flamey stuff, but they're just as important.
Did you try simply turning off swap usage first?
Sharing reproductions is not necessarily copyright infringement. Copyright infringement is usually not a criminal matter. Using correct and precise terminology is important to having an informed debate, as opposed to losing without the debate happening by letting your opponents set the terms.
Why is it that geeks have no trouble using the precise, correct terms when writing code, but so commonly fail to transfer that precision to other areas where it is equally important?
Just remember - prioritizing is one thing, but it's a slippery slope to peer exclusion.
Not really. Prioritize who you request data from, but not who you send it to. If all incoming requests are treated equally, but you only request from the optimal peers, you get all the benefits without any of the omgcensorship fud.
They develop an intuition for quantum mechanics, but that intuition is not based on analogy to previously known things. Developing that intuition is hard, though obviously not impossible. Dijkstra isn't saying you can't understand radical novelties; he's saying that attempting to shoehorn them into bad analogies doesn't help that understanding. I'd say that's rather obviously the case with quantum mechanics.
Are there freely available diagrams anywhere?
You use 2-3 ion engines, so that the net thrust is along the axis between the two bodies, but none of the engines are aimed directly at the asteroid. The loss in efficiency is minimal, even if you're fairly close to the asteroid. For example, aiming 5 degrees off axis results in less than 0.5% efficiency penalty.
That, I have no idea. I'm hardly a spice wizard or anything. But, have you looked at Gnucap? It's Free and does a lot of what I need it to do.
For starters, it's worth worrying about asteroids that would merely destroy a city rather than end life as we know it. And, if you spot them early, there are a number of techniques that could deflect them. With plenty of time to work, small changes in velocity can cause large changes in position years in the future -- turning an impact into a near miss. This is especially true if there is a close approach to another body before the impact, as small changes in position at the approach turn into larger changes in velocity.
If you only need a tiny course correction, there are plenty of options. A gravitational tug, for example (put a spacecraft near the asteroid, use ion engines to maintain position, and let gravitational forces pull the asteroid toward the ship, and vice versa). That lets you use an ion engine to nudge the asteroid without solving the problems of landing on it or grabbing it. If you can get away with even less total impulse, you can simply paint a large portion of it white and let light pressure from the Sun do the work for you.
Things like large rocket engines and nuclear blasts are crude, blunt instruments; if you have warning, a more subtle approach is appropriate.
Modern SRAMs usually use fewer transistors than that. 6T SRAMs are common, for example. They use a pair of inverters to store the state (4 transistors) and a pair of transistors to connect the inverters to the data lines (6 total). The write operation then involves a drive signal with more power than the inverters, thus forcing the state change.
I think you could build one from components if you had data about the memristance function. Start with a voltage controlled resistance element (Gxxx) connected to the two exposed terminals. Add a hidden element of a current controlled current source, sensing on the VCR element, injecting current into a hidden capacitor. The voltage on that capacitor is proportional to the total charge that has passed through the memristor device. The exposed VCR element senses voltage on the hidden capacitor, and uses an interpolated table of resistance vs voltage rather than a linear relationship.
That doesn't capture the hysteretic behavior of the current devices, which stop integrating at the some limiting points, but it's a starting point. You could add such behavior with a few more hidden components (back-to-back ideal zeners across the hidden cap, for example), though getting the right behavior might be a little tricky.
Rockets don't push off from the air at all. The exhaust of a rocket is locally supersonic (and therefore *much* faster than the speed of sound in air), so any back pressure has no impact on thrust. For a rocket operating in air, therefore, there is air pressure on the front of the rocket that isn't balanced on the back, and the imbalance is exactly equal to the nozzle exit area. (Thrust and drag are normally considered independently.)
The performance of a rocket is usually measured as specific impulse (Isp), or how much impulse is generated per unit of propellant burned. In English units, it's usually given as lb*s impulse per lb propellant, and cancelled to seconds (alternately, lb of thrust per lb/s of propellant consumption). This hides a unit of g (cancelling pounds force with pounds mass, which differ by g). Merlin gets a vacuum Isp of 304s. Converting to metric units, that's 2982 m/s (or 2982 N * s / kg), which is the average axial speed of the exhaust. That exhaust speed is independent of atmospheric pressure or lack thereof. However, in an atmosphere, the thrust is reduced by ambient pressure * nozzle exit area, resulting in a reduction in Isp and *effective* exhaust velocity to 275s or 2700 m/s.
(In an attempt to clean up the units, most US rocket engineers and engineering texts now distinguish pounds force and pounds mass, as lbf and lbm respectively. Isp in seconds has hung on, though, even though it's a bastardized mix of units.)
Working backward from those numbers, the difference in thrust from vacuum to atmospheric pressure of 13400 lbf inplies a nozzle exit area of 13400 lbf / 14.7 psi (atmospheric pressure) = 911 in^2, for a nozzle exit diameter of 34 inches, which sounds about right (I don't see actual dimensions listed anywhere).
Hopefully that makes it a little clearer. The key to understanding rocket nozzles is that supersonic flows behave almost nothing like subsonic flows. That's why they have that convergent-divergent shape; they're a de Laval nozzle.
The data sheet says max axial load at MECO is 5g, and at SECO 3-5g depending on mission. They specify a design load factor of 6g.
If you want the slopes of the curves, you can work out estimates from published data. Takeoff mass is 333,400kg. Vacuum thrust is 5.56MN; multiplying by the Isp ratio, that suggests a liftoff thrust of 5.03MN, or about 1.5g at liftoff (seems I misremembered).
Liftoff Isp of 275s equates to 2700m/s, so to produce 5.03MN thrust it burns 1860 kg/s of propellant. That'll give you the start of the curve and total propellant mass; the Isp and thrust increase with altitude (rockets perform better in a vacuum), so the middle portion of the curve is a little hard to pin down without better data about the flight path.
Uncompressed voice is 8 bit * 8kHz, or 8KB/s (64Kb/s). Compressed, it would be more like 2KB/s, possibly less.
Apparently it's pretty easy to snoop on a random person's phone records over there. How many employees have snooped on someone less noteworthy -- a friend, a possibly cheating spouse, etc.? Are there policies in place to catch more mundane privacy invasions and fire those people as well, or does it only matter if the person in question is politically relevant?