You have this creditcard. It works in the mall, it works at the cinema. You go somewhere where you know your brother/friend/whatever also has a creditcard that also works in the obvious places. Do you remember to call the credit card company?

What if the bad guys manage to find your account details at a badly protected webshop? They call the creditcard company saying you'll e doing a few purchases across the country (or abroad). Try it once or twice to see what the creditcard company asks to verify it's you, and most likely the crooks will be able to prepare that information.

have a great deal of respect for you

Sorry, I should have made it more obvious that I was writing tongue in cheek about the monarchy. Not about SpaceX though. I'm pretty impressed.

It doesn't work to do this with a democratic government. We need a monarchy :-(

It seems to me that SpaceX is on the path to a solution that might be affordable by a single administration, though.

This doesn't fix the problem. It makes the chances of exploitation a bit smaller, on a "per-try" basis.

Back in the old days, some daemons or setuid programs would do insecure things with /tmp. So the hacker would make a program:
target = "/tmp/somefile";
while (1) {
      unlink (target);
      link ("/etc/passwd", target);
      unlink (target);
      link ("/tmp/myfile", target);
}
The daemon would check access permissions of the "target", hopefully after the last line in the loop, then open and write the target, hopefully after the second line inside the loop. Leave this running, trigger the target app, and you get the target app to write somewhere where it shouldn't (in this case /etc/passwd. Get it to add "\nmyroot::0:0::::\n" to make the system allow you to login as root without a password....)

The same applies to this stack/compiler randomization tricks: The hacker first tries at a slow pace, but instead of hacking your system, fails to get in because he's crashing your service deamon. You notice your service going down every day or so. Buggy software. Stupid randomization! No time to fix, and you make the daemon restart automatically. And bingo! Now the hacker can try thousands of times!

In cryptography, care has been taken that you can't figure out one of the "bits" of the key by a simple search. So that the exponential search (find the key among 2^256 possible keys) does not become "256 times: find bit n". To guarantee that no "bit leaking" will happen in a buggy program is very, very difficult: The designers of the program don't know where the bug is, the compiler doesn't know where the bug is, but the attacker does!

So... if this goes mainstream, the hackers will find a way to extract little bits of knowledge of the randomization, determine what the actual randomization was, and then attack the service as usual.

Of course, there will be cases where say: the time for the attack is increased beyond the attack-detection-time. So instead of the attack being succesful, the attack might be detected and averted.

Anyway, I much rather have something that actually WORKS instead of "has a chance of working". But maybe that's just me.

As this is from a western company (HP), I expect such technical claims to be reasonably reliable. They claim 1024x768 resolution, which is 100% correct. For something less easy to measure (for me), if they claim 2000 ANSI-lumen, I expect at least say 1800, with the "excuse" something like: we put it on the "boost" setting for that measurement (and then decided not to put it in the final product because it reduces lamp-life a lot).

I decided 15 years ago when I bought my DLP projector that I wouldn't settle for less than 2000 Lumen. Back then this was an expensive "restriction". But 75????

Daniel phillips, where have I heard that name before? It was in the last few days.... :-) Ah! :-)

To be taken serously, the home page needs to mention something more recent than 2008 in the "on the web" section. And the "we're active, see the git log" link needs to point somewhere other than a 404....

If Boeing was interested in getting people into space, more than a handful of them would be there. The fact is that it has taken a company that was outside of the system, with a tiny fraction of Boeing's funding, to make more progress than Boeing has.

185TB is the uncompressed size, as noted in the last word of the summary.

And of course it's in the U.S. interest to make sure the Russians have an active and completely up-to-date source of rocket engines for their nuclear missles.

In this vein, I wonder what it is we are paying the Chinese to do?

I think we need to take a serious look at the "many eyes" theory because of this. Apparently, there were no eyes on the part of parties that did not wish to exploit the bug for close to two years. And wasn't there just a professional audit by Red Hat that caught another bug, but not this one?

I have to say I'm even less confident in the plan to couple it to DNSSEC.

Sure. We're better. But we need to be even better than that.

I'd say more than just the "community". We have a great many companies that incorporate this software and generate billions from the sales of applications or services incorporating it, without returning anything to its maintenance.I think it's a sensible thing to ask Intuit, for example: "What did you pay to help maintain OpenSSL?". And then go down the list of companies.