[tc]

Knew before clicking that this was going to be about DJB having won.

Peter Gutmann definitely has the credibility to make this critique. But saying that DJB having won is more a vote against other crypto than a vote for Dan is like saying that Git having won is more a vote against other SCMs than a vote for Linus.

Well sure, you could say that. But that would rather understate Linus' substantial contribution to thinking about version control differently and better.

Similarly DJB has won because he led the way in thinking about the crypto problem correctly. Peter basically acknowledges the underlying facts here, but seems to not want to give Dan his due.

[panic]

Distributed version control wasn't Linus's idea. BitKeeper, Arch, Monotone and darcs did it first, and in some ways better. But they all had problems: BitKeeper was proprietary, Arch was baroque and difficult to use, and Monotone and darcs had poor performance (darcs egregiously so, with an unfortunately-easy-to-hit exponential-time edge case in their merging algorithm). Using Git was a vote against these systems. But there's also not as much of a DVCS monoculture: Bazaar and Mercurial are also used quite often, and could be adopted quickly if git were to implode for some reason.

[haberman]

Arch also had terrible performance. The primary objects that lived in repositories were changesets, which every client downloaded as .tgz files IIRC, and then replayed locally to reach the current state.

The primary innovation of both git and Mercurial was performance. Git is a highly optimized content-addressable database with version control built on top.

[ams6110]

Arch was baroque and difficult to use

More than git? I shudder at the thought.

[panic]

Well, just to give you a taste, here's an excerpt from "Revision Control with Arch: Introduction to Arch" in Linux Journal (http://www.linuxjournal.com/article/7671):

In Arch, a changeset is represented as a directory tree full of bookkeeping files, patches, new files and removed files. The best contribution technique is to create a changeset directory and then tar it up for delivery:

    $ tla changes -o ,,new-robot-comment
    $ tar czvf my-changes.tar.gz ,,new-robot-comment/

Arch ignores files beginning with two commas, an equal sign and a few other special characters. By using a ,, at the start of our changeset directory name, we avoid the annoyance of Arch complaining that our new directory doesn't exist in the archive. It is probably good practice to use your e-mail address or some other identifier in the tarball filename and changeset directory name.

[dave2000]

I thought it was just me. Anything more than the basic commands and I get confused and have to look it up. Git is certainly popular -perhaps for many it's the first version control system they've used-and is very fast, but would you say it's well designed from a user perspective?

[KingMob]

No, git is a UI disaster. Some of the complexity is necessary due to moving to a distributed model of version control, but most of it is lack of clarity in designing the CLI.

Is anyone who's used Mercurial able to comment on the UI differences?

[xorcist]

Bitkeeper was first among the DVCS's, but Linus had a hand in its design. McVoy intentionally designed something to fit the (decentralised) Linux development process. The adoption of Bitkeeper for Linux and subsequent discussions gave rise to the cambrian explosion of Arch(/TLA/Bzr), Monotone, Darcs etc in the early 00s.

The famous two weeks time off to write git was many years later, when tridge finally forced his hand to do it. I don't think it's quite right to say git was a vote against anything else (except maybe against C++, which would bring some maintenance problems in the kernel community).

[fanf2]

Arch dates from 2001 (https://en.wikipedia.org/wiki/GNU_arch#History_and_maintaine...) but Linux adopted Bitkeeper in 2002 (https://en.wikipedia.org/wiki/BitKeeper#License_concerns)

[wtbob]

I don't think it's so much about not wanting to give djb his due as wanting to point out that literally the rest of the industry is shamefully bad.

[mtgx]

That may be true, but I still think there's a negative undertone against DJB's crypto here, even if it's unintentional (if you're going to talk about a crypto monoculture, it may become inevitable to talk about DJB's work and its adoption).

However, I worry many (developers) will get the wrong message from this post: that they shouldn't use the new standards from DJB (even if they are clearly superior in every way), because that would "help create the monoculture".

Also look at how this post ends:

> So the (pending) Bernstein monoculture isn't necessarily a vote for Dan, it's more a vote against everything else.

So it's not a vote for Berstein that he got so much so right? If it's not a vote for DJB's work, then maybe he can point out what's wrong with it (other than everyone wanting to adopt it).

The post could've very well ended like this, and it would've been better for it:

> The impending monoculture (based around DJB's crypto) is showing us that we need simpler, more boring crypto everywhere, but it needs to come from other authors as well.

Something like that. He is after all arguing against non-boring crypto throughout the post, no? So that should've been his conclusion?

Maybe even add a little bit of "DJB has showed us the way - now it's time for others to pick up the torch and take it from here." But I imagine he wouldn't have gone that far.

[tptacek]

The author of this post is a cryptographer. The people who select ciphers for products are almost invariably not cryptographers. The idea that DJB crypto is selected simply because it is "clearly superior in every way" seems inaccurate.

In fact, I think it's comments like these that set people like Guttman off. If you pay enough attention to the people who select but don't design ciphers --- ie, non-cryptographer engineers --- you're starting to hear more and more of a drumbeat of "do whatever DJB says"; if you push those people to explain those decisions, you don't usually get good answers.

[CiPHPerCoder]

> If you pay enough attention to the people who select but don't design ciphers --- ie, non-cryptographer engineers --- you're starting to hear more and more of a drumbeat of "do whatever DJB says"; if you push those people to explain those decisions, you don't usually get good answers.

Sure. I like to call that condition "secure by default". Said engineers most often don't have a lot of knowledge and experience with cryptography, so they opt for the best option available. In a lot of cases, it's DJB's work. In other cases, it's someone who followed his example (e.g. the BLAKE(2) team).

Also, this might have had something to do with this shift towards the current situation:

https://gist.github.com/tqbf/be58d2d39690c3b366ad

> Use, in order of preference: (1) The Nacl/libsodium default

> If you can just use Nacl, use Nacl. You don't even have to care what Nacl does.

[tptacek]

I take your point, and the point of the sibling commenter. I just think Guttman is talking about a different kind of "DJB by default" phenomenon.

[CiPHPerCoder]

I think you're right.

[napoleond]

And yet, that drumbeat is probably a good thing. And perpetuated by people like you chanting "just use NaCl" every chance you get. So it's not super fair to pick on non-crypto geeks for accepting that easy truth.

[tptacek]

We're not talking about what library to use; we're talking about what algorithms go into standards.

[stcredzero]

But that would rather understate Linus' substantial contribution to thinking about version control differently and better.

That paradigm of version control existed previously. (Monticello in Smalltalk, for example.) However, Linus had the programming chops and name recognition to start it off down the road to what it is today.

[davidgerard]

Most important, I think, was a great big urgent real-life use case (Linux) to optimise git toward. That's why it's really good at managing a Linux-sized codebase.

(Most of what is annoying and difficult about git makes much more sense when you realise it was literally invented for Linus to handle his email, and anyone else having use for it is a serendipitious happenstance.)