...sounds like they got it!

"Currency of the Future". - Karl Hevacheck

They describe this in the signage on the eel tank at the New England Aquarium. They even have a "shock" meter - and they tell you when it is getting ready to shock, you will see some spaced-out low-intensity pulses before "the big one".

So from what I am guessing - they are referring to using the radioactive decay of the materials for true random number generation. This concept isn't new - the unpredictability of radioactive decay has been a know source of "truly random" numbers. The article infers that it could use this to generate a key that could be shared with an external authentication mechanism - but you could do this with any random number source. You'd think they would have mentioned something like "quantum entanglement between the weapon and the president" (which might have been interesting) - but no.

Mod Up. Exactly what I thought upon reading the OP.

I had this problem too. I simply use Comcast's SMTP servers to relay my messages from my own SMTP server. You are required to configure SSL-secured transport only, and required to use your Comcast credentials when sending message to the relay. In-turn, when Comcast passes the messages, the services [you mentioned] accept them, but they still are shown as coming from my servers.

You don't have to "use Comcast's mail service" - they just want to use Comcast as a way of providing some accountability as to where the email is coming from - as a way of limiting spam.

Won't somebody PLEASE think of the children!!

But then you'd need to reboot to load it, I'd assume.

I shutter to think of how this would impact the development/debug cycle of an otherwise simple device driver.

>>C++ can't guarantee a binary API from one > to the next

Oh, you mean like Linux does with Device Drivers...

Compressed is faster on the wire, but takes more CPU time to decompress. If I have a 100GbE network connection coming into a server - my network bandwidth might outpace my compute abilities.

That doesn't mean anything. Were you running on a 3GHz Ivy Bridge server, or a little PIC IoT device? How much CPU time did it take? How many did your application need/require? Did the net result of header decompression along with the easier parsing of the binary header take more or fewer CPU resources then the older uncompressed, ASCII header? etc..etc..etc..

I can't possibly envision ever making Facebook privy to ANY health issues whatsoever. They would gladly shill that information out for profit - undoubtibly why they're doing it. With something such as health issues which are so confidential, making Facebook privy to any of this would be absolutely terrible.

Seems like the efficiency you gain parsing the binary header would be lost with the need to first decompress it ;-)

Are you implying that the US Government overpays, spending money and managing projects in a wasteful or inefficient manner? I say good day to you sir!