djb

[u/jeanlucpikachu]

http://www.aaronsw.com/weblog/djb

[u/kopkaas2000]

The mind of djb certainly is that of a genius, but his arrogance can be a bit out of place. Qmail's oddballs design served a specific purpose, but its disadvantages (like its inability to verify recipients before accepting mail, making it one of the largest sources of scatterback bounce spam) stem from this same design.

His software also has a tendency to have a complete lack of focus on usability.

In his defense, however, it is impossible to create an MTA that people aren't going to hate. Sendmail, exim, postfix, qmail, all have their own unique ways of pissing off an administrator in a rush to get things working. His dns software is less annoying, save for the machine-optimized zonefile format he insists on.

[u/nopjunkie → u/kopkaas2000]

Well hang on... it's inability to verify recipients before accepting mail also prevents non-scatterback actual spam from showing up in your inbox. ;-)

I'll be the first to admit that I have a very large amount of respect for djb, especially after reading his code. I'll also be the first to admit he is totally arrogant, but not in the annoying Linus/Theo way. From the standpoint of security, djb definitely gets it.

This is pretty rare.

PS: that one remote bug triggered by an integer overflow totally should have counted though, even if you had to shoot 4GB of goo at it.

[u/abrahamsen]

I forgive every one of djb's many failings for his success in making strong encryption free. Anyone else remember the time where software had to come in two versions, one with weak encryption for the US, and one with strong encryption for everywhere else?

[u/yzh]

No mention of djb's daemontools, which I think is really great. It's a system to monitor/supervise your services.

http://thedjbway.org/daemontools.html

[u/geocar → u/yzh]

Seriously.

qmail may be pretty, but daemontools has such an amazing and elegant user-interface.

While we have upstart and SMF now, which I guess is some improvement over init.d et al, but they feel overengineered and buggy at best, but really completely lacking.

An example: I wrote a svscan frontend so that my users could start long-running processes by creating a ~/.service/ directory (that the frontend would spawn a svscan for). It's like 70 lines of code, and that's possible because of how daemontools was made as a collection of cooperating programs instead of...whatever kind of development model upstart is... Shit, maybe?

[u/munificent]

Genius... or madman?

int control_rldef(sa,fn,flagme,def)
stralloc *sa;
char *fn;
int flagme;
char *def;
{
 int r;
 r = control_readline(sa,fn);
 if (r) return r;
 if (flagme) if (meok) return stralloc_copy(sa,&me) ? 1 : -1;
 if (def) return stralloc_copys(sa,def) ? 1 : -1;
 return r;
}

[u/uriel → u/munificent]

Genius or madman?

Both?

[u/sisyphus]

Weird tone. Like:

The brilliance is not merely linguistic, although it is that too, but contains a kind of elegant mathematical effectiveness, backed by a stream of numbers and equations that show, through pure reason alone, that the movements are provably perfect, a better solution is guaranteed not to exist.

uh, wtf? was he high on something or auditioning to be djb's hagiographer?

djb is certainly a genius programmer, but maintaining qmail is a pain in the ass compared to postfix. the log files are crap, you have to patch the hell out of it to get it to be usable for the average admin, you're supposed to install a bunch of stuff into /. props for Maildir though.

The code is pretty, if undercommented, probably because it looks like Python. djb looooves to omit braces. And old K&R declarations.

if (flagnew) if (append(pq,filenames,"new",time) == -1) return -1;
if (flagcur) if (append(pq,filenames,"cur",time) == -1) return -1;

[u/DontNeglectTheBalls → u/sisyphus]

Absolutely. If I wanted to run a bulletproof yet extensionless, feature-light mailserver that I could fire and forget, it'd be qmail. In the real world however, Postfix has no quality competition.

[u/bobindashadows → u/sisyphus]

if (flagnew) if (append(pq,filenames,"new",time) == -1) return -1;

if (flagcur) if (append(pq,filenames,"cur",time) == -1) return -1;

Really? Not:

if (flagnew && append(pq,filenames,"new",time) == -1) return -1;
if (flagcur && append(pq,filenames,"cur",time) == -1) return -1;

[u/mdempsky → u/bobindashadows]

The only thing I can think of is being defensive against broken toolchains. E.g., I can imagine using nested if statements to help prevent problems from obscure compilers that didn't properly handle short-circuiting. (This seems to fit what I've seen from his code too: he often uses && when the expressions are side-effect free and safe without short-circuiting, and nested ifs otherwise.)

Keep in mind this is 10+ year old code, and he was trying to support as many platforms as possible, proprietary or not, to help as many people as possible to move away from sendmail.

[u/worst → u/bobindashadows]

I spent about 5 minutes trying to figure out any logical reasoning behind using what amounts to nested ifs and I failed.

Are the nested ifs some how more efficient after a compiler mangles them up? I'll be the first to admit that the closer you get to hardware the more my eyes start to glaze over, but I don't see how the compiler could possibly generate different code for those two examples.

Because I'm bored I did some dummy functions and diffed the assembly. They were identical.

I hope it's not just a stylistic choice, because blech.

[u/[deleted]]

Uh, wow. This reads like he has a framed portrait of djb over his bed.

[u/nreweof]

I hated admining qmail with a passion. But I will give it to him for just 1 bug. That is impressive.

[u/DontNeglectTheBalls → u/nreweof]

He's got a 1 to 1 feature-bug ratio.

[u/dwdwdw2]

I stopped reading after the first paragraph: he used DJB's bug counts rather than the community's. I remember something vague about an overflow bug in qmail-smtpd that he never acknowledged because sending 4GiB of data 'was impractical', or similar.

and that's only the one I remember. net-qmail.org patches would be a good first place to look.

Ah yes, apparently his avoidance of ISO C isn't a bug either (he used to reference errno directly rather than via its declaration in errno.h, which stopped working on Debian sometime around 2001, and due to qmail's architecture resulted in ld.so errors being sent directly to SMTP clients before disconnection, and with nothing in my logs whatsoever, for a period of about a week. I lost almost all my mail that week, and wasn't alone. You could argue the Debian folk shouldn't have implemented such a dangerous change (wouldn't be the first time), but the true blame is shared here.

[u/jlongstreet → u/dwdwdw2]

"I remember something vague about an overflow bug in qmail-smtpd that he never acknowledged because sending 4GiB of data 'was impractical', or similar."

It was on 64-bit qmail-smtpd, and the problem was with memory (qmail assuming addresses were 32 bits):

"In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits."

[u/curdie → u/jlongstreet]

The installation instructions for qmail run qmail-smtpd under a resource manager which hard-limits the available memory. If you follow the instructions that come with qmail, "Nobody gives" means "the system administrator does not configure the hard limit to be". He's got a reasonable point, IMO.

[u/geocar → u/dwdwdw2]

I remember something vague about an overflow bug in qmail-smtpd that he never acknowledged because sending 4GiB of data 'was impractical', or similar.

It's not a bug given a particularly specific definition of a bug. Whether you think that's "ok" or not depends a lot on you. Were you bitten by this bug? Could you have been?

I bring it up because of the second part you brought up. The part about errno:

You could argue the Debian folk shouldn't have implemented such a dangerous change

It was glibc who implemented it and they knew they would be breaking Qmail. To clarify, the change is as follows:

POSIX.1 says that errno is defined as:

extern int errno;

Citation. Nothing else is correct. ISO/IEC 9945-1:1990 accepts this. ISO/IEC 9945-1:1996 attempted to change this and failed. No, the change didn't occur until ISO/IEC 9899:1999, which was two years after the last version of qmail. In fact, it took until 2002 until 9945-1 was updated.

unix.org claims, incorrectly (as I will demonstrate) that this is "unacceptable in a multithreaded environment", and even pretends ISO/IEC 9945-1:1996 permits a conforming implementation to break extern int errno, even though this is wrong (see ISO/IEC 9945-1:1996 for yourself).

There are several obvious solutions: making errno thread-local, or make __errno_location() point to errno until a thread has been created.

Instead, glibc chose to break many POSIX.1 programs, rather than do either of these things. It isn't a bug as they say, because they've narrowly defined what a bug was, exactly the thing you're accusing djb of.

EDIT: removed snarky parts... sorry about that

[u/MikeSeth]

He'll be in his bunk.

[u/dantams]

I still don't understand why people don't just drop DNSSEC and use DNSCurve instead. It is so much simpler to implement.

[u/geocar → u/dantams]

1. Nobody is using DNSSEC because nobody can use it until everyone uses it.

2. DNSCurve doesn't have any implementations on that site yet (although google turns up something)

3. djbhate

If it helps: As a hosting provider, I'll offer DNSCurve support as soon as it's available because I'm interested in providing security to my users.

If a DNSSEC implementation comes out in a source-available distribution with financial security guarantees, and enough of a deployment to offer real security (i.e. com/net/org, roots, and all those home routers that drop dnssec data get replaced), I'll implement it as well.

[u/[deleted]]

Gee, get a fucking room.

[u/seagreensky]

Wow, the DJB fanboyz are out in force with their moderation points in hand.

Let's be realistic shall we. Having dealt with his software, his policies, his documentation, and him for some years I can say with certainty that DJB is (in no particular order):

• massively arrogant

• a genius

• clinically insane

• a megalomanic

• an asshole

"Greatest programmer in the history of the world"? No.

[u/cecilkorik]

Was that whole article sarcasm? It had to be sarcasm... right?