I'm going to assume you've been doing the /. equivalent of living under a rock, since this question comes up (and gets answered) every single time this topic is discussed, and that's a lot. But what the hell...

Landing on solid ground is, generally, preferable. However, unlike the ocean where you can tell all the boats to get out of a safety zone, land has these inconvenient things like buildings and infrastructure that can't simply be told to stay away for their own safety. Until it was clear how precisely SpaceX could bring the rocket down - and remember, we're talking about something returning from the edge of space, at supersonic speeds, with barely any fuel remaining, in a maneuver that had never been attempted before - it would have been foolish to bring the rocket down anywhere near any inhabited regions. Given the geography around the launch sites they use, that means the ocean is the best bet by far.

Also, sometimes they may not have a choice. The rocket *really* doesn't have a lot of fuel left as it returns, and it's going really, really fast in a direction that is decidedly away from the launch site (but not fast enough to make it all the way around the world, or the second stage wouldn't be needed to actually achieve orbital velocity). SpaceX pulls a lot of cool tricks to guide the rocket's return, like using the stage as a lifting surface (with a truly abysmal lift/drag ratio, I assume, but they're also trying to scrub speed) while controlling it with little folding grid fins (which are quite effective at those speeds). However, at the end of the day, even Falcon 9 may not have the fuel margin to return to the spaceport after launches even though it has enough fuel to launch *somewhere*. The center core of the Falcon Heavy - which flies for much longer than the F9 first stage - will be much too far downrange to boost back to the spaceport in most cases. Thus, for FH's center core, the barge may be the only landing option. Landing on a ship may be harder than landing at a conventional spaceport, but the ship can be almost anywhere there's ocean, while land-based spaceports are not noted for their mobility.

Now, with all that said, the goal is to, eventually, be able to land at the spaceport. The next F9 launch after this one will, according to a cool site called SpaceX Stats, attempt to return to the launch site and land there. This presumably demonstrates that SpaceX has been found to have sufficient precision in the first-stage landing attempts so far for it to be safe to land near people and expensive buildings. I wish them the very best of luck!

Oh look, somebody else who apparently doesn't understand how computers work. How do you expect to stop a program[me] from changing a setting in another program[me] when they both run under the same privileges? Chrome has to store its default search provider configuration somewhere. The Java installer can edit that "somewhere" and change the stored configuration. Even if Chrome stores its search configuration in "the cloud", the installer could just use Chrome's cached credentials to change the configuration there.

The only way to change this is if apps don't have the ability to interact with each other's data (something like the isolation/sandboxing used for mobile apps). Anything else, any setting that you (the user) can change, any software running on your behalf can change (whether you want it to or not). I'd expect readers of this site to be able to grasp that, but it keeps coming up so maybe not...

Yeah, the limiting it to only the highest editions of Windows was stupid. It was in XP Pro, and in all editions of Server, but in anything non-server with an Enterprise or Ultimate SKU, it was only in those editions. You could force it to run, in much the same way you can trick Home editions of Windows so they'll join a domain, but it was a hassle.

For what it's worth, Windows has a built-in grep alternative. Findstr.exe (in System32, so it's in the PATH) has slightly different syntax than grep, but it's generally not too hard to switch between them. Windows also has, and has had since DOS, more (it's actually still called more.com, though it's a full 32-bit or 64-bit Windows application), but it's grossly inferior to the options on anything *nix-like.

No equivalents of tail, sed, ssh, curl, whois, etc. or of course *nix shells (Powershell has some cool tricks but it's not the same thing) without installing recompiled versions, though, and those usually don't work as well anyhow.

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.