The Nuclear Bunny Blog

The Kindle 2 I bought arrived today and I have spent the evening playing with the new gadget. I haven’t had very much time for some serious reading with it yet, but there are some fairly clear early impressions that can be drawn.

The e-ink display is absolutely amazing. It is just beautiful. I find it easier and clearer to read than most printed material and it doesn’t feel like you are viewing an electronic device at all. I haven’t really used this technology before, so one thing that did come as a surprise is that each page turn or refresh is noticeably slow. That is, it takes probably around a quarter of a second to actual render the page. It doesn’t get in the way, but it was a surprise. This is an artifact of the e-ink technology itself, which effectively “prints” the page material once and then the display holds it stable.

The size and weight of the device is just right. It’s about the size of a standard paperback and at 10 ounces feels just right in your hand. It is incredibly thin – less than the thickness of a small magazine. Even with one of the optional covers on, there would be no problem taking this thing on a long holiday or business trip.

The user interface for reading is good. The button placement doesn’t seem quite perfect for my hands, but more time will tell. Pages turn fast enough and the ability to quickly highlight words and get their dictionary definition is one of the best features of the device. That said, it clearly would benefit from a multi-touch interface, ala the iPhone, but this would likely just render your e-ink display full of smudged fingerprints.

The keyboard and cursor control are acceptable, but it was much faster to do browse for and buy books via a computer web browser. There are some clear engineering trade-offs made on the keyboard and the cursor control to make them useful in a real world scenario. The good news is it only takes a couple of minutes and then the interface is very natural and more than fast enough.

Amazon’s selection of Kindle books is more than adequate at the moment, and certainly more than we can read in a lifetime. We’ll see as time goes on if the books we want to read show up in the Kindle store versus in print.

I am curious to see if the Kindle 2 is something I will enjoy using or not.  There is something incredibly wonderful about the tangible feel of a book that makes any e-book reader a hard sell. We’ll see if I find it pleasant enough to use for my primary reading tool or not.

At Zenoss we do quite a bit of remote monitoring of computers running Windows. In the Enterprise edition of the product, we collect raw performance counter data using the conventional remote Windows Registry APIs.

We ran into an issue recently with a customer running Windows 2000 where the data from the remote server was being truncated prematurely. Since we implement our own remote API (so we can run natively on Linux and with Python, rather than requiring Windows), there was some immediately concern we ran into a low-level bug in our protocol implementation. Thanks to the release of the Windows Communications Protocols (MCPP) last year we have great detail on how our API layer should function.

Reviewing the MCPP in detail compared to our implementation showed no bugs against the specification, but I did notice some odd behavior. Normally when using the RegQueryValue API you specify a NULL buffer point and a zero-length buffer size so that the call will provide the actual size of the buffer needed. With this particular customer’s server I noticed that this behavior wasn’t behaving as documented in the MCPP.

An error code of ERROR_MORE_DATA was being returned. The MCPP says that when this value is returned the server will populate the size output variable with the actual size in bytes of the needed buffer. In this case, the size was always the same size as the input. After some experimentation I found that if I passed in approximately 64 Kbytes more data the call would finally succeed.

While quite odd behavior, this is actually the documented and expected state in the Win32 API documentation for RegQueryValueEx, but not in the MCPP. Specificially, when using the HKEY_PERFORMANCE_DATA key the ERROR_MORE_DATA behaves differently and the caller has more responsibility in guessing an appropriate buffer size.

The following pseudo-code shows the basic flow for how RegQueryValueEx should be used, either for locally or remote performance data access.

size = 65536 # starting size, probably computed from a previous registry call
params.in.data = params.out.data = buffer(size)
while 1:
    params.in.size = size
    params.out.size = 0
    dcerpc_winreg_QueryValue(params)
    if params.out.result == ERROR_MORE_DATA:
        size = size + 65536 # add another 64 Kbytes of data to the buffer
        params.in.data = params.out.data = buffer(size)
        continue
    break

After fixing that issue I was still left with one oddity. Let’s say, for example, it took 293,500 bytes of data before the RegQueryValueEx call was successful. And yet, the actual amount of returned data would only be 195,000 bytes, or something similar. This behavior seems quite different than on the other Windows operating systems we have tried so far.

This is the first time we’ve tried our data collection against a Windows 2000 server running Exchange locally. Windows 2000 has also been the source of several other key behavior differences in how performance data is returned, so my current speculation is how the server actually determines what data to be returned varies greatly between operating system versions. We normally query the performance counter registry for only a subset of values. It may well be that on Windows 2000 a buffer size large enough to retrieve all performance counters is required, even though once the call is complete it actually used quite a bit less.

Quirky, but another bug gone.