Wednesday, March 31, 2010

A “carousel” is, among other things, an object on a web page that allows you to scroll left and right to see multiple images; it is akin to Windows XP’s “filmstrip” view of images.

Here is a webpage linking to several Javascript carousel plugins:

Tuesday, March 30, 2010

Workaround for yet another IE6 bug

A workaround for yet another IE6 bug:

Sanename: Remove unusual characters from filenames

I was having a difficult time manipulating a lot of files my boss gave me yesterday with scripts in Linux because the files had spaces and other unusual characters in them. I finally wrote a small C program that recursively renames all files in the current directory and all subdirectories so that anything that isn’t ASCII, a letter, a number, or one of the _-. characters in a filename is converted in to a _ character.

Note that this program is dangerous and you shouldn’t use it unless you know what you’re doing.

It can be looked at here:

I do not support this program and it comes with no warranty.

Friday, March 19, 2010

Every HTML/CSS coder’s dream

Every HTML and CSS coder out there with any semblance of clue is eager awaiting the day when no one is using Internet Explorer 6 any more, and dreams of the day no one is using Internet Explorer 7 either.

For example, the last two days at my new job, I have been designing some web pages as per the client’s specifications. The client wanted a certain type of navigation bar, which I implemented using a pure CSS design. It looked great in Firefox, Opera, and Safari.

It looked ugly in Internet Explorer 6. I had to spend over an hour redesigning the navigation bar using a table-inside-table design. Once I did that, I had to spend about another hour doing more workarounds so the design would look good in IE6 and Internet Explorer 7.

I would have been done with the entire site design right now if IE6 and IE7 weren’t used by anyone. Since I had to spend hours working around these browsers’ bugs, I won’t be able to finish things until this afternoon.

I know of four web stat sites who freely give out their numbers on Internet Explorer by version number. Here are the current numbers:

SiteIE6 usageIE7 usage

We probably won’t see IE6 numbers go below 2% until 2012; IE7 (which, while buggy, is a lot more pleasant to work with than IE6) will probably linger with numbers higher than 2% until 2015 or so. So, yeah, I will be wasting a lot of time with these ancient browsers and their bugs for a while longer.

Update: I’m not the only one eagerly awaiting IE6’s death. YouTube has just dropped IE6 support and puts up a big “Upgrade your browser” banner visible only in IE6.

Thursday, March 18, 2010

I’m a web page designer now

Well, I’m slowly but surely getting back in the tech sector. My last gig only had me peripherally involved with tech. My job there was to teach English and translate documents; I also was supposed to help babysit the Windows machines.

While I was happy teaching English, and pleased with how well I translated documents, the tech sector part of the job was not the type of experience I needed to keep my skills current in the tech sector.

So, here’s to the new job giving me more relevant experience (Linux, Apache, MySQL, PHP, etc.)

Tuesday, March 16, 2010

Technology and operating system market share

There is an obsession Linux fanatics have: Microsoft Windows. Their obsession includes, among other things, an obsession about how much market share Windows has. The answer: Not as much as they think.

In addition to Macintosh users and Linux on a lot of servers (and the occasional ultra-geek who uses Linux on the desktop), there’s a lot of technology out there where Microsoft doesn’t have a dominant market position:
  • Cell phones (WinCE is a niche player)
  • Portable book readers (Kindle, iPad, etc.)
  • Car computer systems
  • Servers (While there is IIS and Exchange, Microsoft can’t undersell Linux, BSD, etc.)
  • Dedicated video game consoles (There is the Xbox, but it has to compete with the Playstation and whatever console Nintendo has)
  • DVD and Blu-ray players, as well as stereo systems and DVRs
  • GPS navigators
In my last blog where I talked about how we use technology, and how things have changed in the last two decades, I noted a lot of places where people use technology, most of which involve uses not dominated or controlled by Microsoft.

The idea that Microsoft controls computing and how people use computers is a rather silly idea.

Sunday, March 14, 2010

What we use technology for

Let’s imagine we have a time machine.

The year is 1990 and we are in the technological age. In particular, we have the following in our house:
  • A computer, which we use for writing documents and keeping track of finances.
  • A Nintendo, which we use for playing video games (we may also use the computer for this)
  • A stereo system, which we use for listening to music. This will usually have a cassette and CD player, as well as a radio.
  • A television and VHS VCR, which we use for watching television and renting movies.
  • A telephone, for keeping in touch with people, communicating with friends or business contacts, or asking for a delivery of pizza
  • A camera for taking pictures
When we’re not at home and on the road, we have a Walkman (portable cassette player) for listening to music while walking around, and a cassette based car stereo for listening to music while driving.

Twenty years later, we’re still using technology for the same tasks
  • A computer, which we use for putting music on our MP3 telephone, burning CDs with music to play on our home theater or car, keeping in touch with people we would have lost touch with 20 years ago when we moved, communicating with friends or business contacts, and, oh occasionally writing documents and keeping track of finances.
  • An Xbox/Playstation/Nintendo for playing video games (or our computer)
  • A home theater system, which we use for watching movies, or sometimes for watching TV or listening to music. DVD/Blu ray players can play CDs, and we no longer use cassettes for custom mixes of music because we can now burn CDs.
  • A telephone, for asking for a delivery of pizza

On the road, we have more options:
  • A telephone, for listening to music when walking around, playing video games on the road, taking pictures, and, oh, for communicating with people wherever we are.
  • Our car either has a MP3 CD player, an input so we can hook up our phone to its speakers (via a plug or bluetooth), or we have some adapter to listen to music from our phone while on the road.
  • Our car often also has a device which lets us pop up a map and navigate our journey.
As you can see, we use technology for a lot of tasks. I will discuss how this affects operating system market share in a future blog entry.

Saturday, March 13, 2010

OK, how to store tasks in recursive Deadwood

Since Deadwood is currently a non-recursive cache, we have only one task we perform: We send a DNS query to an upstream server, whose reply we cache and forward on to the end-user.

Since Deadwood only does one task, the structure for remote connections doesn’t need to store what task we’re doing with a remote connection.

This needs to be changed to implement full recursion.

So, let’s add to that structure a “task” element: What we’re doing right now in our process of solving a recursive DNS query.

We can have Deadwood perform the following tasks:
  • We are connecting to an upstream DNS server with the RD (recursion desired) bit set. Whatever reply they give us is one we will cache and forward on to the stub resolver. This is currently the only task Deadwood can do. Should the connection fail, or the reply is not a “complete” DNS reply, we will try another upstream server.
  • We are connecting to a DNS server which is marked as being a possible NS server to our query. The reply is one we may or may not pass on to the client, depending on whether it is a complete reply.
  • We got an incomplete CNAME referral, which indicates we need to change the name of our query to whatever name was at the end of the incomplete referral and do a new query
Tasks will be stored as a stack. The first taks we will have is to connect to the “lowest” NS server we have an entry for. Here is how our remote query will look:

Main -> Non-recursive NS server connect (solve client query).

Should we need to resolve the IP for a glueless NS server, here is how the above task list will then look like this:

Main -> Non-recursive NS server connect (solve glueless IP) -> Non-recursive NS server connect.

If, when trying to solve the glueless IP, we need to solve an incomplete CNAME referral:

Main -> Non-recursive NS server connect (solve incomplete CNAME referral) -> Non-recursive NS server connect (solve glueless IP) -> Non-recursive NS server connect (solve client query)

OK, looking at this, our task will always be trying to make a non-recursive NS server connection. However, we need to store why we’re making this query (client query, glueless IP, or incomplete CNAME referral).

So, we’ll keep the SOCKET, remote_id and the time-to-die, as well as a pointer to the local queries for this query and the initial local query in the “root node”. However, the number of retries as well as the query we’re doing to store this particular task, as well as the list of NS servers we will try to connect, and the number of times we will try before giving up, need to be stored in a special “task” structure which will be stored as a stack pointed to by the “root” DNS query.

Friday, March 12, 2010

More on how recursion is done

Recursion will be done in Deadwood as follows:
  • We look for a record in the cache with the same name and type as the stub resolver requested.
  • If not found, we will look for a CNAME referral with the same name as what the stub resolver requested
  • If not found, we will look for a NS referral with the same name as what the stub resolver requested
  • If not found, we will lop names off of the front of what they requested as a NS referral until we find something in the cache
When we find a CNAME referral, we change the name of what we request to be the final name in the CNAME referral, note that we had this CNAME referral, and continue processing.

When we find a NS referral, we use a NS server at random. If the server is glueless, we will have to find out the IP address of the NS server before proceeding. To hand glueless records, we note the list of NS records as the current step in the recursive process, look up the glueless record, and then continue as before.

I will discuss how to store this entire process in a future blog entry.

Tuesday, March 9, 2010

How Deadwood stores pending remote connections

To implement full recursion, I will have to do an overhaul of how Deadwood stores pending remote connections. In more detail: A pending local connection is when a DNS stub resolver sends a query for Deadwood and is waiting for a reply. A pending remote connection is when Deadwood sends a DNS query to another DNS server and is waiting for a reply.

Here is the structure for basic UDP remote connections:

typedef struct {
SOCKET socket;
int64_t die;
uint16_t remote_id;
int retries;
dw_str *query;
uint16_t num_locals;
local_T **local;
} remote_T;

Note that, in the actual source code, this is commented. To expand on the comments:
  • socket is the number for open socket which will get the UDP data. It’s called a “SOCKET” here because Windows, unlike UNIX, doesn’t use integers for sockets.
  • die is a timestamp for when this connection will be timed out and needs to be discarded. Note that this is a 64-bit number; Deadwood uses 64-bit timestamps to minimize Y2038 problems
  • remote_id is the 16-bit randomly created query ID generated by Deadwood using a cryptographically strong pseudo random number generator. If the reply doesn’t have the same query ID, it might be a DNS spoof attempt.
  • retries is the number of remaining times we will retry if the remote server doesn’t reply to our query when it runs out of time (when our time is the same or greater than the die time)
  • query is the query (name, DNS record type) we sent to the remote server; we keep a copy of it here because we need to make sure the query we get is the same as the query we sent them (again, to make spoofing harder).
  • num_locals is the number of local connections we send an answer to once we get a reply from the upstream server. This was added when I implemented the merging of multiple in-flight requests with the 2.4.07 release of Deadwood (August 31, 2009). When one program asks for, say, and another program or computer asks for while we’re still waiting for the first reply, Deadwood will merge the second request in to the first request, and send the reply to both clients once we get the reply upstream.
  • locals is a list of “local” connections (which can be either UDP or TCP connections); there are the connections we send a reply to downstream once we get a reply upstream
Now, this structure is a simple structure which is fine when the upstream server does the heavy lifting and we’re just caching and forwarding the reply they send us, but this will need to become a lot more fancy in order to make full recursion a reality.

I will discuss what changes I plan to make to this to make recursion possible in a future blog entry.

XFCE 3.2 for CentOS 5

I managed to update an ancient RPM of XFCE 3.2 to compile in CentOS 5. My updated source code RPM is available here:

Friday, March 5, 2010

New Deadwood stable branch: Deadwood 2.5

I have updated the stable release of Deadwood to use the 2.5 branch. This gives us two significant features compared to 2.4:
  • DNS wall functionality (enabled by default; if a DNS reply gives us a 10.x.x.x, 192.168.x.x, or 172.[16-31].x.x IP, we discard the reply)
  • TCC support, allowing people to compile Deadwood in Windows without needing to install an entire development suite
The release I have made is Deadwood 2.5.02; compared to Deadwood 2.5.01, the only change is a small bugfix to the decompression code; there were minor problems with incorrect rdlengths in decompressed packets (see this blog entry for details).

I have done a full test battery for Deadwood 2.5.02; all of the 32-bit and 64-bit SQA tests were done to verify there are no regressions; I also have made sure both the TCC compile and premade binary for Windows work (and, indeed, am using the Windows binary of Deadwood 2.5.02 for DNS lookups writing this blog entry).

In addition to releasing Deadwood 2.5.02, which is available at and on MaraDNS’ download page, I have also updated the MaraDNS snapshot to use Deadwood 2.5.02 (available here), as well as the “head” branch of Deadwood (here).

Thursday, March 4, 2010

I’ve updated the blog

I’ve added a couple of things to the left sidebar of the blog:
  • A pointer to a FAQ with some guidelines on what comments get approved or rejected here
  • A search tool so people can search for information in older blog entries
Please read the blog FAQ before posting a comment here; the FAQ describes what comments I approve and reject.

Wednesday, March 3, 2010

Deadwood 2.6.01 released

Deadwood 2.6.01 released.

This is a Deadwood release with a significant part of full recursion implemented: The code that analyzes an incoming DNS packet to determine what the next course of action should be (send the reply to the stub resolver, contact another NS server, look up a different hostname because we got a CNAME referral, etc.), complete with security checks like bailiwick verification, has been done.

Right now, the code that caches an entry runs this code to massage a DNS packet; this results in the packets Deadwood returning from cache looking different (anything that isn’t an answer to our question is now removed from a DNS packet). Indeed, I had to overhaul the SQA tests to reflect this change.

This is an important step in giving Deadwood full recursion so I can get MaraDNS 2.0 out the door.

It can be looked at here:

New Deadwood snapshot: All sqa tests (but 1) pass

All sqa tests modified or bugs in program fixed so that the tests past, with the exception of the "sqa_tcp_buffering_2" test. (Update: The issue was that this particular test is a bit unreliable and doesn’t always pass. I got it to pass once in both the 32-bit and 64-bit environment so I closed this issue and released 2.6.01)

Here’s a cool link:

This lists every single Window manager for X that exists. Every single last one.

I’m still using FVWM1 from 1995; I will use something more recent when and if someone makes a Window manager that supports:
  • Seamless focus follows mouse (When I tried FVWM2, its focus-follows-mouse was buggy)
  • Multiple workspaces
  • Multiple windows inside each workspace. What FVWM supports which I haven’t seen any newer WM do is, in addition to having multiple workspaces, each workspace is a virtual screen larger than one’s desktop; applications can be moved from one desktop to the other by simply dragging the window past the edge of the screen.

Tuesday, March 2, 2010

New Deadwood snapshot: Getting ready for Deadwood 2.6

I have finished up the code generating packets telling the upcoming fully recursive release of Deadwood what to do when they get a packet upstream. At this point, packets processed by this code are stored in the cache as-is.

Next: Test the code; make changes as needed should the tests find any bugs, and then release Deadwood 2.6.01.

My final ObHack release

A while ago, I found a minor bug in ObHack which Fritz fixed.

I have finally gotten around to integrating Fritz’s patch in to my version of ObHack, which I call “ObHack-006b-pl1” (ObHack release 006b patchlevel 1). This is simply ObHack 006b with Fritz’s patch.

Barring a security hole in ObHack, this will be my last ObHack release. Fritz is the current maintainer and has made a lot of improvements and changes which I encourage people to download and use. Also, Andrew has very recently made a release of Oblige which makes some impressive maps.

As always:

Monday, March 1, 2010

New Deadwood snapshot: NS referral format revised

I have slightly revised the format of a NS referral in the second Deadwood snapshot for today. In the revised NS referral, we start off the string describing the NS referral with a single DNS label (DNS name) describing where in the DNS space the referral string points to (whether this packet should point to NS servers for all of the .com records, the NS servers or what not).

Besides this, the format of a NS referral is identical.

New Deadwood snapshot

Updated INSTALL.txt to be current with post-2.3 Deadwood changes.

dwx_remake_complete_reply(), which remakes a "complete" NS reply with all records which do not directly answer the question removed, implemented.

Next: Make sure we handle NXDOMAIN replies correctly, then have it so Deadwood puts dwx_cache_reply()-made answers in to the cache.

As always: