Re: [MaraDNS list] Rich whining about threads in 2007

WARNING: RANT FOLLOWS

I'm very sorry to send this to the list.  Rich: I'm sorry to use the
word whining.  I meant to send this to myself...but Gmail fucked up
and sent it to the list.  Probably a Freudian slip, looking back.  So,
excuse me while I make this personal and act unprofessionally.  Since
I'm not getting paid a living wage for MaraDNS, this is not a
professional product.

Anyway, now that this is out, I will go public about my personal
feelings about Rich's email.  I'm really frustrated with his attitude.
 Yes, I appreciate his help making Duende around 2003, but that was a
long time.  I looked it up, and back in 2007 he whined that MaraDNS
used threads.  So, WITHOUT GETTING PAID FOR MY WORK, a few months
later I started making, from scratch a non-threaded version of MaraDNS
(Deadwood).

Yeah, there were a lot of other reasons I did it.  Security holes
started getting discovered in MaraDNS, so I felt a rewrite to minimize
them further was in order.  I have never been happy with MaraDNS' old
threading model; it was always meant to be a prototype replaced with
something else.  But this email from 2007 was one of the motivating
factors for starting work on Deadwood.

My frustration with Rich is that he left the MaraDNS community.  His
feedback on using a different memory allocation scheme would have been
valuable in late 2007 once non-recursive caching Deadwood prototypes
were out the door.  I had a lot more free time back then than I do now
and Rich and I could have had the malloc() problem solved in 2008.

Indeed, Jean-Jacques Sarton contributed a lot of IPv6 code to Deadwood
in late 2007 and Deadwood's IPv6 support is a lot better because of
his support.

But, no, Rich left the community.  He did not read the MaraDNS blog
nor the mailing list when I started Deadwood:

http://maradns.blogspot.com/2007/10/groundbreaking-of-deadwood-project.html

He was not there when I was struggled to get the LRU cache to work in
late 2007; that alone took about a month.  He was not there when I
slowly made the program more and more Windows compatible.  He was not
there when I pulled my hair out implementing a non-threaded TCP client
that has no blocking system calls (it's not trivial, I assure you).
He was not there as I struggled to get incomplete CNAMEs and glueless
NS records to resolve correctly in Deadwood (CNAMEs alone were a
nightmare and I'm still ironing out bugs in that code, as seen with
the recent es-us.noticias.yahoo.com update)

I worked my butt off for free on and off for three years to get
Deadwood 3.0 with full recursion out the door.  He we are, five years
later.  I have given Rich everything he asked for back in 2007:
MaraDNS now no longer uses any threads.  So, what does he do?  He
complains about how MaraDNS and Deadwood handle malloc().

I'm sorry, Rich, but MaraDNS is never going to be a perfect program.
No, it's handling of malloc() is not perfect for edge cases when
malloc() actually fails.  There are probably a bunch of places where
Deadwood still dereferences a NULL pointer in the code, something I'm
slowly cleaning up.  There are certainly a number of other bugs in
Deadwood, including, yes, security bugs.  And, yes, Deadwood does not
support DNSSEC, so most users are probably better off using BIND or
Unbound.

But, you know, I'm proud of Deadwood.  It took me three years, but,
unlike Unbound and unlike BIND, I wrote an entire recursive DNS client
without (by and large) being paid for my time.  Unlike djbdns, the
only other volunteer-written finished DNS program [1], I still support
the program and take responsibilities for its bugs--even though I'm
not getting paid to do so.

So yeah, Rich, I'm sick and tired of you trying to justify why this
malloc() thing is such a horrible bug.  Because it isn't.  And, if
this really mattered to you, you would have been there in 2007 when I
was getting Deadwood off the ground.  I built that thing completely
from scratch.  Everything: The crypto lib, the LRU cache, the string
library, all of the DNS parsing functions, the non-threaded UDP and
TCP client.  I only got help for some little bits: The Windows service
code (but I had a functioning Windows service before I got any help)
and the IPv6 code (but I wrote all of the recursive code to handle
IPv6 myself).

You know, I am no Republican (as can be seen glancing at my Facebook
public posts).  But, they do have a legitimate point: There are takers
and there are givers.  Takers are people who are a net drain on
society; givers are the people who do the hard work to make things
happen.  Takers always complain that the givers aren't giving them
enough, or that the giver didn't do things the right way, or what not.

But, you know, I would rather be a giver and have all of the takers
whine about how I don't give them everything they want for free than
be a taker and a net drain to society.

This will be my last posting on the malloc() issue until when and if I
decide to fix it.  Rich could not wait for me to start writing the
non-threaded MaraDNS code before leaving the community back in 2007,
and he may not have the patience for me to deal with more important
issues before dealing with the malloc() issue.

- Sam

[1] PowerDNS does not count since it was originally a commercial product.

On Mon, Jul 23, 2012 at 11:45 AM, Sam Trenholme <[email protected]> wrote:
> http://marc.info/?l=maradns-list&m=117390206723939&w=2
>
> March 12 2007:
>
> On Thu, Mar 01, 2007 at 04:39:39PM -0800, RC wrote:
>> On Thu, 1 Mar 2007 16:49:54 -0600
>> "Sam Trenholme" <[email protected]> wrote:
>>
>> > What libc does the NetBSD on your 386 have.  If you're
>> > using glibc, consider using uclibc ( http://uclibc.org ).
>>
>> BSD != Linux
>>
>> The BSDs use their own libc.  It's somewhere around half as large as
>> glibc to begin with.  And I sincerely doubt it would even be possible
>> to get uclibc working on anything other than Linux.
>
> I have a libc that's pretty much kernel-agnostic (or maybe it's better
> to say agnustic? :) and something like 1/2 to 2/3 the size of uClibc,
> but with no pthreads implementation and I'd really rather not have
> one, ever. Any chance that mara will someday do recursion without
> threads?
>
> (In the mean time I could make an ugly minimal fake thread library to
> get maradns to work, but it would be nice not to have to do that.)
>
> Rich
>
> ----
>
> Yeah sure, but it took over three years to get there.  And now the
> twit is whining about how malloc() is handled.
>
> - Sam