[SATLUG] djbdns slave to bind

[Justizin]

On 10/21/06, Travis H. <solinym at gmail.com> wrote:
> On 9/27/06, Justizin <justizin at siggraph.org> wrote:
> > > Most people run more software packages than OSes, so for most
> > > people I would think consistency within the OS is more important.
> > > Basically DJB is being lazy and non-standard.
> >
> > I disagree with this entirely.
>
> With the fact that most people run more software packages than OSes,
> or that DJB is being lazy and non-standard?

I disagree that he is being lazy, and I assert that he is in fact
even, often, compatible with BIND's RFC-violating behaviour.

> When I say non-standard, I'm not referring to BIND.  I'm referring to
> how you start and stop the utililties (no init.d?  /sbin/service
> doesn't work?), where they run from (/service?  What if root is
> read-only?), how it logs failures, how it integrates into the startup
> script sequence (it doesn't, and often one resorts to running it after
> everything else, which leads to service failures since DNS isn't up
> yet), and so on.
>

Those are not standards, those are conventions that you have come to expect.

init.d is not part of the FHS, just FYI, or the LSB.  It's a SysV
standard promoted by AT&T.

Fuck AT&T.

FWIW, daemontools behaves similar to MacOSX/Darwin launchd, although
daemontools kicks launchd's ass, and I believe the concept of a launch
daemon may be proposed by Apple as part of the Single UNIX
Specification.

Major advantages of the daemontools approach include:

  * automatic log rotation
  * precise timestamps on all logs
  * auto-restart of failing services
  * the ability to delegate service control authority using filesystem
permissions

I'll give you that /service is not FHS compliant, quite, but there's
nothing preventing it from being accepted as part of a future FHS.

> > who often moderate DJB's bitching
>
> Of which there is plenty...
>

And well earned.  FYI, it is an anti-trade violation to moderate a
discussion list of which the purpose is to develop technology
standards.

> > Anyway, the stuff is not lazily written.  It has a personal $1000
> > security guarantee which hasn't been paid out in many years.
>
> It's $500 by the way.  In fact, both DJB and Wietse Venema have found
> problems in each other's software, and DJB has refused to pay up.
> Whether or not the problems constitute a "security problem" is fairly
> subjective, he has clarified the criteria a bit, but let's just say
> that while he has no problem talking about the bugs in other stuff, he
> doesn't appear to have any pages on the merits of bugs in _his_ stuff,
> or at least they aren't placed prominently enough for me to find.
>
> That having been said, I hate BIND.  The zone files are ridiculously
> picky syntax, and the "seperate caches and servers" makes perfect
> sense to me, although I may not want to have 4 servers up all the time
> just to keep DNS working.  Yes, you can use IP aliases.

Well, the argument is something like the monokernel vs. microkernel discussion.

BIND is the FreeBSD kernel of DNS systems, whereas djbdns is more like
a microkernel, being composed of small programs.

Also, lots of BIND administrators go to extreme lengths to implement
split-horizon DNS, which is basically just the DJB way, with lots of
BIND code paged out on systems where it is not needed, vs. not running
in the first place.

> tinydns does have its limitations though, like not being able to CNAME
> to an A record, instead having to expand everything to IP addresses.

tinydns can't CNAME? are you mad?

> So it's hard to create shorthands, like you can in BIND or, say,
> /etc/aliases (postmaster goes to root, root goes to travis).  You
> can't reassign things in a group.... still, I like the on-disk format
> of his databases.

His entire format is a shorthand compared to BIND's zone-file.

> > > I use some ports thingies which fix up his code to be consistent with
> > > the OS... they can distribute those, because it contains no DJB code.
> >
> > FWIW, the whole reason you can't redistribute DJB's code in binary
> > format goes against the lazy statement.  DJB is saying:
> >
> >   "Here is the source code to POSIX-ish software which should perform
> > as expected.  I want you to download the source code from me, so that
> > you know it isn't arbitrarily patched."
>
> i don't follow... DJB wants there to be one interface to his programs,
> so that he only has to write one piece of documentation.  And there's
> a ton of patches floating around, that he refuses to incorporate into
> the source (perhaps with good reason, I don't know), and so people
> can't patch it and redistribute it as, you know, packages that you
> could get through yum or apt or whatever floats your boat.  The best
> you can do is a bit more complicated, distribute a package that
> downloads his code, patches it, builds it, etc.
>
> I fail to see how his rationale refutes the lazy adjective.  He's
> forcing everyone to compile from source, to save effort on his part.

It's not to "save effort".  One man can only expend so much effort.
He's forcing you to compile from source to accomplish a goal.

I'm not sure I entirely agree, but I tell you what, RedHat slaughters
people's code and it gives their project a bad name.

-- 
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/