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

[D. J. Bernstein]

http://cr.yp.to/djbdns/blurb/easeofuse.html is the table that we're
discussing here.

Kevin Darcy writes:
> D. J. Bernstein wrote:
> > ``Copy various programs, system-dependent libraries,
> > and system-dependent devices'' is a perfectly reasonable summary.
> No it's not. You don't need that stuff if you're not using named-xfer.

You're wrong, according to the BIND 9 manual: ``Depending on your
operating system, you may need to set up things like /dev/zero,
/dev/random, /dev/log, and/or /etc/localtime.'' I've updated my summary
to say ``Copy various system-dependent files, which are not thoroughly
described in the BIND manual.''

> In one of the BIND 8.2 versions the "forwarders { }" syntax was added
> to selectively cancel forwarding,

You seem to be saying that I can remove the ``10.1.2.6;'' part from the
solution for BIND 8.2 and above. I agree that this is a bit simpler, but
does it work correctly? When BIND looks up www.d.x.moon.mil in the
example, will it start with the x.moon.mil server (ignoring delegations
from moon.mil or above), then follow the d.x.moon.mil delegation? The
documentation seems to suggest the opposite.

Either way, the conclusion is the same: the sysadmin has to edit
named.conf, while djbdns automatically does the right thing.

> if you're on a slow link lots of stdout can be painful

Silly argument. _If_ there is a syntax error then djbdns will give you a
one-line error message. Watching for BIND errors involves at least as
much output, usually much more.

You ask where the message is saved with djbdns. The answer is that
running ``make'' again will very quickly show you the message again. Of
course, people normally _fix_ the error, rather than looking at it again
and again.

> Since you *recommend* not using AXFR/IXFR, it even strikes me as even
> a little hypocritical that you would assume its use in your supposedly
> apples-to-apples comparison of djbdns and BIND.

Learn to read. I'm comparing the supported, documented djbdns solutions
to the supported, documented BIND solutions (except where I couldn't
find any supported BIND solutions). I'm sure the BIND company will send
me rsync solutions for my table _if_ they ever start supporting rsync.

> only 2 main executables

So what? Is that supposed to help the system administrator? Then why are
the BIND solutions more difficult than the djbdns solutions?

> Support services aren't always necessitated by a
> software package's difficulty-of-use.

There are, of course, some support services for easy-to-use packages.
However, support services for hard-to-use packages generally have a
larger income-per-package-user ratio. Do you understand what the phrase
``financial interest'' means? 

---Dan