that's just one. there are dozens of NASA 'human rating' standards documents that are expected to be followed, plus (possibly) some standards that are unofficial or just in the heads of certain managers.
SpaceX say they have adhered to every *published* NASA human rating requirement. they keep asking if there's anything else that's not published..
BTW the space shuttle did not follow several of those standards, but was 'waived'.
he says they're leaning towards a 1.7 million lbf engine, but they've also been looking at a 3.5 million lbf engine with a throttle setting for use in smaller rockets (back to 1.7, presumably).
the F-1 engine from the Saturn-V (Apollo), for reference, was only 1.5 million lbf, and still holds the title for 'largest rocket engine'.
that was their evolution plan - build a 'Merlin 2' sized to replace the 9 x Merlin 1s required for Falcon 9, then start building bigger rockets with multiple Merlin 2s.
BUT Elon has talked about building a Merlin 2 engine sized all the way up to 3 million lb/f (about three times bigger than the 'Falcon 9 replacement' size), which might be the route they took if there was suddenly a lot of money available to skip a step (and it would probably be sensible, if there was a tight deadline).
Falcon *XX*, not the current Falcon 9, or the planned Falcon 9-Heavy.
he offered it for $2.5 billion. any excess above that to be paid for by SpaceX, not the government. and the throw weight would be about 150 tons to LEO, so bigger than Ares-V (or the latest NASA plan)
smell like it, at least.. so probably taste like it to.
people on 'undercover missions' (special forces etc) usually eat the local diet for a couple of weeks before being deployed, so they don't smell like 'foreigners'.
doesn't look cheap, or terribly easy. OTOH the technology would be re-usable for on-orbit fuel stores, so there's probably NASA $$ available for development.
this doesn't apply to Linus, but it's only a three year wait before you can apply for citizenship if your green card was allocated due to marriage to a US citizen
it's used quite a lot in some countries outside the US.. Australia is an example I think.
the main reason the US VOIP companies don't use it is that they hate the idea of it. it would short circuit them out of a huge number of their calls (peer-to-peer, direct between office PBXs), and they'd still get the blame for bad sounding calls (with no way of fixing them!)
comcast has two 'VOIP' offerings - one is basically an ISDN line on a different frequency ('Comcast Digital' I think) - it's not VOIP (actually, it's better, because faxes etc will work perfectly). it doesn't share bandwidth with your internet connection etc.
they also do a real 'VOIP' system. it should work perfectly because they control the QOS at both ends of the bandwidth bottleneck (the last couple of miles to your house). they do QOS at the headend to make sure your call gets priority, and also program your cable modem to do QOS outbound to prioritize your outgoing audio. the result is extremely low jitter (and hence, very small jitter buffer sizes).
my bet would be that the call is placed onto a circuit switched network as soon as it reaches the headend.. so there's only a very short run of 'VOIP'.
I guess I should have given a simple recipe for working (business) VOIP:
1) pick a provider who will give you a bundle of (a) VOIP lines, (b) bandwidth, and (c) phones. getting it all in one bundle makes finger pointing between providers impossible, and in theory they should have everything setup (QOS etc) to work properly. an example: speakeasy. there are others...
2) insist on a 60 day trial. don't let them bullshit you with "but we only do 30 day trials". the one person in your office most sensitive to audio problems will be on vacation in a thirty day window...
3) DON'T get rid of your old phone system. just forward the number(s) temporarily to the new system
4) HAMMER it for 60 days. download and upload as much as you can. get as many people on the phones at one time as you can. run some bittorrent clients and download some (legal) stuff - for example Linux install ISOs. bittorrent really stresses QOS. run a bunch of web-conference sessions if you use them. blast your LAN with a high rate of broadcast pings. *insist* that people tell you about audio problems (they still won't..). make them check whether the person they were talking to was on a cellphone or VOIP - if they were, it's hard to place the blame..
latency is a factor of three things in a VOIP call (and partially, a cell phone call):
1) the round trip time to the server. most of the VOIP providers out there resell one of the big providers (Level 3, Global Crossings), so pinging your mom&pop VOIP provider's server doesn't necessarily give you the right value - however, most providers aimed at home use bounce the audio via the own server to work around NAT problems that an office PBX won't have (so pinging *will* give the right answer.. there's always a 'BUT')
2) if a compressed codec is being used, there's a fixed delay introduced by the code/decode steps. it's common for call centers to use the G.729 codec, so that they can fit more calls in the same amount of bandwidth. this also applies to cell phones (GSM codec)
3) jitter buffers. because the internet is a packet switched network, and because QOS is not perfect even with the best equipment, every VOIP device uses a 'jitter buffer' at the point that the audio is de-packetized and played back through a speaker. this adds a fixed (or more typically, variable) delay to the inbound audio, allowing slow (or reordered) packets a chance to 'catch up' before the audio actually needs to be played.
the two major factors are (1) and (3). I suspect (1) is not much different to the delay on a 'normal' phone line in most cases these days (because switches are fast, and the big VOIP providers have POPs in all the exchanges). the major killer is the jitter buffer. typically, it should be below 60ms to get a 'natural' sounding conversation - but if you have a bad connection (by that I mean: you don't have QOS implemented at both ends of the bandwidth bottleneck), the jitterbuffer will have to get larger and larger to compensate. home VOIP providers 'fix' broadband connections with no QOS (all of them) by raising the jitter buffer to high levels (because people are a bit more tolerant of long delays than stuttering, breaking up, calls..)
there's a final possibility.. you may very well have been talking to an Indian call center.. they almost always use VOIP, with G729, and the round trip time is HIGH.
given:
(1) pick a provider who can pass through the audio to your server directly from Level3/GC
(2) don't use a compressed codec - use ULAW
(3) make sure you've got QOS *everywhere* from the server through your internet gateway, and back again (that includes smart switches doing QOS, VLANs etc). this is the tricky one - you need to find an ISP who is willing (and able) to provide QOS on the incoming side to your server too - you can do QOS for outbound traffic yourself, but your ISP *has* to do it for inbound traffic for you...
you'll get low latency, good sounding, calls. screw up on any of the above three and you'll get either (a) pissed off users because "the phones sound terrible again" or (b) high latency, echo, talking over one another - see (a).
relatively low power lasers can apply enough force on a (dead) satellite or other orbital trash to gradually reduce their orbit until they eventually burn up:
the trick is not blinding other satellites in the process.. especially 'secret' ones that you didn't know were there... also, if the satellite is not really 'dead' (just nonresponsive), it may continue to use it's own OMS etc to counter the laser pressure and stay in orbit... at least until it runs out of fuel.
yeah, except they get pulled out when you need to plug something in, and left (or dropped) on the floor. then the kid chokes on them. I ended up using these:
but they're about $5 each, not 50c each each like the little plastic doohickeys.
you can also get the sockets with built-in guards, but then you have to put up with the sighing and tsk-tsking of everyone who visits because they can't see the protection. seems better to me to just have it in every socket, for a few extra pence (or cents) at build time. especially when you eg visit grandparents and have to run round with a handful of plastic widgets to safe someone else's house.
don't forget that 240V is far more dangerous than 110V (especially with UK ring mains - you're exposed to 30+ amps too, instead of the 15-20A in the US). having been shocked with both at various times, 110V is painful but bearable.. 240V makes you feel like your heart's stopped!
as far as the switches, yes, they're built to be used repeatedly (eg: lamps). I haven't been able to find a socket here in the US with built in switches - it would have to be some sort of combined receptacle and faceplate..
there was a UPS.. it didn't last long enough to cover the entire outage. why didn't it shut down a few minutes before the power ran out? because we were using a logging filesystem, and we needed the machine to run as long as possible..
the backup was not as useful as it should have been (incomplete, sigh).
I can't remember a time when ext3 failed to be repaired (sometimes with a little manual help recovering files from lost+found).
I have a *very* clear recollection of reiserfs eating huge chunks of the filesystem as it 'repaired'.
me too.. power outage = partially broken filesystem. reiserfsck = completely broken filesystem. and a day long session of trying to fix things on a critical machine.
end result: we now use ext3 everywhere...
probably a more useful route would be to port http://www.reactos.com/ to run under Xen. You would need to port their implementation of the NT HAL, plus write the device drivers for network/console etc. (obviously this was what the Xen developers already did for XP but can't release).
the idea behind porting ReactOS is that you end up with an NT style HAL.dll and drivers which *could* be substituted into a real XP install?
caveat: I have no idea how complete ReactOS's HAL.dll is... but they have been trying for API compatibility in most stuff...
Slashdot Mirror
that's just one. there are dozens of NASA 'human rating' standards documents that are expected to be followed, plus (possibly) some standards that are unofficial or just in the heads of certain managers.
SpaceX say they have adhered to every *published* NASA human rating requirement. they keep asking if there's anything else that's not published..
BTW the space shuttle did not follow several of those standards, but was 'waived'.
sigh. forgot to log in. parent article was me, if anyone cares.
took a while to find... it was from an interview with Aviation Week:
http://www.aviationweek.com/aw/generic/story_channel.jsp?channel=space&id=news/awst/2010/11/29/AW_11_29_2010_p28-271784.xml&headline=NASA%20Studies%20Scaled-Up%20Falcon,%20Merlin
he says they're leaning towards a 1.7 million lbf engine, but they've also been looking at a 3.5 million lbf engine with a throttle setting for use in smaller rockets (back to 1.7, presumably).
the F-1 engine from the Saturn-V (Apollo), for reference, was only 1.5 million lbf, and still holds the title for 'largest rocket engine'.
that was their evolution plan - build a 'Merlin 2' sized to replace the 9 x Merlin 1s required for Falcon 9, then start building bigger rockets with multiple Merlin 2s.
BUT Elon has talked about building a Merlin 2 engine sized all the way up to 3 million lb/f (about three times bigger than the 'Falcon 9 replacement' size), which might be the route they took if there was suddenly a lot of money available to skip a step (and it would probably be sensible, if there was a tight deadline).
Falcon *XX*, not the current Falcon 9, or the planned Falcon 9-Heavy.
he offered it for $2.5 billion. any excess above that to be paid for by SpaceX, not the government. and the throw weight would be about 150 tons to LEO, so bigger than Ares-V (or the latest NASA plan)
smell like it, at least.. so probably taste like it to.
people on 'undercover missions' (special forces etc) usually eat the local diet for a couple of weeks before being deployed, so they don't smell like 'foreigners'.
ULA have done studies on extending the life of the Centaur upper stage past a few days, for example:
http://unitedlaunchalliance.com/site/docs/publications/CentaurExtensibilityForLongDuration20067270.pdf
doesn't look cheap, or terribly easy. OTOH the technology would be re-usable for on-orbit fuel stores, so there's probably NASA $$ available for development.
this doesn't apply to Linus, but it's only a three year wait before you can apply for citizenship if your green card was allocated due to marriage to a US citizen
it's used quite a lot in some countries outside the US.. Australia is an example I think.
the main reason the US VOIP companies don't use it is that they hate the idea of it. it would short circuit them out of a huge number of their calls (peer-to-peer, direct between office PBXs), and they'd still get the blame for bad sounding calls (with no way of fixing them!)
comcast has two 'VOIP' offerings - one is basically an ISDN line on a different frequency ('Comcast Digital' I think) - it's not VOIP (actually, it's better, because faxes etc will work perfectly). it doesn't share bandwidth with your internet connection etc.
they also do a real 'VOIP' system. it should work perfectly because they control the QOS at both ends of the bandwidth bottleneck (the last couple of miles to your house). they do QOS at the headend to make sure your call gets priority, and also program your cable modem to do QOS outbound to prioritize your outgoing audio. the result is extremely low jitter (and hence, very small jitter buffer sizes).
my bet would be that the call is placed onto a circuit switched network as soon as it reaches the headend.. so there's only a very short run of 'VOIP'.
I guess I should have given a simple recipe for working (business) VOIP:
1) pick a provider who will give you a bundle of (a) VOIP lines, (b) bandwidth, and (c) phones. getting it all in one bundle makes finger pointing between providers impossible, and in theory they should have everything setup (QOS etc) to work properly. an example: speakeasy. there are others...
2) insist on a 60 day trial. don't let them bullshit you with "but we only do 30 day trials". the one person in your office most sensitive to audio problems will be on vacation in a thirty day window...
3) DON'T get rid of your old phone system. just forward the number(s) temporarily to the new system
4) HAMMER it for 60 days. download and upload as much as you can. get as many people on the phones at one time as you can. run some bittorrent clients and download some (legal) stuff - for example Linux install ISOs. bittorrent really stresses QOS. run a bunch of web-conference sessions if you use them. blast your LAN with a high rate of broadcast pings. *insist* that people tell you about audio problems (they still won't..). make them check whether the person they were talking to was on a cellphone or VOIP - if they were, it's hard to place the blame..
5) ??
6) profit
latency is a factor of three things in a VOIP call (and partially, a cell phone call):
1) the round trip time to the server. most of the VOIP providers out there resell one of the big providers (Level 3, Global Crossings), so pinging your mom&pop VOIP provider's server doesn't necessarily give you the right value - however, most providers aimed at home use bounce the audio via the own server to work around NAT problems that an office PBX won't have (so pinging *will* give the right answer.. there's always a 'BUT')
2) if a compressed codec is being used, there's a fixed delay introduced by the code/decode steps. it's common for call centers to use the G.729 codec, so that they can fit more calls in the same amount of bandwidth. this also applies to cell phones (GSM codec)
3) jitter buffers. because the internet is a packet switched network, and because QOS is not perfect even with the best equipment, every VOIP device uses a 'jitter buffer' at the point that the audio is de-packetized and played back through a speaker. this adds a fixed (or more typically, variable) delay to the inbound audio, allowing slow (or reordered) packets a chance to 'catch up' before the audio actually needs to be played.
the two major factors are (1) and (3). I suspect (1) is not much different to the delay on a 'normal' phone line in most cases these days (because switches are fast, and the big VOIP providers have POPs in all the exchanges). the major killer is the jitter buffer. typically, it should be below 60ms to get a 'natural' sounding conversation - but if you have a bad connection (by that I mean: you don't have QOS implemented at both ends of the bandwidth bottleneck), the jitterbuffer will have to get larger and larger to compensate. home VOIP providers 'fix' broadband connections with no QOS (all of them) by raising the jitter buffer to high levels (because people are a bit more tolerant of long delays than stuttering, breaking up, calls..)
there's a final possibility.. you may very well have been talking to an Indian call center.. they almost always use VOIP, with G729, and the round trip time is HIGH.
given:
(1) pick a provider who can pass through the audio to your server directly from Level3/GC
(2) don't use a compressed codec - use ULAW
(3) make sure you've got QOS *everywhere* from the server through your internet gateway, and back again (that includes smart switches doing QOS, VLANs etc). this is the tricky one - you need to find an ISP who is willing (and able) to provide QOS on the incoming side to your server too - you can do QOS for outbound traffic yourself, but your ISP *has* to do it for inbound traffic for you...
you'll get low latency, good sounding, calls. screw up on any of the above three and you'll get either (a) pissed off users because "the phones sound terrible again" or (b) high latency, echo, talking over one another - see (a).
relatively low power lasers can apply enough force on a (dead) satellite or other orbital trash to gradually reduce their orbit until they eventually burn up:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.120.6304&rep=rep1&type=pdf (DARPA/USAF paper from 2000)
the trick is not blinding other satellites in the process.. especially 'secret' ones that you didn't know were there... also, if the satellite is not really 'dead' (just nonresponsive), it may continue to use it's own OMS etc to counter the laser pressure and stay in orbit... at least until it runs out of fuel.
yeah, except they get pulled out when you need to plug something in, and left (or dropped) on the floor. then the kid chokes on them. I ended up using these:
http://www.safety1st.com/usa/eng/Products/Home-Safety/Electrical/Details/467-10406-Swivel-Outlet-Cover
but they're about $5 each, not 50c each each like the little plastic doohickeys.
you can also get the sockets with built-in guards, but then you have to put up with the sighing and tsk-tsking of everyone who visits because they can't see the protection. seems better to me to just have it in every socket, for a few extra pence (or cents) at build time. especially when you eg visit grandparents and have to run round with a handful of plastic widgets to safe someone else's house.
don't forget that 240V is far more dangerous than 110V (especially with UK ring mains - you're exposed to 30+ amps too, instead of the 15-20A in the US). having been shocked with both at various times, 110V is painful but bearable.. 240V makes you feel like your heart's stopped!
as far as the switches, yes, they're built to be used repeatedly (eg: lamps). I haven't been able to find a socket here in the US with built in switches - it would have to be some sort of combined receptacle and faceplate..
and the plastic guards across the power pin sockets that only open when the earth pin is inserted.. prevents little fingers etc.
oh, and they always (almost always, not on really old sockets) have a switch next to each socket so you can turn them on/off.
for a 'taint mode' in PHP, try this: http://wiki.php.net/rfc/taint
there was a UPS.. it didn't last long enough to cover the entire outage. why didn't it shut down a few minutes before the power ran out? because we were using a logging filesystem, and we needed the machine to run as long as possible.. the backup was not as useful as it should have been (incomplete, sigh). I can't remember a time when ext3 failed to be repaired (sometimes with a little manual help recovering files from lost+found). I have a *very* clear recollection of reiserfs eating huge chunks of the filesystem as it 'repaired'.
me too.. power outage = partially broken filesystem. reiserfsck = completely broken filesystem. and a day long session of trying to fix things on a critical machine. end result: we now use ext3 everywhere...
probably a more useful route would be to port http://www.reactos.com/ to run under Xen. You would need to port their implementation of the NT HAL, plus write the device drivers for network/console etc. (obviously this was what the Xen developers already did for XP but can't release).
the idea behind porting ReactOS is that you end up with an NT style HAL.dll and drivers which *could* be substituted into a real XP install?
caveat: I have no idea how complete ReactOS's HAL.dll is... but they have been trying for API compatibility in most stuff...