I've spent significant time reading DJB's source, particularly daemontools. It makes me sad that programmers in this decade don't seem to be taking that much influence from him.<p>Commercial software is hopeless in terms of bloat and security holes. Open source software is sadly not that much better.<p>The whole motivation for djbdns was all the glaring holes in BIND, and I think the same is true for qmail and sendmail. Yet basically every institution in the world is running a pile of sloppy software that dumps our private data to hackers on command.<p>There is a lot to learn from djb. He's about 10-20 years ahead of his time, and you have to read code to absorb the wisdom.<p>Here is some text that my help:<p><a href="http://thedjbway.b0llix.net/" rel="nofollow">http://thedjbway.b0llix.net/</a><p><a href="http://lwn.net/Articles/257004/" rel="nofollow">http://lwn.net/Articles/257004/</a>
Looking at his code, it's kind of scary. No comments. K&R C style declarations. Vast amounts of pointer arithmetic. What makes this work is that he defines a generic collection class.[1] This being C, it's a macro which generates a struct:<p><pre><code> #define GEN_ALLOC_typedef(ta,type,field,len,a) \
typedef struct ta { type *field; unsigned int len;\
unsigned int a; } ta;
</code></pre>
This is equivalent to <vector> from C++. Then he defines strings based on this (see stralloc.h), and provides the usual operations on them. Disciplined use of those primitives provides good reliability for all the string handling a mail handler does.<p>[1] <a href="https://github.com/amery/qmail/blob/master/gen_alloc.h" rel="nofollow">https://github.com/amery/qmail/blob/master/gen_alloc.h</a>
I disagree with Aaron. I would reserve the title of the greatest programmer in the world to Fabrice Bellard. He single-handedly wrote QEMU, FFMPEG, an LTE base station, a PC emulator in javascript, and countless other projects. Alone.<p><a href="http://bellard.org/" rel="nofollow">http://bellard.org/</a>
Wow three letters, so many stories in my head.<p>Here are my top 5 reasons why I think qmail + daemontools + djbdns is great :<p><pre><code> 1. bugs free code ( well almost ) ;
2. fast & memory efficient ;
3. following "everything is a file" philosophy ;
4. easy to configure and more
</code></pre>
I've been using this suite for almost 10 years now. I've never found any alternative. BIND was too complicated in terms of configuration for me and also got updates almost every 2 weeks ( 8 years back it was much much harder than doing "apt-get ..." )<p>Qmail is also flawless piece of software. It basically taught me how you should separate processes and how to use linux accounts properly for the daemons. Amazing.<p>Finally the only thing I rely on right now is daemontools. I'm using it for all of my production nodejs websites and even for a tool that I call "deployer" which automatically stops, updates and starts a daemon from the suite.
I largely agree with this, but I also think it's worth noting that DJB opted out of writing most functionality, leaving it to the end user, so he has provided us with a fantastic bike frame upon which we bolt far less superior software than the alternatives.<p>You want AXFR with djbdns? Well, DJB decided that AXFR is stupid, and that you should live in a monoculture of only DJB software, which doesn't have to conform to standards, so you have to write scripts to handle this at both ends and AXFR is one of the BIGGEST security concerns in DNS.<p>That said, I've really enjoyed running qmail, dnscache, and daemontools. These days I use runit, simply because it is maintained, because I have trouble buying into the notion that any software can be suitable across platforms and changing underlying libraries. I have no doubt that runit's code is less stringent than DJB's, and I find it fruastrating that a couple of things I used to do with daemontools cannot be done with runit.<p>Anyway, always good to ressurect Aaron's ideas, that DJB outlasted him is a fucking shame.
I have vague memories of the fact that qmail was mostly used with patches that DJB didn't want to incorporate, (e.g. support for STARTTLS).<p>This ended up causing a lot of people to use other servers which _did_ respond to user demands.<p>So maybe other than only learning from the way he writes code, we can also get some ideas on how to nurture open source projects.
I've followed a policy of using djb's software whenever possible over the years. Unfortunately qmail shows its age and may no longer be a good choice these days, but then again, who runs their own email server? :)<p>daemontools and ucspi-tcp are still some of the best tools to dig into. I love multilog (part of daemontools) which solves problems I didn't even know exist. e.g. I had a pool of servers and wanted to collect all the logs in one place... the way multilog names files makes this a simple rsync task, and you can just concatenate and sort, it even works for multi-lined output.<p>Since I started using docker, djb's tools got a new life for me. I manage all services within docker containers with daemontools.
I used to work as a UNIX admin, so having a home OpenBSD box to handle mail seemed like a requirement. I ran qmail and djbdns, under daemontools, because there was nothing else as secure, nothing else 'properly' designed (I agreed with the design principles behind the software) and nothing else as easy to administer (I really don't like m4).<p>I spent a long time trying to understand why DJB's software wasn't considered the gold standard and installed by default on all Linuxes and BSDs. I read lots about arrogance, but couldn't see any - I could only see a commitment to solid software.<p>Eventually the only theory I was left with was that perhaps the 'UNIX way' was something people didn't really understand, or didn't want to invest time into understanding. I'll draw a parallel with vi editor[s]: Those who invest time into understanding the vi philosophy are happy working with it and would rather not use anything else. Others think they (we - you might have guessed I'm a vi user) are somehow ultra geeky or hardcore. Maybe this is why there's a preference for server software with a shorter learning curve, too.<p>The thing I really didn't 'get' was that to me, djb's tools had no learning curve, because they work 'the UNIX way'. Perhaps this is why those who like[d] his software never made their voice heard enough, or did the work, to get them into mainstream distributions: They don't understand why others don't see that they're great.<p>There could be other reasons. For example: I gave up running my own mail server when I got sick of dealing with spam and couldn't find a decent web interface. I think squirrelmail was the best I could find at the time and gmail was so much better. Sorry, squirrelmail! Perhaps it was easier to integrate anti-spam software with other mail servers. Perhaps I never found out because I refused to use other mail servers, having seen all the security advisories. Maybe my refusal to consider 'insecure' software meant I was blind to the advantages of sendmail and postfix, rather than simply others being blind to the advantages of qmail.
Are you people serious? His code is absolutely disgusting:<p><pre><code> uugh = constmap(&mapuser,x,i);
if (!uugh) die_user(x,i);
++i; x += i; xlen -= i; i = byte_chr(x,xlen,':'); if (i == xlen) return;
</code></pre>
<a href="https://github.com/amery/qmail/blob/aa6bf9739209ca76f7f3af0feada5552723a622b/qmail-pw2u.c#L205-L207" rel="nofollow">https://github.com/amery/qmail/blob/aa6bf9739209ca76f7f3af0f...</a><p>It's mostly bug-free because it scares bugs away. If I was a bug I wouldn't want to live in there.
DJB had some great comments on what he thought makes qmail secure: <a href="http://cr.yp.to/qmail/qmailsec-20071101.pdf" rel="nofollow">http://cr.yp.to/qmail/qmailsec-20071101.pdf</a><p>Perhaps the most legit complaint of DJB's work is that he would often lobotomize chunks of a protocol if he didn't like it. But it was still great work and it contrasted nicely to some horribly insecure software at that time (sendmail and bind)
He also was the person behind Bernstein v United States which the Ninth Court ruled software as freedom of speech.<p><a href="http://en.wikipedia.org/wiki/Bernstein_v._United_States" rel="nofollow">http://en.wikipedia.org/wiki/Bernstein_v._United_States</a>
DJB a software engineer who doesn't listen to other's input and believes that his way is always the right way. Despite the fact that his software is solid, I try to avoid it all costs because it is a huge pain to configure and manage and doesn't follow the UNIX way <i>at all</i>. It follows the DJB unix way, which is terrible if you want to use anything that isn't DJB.<p>Also tinydns is fundamentally broken because DJB doesn't believe in split views.
> But these programs are not just for being seen or read — like a graceful dancer, they move!<p>This is what makes programming beautiful. The analogy that come most easily to me are to machines, like the wonderful stationary engines that sometimes ran at the Manchester Museum of Science and Industry. But in comparison their movement is so constrained... Dancing is far more representative.
I appreciate this as an avid user of daemontools (<a href="http://cr.yp.to/daemontools.html" rel="nofollow">http://cr.yp.to/daemontools.html</a>) -- thanks for the link!
The bug thing is about <i>security holes</i>, right? I think the comparison with Knuth is apples-to-oranges.<p>Or is it actually the case that, since the first public releases of djbdns and qmail, no bugs, security or otherwise, have been found?
The "one bug was found" only goes for exploitable security vulnerabilities. There have been many other, less impactful bugs. This is still an an impressive archievement, especially because DJB chooses to juggle with chainsaws and write in C.
I question the reasoning for calling Knuth's abilities into doubt because he had a diary of all of the bugs he encountered along the way in his programs. That is a practice of his that I often feel I should imitate.
Perhaps people are annoyed that DJB does everything his own way, rather than using standard tools? I vaguely remember building DJB's software from source to be non-trivial, but that was a decade ago.
A good time to link to the Unix Security Holes Course djb gave in 2004: <a href="http://cr.yp.to/2004-494.html" rel="nofollow">http://cr.yp.to/2004-494.html</a>
I don't hate djb, but I won't run his code.<p>If you should happen to get involved in IETF discussions, I believe you will still occasionally find him there discussing how to fix various protocols. Back in 2002 I was witness/participant to one discussion involving djb that made me think twice.<p>Because a great deal of software will not be able to handle Unicode (even now) there was some discussion back then about how to handle domain names in older software once domains with non-ASCII characters were allowed. If your software is assuming all ASCII characters, how do you display/handle a domain with greek or cyrillic characters? This obviously affects DNS and Mail software, so djb's contribution should have been valuable.<p>The consensus from everybody else was a temporary hack: Punycode. <a href="http://en.wikipedia.org/wiki/Punycode" rel="nofollow">http://en.wikipedia.org/wiki/Punycode</a><p>djb did not like this. He suggested all software should instead represent the actual characters rather than changing them because humans should be able to read them. He proposed this should be done through ASCII art. So if you were to register ααα.com (that's three greek alphas if your browser can't render them), all software should display this as:<p><pre><code> _
/\/ /\/ /\/ / /\ /\/\
\/\ \/\ \/\ o \_ \/ | |
</code></pre>
We has very serious, and got very upset when we pointed out this would require re-writing all software deployed to date, and if we were going to do that we'd just make it support Unicode properly.<p>My problem was that this idea was so batshit crazy I had to then question how crazy his actual implementations were. I dug into the source code of several of his tools.<p>I came away feeling that the reason bugs had not been found in his code were not because his code was bug-free, but because it is impenetrable noise.<p>As others have suggested here, it is uncommented, he uses a lot of pointer arithmetic, some parts don't make sense. Making a contribution to improve it is difficult. Identifying if the code is correct or not is near impossible.<p>DJB's code might be bug free, but it is also quite likely to be bug-ridden but nobody has been brave or bored enough to figure out where those bugs are.<p>I expect it does not have the same holes as BIND or sendmail (both of which are awful), but it will have holes.<p>The wonderful beauty of open standards and the work that the IETF has done of course, is that it means we have choices and if you want to run djb's code, you can go and do that. If you don't - and I do not - you have choices of other software that will inter-operate with it as expected.<p>I don't hate djb, but I don't trust the claims made about his code being watertight, and I do not believe somebody who writes code that is hard for others to understand is worthy of the title "greatest programmer who has ever lived".<p>Good luck to him and all who use his code, but no thanks, not for me.<p>P.S. - if you want to see what good code does look like in an MTA, take a glance at the source for exim one day. It is very clear and well structured, I think.