Re: DNS servers
We're discussing the example
cd /service/tinydns/root
./add-host lion.x.mil 1.2.3.4
make
from http://cr.yp.to/djbdns/blurb/easeofuse.html. These commands will
automatically stop and display a message if there are any syntax errors,
disk-write errors, etc. (Of course, there won't be any syntax errors
added by add-host, but maybe you edited the data manually.)
The ``DNS and BIND'' book says that you have to check syslog because
otherwise ``you might never notice'' syntax errors. That's true for
BIND, but it's not true for djbdns. The extra step of checking logs is
unnecessary for djbdns.
Sanders claims that I'm telling people to ignore the possibility of
errors introduced by editing. That claim is completely incorrect. I'm
saying---and, in fact, the same web page mentions a little later---that
these errors are automatically put on your screen in response to your
commands. (Exactly as you would expect from normal UNIX commands.)
Other helpful djbdns features illustrated by the same example:
* you can simply run a program instead of manually editing files;
* you don't have to repeat the host information in PTR format;
* the add-host program automatically stops if the name or IP address
was used before (if you want repetitions, use add-alias);
* the update is saved to disk (atomically!) just in case there's a
power outage;
* you don't have to worry about serial numbers;
* you don't have to worry about trailing dots.
A bunch of little improvements like this add up to a quite noticeable
overall improvement in ease of use: time saved, errors avoided,
confidence gained. (By the way, when Sanders claims that ease of use is
inherently subjective, he's ignoring decades of UI research.)
A more subtle point illustrated by this example is how easy the tinydns
data format is for programs to parse. The add-{host,alias,mx,ns,childns}
scripts, and the tinydns-edit program that they use, are small and
straightforward.
Sanders claims that the tinydns configuration syntax isn't ``any easier
for programs'' than the BIND configuration syntax. That's ludicrous.
Where's the equivalent of add-host for BIND zone files? To do the job
right, you'd have to parse named.conf in enough detail to reliably
locate the relevant forward and reverse zone files, then parse those
files in enough detail to check for prior use of the name and address,
update serial numbers, and so on. Yes, BIND can do all this parsing, but
BIND is a huge piece of code!
Nate Campi pointed out a few of the complications of the BIND zone-file
syntax that are avoided by the tinydns syntax. Sanders responds that
``programs should do the extra work.'' Gee: I thought he was claiming a
moment ago that there wasn't any extra work.
Talking to Sanders is like talking to Microsoft users who don't
understand why so few UNIX programs read Microsoft's document formats.
Some of those users scream that the UNIX people aren't paying attention
and don't care about compatibility. When programmers try to explain that
the limited software choice is caused by the unnecessary complexity of
the file format, the users respond that it's the programmer's job to
deal with that complexity. What's really sad is that they continue
blithely creating files in overly complicated formats.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
P.S. I wonder whether Sanders is bothered by the ``magic'' filenames in
the cron file hierarchy, and the terminfo file hierarchy, and the init
system, and many other UNIX configuration mechanisms. Is it so hard to
grasp the concept that the filesystem is a database?
Reply to: