XP, being NT, still has the POSIX subsystem. It probably still works with NetBSD's pkgsrc, too.
Also, it's not so useless as you claim; Microsoft themselves used it internally for years to host Hotmail, and right up until Win8.1 it was a viable alternative to Cygwin for anybody with a compatible version of Windows (or who wanted to force it to run anyhow). It handles/handled some things, such as SetUID/SetGID, which Cygwin couldn't (and I believe still can't) emulate, supported case-sensitivity on NTFS (though this could be used to confuse the hell out of Win32 programs), had a couple of different choices of package managers available, and could compile and run most source code intended for *nix systems (third-party compatibility layers added support for some of Linux's extensions to POSIX).
BZZZZT try again. Chrome used (and still uses) its own JS engine, distinct from the built-in JS support in WebKit. Apple didn't let them do that on iOS; they had to use the JS engine that runs in the WebKit that is used in the webview widget, no exceptions. Until a recent iOS version (8, I believe), that WebKit build didn't even use JIT-compiled JavaScript, so it was always a lot slower than Safari.
The JS engine (including both its performance and its behavior) is a hugely important part of a modern browser. By that standard, Chrome-on-iOS definitely wasn't the same thing as Chrome-on-PC.
That's not how HSTS preload works. Or rather, it is, but you're missing a vital step. The preload list won't accept sites that don't specify the "preload" flag in their Strict-Transport-Security header. It ought to go without saying that they won't accept sites which don't serve HTTPS at all...
The max-age and includeSubDomains directives are relevant to browsers. The preload directive is relevant to HSTS preload list maintainers (or rather, to their servers). I guess the government could try coercing the preload list maintainers into including the relevant.gov sites even if they don't meet the requirements for inclusion in the list, but I'm pretty sure that won't happen.
Space is really, *really* fucking big. Even low earth orbit at any given altitude is vast; it's literally larger than the surface of the planet. Add altitude shells to that - go up a few KM and you're now a few KM away from anything in the lower shell, even at closest point of approach - and there's an astonishing amount of room in space.
You wouldn't ask if there's room for 4000 more ships on the ocean, despite the fact that there's a lot less ocean and a lot more things crossing it vs. what we have in LEO. You wouldn't even ask if there's room for 4000 more cars on the road in the continental US, despite there being many orders of magnitude less space on US roads than there is in any given LEO altitude. Satellites, functional or not (including debris), move in predictable patterns, and functional satellites have thrusters that allow them to alter or maintain their course.
Agreed, of course, that the satellites should be capable of de-orbiting. But seriously, this "is there enough space in LEO?!?" meme is kind of dumb, at least right now. Let's assume you put each satellite in the middle of 20x20 KM non-overlapping exclusionary zone (omitting the third dimension for now). 400 KM^2 per bird. 1,600,000 KM^2 total. Sounds big, right? You could fit that entire collection, with a hundred thousand square KM left over, into Alaska. Don't get me wrong, Alaska is a big place, but it's not *that* big on the world scale. That's all in one orbital shell.
Well, MS isn't always the fastest on rolling out security features. Somebody else may need to lead the way. If the Mozilla foundation releases HSTS for Firefox 1.0, it might be possible to persuade MS to do the same for their similarly-aged browser...
SRP has a number of problems, the most notable being that there's no way to securely *distribute* (or create) the password without falling back to some other TLS suite, or doing it out of band. This really limits the usefulness of SRP in a browser.
Additionally, I'm not sure how browser support for SRP is supposed to make phishing stop working. If the user still needs to enter their password somewhere, then the phishing attack just has to look like wherever they usually enter their password. Yes, an attacker intercepting the network traffic of a legitimate handshake won't be able to extract any useful info about the password (or be able to replay it blindly), but a phishing site that gets users to enter their password and then sends that password back to the (attacker's) server via whatever mechanism it cares to will still work just fine.
On the other hand, there are definitely places that I'd like to see SRP deployed. A key one, which I consider a lot more important than in browsers, would be as a replacement for NTLM hashes (which are antique and terrible) in SMB (Windows networking, Samba, etc.) traffic. It also makes sense for things like remote desktop or ssh (where, at least for password auth, you assume that both sides already know the password so the distribution problem is taken care of). Once you have it in those places, putting it in the browser seems reasonable enough - after all, enterprises do use IE's built-in support for NTLM auth to web servers, which sucks about as much as NTLM for SMB - but I'd put the other areas ahead of the browser.
On the one hand, you're kind of wrong; any site that wants to can opt into the HSTS preload list, and IE uses the same preload list that both Chrome, Safari, and Firefox use. The preload list, by the way, is not a "whitelist" in the usual sense; it simply has the effect of there having been a "zeroth visit" before the first visit, so the first visit is safe. After that, the site behaves as normal.
On the other hand, it is true that getfirefox.com doesn't support HSTS at all (much less appear in the preload list, which would reject it anyhow for failing to have the response header present). Worse, though, mozilla.org doesn't seem to support it! At least, the Chrome dev tools don't list the Strict-Transport-Security header in responses from the site. That is a bizarre (and, frankly, unwise) omission.
The Internet was a very different place 15 years ago! Also, satellites were less advanced, bandwidth demand was lower, launch costs were higher, and Elon Musk wasn't behind the project.
OpenSSH has been ported to Windows a number of times. Off the top of my head:
* Interix (POSIX subsystem running on native NT, but still technically Windows) has at least one version of OpenSSH (server and client).
* Cygwin (emulates Unix on Win32) has OpenSSH, (server and client).
* MSYS (a set of Unix tools ported to Win32 via MinGW) has OpenSSH (client for sure - it's installed with Git for Windows - not sure about server).
None of those are terribly well integrated with Windows' way of doing things, though. Sometimes that's a good thing - I can take my.ssh folder from a Linux box, drop it on a Windows system, and it'll work with the things listed above - but it also means that (for example) the public key used when SSHing into my Windows box is completely unrelated to the public key used when RDPing into the same box. That's silly.
Indeed. I expect one of the things they'll be looking at doing is adding support for some of Windows' built-in authentication options. For example, recent versions of RDP use machine certificates, typically with a trust-on-first-use model similar to SSH. It would be nice if SSHing into a Windows box could re-use that machine cert, and SSHing from a Windows box could take advantage of the list of IP+cert pairs that you already trust. This would require some code changes to OpenSSH though, since it is of course currently utterly unaware of Windows' certificate stores.
Also, powershell isn't really used to displaying to anything except Windows consoles. Just for the hell of it, I tried running it in xterm (which, while antique, any *nix program would be OK with) by SSHing into a Windows box. It launched, but trying to run any commands - even exit - appeared to hang (though Ctrl+C worked to exit out of PS entirely). This may not be something that Microsoft needs the help of the OpenSSH devs to fix, but it's something that needs to be fixed, regardless. If people can SSH into Powershell, then Powershell needs to be able to display to whatever console they're SSHing from.
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.
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.
Slashdot Mirror
XP, being NT, still has the POSIX subsystem. It probably still works with NetBSD's pkgsrc, too.
Also, it's not so useless as you claim; Microsoft themselves used it internally for years to host Hotmail, and right up until Win8.1 it was a viable alternative to Cygwin for anybody with a compatible version of Windows (or who wanted to force it to run anyhow). It handles/handled some things, such as SetUID/SetGID, which Cygwin couldn't (and I believe still can't) emulate, supported case-sensitivity on NTFS (though this could be used to confuse the hell out of Win32 programs), had a couple of different choices of package managers available, and could compile and run most source code intended for *nix systems (third-party compatibility layers added support for some of Linux's extensions to POSIX).
BZZZZT try again. Chrome used (and still uses) its own JS engine, distinct from the built-in JS support in WebKit. Apple didn't let them do that on iOS; they had to use the JS engine that runs in the WebKit that is used in the webview widget, no exceptions. Until a recent iOS version (8, I believe), that WebKit build didn't even use JIT-compiled JavaScript, so it was always a lot slower than Safari.
The JS engine (including both its performance and its behavior) is a hugely important part of a modern browser. By that standard, Chrome-on-iOS definitely wasn't the same thing as Chrome-on-PC.
That's not how HSTS preload works. Or rather, it is, but you're missing a vital step. The preload list won't accept sites that don't specify the "preload" flag in their Strict-Transport-Security header. It ought to go without saying that they won't accept sites which don't serve HTTPS at all...
The max-age and includeSubDomains directives are relevant to browsers. The preload directive is relevant to HSTS preload list maintainers (or rather, to their servers). I guess the government could try coercing the preload list maintainers into including the relevant .gov sites even if they don't meet the requirements for inclusion in the list, but I'm pretty sure that won't happen.
Space is really, *really* fucking big. Even low earth orbit at any given altitude is vast; it's literally larger than the surface of the planet. Add altitude shells to that - go up a few KM and you're now a few KM away from anything in the lower shell, even at closest point of approach - and there's an astonishing amount of room in space.
You wouldn't ask if there's room for 4000 more ships on the ocean, despite the fact that there's a lot less ocean and a lot more things crossing it vs. what we have in LEO. You wouldn't even ask if there's room for 4000 more cars on the road in the continental US, despite there being many orders of magnitude less space on US roads than there is in any given LEO altitude. Satellites, functional or not (including debris), move in predictable patterns, and functional satellites have thrusters that allow them to alter or maintain their course.
Agreed, of course, that the satellites should be capable of de-orbiting. But seriously, this "is there enough space in LEO?!?" meme is kind of dumb, at least right now. Let's assume you put each satellite in the middle of 20x20 KM non-overlapping exclusionary zone (omitting the third dimension for now). 400 KM^2 per bird. 1,600,000 KM^2 total. Sounds big, right? You could fit that entire collection, with a hundred thousand square KM left over, into Alaska. Don't get me wrong, Alaska is a big place, but it's not *that* big on the world scale. That's all in one orbital shell.
Well, MS isn't always the fastest on rolling out security features. Somebody else may need to lead the way. If the Mozilla foundation releases HSTS for Firefox 1.0, it might be possible to persuade MS to do the same for their similarly-aged browser...
SRP has a number of problems, the most notable being that there's no way to securely *distribute* (or create) the password without falling back to some other TLS suite, or doing it out of band. This really limits the usefulness of SRP in a browser.
Additionally, I'm not sure how browser support for SRP is supposed to make phishing stop working. If the user still needs to enter their password somewhere, then the phishing attack just has to look like wherever they usually enter their password. Yes, an attacker intercepting the network traffic of a legitimate handshake won't be able to extract any useful info about the password (or be able to replay it blindly), but a phishing site that gets users to enter their password and then sends that password back to the (attacker's) server via whatever mechanism it cares to will still work just fine.
On the other hand, there are definitely places that I'd like to see SRP deployed. A key one, which I consider a lot more important than in browsers, would be as a replacement for NTLM hashes (which are antique and terrible) in SMB (Windows networking, Samba, etc.) traffic. It also makes sense for things like remote desktop or ssh (where, at least for password auth, you assume that both sides already know the password so the distribution problem is taken care of). Once you have it in those places, putting it in the browser seems reasonable enough - after all, enterprises do use IE's built-in support for NTLM auth to web servers, which sucks about as much as NTLM for SMB - but I'd put the other areas ahead of the browser.
On the one hand, you're kind of wrong; any site that wants to can opt into the HSTS preload list, and IE uses the same preload list that both Chrome, Safari, and Firefox use. The preload list, by the way, is not a "whitelist" in the usual sense; it simply has the effect of there having been a "zeroth visit" before the first visit, so the first visit is safe. After that, the site behaves as normal.
On the other hand, it is true that getfirefox.com doesn't support HSTS at all (much less appear in the preload list, which would reject it anyhow for failing to have the response header present). Worse, though, mozilla.org doesn't seem to support it! At least, the Chrome dev tools don't list the Strict-Transport-Security header in responses from the site. That is a bizarre (and, frankly, unwise) omission.
The Internet was a very different place 15 years ago! Also, satellites were less advanced, bandwidth demand was lower, launch costs were higher, and Elon Musk wasn't behind the project.
OpenSSH has been ported to Windows a number of times. Off the top of my head:
* Interix (POSIX subsystem running on native NT, but still technically Windows) has at least one version of OpenSSH (server and client).
* Cygwin (emulates Unix on Win32) has OpenSSH, (server and client).
* MSYS (a set of Unix tools ported to Win32 via MinGW) has OpenSSH (client for sure - it's installed with Git for Windows - not sure about server).
None of those are terribly well integrated with Windows' way of doing things, though. Sometimes that's a good thing - I can take my .ssh folder from a Linux box, drop it on a Windows system, and it'll work with the things listed above - but it also means that (for example) the public key used when SSHing into my Windows box is completely unrelated to the public key used when RDPing into the same box. That's silly.
Does the OpenSSH license prevent making the code proprietary? I'd have guessed it was under a BSD license, which permits closed-source derived works.
Indeed. I expect one of the things they'll be looking at doing is adding support for some of Windows' built-in authentication options. For example, recent versions of RDP use machine certificates, typically with a trust-on-first-use model similar to SSH. It would be nice if SSHing into a Windows box could re-use that machine cert, and SSHing from a Windows box could take advantage of the list of IP+cert pairs that you already trust. This would require some code changes to OpenSSH though, since it is of course currently utterly unaware of Windows' certificate stores.
Also, powershell isn't really used to displaying to anything except Windows consoles. Just for the hell of it, I tried running it in xterm (which, while antique, any *nix program would be OK with) by SSHing into a Windows box. It launched, but trying to run any commands - even exit - appeared to hang (though Ctrl+C worked to exit out of PS entirely). This may not be something that Microsoft needs the help of the OpenSSH devs to fix, but it's something that needs to be fixed, regardless. If people can SSH into Powershell, then Powershell needs to be able to display to whatever console they're SSHing from.
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.
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.
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.