In fairness, a country can have lots of astronauts without having the ability to launch them itself. After all, right now, the *USA* doesn't have a man-rated spacecraft, yet we still routinely send astronauts to the ISS. We just use Russian launches for it.
For the record, Windows Phone is reasonably popular in some parts of the world. For example, in India, it's somewhere around 10% (based on sales share there the last few years, and on having just spent a couple weeks in India). As a reminder, there are a *lot* of Indians (though many are too poor to afford a smartphone, even the super-cheap WP8 and Android models popular there).
I'm from Seattle, so Windows phones aren't really that rare around here. I've also seen them in France and, of course, Finland, when I was last there. I only rarely see them in California or elsewhere in the US, though.
On the other hand, when I was in Indonesia last year, there wasn't a single Windows Phone in sight, but I think Blackberries outnumbered iPhones. Android beat both, but it was weird seeing a platform that's a rounding error in the US in second place.
Often it's not even the cheap hardware, but just really shitty drivers (frequently pre-installed by OEMs). Do a clean install of Windows and be careful about the source of your drivers, and you can go years without a crash on Windows (on a heavily used gaming box, no less). I know, I've done it.
I honestly didn't understand why most people hated Vista so much (I mean, it had bugs, but they weren't *that* bad; it used a lot of RAM, but I was running it on 1280 MB and it was all right) until I tried an OEM image of it. Took 3x as long to boot to a usable state (despite having about the same specs), was noticeably laggier, had less free memory, and crashed in under an hour of use (I'd been running the RC2 build - not even release - for months without a crash). That kind of problem with shitty OEM builds is, unfortunately, a problem in the PC world. Apple takes care to avoid it (though their own Windows drivers also tend to be shit.)
Bringing this back to phones, the same problem applies there. An awful lot of Android OEMs take a fairly good OS - the stock Android platform - and then run it on hardware with bad firmware (which, sadly, is usually not user-fixable), bad drivers, and (often buggy) bloatware. The result is... not pretty. The OEMs don't really have anybody to blame but themselves, but the users keep buying it so as far as the OEMs are concerned, they're doing the right thing.
My take on it is, that iPhone users only THINK they use their phone a lot, while Android users use their phones more than they think they do.
Sadly, it's arguably the other way around. The problem isn't that Android users use their phones a lot, it's that the phones (or rather, the OS) is terrible at not using the battery when the user isn't using it. A skilled and conscientious user can regulate their Android phone's battery use pretty well, and get excellent battery life (without compromising functionality much), and there are apps to automate some of that, but... by default, Android is *terrible* about leaving stuff running in the background. This makes it more functional than the competing OSes in some ways, since those tend to have pretty strict restrictions on background processing, but sometimes the stuff it does (like continually tracking your location if you open Maps and then don't tell it to kill the location service when not needed*) is just stupid.
Yes, when you're running something that will really pound on the battery (like gaming) then Android devices might outlast their competition. They do have larger batteries, in most cases, and their processors are no less efficient. The reason for those larger batteries, though, is because in order to get anything close to the same average battery life in normal usage Android needs more battery capacity. Expand the time scale from a few hours of intense usage to a day or normal usage, and Android will usually burn through a lot more Watt-hours for the same level of user usage.
* Caveat: This was something I noticed on my father's Android 4.0 device; they might have fixed it since. It was fucking stupid though; he'd used Maps for a few minutes in the morning (with location, but not navigating to anything), then gone back to the home screen without force-killing the app or turning off GPS, left the phone in his pocket the whole rest of the day, and found its battery nearly dead in the afternoon. Over 90% of the battery had, over half a day, gone into tracking him as he wandered around a boatyard with the app neither running in the foreground nor under orders to do anything in the background!
Correct. As a random example, a NULL pointer read - certainly the most common class of memory error I've seen, probably the most common by far in general - is almost never exploitable (for arbitrary code execution). You can use it to crash programs (denial of service) but usually not for anything else.
They are, in fact, the engines the Musk said were fully 3D printed. Good point about the first flight thing.
Or, for those that prefer a GUI experience, Resource Monitor (can be launched directly, or from the "Performance" tab of Task Manager) has a "Network" tab that shows all processes with network activity or listening ports, and what those ports and protocols are. It's basically the same info as you get from Netstat, but in a conveniently clickable format.
An aborted launch (as opposed to a scrubbed one) would definitely want to divert to the ocean if possible; the Dragon 2 uses the same thrusters (and their same fuel tanks) for its emergency escape system as it does for the intended ground landings. That's one of the reasons it still carries parachutes; in the event that it needs to use its rockets for launch escape, there's not going to be enough fuel left for a propulsive soft landing.
A scrubbed launch, you just get out of the capsule and go back down the stairs or whatever to the launch pad to try again the next day.
For pure Dalvik apps that don't rely on Google Play services, you won't even need to recompile the apps to get them onto Windows (Phone) 10. Just submit the APK as-is to the store.
(search for a brand like Blu). What will it be running? Android 2.3
You can get a BLU phone running the latest release of WP8.1 for under $70 (http://smile.amazon.com/BLU-Win-JR-Smartphone-Unlocked/dp/B00PYWQ7QK/ref=sr_1_1?s=wireless&ie=UTF8&qid=1430876487&sr=1-1&keywords=BLU). It's certainly more than the cheapest Android models, but it's also current software and continues to get upgrades. It can run all the apps that will run on its hardware (no API limitations), can receive software updates promptly, and can even enroll in Microsoft's developer preview program to get new builds as soon as they are released without waiting for OEM review.
Microsoft's own Lumia line - the 4xx and 5xx models in particular - are similarly cheap; I've seen the 520 (now two years old, but it'll still run the latest builds) for under $50 brand new. Android is no longer the uncontested ruler of the low-end smartphone space. In fact, the regions where WP8 has the highest market penetration are those where these low-end phones are the standard choice.
As WP matures, the choice of an antique, insecure, no-longer-targeted-by-developers OS or a modern one that is still getting updates will drive more and more customers to it, unless Google steps up their update game. (Of course, at present, developers don't target *any* version of WP very much, but probably still more than new Android apps that target 2.3 or are tested on it).
The sheer mass of ignorance in that post is staggering. For example, Darwin's theory of evolution by natural selection wasn't even formed in the Galapagos, much less before visiting. It came years after his return to England, though it was in large part informed by his observations on the voyage. He wasn't trying to disprove anything, so far as I know, though as a botanist with theological training but low (for his time) personal piety he may have questioned the theological explanations already.
Also, merely observing things and making theories about them after the fact is, at best, a part of the scientific process. The critical step is using theories to make predictions, and then testing those predictions. Calling that "attempting to disprove a theory" is bad science as well, since it implies a bias against a result; one should simply test whether the predictions are upheld by experimental results (or, where experiments aren't practical, further observation of the environment, preferably a new and untainted example) or the predictions fail. One then refines (or replaces) the theory, based on this new data, and makes new predictions.
Probably (assuming there's any leakage at all), but then you've just got a thruster that is a *less efficient* light drive. As in, it's like a normal photon drive, but a lot of the photons it produces don't actually produce thrust. That would lead to the opposite affect of what we're seeing here, which is a drive that appears to only produce photons yet gets hundreds to thousands of times as much thrust as a photon drive would at that power.
Leaving aside the fact that light has momentum and therefore is sufficiently "physical" a propellant for this example, and the fact that this thing produces orders of magnitudes more thrust than a few Watts worth of photons could impart, you're still missing a really key problem:
You can impart momentum on a mirror by shining a flashlight on it, but you can't impart momentum on a sealed box by having a lit flashlight *inside* it!
The EmDrive uses a sealed cavity. There's nowhere for any propellant to come out, even if there were any!
The order of magnitude isn't actually the weird part. It's the "without propellant" part, or the "but the back is closed" (this thing produces infinite orders of magnitude more force than you'd get out of a photon drive with nowhere for the photons to escape, yet the microwaves are emitted into a sealed chamber).
Basically, it appears to be reactionless. All other propulsion systems are reaction based. When walking, your feet push on the ground; ground goes one way and you go the other. When sailing, your sails push on the wind (bending it to go in a direction more behind you than it otherwise would) and your boat goes in the opposite direction from where the wind goes. When flying, your engines (or an animal's wings) push the air out behind you; air goes backward and you go forward. With a chemical rocket, burning gases come out of the rocket going one way, and the rocket goes the other way. With an ion drive, particles (usually of a gas, like xenon) are ionized and then shoot towards a magnetic field (with their ionization canceled out before passing through the field, so they don't get pulled back by the field); particles go one way, spacecraft goes the other. With a light drive, photons go out one end of the ship (and yes, they have momentum even though the conventional Newtonion function for momentum, mass times velocity, suggests that massless photons shouldn't have any momentum) and each one going backwards imparts and equal (tiny!) amount of momentum in the other direction to the emitter or reflector that they were directed backward from.
In each case, the momentum of the stuff being pushed one direction equals the momentum imparted to the thing doing the pushing. Then we get this thing. With the EmDrive, nothing comes out of the drive. There's nothing (that we can detect) going out the back of the drive. No momentum in one direction to impart momentum in the other. Despite this, the drive tries to go forwards. This is a really, seriously, mysterious result.
I get that this is Slashdot and almost nobody reads TFAs, but seriously, the last time this thing was discussed there were plenty of comments pointing out that it had already been replicated in three different labs around the world... *last year*! True, I don't know if the "... in a vacuum" result has been replicated yet (though at least one lab has offered to do so) but considering that the results in the vacuum were consistent with the atmospheric results (and also considering the care that was taken to ensure that the result wasn't being caused by the atmosphere anyhow, like comparing the operational device with a dummy load that still generates the same heat, or turning the device around) I don't think that the error in our expectations is due to vacuum-vs.-atmosphere, so the other experiments are useful examples of the same effect.