Well, let's see what statistics has to say.

I ignored failures of the payload, non-propulsion systems, or any failures where I could not identify which stage failed. Failures of staging mechanisms were rounded up to the higher stage. Flights with missing stages were still counted. All variants of each rocket family were included - Soyuz includes R7 launches, Thor/Delta includes Japanese licensed derivatives.

Soyuz: 25 first-stage failures, 18 second-stage failures, 29 third-stage failures
Proton: 9 first-stage failures, 11 second-stage failures, 17 third-stage failures
Ariane: 4 first-stage failures, 0 second-stage failures, 4 third-stage failures
Thor/Delta: 5 booster failures, 22 first-stage failures, 16 second-stage failures, 11 third-stage failures

Soyuz and Thor racked up a lot of early failures of the first stage, which seems attributable to simple inexperience (each had one failure from failing to fill the fuel tanks before launch). Even compensating for that, it seems the first stage is a dangerous stage, prone to failure.

However, your statement seems to bear out - the third stage does seem disproportionately dangerous. Oddly, it often seems to be control of the third stage that fails, not always the rocket itself.

The Proton rocket has gone through a number of redesigns over its long life. The latest version, the Proton-M, first flew in 2001, and they kept flying the Proton-K for many years (for reasons I actually don't know). They've only done 90 flights of the Proton-M, and half of them were in that post-2010 period of "repeated failures" (although they had about as many failures for pretty much all of the 2000s as well).

I would highly expect the faulty pump to have been redesigned with the Proton-M modifications, based simply on that analysis.

Okay, I know it's probably the least important thing about the craft, but still...

Why are they using such an ancient, decrepit-ass rocket motor? The AR2-3 is incredibly old - it dates back to a Gemini-era trainer, basically a modded F-104 that NASA used for early tests and training for spaceflight. It was made back when rocket chemistry was still in the "even the experts don't know much" stage, so it burned jet fuel and high-test peroxide (90%+ H2O2 in H2O).

Jet fuel is not good for rockets - basically, the restrictions on what compounds can be present is fine for jet engines, but leads to horrible problems with rockets. There's a specific petroleum-product blend designed for rockets, called RP-1, which clamps down on things like sulfur compounds or alkenes that love to gum up the works. This rocket was originally used on a jet fighter and shared fuel with it, so that was understandable... but the USAF recertified the engine for modern JP-8 instead of the old JP-4. So they already went through the effort of making it work with a new but similar fuel. Unless the X-37 hides a jet engine on itself somewhere, I don't see why they couldn't have used RP-1 instead.

Further, rocket science moved away from peroxide for a reason - it's dangerous. It will explode for basically any reason - peroxide decomposes exothermically, so once it starts reverting to H2O + O2, it's nearly impossible to stop. And it reacts with tankage surprisingly often. Oh, and it does horrible things to your specific impulse, which really hurts you on a last-stage engine like this one.

Honestly, using the engine at all is a weird choice. Sure, maybe they had some laying around... from the sixties... but that's like putting an F-104 engine in a prototype aircraft, it just doesn't seem right when other off-the-shelf systems work better. An AJ-10 would have worked beautifully. An RL10 might not have fit the aero package (hydrogen is a bulky fuel), but would have given them some impressive dV if they wanted it. Aestus would be a perfect match as well, if they didn't mind outsourcing to the Euros. Even Kestrel would work (although it first flew around the same time as this, so understandable not to use it). Point is, they had options, and being the Air Force, they could easily have just had an engine custom-made for it if they so wanted.

So what are the implications? All I can think of is a) they don't care how badly the rocket performs, b) they probably aren't going to keep that engine in whatever "production" version they build, or c) they have some other reason to use peroxide or JP8. Maybe peroxide is also their monoprop for RCS? That isn't really worth it though, particularly when UDMH works better as RCS and in the main motor.

Do you understand the difference between "has to be" and "can be"?

Steam is in charge of downloading and installing the game. After that, you can launch it directly.

If, and only if, the game was coded to additionally use Steam's DRM features, it will then check that Steam is running and attempt to authenticate (which can be as simple as the local Steam instance having a cached authentication).

If it doesn't use Steam's DRM, it will just run as a regular old executable. Steam does not mandate ANY DRM, it only mandates that if you use non-Steam DRM, you have to make a note of it on your store page.

I have dozens of games bought and downloaded on Steam that do not touch Steam's DRM. I've actually copied some of them over to other computers and had it still work without Steam even being installed.

Rust is not yet production-usable. It has enough known bugs in the tracker that I can't even contemplate using it for a personal project, let alone for real.

And yet they're already pushing the marketing, proclaiming it as a guaranteed C-killer. I'm sorry, but they've said that about every compiled language since C, and it hasn't been true for one of them. And you're pushing it this hard, when you're still this early along in development?

Nobody uses C or C++ because they love the language. They use it because it has all the tools they need to debug, and all the libraries they need to run, and all the performance they need for the task. Rust maybe has the last one, but only has the second by being C-compatible (defeating the purpose of using a new language, particularly when you have to write this much wrapper code around it) and has none of infrastructure needed for large modern projects.

Dear Rust devs: stop writing articles about how great Rust will be, and start writing stuff to make your language actually usable. Maybe then people with their heads outside their asses will listen to you.

Steam itself doesn't universally apply DRM - a large number of games on Steam don't have DRM at all, you can just copy the files to wherever you want and run them.

They do offer their own DRM, which is about as non-intrusive as you can get while still being DRM, and they allow publishers to include their own DRM as long as it is noted on the store page. You can be mad about games using DRM, but Valve isn't the one to be angry at.

PS: Valve's talked about issuing a patch to disable the DRM if they ever go out of business. Realistically that probably won't happen (too many licensing problems), but the DRM is trivially bypassed as long as you have the game downloaded already, so they really can't stop it.

Sadly, their brags of "only five years behind" is an underestimate. It's a 65nm chip - its heyday was 2006-2007, on tail-end Pentium IVs, early Core 2, and Phenoms. 45nm hit in 2008, followed by 32nm in 2010. In 2012 Intel hit 22nm, but most others were on a 28nm half-node. Currently, 14nm is shipping from some vendors, and the rest are gearing up for it.

Account for the fact that these chips most likely won't actually be delivered until 2016, and you'll see they're really 10 years behind, not 5. That will probably still be fine for desktops or industrial use, but mobile is out, and servers will be very inefficient compared to modern ones.

SpaceX is getting some of the benefits of skipping the LAS, by using the same system for at least two tasks.

The primary use is as a propulsive landing system. That's probably the main way they'll be used. There's a backup parachute system, but they want powered landings to be the norm.

The secondary use is as an abort engine. It'll probably be rarely used, and I think it uses up all the fuel so an aborted launch will have to use parachutes, which will make for rougher landings but still plenty survivable. This way, they won't be carrying fuel that isn't used in some way during the flight.

A third possible use is as an in-flight maneuvering system. This is mostly done using the smaller Draco engines, not the big SuperDracos, but they run off the same fuel supply and are mounted in the same pod. But if they ever need to do significant orbital maneuvers, I expect they'll light up the SuperDracos.

Because they're trying something new with it. They're using the same set of engines for emergency escape as they are for propulsive landing of the capsule. That's fairly innovative in and of itself, and the changes required for that (side rockets instead of a top-mounted tower) let it also be used for a longer period of the flight.

As always, the answer is "it depends on a lot of things":

1. Is the language little-used because it's a special-purpose language? UnrealScript probably doesn't crack the top twenty as far as general programming languages go, but in the game dev field it's probably one of the biggest. Using a specialized language for a specialized task is fine - usually even a good thing.

2. Is the language little-used, but library-compatible with a more common language? Clojure is a rare language, but it can call Java libraries and code, which is a massive boon. Actual programming languages don't matter so much as the libraries they allow you to use, and if you can piggyback on a bigger library of libraries, you can go far with a small, obscure language. This isn't sufficient to make the language OK to use, because:

3. Is the project going to be worked on by more than one person? Personal projects, sure, use whatever language you feel like. Small groups can decide what to use. But if it's a big project that's likely to cycle through developers, think about the impact using an uncommon language will have.

4. Is there something about your problem that makes common languages inefficient or ineffective? Is the uncommon language objectively better at the exact task you're solving? Or is it just "the syntax is slightly cleaner"? This isn't a full deciding factor, but unless the language shows promise as being useful in the future, I wouldn't use it on a personal project.

Any chance Comcast will look at where their customers now lie, decide they're now an ISP with a side business in TV rather than a cable company with a side job in internet, and stop raping the quality of their internet to drive customers towards their cable offerings, and give up on those silly plans to become a competitor to Netflix et al. because they feel lonely without the ability to cram their own ads into something that's already overladen with advertising?

No chance? Didn't think so.

Weird, I'm a 90's kid and:
I haven't touched my Facebook account in years
My Twitter is mostly subscriptions, generally to things that are actually interesting (eg. @RealTimeWWII not @kanye)
I have no Instagram
I've never actually heard of Opentable
I've taken one selfie in my life, and it was a joke at my sister's wedding

I also used MS-DOS (via Windows 95, sure, but it still counts), think Perl is a more useful language than Ruby or any other fad-language-of-the-week, and I can read assembler if given enough time and a table of opcodes.

Do I still qualify as a Digital Native?

I was thinking just that - creating a USB device that takes input from one port, and simulates a mouse on the other, is pretty trivial.

The only excuse for having less than four should be having too many other ports present to physically fit them all.

Every current Intel mobile chipset provides at least four USB3 ports, and most provide six. The only acceptable reason not to have at least four is "between all these video outputs, audio outputs, Thunderbolt port, and SD card reader, there just wasn't room for all four USB ports".

The physical USB port costs basically nothing. You can get them for ten cents apiece on Amazon - I'm sure buying in lots of thousands instead of twenty will bring that down even further. Going above what the chipset provides adds an expense, of course, but 4-6 USB ports is enough. I just don't see a reason not to populate all of them with a physical port.

* Last-minute addition: another reasonable excuse is "we routed the USB port internally to the Bluetooth and Wifi adapters". Some motherboards do things that way, and that is indeed a reasonable excuse for having only two USB ports, if using a chipset with only four USB ports. But I would argue that if you know two ports will be used internally, you should probably spring for a 6-port chipset, particularly since only the cheapest limit to four.

Valve and Bethesda made numerous mistakes with this implementation, but I still consider it a good idea. I'm definitely planning to allow paid mods in my own games, if I ever get one ready for retail. But here's where they went wrong.

1) They set a minimum price far too high. Relatively few mods are worth a dollar, even the ones that are worth buying at all. Give supply and demand a free hand to set prices, and I think most average-sized mods would have been priced around $0.20. Some might have been able to sell at a much higher rate, but not many.

2) They didn't protect from fraud. As soon as the announcement hit, people started uploading mods they didn't make - there was already a massive corpus of free mods, after all, and basically no protection against this. The least they could have done is give a decent warning period, for mod authors to decide whether to start selling their mods or not, and to search for fake versions being uploaded without their consent. They didn't do that, and they definitely didn't do any sort of technical measures, like comparing uploaded mods' checksums against those already uploaded. All of that is easily foreseeable because I actually foresaw it - I've been planning how to do this in my own games, and all of that was on my list before they even announced their feature.

3) They didn't share the profit well. Valve was taking a 30% cut, which is already more than they do for full games, and then Zenimax was taking another 40%. I can see that, because the base game does a non-trivial amount of work for the mod, that they do deserve some compensation (although I'd say increased sales are the true payment to the publisher). But a cumulative 70% is just ridiculous. I'd argue that no less than 50% should go to the modder. For my own games with paid mods, I'm thinking more in the 75:25 or 90:10 range, or even 100% to the modder (because, after all, a vibrant modding community brings about more sales, so the marginal loss on hosting is more than recovered).

4) They launched it suddenly, with no notice. Nobody had any inkling it was coming, least of all the modders who would be most affected by it. Valve and Zenimax should have given at least the big-name modders some heads-up, so they could think and have time to rationally decide whether to start selling, and for how much, and to work out any licensing issues in multi-person teams. And perhaps if gamers had been able to see it coming, they could have realized it was a good thing, instead of letting the knee-jerk reaction control the debate.

They did, however, do one thing surprisingly right, which deserves recognition: they gave full, automatic refunds within 24 hours of purchase on any mod you didn't like. That's definitely something necessary, and something very surprising to see from Valve.

Hopefully they can sort out these issues with the next game they try this on, instead of giving up on what is an excellent idea.