Concorde, at least in British Airways service, ran at a profile for a significant portion of it's service life. BA never lost an opportunity to say that, either.
Of course, that was because BA were effectively given their Concorde fleet (I think they paid 1 UKP per aircraft) by the UK government when they (wisely) refused to pay market rates to purchase them (...because there's no way they'd ever have made a penny out of them if they'd had to pay for them).
A hate working on a monitor that has a little black dot in the middle of the screen. This is one advantage that CRTs still have over LCD. Maybe when resolutions get so his that a single missing pixel is effectively unnoticable, it won't bug me so much.
Hmm. Every single LCD I've worked with with dead pixels fails with white spots, or individual colours (red/green/blue). Which is a LOT less distracting, given I mostly work with light backgrounds. Also, individual pixels are tiny.
Not to say that it's not irritating, but I'd hardly call it unworkable....
EzRocket is a great, great testbed for a restartable, reliable, affordable, commercially available rocket engine.
And the flight test series they conducted really did push the state-of-the-art in rocket propulsion, in all of the arenas above
However, the EZRocket testbed - a converted Rutan LongEze homebuild aircraft - is in *no way* a suitable platform for development as a honest-to-goodness Space Rocket. It's not even got a pressurised cockpit, for instance.
XCor do have sub-orbital transport plans - the Xerus vehicle - but this is at the concept stage: it's not a complete design let alone having any bent metal!
There is no need to launch anything from the equator.
The closer to the equator you launch from, and the closer to due-east your launches are pointed, the more benefit you gain from the Earth's rotation in making orbital velocity.
This applies to Aircraft launches too, since the boost is then: aircraft velocity + earth rotation.
The further your launch is from 0 degrees inclination, the less benefit you gain from earth's rotation, and the less the benefit from launching at the equator. This can actually be made up somewhat by launching from north/south of the equator due east (e.g. Kenedy launches are most efficient to 28 degree inclination launches, the same as the latitude of the launch site.
Launches into polar orbit - 90 degree inclination - by definition get no benefit from Earth's rotation, so it doesn't matter where you launch from.
Launches that are sub-orbital get no benefit from the earth's rotation other than - possibly - affecting the range achieved. For the specific case of the X-Prize, where most teams seem to want to land more-or-less where they launched from, there's no benefit from earth's rotation it's - at most - just another trajectory-affecting factor to take into consideration.
Anyone else unable to compile with JFS enabled as module?
fs/jfs/jfs_dtree.c: In function `add_index': fs/jfs/jfs_dtree.c:388: parse error before `struct' fs/jfs/jfs_dtree.c:389: `temp_table' undeclared (first use in this function) fs/jfs/jfs_dtree.c:389: (Each undeclared identifier is reported only once fs/jfs/jfs_dtree.c:389: for each function it appears in.) make[3]: *** [fs/jfs/jfs_dtree.o] Error 1 make[2]: *** [fs/jfs] Error
Google shows no hits, and it's not important enough for me to track any further at the minute (since disabling JFS is an adequate work-around for me).....
If these systems break down, milage tanks and emissions skyrocket.
See, these are linked. When you do less MPG, you turn more petrol (gasoline) into emissions (CO2, H2O, the noxious nasties) for a given distance driven.
I also note that most (all?) cars are fitted with Cats and ECS systems anyway, not just Hybrids.
The measure of "efficiency of burning" for a car is it's Miles-Per-Gallon attained. What it does with that burned gas - power the wheels directly or recharge a battery - doesn't matter. If both cars burn a gallon to go 30 miles, then (correct me if I'm wrong, someone, please!) by definition they've released the same amount of CO2, H2O and the rest into the atmosphere.
I don't get it. If I drive 31.5MPG and burn a gallon of Gas, I convert 1 gallon of gasoline (petrol) into CO2, H2O and all that other lovely stuff.
The laws of chemistry don't care whether I do it in a hybrid, petro-electric, big-block V8 or average suburban runabout. They just specify that 1 gallon of high-octane hydrocarbons get converted to a bunch of gases, liberating energy
So how does my car's TLA[1] or E-TLA[2] classification affect it's actual[3] efficiency/cleanliness?
[1] = Three Letter Acronym
[2] = Extended-TLA, AKA Four-Letter-Acronym
[3] = Yes, I read the article and I realise that the EPA's methods of testing and subsequent classifications have nothing to do with the laws of physics, chemistry or common sense. Which is probably the answer I'm looking for here anyway...
Uh, I hate to point out the obvious, but just where do you think the precious electricity comes from that drives your hybrid vehicle? Bzzzzt! Time's up! It comes from fossil fuels, that's where it comes from!
Umm... Since this is the good 'ol US-of-A, I thought a not-insignificant fraction of that electricty came from Your Friend, The Atom ?
Or have I been lied to by US-sourced programming like The Simpsonsagain?
OK, all the best names (Lotus!) are owned abroad, but what's left ain't bad[1]
[1] = Except Rover. I speak as someone who owned one[2]
[2] = OK, two. Technically the first one was an Austin Metro though. It should be in the top 10 bad cars list.
Actually the Space Shuttle does have to worry about skipout. Any vehicle traveling faster than orbital velocity has to worry about it.
Errr.... Self-contradiction here?
The Shuttle, by definition and design, never exceeds orbital velocity.
And I stand by my original assertion: Once the shuttle touches atmosphere, it's coming down soon, and it's only a matter of where and how. "Skip-Out" in this case can only be for a fraction of an orbit, because by definition once you've encountered atmospheric drag you'll have reduced your velocity below that required to maintain your current orbit. For the Shuttle, this won't present a consumables issue, although it might present control issues.
Your explanation of the difference between heating loads and rates is useful, but misses the point. With a "dense", unpowered vehicle like the Shuttle, your options for descent are limited: you need to get deep enough into the atmosphere to generate sufficent aerodynamic lift in order to maintain altitude whilst bleeding off speed (reducing your heating rate), but not so deep as to generate enough friction to overload the TPS. In fact, the TPS HAS to be designed to cope with this heating rate since that's going to be the minimum possible. Your other options are to lower the wing-loading of the vehicle (by reducing total mass or increasing wing area) which would allow you to slow down higher in the atmosphere at a lower rate. Interestingly, the total heat load would be roughly similar from such a tradeoff, but the rate would be lower. Lower/Faster descents do reduce the total heat load on the airframe, but at the expense of vastly greater heating rates, far beyond the ability of the TPS to cope. It's this tradeoff between heating rate and aerodynamic control (i.e. lift!) that drives the Shuttle's descent profile, rather than a need to minimise total heat load (because your vehicle configuration pretty much decides this).
Technically speaking, the only way to "Bounce off" the atmosphere is if you're coming in at greater than earth's escape velocity. If you're travelling slower than escape velocity, the best you can manage is a "loft" that trades height for speed. The golden rule here is: Once your non-interplanetary vehicle encounters the sensible atmosphere, your time in orbit is just about over.
The only vehicles for which "Bounce" was a serious problem were the Apollo capsules and Russia's Zond lunar spacecraft (which never flew manned). In the case of Apollo, "Skipping" was a serious consideration since although the trajectories ensured that even at lunar-reentry speeds, the atmosphere would be re-encountered, this could take 2-3 days on a looonggg orbit - a problem when the Command Module held power, fuel and other consumables for only 2-3 hours independent flight (having ditched the Service Module at this point). The re-entry programs and manual reversion procedures thus focussed on ensuring that a skip absolutely did not happen, at the expense of a hard ride down and loss of targetting, if necessary.
In the case of the X-15, however, the problems were different although related. Because the X-15 only got up to about Mach 6 (remembering that even low-earth orbit requires a speed of Mach 25), there was never any question of performing a significant "Bounce". Nevertheless, the conditions on an X-15 re-entry were severe enough that a Thermal Protection System (TPS) was required. Problem was, this was designed for the X-15's original target speed of Mach 5 and used a "heat-sink" inconel structure to absorb the heat whilst retaining strength. This worked just about OK, however when the X-15-A2 mods were made (external fuel tanks to increase deltaV hence re-entry speeds), this increase was enough to overload the TPS. The solution attempted was to spray a coating of (pink) ablative material over the X-15 before each flight, and let it burn off during re-entry. This proved problematic, not least of all because the charring ablative coated the pilot's windscreen! A more serious problem was caused by an experiment attached to the lower ventral fin, a mock-up of a hypersonic ramjet. At the increased speeds encountered by the X-15-A2, the shock waves from this ramjet impinged on the lower fin (rather than streaming past) and caused sufficient local heating to "eat" away the fin's structure.
Whilst it may be tempting to assign all of these problems to the "should have known better" category, remember that A) The X-15 was designed in the '50s. Using slide-rules and paper, and best judgement rather than fancy-dancy CFD codes and CAD/CAM. B) The X is important: it means that it's a vehicle designed to find out what the issues and problems are with a particular flight regime, and to test potential solutions.
SpaceShipOne's flight program is similar to the X-15 in many respects, but is lower-energy (Mach3 vs Mach5-7). They can expect to see greatly reduced heat load problems during their re-entry profile because of this, as well as having a novel way of dealing with it in a controlled fashion.
There's probably a technical specification of re-entry, but a good working definition is "A manoever re-encountering significant aerodynamic effects occuring at hypersonic(ish) speeds". You'll note the fudge-factor on speed there.
To paraphrase this: It's not the height you get to, it's the speed at which you re-encounter the sensible atmosphere.
In the case of the X-prize contenders, they'll all pretty much have to "re-enter" the atmosphere even though they're sub-orbital: anything using a rocket to get to the height required for the X-Prize (100km I think?) is going to have to be going relatively fast to achieve this; SpaceShipOne is planning a maximum speed of Mach 3ish IIRC. Thus, they'll all be hitting the atmosphere fast enough to encounter significant aerodynamic heating. Fortunately for them, they won't be doing it for long or too severely: the feathered flight mode effectively turns the whole fuselage into an airbrake, which not only bleeds speed off quickly (reducing total heat load) but also spreads the heated area across the whole base of the craft (reducing specific heat input in Watts/Square Metre or whatever your preferred power/area units are!). All this means that SpaceShipOne can get away with a fairly limited Thermal Protection System. Compare and Contrast with Shuttle's extensive, expensive, fragile TPS or Apollo's use-once-and-throw-away ablative heatshield TPS.
Note that your reasoning for worrying is slightly OTT: The difference between X-Prize sub-orbital flight and Shuttle-type orbital flight is ~Mach3 vs ~Mach25. That's quite an "over-achievement" to be hoping for, I'm afraid (and, since total heat energy input scales better than linearly with increasing speed, such a craft "over-achieving" could expect a very short and glorious career as a fireball).
I've never had Voice Dialling dial the wrong number, but plenty of times when it's failed to find the right number. It's by no means a perfectly working feature, but for my application at least it's marginally serviceable.
I'd have thought it was close enough that the extra processing power of a smartphone / pda CPU would have made it very reasonable, rather than something to be waited on by a 3rd party app. developer...
Blimy, first no bluetooth (which would have let me not only do handsfree calls but also sync to PC), now no voice diallingI thought the big thing about a Treo was it's a Converged Device... you know, best of both worlds? But if it's lacking these sorts of phone facilities, and "only" running PalmOS (not that there's anything wrong with PalmOS but I like my environments a bit fuller-featured and hackable, personally), then it's absolutely no use to me. I'll stick with my (bluetoothed and voice-dialling) Nokia 6310i and my soon-to-be-replaced-by-Zaurus-C760 Psion 5mx PDA thanks. It doesn't sound like there's anything useful the Treo can do that I either can't do now (albeit slower and in B&W), or don't really want to do (Why bother with photo caller ID if I have to hold the phone to my ear to use it?)
Sorry, this is all rather inflammatory of me I know, but this really does sound like Technology for Technologie's sake rather than in the service of a better product...
Colour me redundant by all means, but a phone this size, with such a beautiful screen that you're obviously supposed to, you know, look at, and it's got no Bluetooth? What were they thinking? How am I supposed to use the thing to make calls in this 21st-century totally hi-tech world of ours? I'm sure as hell not going to hold it up to my ear and mess up the nice screen. And a wired handsfree kit? Oh how very 20th century. Not to mention illegal to use in the car, come December here in the UK.
OK, I'm foaming at the mouth needlessly, but seriously... a smartphone without Bluetooth, in 2003 already, just sounds so terribly incomplete to these European Consumer's eyes...
Perhaps I shouldn't worry too much, after all it's not like it's actually available over here anyway...
OK, I'm in favour of working-around the problem in classic
The internet interprets {badthing} as damage and routes around it
..fashion, and I'll be installing a patched bind whenever I can.
But I'm really concerned that this effectively lets VeriSign get away with it. They've bust everyone's trust folks, doesn't anyone care? This sort of activity in a social context (umm... let's see if we can construct a tortured metaphor:...uhhh..: Your friend asks for your cousins's phone number and you instead give them the phone number of your shop. Reasonable?) would result in the perpetrator being ostracised fairly quickly, if not actually slapped about by a clue-by-four. It's flat out antisocial behaviour, never mind any legalities.
Here, since these buggers appear to hold us all over a barrel with the root domains, we can't just ignore them, and invoking legal recourses is at best slow and expensive. But what about appeal to the authorities that granted them those rights?
Um, the more I rant about this the closer I get to thinking a better solution is switching to an alternate root... Best head off to google again then, I know there's a way around this...
I've had that happen to me on a number of different systems including my KT-7 RAID (-0) system.
Possibly erroneously, I've put it down to thermal recalibrations since there doesn't appear to be any fixed pattern to them (e.g. when I know I'm hitting certain files that would indicate a disk-region specific problem). And I've never had a crash or corrupt data - just a system freeze for 2-3 seconds then carry on as before. Typically affects Windows boxen more than it affects Linux (just from a user responsiveness standpoint; it actually occurs for me under both OSes and various flavours of Windows).
I notice you're marked FLAMEBAIT which is probably not fair.
However, I'm not sure your testing methodology is correct. I just went back through some older logs on my box,using the same method as you, and I get variable but large numbers of hits on these ports going back as far as August 3rd (in which I got 260 hits on these ports). My record so far appears to be August 6th when I got 821 hits, which is still before the worm was released.
So I'm not so sure you're actually measuring anything worthwhile with this. Sorry.
I have a Nokia HDW-2, so you can immediately file me in the "Kook" category
I wanted a Bluetooth headset precisely because I wanted to avoid wires from the phone to the headset. My job means I do spend a not inconsiderable time in the car, although not enough to justify a full on car kit (although I'm keeping my options open for the next car being bluetooth equipped...). My experience has been that wired headsets get in the way when driving: even if you've allowed enough slack in the leads, looking left and right still makes you feel like it's going to fall out at an inconvenient time. The HDW-2 is small enough and light enough that you just don't notice it for these things, and that means you can concentrate on something else (...like driving).
For what it's worth, the headset does claim to use encryption between compatible nokia phones and headsets. Not that I worry too much about this: the range of the device isn't enough really that it's worth getting all technical: you can probably just overhear what I'm saying.
I pretty much agree with the review above though: it's great indoors, or in the car. But it's absolutely useless outdoors since the Mic picks up just about any wind noise (such as that generated just walking along) which makes you really unpopular really quickly.
Great idea! That covers the control aspect admirably! I shall be sure and tell the great folks on RISKS Digest that all their fears and previous examples of control law systems going wrong are of no import.
OK, that was harsh. FBW works OK in the real world, I guess, after 30-odd years of development. I wonder about tuning it for a model Helo but never mind that
Rather more seriously, how do you propose to tackle the mechanical reliability issues? Model RC engines aren't up in the RB211-runs-for-years reliability range, and all that whirling mass and consequent vibration takes it's toll on the structure too. I think this would actually be the killer for any real world application involving long-duration (longer than 10 minutes or so) flight, high availability and high required reliability. But maybe I worry too much.
Err... See, the thing about model helicopters is that they're a complete pig to fly. I think the mean-time-before-superglue for learner pilots is about 30 seconds of flight time. It's inherent in the technology: they're very mechanically complex and dynamically unstable.
So having said all that, do you think it would be a good idea to have a whirling mass of blades teetering close to anything you think as valuable? Such as cyclist's heads, for example?
LEO is about 8KM/Sec. Earth Escape velocity is about 11KM/Sec. Which changes the figures somewhat - LEO is 72% of anywhere...
To put this in context, note that the only man-rated launcher capable of this speed, the Saturn V, had a capacity to Low Earth Orbit 118 Tonnes, wheras the capacity to Lunar orbits (which are as close to escape velocity as makes no odds) was about 43 Tonnes, or only about 40% of LEO payload capacity. All of which should go to make the point that it'd take an awful lot of rocket and fuel to make much of a difference to Hubble's orbit.
...And we haven't even started on the changes needed to ensure Hubble can operate in deep space (cold) compared to nice, warm LEO (where the warm Earth fills half of the sky all the time). Or on the telemetry requirements (IIRC Hubble uses TDRS for data relay so only has relatively small antennas and transmitter power itself)
"The Hubble was supposed to photograph wide swaths of the sky with the greatest precision ever achieved. With the blurry lens the precision was gone. However, when they repaired the lens to restore the precision, the resulting view was no longer wide swaths, and was more like looking through a keyhole at a little piece of the sky."
This may have been true of WFPC-2 (the camera installed during the first servicing mission that went along with the corrective optics package that worked around the defective secondary mirror. However, I don't believe it's true of the current optics set installed after the last mission, since all of the instruments installed then (leaving none of the original cameras and sensors, IIRC) were designed with the spherical aberration in mind. Indeed, the corrective optics package was removed during this last mission to make room for another instrument...
On the other hand, I can't recall whether the ability to do wide field-of-regard imaging was restored since that would have been down to the scientific merit; I believe the advances in earth bound observation from active optics have made the return from doing wide-area imaging from Hubble less attractive..
Slashdot Mirror
Of course, that was because BA were effectively given their Concorde fleet (I think they paid 1 UKP per aircraft) by the UK government when they (wisely) refused to pay market rates to purchase them (...because there's no way they'd ever have made a penny out of them if they'd had to pay for them).
Hmm. Every single LCD I've worked with with dead pixels fails with white spots, or individual colours (red/green/blue). Which is a LOT less distracting, given I mostly work with light backgrounds. Also, individual pixels are tiny.
Not to say that it's not irritating, but I'd hardly call it unworkable....
EzRocket is a great, great testbed for a restartable, reliable, affordable, commercially available rocket engine.
And the flight test series they conducted really did push the state-of-the-art in rocket propulsion, in all of the arenas above
However , the EZRocket testbed - a converted Rutan LongEze homebuild aircraft - is in *no way* a suitable platform for development as a honest-to-goodness Space Rocket. It's not even got a pressurised cockpit, for instance.
XCor do have sub-orbital transport plans - the Xerus vehicle - but this is at the concept stage: it's not a complete design let alone having any bent metal!
There is no need to launch anything from the equator.
The closer to the equator you launch from, and the closer to due-east your launches are pointed, the more benefit you gain from the Earth's rotation in making orbital velocity.
This applies to Aircraft launches too, since the boost is then: aircraft velocity + earth rotation.
The further your launch is from 0 degrees inclination, the less benefit you gain from earth's rotation, and the less the benefit from launching at the equator. This can actually be made up somewhat by launching from north/south of the equator due east (e.g. Kenedy launches are most efficient to 28 degree inclination launches, the same as the latitude of the launch site.
Launches into polar orbit - 90 degree inclination - by definition get no benefit from Earth's rotation, so it doesn't matter where you launch from.
Launches that are sub-orbital get no benefit from the earth's rotation other than - possibly - affecting the range achieved. For the specific case of the X-Prize, where most teams seem to want to land more-or-less where they launched from, there's no benefit from earth's rotation it's - at most - just another trajectory-affecting factor to take into consideration.
Anyone else unable to compile with JFS enabled as module?
Google shows no hits, and it's not important enough for me to track any further at the minute (since disabling JFS is an adequate work-around for me).....
I think you're emphasising my point:
See, these are linked. When you do less MPG, you turn more petrol (gasoline) into emissions (CO2, H2O, the noxious nasties) for a given distance driven.
I also note that most (all?) cars are fitted with Cats and ECS systems anyway, not just Hybrids.
The measure of "efficiency of burning" for a car is it's Miles-Per-Gallon attained. What it does with that burned gas - power the wheels directly or recharge a battery - doesn't matter. If both cars burn a gallon to go 30 miles, then (correct me if I'm wrong, someone, please!) by definition they've released the same amount of CO2, H2O and the rest into the atmosphere.
Ummmmmmmmmmm....
I don't get it. If I drive 31.5MPG and burn a gallon of Gas, I convert 1 gallon of gasoline (petrol) into CO2, H2O and all that other lovely stuff.
The laws of chemistry don't care whether I do it in a hybrid, petro-electric, big-block V8 or average suburban runabout. They just specify that 1 gallon of high-octane hydrocarbons get converted to a bunch of gases, liberating energy
So how does my car's TLA[1] or E-TLA[2] classification affect it's actual[3] efficiency/cleanliness?
[1] = Three Letter Acronym
[2] = Extended-TLA, AKA Four-Letter-Acronym
[3] = Yes, I read the article and I realise that the EPA's methods of testing and subsequent classifications have nothing to do with the laws of physics, chemistry or common sense. Which is probably the answer I'm looking for here anyway...
Umm... Since this is the good 'ol US-of-A, I thought a not-insignificant fraction of that electricty came from Your Friend, The Atom ?
Or have I been lied to by US-sourced programming like The Simpsons again?
I was going to say something disparaging about US cars and gas mileage, since my 2.4 Volvo V70 tank gets about 33 MPG
...Then I remembered that UK Gallons are about 20% bigger than US Gallons, and that I was going to make a fool of myself, again
Carry on, nothing to see here....
Morgan.
Westfield.
Noble.
TVR.
Marcos.
MG Rover. Again.
OK, all the best names (Lotus!) are owned abroad, but what's left ain't bad[1]
[1] = Except Rover. I speak as someone who owned one[2]
[2] = OK, two. Technically the first one was an Austin Metro though. It should be in the top 10 bad cars list.
Errr.... Self-contradiction here?
The Shuttle, by definition and design, never exceeds orbital velocity. And I stand by my original assertion: Once the shuttle touches atmosphere, it's coming down soon, and it's only a matter of where and how. "Skip-Out" in this case can only be for a fraction of an orbit, because by definition once you've encountered atmospheric drag you'll have reduced your velocity below that required to maintain your current orbit. For the Shuttle, this won't present a consumables issue, although it might present control issues.
Your explanation of the difference between heating loads and rates is useful, but misses the point. With a "dense", unpowered vehicle like the Shuttle, your options for descent are limited: you need to get deep enough into the atmosphere to generate sufficent aerodynamic lift in order to maintain altitude whilst bleeding off speed (reducing your heating rate), but not so deep as to generate enough friction to overload the TPS. In fact, the TPS HAS to be designed to cope with this heating rate since that's going to be the minimum possible. Your other options are to lower the wing-loading of the vehicle (by reducing total mass or increasing wing area) which would allow you to slow down higher in the atmosphere at a lower rate. Interestingly, the total heat load would be roughly similar from such a tradeoff, but the rate would be lower. Lower/Faster descents do reduce the total heat load on the airframe, but at the expense of vastly greater heating rates, far beyond the ability of the TPS to cope. It's this tradeoff between heating rate and aerodynamic control (i.e. lift!) that drives the Shuttle's descent profile, rather than a need to minimise total heat load (because your vehicle configuration pretty much decides this).
OOOh, I'm going to blow karma on a pedantry trip
Technically speaking, the only way to "Bounce off" the atmosphere is if you're coming in at greater than earth's escape velocity. If you're travelling slower than escape velocity, the best you can manage is a "loft" that trades height for speed. The golden rule here is: Once your non-interplanetary vehicle encounters the sensible atmosphere, your time in orbit is just about over.
The only vehicles for which "Bounce" was a serious problem were the Apollo capsules and Russia's Zond lunar spacecraft (which never flew manned). In the case of Apollo, "Skipping" was a serious consideration since although the trajectories ensured that even at lunar-reentry speeds, the atmosphere would be re-encountered, this could take 2-3 days on a looonggg orbit - a problem when the Command Module held power, fuel and other consumables for only 2-3 hours independent flight (having ditched the Service Module at this point). The re-entry programs and manual reversion procedures thus focussed on ensuring that a skip absolutely did not happen, at the expense of a hard ride down and loss of targetting, if necessary.
In the case of the X-15, however, the problems were different although related. Because the X-15 only got up to about Mach 6 (remembering that even low-earth orbit requires a speed of Mach 25), there was never any question of performing a significant "Bounce". Nevertheless, the conditions on an X-15 re-entry were severe enough that a Thermal Protection System (TPS) was required. Problem was, this was designed for the X-15's original target speed of Mach 5 and used a "heat-sink" inconel structure to absorb the heat whilst retaining strength. This worked just about OK, however when the X-15-A2 mods were made (external fuel tanks to increase deltaV hence re-entry speeds), this increase was enough to overload the TPS. The solution attempted was to spray a coating of (pink) ablative material over the X-15 before each flight, and let it burn off during re-entry. This proved problematic, not least of all because the charring ablative coated the pilot's windscreen! A more serious problem was caused by an experiment attached to the lower ventral fin, a mock-up of a hypersonic ramjet. At the increased speeds encountered by the X-15-A2, the shock waves from this ramjet impinged on the lower fin (rather than streaming past) and caused sufficient local heating to "eat" away the fin's structure.
Whilst it may be tempting to assign all of these problems to the "should have known better" category, remember that A) The X-15 was designed in the '50s. Using slide-rules and paper, and best judgement rather than fancy-dancy CFD codes and CAD/CAM. B) The X is important: it means that it's a vehicle designed to find out what the issues and problems are with a particular flight regime, and to test potential solutions.
SpaceShipOne's flight program is similar to the X-15 in many respects, but is lower-energy (Mach3 vs Mach5-7). They can expect to see greatly reduced heat load problems during their re-entry profile because of this, as well as having a novel way of dealing with it in a controlled fashion.
There's probably a technical specification of re-entry, but a good working definition is "A manoever re-encountering significant aerodynamic effects occuring at hypersonic(ish) speeds". You'll note the fudge-factor on speed there.
To paraphrase this: It's not the height you get to, it's the speed at which you re-encounter the sensible atmosphere.
In the case of the X-prize contenders, they'll all pretty much have to "re-enter" the atmosphere even though they're sub-orbital: anything using a rocket to get to the height required for the X-Prize (100km I think?) is going to have to be going relatively fast to achieve this; SpaceShipOne is planning a maximum speed of Mach 3ish IIRC. Thus, they'll all be hitting the atmosphere fast enough to encounter significant aerodynamic heating. Fortunately for them, they won't be doing it for long or too severely: the feathered flight mode effectively turns the whole fuselage into an airbrake, which not only bleeds speed off quickly (reducing total heat load) but also spreads the heated area across the whole base of the craft (reducing specific heat input in Watts/Square Metre or whatever your preferred power/area units are!). All this means that SpaceShipOne can get away with a fairly limited Thermal Protection System. Compare and Contrast with Shuttle's extensive, expensive, fragile TPS or Apollo's use-once-and-throw-away ablative heatshield TPS.
Note that your reasoning for worrying is slightly OTT: The difference between X-Prize sub-orbital flight and Shuttle-type orbital flight is ~Mach3 vs ~Mach25. That's quite an "over-achievement" to be hoping for, I'm afraid (and, since total heat energy input scales better than linearly with increasing speed, such a craft "over-achieving" could expect a very short and glorious career as a fireball).
I've never had Voice Dialling dial the wrong number, but plenty of times when it's failed to find the right number. It's by no means a perfectly working feature, but for my application at least it's marginally serviceable.
I'd have thought it was close enough that the extra processing power of a smartphone / pda CPU would have made it very reasonable, rather than something to be waited on by a 3rd party app. developer...
Blimy, first no bluetooth (which would have let me not only do handsfree calls but also sync to PC), now no voice diallingI thought the big thing about a Treo was it's a Converged Device... you know, best of both worlds? But if it's lacking these sorts of phone facilities, and "only" running PalmOS (not that there's anything wrong with PalmOS but I like my environments a bit fuller-featured and hackable, personally), then it's absolutely no use to me. I'll stick with my (bluetoothed and voice-dialling) Nokia 6310i and my soon-to-be-replaced-by-Zaurus-C760 Psion 5mx PDA thanks. It doesn't sound like there's anything useful the Treo can do that I either can't do now (albeit slower and in B&W), or don't really want to do (Why bother with photo caller ID if I have to hold the phone to my ear to use it?)
Sorry, this is all rather inflammatory of me I know, but this really does sound like Technology for Technologie's sake rather than in the service of a better product...
Acchh!
Colour me redundant by all means, but a phone this size, with such a beautiful screen that you're obviously supposed to, you know, look at, and it's got no Bluetooth? What were they thinking? How am I supposed to use the thing to make calls in this 21st-century totally hi-tech world of ours? I'm sure as hell not going to hold it up to my ear and mess up the nice screen. And a wired handsfree kit? Oh how very 20th century. Not to mention illegal to use in the car, come December here in the UK.
OK, I'm foaming at the mouth needlessly, but seriously... a smartphone without Bluetooth, in 2003 already, just sounds so terribly incomplete to these European Consumer's eyes...
Perhaps I shouldn't worry too much, after all it's not like it's actually available over here anyway...
OK, I'm in favour of working-around the problem in classic
But I'm really concerned that this effectively lets VeriSign get away with it. They've bust everyone's trust folks, doesn't anyone care? This sort of activity in a social context (umm... let's see if we can construct a tortured metaphor: ...uhhh..: Your friend asks for your cousins's phone number and you instead give them the phone number of your shop. Reasonable?) would result in the perpetrator being ostracised fairly quickly, if not actually slapped about by a clue-by-four. It's flat out antisocial behaviour, never mind any legalities.
Here, since these buggers appear to hold us all over a barrel with the root domains, we can't just ignore them, and invoking legal recourses is at best slow and expensive. But what about appeal to the authorities that granted them those rights?
Um, the more I rant about this the closer I get to thinking a better solution is switching to an alternate root... Best head off to google again then, I know there's a way around this...
Re: your intermittent freeze situation...
I've had that happen to me on a number of different systems including my KT-7 RAID (-0) system.
Possibly erroneously, I've put it down to thermal recalibrations since there doesn't appear to be any fixed pattern to them (e.g. when I know I'm hitting certain files that would indicate a disk-region specific problem). And I've never had a crash or corrupt data - just a system freeze for 2-3 seconds then carry on as before. Typically affects Windows boxen more than it affects Linux (just from a user responsiveness standpoint; it actually occurs for me under both OSes and various flavours of Windows).
I notice you're marked FLAMEBAIT which is probably not fair.
However, I'm not sure your testing methodology is correct. I just went back through some older logs on my box,using the same method as you, and I get variable but large numbers of hits on these ports going back as far as August 3rd (in which I got 260 hits on these ports). My record so far appears to be August 6th when I got 821 hits, which is still before the worm was released.
So I'm not so sure you're actually measuring anything worthwhile with this. Sorry.
I have a Nokia HDW-2, so you can immediately file me in the "Kook" category
I wanted a Bluetooth headset precisely because I wanted to avoid wires from the phone to the headset. My job means I do spend a not inconsiderable time in the car, although not enough to justify a full on car kit (although I'm keeping my options open for the next car being bluetooth equipped...). My experience has been that wired headsets get in the way when driving: even if you've allowed enough slack in the leads, looking left and right still makes you feel like it's going to fall out at an inconvenient time. The HDW-2 is small enough and light enough that you just don't notice it for these things, and that means you can concentrate on something else (...like driving).
For what it's worth, the headset does claim to use encryption between compatible nokia phones and headsets. Not that I worry too much about this: the range of the device isn't enough really that it's worth getting all technical: you can probably just overhear what I'm saying.
I pretty much agree with the review above though: it's great indoors, or in the car. But it's absolutely useless outdoors since the Mic picks up just about any wind noise (such as that generated just walking along) which makes you really unpopular really quickly.
Great idea! That covers the control aspect admirably! I shall be sure and tell the great folks on RISKS Digest that all their fears and previous examples of control law systems going wrong are of no import.
OK, that was harsh. FBW works OK in the real world, I guess, after 30-odd years of development. I wonder about tuning it for a model Helo but never mind that
Rather more seriously, how do you propose to tackle the mechanical reliability issues? Model RC engines aren't up in the RB211-runs-for-years reliability range, and all that whirling mass and consequent vibration takes it's toll on the structure too. I think this would actually be the killer for any real world application involving long-duration (longer than 10 minutes or so) flight, high availability and high required reliability. But maybe I worry too much.
Err... See, the thing about model helicopters is that they're a complete pig to fly. I think the mean-time-before-superglue for learner pilots is about 30 seconds of flight time. It's inherent in the technology: they're very mechanically complex and dynamically unstable.
So having said all that, do you think it would be a good idea to have a whirling mass of blades teetering close to anything you think as valuable? Such as cyclist's heads, for example?
I've already been corrected on this elsewhere in the thread.
LEO is about 8KM/Sec. Earth Escape velocity is about 11KM/Sec. Which changes the figures somewhat - LEO is 72% of anywhere...
To put this in context, note that the only man-rated launcher capable of this speed, the Saturn V, had a capacity to Low Earth Orbit 118 Tonnes, wheras the capacity to Lunar orbits (which are as close to escape velocity as makes no odds) was about 43 Tonnes, or only about 40% of LEO payload capacity. All of which should go to make the point that it'd take an awful lot of rocket and fuel to make much of a difference to Hubble's orbit.
...And we haven't even started on the changes needed to ensure Hubble can operate in deep space (cold) compared to nice, warm LEO (where the warm Earth fills half of the sky all the time). Or on the telemetry requirements (IIRC Hubble uses TDRS for data relay so only has relatively small antennas and transmitter power itself)
You're absolutely right: 8KM/S for very-LEO, 7KM/S for higher Leo. How very embarrasing when a quick google would have put me straight.
Thank you for the corrections.
This may have been true of WFPC-2 (the camera installed during the first servicing mission that went along with the corrective optics package that worked around the defective secondary mirror. However, I don't believe it's true of the current optics set installed after the last mission, since all of the instruments installed then (leaving none of the original cameras and sensors, IIRC) were designed with the spherical aberration in mind. Indeed, the corrective optics package was removed during this last mission to make room for another instrument...
On the other hand, I can't recall whether the ability to do wide field-of-regard imaging was restored since that would have been down to the scientific merit; I believe the advances in earth bound observation from active optics have made the return from doing wide-area imaging from Hubble less attractive..