D. J. Bernstein
aaronsw.com
aaronsw.com
Patches, you say? Well, I'm glad you really like source code, because that's exactly what you'll be dealing with to get all of this up and running. I've done it many times before manually and it takes around ten hours to do it.
While Aaron's point is that djb's code, vision and discipline are possibly unmatched (I concur on all counts), the software (principally qmail) is antiquated in the sense that nobody needs just that one part in order to run a semi-modern email system.
So, as you start downloading the .tgz for qmail and begin studying it like good campers, remember that this wonderful code is, by itself, not up to the job that it purports to serve.
-- Lots of love,
Someone who currently runs two qmail systems and will never go to the trouble of setting one up again
If no one can use your code, it doesn't matter how beautiful, well-thought-out, or well-written it is. Software exists for the purpose of being executed. If your project cannot be deployed with a reasonable amount of effort, it's worse than bad software, it's a waste of time.
That is bad too. If I had to pick between "secure + customizable but hard to setup" and "easy to set up, but is a one giant gaping security problem", I think I would rather have the first.
Software is about collaboration, like a relationship; one person shares their ideas (qmail), another shares his (your site's configuration), and both parties do better than the sum of their parts. Easy-to-install software that doesn't require thought or communication is a one-way conversation; nice in the short term, but not something you want to be with for the rest of your life.
You certainly should, but it isn't the coder's responsibility to make this possible. It's the language/system designer's.
Just because C doesn't let you deploy nicely has nothing to do with djb's ability to create beautifully architected code, which is what Aaron is praising. I'm sure djb could have written equally beautiful code in Squeak Smalltalk, and it would have been a breeze to deploy, but had no impact on how elegant the code itself was.
I'm merely expressing my belief that in code that is meant to be used in production, facilitation of deployment is part of the problem scope. This is especially so when proper deployment is critical (as is the case with a mail server for example.) If QMail make deployment more difficult than it could be, then that is a problem with QMail. It might be the result of a worthwhile trade off. It might be better than it's competitors. But it's still a problem.
"You suck for not doing enough work" is no way to treat someone giving you free software.
Unused potential is another name for waste.
This is exactly why I've been using Postfix (or, preferably, get Google or someone else to handle it for me).
Easy to install is a feature, and a pretty close cousin of the "shipping" feature.
DJBs software is interesting mostly from an academic perspective. In the real world, it's hard to justify using something else, when apt-get gets the job done in literally seconds.
It's good that it's so easy to figure out how to use, because I touch it less than once a year, so I've completely forgotten about it. That's great software.
And I bet the operators of ten of the thirteen root nameservers who are running BIND will be mighty glad to hear from you!
It's true though; thirteen root nameserver operators do run BIND. You know what's worse? The tens of millions of people that like The Black Eyed Peas. >shudder< - what's wrong with me?
djb is in no way the best programmer of the world, but he is a very smart programmer, and probably an even better mathematician. And now, my arguments about why he is not the best programmer.
1) djb software is not the most elegant software around at all. Actually trying to write high performance and bug free software his style is the most procedural possible, with very little abstractions layers.
2) his software is well known to be uneasy to configure. There are qmail hackers around. When there are <name of a unix deamon>-hackers around it's a bad sign about the quality of the interface between the program and the rest of the system and the system administrator itself.
3) Djb played no role at all in the programming languages world. AFAIK he never suggested some new idea for programming languages or new directions that are now considered important. You can't be the best without being influential in the field.
4) Djb newer wrote big systems that were crucial for the programming world. Qmail and djbdns can disappear tomorrow and everything will be up and running anyway. GCC or the Linux Kernel are a different matter.
I can continue, but I think 1+2+3+4 are already enough to deny the argument aaronsw is trying to push in the article.
I think an appropriate analogy is judging an architect on the hammers he has improved instead of the buildings he has designed.
Still it is surely important to look at this great programmers in the aim to try to emulate all the stuff that they got right in order to improve ourself.
It seems like a lot of the energy around languages is frivolous. It's more fun to play with language features than to attack a real-world problem like writing a mail server.
As for #4, why does criticality matter? And why does the audience have to be programmers? Couldn't the author of a spreadsheet be as worthy as the author of a compiler?
Not that I'm endorsing DJB's nomination; I have pored through his source code for various reasons and have some reservations about it. But you could do much worse.
(And yes, it's all silly.)
as for #4 it's very admirable to write real world software, but the best programmers in the world, like Joy or RMS tend to write big systems that can be used by the other hackers in the world, because to write a new operating system, a C compiler that live for decades contributing even to the development of new operating systems (It's hard to imagine Linux without GCC in some way), or world class text editors (vi, emacs) is not something everybody can do, but only the best programmers in the world.
Might have an inheritance conflict there. ;)
he had these new ideas for software development, installation, and maintenance, so he implemented them and because they are different, people equate that with being difficult. he didn't like a lot of standard libraries, so a lot of his software uses his own routines (which has been extracted as libdjb - http://www.fefe.de/djb/) which is partially the reason for his impressive security record. i think you underestimate his impact on the unix software development community.
your fourth point is just wrong. a lot of ISPs rely on qmail and djbdns and to say that they wouldn't care if they just disappeared is just silly. sure there are alternatives, but so are there to linux and gcc.
"As a UC Berkeley graduate student, Joy worked for Fabry's Computer Systems Research Group CSRG in managing the BSD support and rollout where many claim he was largely responsible for managing the authorship of BSD UNIX, from which sprang many modern forms of UNIX, including FreeBSD, NetBSD, and OpenBSD. Apple Inc. has based much of the Mac OS X kernel and OS Services on the BSD technology.
Some of his most notable contributions were the vi editor, NFS, and csh. Joy's prowess as a computer programmer is legendary, with an oft-told anecdote that he wrote the vi editor in a weekend. Joy denies this assertion.[2]"
The wikipedia article links specifically to a sadly abandoned project that Salon had years ago to document the free software revolution.
http://dir.salon.com/story/tech/fsp/2000/05/16/chapter_2_par...
I've always remembered it and wished they'd finished but it sadly seems to have stopped getting new entries in '01:
> What other field combines all these arts? Language, math, art, design, function. Programming is clearly in a class of its own. And, when it comes to programmers, who even competes with djb? Who else has worked to realize these amazing possibilities? Who else even knows they are there?
Is this satire?
[1] Having asked this question directly to DJB in person, I can say that I am at least convinced he wrote this stuff in C.
I haven't read the qmail source (just some design docs about how the whole system fits together, which I found rather impressive), so I'm not talking specifically about that.
NB: Qmail's license wasn't public domain until 2007. (Also, damn, tptacek, you're fast! I deleted that part, since I'm talking about auto-generated code in general.)
(I'm in 100% full-on maximum overdrive procrastination mode today, since what I need to get done is to script and record a screencast of my app, and I'm frozen up about where to start with it. Sorry for being so fast to respond).
But that has nothing to do with the code, which is not only epsilon from assembly (Bernstein fully embraces the notion of writing code in high-level assembly), but also clever and concise almost to a fault.
As someone who ran qmail since it was originally released in beta, I also remember vividly Bernstein's original idea about configuration, which is that "configuring" your mail server with C code was more reasonable than learning another programming language (Sendmail "cf"). Which implies that a lot of the code in the interesting parts of qmail are less about design, and more about encoding mail routing policy as C code.
- Split the system into small components that do one thing and do them well. - Give each part of the system the minimal set of privileges needed (if necessary by running as different users and set filesystem privileges accordingly). I.e. qmail has separate binaries for inbound smtp, pop3, managing the queue, local delivery, remote delivery and more. - Make each part of the system communicate only via well defined interfaces (using pipes in qmail) where it is explicitly assumed that you can't really trust the sender. - Don't ever use library functions that don't length check things. Then again he uses his own stdio replacement, and his own string functions.
But really that's just the way he codes. It's very intricate. It's like a very ugly Swiss watch.
While this is certainly impressive, the number of bugs is not a good metric for measuring the effectiveness of a programmer. A programmer is only as good as the business problems she solves.
One bug in a life-critical application could be catastrophic. On the other hand, a programmer that makes sure their code is completely bug-free would not do well in a domain where time-to-market is critical and quality of service is not.
You know what, even John Resig's jQuery software is served by millions of servers, running in billions of web pages every day.
This all "THE BEST" thing, is somehow pointless IMO.
They all are rock solid cross-browser JS toolkits.
It's kind of a shame because of the the advantages of being young is being able to approach a field without having to take sides. Meaningful dialog and inquiry void of motivated reasoning are beautiful things. Unfortunately, some people need an argument.
You must be describing your youth, not mine! My experience with youth is that it was the period of my life in which the whites were blindingly white, the blacks impossibly back, and there were no colours or shades of grey to distract us from our belief that we knew exactly what was right and what was wrong.
And thank goodness, because a belief in right and wrong can propel you to change the world while you have the energy to carry it through :-)
Unfortunately, certitude can also lead people to be fierce advocates of the status quo.
$.fn.defaults({goosebumps: false});Linus Torvalds
* The Linux Kernel
* git
Fabrice Bellard
* FFMpeg (if you've done anything with video in the last 10 years, you've used this)
* QEmu (basis for QEmu emulator and userspace portion of KVM VM). Ubuntu's open EC2-API compatible elastic cloud app uses this, as does Red Hat Advanced Platform.
If there are any others, let me know. Mongrel's pretty popular, if Lamson does the same maybe we could add Zed.
People have arguments like this all the time in the sports sector, and at least there you can come up with all kinds of statistics and recordings, but what do you have for programmers? If they produced Open Source, you might have the end result of their work, but that would exclude a large part of the work force. And even then, what are your points of measurements? Just the amount of bugs? Total? Per year? Per line? Meh.
And as a final, somewhat unrelated note: Which I have nothing against Mr. Bernstein himself, I've got a pretty low opinion of most djb fanboys I've encountered in the past...
I have some experience with qmail. While I agree that it's generally very nice and certainly incredibly bug free, that quality comes at a price: Lack of features.
The moment you start adding stuff: Server-side filtering (like sieve), LMTP, virus checking, spam filtering, virtual users - all that stuff you need to run a modern mail server - you will have to patch qmail.
And by manually patching your installation, you are picking up responsibility: Now that you are not running stock qmail, but something you patched and installed yourself, you will no longer be able to rely on your distribution for security fixes and you'll have to keep updated and repatch yourself.
And while qmail is beautiful and bugfree, the same can not always be said for the additional patches, so you WILL be patching.
If you get all the patches for the functionality you need to actually play together that is.
If qmail solves your issue and you are prepared for this, then go with qmail. If you need a ton of functionality built-into your mailserver, probably go Exim and if you need good compromise between featureset, architecture and security, then you'll probably take postfix.
I worked for a long time with guys that wrote embedded software. Absolutely brilliant guys that never get their due because no one knows how they were.
I don't want to be dismissive but I think TeX is more complex and uses non trivial algorithms. So it's like comparing an apple to an orange.
If you're going to compare qmail to something else though I think it should be compared to sendmail (or postfix for that matter), not to TeX.
Personally I think djb is a great coder, but there are quite a few of those around.
Programming is not a single-valued enterprise anyway, so best is a very hard to measure quantity, as good as meaningless. But I know 'bad' when I see it :)
From a systems programming perspective, qmail is not only nontrivial, but actually groundbreaking. His allocator design, the way he architected his libc replacement, the extent to which he takes advantage of bare-metal Unix programming (look at his queue notification mechanism), it's all really cool stuff.
But there's a big difference between theoretical CS and systems programming, and the parent commenter is right to point out that TeX is more complicated from a CS perspective than qmail is.
thread closed.
how about this for minimalism: http://cr.yp.to/
Except to say "best" is such a subjective thing as to make it useless.
There are many programmers deserving of a "hall of fame" entry.
http://cr.yp.to/djbdns/intro-dns.html
under the "Multiple Servers" section, he says
"To protect against computer failure, there are actually several root servers, several .to servers, and two yp.to servers."
I don't understand, is he saying there are only two DNS servers in the world that you can contact to resolve yp.to?
$ dig yp.to ns
; <<>> DiG 9.4.3-P3 <<>> yp.to ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63068 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;yp.to. IN NS
;; ANSWER SECTION: yp.to. 184700 IN NS b.ns.yp.to. yp.to. 184700 IN NS f.ns.yp.to.
it's not measured by the no. of lines of code, bugs,etc.
But he certainly did a lot of good programming.
In any hall of fame where we mention Linus, Guido and Bernstein we probably do need to mention Gates as well.
Altair.BASIC