New Deadwood snapshot

OK, at this point the code appears to be able to handle getting big DNS packets from the upstream DNS provider and forwarding them via TCP to the local DNS resolver; note that these big packets aren't cached.

It can be looked at here

I love Linux; really, I do

For a while now, I have been posting a number of rants that explain why it is I use Windows XP instead of Linux today on my desktop.

I have decided to no longer post these kinds of rants. I have made my decision; my desktop now runs Windows XP. [1] This does not mean I hate Linux. It's an excellent server OS and embedded OS.

My primary concern right now is not what operating system I use on my computer.

My primary concern is to find a good job in California and to be closer to my family and make good money again. If my 14 years of using Linux can help me do this, great. If I get a job as a .net developer or Windows sys admin, great. If I completely leave the tech industry and get a job as a professional translator or teaching ESL, great.

I think working on Deadwood and getting MaraDNS 2.0 out the door may help me accomplish this goal. Even if not, I have a lot of free time because of my current work situation (part-time work, with a lot of dead time between translations and when the computers are just happily humming along), so it gives me something to do that is more productive than, say, arguing on Slashdot. [2] And, hopefully, something that helps people and makes the world a slightly better place.

I was listening to CNN recently, and they were talking about how a lot of people unemployed because of the crisis are doing a lot of volunteer work to pass the time and help people. Deadwood and MaraDNS 2.0 is my volunteer project during this economic downturn.

- Sam

[1] I have a CentOS 5 VMware virtual machine I use for Deadwood/MaraDNS development. I also have a CentOS 5 Linux partition I boot into for 64-bit testing and to use as a music player to listen to music at night every now and then. I can't use it for much more because my hardware isn't fully supported, even though I did buy a Linux laptop.

[2] Slashdot was a big time sink for me back when I was a Linux fanatic. I would spend hours on Slashdot instead of doing useful things like work on open-source projects. One of the reasons I have spent a lot of effort justifying my decision to use Windows XP on the desktop is because I was justifying, to the person I was a decade ago, why I made this decision.

Deadwood snapshot update

Some more work on handling DNS packets too big to fit in 512 bytes: Test that uses named (BIND) to generate big DNS packet added (sqa_bigpacket); some more code to handle these big packets correctly has been done but we're not at the point where we correctly handle these big packets yet.

2002: The year Linux on the desktop died

People keep talking about there soon being the "year of the Linux desktop". I've seen this prediction for at least a decade. This prediction will never become true. Indeed, Linux on the desktop died in 2002.

There are three events in 2002 that killed Linux ever having any chance of making it on the desktop:

• Mac OS X was out and getting application support; UNIX was finally on the desktop (and it wasn't Linux)
• Windows XP came out: Microsoft finally had an OS for end-user desktops with server-level stability
• Loki games, a company that made games for Linux, went out of business. This was the final nail in the coffin for commercial desktop applications for Linux

Linux's big advantage in the 1990s, besides being free and open, was that it was a good deal more stable than Windows and Mac OS 9. While consumer end-user desktops had constant problems with crashes and instability, Linux was a server-class operating system and very stable.

Sure, it didn't have a very friendly user interface, but for people who took the time and effort to learn it, it was a very powerful and stable system. Indeed, in the mid-1990s, after spending an hour trying to log in to our UNIX server at work from Windows and failing, I said "there has to be a better way", and installed Slackware 96 on my computer at work. This computer became a Linux server that I used to process reports and perform other tasks; it eventually was upgraded to RedHat 4.2 (with the FVWM1 windows manager) and the server was still up after I left the company until the company was bought out. At no cost, the company I worked at had a very capable workgroup server in our office.

I was sure Linux would some day become more friendly on the desktop and people would start buying Linux applications in droves. Indeed, in part to support the Linux cause, and in part to have a nice office suite on my desktop, I bought a lot of applications for Linux. I bought commercial versions of Red Hat Linux, I bought both versions of Wordperfect that were made for Linux, I bought another office suite called "ApplixWare", I bought another spreadsheet and database for Linux, and I bought a lot of Loki games for Linux, including games I never played.

Sure, it was a cottage industry, but there was a definite market for Linux software out there.

This market died in the early 2000s. Corel bet the ship on Linux succeeding on the desktop in 1999; it didn't and Corel went down in flames as a result. With both Mac OS and Windows updated to have Linux's stability, what little market there was for commercial Linux software all but evaporated.

Wordperfect is no longer available for Linux. Corel is no longer available for Linux. Loki Games died in 2002 and I think Quake 4 was the last commercial game with a Linux port (John Carmack has talked about moving away from OpenGL, and it looks like ID Games, the last holdout for commercial Linux games [1], never made a Linux port of their latest game, Quake Live)

Applixware is still around, but in a much-reduced form; it's no longer for retail sale but exists as a "download-then-register" product. They appear to be targeting enterprise desktops (what were called "Workstations" in the 1980s and 1990s), and no longer target the end-user desktop.

There is no market for Linux desktop applications today. If you want to make money selling desktop software, Linux is not the platform to target.

So, why is there still a lot of noise about Linux on the desktop in the internet?

It's like the Amiga in the 1990s. The Amiga died in 1992 when Commodore stopped making this computer. No matter that there were still people with Amigas on their desktops, using Amigas for professional work as recently as 1997. The Amiga was dead in the marketplace: No one was making any money selling Amigas any more, and indeed, you could no longer buy a new Amiga.

People kept talking about the return of the Amiga in the 1990s, but it never happened. People keep talking about the year of the Linux desktop in the 2000s, but it is never going to happen.

[1] For years ID games were available for Linux: Doom, Quake, Quake II, Quake III, etc., but this seems to have finally stopped.

Deadwood snapshot: Memory leak plugged

I added a TCP query to the memory leak test, which caught a 3-byte memory leak in the code I added this weekend. I have plugged this leak and updated the code.

I have also added a "CODE HERE" comment to DwUdpSocket.c where I will add code to set up a TCP query upstream if we're using a TCP client and get a truncated reply.

Since this is thread-free code, I have the code set up to request TCP data to be sent or received, then have other code that actually sends and receives the TCP data. I need to add routines that will take the TCP request made in DwUdpSocket.c, send the data upstream (or keep if buffered if not sent), wait for a reply upstream, then send the upstream reply back to the client (again, using buffering because this is thread-free code).

The snapshot is at the usual place.

New deadwood snapshot: Testing cleaned up

Before I implement proper handling of truncated packets from upstream, I have cleaned up the testing for the new combined UDP-and-TCP DNS client code. I have fixed the "maxprocs" test so it doesn't fail at random the way it used to, and added a new test to test handle_noreply for DNS-over-TCP connections.

Next: Correctly handle truncated DNS packets.

It can be downloaded here

Deadwood snapshot update

I've just uploaded a second Deadwood snapshot for today:

• Server fail sent to TCP client if no upstream servers are reachable
• If handle_noreply has a value of 0, TCP connection closed if no upstream servers are available; Documentation updated to note this behavior
• NOCACHE option removed; we'll keep this in Deadwood 2.3, which is the Deadwood version to use on embedded systems.
• SQA tests updated; maxprocs test disabled because it's too flakey (Todo: make this test reliable and consistent)
• Program compiles and runs in Windows

It can be downloaded at the usual place

New Deadwood snapshot

In the 20090427-1 snapshot of Deadwood, I have polished up the code that takes a DNS-over-TCP connection and converts it in to a DNS-over-UDP connection to send upstream.

• TCP idle timeout works again
• TCP DNS queries will use cached entries before trying to make a UDP connection
• All compile-time warnings removed
• Marco Njezic pointed out Windows service won't run if there was a space in a path to Deadwood.exe; fixed.

It can be downloaded at maradns.org/deadwood/snap

The next thing to do is to have it so, if we get a DNS-over-TCP query, and sending a UDP query upstream results in a truncated packet, we try to get the query upstream over TCP and send the full packet back over TCP. (UDP queries that get truncated packets will get a truncated reply)

If we cache these replies, it's important to note they're too big to fit in a UDP packet and must be sent over TCP.

As an aside, these kinds of packets are very rare. The upstream DNS servers I have been using for a while have recently started dropping DNS-over-UDP packets, and I didn't even notice until I did TCP testing with Deadwood.

Deadwood snapshot update: DNS-over-TCP connections now converted in to UDP

Well, it looks like the changes to allow me to make multiple Deadwood snapshots in a single day are really paying off; it is making me more productive with Deadwood, because I no longer have a reason to "rest on my laurels" after making a Deadwood snapshot.

I have just uploaded a Deadwood snapshot that can take a DNS-over-TCP query, convert the query in to a UDP query to send upstream, get a reply from the UDP server upstream, and send the reply back as a TCP DNS reply.

I have only tested this code in my CentOS 5 virtual machine.

The code is a little rough; for example, this conversion process doesn't look to see if we have a cached reply before sending the query upstream. Also, I'm not sure I have the code in place to close idle TCP connections. But, the code is usable and works, so I feel confident uploading this (as deadwood-Q-20090426-2) and making another snapshot tomorrow with the rough edges cleaned out (caching, closing idle sockets, compile-time warnings, and Windows support)

It can be downloaded at the usual place

MaraDNS snapshot update: Deadwood updated to 2.3.02

I have just uploaded a new MaraDNS snapshot today; in this snapshot, the version of Deadwood included with MaraDNS is Deadwood 2.3.02. This snapshot can be looked at here.

Next: Add code to actually parse DNS-over-TCP queries and send UDP queries upstream in reply. I may or may not finish this code today.

Deadwood snapshot update: Now it's only a single Windows service

I have updated Deadwood's Windows code so that its service code now correctly reflects the fact that Deadwood is now a single combined UDP-and-TCP service. As it turns out, I did end up using some of Marko Njezic's code again, because he added code to have Deadwood.exe show the user how to install Deadwood as a service if they just invoke "Deadwood.exe" as a non-service.

I have updated the Windows documentation accordingly. In addition, I have updated the script make.version.h to handle the deadwood-Q-YYYYMMDD-N daily snapshots.

Next: Release a MaraDNS snapshot with Deadwood updated to 2.3.02

Then: Tighter TCP and UDP integration: Return results from the UDP cache for TCP queries (or add results to the UDP cache)

It can be downloaded at the usual place.

Deadwood snapshot update: UDP and TCP now handled by the same daemon

I have spent all morning combining the UDP and TCP code in to a single combined daemon. We now have two lists of pending connections: Pending UDP connections, which are handled by the code that can cache UDP DNS packets, and pending TCP connections, handled by the far simpler forwarding-only DNS-over-TCP code.

This was easier than I thought it would be; I just had to add two more dwood2rc parameters, and cut-and-paste code from DwTcpSocket.c to DwSocket.c. The effort I have gone to conform to a coding style that keeps the code easy to maintain is truly paying off.

I have also updated the documentation and the SQA tests (but haven't run a SQA test battery). I have only run this code in CentOS 5, and haven't tested it in Windows.

Since I've removed one daemon (DwTcp/DeadwoodTCP) and have only one daemon (service) handle both UDP and TCP now, I will next revert DwWinSvc.c (the code that handles making Deadwood a Windows service) back to its older (2.2.01) form when it only handled one service. I appreciate Marko Njezic contributing code to give the Windows version support for two services, but this code actually is only needed in the 2.3 branch of Deadwood.

I will maintain the 2.3 branch for the foreseeable future because, among other reasons, the way DNS-over-TCP is handled in this code allows the TCP daemon/service to be a general-purpose TCP load balancer.

Starting tomorrow, I am going to give daily snapshots a new naming scheme. Instead of being deadwood-Q-YYYYMMDD, they will now be in the form deadwood-Q-YYYYMMDD-N, with N being a number starting at 1. This will allow me to issue multiple Deadwood snapshots a day.

In addition, I have had a policy of only posting one new blog here a day. Starting tomorrow, this policy is no longer in effect, and I will sometimes post multiple blog entries in a single day. These two changes will allow me to post multiple Deadwood snapshots a day, which should help accelerate Deadwood development. My goal is to have full recursion in Deadwood by the end of the year, and release MaraDNS 2.0.

This code can be looked at over at maradns.org/deadwood/snap.

Deadwood 2.3.02 released: Documentation clean-up

As I was going through some of the Deadwood documentation the other day, I realized that the Windows documentation was, in some parts out of date, with information no longer true like Deadwood-over-TCP not being installable as a Windows service. So, the last couple of days, I have been going through the Deadwood documentation and updating it, especially the Windows documentation.

I have also noted the default value for all Deadwood parameters in the Deadwood man page (Deadwood reference).

This revised documentation should be more clear to read and follow, especially for Windows users.

I have also slightly rearranged the SQA tests (the "maxprocs" tests sometimes randomly fails in my CentOS 5 virtual machine, so it's now one of the first tests done), and added a comment in DwMararc.c pointing out the default values there are not always the default values used by Deadwood, with a pointer on how to find the real default values. The code is otherwise unchanged (except for the random prime updated and the version number bumped up).

This is a stable release of Deadwood, and will be supported for the foreseeable future.

Deadwood 2.3.02 can be downloaded at maradns.org/deadwood or at maradns.org/download.html.

My next project is to start work on adding TCP support to the UDP code, so we can have a combined UDP and TCP daemon. I should probably also remove that one passing reference to IPv6 in the Deadwood Windows reference (no IPv6 support in Windows).

Deadwood (MaraDNS) roadmap

Now that Deadwood 2.3.01 is out, I spent the last day coming up with plans of what to do with this code. One plan I had was to add this code to Busybox, but the code is far too big to be a Busybox module, and making it small enough to run in Busybox is more bother than it's worth.

Quite frankly, I'm moving away from Linux. I have spent over eight years working my butt off on MaraDNS for Linux and have some small donations and a free web hosting provider to show for it. I have only gotten one job interview for MaraDNS (with Google), which didn't pan out. During interviews, when I say I'm the MaraDNS guy, I get the "What's MaraDNS?" response.

The thing I don't like about Linux is its cult-like belief system. There is an idea that people making digital media of any kind (music, movies, computer programs, video games, art, etc.) should do all of their work for fun and for free, and that people will somehow magically get money for their work (musicians should earn 100% of their money from concerts, open-source programmers can get better jobs because of the positive reputation their open-source project, people can make money from services and support, etc.)

Well, I've been in the trenches. It's more like this: If you have an email address on your web page, you get all kinds of inane feature requests and bug reports for fixed bugs in old versions of the program added to some Linux or BSD distribution. People send emails sending veiled threats demanding I support them or add the feature they want or they will no longer use my program (see this Slashdot posting for an example of this kind of attitude). People send incomplete bug reports and don't follow up when I ask for more information to reproduce the problem.

Money? Not very much. I finally, last year, cut off private email support then set up a "pay me if you want features or an unsupported OS supported" model. This worked; I even get some pocket change from people willing to sponsor me (see my list of MaraDNS sponsors).

At this point, I don't do private email support without being paid for my time. I don't add feature requests without being paid for my time. I don't support any OS besides CentOS 5 and Windows XP (with some pointers for Vista users) without being paid for my time.

I feel, on some level, like Eric Scheibeler did after moving beyond Amway (I'm right now reading his excellent book Merchants of Deception). I feel I am finally moving beyond a big lie I have been living for well over a decade.

That said, I am still working on Deadwood. Because of my current work situation, I have a lot of free time, and I still want to get a MaraDNS 2.0 out there. But, my focus has changed. MaraDNS 2.0 will have far better Windows support than older versions of MaraDNS, because, quite frankly, Windows is where most of the users are, and, yes, where most of the money is.

OK, now that I got that out of my system, what is my plan for Deadwood? Well, the next thing I want to implement is more tightly integrating the TCP and UDP code. I want Deadwood to be able to get TCP answers from the cache, and to be able to send a TCP query when getting a truncated response from upstream.

After that, I want to make it possible to have upstream_servers for hostnames besides the root hostname (".").

Then I should take MaraDNS' DNS compression and decompression code and port it to Deadwood's codebase.

Next, I can think about TTL aging and resource record rotation.

Then I can concentrate on real recursion.

There's a lot to be done with Deadwood.

Deadwood 2.3.01 released: Stable Deadwood release

I have released Deadwood 2.3.01 today. This is a stable release of Deadwood that will be maintained for the foreseeable future with bugfixes; it is a very good tiny forwarding/caching DNS server when one has access to other recursive DNS servers.

The biggest change, compared to Deadwood 2.1, is that the program is now a full-fledged Windows service. In addition, it's now possible, in CentOS 5, to compile the program without caching, which makes the binary a little smaller.

I did a number of tests with this code. I've added a couple of tests to make sure Deadwood can compile and run correctly when compiled without caching; in addition I have added a test to make sure there are no warnings when compiled with GCC 4.3. I also installed CentOS 5 64-bit and made sure it passed all of the tests (except the network TCP test, which I can't run in CentOS 5 because it's non-trivial to get my Intel 3945ABG wifi card to work).

The documentation included with the Windows binary has improved, and the program is now a single combined binary under 32k in size.

One minor issue with the Windows binary is that one can not see the DeadwoodTCP service logs until the service is stopped (the buffer is not flushed). The Deadwood (UDP) service will not flush logs unless it is idle for a second (so as to not waste time flushing buffers when heavily loaded).

Deadwood 2.3.01 can be downloaded on the Deadwood web page or on MaraDNS' download page. The Deadwood 2.1 branch will only be available and supported for three more months (it will be removed from the website on July 22, 2009), and is available here

Deadwood snapshot update: NOCACHE compile-time flag

I have released a new snapshot of Deadwood today; this snapshot implements the modular code which I have been planning for a while. To make this modular code as simple as possible, the only thing I have made modular is the ability to cache records with a new NOCACHE compile-time switch. With this switch, one can optionally compile without the cache code integrated.

This actually only saves about five kilobytes of code, but may be useful for really tiny embedded systems where caching is not needed.

I have also added tests for this new flag, and another test that makes sure we get no warnings in GCC 4.3 when compiled with -Wall enabled. I have verified that this snapshot of Deadwood passes all SQA regressions in CentOS 5.

Additionally, I have made the Windows-specific documentation part of the Deadwood source tree, and performed a spell-check and other updates with the documentation.

The only thing I will do before releasing Deadwood 2.3.01 is to make it easy to get the version number of Deadwood in the Windows compile, by both showing this info when Deadwood.exe is called without correct options, and in the logs for Deadwood's Windows service.

It can be downloaded at maradns.org/deadwood/snap

Deadwood 2.2.02 released: DNS-over-TCP is now a Windows service

I have released Deadwood 2.2.02 today. This is a testing release; while reasonable effort has been made to ensure this program does not have bugs, the emphasis with this release is to add new features and this is not a "bugfix only" branch of Deadwood.

Deadwood is a non-recursive DNS cache for CentOS 5 and Microsoft Windows XP (which can also run in Windows Vista, but since there is no UAC manifest, the file has to be run using a shell prompt with Admin rights).

This code integrates code contributed by Marko Njezic to make it so both DNS-over-UDP and DNS-over-TCP are supported as a Windows service by Deadwood. I have updated the documentation to reflect this, and have added the CentOS Linux manual slightly adapted for the Windows version of Deadwood to the Deadwood Windows zip file.

The binary is under 32k, but has full support as a native Windows service for DNS-over-UDP and DNS-over-TCP. DNS-over-UDP has full cache support, and the DNS-over-TCP client can (in theory) be used as a general-purpose TCP load balancer.

It can be downloaded, both as source code and as a Windows binary, at maradns.org/deadwood/testing (the .zip file is the Windows binary; the .tar.bz2 file is the source code)

TODO:

• Have the documentation in the Windows binary zip file made part of the main source tree.
• Spellcheck all documentation; there is the occassional misspelled word
• Add pointer to dw_cache in Windows binary zip file example dwood2rc file
• Make code more modular: Make it possible to compile the code without support for caching
• Release Deadwood 2.3.01

Deadwood snapshot update: Marko Njezic has added TCP service support; Final ObHack release

Marko Njezic has contributed code to have it so Deadwood's TCP half is now a working Windows service. This has resulted in the syntax for installing and removing the Deadwood service from the command line changing. Instead of using Deadwood --install and Deadwood --remove, now Deadwood install all and Deadwood remove all is used. Instead of one service, Deadwood is now two services: Deadwood and DeadwoodTCP.

I have updated the INSTALL.txt file to reflect these changes. The reason for the two services is because the program that handles the occasional DNS-over-TCP packet is run separately from the main DNS-over-UDP service.

Before releasing Deadwood 2.2.02:

• Have it so the DeadwoodTCP service can properly log things to a file named dwtcplog.txt
• Have Deadwood's URL, http://maradns.org/deadwood, in the description of the Deadwood and DeadwoodTCP service that one sees on the list of services
• Update the SQA regression to reflect the new www.example.com server
• Have the www.example.com DNS-over-TCP test run first, since this is the most likely test we will need to update whenever the example.com DNS server moves

This can be downloaded at maradns.org/deadwood/snap

---

I have made a release of ObHack yesterday, ObHack 006b. This is ObHack 006a with the following last-minute bugfixes:

• More of Mr. Chris' themes are in the "Doom 1 Mr. Chris" game
• Default game is Doom2 again
• I've finally fixed the long-standing issue with monsters and items on crates (Andrew's fix needed changes in two parts of the code and I only changed one part back in 2008)

This will probably be the final release of ObHack; there isn't that much interest in a random map generator for a 15-year-old game (albeit one with a number of source ports that give the game modern 3D support) and Andrew has already released a new rewrite of Oblige; ObHack was my modifications to his older 2007 Oblige release.

ObHack can be downloaded at samiam.org/slump

ObHack 006a released: Real secrets; Mr. Chris contributions; Switches setting

I have released ObHack 006a today; I plan on having this be my last ObHack release for the foreseeable future, since Oblige III is already out and it will take me a while to adjust to Oblige III.

There are a lot of changes compared to the last ObHack release:

• ObHack now has real secrets; you'll have to pay attention to find the secret areas
• Every level now has at least one secret
• New option: "Switches"; this allows you to have all puzzles be key puzzles, switch puzzles, or a mixture of both
• New game type: "Doom 1 Mr. Chris"; this is a version of Doom1 with some of Mr. Chris' changes applied to it
• RNG seeds can be up to 20 letters long now

It can be downloaded at samiam.org/slump

Why we will never have the year of the Linux desktop

The is a misconception Linux enthusiasts have that no one makes drivers for Linux because of the chicken-and-egg problem: Since everyone uses Windows, hardware makers only make drivers for Windows.

However, one fact Linux zealots ignore is that Linux is not a friendly place for people to make third party drivers.

The problem is that some Linux developers do not respect a company's desire to have trade secrets, and have an anti-corporate attitude that poisons Linux. I call this the "GPL religion", where some zealots believe that people who make money selling software are somehow evil.

Linux needs to let third parties make binary-only drivers for Linux for Linux to succeed on the desktop.

Here is an example of a kernel developer who is religiously opposed to binary drivers. From the linked article:

You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree.

In the real world, I have three choices: I can use a stable Linux kernel without support for all of my hardware (CentOS 5), I can have an unstable Linux kernel with support for all of my hardware (Ubuntu), or I can use Microsoft Windows, which gives me both a stable kernel (Windows XP) and support for all of my hardware (since Windows is a friendly place for people to make third-party drivers).

Linux [is] such a strong, stable, and mature operating system which is the reason you are using it in the first place.

No, it's not. I am using Windows XP right now because Linux is not a usable desktop operating system.

Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better.

This idiocy is what happens when engineers, not managers, drive development. Linux is about tweaking things and constantly breaking perfectly working software. If you want to use your computer to get work done, however, Linux is a horrible choice for a desktop OS.

Having an unstable interface is OK if the only drivers you have to worry about are the disk controller and NIC drivers (Linux in the server back room). It's a horrible choice if you want to have a sound card driver, a video card driver, a mouse driver, and all the other happy stuff that a desktop OS needs.

Deadwood 2.1.02 released: DNS-over-TCP now works

I have released Deadwood 2.1.02 today; this is Deadwood 2.1.01 with the small patch to get DNS-over-TCP to work again applied.

Deadwood 2.1 is the stable branch of Deadwood; for the time being, any significant bug fixes in the "developer snapshot" and 2.2 branch of Deadwood are backported for the 2.1 branch, so people can have a version of Deadwood without significant changes.

Since Deadwood is still in active development, I will probably only support Deadwood 2.1 for six months or so; I will expect people to update to 2.3 (slightly different build process; real service in Windows which will change how things are done there, etc.) fairly quickly.

It can be downloaded at maradns.org/deadwood

Deadwood snapshot update: DNS-over-TCP now works

Mr. Max pointed out to me that he couldn't get DNS-over-TCP to work with Deadwood. Looking at the code, I realized that the code would not flush TCP buffers until another TCP connection was made; I have changed the code to flush TCP buffers 20 times a second.

In addition, I have added a SQA regression that tests real-world DNS-over-TCP so that I can ensure DNS-over-TCP doesn't break (I swear DNS-over-TCP worked when I tested it earlier this year after adding buffers).

Finally, I have added a patch that fixes DNS-over-TCP and have verified this patch patches against Deadwood 2.1.01 and Deadwood 2.2.01. I will soon (probably tomorrow) make Deadwood 2.2.02 and 2.1.02 releases with no changes except this patch applied.

For people that want DNS-over-TCP working today, the code can be seen at maradns.org/deadwood/snap

Lets look at some RRs

Like any open source developer, I like to jump the gun and think about future plans before finishing the work in front of me.

One thing I have been thinking about is how Deadwood should store non-recursive DNS records. An authoritative record is really quite different from a cached record, and needs to be stored in memory differently.

Here is how Deadwood (and MaraDNS) store a record in memory:

• A hash of a string containing both the hostname we are looking for (samiam.org, www.tagged.com, etc.) and the record type we want (A, NS, MX, AAAA, etc.) is made
• This hash is used to look up the string in memory
• A given slot can store multiple records
• We look at all the records in the slot until we find the one we are looking for

Note that the records are stored differently than the way the RFCs assume records are stored; the "A" and "CNAME" record for the same data is assumed to have the same slot in the hash (or BTREE or whatever).

While for a cache it's OK if the data for an A record is in a completely different location in memory than the CNAME record for the same hostname, this causes issues with an authoritative nameserver. Namely:

• For star records to be anally RFC compliant, the RFCs assume the DNS server stores all of the records for a given hostname in the same slot
• Whether to give a NXDOMAIN or "host not there" reply depends on whether there are some records for a given hostname
• We can more quickly find a corresponding CNAME record if the CNAME record is in the same hash slot as where the A/MX/whatever record would be

So, how should we store multiple records in the same structure?

Well, my current plan is to have an 8-element "mini-hash" for each hostname. Why 8 elements? Well, when I did some research in to what modulus works best for making it so the most common RR types have their own "slot" [1], I saw that a modulus of 8 is the best modulus under 10. The only "collision" (for A, NS, MX, CNAME, SOA, PTR, TXT, and AAAA records) is between AAAA and PTR records; however combined AAAA/PTR records are pretty uncommon.

So, my current plan is to have an 8-element array; each element of this array will point to a string, an RR number, and a "next" element (just in case they want to use some exotic record type). The string will be the data for the record they want; the RR number the RR type, and next a linked list to allow collisions.

So, this will probably be how I store records once I give Deadwood the ability to have authoritative data.

- Sam

[1] awk '{for(a=3;a<=20;a++){delete(c);printf("a: %d ",a);for(b=1;b<=NF;b++){d=$b % a;printf("%d",d);c[d]++;if(c[d]>1){printf("*");}printf(" ");}print " "}}'

New Deadwood snapshot

I have posted a new snapshot of Deadwood today. No code changes have been made; the only thing different is that there is a new file, Vista.txt, that is a copy of a recent blog here that describes one way to install and get Deadwood to work in Windows Vista.

"Cityhopper" has given me a link to download Microsoft Visual studio; I have downloaded this program and now have a full Microsoft development environment for my Windows XP system. Unfortunately, I currently don't have a copy of Vista to test Deadwood on, so will not be able to make a proper UAC menifest for Deadwood until I get my hands on Vista again. In the meantime, the admin cmd prompt workaround allows Vista users to use Deadwood.

It can be downloaded at maradns.org/deadwood/snap

Windows Vista, Manifests, and MinGW

"Mr. Max", who has been helping me with Windows-specific programming in Deadwood, pointed out that the correct way to have an application request for admin rights from Vista's UAC is to give the program a "manifest" that tells the UAC to do the make-the-screen-dark and ask-for-admin-rights thing.

However, doing some research, it looks like it's not possible to have the toolkit I use to build Deadwood, MinGW, add this manifest. The "manifest" the UAC looks for is meta-data in the .exe file; the tool to add this meta-data (mt.exe) is part of Microsoft's visual studio and I don't think Microsoft currently makes this a free download (they did a couple of years ago, but I think that program ended).

I should probably describe MinGW a little. MinGW is a set of programs that make a GNU (Linux-like) build environment available in Windows to make Windows applications. By using this toolkit, I can use the same source code and tools to build binaries both for Linux and for Windows. For various reasons I use an older version of this toolkit, and Windows Vista was only a glint in Bill Gates' eyes when the version of MinGW I use was released.

So, the toolkit I use to build Deadwood doesn't have a tool to add manifests for UAC. I don't think newer versions of MinGW do either; since MinGW is open-source software, software gets released when it is released and adding new features can be glacially slow.

The long and the short of it is this: I can't add a manifest to Deadwood.exe right now because I don't have the mt.exe tool to add this. I don't know how to download such a tool free and legally. I'm sure a version of it is avaiable over at TPB, but I don't want to go there for legal and ethical reasons (Yes, Microsoft's programmers should be compensated for their hard work).

So, for the time being, I will instruct Vista users to use the admin cmd prompt workaround to install Deadwood.

Deadwood in Vista: The admin cmd prompt workaround

I posted yesterday about working around Vista's UAC with Deadwood by renaming the Deadwood program. Another way to get Deadwood to work in Vista is to use a cmd prompt with superuser (sorry, I meant to say "admin"; I've been using Linux for far too long) privileges.

To create a cmd prompt with admin rights:

• Right click on an unused part of the desktop
• Select the "new" sub-menu
• Select "shortcut" in this sub-menu
• When it asks for the location of the new shortcut, just type in "cmd" (without the quotes)
• Click on "next"
• When it asks for a name for the shortcut, the name "cmd" is fine; click on "finish"
• There will now be a shortcut on your desktop with the name "cmd". Right click on this shortcut.
• Select "properties", and make sure the tab selected at the top of the "proprties" window is the "shortcut" tab
• Click on the "advanced" button
• Check the "execute as administrator" checkbox
• Click OK in this window and (if needed) in the "properties" window

At this point, you will have a shortcut with the name "cmd" that is akin to the "su" command in *NIX: Clicking on this shortcut will give you a command prompt with full access to the system. Note that the UAC thingy will ask for confirmation every time before giving you access to this command prompt.

Once setup, this cmd window can be used to install Deadwood on Windows Vista as per the directions for installing Deadwood in Windows XP.

How I got Deadwood to work in Vista

I was able to get Deadwood to work in Vista this week. Here is what I did:

• I renamed Deadwood.exe with the name install.exe
• I installed Deadwood as a serivce by typing in install.exe --install
• Vista's UAC thingy asked if it was OK for install.exe to run; I let it continue
• I edited the dwood2rc.txt file as per an XP install of Deadwood
• net start Deadwood doesn't work, so I had to start the service by going to the service control panel (another confirmation needed by UAC to open up this control panel) and starting the service there

Does anyone know of other ways to work around Vista's UAC tingy when installing a service, or of getting it so we can get the UAC to ask for confirmation without renaming the program?

Another possible workaround for Vista's UAC is to use an Admin command prompt, as described on this page

Why I like Windows: Things just work

Earlier this week, I was preparing an English class and needed to print out the next day's lesson. They just installed a new network printer which is, of all places, on my desk. So, I figured it would be more convenient to print to the printer on my desk than the one 5 meters away on the other side of the office, especially since I like to print documents on both sides in order to minimize paper use.

So, in XP the first thing I tried doing was using the network driver to hook up to this printer. The network driver couldn't find the printer (it probably uses some other networking protocol or some such). So, I just disconnected the printer from its networking box, and connected it to my Windows XP virtual machine (which has USB support).

The printer just worked. All I had to do was plug it in to the USB port. It appeared in the list of printers. I decided to make it the default printer and change its name to "on my desk"; this was done with a simple right-click.

This is why I like Windows. Things just work. Because, quite frankly, I am not living in my mother's basement, have a job, and have better things to do with my time than try and get something to work in Linux that works right away in Windows.

The bad news is that they have since moved this printer and it's now uptairs. Oh well, it was nice while it lasted.

ObHack snapshot update: Secret doors

I have released a new snapshot of ObHack today; this snapshot is identical to the 20090404 (April 4, 2009) snapshot of ObHack except that secret doors can no longer been seen by looking at the automap (the linedefs for secret doors are now correctly marked as "secret" linedefs).

It can be downloaded at http://samiam.org/slump

Deadwood 2.2.01 released: Testing version

I have both released source code and a Windows binary for Deadwood today. This is a testing release; while reasonable effort has been made to ensure this program does not have bugs, the emphasis with this release is to add new features and this is not a "bugfix only" branch of Deadwood.

Deadwood is a non-recursive DNS cache for CentOS 5 and Microsoft Windows XP; this is the first binary Windows release that runs as a Windows service. This code will eventually become MaraDNS' recursive cache.

My next step is to add Deadwood's man page to the Windows binary and add a pointer to the cache file in the included example dwood2rc.txt file. After that, I plan on making it so DwTcp can become a service also.

Once DwTcp can become a service, I will release another 2.2 release of Deadwood.

After that, I will work on making the code more modular.

Deadwood 2.2.01 can be downloaded here:

http://maradns.org/deadwood/testing

Deadwood snapshot update

I have released a new Deadwood snapshot today:

• All compile-time warnings in Win32 removed.
• Code to install and remove service now lets user know if the service was installed or removed.
• Win32 README added (this is mosly a copy-and-paste of INSTALL.txt)

It can be downloaded at the usual place

Simple RadioGatun library

A while ago, I wrote a simple code-size optimized Radio Gatun library. A version of this code is used in new ObHack releases, and can be downloaded here or looked at here.

ObHack snapshot released: Real secrets

One thing that has always bothered me a bit about Oblige/ObHack is that secrets are fairly rare, and no real effort is made to hide the secret areas.

Today's snapshot of ObHack fixes this. Now, ObHack generated maps will always have at least one secret on a level. In addition, it's not quite so trivial to find a secret; you need to pay attention to find it.

The ObHack snapshot (20090404) can be downloaded by clicking on this link.

Deadwood snapshot update; On open source

I have just posted an update to Deadwood today. Lots of changes:

• log file name changed from "log.txt" to "dwlog.txt" (so admins who forgot where they put Deadwood can more easily find dwlog.txt)
• Date and time added to Windows dwlog.txt logfile
• log file flushed (updated) whenever there is a second of inactivity (if the server is busy, the log file won't get flushed, but will get flushed when idle)
• INSTALL file changed to use Win32 line breaks and renamed "INSTALL.txt"; file updated to have more comprehensive startup information for CentOS 5 and a note about dwlog.txt.
• Fatal dwood2rc error now correctly noted as a dwood2rc error
• Makefile renamed Makefile.centos5 in src/; Makefile.mingw renamed Makefile.mingw310 (I'm making it clear I only support CentOS 5 and MinGW 3.1.0)
• Cleanup of Makefile for CentOS 5 duende helper
• Some compile-time warnings when compiling in Windows removed

---

I feel empty and betrayed by Open Source.

For years I believed the big open source lie. I believed that a group of volunteers working together on the internet could make professional-quality end-user software. I was wrong. Flat-out wrong.

What BSD and later on Linux has shown is that a group of volunteers working during their free time can make a free computer operating system which is very powerful, but very difficult to learn.

This is what Linux was when I first used it in 1995. It was no Solaris, but it was a good deal more stable than Windows 3.11 and Windows 95. It would take me hours to get X configured and working, but once it was working, it was rock-solid stable. I wasn't getting any BSODs (messages Windows shows when the system crashes).

I remember I had Windows 95 [1] and Linux in early 1996, and wanted to set up PPP (the most common way of using a modem to access the internet) so I could use Netscape. It took make about half an hour to get Netscape and PPP going in Windows 95; it took me two or three days to get Netscape and PPP to work in Linux.

However, despite the difficulty of using Linux, I preferred it because of its stability. I had one friend with a driver in Windows 95 that was constantly giving him BSODs; I told him he should use Linux more. I remember another friend who tried getting Windows 95 working on an AMD motherboard he had and him reinstalling and re-reinstalling Windows 95 and never getting the system to quite work right.

I remember feeling Microsoft was an evil monopoly because you couldn't make a motherboard or other peripheral without getting Microsoft to support it. I remember Microsoft using their monopolistic practices in the 1990s to drive Netscape out of business and hating Microsoft for doing that.

At the same time, I was resenting all of the companies who wouldn't release hardware specs for their cards so we could use them in Linux, and resenting the companies (like Real networks) who made video players without Linux support. I felt like a second-class computer citizen. There was so much I couldn't do because I used Linux; I couldn't watch videos in Real player. I couldn't use Microsoft office (and spent a good deal of money buying WordPerfect and Applixware's office suite for Linux) or easily read .doc files.

I remember people using StarOffice (since its binary was a free download) and thinking these people were cheap bastards for not getting a real office suite for Linux (I had managed to get a good job in Silicon Valley at this time, so it was nothing to spend $200 or $300 here and there to get an office suite).

Solaris was still big and the issues I had with Microsoft Solaris admins had too. So I wasn't alone in my dislike of Microsoft.

Well, in the 2000s, a lot changed. The dot-com bubble burst and I no longer worked in the tech industry. Solaris basically died, with I got a degree in computational Linguistics and moved to Mexico to discover myself.

Netscape was killed by Microsoft's monopolistic practices; by 2002 everyone was using Internet Explorer. Windows XP came out in 2002 and the instability problems that always plagued Windows 95 were once and for all resolved by having people use a version of Microsoft's server-class code on the desktop.

Linux, however, did not improve their desktop experience.

In the mid-1990s, the big distro to use was Slackware; in 1997 I went from Slackware to RedHat because it was easier to apply security patches in RedHat. RedHat was the dominant distro to use when the dot-com bubble burst in 2001.

RedHat never made a serious effort to make Linux a desktop OS; their bread and butter was selling servers.

In 2003, RedHat realized they couldn't sustain their business model giving their flagship product away, so they did the RHEL/Fedora core split. I used Fedora core for a while, then moved from Fedora Core to CentOS when this free RHEL clone became available.

To fill the vacuum for a desktop-oriented Linux, their was first Mandrake (originally a fork of RedHat 5) then later on, Mark Shuttleworth made a few billion dollars and decided to fund his own free Desktop Linux, Ubuntu.

Because of fragmentation in Linux (the eternal KDE-vs-Gnome battle), desktop development was divided between two different desktop projects (more if you count things like XFCE and Blackbox). Free software developers are more interested in "scratching their own itch" than in adding features that don't benefit themselves but benefit users of the software; this makes it more difficult to motivate people to help with end-user Desktop software.

Linux, simply put, did not have a usable end-user desktop when Windows XP came out in 2002. Microsoft won the race: Microsoft was able to make their high-quality desktop use server-class code for the underlying operating system before Linux could make their server-class operating system an end-user desktop.

Linux still does not have a usable end-user desktop today. Issues that don't matter when making a *NIX server matter a lot when making a desktop computer. It matters on the desktop that the underlying libraries and kernel change so much it's hard to make a binary-only desktop program that will continue to work for the foreseeable future. It matters on the desktop that binary-only drivers are not welcome, and that the kernel developers go out of their way to not allow these kinds of drivers.

I have looked at Linux for years, and have been using Linux since 1995, and as my only real desktop OS from 1995 until 2003. It hasn't changed. It's always been fragmented with strange bugs and a lack of discipline to give users the things they expect a desktop desktop to have. I thought in 2000 we would have the year of the Linux desktop. I realize, in 2009, that we're never going to have the year of the Linux desktop.

Firefox shows that people can make open-source professional-quality desktop software that people will use. About 30% of people surf the internet using Firefox and it didn't come out until 2004 or so. 1%, maybe 2% of people surf the internet using Linux, even though Linux has been around since 1991. In little over four years, Firefox was able to get desktop adoption Linux can only dream of.

It's sad that Linux is too fragmented to do the same thing. Ubuntu's instability (because they have to use unstable versions of software to support new hardware) is on par with Windows 3.11. I'm glad that Linux has become a viable server OS; I'm sad that Linux will never become a viable desktop OS.

- Sam

[1] I didn't use Windows 95 very much back then; Linux was my primary desktop OS and Windows 95 was on my old 486 so I could keep my skills up to date.

Linux sucks: CentOS 5 doesn't support my laptop

OK, I've tried Ubuntu. It was nothing but crash after crash after crash. I finally threw out Ubuntu, repartitioned my hard disk, and used only Windows XP, with CentOS 5 in a virtual machine.

Last night, I tried to install CentOS 5 on my laptop. I wasted most of a day worth of work on this project.

It didn't work.

The base install was pretty quick and took maybe 40 minutes.

First of all, the wireless card didn't work. I followed the directions on the CentOS wiki and it still didn't work. I was able to see wireless networks, but was unable to connect to my home network. I wasted about an hour of my life trying to get this to work.

This morning, I tried getting the touchpad driver working so the touchpad doesn't click the mouse button every time I tap the touchpad. After installing the synaptics driver, I had to figure out how to configure xorg.conf to use the driver. Well over an hour of my life wasted doing that.

Once I did all that, it still didn't work. It would seem my touchpad isn't supported with the touchpad driver in CentOS 5. I tried newer drivers; either the newer driver wouldn't compile or the driver wouldn't work.

So far, I had wasted four hours of my life. In Windows, the same amount of work would have given me a working computer at this point. Actually, in Windows, it would have taken about an hour to install the base system, under an hour to get all the drivers up and going, and I could have played video games or spent time with my girlfriend the other two hours.

I did buy Linux hardware. I specifically got a Linux-compatible Dell. And, yes, the hardware does work in Ubuntu, but, unfortunately, the system is too unstable for me to use.

I pointed out the issue here:

Linux's problem is this: Drivers for CentOS 3 do NOT work in CentOS 5. Why is that? Why do the Linux developers need to constantly change the driver model while Microsoft is able to keep the driver model stable? Constantly changing driver models is fine in the server back room, but is not OK for an OS that wants to be on the desktop.

This is why Windows XP, not Linux, is on my desktop right now; Ubuntu is far too unstable for me and I shouldn't be forced to use an unstable OS just to have drivers. I mean, there are drivers for all my hardware in Windows XP. And there are drivers for all of my hardware in Ubuntu 7. So why aren't there drivers for all of my hardware in CentOS 3?

(I may move back to Linux on the desktop if all my hardware works with CentOS 5.3; we'll see)

Here is how one freetard replied to me:

your [sic] being technically handicapped and/or grossly uninformed about Linux kernel development. However, if you keep sticking your foot into your mouth, you will at least add some mild entertainment to the thread while we wait.

I replied to this idiot:

YoureAnIdiotForNotLikingLinux(TM)

A lot of people here have been using Linux for a long time, or used to be freetards (I myself am a recovering freetard). We probably know Linux a good deal better than you do. Note also that Ken Thompson doesn't like Linux, and Dennis Ritchie uses Microsoft Outlook to read email these days.

Anyway, could you care to explain where I am wrong and how I'm wrong. Please back up your assertions with facts.

He never replied to me.

Linux sucks on the desktop. I'm back to using Windows XP. Even at $5 an hour, the $100 that Windows XP home edition costs [1] is 20 hours of labor; it would take me about that long to get everything working in CentOS 5.3.

OK, since I wasted my time with Linux (again), I didn't get a chance to work on Deadwood. I will continue working on it tomorrow.

- Sam

[1] As an aside, cdsfu.com sells pirated software and Google needs to stop letting them advertise.

Deadwood snapshot update

In today's Deadwood snapshot, I have decided to remove all Linux support and have Deadwood be a Windows-only binary. I realized that I wasn't making what I was worth giving away my hard work, and Deadwood from now on will be a shareware application; Windows users are free to use it but will get a nag screen every time they boot their system until they register their copy of Deadwood. This will hopefully result in me earning enough money to return to the United States with my girlfriend and marrying her in the states.

Happy April Fool's day everyone.

Deadwood, for now, is still an open-source (BSD licensed) application and still compiles and runs just fine in Linux (well, CentOS 5.3; I don't test it in other versions of Linux and your mileage may vary). However, I have slightly improved its Windows support today by cleaning up the logging a little, and by removing a couple of compile-time warnings one sees while compiling Deadwood in Windows (it has no compile-time warnings in Linux).

Today's snapshot can be downloaded at the usual place