Subject: Re: Fwd: Re: Microsoft: Closed source is more secure
From: Lynn Winebarger <>
Date: Sun, 6 May 2001 05:52:04 -0500

On Thursday 03 May 2001 11:04, Ian Lance Taylor wrote:
> Lynn Winebarger <> writes:
> > (a) personality of the author as seen in Internet postings (usenet/web
> > pages) (b) poor documentation, if qmail is any indicator
> > (c) odd way of writing source code, if qmail is any indicator
> > (d) odd build process, if qmail is any indicator
> > (e) odd license and infrequent updates to official source (if qmail
> > ....), which exacerbate the effects of b,c, and d.
> None of these say that djbdns is non-conforming or non-usable.  The
> problem to be addressed is bind.  If there were a better alternative,
> we could use that.  But, as far as I know, there is only djbdns, which
> does work, and is secure.  (I use it myself, and I've read the
> code--once adjusted to the style, it's a heck of lot easier to read
> than the bind code.)

    Can't speak directly to djbdns (that's why there's all those "if qmail
is any indicator"'s up there).  I wouldn't doubt that bind code would be
harder to read, though.

> I will note that your points (a), (c), and (d) seem irrelevant, and
> that I disagree with your feelings on (b).  I agree that (e) is a
> problem.  With respect to the interaction of (e) and (b), I note that
> the documentation is on the web, and is updated rather more frequently
> than the code.

     I  unintentionally misconstrued the original question as "Why don't more
people use djbdns?" rather than "Why don't _you_ [whoever he was replying to]
use djbdns?".  I agree (a) is irrelevant if the software is complete enough
 that you don't have to work with the author to add features (which appears
 to be the case for djbdns).  If you have to modify the code and want it put
 in the main distribution, (a) is a _factor_.   It's a greater factor when
 forking is not an option. (c) and (d) were factors for me once I decided I
 would have to read the source code to qmail to choose among the multitude of
 patches, or if I wanted to do it myself.  The fact that I had to read C code
 to see how the programs were built I took to be a bad portent of things to
 come.  I could not see (and still do not see) any good reason not to use a
 standard Makefile for the entire build process.   At this point I
 re-evaluate the question of whether the time it'll take to read the source
 and judge patches will be worth the payoff, or whether it'd be better to
 work with a free solution that had all the necessary C code and just needed
 the right configuration. Perhaps I mis-estimated, but I don't think so yet. 
 The time it takes to develop good C with non-buggy memory management is
 almost always going to be greater than writing a configuration file, even if
 that file uses its own programming language.  And (c) does exacerbate that
 until you've adjusted to the style (which is just odd, not obfuscated).
     Is it common now for the sysadmins (or whoever will be implementing an
 org's mail system) to be C programmers?  Of course, larger organizations can
 afford to pay for mail specialists to do this, but the question isn't
 restricted to them.