The DJB legacy

Who is this DJB guy, and why is he so special anyway ?

Dan J. Bernstein is a cryptologist and
a mathematician; he's also the author of a widely known and used MTA,
qmail, as well as a few
lesser known pieces of software.

For some time he was quite active in some Unix software-related
Internet newsgroups and mailing-lists; he quickly became a
controversial figure of the Unix programming community, mostly
by being extremely vocal against well-known authors of
"mainstream" Unix software and by suggesting designs so removed
from traditional software design that a normal human reaction is
to first view him as a complete nut.

I do not care for controversy. I am interested in the code. I was
a sysadmin at the time, and still learning to program in C beyond
what they teach you in school (i.e. not much). I had heard enough
horror stories with sendmail; so I gave a shot at qmail, trying to
understand its design principles and the way it was made. And then
I fell down the rabbit hole.

Look, I don't care what you think of the guy, I don't know him
anyway, and this is totally beside the point. The only thing that
matters is that DJB's software is right in so
many ways. This software works. DJB's design
principles are sound and elegant; they are
sound foundations to build reliable, secure, and
low resource-consuming software. And the design,
when you get used to it, feels so unix-ish: it's Unix the way it
should have been from the start.

Studying DJB's software was the best course in C/Unix programming
I ever had. Now I teach C/Unix; and I am really glad I
learned from the best.

Building beyond DJB's works.

However, I mostly see DJB as a pioneer. He showed it was possible
to think Unix differently and build secure, reliable and efficient
software without investing millions of dollars into it; now it is
up to software architects and programmers to use the breakthrough
and build upon it. There's a real demand for quality Unix software
out there; it's time to supply. And
I am not the only
one thinking this way.

So, skalibs.

One of the "DJB philosophy" key points is to question the
interfaces. You have a task to do; you have existing interfaces.
What do you do?

Most people don't even think about it and use the existing
interfaces, even if it amounts to cramming a square peg into a
round hole. This is why buffer overflows exist. This is why
people use abominations such as
gets(),
which is still in the Single Unix Specification as of version 4,
in freaking June 2011. This is why the System V
initialization scheme is still prevalent in Linux distributions,
despite being one of the slowest and most unreliable of all
initialization schemes. This is why people still use the
atrocious "libresolv" DNS client library.

An alternative way of thinking is to ask yourself:
"Is the interface I have adequate for the task at hand?"

If yes: perfect, use that interface.

If no: then do not use that interface, duh. Design a
better one and use it: so the complexity will be split and the code
will be easier to maintain.

Interfaces should be questioned right down to the libc. You
cannot build strong software on flakey foundations. And from a system
and network programmer's point of view, one thing is clear: most
standard libc interfaces suck. There is no buffered asynchronous
I/O. There is no timed I/O. There is no heap management helper. Even
simple system calls are not
always guaranteed to succeed!

That is where skalibs comes from. skalibs results from questioning
the libc interfaces, and providing replacements or additions where
the existing interfaces do not make it easy to write reliable, secure
and efficient software. It is inspired by DJB's work. It is
not a shrine or anything of the kind.

Conclusion

So, in short, DJB is not a guru, I'm not a mindless brainwashed fan,
and the "DJB advocates" are not a cult. We just think DJB brought
something to Unix and more generally to the software programming world;
we learned from him, we write software following
sound principles that he was one of the first to really apply, and we give
credit where credit is due.