I started programming in C++ in '89. Templates were still new, but most of the language was stable. C++ code I wrote in '89 is still readable and compilable today. I know people who started with C++ in 1981, when it was still Bjarne's skunkworks project. The first public release was '83, making C++ 33 years old -- closer to 40 years old than 25.

(I'm the AC who originally posted; I wasn't logged in then.)

But it's nice to know they somewhat cater for the Liberians, the USAmericans and the rest of the world.

Oddly enough, a .30-06 is only called 7.62x63mm. That's the metricified name for it... but not the actual dimensions of the round: the bullet diameter is 7.8mm, not 7.62mm.

Cartridge names look like they're dimensional quantities, but they're not, and really never have been. The .38 Special and the .357 Magnum fire the same size of bullet. (In fact, you can fire .38 Special from .357 Magnum revolvers.) The German-designed 7.65mm Parabellum cartridge actually fires bullets 7.85mm in size. The Russian 9mm Makarov is actually 9.2mm. The 9mm Parabellum and 9mm Short fire different sizes of bullets, too; one is true 9mm and the other is smidge larger.

Moral of the story: the name is just a name -- it doesn't actually reflect the size of the cartridge, and for that reason there's no reason to prefer metricified names.

Tell that to Chief Justice Rutledge, who was appointed in a recess only to have it yanked away from him when Congress returned to session and said "no".

And in fact, we've had Chief Justices named by recess appointments. Chief Justice Rutledge comes to mind...

Justice John Rutledge (September 26, 1789 – March 4, 1791) was succeeded by Justice Thomas Johnson (August 5, 1792 – January 16, 1793). That's a 17-month gap. IIRC there are other, longer gaps.

Not true: SCOTUS has had two-year gaps before. The longest delay from the time a new justice is nominated is 125 days, but sometimes the USG has taken a damned long time nominating a replacement...

It's clickbait and self-promotion.

Clickbait, no: there's actual, real, high-quality content to what he writes.

Self-promotion: so what? If someone writes something interesting and informative, I want it to be brought to my attention -- even if they're the ones to bring it to my attention.

One, the spec is positively Byzantine. It makes OpenPGP look like a marvel of clarity. It's a very hard spec to implement correctly, and for that reason I distrust most of the S/MIME out there.

Two, S/MIME has some hardwired dependencies on SHA-1. (So does OpenPGP; S/MIME has more of them.) SHA-1 isn't looking very healthy right now. OpenPGP is migrating away from SHA-1 and the working group is actively developing a new spec. The S/MIME community isn't.

The biggest problem with OpenPGP is that it doesn't protect the metadata.

It's about to. :)

Daniel Kahn Gillmor had a novel idea for how to use PGP/MIME in a creative way to extend protection to virtually all the email header information. Enigmail is implementing this, as are a few other groups. Metadata protection is coming to OpenPGP -- and very soon!

Enjoy!

• Secrecy, flagging, and paranoia: adoption criteria in encrypted email
• How to make secure email easier to use
• Why Johnny Can't Encrypt and Why Johnny Still Can't Encrypt
• Views, reactions, and impact of digitally-signed mail in e-commerce
• Usability of security: a case study

Quoting myself:

And some people -- idiots who don't understand that optimizing one of these may necessarily mean pessimizing another -- smile and say, "Yes!"

You're one of those idiots: I get it. But so long as you're saying "improve everything!" I'm going to ignore you, because some of these things are incompatible.

Yes and no, but mostly no. (ObDisclosure: I help out with Enigmail.)

• Could we do better? Maybe. Probably. But first you'll have to define what "better" means. Some people say it means stronger crypto. Some say it means a simpler RFC. Some say it means a better user interface/user experience. And some people -- idiots who don't understand that optimizing one of these may necessarily mean pessimizing another -- smile and say, "Yes!" Honestly, when it comes to "we can do better" style criticism, my response is simple: I know we can do better -- but first you have to tell me what 'better' means.

• But that doesn't matter. When it comes to communications security the world is divided into two camps. The first one doesn't need it right now and the second one does. If you don't need communications security right now, that gives you a great amount of luxury to sit on the sidelines and wait for something better to come along. If you do, though ... then GnuPG and Enigmail are pretty much the best thing going right now, at least when it comes to email.

• Alternatives? What alternatives? The only alternative right now for email security is S/MIME, and that's far worse than OpenPGP. If you want to communicate using Silent Circle, go for it. Want to use OTR, be my guest. But if you need email security... "it's probably time to look into alternatives" is the kind of advice that sounds good only until you realize just how few alternatives there are, or how lousy they are.

I'll be the first to agree that GnuPG is a usability nightmare. Absolutely. If you like I'll point you towards several references in the peer-reviewed literature that show why it's so bad. But when people start talking about alternatives, I want to know which alternatives they're suggesting; when people start talking about doing it better, I want to know what better means.

I didn't say it was proven. I said it was a result. We don't have a formal proof that P != NP, but find me a single practitioner who thinks we'll find a proof of P = NP.

At some level math works on the basis of consensus. Consensus determines whether we accept a proof or reject it for omitting an important step; consensus determines which axioms we accept to be true. And so far, the consensus seems to be "BQP != NP, just like P != NP."

But yes, we're going to keep looking for the proofs. :)

Depends on what you mean by proven. It's believed about as strongly as people believe P != NP. There's zero evidence BQP can address NP-Complete (or, for that matter, even interesting parts of NP), and a lot of good reasons to believe it can't. However, a proof has been as elusive as the P != NP proof -- another thing which pretty much every CS nerd agrees to be true, but it hasn't been rigorously proven yet.

Quantum computers cannot solve NP-Hard or NP-Complete problems -- at least, no faster than a classical computer. This is one of the most basic results in the field, and the author keeps on making hash of it. This article should not be taken seriously if it's rife with such basic errors.