Welcome to 2008!

Just letting people know I've finally caught up on my MaraDNS support emails; a couple of requests for better dangling CNAME handling, of all things. The real solution is this: If you're going to have dangling CNAME records, use a different DNS server for recursive resolving than authoritative resolving (1.3's ability to slice up the recursive space makes these kinds of setups easier).

Welcome to 2008 everyone! One of my resolutions is MaraDNS 2.0, which will not allow the same IP to be both authoritative and recursive, and that will have a completely rewritten recursive resolver.

- Sam

My Christmas gift

I'm giving everyone on the internet, for Christmas, a new stable release of MaraDNS: 1.3.07.08. This is a stable release; after over six months of testing, I feel comfortable declaring this branch the new stable branch of MaraDNS. This branch has a few new features compared to 1.2, most notably BIND zone file support.

I haven't uploaded it to Sourceforge yet, but it can be downloaded at the official web site.

I will support 1.2 until the end of 2010. Unlike 1.0, there will not be a "security fixes only" period of support. Both security and other critical bugs will be fixed for three more years. 1.0 is now only available as an indirect link from the download page and is only supported for critical security fixes.

I hope to answer the support email piling up in the next few days. The holidays are pretty hectic, however, so I can't guarantee anything.

- Sam

Merry Christmas everyone

Just letting people know that Christmas plans with family were more hectic than I thought they would be; I haven't had a chance to answer any support email or make the 1.3.07 stable release Friday the way I planned to. I will release 1.3.07 stable later on today, and will answer emails in the next few days.

- Sam

Quick MaraDNS support update

I'm madly getting ready for my trip to the US tomorrow; I haven't had time to answer the MaraDNS email that has been building up this week. I should, hopefully, have time Thursday to answer it. We'll see. Right now, I have three unanswered MaraDNS support emails, and one non-MaraDNS support email unanswered.

Thank you, everyone, for your patience, and for your interest in MaraDNS and my other geek projects.

- Sam

MaraDNS snapshot update

Up until today (yesterday on my laptop), when Deadwood-2 tried to connect to an upstream server, and the server didn't respond, Deadwood would just drop the packet on the ground, and the DNS resolver would have to send another packet.

No longer.

When the upstream DNS server doesn't respond, instead of just dropping the packet on the floor, Deadwood 2 now tries harder to give the client something they can use.

First, Deadwood tries contacting a DNS server again. Should the DNS server not reply again, then Deadwood starts trying extreme measures. Maybe there is an expired copy of the record in question in the cache; if so, we give that record to the end user. If not, then, as a last resort, we give the client a SERVER FAIL response so they know something is up.

All of this can be adjusted by dwood2rc parameters, which are documented.

It can be downloaded, as always, here.


- Sam

MaraDNS 1.2.12.09 release; snapshot update

I have uploaded MaraDNS 1.2.12.09 today. This backports some minor bugfixes in the 1.3 branch to the 1.2 branch. Also, the ICANN root server list is updated. Since there are no critical bugs fixed in this, I will continue to support 1.2.12.08 for a few more months, in order to give distributions time to update to 1.2.12.09. Here

I have also uploaded an updated snapshot for the development version of MaraDNS, available here

MaraDNS snapshot update

I have updated the development branch of MaraDNS today; I fixed a bug with the saving of the cache to a file, where it would not work if chroot_dir was not the current working directory; I also applied some minor fixes to the code contributed by Sarton. It can be downloaded here.

- Sam

MaraDNS snapshot update; Sarton's MaraDNS release

I have uploaded a new snapshot of MaraDNS today. This snapshot properly handles NXDOMAIN replies, and should handle truncation properly. In addition, it supports writing the cache to a file, and reading the cache from said file, and the user-id and group-id Deadwood-2 run as are now configurable in the dood2rc file. It is available here.

In addition, Sarton has made his own 1.3 release of MaraDNS, which is available here.

- Sam

Snapshot update: Deadwood-2 now has a working cache

I have been sick and pretty much laying in bed playing video games and working on MaraDNS the last three days.

Deadwood-2 is now a fully functional caching non-recursive DNS server. There's a lot of work still to be done, but we now have caching. Look at the code (and the TODO) in today's snapshot of MaraDNS.

In addition, Jean-Jacques Sarton has contributed a couple of bug fixes to some of the SQA tests.

The snapshot can be downloaded here.

- Sam

New MaraDNS snapshot; ObHack update

Just letting everyone know that, even though I was distracted by excellent GPL free video game Wesnoth and updating ObHack, I still made a little progress with the Deadwood-2 client. It's a little closer to being a non-recursive DNS cache that will, yes, have support for reading and writing the cache to a file (the file writing and reading code has already been written).

It can be downloaded here

---

I have also updated ObHack, adding two new features: You can now choose how inddors or outdoors the randomly generated map is, and you can choose to have an inital weapon (this is mainly for balancing mini deathmatch maps).

MaraDNS 1.3.10 and 1.3.07.07 released

Today I have released two versions of MaraDNS: MaraDNS 1.3.07.07, and MaraDNS 1.3.10. Full details on what has been updated can be seen in the changelog. Downloads are here (scroll down).

- Sam

Adding support for reading and writing the cache to disk

This week, I have been working on adding the ability to write the Deadwood-2 cache to a file, and read the Deadwood-2 cache from a file. Support for writing the file is complete. The file is very simple, and has the following format: For each element in the cache, write the key string to the file, followed by the value string object, followed by a 64-bit timestamp of when this record expires. Put less important (more likely to be deleted) elements at the beginning of the file and more commonly accessed cache elements at the end of the file (The reason for this is, when adding elements to the cache, more recently added elements are considered more important).

The string object has a very simple format in the file: A 32-bit big-endian length value, which must be a positive signed number (negative signed numbers mean the string has a length of 0), followed by the binary string. The timestamp is a representation of the 64-bit timestamp used by Deadwood, whose epoch is when the episode "Gambit" of the Blake's 7 television programme was first broadcast. Each second has 256 "ticks".

I have also fixed a bug in the hash used by the cache (it took me a couple of hours of fiddling around with Deadwood to find and get rid of it).

---

I'm also playing around with Doom Builder, an open-source Windows-only (Why doesn't Linux have a decent Pascal compiler?) program for editing maps. It's very easy to learn and use; I'm using it to make changes to a 9-map megawad generated by Oblige (for Heretic) in to one suitable for single player, deathmatch, and coop play.

I'm having a lot of fun with it; I just wish I had some buddies down here in Mexico to deathmatch with.

- Sam

Deadwood-2 hash core finished; ObHack update

I have finished the core hash that will be the Deadwood-2 cache this weekend. This is a data structure that is optimized for making a DNS cache. It's like the cache MaraDNS currently uses, but a much simpler, clener codebase with some features MaraDNS' current cache does not have. This code can now be expanded to make a caching forwarding DNS server.

The one feature I want to add to the core hash first, however, is the ability to write the cache to a file, and read the cache from a file.

The updated snapshot can be downloaded here

---

I also have an update to ObHack, fixing some critical bugs, and adding one "feature":

• Critical fix: Door statues are now less likely to make it impossible to finish a level w/o the "noclip" (OK, "kitty") cheat code.
• Critical fix: Being unable to find a door fab no longer causes ObHack to crash and burn (we just try with a different level)
• Critical fix: Now there's a high recursion depth limit when retrying to plan a level; this way, the program does not freeze in an infinite loop if it's impossible to find a plan that meets the requirements.
• Critical fix: An assert when making small deathmatch maps sometimes failed. Fixed; assert removed.
• Feature added: Heretic "full game" megawads now make E6M1-3, with E6M3 not having an exit (neither in single player nor deathmatch)

ObHack can be downloaded here

MaraDNS, ObHack, and font updates

I have updates for not one, not two, but three different projects of mine today.

---

My MaraDNS update has one change to the mainline code: l.root-servers.net IP has been updated. I am also working on the hash-generation code again for the "Deadwood-2" code, which will become a simple non-recursive caching DNS server. This is available here.

---

ObHack, my hacks to the excellent OBLIGE Doom random map generator, has a very minor update: Single player maps now have deathmatch starts. I added this feature since the small levels are small enough to be playable as 1-on-1 deathmatch maps with Heretic, and as 3-way or 4-way Doom/Doom2 deathmatch maps (all of those Doom fabs give players more little hidey holes). Also, Heretic (but only Heretic, alas) single player maps now have a couple of coop starts. In addition, I now have a Linux tarball, in addition to the Windows zipfile and a source tarball.

ObHack 002a (I'm not giving this a new number since the maps are identical to 002 maps, with only deathmatch and coop starts added) is available as a Windows zipfile here, as a Linux binary tarball here, and as a source code tarball here. An example megawad for Heretic is available here

---

I have made a minor update to my "Sandals" font, an attempt to make a readable screen font. This font can be downloaded here. I also have a version of this font that includes the bitmap version of a famous font made by a major software company here (I'm using an American server owned by an American since, while American law clearly states you can't copyright the bitmap version of a font, European laws are not clear on this matter).

- Sam

ObHack update

I have just uploaded a minor update to ObHack, my hack of Oblige. This is a bugfix only release; the bugs fixed are:

• There was a bug that would sometimes stop megawads of small episodes being created. Fixed.
• It was possible to have only one exit (either the secret exit or an exit going to the non-secret level) on a small map. Fixed; any map that should has a secret exit will now always have both a normal and secret exit
• In Heretic, at "Smite-Meister" (Heretic's name for "Ultra-Violence") diffculty, it is sometimes nay to impossible to get through the legion of golems and gargoyles to get at the cross bow. Workaround: There is now, at this difficulty level, always the gauntlets and the Chaos device at the beginning of the level; this makes it easier for the player to rush to the crossbow without unbalancing things too much
• Random numbers generated tweaked to make completely different maps than yesterday's ObHack release

The Windows binary is here and the source code here

My hacks to Oblige (a new Doom random map generator)

For a while now, I have been working on some FreeDoom-specific hacks to SLIGE called SLUMP. Indeed, I released an update to this program in late October.

Just this Monday, I disocovered a new (for 2007) Doom random map generator called OBLIGE (alternate link). I feel this map generator is a good deal more advanced than SLIGE and SLUMP. Unlike SLIGE/SLUMP, it supports:

• Real outdoor areas
• Balconies
• More detailed rooms
• No "null" quests: If you go somewhere and fight monsters, you will get some prize for your bother (such as a good weapon or a power-up)
• Heretic and Hexen support, in addition to real FreeDoom and Plutonia/Evilution support
• Real deathmatch and coop support
• A GUI interface

SLIGE only has a couple of features not supported by OBLIGE, such as variable-sized rooms, boss arenas (which I broke in SLUMP), and teleporters.

Unlike SLIGE, which codes everything in C, OBLIGE uses a scripting language called Lua for the map building core. The code is larger than SLIGE--my Windows zipfile of SLUMP, complete with node-builder is only 100k in size; OBLIGE is about six times larger. It's also slower; I can make a 32-level small megawad in SLUMP/SLIGE (complete with the nodes being built with BSP) in about a second; a megawad with the same size takes between 30 seconds and a minute to make in OBLIGE.

The nice thing about the Lua core is that it is far easier to customize the map generator. Indeed, I have done exactly that, and have made the following updates to OBLIGE:

• Smaller levels, especially when making deathmatch maps and when selecting a "small" level size.
• Allowing smaller levels caused some bugs to pop up, which I have addressed.
• It is now possible to finish an episode in Doom 1 or Heretic; E#M8 is now a normal level with a normal exit (no boss arenas though)
• Heretic fixes: No more doors that you can't open; you can now go to the secret level
• Build fix: If a level is unable to place a staircase, instead of crashing and burning, the generator will discard the level and try again.

I call my hacked version of OBLIGE "ObHack" (an expression used in a now-dead once great Usenet newsgroup called alt.hackers); the Windows binary can be downloaded here; the source code (nothing that compiled has been changed, however; only the Lua scripts) is here.

---

Some MaraDNS support issues: An automatically generated Debian bug saying it's hard to automate getting a new version of MaraDNS; one of the root servers has changed. Now that I've had fun making my ObHack fork of OBLIGE, I will work on these this afternoon.

MaraDNS snapshot update: Another bug fixed

I didn't have any time to work on Deadwood this weekend because:

1. Jan Hrdonka reported another bug which I had to find and fix (details below)
2. I was working on a new version of my tiny live CD distribution of Linux (Firefox had to be updated, etc.)
3. I spent some time with my girlfriend this weekend

The bug fixed in MaraDNS is that the CSV2 parser could not handle "blank" zone files--zone files with only SOA and NS records. I have fixed this bug in MaraDNS 1.3, complete with adding a regression to make sure the bug stays fixed, and have added a FAQ entry describing the bug and a workaround.

The reason for the bug is this: The CSV2 parser doesn't actually add the SOA record to memory until after all of the NS records, since the SOA record needs the NS records. The code adds the SOA records before adding the first non-NS entry. I forgot to add the SOA record after reading all of the zone in the case of having a zone with no records except SOA and NS records. I have added code to do this.

Since this is not a critical fix (there's a workaround for 1.2 users), this bug will not be fixed in MaraDNS 1.2

Deadwood and 64-bit systems; a highly scalable load balancer

People looking at the source code of Deadwood will observe some of the code is 32-bit specific; There are a lot of int32_t and uint32_t variables and functions in the code. The reason for this is to make porting to 64-bit easier; while not as efficient as using 64-bit ints everywhere, it's pretty much guaranteed that the code will run the same on a 32-bit and 64-bit CPU/operating system (my development machine has a 64-bit CPU, but is currently using a 32-bit operating system). However, one thing I have been thinking about is how to scale the code up to use 64-bit ints.

Most of the code can be pretty easily scaled up; use a 64-bit int instead of a 32-bit int for various constants. The random number generator, Radio Gatun, has both a 64-bit and 32-bit version.

The one bit of code that can't easily scale up quickly is the code that generates the 31-bit primes. I use a simple trial division that doesn't scale up. This code will have to be rewritten to use something fancier; Chris Caldwell has a lot of really good pages about how to quickly find a big prime. Using this method, along with this should be able to find a number that is almost certainly a 63-bit (18-digit) prime without being too much slower than finding a 31-bit prime.

---

It is possible to make a DNS load balancer that can handle far more than 3,500 queries a second. The bottleneck with Deadwood-1 is how I use TCP/IP (or, should I say, UDP/IP). The trick is to have both the load balancer and the upstream DNS servers have public and private IPs. The load balancer would get its query on a public IP, and send it over a private IP to the upstream DNS server. There will be a firewall in front of the load balancer that rejects all packets with private IPs coming in from outside.

For each upstream load balancer, there can be about 64000 connections at the same time. Given 10 upstream load balancers, thats 640000 connections a second. That's, with a seven second timeout, over 90000 DNS queries a second.

However, I'm not going to develop this code. Instead, I'm going to work on the caching DNS server. My plate is already full.

- Sam

Deadwood-1 updated; MaraDNS snapshot update

I have updated Deadwood-1 today to handle a higher load. This is done by having the port range used for binding to a secure local port be user settable, and by having the code that binds to a local port retry up to 10 times should it be unable to bind to a port the first time. I estimate that the Deadwood-1 load balancer can handle up to 24,500 simultaneous pending connections, or 3,500 connections a second at the default timeout of seven seconds (more if the upstream DNS server answers more quickly then seven seconds).

These changes are documented in a HANDLING.HIGH.LOAD document.

I have also made some revisions to the design of the hash in Deadwood-2, and have started writing code to store and retrieve entries from an array based on the hash value of dw_str objects.

- Sam

Deadwood-1 bugfix

I have just uploaded a new snapshot of MaraDNS today. In this snapshot, I have fleshed out the design of the hash for Deadwood-2 a little more, and have fixed a minor bug in Deadwood-1: When Deadwood-1 was overloaded, the "SERVER FAIL" packets did not have the correct length; I have fixed this and now the packets have the correct length.

I have also made a package with just Deadwood-1 called "Deadwood-1.00"; this package will be updated when (and if) I find and correct other bugs in Deadwood-1.

Both can be downloaded here

- Sam

Deadwood-2 started ; Qmail may soon become public domain

Today I am releasing the groundbreaking release of Deadwood-2. Deadwood-2 will be a simple DNS cache that caches requests made to a fully recursive DNS server. Last night, I wrote the code to implement the hash compression algorithm, making what I feel to be a reasonable balance between security and speed.

The has compression algorithm is a simple XOR with the data to hash, followed by a 32-bit multiply and a circular rotate (since mod 2^32 multiplies have problems with repeating patterns in the lower bits); the last data we XOR against is the length of the message. To make things reasonably secure, I am making the 32-bit number one multiplies by be a relatively secret 31-bit prime number; I have written a small program that finds a random 31-bit prime number, and makes a header file that determines Deadwood's default multiplication constant for making a hash out of a string. The script that creates the MaraDNS tarball automatically runs this program to change the random number.

In addition, the code will allow the user to reset this number to some other number, and the documentation will encourage the user to do so (telling them how to use RandomPrime to see a random 31-bit prime number).

The file can be downloaded here

---

I have some very good news: It looks like DJB is going to make Qmail public domain. I hope DJB soon does the same thing for DjbDNS; my main issue with DjbDNS, besides the hyperbolic claims like "DjbDNS has no security holes" (it does), is its license. I will retract my rant against DjbDNS when and if the DjbDNS code becomes public domain.

Thanks a lot for the birthday present, DJB! :)

- Sam

MaraDNS snapshot update

I just uploaded a snapshot with three minor errors in Deadwood-1 pointed out by Jean-Jacques Sarton corrected:

• I did not close the socket for binding to a local IP if bind() or accept() failed
• I did not close the dwood1rc file handle after parsing the dwood1rc file
• I did not close the random seed file after getting entropy from this file

It can be downloaded here

Note that none of these problems caused a leak; in all three cases, it was simply a case of a resource (a file or socket) being opened once and then never closed.

I will update the coding style to make sure these kinds of problems don't pop up again.

- Sam

Deadwood-1 is now finsihed

In today's snapshot of MaraDNS, all of the features that deadwood-1 is going to have are already implemented. Deadwood-1 is now frozen, and it is time to look at the roadmap for Deadwood again:

Deadwood-1: An IPv6-capable cross-platform TCP and UDP DNS load balancer.

The target for this was the end of October, and it was finished around the beginning of November.

Deadwood-2: A DNS forwarding cache. Target date: Before the end of 2007.

Deadwood-3: A full DNS recursive resolver. Target date: Mid-2008

And, in more detail, my plans for Deadwood-2:

Deadwood-2 will be a forwarding cache. This means that deadwood-2 will look for an answer in the cache, and, if there isn't an answer in the cache, it will contact a recursive DNS server and cache the reply it gets. The cache will have the following features:

• A custodian that deletes an unused cache entry if the cache is full. (MaraDNS' current cache has this)
• The ability to get an expired record from the cache if it is not possible to contact any upstream recursive servers.
• The ability to write the cache to disk, and read the cache from disk.

Deadwood now works in Windows

I spent about four hours this morning making a one-line fix in the Deadwood code so it would run in Windows. First, I installed and configured BIND in Windows; a non-trivial task since the BIND developers seem to be on a crusade to make BIND as difficult to configure and run as possible. Once I did that, I found out, the hard way, that services on localhost can only bind to the IP 127.0.0.1, and that binding to other localhost addresses doesn't work.

At this point, I had a working testing setup. I finally was able to debug the code, and found out that the reason TCP wasn't working in Windows is because you have to send() instead of write() on a TCP socket.

Once I fixed the code, I updated the documentation and coding style document to document the macros I use to make the same socket code work both in Windows and *NIX, so other people writing socket code will also write cross-platform socket code.

Anyway, the updated Deadwood source code that works in Windows can be downloaded here.

- Sam

MaraDNS Halloween snapshot

I have uploaded a new snapshot of MaraDNS today. This snapshot is a snapshot of the work I have done so far porting Deadwood to Windows. The UDP client works; the TCP client, however, has problems which I am still debugging.

Windows sockets are somewhat different from *NIX sockets; I have been reading the Winsock Programmer's FAQ and have downloaded Visual Studio C++ express with all of the MSDN documentation, which will hopefully give me the Windows version of things like "man 2 select".

Some of the *NIX code looks different since I'm making Deadwood portable. There is not a fcntl() visible in the main code; instead I have a macro, make_socket_nonblock() which does the right thing in both *NIX and Windows. There are some other changes: Sockets are not ints, but SOCKETs in Windows; you don't close() a socket, but closesocket() it. An error for sockets is INVALID_SOCKET. There's no inet_aton(), much less inet_pton(), so I just wrote a wrapper for inet_addr() that acts like inet_pton(). The socket code now looks like a strange mixture of Windows and *NIX socket code, with #defines in DwSocket.h making the Windows code look like *NIX code, and making the *NIX code look like Windows code.

My current project is to fix the TCP code in Windows.

As an aside, XP service pack 2 only has one loopback IP address, but Microsoft has a hotfix that fixes this issue; I needed to do this so I can test MaraDNS when offline.

You know, it's a mystery to me why IPV6, out of its 340282366920938463463374607431768211456 possible IPs, only allocates one for loopback. I mean, they could have allocated 16 IPV6 IPs for loopback; I'm sure 340282366920938463463374607431768211440 IPs is enough for non-loopback use.

Anyway, the latest snapshot can be downloaded here.

- Sam

MaraDNS snapshot update: Deadwood now has TCP support

I have added TCP load balancing support to Deadwood. Let me clarify that: Deadwood now compiles two programs, DwMain, which is the UDP DNS load balancer, and DwTcp, which is currently a general-purpose simple TCP load balancer.

What DwTcp does is quite simple: It listens on a user-settable port (53, or DNS, by default). When a client connects to it, DwTcp connects to the upstream TCP server on a user-settable port (again, 53 by default) and any data the client sends over TCP is sent, unchanged, to the upstream server, and any data upstream sends over TCP is sent, unchanged, back to the client.

DwTcp is currently not DNS-specific. It could be used as a HTTP or even SMTP load balancer. The main problem with DwTcp is, when used as a load balancer, is that the servers behind DwTcp will not be able to determine the IP connections come from--they will see the DwTcp server's IP, and DwTcp does not log connections.

My plan is to integrate the TCP code back in to DwMain, making DwMain both a TCP and UDP DNS load balancer. I have written the DwTcp code in a manner that should not make this too difficult to do.

I also plan on making the TCP code do some useful DNS-specific things. One useful feature, for example, would be to look at the incoming TCP packet. If the request is not an AXFR or IXFR request, send the question over UDP and, if the UDP reply is not truncated, convert the UDP reply back in to a TCP reply. If the packet is truncated, try again over TCP.

However, other things are more important. I am currently working on Winsock support and getting the code to run as a native Windows binary with MinGW32. Both the UDP and TCP code compile in Windows, but the socket() call fails in the TCP code. Since I didn't have Winsock documentation at home, I couldn't resolve the issue.

After finishing that, I want to add ip-based ACL support which will allow the load balancers to restrict the range of IP addresses that can connect to the load balancer.

MaraDNS snapshot update

Jean-Jacques Sarton and myself have added IPV6 support to Deadwood. This is an optional compile-time flag, since a number of systems don't have IPV6 support yet (Cygwin and Mingw32, *cough* *cough*). In order to enable IPV6 support, add '-DIPV6' to the flags when compiling Deadwood, as in:

        export FLAGS='-Os -DIPV6'
        make

The IPV6 support adds, in DeLi Linux 0.7.2, 356 bytes to the code when disabled, and 708 bytes to the code when enabled. The binary is now 14,448 bytes in size when compiled in DeLi 0.7.2 with the '-Os' flag, IPv6 disabled, and the binary stripped. With IPv6 enabled, the binary is 14,800 bytes in size. Of course, keep in mind that uClibc is also bigger when it has IPv6 support.

In addition, it would seem that, somewhere in the 1.2 development cycle, I broke the echoing of the RD ("Recursion Desired") bit in the DNS header. This has been restored. Also, looking at that code, I realized it wasn't thread-safe, so I made the code thread safe. Also, it would seme that not only do some brain-dead embedded DNS programs check the RD bit in the DNS header, they also check the RA ("Recursion Available") bit (neither bit should be looked at whem getting a DNS reply, but oh well). So, I've hacked things so MaraDNS replies with a packet with the RA bit off if sending an authoritative reply, and the RA on if sending a recrusive reply. Not 100% ananally RFC-compliant, but should fix the problems seen with braindead DNS programs.

And yes, the RD and RA fixes have been backported to the 1.2 branch, and should be a part of the next 1.2 release (mid-December, barring a critical security problem).

The MaraDNS snapshot can be downloaded here

MaraDNS snapshot update

Well, I've implemented a secure random number generator for the new Deadwood code. Last time, with MaraDNS, I used AES, which became an AES variant in late 2001. The problem with AES is that it may have cache timing issues with some CPUs, since it uses table lookups to get indexes based on key information. I revised the code to work around this, at the expense of making the code about three times slower. Also, the code is fairly large and block ciphers are not the best building block for making random streams.

This time, I am using a new stream cipher/cryptographic hash algorithm called "Radio Gatun". Radio Gatun is a new and novel cryptographic primitive: It's a cryptographic hash that can take an input of any length, and generates, from that input, a hash of any desired length. It's also (if not officially) a stream cipher that can take a key of any desired length.

Radio Gatun is a derivative of a late 1990s stream cipher/hash construction called PANAMA. PANAMA's cryptographic hash creation was broken, but it's (as far as we know) still as secure stream cipher. Radio Gatun is not as fast as PANAMA, but appears (so far) to be both a secure cryptographic hash and a secure stream cipher primitive.

Radio Gatun, in theory, can use words of any length from one bit to 64 bits. In practice, test vectors only exist for the 32-bit and the 64-bit versions of Radio Gatun. The Deadwood code is using the 32-bit version of Radio Gatun, but this can be fairly easily changed to use the 64-bit (or, if one wants, the 16-bit or even 8-bit) version by changing two defines in DwRadioGatun.h, and rewriting the dwr_rng() function.

Radio Gatun is a good deal more compact than AES; the entire library fits in under 2k (2048 bytes) when compiled with -Os; compare this with the 12k or so the AES-derived library uses.

---

I have also created a basic SQA test, and fixed some bugs. There was a minor bug in the FSM definition that made it so dwood1rc parameters could not have numbers in them, making ipv4_bind_addresses not work; this has been fixed. Another bug is that I did not use the socket bound on port 53 to forward the remote reply back to the local user; this made Dig unhappy, since Dig checks the port number of the reply.

In addition, I have added "DwMain -f dwood1rc" style argument parsing.

Oh, oh, there's some under the hood changes. DwMain.c is now a very small file; DwSocket.c has all of the functions that use socket-specific code (and no functions that don't use socket code) and DwSys.c has the rest of the functions. This way, adding DNS-over-TCP, ipv6, and WinSock support only requires changing the DwSocket.c file.

The DwMain binary, when compiled in DeLi Linux 0.7.2 with the -Os flag and stripped, is currently 14,092 bytes in size.

MaraDNS 1.3.07.06 and 1.3.09 release

Today I release not one, but two versions of MaraDNS: MaraDNS 1.3.07.06 and MaraDNS 1.3.09. These are both beta-test versions of MaraDNS; the changelog is here. Downloads of these versions of MaraDNS are available here (Scroll down to see the 1.3 releases).

I also have made a tiny version of the Radio Gatún hash function available under the same license terms as MaraDNS (BSD w/o advertising clause), which is available here.

- Sam

MaraDNS update; Ubuntu rant

OK, I have uploaded a new snapshot of MaraDNS today. This fixes a bug in the zoneserver where it did not properly inform the user they have an incorrect IP in their mararc file, and also, the Deadwood project now does something useful.

If you look in the directory deadwood-1 off of the Snapshot's directory, you will observe a number of files. This is a working (if very basic) DNS load balancer. Basically, use "make" to compile the code, and then edit the dwood1rc file to configure the load balancer. The dwood1rc file uses the same general format as a mararc file, but only supports the following three parameters:

1. bind_address This is the IP address we bind to
2. chroot_dir This is the directory the program will run from
3. upstream_servers["."] this is a list of DNS servers that the load balancer will try to contact

Basically, what the server does is listen on the address specified in bind_address. When it gets a DNS query, it will make sure this query is a query (an not an answer), then send the query, as is, to one of the servers listed in upstream_servers["."]. It will then wait up to 7 seconds for an answer from the upstream server. When it gets a reply, it sets the "this is an answer" DNS bit, then sends the reply back to the original client.

The load balancer can only handle 32 pending replies from the upstream server before it will no longer process incoming replies. When the server is overload, it currently silently drops packets.

No attempt is made to randomize the query ID nor the source port of the query when forwarding the query.

Only ipv4 is supported; there is no ipv6 support. Only DNS-over-UDP is support; DNS-over-TCP is not supported.

I plan on, before moving on to implement caching, to add support for randomized query IDs and source ports, to add user-configurable maximum wait time and maximum allowed number of pending queries, to have the server send "server fail" DNS messages if the load balancer is overloaded, and supporting DNS-over-TCP.

In the meantime, people may want to look at the Deadwood code and give me suggestions on how I can improve this code. As always, the snapshot can be downloaded here

---

It would seem that Ubuntu does not come with a firewall by default. Ugh. I'm really disappointed that, not only does Ubuntu install a bunch of services that bind to ports, but they don't bother to install a firewall to protect the system. This is really insecure. What I have done is go in to /etc/rc2.d and turn off all of the services that bind to ports. I have also downloaded an article on installing a firewall in Ubuntu, and am working on getting a firewall going.

In the 1990s, RedHat had a lot of security problems. They finally woke up and RedHat and Fedora now come with a firewall when you install the OS. Ubuntu needs to learn from RedHat's lesson.

MaraDNS snapshot update

Jean-Jacques Sarton has added the ability for askmara-tcp to send IPv6 packets. I haven't tested the code, but MaraDNS compiles without any warnings. The updated snapshot can be downloaded here

Note: MaraDNS 1.3.07 will not include RPMs

I'm letting MaraDNS users know that future releases of MaraDNS 1.3.07 will not include RPM files. The reason is because my current computer does not have a system for building RPM files; I am using my older computer to build the .rpm files, which runs CentOS 3.

Instead, I will have a script update the .spec file with every release of MaraDNS, and rpm users can build their own .rpm files thusly:

• Copy the file build/maradns-version.spec to the directory /usr/src/redhat/SPECS.
• Copy the maradns-version.tar.bz2 file to /usr/src/redhat/SOURCES
• Become root and enter the /usr/src/redhat/SPECS
• As root, do this command: rpmbuild -ba maradns-version.spec.
• You should now have .rpm files in /usr/src/redhat/SRPMS/ and /usr/src/redhat/RPMS/i386 (or whatever)

I will leave the building of .rpm files to people who are experts at making rpm packages, and concentrate my efforts on making the best possible recursive DNS server; my current project is a complete rewrite of the recursive code.

MaraDNS snapshot update

I have uploaded an updated snapshot of MaraDNS today. In this update:

• askmara can now send packets over ipv6 if MaraDNS is compiled as an authoritative-only DNS server (Thanks, Mr. Sarton)
• A script now automatically updates the .rpm spec file
• I have made a lot of progress with the code that will become the new recursive code. We will hopefully have a working load-balancing DNS server with the new recursive code by Friday.

It can be downloaded here.

MaraDNS snapshot update: ipv6 works again

I have uploaded an update to the MaraDNS snapshot. Here are the changes since the last update:

• I broke ipv6 in the last snapshot release when I changed MaraDNS to compile with no warnings when compiled as an authoritative-only server. Fortunatly, my regressions very quickly caught this bug, and I made the one-line fix to get ipv6 to work again.
• Mr. Sarton has added ipv6 support to the askmara-tcp tool (He's actually added a lot of ipv6 support, which I'm slowly making part of the post 1.3.07 code as I get time to evaluate his patches).
• I have added some tests to make sure we can use DNS-over-TCP to send packets over 512 bytes in length (not a big real-world issue, since MaraDNS has full RFC2181 DNS truncation support)
• Some slight updates to the documentation included with the deadwood code

The code can be downloaded here.

I hope to have time Sunday to update Deadwood some more, and release another snapshot Monday.

- Sam

MaraDNS support email works again

Just letting everyone know that MaraDNS support email works again, and that people can send me MaraDNS support questions via private email from the MaraDNS contact page.

I won't have an update to the MaraDNS code today; I have been too busy with real life to work on MaraDNS for the last couple of days. I may have a minor update for Friday; we'll see.

I should have time Sunday to work on MaraDNS again.

- Sam

MaraDNS snapshot update

I have been hard at work on the Deadwood project these last few days. This is the code that will eventually replace MaraDNS' recursive core. I have managed to accomplish the following with the Deadwood code this weekend:

• I created a finite state machine tokenizer that can convert a FSM definition in to easy-to-parse tokens.
• I greated a FSM definition that can parse mararc files.
• I created a parser to parse the tokenized mararc FSM definition.
• I wrote a wrapper for the FSM parser to parse mararc files and store the parameters in memory for access by other parts of the Deadwood project.
• I added some capabilities to the DwString library so it is able to do all of the above.
• I wrote a coding style document for the Deadwood code.

I have also made some minor revisions to the main MaraDNS code:

• I have added an #ifdef that should resolve the problem with running MaraDNS on cygwin
• I have removed the one warning visible when MaraDNS is compiled as an authoritative-only client (with ipv6 support to boot)

Anyway, the snapshot can be looked at here.

---

I am aware that MaraDNS support email is currently not working. I have let the relevant people know, and things will hopefully be resolved in a few days.

Groundbreaking of Deadwood project

In today's snapshot of MaraDNS, I have started a new project that I have been meaning to do for years: A complete rewrite of the recursive half of MaraDNS. I am calling this project the "Deadwood" project. My goals is to, step by step, make a non threaded recursive DNS server. The three stages of the Deadwood project will be

• Make a basic "load balancing" DNS server that takes incoming DNS requests, sends the request on to one or more "upstream" DNS servers, and give the reply from the upstream server back to the client.
• Make a basic caching DNS server, that will need the upstream server do all the heavy lifting of making the recursive query, but that will remember queries so the upstream server doesn't have to do as much work
• A full-featured recursive server, like what MaraDNS now has

Today, I have begun the first step; it is, if you will, the "groundbreaking" (first) release of the new MaraDNS recursor. What I have done is make a simplified buffer-overflow resistant string library that has all of the parts of MaraDNS's string library that I actually use, but none of the stuff that I implemented but never use. My next step is to make a mararc parser, and then I will make the DNS client.

It is part of the lastest MaraDNS snapshot available here, in a directory with the title deadwood-1

While I have wanted to do this for years now, I'm glad I waited because people have done a lot of testing with MaraDNS and found some minor security problems. I now know what coding mistakes to avoid to not even have those minimal kinds of security problems.

MaraDNS snapshot update

I have been updating the MaraDNS snapshot for the last couple of days. Fairly minor updates; yesterday I added a test to make sure the zoneserver works. Today, I added a test to make sure the ipv6 binding works when MaraDNS is compiled as an authoritative-only client. It can be downloaded here.

- Sam

Announce: C-40 interactice fiction contest

After the success of the Commodore 32 machine shipped in 2004, we have decided to upgrade this machine for 2007. The new C-40 machine is available at an even lower price than the 2004 Commodore 32, has an easier-to-read LCD panel display, and is far more portable than our earlier model.

While completely compatible with the Commodore 32 games, the C-40 also has an expanded memory. This machine has some 40960 bytes of memory that game cartridges can use. Like the Commodore 32, this C-40 can play both z3 and z5 z-machine games.

We are looking forward to shipping some games that will take full advantage of the C-40s large memory for the Christmas season this year. This is where you come in: We are introducing a C-40 contest where anyone on the internet can make a z3/z5 z-machine game that fits in 40960 bytes or less. Unlike the previous Commodore 32 contest, one is not required to use Inform nor the minform library to make entries for this contest. Any system that the contest entry writer can come up with to pack as much adventure in 40960 bytes is welcome, including home-grown parsers and optimized assembly language. In addition, games are not limited to text adventures; ASCII arcade games are welcome, as long as they can be played on the C-40's 80x24 display.

We are also looking for judges to judge the games in the contest.

The rules of this contest are:

• Any kind of game that is a Z-machine version 3 or Z-machine version 5 game that fits in 40960 bytes or less is welcome.
• All games submitted to this contest must be original for the contest.
• All games must run correctly in Frotz 2.43 using an 80x24 display.
• All games must be submitted on or before Monday, December 4 2007.
• All games are to be submitted to me via email.
• Any entry submitted to the C-40 contest must be one where there is permission to redistribute the submission on my webpage and on the IF archive.

As a matter of convenience, I have version 6.15 of Inform along with the mInform library available for people who want to use this SDK (Software development kit) to make entries for this contest available here (400k .zip file).

This will run in both *nix systems (including Mac OS X) and on Microsoft Windows. Windows users: You will need to create a directory named \tmp before being able to compile programs with the inform.exe program included in the zip file.

Based on the Commodore 32 entries, one should be able to fit a small 10-room adventure in the 40960 bytes allowed in the C-40 contest, or, with some clever programming, a large 25-room adventure.

Of course, one could opt to make a huge Scott-Adams style adventure with dozens of rooms. Or, for that matter, one can make a very extensive ASCII ART arcade game in 40960 bytes (but remember the 80x24 rule!).

- Sam

MaraDNS snapshot update

I have made some improvments to MaraDNS in today's snapshot

• MaraDNS compiles again (albeit with one warning) with configured to be authoritative-only ( ./configure --authonly; make )
• Tests revised to pass when running a snapshot version of MaraDNS
• New script that only runs the tests relevant for the authoritative-only compile of MaraDNS added

It can be downloaded here.

Maradns snapshot update

I have uploaded a snapshot of MaraDNS today. In today's snapshot, I have added support for AIX contributed by Alfred Reibenschuh. I have also added a large number of tests to make sure most mararc parameters work, and fixed a couple of ocscure mararc parameters that were not working correctly.

It can be downloaded here

- Sam

Brief reviews of all of the "Commodore 32" contest entries

Here are my brief reviews of all six of the Commodore 32 contest entries from three years ago. Since these have already been reviewed by others, I will keep my review very brief.

1. Amusement Park. This is easily the best of all of the entries. It has some 15 rooms and a number of different puzzles to keep you challenged. Even after finishing all of the rides, there is the additional challenge of figuring out how to get all 100 points. Some reviewers criticized the writing, but it's fine for a text adventure. Indeed, this is a story of someone remembering fondly going to an amusment park, and how those memories are slowly dying. There are no significant bugs; I thought not being able to get the last five points was a bug, but figuring out how to do it simply requires paying close attention to the game's text.
2. Downtown Train. Second place. I felt this one had the best writing of all of the Commodore 32 entries. I really liked the ending and the love story in this tiny adventure. Only three rooms and one challenging puzzle.
3. Turning Point. Third place. This game also has good writing, and a couple of nice puzzles. However, maybe I've played too many text adventures, but I was able to solve this fairly quickly. The game only has six locations, and not as many puzzles as Amusement Park. Besides that, it's a really fun tiny adventure.
4. Endgame. Fourth place. This would have been a fun little one-room adventure, but had too many bugs for me to fully enjoy it. For example, "erase" is not correctly implemented, which confused me until I figured out to use the verb "remove". Also, as a Christian, I found the 500-point ending a little offensive.
5. Zombies. This would have been a fun adventure, but has too many bugs. This adventure really needed to fuller testing and bugfix cycle.
6. Paparazzi. This is why you do not use Inform 6.30 to write a tiny 32k adventure. There is a lot of bloat in 6.30 that 6.15 (the compiler all the other entries used) doesn't have; the author of this game simply did not have enough room left to make a compelling adventure.

MaraDNS 1.3.08 and MaraDNS 1.3.07.05 released

OK, I have a tradition of releasing new versions of MaraDNS on solstices. This time, however, I'm releasing a new version of MaraDNS on an equinox. Basically, new code is being contributed to the MaraDNS codebase: Mr. Sarton is improving ipv6 support and I just added NAPTR support. However, these changes can not be integrated in to the Beta-test release of MaraDNS, since the only changes in that branch are bugfixes, new SQA tests, and documentation updates.

So, I have created a new development branch of MaraDNS. This is where new features, such as NAPTR and ipv6 are being added to the code. These features have not been fully tested and I can not guarantee that development releases will even compile. However, they feature new features that some people may want to use.

Today I have branched off MaraDNS 1.3.08 (the development branch) and 1.3.07.05 (the updated beta test release). The files can be downloaded from the MaraDNS download page here.

- Sam

Interactive Fiction review: Inevitable by Kathleen M. Fischer

OK, last night, as I was relaxing, I finished Inevitable (the version submitted to Spring Thing 2003), a game by Kathleen M. Fischer I have been playing all week. Here is my spoiler-free review of the game: The puzzles are not very well designed. There is, for example, one puzzle where you have to do five different steps (two in "Easier" mode) to solve the puzzle. If you don't do any of the steps correctly, the puzzle is not solved. The game does not give you any hint you have done any of the five steps, and one description of an object is poorly written, making it very difficult to solve the puzzle in question.

If the description of that one object was better written, I would have been able to solve the one puzzle without cheating. And yes, the post-SpringThing version of this game has the same problem with the item description in question.

I had to resort to using txd to decompile the game to solve this one puzzle.

Once this puzzle was solved, I was able to finish the rest of the game within 30 minutes.

The game feels rushed, particularly near the end. It starts off with giving you wonderful puzzles, and memories that give the game real flesh, but then degenerates in to a very frustrating puzzle-fest, where you have to solve about 10 puzzles without being able to visit very many new locations when solving each puzzle, and where you get no real new memories after solving these same puzzles.

A lot of the mythology of the universe of this game is completely unexplored. For example, (minor spoiler) we never get a hint about why the bad guys massacred so many people in the past; something which I felt should have been answered in the game. I also did feel the story, as I was finishing the game, was not very compelling.

On a 1 to ten scale, I give this game a five. Minus three points for poor puzzle design, and minus two points for not having the story in the conclusion of the game as compelling as the story near the beginning of the game.

MaraDNS snap update; MaraDNS 1.3.07.05 and 1.3.08 coming out tomorrow

I have updated the snapshot release of MaraDNS today to include some updates to the FAQ included with the 1.3 branch of MaraDNS. I have also added (completely untested and probably currently not working) support for the NAPTR record, as requested on the MaraDNS mailing list. The update to the FAQ will be included in 1.3.07.05; the NAPTR code will only be in 1.3.08.

I plan on releasing MaraDNS 1.3.08 and 1.2.12.05 tomorrow.

I have also made a snapshot for the 1.2 branch of MaraDNS, which integrates the update maraconf.sh code in this branch, and which fixes a one-byte typo in the FAQ.

The 1.3 snapshot can be downloaded here and the 1.2 snapshot can be downloaded here.

As an aisde, I have removed all unsupported older versions of MaraDNS from the maradns.org webpage; the only versions of MaraDNS available on the webpage are recent snapshot releases and the three supported releases of MaraDNS: 1.2.12.08, 1.3.07.04, and 1.0.41.

- Sam

MaraDNS snapshot update

This weekend, I silently uploaded a new snapshot of MaraDNS. Today, I have slightly updated that snapshot. This snapshot has some new code:

• IPV6 support added to askmara and fetchzone by Jean-Jacques Sarton.
• maraconf.sh updated

Since this is new code, I will be branching the MaraDNS tree when I release 1.3.07.05 and 1.3.08 this Friday. Basically, 1.3.07.05 is MaraDNS 1.3.07.04 + updated tests + bugfixes + updated documentation; 1.3.08 will be 1.3.07.05 with Sarton's ipv6 code added. This way, people can contribute new features to MaraDNS while I prepare the 1.3.07 stable release of MaraDNS, which I plan on releasing on December 21st.

It can be downloaded here

- Sam

New MaraDNS snapshot; help for people trying to install Linux on a 1420

I have updated the MaraDNS snapshot today. This snapshot has a couple of fairly minor changes:

• There is a new mararc dictionary variable, future that will allow new parameters to be set in future versions of MaraDNS, but still have the mararc file parse in MaraDNS 1.3. For example, let us suppose a future version of MaraDNS sends NOTFY packets when a zone file is updated. Then we can have a mararc variable send_notify_to, and for people who wish to use the same configuration file in MaraDNS 1.3, future["send_notify_to"].
• I have doubled the default amount of memory allowed to be allocated, since I saw MaraDNS hit the maximum the other morning, when I was on a broken internet connection

It can be downloaded here

---

For people trying to get their Dell Inspiron to work in Linux, Dell now has an ISO image available for installing Linux on to one of these computers.

- Sam

On limiting the size of an interactive fiction game

I have been reading some of Emily Short's essays. One essay that, in particular, stood out to me is one on Interactive fiction geography. In this essay, Emily talks about some ways to put a border around an IF map, and how to make this border exist without making the player feel claustrophobic. She suggested some ideas for a boundary; I have a couple other ideas for a boundary in IF:

• One, which I implemented in Desert Adventure, is to have the boundary be one where the player realizes they will die if they go past the "edge" of the map. Basically, I have a "lost in desert" location where all the exits take the player back to the start location, with the message "Lost in the desert, I walk towards the oasis, the only landmark I can see." seen when they travel from this location.
  
• Another is to not have a boundary at all. How is this done? With a random map generator. Basically, have the computer generate interesting scenery which extends forever no matter what direction the player goes. The problem with this approach is that there is a limit to the kinds of maps random map generators can make. Basically, a random map generator can make a reasonable approximation of natural scenery, or maze-like maps. Also, a computer can't make the kinds of clever puzzles that are the hallmark of most kinds of interactive fiction.

  What a random map generator can generate are "hack and slash" maps; they can work when the objective is to, for example, kill monsters and collect treasures. Random map generators can also make basic "find the key" puzzles; and possibly even "examine things to find stuff" puzzles, but nothing really more complicated than that.

  I can see something like this for a role playing game, where the player has skills and hit points, and has the objective of killing monsters in order to acquire more skills and hit points, which allow them to kill even nastier monsters.

  However, I am not sure whether this kind of game will appeal to many interactive fiction players. It's a different game, and we knew this as far back as 1981 (Such as Scott Adams' "If you like to kill monsters play 'MACES & MAGIC'!" comment in Savage Island).

Anyway, some food for thought for game designers.

You can now play Desert Adventure online

You can now play Desert Adventure online if you have a Java-capable browser. :)

Click here to play this game

- Sam

MaraDNS snapshot update; Desert Adventure updated

I have uploaded a new snapshot of MaraDNS today. In this updated snapshot, Jean-Jacques Sarto has added support for, and I have documented, FQDN6 records, records that allow you to set up "reverse" and "forward" DNS support for IPV6 addresses.

I have also changed the formatting of the source files: the .c and .h files no longer have tabs, but use multiple spaces instead. This is something I should have done before releasing 1.2; it makes the source code look consistant across different editors. since this change means that it will be more difficult to use patches for older versions of MaraDNS that use tabs instead of spaces. At least I did it before 1.3.

Finally, I have added a few more SQA tests.

---

I have also updated my Desert Adventure game. I made one puzzle a little easier and another puzzle a little harder (But help is now available for this harder puzzle). Also, I fixed one bug and revised the compile script to remove more unused whitespace, allowing more adventure to fit in the same amount of space.

In addition, I revised ScottFree to give SavedRoom initial value of 1 and added a z-machine version of Desert Adventure (created with scott2zip, revised by myself, and compiled with an ancient version of Inform) for people who don't feel comfortable compiling ScottFree.

The update is available here (80k zip file).

Making MaraDNS even more secure

Now that MaraDNS has had over five years of real-world testing, and a few minor security problems (nothing worse than denial of service) have been found, here are some thoughts on how to make a program have the minimum number of security problems possible:

• Do not add features to a program after a design/requirement spec for the program has been written. All three MaraDNS security problems existed because I added features to the program after the basic program was done. Namely:
  
  
  
  
  1. I added round-robin rotation to the codebase after the basic authoritative-only DNS server was written. This added a denial of service security bug to the code.
     
     
  2. I changed the authoritative code to give out nicer messages when invalid DNS packets were received. This added another denial of service security bug to the code.
     
     
  3. I added ipv6 to MaraDNS. This was the cause of a third, and final (so far; knock on wood) denial of service security bug to MaraDNS.
  
  
  It also looks like the one known denial of service security bug in djbdns was the cause of a similar feature creep; basically, the existence of TCP code in dnscache caused the bug.
  
  
• Code in a style that make memory leaks difficult. For example, make sure there are a limited number of strings allocated at the beginning of a function, and use a variable to store the return value. Use gotos for error trapping if programming in C, since C does not have real Java-style error trapping, nor C++'s automatic destructors.
  
  If a block of code needs a temporary string, declare the string at the beginning of the block and don't leave the block without zapping the string. For example:
  
  

  
          function() {
                  /* This is *always* the first part of a 
                   * block that allocates
                   * strings.  Yes, we allocate every last 
                   * string *before*
                   * doing anything else */
                  overflow_resistant_string *s1, *s2, *s3;
                  if(allocate_memory(s1) == 0) {
                          return ERROR;
                  } else if(allocate_memory(s2) == 0) {
                          deallocate(s1);
                          return ERROR;
                  } else if(allocate_memory(s3) == 0) {
                          deallocate(s1);
                          deallocate(s2);
                          return ERROR;
                  }
  
                  int return_code = OK; /* If you're using 
                  * GCC2 still, upgrade */
  
                  /* Now we run normal code */
  
                  /* Lots of snipped code here */
  
                  if(do_something_important == FAILS) {
                          return_code = ERROR;
                          goto leave_function;
                  }
  
                  /* Lots more snipped code */
  
                  if(weve_already_funished == YES) {
                          return_code = YIPEE;
                          goto leave_function;
                  }
  
                  /* More snipped code */
  
          leave_function:
                  deallocate(s1);
                  deallocate(s2);
                  deallocate(s3);
                  return return_code;
          }
  

  
  
  
• Use buffer-overflow resistant strings. Check; this is why MaraDNS (knock on wood) hasn't had a security problem worse than denial of service.
  
  
• Use as many operating system features to sandbox the code as possible. Check; this is why MaraDNS is in a chroot() environemt running as the "nobody" user (it is also possible to have MaraDNS run as a maradns-specific user if desired)
  

Desert adventure: A new tiny interactive fiction story

I spent all day yesterday making an interactive fiction story called Desert adventure. This is classic late-1970s early-1980s adventure: Our adventurer is all alone in a desert near an oasis, and has to find the treasures.

This is an original adventure for the Scott Adams' adventure interpreter language, and is, to the extent of my knowledge, the first original adventure for Scott's language in over 20 years.

While Inform, Adrift, and what not are more capable than Scott's language at making complicated adventures, Scott's system has the advantage of being extremely compact, being originally designed to run on a system with only 16 or 24 kilobytes (yes, kilobytes) of memory. For example, my implementation of Cloak of Darkness for Scott's system is under 3,000 bytes in size. Compare this to the Z-machine version of the same game, which is over 50,000 bytes in size.

The program to run Scott Adams' adventures is under 20k in size; the Z machine interpreter is about 80k in size, and other interpreters are even bigger.

My goal in making this adventure was to make a playable, very small adventure that people can freely include with programs like ScottFree.

In particular, I wanted the adventure to fit in under 6 2048-byte blocks (12288 bytes), which it barely does.

To play this game, play it online or download it here (80k zip file). This zipfile includes a Windows program for running Scott Adams adventures, a version of ScottFree for *NIX (including MacOS X in a terminal) updated to not have bugs when compiled in a modern version of GCC, and a z-machine version for people who don't feel comfortable compiling ScottFree.

- Sam

Update: 2007/09/10: Updated version to 1.1 and added note there is now a z-machine version of Desert Adventure. 2007/09/11: Added online version

MaraDNS snapshot update; Cloak of Darkeness

I have made an update to the MaraDNS snapshot public today. In this update, I have removed a lot of old cruft from the MaraDNS tree. The biggest savings comes from removing the .pdf manpage reference from the documentation tree; this reference doesn't include the tutorial, so is of limited use. I have also removed some old documents and programs not needed by MaraDNS which haven't been looked at or updated in years.

In addition, bind2csv2.py now has a man page, and the authoritative tutorial has been updated to point out the recursive resolver had dnscache-style custom name servers for subtrees of the DNS space.

Jean-Jacques Sarto has contributed a patch that allows csv2 zone files to have FQDN6 records in in csv2 zone files, for better ipv6 support. I have not integrated this patch yet; I have to make sure he licenses the patch under a MaraDNS compatible license and that the patch doesn't introduce any other bugs.

The September snapshots of MaraDNS can be downloaded here.

---

I have had a long-term interest in Interactive Fiction ever since the days of Adventure and Zork in the late 1970s. This weekend, being a little bored, I have ported Cloak of Darkness to the parser Scott Adams used for his late 1970s and early 1980s video games.

I had to do some hacks to pull it off; namely, I have the adventure teleport the player from one room to another instantly under certain circumstances:

• If the player tries to go out in to the street from the foyer, they enter the street. They are then instantly teleported from the street back to the foyer with the "You've only just arrived, and besides, the weather outside seems to be getting worse." message.
  
• If the player has hung up the cloak, and enters the bar, they are instantly teleported from a dark room to the actual bar.

Basically, since Scott Adams' format kills the player if they hit a wall in the dark, I made the bar a dark room with exits in all directions. If they take any of the exits, they go to another dark room and have a 50% chance of messing up the message for every turn they are in the second dark room. Both the first and second dark room's "North" exit takes them back to the foyer.

Another hack is that the Cloak is not a normal pickable (carryable) item. Instead, "drop cloak" is explicitly given two actions:

• Give the player the "This isn't the best place to leave a smart cloak like that lying around!" message in any room besides the cloakroom
  
• Put the cloak on the hook in the cloakroom, and set the flag so the person, when in the dark room, is instantly teleported to the bar.

Also, get cloak when the cloak is in the cloakroom picks up the cloak, and clears the "telport from dark room to bar" flag.

The game makes assumptions that Scott Adams' adventures never had, but it works pretty well. In ScottFree, I never see the teleport. It is possible, were this file used in an actual 1970s computer, that the player might see a brief flash of the room they were teleported from before being teleported.

My port is available in a zipfile, along with a version of the scott2zip converter updated to run in Perl5 and ScottFree updated to not have a bug when compiled in GCC4 (A recent version of the Linux C compiler):

cloak-scott-0.1.zip

The above zipfile can be freely uploaded to the if-archive or anywhere else (I assume Roger Firth allows people to freely distribute implementations of Cloak of Darkness).

I think this is the only new Scott Adams game in over 20 years. Considering how difficult it was to pull off, I can see why no one makes games in this format any more.

- Sam

MaraDNS snap; POSIX thoughts

I have released a new snapshot of MaraDNS on the MaraDNS snapshot page today. This is a very minor set of improvements: I have added a couple of shell scripts in the tools/misc directory that make it easier for me to release new versions of MaraDNS. There's nothing here for end-users of MaraDNS.

Starting tomorrow, MaraDNS snapshots will be in this directory.

---

Looking at the POSIX specification, there's some cruft in there, notably the uucp program. UUCP was a way of transferring files between UNIX computers that was popular in the 1980s and lingered on through the 1990s. It was a way of getting email and USENET on a computer that would only be online for a short period of time. I remember around 1997, when NetCom (my first dot-com job) finally completely canceled UUCP access, since the UUCP programs we had were acting up and no one knew how to fix them.

There's more to DNS than BIND and DjbDNS

Back in early 2001, there were only two DNS servers available: BIND and DjbDNS. Both DNS servers had problems: BIND constantly had security problems in it that gave attackers remote root access to systems. DjbDNS had a non-open source license and a disregard for standards that made using it problematic.

The feeling was that a new DNS server needed to be made. So I started developing MaraDNS. It was a lot of work; DNS is a non-trivial protocol.

Six years have passed since then and a number of DNS servers have come and gone. The ones that are still being actively maintained are my own MaraDNS, NSD, and PowerDNS. [1]

However, whenever a discussion about DNS servers comes up, we get the same BIND-vs-DjbDNS flame war rehashed over and over again. The flame wars are based on the following outdated bits of information:

• BIND has privilege escalation security holes coming out every month (not true since BIND9 became viable in 2002 or 2003)
• DjbDNS has no security holes (not true: DjbDNS has an unpatched remote denial of service security hole)
• There are no free DNS servers besides BIND and DjbDNS (Not true; there are three other active open-source DNS servers)

Here is an example posting showing how people are still living in 2001 when it comes to DNS servers.

So, people, wake up and smell the coffee. There are no less than three other DNS servers. Being actively maintained. We are no longer in a BIND-and-DjbDNS world. BIND is no longer a remote root exploit waiting to happen.

- Sam

[1] There are some other DNS servers that are no longer actively maintained or on life support: pdnsd (the last update is from a year ago) and posadis (last update three years ago). There's also MyDNS (last update almost two years ago), which is a "one trick pony" DNS server for people who want to use a database to manage DNS records.

MaraDNS update: All versions

The good news is that it only took me about 15 minutes to find and reproduce the bug that was causing the improper resource record rotation. The bad news is that the bug that causes the rotation is one that enables a remote denial of service. Hence, I updated all three supported versions of MaraDNS (1.0, 1.2, and 1.3) last night to fix this bug.

Basically, someone can send a specially crafted DNS packet to the DNS server that will make an authoritative CNAME record not resolve. The workaround to disable this denial of service is to add the following line to the mararc file:

max_ar_chain = 2

The fix is to download MaraDNS 1.0.41/1.2.12.08/1.3.07.04 from the MaraDNS download page or to download MaraDNS 1.2.12.08 from the Sourceforge MaraDNS page

All distributions are strongly encouraged to update to 1.2.12.08, or to 1.0.41 if still using the 1.0 branch of MaraDNS. Please remember, 1.0 users, that non-security bugfixes in MaraDNS 1.0 will no longer be applied after December 21 of this year.

I would like to thank Michael Krieger, whose bug report helped me find and fix this problem.

MaraDNS snapshot update

For people who have been looking at the August 2007 MaraDNS snapshot directory, I quietly uploaded a couple of updates this weekend. Both of these updates were minor typo-fix updates; I would like to thank Joerg Sonnenberger and Brandon Holbrook for their bug reports.

Today, the update is a little more major. I have made a script that runs all of the SQA regressions, as a single script. I have also updated the SQA tests to be easily pass/fail tested, so that the script can figure out if a given test has succeeded. While the script takes a couple of minutes to run, this allows me to easily run the script whenever I want to make sure a given release is ready to make public.

The only other TODO I have for the 1.3 branch before christening it stable is to find and fix the bug that causes improper RR rotation. Also, if anyone who uses pkgsrc wants to contribute some patches to make MaraDNS more pkgsrc-friendly, please do so. The people who whine complain to me about MaraDNS not playing well with pkgsrc strangely become silent when I ask them for patches to actually fix the problem.

I'll probably also make sure the documentation is OK.

I may be able to declare MaraDNS stable on September 21, 2007, if everything continues to go well.

- Sam

Linux fanboys are annoying

You know, as a long-time Linux advocate, I find Linux fanboys to be very annoying. The thing that is most annoying about them is that they are loud-mouthed, deluded, and have an irrational hatred of Microsoft. Linux Weekly News has been somewhat immune from the invasion of the Linux fanboys until fairly recently, probably because you have to pay or (like myself) wait a week before reading their news. However, this is changing; Here is an example of the fanboys being annoying on LWN. Here, the fanboys go on with their anti-Microsoft shills in an article about the Python programming language, of all things, simply because the linked article had a Microsoft ad in it.

Ugh.

They also spread nonsense like OpenOffice being just as full-featured as Microsoft Office. It isn't. Let me give you just one example: Microsoft Office, since at least Office 2000, has an easy way for you to assign special symbols to keypress combinations. OpenOffice doesn't. This is a known bug. The reason why MS Office can have this feature and OO doesn't is because OO doesn't have the manpower to add features like this. This is because you didn't pay for the software, so their isn't enough money to pay developers to make the software as feature-full as MS Office is.

Another example: I have installed Firefox on countless Windows machines. It was clean; in particular, since I am bilingual, I like to have its built-in spellchecker switch between English and Spanish easily, depending on which language I'm writing in. All I had to do in Windows is add Spanish, and the list can be quickly used, since it only has English and Spanish. In Ubuntu, Firefox had dozens of languages in it. There was no way, in the package management system (Synaptic), to remove these languages. I finally had to go in to /usr/lib/firefox/dictionaries and remove the dictionaries by hand.

Ugh again.

Now, Linux does have advantages over Windows. The price is better. The development and *NIX environment is a very productive environment for someone who knows UNIX's arcane commands. I really like the FVWM1 window manager, which was a fast and light window manager in 1995, and is today lightning-fast. But Linux isn't ready to be a end-user desktop. Not yet.

- Sam

MaraDNS snapshot update

I have made some minor updates to the MaraDNS snapshot. I have verified that the example mararc file included in the zoneserver manpage works as advertised. I have also added a couple of other tests to the SQA process.

My next step is to automate the SQA process so that all one has to do, on a Linux system with valgrind, is run a single script, which will run each SQA test and tell you if you have passed or failed the SQA test, and stop testing if any of the tests fail.

I also want to move the documentation for many of the SQA tests from the single top-level README file in to README files in the corresponding folders--the newer tests already have documentation in this form; the older tests do not.

I also have a patch from Joerg Sonnenberger that I will apply to the 1.3 series of MaraDNS.

After that, I will work on the "records rotate when they shouldn't" bug; in particular, I will see if I can reproduce it.

- Sam

MaraDNS snapshot update

I uploaded another MaraDNS snapshot today. In this snapshot, there are no major changes (Read: No new bugs found and fixed. Maybe MaraDNS is becoming 100% bug-free). However, I have added a few more SQA tests, and have updated the zoneserver man page and fixed a couple of typos in the tutorial documentation. After making the release, I realized that the example mararc in the zoneserver man page is a little inaccurate. This will have to wait until my next snapshot of MaraDNS.

The snapshot is available on the MaraDNS webpage.

---

In related news, I am also updating MOAM-CD.

I have managed to squeeze out more unused stuff; I got rid of a lot of kernel modules that won't be used on a basic web terminal, such as bluetooth drivers, non-X video drivers and a number of filesystems like reiserfs. This cleanup saved about five megs of space. I also removed some Cyrillic fonts (This CD is only for English and Western European language speakers).

For some reason, the .jar files (which is just another name for .zip) in Firefox's Chrome folder are really poorly compressed; I used advancedcomp to recompress these files, saving 2.8 megs of space there. I also removed the C development environment, saving about 10 megs of space.

Once compressed, the amount of space saved was, in total, some ten megs. Yes, I now have a usable web browsing system complete with Firefox 1.5 in only about 27 megs. Which gives me a lot more space for other stuff, and even allows the system to fit on one of those square 30 megger business card CDs.

I have also updated the variable-width font, and Firefox is updated to be current with Firefox 2.0.0.5's security fixes. The two 2.0.0.6 security updates are not critical; the one critical bugfix is caused by Microsoft Windows' broken security model, and doesn't impact Linux.

In addition, I have added the VIA chipset Unichrome driver. X's auto-probe script is smart enough that, as soon as this driver was compiled and placed in /lib/xorg/modules/drivers, it auto-probes for the chipset. I tested things on a computer that I know uses this chipset, and the driver works like a dream.


I should have a release of moam-cd-0.6 later on this week. I need to make the width of the space "character" a little wider at 14 points with the "Sandals" font, and should make the 12-point "A" a little narrower (not as important, and harder to fix; the space fix is a one-character change in the appropriate .bdf file).

MaraDNS releases: 1.2.12.07 and 1.3.07.03

Today I have released not one, but two major releases of MaraDNS: 1.2.12.07, the latest bugfix update to the stable branch of MaraDNS, and 1.3.07.03, the latest bugfix, SQA, and documentation update to the beta-test branch of MaraDNS.

1.2.12.07 fixes a number of fairly important bugs which were fixed a while ago in 1.3:

• Bugfix: If bind_star_handling was set to 2, MaraDNS would leak memory when the existance of another RR stopped resolution using a star record.
• Bugfix: bind_star_handling, when set to 2, now appears to do the right thing.
• Bugfix: Non-critical double-free() removed.
• Bugfix: askmara no longer goes in to an infinite loop when it receives an invalid TXT record.
• Bugfix: csv2 parser now makes sure that TXT chunks are no longer than 255 characters in all cases.

1.3.07.03 has two bugfixes, five SQA tests added, and some other updates. Not noted in the changelog is that I have moved the udpsuccess() function call in to its own file. The thinking is to make the main MaraDNS.c fils smaller, to make things more tidy and to make re-compiles faster.

My next plan for MaraDNS has not changed: Find the bug that is causing inappropriate rotation of resource records. This one appears to affect 1.0, 1.2, and 1.3, so I would like to find it. If I can't find it, I will completely rewrite the relevant RR rotation code.

I hope to find this bug before 1.0 becomes security-only updates on December 21st.

It would seem that some versions of BSD use a system called pkgsrc that basically assumes you use autoconf for building your program, something MaraDNS does not do. This makes it difficult for pkgsrc packagers to package MaraDNS. I won't fix this in 1.2, but it may be something worth changing for 1.3 if the changes do not disrupt things too much.

MaraDNS snapshot update

I have made a minor update to the MaraDNS snapshot today: I fixed the recurse_delegation test to give accurate test results. Currently, both 1.2 and 1.3 always, when both subdelegating and acting as a recursive resolver, give out the delegation records when asked for a name in a subdelegated domain. This is OK in 1.2; one should not have the same DNS server both subdelegating domains and performing recursion. This is a bug in 1.3; 1.3 should let you choose what MaraDNS does in this circumstance.

I will fix the 1.3 bug later on this week, and should release 1.2.12.07 Friday.

MaraDNS snapshot download link

- Sam

New MaraDNS snapshot

I made a lot of progress with MaraDNS yesterday. I have done most of the SQA tests I set out to do. I have found and fixed one bug: csv2_default_zonefile did not work without other zone files in the 1.3 branch of MaraDNS.

I may have found another bug: It looks like there are problems with recurse_delegation in 1.3; I will have to do some 1.3 and 1.2 tests. If there is a problem in 1.2, I will hold off the 1.2 release until I find and fix the bug.

I am also starting to split off the huge MaraDNS.c file; the large udpsuccess() routine now has its own file. This way, the code should be a little easier to manage.

My short term plans for MaraDNS: Later on this week, or possibly early next week, release 1.2.12.07, which has a number of non-critical bugfixes compared to 1.2.12.06 released three months ago. I also plan on releasing 1.3.07.03 later on this week, possibly even on the same day as 1.2.12.07.

My medium term plans for MaraDNS: I plan on making the 1.3 branch stable on December 21, 2007. There is a long-term bug which has been reported to me twice: Sometimes records which should not rotate are rotated. The problem is probably either in udpsuccess() or udpany(); I will investigate this concern some more and hope to reproduce it. This code affects both 1.0 and apparently 1.2. If all else fails, I will completely rewrite the round robin rotation code for the 1.3.07 stable release of MaraDNS.

My long term plan is to write a stand-alone DNS recursor that will not use threads; there is a need for a truly open source small DNS recursor.

The snapshot can be downloaded here

Linux annonyance: /dev/hda now has large file problems

Ever since the creation of Linux in 1991, the way to mount IDE hard disks and CD-ROMS was to type in something like mount /dev/hda1 /mnt, or for an IDE CD-ROM drive, something like mount /dev/hdc /mnt. However, this no longer works that well in the kernel that comes with Ubuntu 7.04 (2.6.20-16-generic). If there is a DVD which is larger than four gigabytes in size, the CD/DVD-ROM drive can not access the files past the four gig limit. This was not a problem with older Linux kernels; the kernel developers broke something that has been working for years.

Instead, one has to get the udftools package via sudo apt-get install udftools, configure the file /etc/default/udftools to point to the CD/DVD-ROM device, and then mount the DVD as /dev/pktcdvd/0. Ugh. As an aside, there are online guides for making UDF packet-writing DVDs (DVD-RWs that you can write to as if they were a huge floppy disk) that give bad directions. Please read the directions in the file /usr/share/doc/udftools/README.Debian.gz for correctly formatting a packet DVD. I now have two coasters that used to be DVD-RW blanks because I did not follow these directions, but instead trusted inaccurate on-line directions. In particular, I didn't do the essential growisofs -Z /dev/hdc=/dev/zero step between formatting the DVD-RW and putting the UDF filesystem on the DVD-RW, since the on-line guide did not mention this step.

Also, when mounting a DVD-RW, you really want to mount it like mount -o noatime /dev/pktcdvd/0 /mnt since otherwise it will do very slow writes when all you want to do is read some files. Yes, I actually learned something useful from reading a Slashdot discussion. Naturally, Slashdot misattributed a quote to Linus, but hey at least the information in this thread is useful.

MaraDNS snapshot update

Another MaraDNS snapshot update today.

There are two main updates: I have updated the sqa/regressions/truncation test to run both on MaraDNS 1.3 and in MaraDNS 1.2 (so I can verify that the test shows the presence of the bug in old 1.2 releases but the non-presence of the bug in 1.3). I have also made some minor touch-up to the bind2csv2.py documentation.

It is available here.

MaraDNS snapshot updated

OK, after neglecting MaraDNS for over a month (I was on vacation and did not have a computer to do MaraDNS work on during the vacation), I have finally released another snapshot of MaraDNS. This is only a very minor change: I have added a readme file to the sqa/regressions directory describing the various regression tests.

The big change is behind the scenes; I have sucessfully moved the MaraDNS development environment to my new Dell laptop runinng Ubuntu. While I will still compile the Windows and CentOS binaries on my older Thinkpad, the majority of the development will now happen on the newer Dell.

I hope to have more significant updates to the 1.3 branch soon.

I also plan on releasing 1.2.12.07 in a week or two; there are a number of 1.3 bugfixes that I have already backported.

- Sam

Linux distribution choosing made easy

One common complaint people have about Linux is that there are too many distributions to choose from. In response to this complaint, here is a simple list telling you what Linux distribution you should use:

• If your computer was made in the last three years, get Ubuntu
• If your computer is between three and six years old, get Xubuntu
• If your computer is anything older, and is a 486 with 16 or megabytes of ram or better, get DeLi Linux
• If your computer is even older than that, choosing which Linux distribution to use should be the least of your worries. Computers that old are usually falling apart; it can be nay-to-impossible to get an antique like that to power on, much less install Linux on

- Sam

On Chess Variants

I have had a long-term interest in chess variants. Chess variants are various ways of changing the rules of chess to make a slightly, or, at times, very different game. My motivation in interest in Chess variants is summed up in an article in this zipfile:

One of the nice things about chess variant design is that it opens up new fields of opening study to explore. In FIDE (orthodox, western) Chess, any move on the first half-dozen turns that is not an outright blunder has already been throughly studied and explored. Many opening lines are 20 or 30 moves deep. There are little, if any, interesting new frontiers to explore.

Chess variants, however, make it possible for someone to be a trailblazer again, exploring openings that have never been studied before.

I have been studying a chess variant which I "invented" back in 2004 (and published in 2006) called "Schoolbook Chess".

There are a couple of things a chess variant inventor can do to help people play their chess variant. One thing they can do is make a game courier preset. This is a web service where one can easily add new chess variants. Most presets do not enforce the rules for the variant. The preset I made for Schoolbook chess, however, enforces the rules simply because I was able to easily modify another preset that is identical in all aspects except for the opening setup of the pieces.

Another thing someone can do to play chess variants is to make a Zillions of Games rules file. Zillions of Games is a proprietary program for Windows (runs well under Wine) that can play a large number of Chess variants and other abstract strategy games. My zipfile is an implementation of Schoolbook chess for Zillions of Games. However, it also has ChessV rules files for Schoolbook (not that they are needed; ChessV has had the ability to play Schoolbook since the 0.9.0 release a year ago). In addition, it has some documentation for Schoolbook, including opening analysis, annotated games, and a few mating positions.

What I was doing all weekend was updating this zipfile. First of all, ChessV has moved since I last released a Zillions zipfile. I also updated a couple of other links.

Second of all, I added four mating positions (maybe I should reword those last two words) to the zipfile. This was the lion's share of the work. I had to make sure the positions were indeed mating positions, make two screenshots for each position (we use a different black and white color scheme when printing the page), create and verify the solutions to the mating positions, and then integrate the positions in to the list of 12 mating positions we already had, double and triple checking to make sure I did not introduce any errors. This took hours.

During this process, I submitted some of these new mating positions that have not been submitted to the chess variants page before, which also took some work.

Once that was done, I had to modify the zipfile a little (removing some "no commercial use" graphics) in order to make the zipfile suitable for submission to Zillions of Games. I then submitted my submission via email.

This took all weekend to do. Far longer than I thought it would. All for a game that has only been played about two dozen times, mostly me-vs-some other chess variant inventor (the mating positions and opening analysis come mainly from computer-vs-computer or some of my computer-vs-human games). Needless to say, I don't think I will revise this game at all until 2008.

- Sam

Blog layout updated

As people who visited this blog before can see, the blog layout has been updated to both be more readable and to more resemble the look of the MaraDNS website. I've tested it; it looks good in Firefox 2, Opera 9, IE7, and Dillo. The site is no where near validating, but I'm not going to lose any more sleep over that. Heck, if anyone knows of a blogspot blog that validates, I will be amazed.

- Sam

1420 update: Suspend broken

---

Well, it would seem that there is a key feature broken with my Inspiron 1420: Suspend is completely broken. Not just a little broken. Completely broken. Attempts to suspend the laptop do nothing more than crash the system.

I, of course, tried various ways to suspend the system:

• sudo pmi action suspend
• sudo pmi action hibernate
• sudo apt-get install uswsusp

  Followed by either:

  s2ram

  s2disk

All of these have the same result: The system crashes, forcing a reboot.

Another bug: Take a blank DVD-RW. Format it as a UDF filesystem in Windows Vista. Write data to the disk. Now, put it in the Linux system. Write some more files. The UDF filesystem is now perfectly fine in Linux---but Windows Vista can not read any of the data on the disk, and will not allow you to write to the disk unless you reformat the DVD-RW.

Now, this could simply being a case of Microsoft playing their old vendor lockout games, where they refuse to read UDF-formatted disks written to by the competitor's product.

Speaking of vendor lockout, I wonder how log it will take Microsoft before they punish Dell for selling non-Microsoft computers by charging more for Windows.

Review: Dell Inspiron 1420 with Linux

---

I have finally received my Dell Inspiron 1420 that comes with Ubuntu 7.04 preinstalled today. The order took about a month to process; this is a brand new model, and I was one of the first people to order it. I would have gotten a Thinkpad, but chose Dell since they are going out on a limb and are making computers with Linux preinstalled. This means that I get a computer that works out of the box with Linux-compatible hardware; there is no need to use ndiswrapper to get the wireless card to work with Linux, and no strange winmodem without a Linux driver lurking in this laptop.

This is one of the first systems; I ordered the system too early to get the free hard disk and memory upgrade. When I asked to upgrade the system, I was told I would have to cancel the order and reorder to do that. The systems have a two-week backlog and I want to get back to Mexico as soon as possible, so I decided to have just get the computer as quickly as possible.

The system booted in to Linux without problem. Since Ubuntu uses all 80 gigs of hard disk space, I tried to reinstall Ubuntu from the supplied CD in order to have more free space. Strangely enough, while Ubuntu runs fine on the system, the Ubuntu Live CD can not successfully boot. I had to download and burn the Ubuntu "alternate install" CD in order to get a Ubuntu system I could repartition from.

The good news is that the partition manager included with Ubuntu's "alternate install" CD has partition resize support. I was able to resize the partition Dell's Ubuntu install is on without having to reinstall the OS. While it was a slow process, it saved me the bother of reinstalling all of the restricted drivers and configuring the computer yet again.

As a Linux system, it is a great system. If you are a Linux hobbyist or experienced Linux user, this is a system worth having. All of the hardware works with a minimum of restricted drivers (for the winmodem and wireless network card) used. Even the SD card reader works. If you are an average Windows or Mac OS X user, however, I would not recommend this system.

Here are some issues which I have seen with this system:

• The wireless configuration GUI tool only supports the very insecure WEP encryption. Setting up WPA encryption is non-trivial. For the record, the cookbook linked to does work and I am using it to be on our secure wireless network at home.
• Firefox's inline spelling dictionary is really nice. Unfortunately, Ubuntu comes with a really long list of languages that makes it difficult for me to switch between English and Spanish; something I do quite frequently. Even after uninstalling all of the languages besides English and Spanish, Firefox still has this huge list of languages I can spell-check against, only two of which I will actually use.

Linux has a made a lot of progress since the mid-1990s in terms of being an end-user desktop machine (the resize partition feature is a very nice addition); however I must conclude that Linux, as a desktop machine, is more geared towards the kind of people who had a computer in the late 1970s (see my last blog posting).

I think one day Linux will become a viable desktop system for the masses. Until then, Dell is a pioneer in making Ubuntu desktops and laptops for the small niche who would rather have Linux on their computer. I just hope Microsoft does not illegally punish Dell for making this bold move.