Nynaeve

Evidently, a couple nights ago at 2:30am or so, my datacenter box grew an extra ~1GB of RAM for about 10 minutes:

Unfortunately, the magical mystery RAM (for lack of a better word) disappeared after about 10 minutes. Too bad, more RAM would have always been welcome…

It seems that there’s some sort of strange bug with either Cacti or the SNMP utilities that it is using to query data, which occurs when the box is under load. At the time when the anomalous measurements were returned, there was a transitory jump in load average on the monitoring system (if the Cacti graphs are to be believed this time around):

(Did I mention that things have a general tendency to break in strange and mysterious ways while in my presence?)

Anyways, now I have to wonder how reliable my other Cacti graphs are after this little discovery. This time, at least, the discrepancy was fairly obvious…

Today, I’m heading out to Redmond for this coming Blue Hat. My first time going to Blue Hat, but it’ll hopefully be interesting, to say the least :)

I’m definitely looking forward to seeing some of the presentations, and meeting some interesting people. along the way.

I decided to go check that the frontpage of the blog still passed the W3C XML validator today (something I try to remember to do at least semi-regularly) and, to my dismay, there were validation failures all over the place.

It seems that WordPress is not particularly intelligent about determining where it should and should not place <p> tags; depending on how you place your whitespace around the beginning of a list (ol/li) or tt (or other tag whose contents tend to span multiple lines), it seems to have quite an affinity for either spewing completely bogus open or close p tags (or closing tags in the wrong order, such as a opening a p tag before a user-specified li tag, then “helpfully” automagically closing the p tag before the closing li tag the user writes in the post).

The worst part of the whole thing is that the breaking tags are autogenerated, and they’re controlled by what sort of whitespace (e.g. blank lines) you have near your the opening and closing tags. Because the “helpful” autogenerated tags aren’t visible at “design time” for a post, you’re all but limited to blind trial and error to get it working right. Sometimes, you even need to put seemingly bogus </p> tags in at “design time” to match unbalanced tags emitted by WordPress automagically at display time.

I love how this turns writing blog posts that render properly into debugging something that is influenced by how I use whitespace. Argh!

Excuse me, while I go back to figuring out the right combination of blank lines to fix the rest of the blog’s tag close mismatch failures…

The blog’s been (finally) moved to a reliable box, at a reliable location (including all dependent services), so that should be the last of the intermittant downtime.

So, same url, but minus the random downtime.

The box I have been hosting the blog on had got to its last proverbial leg as of late; hanging about every 12 hours or less. So, I decided to move the whole thing over to another box. I’m already in the middle of another project to eventually host the blog at a real location, but that’s still in the works and not ready yet. Not wanting to go to the trouble to configure WordPress and everything on another box just temporarily, I decided to give the VMware Converter a try and move the entire box into a VM image on a more stable computer at my apartment.

So far, I’m pretty pleased with the results; it took only a couple of minutes to install the converter and start the conversion process (which took about 1.5 hrs total to complete). Surprisingly enough, the thing mostly just worked out of the box after being VM-ized; I had to install VMware Tools, and reconfigure network settings a bit, but other than that, the whole experience was rather seamless.

For now, the blog should be a bit more stable (now living as a VM on a relatively new and, ah, higher quality tower server that I recently acquired to run most of the services for my apartment).

And as far as VMware Converter goes, color me impressed; I expected to run into a lot of snags, but the user experience was quite good. Definitely a great timesaver for retiring old, failing hardware without having to go through the trouble of reconstructing a new install to perform the tasks of the old one.

Well, I just spent the past hour and a half trying to resurrect the box that hosts the blog after it froze again. I finally succeeded in getting it working (cross my fingers…). At this point, though, I think that it’s time to start working on moving the blog to a more reliable location. The current box has locked up a couple times this month already (to the point where I can’t break in with either KD or SAC), which is worrisome. Furthermore, as the current box also happens to be routing for my apartment LAN, it locking up also means the primary Internet connection will for my entire apartment will go as well – ick. The fact that it took about an hour and a half of disassembling it and putting things back together to get it running is definitely something I take as a strong sign that it’s going to take a turn for the worst rather soon. Granted, this box was donated to me, so I suppose I can’t complain too much, but it’s time to get something more reliable.

Since I’m going to be switching boxes for the blog anyway (as the current box looks as if it is going to die, permanently, any day now), I am going to move it to a more capable hosting location (i.e. not my apartment) while I’m at it. Furthermore, I’ll probably be going ahead and upgrading to the next major WordPress version soon as well now that it’s out of beta. Assuming that goes well on the new blog server, it’ll be running 2.1 when I cut it over from the old box.

Hopefully, this should end up with the blog being a bit more responsive (the burst data rate at my apartment is a bit less than I would like for hosting the site), and (finally!) drive a stake through the periodic but short outages I’ve had due to flaky hardware over the past few months.

I’ve finally gotten around to getting a new computer; an XPS M1710 with a 2.33GHz Core 2 Duo processor, 2GB RAM, and a GeForce 7950 Go GTX (512MB RAM). It’s been working fairly well so far performance-wise (and with dual core, my computer was even responsive during VS2005SP1 setup!). There were a couple of nice unexpected upgrades that I happened to get in the process; the new laptop has a built-in smart card reader (good-bye clunky USB smart card reader), and the LCD backlight brightness is much improved over my Inspiron 9300 (a relatively dim backlight and a glossy display made that laptop difficult to read sometimes, depending on outside lighting conditions). Also, the programmatic LCD brightness API seems to be functional with the new video card (I’ve got some plans for that, primarily relating to replicating the neat MacBook Pro behavior of automatically dimming the display when idle – assuming no program has put the system in contiguous display mode, like with video playback or slideshow presentations).

Having a dual core chip on my main workstation is definitely a noticible benefit for me; the difference is immediately visible when running two intensive programs at the same time (which is a common occurance for me, a multimon addict). If you do serious multitasking on one computer, then you’re a prime candidate for seeing real benefit from dual core, in terms of keeping the system responsive while running more than one intensive program simultaneously (provided your programs aren’t all I/O-bound).

Perhaps the most fundamental change, however, is that I decided to go with Windows Vista x64 as the operating system. This means that for all general-purpose computing, I am effectively cutting over to a 64-bit platform entirely (in the past, I’ve only really used x64 for development and not as a general-purpose platforms). This includes the whole gamut, from development and debugging to games and email and whatnot. I’ve already tried Vista out as the operating system on my primary workstation before and it worked out well enough, but taking the leap to 64-bit is another story entirely. Since there’s no backwards compatibility with 32-bit drivers, this is a bit more of a change than just switching to Vista as far as having working hardware goes.

It turned out that things ended up much better than I thought, however. Vista ended up shipping with native x64 drivers for almost all of my hardware (even the Bluetooth 2.0 card and draft 802.11n WLAN card – seems the people at Broadcom have been busy working on their drivers lately). The only hardware that didn’t have native drivers out of the box were several of the non-SD memory card reader devices (i.e. Picture Card), which I don’t really happen to care about, and the video card. Getting the video card to work was a bit of a hassle; I first grabbed NVIDIA’s latest official Vista x64 beta drivers (release 96.85), but these turned out to be fairly buggy (strange graphical corruption in fullscreen mode in Neverwinter Nights 2). Eventually, I dug up a copy of some more recent Vista x64 drivers (release 97.46) which were a bit more stable (unfortunately, I had to go manually install the drivers as the inf didn’t properly list my card as supported). That little bit of unpleasantness aside, the Vista x64 experience has been pretty good so far. World of Warcraft and Neverwinter Nights 2 run fine under Wow64, and all of the usual development tools (VS2005 and friends) work as well, though I had prior experience getting VS2005 working under Windows Server 2003 x64.

The only piece of hardware that I’m still not sure about on the new laptop is the ExpressCard slot (which might be what the Ricoh 1180:0843 device that I haven’t been able to identify is). I don’t see this as an immediate problem, however; the only generally available ExpressCards that I have seen thus far are EVDO/EDGE/HSDPA modems, and as Bluetooth works out of the box, I can get EVDO/1x modem capability just fine using my cell phone instead of through a dedicated ExpressCard modem.

While there have been a couple of rough edges (having to manually override PnP for installing new video card drivers, and a couple of installers that were confused about the difference between c:\windows\system32 and c:\windows\syswow64), it seems that native x64 Windows support on real hardware (as opposed to just running in VMs) has come a long way recently. If you are thinking about trying x64 Windows outside of a VM, though, I would try to make sure that you have relatively recent hardware. Since you won’t be able to rely on backwards compatibility with old 32-bit drivers released that may have been released many years ago, any hardware vendors that have provided you hardware will in general need to have been still actively supporting that hardware relatively recently for there to be a shot at it having x64 drivers.

All in all, things look good so far with the new hardware (and running everything under x64). I’ll post back with any showstoppers I encounter with doing x64 full-time, but things are looking well thus far.

There was a small DNS glitch affecting access to the site which was resolved yesterday – sorry about that.

Alex Ionescu of TinyKRNL and ReactOS has put up his blog. I’d encourage you to check it out; I’m certain that he’ll have plenty of interesting and worthwhile content up there given his background.

Some of the things I’m planning on covering some time soon are:

• Finish off the Win32 calling conventions series.
• Continue the series about how the object namespace intersects with the Win32 API a bit further (Terminal Server session isolation, logon session isolation for mapped drives, etc).
• Describe some of the common optimizer tricks that you might see when reverse engineering something (x86 assembler). For example, multiplication tricks with lea and that sort of thing.
• Overview of how to use kernrate (the Microsoft profiler utility) to track down processor usage / performance problems.
• Care and feeding of inline assembler on x86 (when to use it and when not to use it).
• SEH on x86 (maybe)
• A basic discussion on kernel debugging at some point in time…

I’m also working on organizing some of the post series into an easily accessible directory for quicker reference (note that some of the links in the Post Directory may not yet be active).

Let me know if there are any other topics that you might be interested in hearing about and I’ll see about posting about them at some point.