Users Want *Seamless* Solutions, Not Patchwork (was Re: Users want solutions, not buzzwords)

[D. J. Bernstein]

Kevin Darcy writes:
> anyone who cares about ease of use (your audience here) would have at
> least scripted these updates a long time ago

Gee. A moment ago I thought you said something like ``Users Want
*Seamless* Solutions, Not Patchwork.'' And now you're saying that I'm
``dishonest'' for not taking your local BIND patchwork into account.

My table compares the supported, documented djbdns solutions to the
supported, documented BIND solutions. The only exceptions are cases
where I couldn't find _any_ supported BIND solutions.

If the BIND company tells me that version 9.whatever now supports an
easier solution, namely blah blah blah, I'll be happy to add that
information to my table.

> getting named to follow delegations under a forwarded domain
> does *not* require a new zone definition

On the contrary. As the DNS and BIND book says, in a discussion of BIND
scaling problems: ``zardoz will ignore the delegation information and
forward the query to terminator.''

> neither does BIND require shared libraries and various other stuff in
> a chroot jail

On the contrary. ``Copy various programs, system-dependent libraries,
and system-dependent devices'' is a perfectly reasonable summary.

> you have an extra step for "Look for errors in your system's logs"

With djbdns, the errors are displayed automatically. With BIND, the
system administrator has to go to extra effort to check for errors.
That's an extra step. How you can call this ``unfair'' is beyond me.

> > Unlike the BIND company---which sells support services---I don't have
> > any financial interests in hard-to-use software.
> Every time you make a snide reference -- like that one -- to "the
> BIND company", you make yourself look like a conspiracy-theorist nutcase,

The BIND company sells support services. It has a financial interest in
hard-to-use software. This is not a conspiracy theory; it is a simple
statement of the economic facts.

> how many hours of prior download/compile/install/config

The normal situation is that ssh is already working and rsync is
unnecessary. It is straightforward to download, compile, and install
daemontools, ucspi-tcp, and djbdns---much easier than downloading,
compiling, and installing BIND. You don't need anything else.

> The point is, by not supporting EDNS0, you're locking djbdns out of dozens
> if not hundreds of potential useful extensions to DNS.

``Locking out''? Don't be silly. I can implement EDNS0 later, and I will
do so _if_ it means something for my users. Right now, it doesn't.

> Writing your own DNS implementation was a good step, but
> proving that your way of doing DNS *at*the*protocol*level* is better,

What are you babbling about? djbdns uses the existing DNS protocol to
help administrators retrieve and publish DNS records. It is a research
project in security and in ease of use; it is not a research project in
protocol design.

---Dan