That's not the new Microsoft, that's the Microsoft of the last decade.

Also consider that in most markets, Windows Phone is closer in phone marketshare to iOS than iOS is to Android. That's not saying a lot. But WP is definitely at the #3 spot, and the way this market is... if they can find that itch to scratch, things could change within the course of two or three years.

Which is like bragging about Pluto because it's closer to the Sun than to Proxima Centauri.

Third place in the mobile market is a dubious distinction, at best. In reality, Windows phones are irrelevant, but only slightly less irrelevant than, say, BlackBerry.

I find this an interesting statement. Running the numbers, I find that you'd have to be using a rocket burning something rather better than H2/O2 (we're talking Isp >500 just to reach escape speed, much less to reach the target rock) to allow two launches of a delta-IV heavy.

Huh?

The fact that a Delta-IV Heavy has a LEO payload of over 27 tonnes is a fact. You don't need to "run the numbers". As for the kick stage, I didn't specify a propulsion system - for all we care (since we haven't established a timeframe), it could be an ion drive and not even take a rocket so large as a Delta IV-Heavy.

Meanwhile, the Falcon Heavy is to make its first launch this year, with double the payload of a Delta IV-Heavy. And as was mentioned, the Tsar Bomba was not optimized to be as lightweight as possible.

And this entirely ignores that noone actually has a Tsar Bomba sized nuke available to be detonated.

Oh, and you didn't allow for a backup

It's almost as if I didn't add "with enough advance warning" for that scenario and leave what "enough advance warning" is unspecified. But if there's another rock the size of the Chicxulub impactor out there and we don't see it until the last second, we deserve to get hit - we're no longer talking about a 50 meter spec (Tunguska-sized), rather a rock with a cross section 30% bigger than the island of Manhattan. We're talking about an impact of a scale that happens once every hundred million years or so.

A more appopriate version of the BBC's article:

---------------
OMG - matti makkonen .fi sms pioneer dead!!!
---------------
WTF - mm just died @63! #txtpioneerdeath was father of sms & dvlped idea of txt msg with phones. @2012 msged BBC that txt would be here "4EVR".
--------------
shoutout 2 Nokia for spreading sms w/Nokia 2010. thought txt good 4 language. was btw mng. director of Finnet ltd and "grand old man" & rly obsessed with tech.
--------------
OMFG people!

It is not only possible, but the easiest option, to "blow them up Armageddon style" (minus the drilling and the like). There's a lot of simulation work going on right now and the results have been consistently encouraging that even a small nuclear weapon could obliterate quite a large asteroid into little fragments that won't re-coalesce, while simultaneously kicking them out of their current orbit. A few years ago they were just doing 2d calcs, now they've gotten full 3d runs.

Think for a second about what nuclear weapons can do on Earth. Here's the crater of a 100kt nuclear weapon test. It's 100 meters deep and 320 meters wide. You could nearly fit a sizeable asteroid like Itokawa inside the hole. And that thing had Earth's intense gravity field working against it and was only 1/10th the size of weapons being considered here. In space you don't need to "blast out" debris with great force like on Earth, you merely need to give it a fractional meter-per-second kick and it's no longer gravitationally bound. And the ability of a nuclear shockwave to shatter rock is almost unthinkably powerful - just ignoring that many if not most asteroids are rubble piles and thus come already pre-shattered. Look at the "rubble chimneys" kicked up by even small nuclear blasts several kilometers underground (in rock compressed by Earth's gravity). Or the size of the underground cavity created by the wimpy 3kT Gnome blast - 28000 cubic meters. Just ignoring that it had to do that, again, working against Earth's compression deep underground, if you scale that up to a 1MT warhead the cavity would be the size of Itokawa itself.

You of course don't have to destroy an asteroid if you don't want to - nuclear weapons can also gently kick them off their path. Again, you're depositing energy in the form of X-rays into the surface of the asteroid on one side. If it's a tremendous amount of energy, you create a powerful shattering shockwave moving throughout the body of the asteroid. If it's lesser, however, you're simply creating a broad planar gas/plasma/dust jet across the asteroid, turning that whole side into one gigantic thruster that will keep pushing and kicking off matter until it cools down.

The last detail is that nuclear weapons are just so simple of a solution. There's no elaborate spacecraft design and testing program needed - you have an already extant, already-built device which is designed to endure launch G-forces / vibrations and tolerate the vacuum of space, and you simply need to get it "near" your target - the sort of navigation that pretty much every space mission we've launched in the past several decades has managed. In terms of mission design simplicity, pretty much nothing except kinetic impactors (which are far less powerful) comes close, and even then it's a tossup. Assuming roughly linear scaling with the simulations done thusfar, with enough advance warning, even a Chicxulub-scale impactor could be deflected / destroyed with a Tsar Bomba-sized device with a uranium tamper. Even though it was not designed to be light for space operations, its 27-tonne weight could be launched to LEO by a single Delta-IV Heavy and hauled off to intercept by a second launch vehicle.

Uber drivers are subsidized by everybody else. Taxi drivers have to pay high insurance rates because the act of driving a long distance every day for a ton of strangers is a job that inherently leads to a much higher statistical rate of payouts. If they're driving as a taxi on regular car insurance, it's you that's paying the bill for their swindle of the insurance system.

Because moving from one proprietary language/library ecosystem to another proprietary language/library ecosystem is somehow an improvement.

Fuck them both. We have truly open ecosystems like C++, and I would encourage any sensible developer going forward to move away from the likes of Java and the .NET ecosystems, now that the Supreme Court has essentially turned them into perpetual litigation machines.

But cleanroom implementations are meaningless if copyright can be asserted over the API. Clean room implementations only work because it has been generally understood that an API itself is essentially a directory listing, like a phone book, that in and of itself does not constitute some sort of creative work. Before the Oracle case, it was assumed that it was the code itself that constituted the intellectual property. But that is now apparently no longer true, and thus the Win32 API has gained the same level of protection as the source code.

If this stands, and is not corrected either by a lower court or by Congress, no one will every try a clean room implementation of any non-free library again, because there's a real likelihood that you would find yourself sued into oblivion for breach of copyright.

Wine may be safe because MS is being constrained by future potential anti-competitive suits, and of course Samba is protected because of a deal cut with the EU. But from this day foreward, clean room implementation of proprietary APIs, and I assume any other software spec (document format, communications protocol, etc.) will have absolutely no protection under the law.

Yeah, wouldn't that be great if I had linked it in my first post, and then if you had actually read my post well enough to see it?

Would you contribute to a future project like Samba or Wine now?

It certainly is looking that way, but there is the whole notion that what amount to call tables can be copyrighted. What the supreme Court has done here is basically unravel the common understanding of the difference between spec and implementation, and if Java is the most obviously vulnerable, in a very real way it means any number of APIs that have been re-implemented (like the standard *nix set of system calls) could suddenly be plunged into a purgatory-like nether world. I made vulgar jokes about using stdio.h in C programs, but that's the real question. Considering that in many cases header files and libraries whose origins go back decades in many different languages and on many different architectures could become low-hanging fruit, and since copyrights are in most industrialized countries are essentially perpetual now, big software houses now have a far better club to beat competitors with than patents.

Do you think another Samba or Wine project could happen if the lower courts rule for Oracle? Who would be crazy enough to even try?

Fucking hell, I guess I'm utterly fucked, because pretty much every C program I've ever written includes #include <stdio>. Here I thought I was invoking a free and open set of library functions passed on down since the 1970s, and now it turns out I've been stealing someone's hard work in creating a standard set of functional calls. I'm dirty fucking thief.

If specifications alone can be copyrighted, then the software industry is in for a world of hurt.

A function name and parameter spec is now "someone's shit"? Oracle's position is about as sensible as SCO's was.

All the early games I played were very "crunchy"; D&D, AD&D, Palladium, Twilight 2000 and Traveler 2300. The inelegance of such systems really began to drive me nuts, and I ended up going with Fudge and its variants like Fate. I never really played Gurps very much, but as I recall it was the middle ground between the kind of ultra-loose systems like Fudge and the very complex systems like AD&D. Now, I run a couple of PBeMs; a Palladium Rifts one and a home-brew heavily narrative game in the Harn universe, and dice are rarely used in the Palladium game, and not even part of the Harn game