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

[Kevin Darcy]

If it's just a research project, why does djb actively "market" it to
*everyone*, pitching it as an "upgrade" from BIND? Why does he brag about the
big sites that are using djbdns and encourage people to announce on their
websites that they are doing so, so that "djbdns" will generate more hits in
search engines? Doesn't he have enough lab rats for his research project yet?

djbdns may have started as a mere research project, but that's not how it is
being marketed now. It's being marketed as a replacement for BIND or any other
full-featured DNS implementation. I therefore treat it as a BIND competitor and
hold it to the same level of requirements to which users typically hold BIND.


- Kevin

Danny Mayer wrote:

> Kevin Darcy wrote:
>
> > My point is, though, whether it's 3Kb or 3Mb, waste is waste. Because of
> > your design decision to split the AXFR server from the main authoritative
> > server, you have to put lookup code into axfrdns so that people can run
> > axfrdns alongside tinydns on the same address. This lookup code in axfrdns
> > duplicates what's already in tinydns. Now, maybe if you had a way to put
> > the code which was shared by the two programs into a shared object,
> > dynamically-linked from both tinydns and axfrdns, I wouldn't be griping so
> > much. But that would complicate the build and installation process,
> > wouldn't it? Overall, I don't think it would be a net win in terms of
> > ease-of-use. You're in a no-win situation because of your fundamental
> > design decision. rsync and ssh are nifty tools for replicating files, but
> > in the process of accommodating (nay promoting) their use, apparently you
> > have sacrificed some elegance/efficiences that you could have otherwise
> > realized, for folks who want to use plain old AXFR for replicating their
> > zone data -- they have to configure and run a separate program, which
> > partially duplicates tinydns code. Your personal bias against AXFR is
> > reflected in the design of your package. What a shame for folks who find
> > AXFR quite usable, or might actually prefer it (gasp!). Apparently they
> > don't matter....
>
> You have to remember that DJB describes djbdns as a research project.
> A research project doesn't have to satisfy anyone else's requirements,
> just the goals of the research.
>
> >
> > > The documentation also answers your remaining questions. RTFM.
> >
> > I have RTFM'ed, but the FM hasn't been of any help.
> >
> >
> > One would have to grovel through the code to get the answers to these
> > questions. I decline to do so. Such laborious methods of ascertaining
> > answers to basic configuration questions should not be necessary with a
> > package which makes extravagant claims about its "ease of use".
> >
> > (To everyone: yes, I know this thread is now starting to drift from
> > strictly "ease of use" issues to quality-of-documentation issues, but my
> > opinion is that inadequacy of documentation is a factor in "ease of use",
> > since it's hard to configure a DNS package if you can't easily find out
> > *how* to configure it. Besides, Dan started the drift by telling me to
> > RTFM... :-)
>
>     Research projects don't require documentation to satisfy all questions,
> just
> the ones that the research was designed to answer.  That's the point of
> research after all.
>
>         Danny