Deadwood snapshot update

I am in the process of writing a roadmap where I detail how I will implement recursion in Deadwood. In addition, I have made a Windows binary of this release; Deadwood looks stable and, instead of running in debug mode looking for a crash that I never reproduced, I am running it as a service again.

Rant: Putting closure on a project

OK, one of my rants about open-source projects: A lot of open-source developers have a hard time putting closure on a project. For example, in the 1980s, Stan Shebs created a game called Xconq. He revised it and even rewrote it in the 1990s. In the early 2000s, he posted to the Xconq mailing list a roadmap for Xconq. A few years after this, Xconq languished; it was transferred to Sourceforge around 2005, with the last release being done on June 12, 2005.

In 2006, when someone asked if Xconq was dead on the mailing list, they were told “It's not dead, it's... resting.”. But, at this point, Xconq was dead; while a few CVS changes were done after this, the last CVS commit was done in 2007 and the project has been completely moribund since then.

Xconq is dead.

OK, big deal. A lot of open source projects come and go. My issue is this: As an open-source developer, I have a responsibility to put closure on my projects. When a given open-source project is something I realize I have no interest in working on any more, I let the project go, via a formal announcement. For example, I announced the end of my Kiwi Spam program on October 17, 2001; while I got a couple of emails expressing disappointment the project had ended, I never got a maintainer for the project. Recently, after making a few minor updates to ObHack, my fork of a random map generator for Doom-type games, I announced I would no longer be working on this code. There was enough interest in the code I was able to hand over maintenance duties over to Fritz, who has since then fixed a bug I never fixed and made a couple of releases of ObHack.

Closure is, IMO, very important for an open-source project. It tells the world “I’m responsible enough to know when to start a project, and, just as importantly, when to finish a project.” It allows the community of users to know you’re no longer interested in a project, making it possible for them to become the maintainer if there is still interest in a given project (such as what happened with ObHack).

Everything has a beginning and an end. A responsibly done open-source project is one that knows when it’s time to pack up and go home.

MaraDNS snapshot update: Documentation updated

I’ve updated MaraDNS’ documentation to have the DNS software and the advocacy pages be more up-to-date. In particular, the pages now acknowledge the existence of MyDNS-ng and there is now a very brief mention of GbDNS.

The MaraDNS tarball with these updated web pages can be seen in the 20090929 snapshot available at this location:

http://www.maradns.org/download/1.3/snap/200909/

New MaraDNS snapshot: FAQ updated

I've updated the MaraDNS FAQ to point out that MaraDNS doesn't resolve names in domains she sub-delegates; this is my follow-up to the concern brought up in this mailing list thread.

Opera users: Please tell what HTML I need to change on MaraDNS' FAQ page to get it to render properly (to get the box with the FAQ questions and answers to be to the right of, instead of below, the navigation toolbar on the left). This page renders fine in IE8 and Firefox 3.5; it's only Opera 10 that seems to have a problem with it (and other pages at MaraDNS.org render fine in Opera 10).

Update: Opera is having problems with the FAQ overflowing in horizontal size because it uses a slightly bigger font for fixed-width text. The offending <pre> tag is in this FAQ question. I'll see what I can do to fix the CSS to work around this Opera-specific issue.

Second update: Fixed. I've also added the question numbers to all the FAQ answers, and fixed an "otther" to correctly be "other".

ChessV 0.9.4 released

ChessV is a program written by Greg Strong that can play Chess and a handful of Chess Variants that I’ve been hosting for the last month or so. Since having the program available online has made people interested in working with its codebase, including having Muller convert it to work with Winboard, Greg Strong has worked on the code again and has just released ChessV 0.9.4, which is a bugfix release. The only new feature this version of ChessV has is a special binary that can interface with Winboard.

It is available here for download:

http://samiam.org/chessv

Spanish accents for US keyboard update

I’ve slightly updated the keyboard layout for my US-keyboard-with-Spanish-accents design to make it easier to input typographic quotes.

The page where I link to this keyboard layout is here:

http://samiam.org/typing.spanish.characters.html

And the download is:

http://samiam.org/es-us-20090926.zip

ObHack secret spoiler bug fixed by Fritz

A while ago I found a bug in ObHack 006b which I decided wasn’t worth the time to fix.

Well, Fritz has fixed this bug. I have a patch at the following location:

http://samiam.org/slump/secret-spoiler.patch

Note that this patches cleanly against 006b, but does not patch cleanly against Fritz’s ObHack 006.4 release. I am sure Frtiz’s next ObHack release will have this bug fixed.

I’ve been sick; Spanish keyboard update

I’ve been sick these last few days, so I haven’t been able to make as much progress with Deadwood as I would have liked. However, this morning I finally got around to updating my “US-English with Spanish accents” keyboard for Windows to have the ¡ work correctly, and to have a number of other symbols that I like to use (such as real quotes, as you can see in this blog posting).

The page where I link to this keyboard layout is here:

http://samiam.org/typing.spanish.characters.html

And the download is:

http://samiam.org/es-us-20090923.zip

Deadwood minor update

I have posted a minor update to Deadwood today. I'm just taking a couple of days to get psychologically in "finish Deadwood" mode and ramp up to spending all my geek time developing the code.

My goal right now, for Deadwood 2.5.01, is to have Deadwood able to look at a remote reply and determine whether:

• The reply is a complete reply; if there are any CNAME records in the reply, all CNAME records have a corresponding A (or whatever) record
• The reply is an incomplete CNAME reply
• The reply is a NS referral. All records with A or AAAA glue are converted in to IPs; all incomplete records (NS referrals without names) are stored as names
• The reply is a not there reply

The next bit of code I will write is the code to convert A and AAAA glue in to simple IPs.

Back to Deadwood

I have released a new snapshot of Deadwood today which is a minor update, and the first with code that will be used for the recursive part of Deadwood.

It can be downloaded at this location:

http://maradns.org/deadwood/snap/

Explanation of Schoolbook 2009 results

Due to an error in how I set up the time controls, Joker80 played very poorly. Joker80's performance in this tournament does not accurately reflect its true playing strength.

I will, for Schoolbook 2010, set up things to have more fair time controls. Right now, I'm looking at doing 40 moves in 20 minutes, with 30 seconds a move for engines that can only do "X seconds per move".

Schoolbook 2009 tournament

OK, never say never. I told myself I would put Schoolbook Chess, a variant I invented back in 2006, to rest. Well, while taking a break from Deadwood development, I discovered there are a number of computer chess engines out there that can play my chess variant, so I got permission from three makes of chess engines to enter the 2009 Schoolbook Chess computer tournament; the tournament was a six-game double round robin. The final results were:

ChessV 0.9.0 with time handicap: 3
TJChess10x8: 3
Joker80: 0

The games were Game/15 (all moves in 15 minute) games done on a Core 2 Dual 1.5 ghz laptop processor. A reasonable, but not extensive, effort was made to make sure no other processes were running during the tournament. Both engines played (and pondered) at the same time on the same computer.

TJChess and Joker80 played at Game/15 in WinBoard. ChessV 0.9.0 was given 30 seconds to make a single move.

Joker80 lost all four games it played, giving TJChess10x8 and ChessV 2 points each. In the ChessV-TJChess10x8 games, TJChess10x8 won once as white, as did ChessV.

I observe that Joker80 is usually stronger than TJChess10x8, but plays Game/15 very poorly.

In both TJ-vs-ChessV games, ChessV made a castling move TJChess could not recognize (in Schoolbook, it is legal to move the kind two or three squares while castling, and four squares while castling on the queenside). When this happened, I stopped the clocks, set up the board to have the castling move be done, restarted WinBoard, and gave TJChess10x8 10 minutes to complete the rest of its moves.

The actual games, including Zillions of Games save files of all games, are available at the following location:

http://samiam.org/schoolbook/

As an aside, people can download ChessV here:

http://samiam.org/chessv/

For people who do not have Zillions of Games, the save files are in a format that looks like a normal Chess score.

OK, I'm done with Chess variants for 2009. We'll see if I have a 2010 tournament.

Time to go back to developing Deadwood.

Deadwood news

I haven't made an update to Deadwood for a few days. I still have plans to begin the recursive code, and a pretty solid roadmap of how I will write that code, but life has come up and I just haven't had time these last two weeks to work on it.

What I have done, however, is test the Deadwood code. I have been running Deadwood in debug mode as my only DNS server for over a week and have not had a single crash. I also ran stress tests, again without a crash. The code looks solid; I think the September 9 update fixed whatever it was that was causing the crash I and an anonymous poster saw a week or two ago.

I hope to start work on Deadwood again in a day or two.

Deadwood minor update

I've updated Deadwood's Makefile to have a new .c source file: DwRecurse.c, where routines specific for implementing full recursion will be placed.

Deadwood roadmap: Implementing recursion

I am now ready to begin implementing recursion for Deadwood.

My plan is to write functions that handle the recursion, then revamp the code that handles in-flight requests to be able to handle recursive requests.

The first code I will write is a function that can compare DNS labels in a string to see if they are the same label. If they are, return a 1, otherwise return a 0 (-1 if some error happens while doing this processing).

After doing that, I will write a function that, if given a DNS reply with NS records, converts the NS records in to IPs if there is sufficient information in the AR section of a DNS reply to do so.

Once I do that, I will make a function that sees if a given reply is complete. A complete reply is a reply where the IP or whatever they asked for is in the answer they give us. A CNAME reply is complete if it includes the requested IP/whatever. A "not there" (SOA in NS section) reply is complete. A reply with an IP is complete.

A CNAME reply without the actual IP or whatever is incomplete. As is a NS referral.

Anyway, I hope to start work on this in a day or two.

New Deadwood snapshots

Well, I've run a bunch of stress tests with Deadwood, both with gdb and with Valgrind. There are no errors nor (as an anonymous commenter thinks there might be) any memory leaks.

Since this anonymous commenter reports a glibc error (which, sadly, they did not have a chance to save), this indicates that there might be a double-free() situation. What I have done is revised reset_rem() to always make sure a given memory location is a non-null pointer before free()ing it, and making the memory pointer point to null after resetting it. I have also revised the code to initialize all "local" pointers as null pointers before being used.

The snapshot with these changes applied can be downloaded here:

http://maradns.org/deadwood/snap/

The filename with an 'H' in it (head branch) is the version to look at.

OK, at this point, I'm closing the issue as being unreproducible. If anyone sees this and has a stack trace or any useful information, please let me know.

I have also revised the stable 2.3 branch of Deadwood by removing a spurious fflush from the hash (cache) code. Again, the download is in the same place, with an 'S' in the filename (stable branch).

Deadwood testing update

Yesterday, my copy of Deadwood 2.4.07 crashed in Windows, and I had to restart the service.

I looked at the Dr. Watson log, but the log had no useful information about why Deadwood crashed (it had an exception number of 80000007 and reported "ERROR -> ntdll!KiFastSystemCallRet: 7c91e514 c3 ret"), but appears to be something outside of Deadwood's code).

I ran some stress tests with Deadwood in Linux this morning and was unable to reproduce the crash.

I am going to close this issue as "unreproducible" unless anyone chimes in and reports Deadwood 2.4.07 crashing. It was probably caused by some bug in the Windows kernel or what not. If anyone sees this kind of crash, it would be best to include a stack trace, but I'll live if all you can give me is a Dr. Watson rerpot.

Another feature to add for Deadwood 3.0

Another feature I will need to add to Deadwood 3.0 before releasing it is giving it the ability to parse legal MaraDNS 1.x files.

This means I have to add every single variable MaraDNS 1.x has in mararc files and adding it to Deadwood. For the most past, the variables will be ignored and do nothing; the Deadwood man page will have, for each of these variables, a description of the variable and the note "This variable does not affect Deadwood and is only here so Deadwood can parse MaraDNS mararc files". For example, we will have a "dummy" csv2 dictionary variable (a pointer to a zone file in MaraDNS 1.2+) which will do nothing in Deadwood.

The most notable change I will have to make is adding support for ipv4_alias to Deadwood 3.0, which will result in the code which parses IPs being re-written.

MaraDNS and Deadwood roadmap

At this point, I have implemented, with one notable exception, all of the features MaraDNS 2.0 should have. The one and only feature I plan on still implementing is full recursion for the Deadwood engine.

The following roadmap is completely speculative; I might decide to stop MaraDNS development and only provide basic bugfix support for MaraDNS/Deadwood:

• Implement recursion for Deadwood, and release this as Deadwood 3.0 (Deadwood 2.0 will still be supported as the Deadwood 2.3 branch for people who need a very small program on embedded devices or a high-performance DNS load balancer)
• Release MaraDNS 1.3.15.01 which will be MaraDNS 1.3.14 with bugfixes applied.
• Release MaraDNS 2.0.01, which will be MaraDNS 1.3.15.01 with Deadwood 3.0, and all the old recursive code torn out.
• Announce EOL timeline for MaraDNS 1.3.07.XX
• Not implement any new features for MaraDNS for a period of six months or longer after 2.0.01 is released