[esm@logic.net ~]$ _

It's a political scandal, caught on tape. Thanks to Digg for the link.

Yeah, that's right. You've been Barack Roll'd.

During a discussion on EvoM about organizing the community's work on modifying the Mitsubishi Lancer Evolution ECU, I threw out the suggestion of a wiki. Since no good deed goes unpunished, I ended up setting up a quick MediaWiki instance, and various folks have been working like crazy to move some of the best information in the EcuFlash forum on EvoM to the new wiki. The URL, at least for now, is evoecu.logic.net, but if this looks like it'll take off, there's no reason it should be tied to my domain, so I'll probably register something specific for it.

It's nice being able to give something back to a community like this; I haven't been doing much disassembly lately, but hosting, I can do. :-)

So, it's been a while since I did any actual writing of code, other that the occasional hack related to the ECU in my Evo, when a friend of mine told me about a pre-interview programming task he'd been given: implement Tic-Tac-Toe, with a computer opponent that never loses (or results in a draw, in the worst-case scenario). Since we never really did anything like that back in my data structures and algorithms course in university (we focused mainly on more mundane applications; game theory never really came up, unfortunately), I took a quick stab at it in Python, using Negamax (with alpha-beta pruning to speed it up). I tossed a few other "dumb" player implementations in for good measure while I was testing.

No, this isn't exactly complicated stuff, but it definitely falls under the heading of good practice, something I haven't done enough of lately. I think I'll polish this up a bit more (I'd at least like to get a few basic tests added for completeness, and write a slightly more useful __main__); maybe throw a wxPython front-end on it since I've been spending so much time with that on the Evo stuff anyway.

Why do I still tend to prefer Python, despite the fact that I see value in and actively use the new hotness? Well, this might give you an idea.

(For the curious, that's Camping, a microframework from _why. Yes, I know it looks like that because _why is insane. And yes, I know there's an unabridged version with documentation. The fact that the abridged nightmare is even possible frightens me. ;-)

If you're reading this, you're reading my blog as hosted on Slicehost. This is the first step of getting my websites and other infrastructure out of the spare bedroom of my home, and onto somewhat more stable hosting.

Read more...

Well, it took a bit longer than expected, but I've migrated this blog from Pyblosxom to Django. More technical details after the jump.

Read more...

I've been using PyBlosxom for the last few years for my online presence here, and while it certainly does the job, I have a habit of getting bored with stuff that works after a while. So, I'm in the process of whipping up my own blog using Django, because hey, web frameworks are the new red. Or something. :-)

Actually, real reason is that PyBlosxom is category-centric; there's no real inherent understanding of a post having multiple categories (perhaps tagging/multi-category functionality is there in a newer version, but upgrading has always been difficult because of a few changes I've made). I found most posts I made ended up touching on multiple categories; racing and geek stuff often overlap, for example. So, lacking native tagging of articles, and not wanting to mess with some of the tag add-ons I've seen for PyBlosxom, I figured I'd just write my own.

What's interesting about this move is that the most recent framework I have experience with is Rails, so it's been interesting to see a Pythonista spin on the idea. What's funny is that, from a functionality perspective, they're really quite similar. Scaffolding, database interaction, view and administration generation are all disquietingly similar. Except, you know, that Ruby vs. Python thing. ;-)

As expected, the basic blog application was a snap. I've been spending most of my time on "fit and finish"; putting together template tags for displaying the sidebar calendar, working out a quickie scheme for importing all the old data, and adapting my current "static" content to the flatpages contrib framework. I'm also trying to make sure I don't break the old URLs too badly.

Once I have most of what PyBlosxom does for me today implemented, I'll probably just cut over at that point. Afterward, I'll concentrate more on some of the specialty stuff I'd like to pull in: timeslips, logs from the cars, dive logs, etc. Fun stuff. :-) And at some point, I'll throw the whole project into SVN so others can poke at it. (I might have to post up my calendar template tag on Django Snippets at the very least, since the only other one up there uses datetime instead of the new calendar module.)

This post is more for my own benefit than anyone else's; every time I fire up IDA Pro with a fresh ROM, I have to re-learn how exactly to get to a usable disassembled image.

Assuming you have an ECU image from your car saved as a .hex with EcuFlash, fire up IDA Pro (I'm currently using 5.0.0.879, so this might differ from version to version), and go to "File" and "Open...". Select the "Hitachi SH4B" processor from the drop-down, and just keep clicking OK until you're presented with the ROM view.

The first four bytes of the ROM tell the processor where to jump to when booting; so, type "g", and enter the address stored in those first four bytes and hit OK. Then, type "c", and watch as IDA Pro disassembles your code automatically in front of you.

After that, though, you're on your own. See AktiveMatrix for the latest in what people are doing with a disassembled Evo ECU, as well as the forums at OSEcu Roms and OpenECU.

Following on the heels of that great old-school DEC advertisement, I get another blast from my non-academic past at University: an interview with Richard Bartle, one of the creators of the original MUD that ran at Essex University back in the late 1970s and early 1980s. MUDs are the majority of the reason I'm doing what I do today (after a fashion), and were my first introduction to social computing and network programming. What's really interesting to me is that he's saying the same things that any of us who were involved in building these text-based online delusions in the 80s and 90s were constantly harping on about, and it all still applies even though the graphics have gotten better. (In fact, he makes the excellent point that with the improvement in visual stimulus, the ability to interact with the environment has actually gotten worse, because of the nature of ad-hoc natural language.)

It was a good read; I haven't played with these things in long time (aside from a brief flirtation with creating a Python-based runtime-mutable object environment similar to the facilities that LP-style MUDs had), so it was a nice walk down memory lane, and a reminder that there really isn't much new under the sun, just a prettier interface on it. :-)

This is mainly a note for myself, but someone else might find it handy. Working with modern initrds requires monkeying with cpio, which I can never remember the correct command line parameters for off the top of my head. So, here's a quick workflow (borrowed from Chip Shabazian) for manipulating an initrd image.

mkdir initrd
cd initrd
gzip -dc path/to/unzipped/initrd.img | cpio -id
# Make the changes you need
find . | cpio -c -o | gzip -9 > /path/to/new/initrd.img

Chip Shabazian's presentation at LinuxWorld

This is too cool for words:

God, I feel old.

I came across a del.icio.us link to this article on Coding Horror this morning, and it interested me on several levels.

First, there's the obvious: the article talks about the difficulty in locating programmer candidates that can perform basic programming assignments in an interview setting. Several commenters hit on some of the things that can contribute to this problem, including the psychology of an interview environment, the ability of the candidate to manage their stress, and the obvious problem that there's a lot of CS graduates who haven't spent enough time behind a keyboard to be useful in a production programming shop. That's what his article is about, and I'll leave that discussion there.

I'm much more interested in the response to the article. Responses range from senior developers to folks still in college or high school, and the resounding pattern is: they want to solve the problem. That's not what the author was shooting for, obviously, but readers were falling all over themselves (myself included) to post up the first response in their favorite language.

My speculation is that programmers who love what they do - the kind of folks who hang out on programming-related websites, who read the latest O'Reilly books when they come out, who participate in open source projects and "scratch itches" regularly - can't ignore an opportunity for practice, much like what Dave Thomas talked about when he introduced his idea of "Code Kata". Throw out the accusation that most programmers can't solve a simple problem, and you've practically demanded that they take a swipe at it.

There's more to it, though; lower the barrier enough, and more and more people get attracted to the idea. You see this kind of behavior on topical mailing lists: ask a complex question, and you may get an answer, but not a lot of people will jump up and offer their help. Ask an easier question, perhaps something that a lot of people know the answer to (or can easily derive the answer to), and suddenly, you get an overwhelming response. There's an aspect of ego at play here that's interesting; it's an opportunity to present yourself as a subject matter expert, or at least as someone knowledgable of issues surrounding the question.

Interesting stuff, to be sure. I suspect there's a good group dynamics case study or paper to be had here for someone with the time.

Let's say I have a data set in a SQLite database. And, let's say I need to iterate over every row in that database, performing some action based on it. There's a few ways I can do this. First, the old, direct-to-driver version:

require 'sqlite3'

db = SQLite3::Database.new("test.db")
db.execute("select * from test_entries") do |row|
  ...
end

SQLite example

That works, but of course, it's bound forever to SQLite, and we'd like to abstract that a bit. The "new hotness" appears to be ActiveRecord. So, let's reproduce that using AR:

require 'active_record'

class TestEntry < ActiveRecord::Base; end

ActiveRecord::Base.establish_connection({
  :adapter => 'sqlite3', :dbfile => 'test.db'
})

TestEntry.find(:all) do |entry|
  ...
end

ActiveRecord example

Here's a tip: don't do that. ;-) That find call actually instantiates an ActiveRecord::Base for every single row in the database, then returns the result set, which you're now iterating over. So, for anything but a trivially-small result set, you're going to use a ton of memory, and create an enormous workload for very little good reason.

So, I suppose this blog entry is really just a whine: why isn't there a lazy-instantiation iterator for result sets in ActiveRecord? In this (common, I'd think) case where you want to do some sort of trivial filter or action across the entire table on a per-row basis, but don't care about the row after you've worked with it, that would be a huge win. The interesting thing is that this is exactly how the auto-generated association methods work, and you actually have to go out of your way to do eager loading of associations (since just automatically doing joins under the hood is an obviously bad idea).

My specific use case is an application log stored in a table that I'd like to iterate over for some basic statistical analysis, and a single day of logs is a 600M SQLite database (approximately 3.6M rows). This won't fly for doing a single day of processing, and I'd like to be able to do something for monthly and quarterly reporting.

I'll probably resort to DBI to accomplish this in a database-agnostic manner, but that feels like an incredible step backwards. I just can't understand why the find* methods weren't written as iterators that do lazy instantiation of the result set; the interface would be effectively the same, but the potential performance gains could be tremendous in certain cases.

So, you bought one of those shiny new Penguin Computing BladeRunner systems, and were thinking to yourself: "I wish there were a good guide to getting Linux to do what it should on these things". Well, I'm going to try and cover two of the basics here: serial console configuration, and interface bonding. Everything else is pretty much stock stuff, but I had a heck of a time figuring out configurations that worked here. The discussion below assumes you're running RHEL or Fedora, but the idea should be fairly clear.

First step: learn about some of the remote management features of the BladeRunner. You have a couple of configuration commands that are useful here, related to console management and power. Log into the chassis, and type conf; for some reason, they put this under "configuration" rather than "management" or some other similar tree of the command set. Now, you can control power to individual blades with server-blade power <num> [cycle|forced-off|off|on] (where <num> is the number of the blade you're managing). on means exactly what it sounds like; power on the blade if it's currently off, just like it would if you hit the power button on the front. off sends an ACPI power vevent to the blade, advising it to shut down; it doesn't actually force power to be pulled; that's what forced-off does. cycle removes power to the blade, and adds it again; off the top of my head, I don't recall if it does so gracefully or not. Check the documentation, it might be there (but probably not).

The next command that's interesting here is server-blade console-redirect <num>: that grabs the serial console for that particular blade, and displays it to your current session. The serial console configuration appears to be set in stone, from what I can see: 57600 bps, 8 data bits, no parity, 1 stop bit, with hardware (RTS/CTS) flow control. If you power up a blade fresh from the factory, you'll notice that the BIOS is already set up to redirect output to both the serial port and the built-in KVM in the chassis.

That's about all I'll say about the chassis management side of things, since they actually do cover this stuff fairly well in the documentation. The problem I found with the documentation was that it didn't cover host-side configuration of certain things, specifically interface bonding and serial console configuration. Maybe they thought it was out-of-scope for their documentation; I hate to be the bearer of bad news, but the chassis is pretty useless without systems to run on it. ;-) (Here endeth the snide remarks, hopefully.)

Next up is host-side serial console configuration. This is fairly standard stuff, once you know what the settings need to be, but I'll spell it out here too. First is the bootloader; GRUB, in my case. You'll want to add a couple of lines to the GRUB configuration file (in the main stanza):

  serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1
  terminal --timeout=10 serial console

Optionally, you can also add hiddenmenu to the options; that reduces the amount of text being displayed at boot time to a minumum, unless you need it. Set the timeout on the terminal line to whatever is appropriate for you; 10 seconds before you're kicked to the primary display was good enough for my needs, since I didn't want the boot process to take much longer than it already did.

Next up, also in the grub configuration file (on the command line of each kernel you want to boot), are the kernel parameters that get your boot output sent to the right place. Adding console=tty0 console=ttyS0,57600n8r to the kernel command line seemed to do the job for me (display on /dev/ttyS0 at 57000 bps, no parity, 8 data bits, hardware flow control). If this is a stock Red Hat/Fedora installation, I suggest getting rid of the rhgb and quiet entries on that line as well; for server use, you really want to see that console output, so that when you inevitably get a kernel that has a bad day, you don't have to monkey with grub configuration via a 57600bps serial line to capture the panic.

The final step is making it possible to log in on the console. Adding the following line to /etc/inittab worked great for my needs:

  co:2345:respawn:/sbin/agetty -h ttyS0 57600 vt100

The co is an name for the entry, but it's become a defacto standard for the inittab name for the serial console entry. 2345 should be obvious (runlevels to operate in), respawn means run it again after you log out, not just once. The agetty command line just specifies hardware flow control (-h), linux device (ttyS0), speed (57600), and terminal type (vt100); change terminal type to anything appropriate for your environment, but vt100 is pretty safe for most folks.

That covers serial console configuration. For more details on that piece of the puzzle, I strongly recommend reading over the Remote Serial Console HOWTO; it discusses some of the ins-and-outs of other boot loaders, some other configurations you might be interested in trying, and some general advice for this kind of setup.

Next up is interface bonding; every blade has two Broadcom NetXtreme BCM5780S Gigabit Ethernet NICs built in, each connected to one of the two management blades through an internal backplane. I've been using the tg3 drivers for these quite successfully; the bcm5820 module is also available as a third-party add-on, but appears to be deprecated at this point. So, your /etc/modules.conf or /etc/modprobe.conf (depending on version) will likely have a couple of lines in it like alias eth0 tg3 for each interface. Next up is bonding configuration: add the following lines:

  alias bond0 bonding
  options bonding mode=2 arp_interval=500 arp_ip_target=10.0.0.1

Change 10.0.0.1 to whatever your default gateway is. You might be asking yourself why you shouldn't use MII instead of ARP on these systems, and it's a good question. The failure mode of the chassis internal network precludes it; you can end up with one management switch down, but the MII status of the ethernet interface still shows it being up. You can test this out by setting your bonding configuration to use MII instead, then yanking out one of the chassis management blades.

The next piece is very specific to RHEL or Fedora; please refer to your Linux vendor's documentation for details on how to do it elsewhere. In /etc/sysconfig/network-scripts, create a file called ifcfg-bond0 that looks exactly like a normal ifcfg-* file (in fact, you might want to just move your existing ifcfg-eth0 or similar file there); specify how you want this combined interface to behave. Then, for each of ifcfg-eth0 and ifcfg-eth1, add a file that looks like:

  DEVICE=eth0
  TYPE=Ethernet
  BOOTPROTO=none
  ONBOOT=yes
  MASTER=bond0
  SLAVE=yes

(Change DEVICE= to the appropriate line for each device.) More information on interface bonding under linux is available from the OSDL Linux networking site.

That's the main stuff. Obviously, test all of these changes with a complete boot to make sure console redirection is happening the way you want it, and to be sure that your bonded interfaces are showing up as a single bond0 interface (and that you have connectivity to and from them). Good luck. :-)

Have you hugged your systems administrator lately? ;-)

I've been doing UNIX administration for quite a few years now, and I know a few other people who would call this their profession. I've been noticing, though, a rather drastic difference in attitude toward systems and users in some of them, and I think I've finally nailed down where that difference might be coming from. Fair warning: as usual, this is written basically as a stream-of-consciousness kind of thing, so I may or may not actually get to the point.

You have a few different priorities as a systems administrator, and your job is to juggle them using your best judgement (weighing business needs, available resources, personal time, etc). One of these priorities is production support; keeping the systems that run your business online and performing whatever task it is that they are supposed to be doing (in the case of an Internet-facing business, for instance, this could mean keeping the web, app, mail, and other servers running; for a development shop, it could mean keeping the build systems working smoothly). Inevitably, though, there is another audience that systems administrators are asked to deal with: users. In some cases, that means developers; in others, it means the sales team. In either case, as a technical lead, your job is to help them get their job done. Some administrators get lucky: they only have to deal with one environment or the other. In most shops, however, the administrative staff shares responsibilities. This sounds fine, until you consider the psychology of the two situations.

Production support generally involves saying no a lot. Change is bad; slow, methodical improvements are fine over time, but radical departures from what is known to work are frowned upon. Taken to the logical extreme, you end up with a heavy-weight change control process where even small system changes are scrutinized heavily. And to those who hate such things (and I'm right there with you), this is a good thing. Production systems are differentiated from others by the fact that the business lives and dies by them functioning correctly. By extension, things that effect those systems ought to be tightly controlled and monitored.

But development (or, in some environments, user) systems are a completely different thing. Joel Spolsky has talked about this kind of thing at length: the systems are a tool to help the users do useful work. If a development group needs a machine or two for testing, then find a couple somewhere. If a user needs access to the Internet to research a sales pitch they're working on, give it to them. This doesn't mean giving them everything they ask for; this means finding out what they need to do their jobs, and working toward that in a collaborative manner. The systems administrator provides the role of technology expert and facilitator in this arena.

Take someone who has done production support for years, and give them a development group to support, and Bad Things Happen. The admin can't understand why on earth they want to do things like arbitrarily shuffle 50GB files around the network, use various outdated tools that only support older insecure protocols, or talk on IRC or an instant messenger with people outside the company. They lack perspective: they don't see how that style of systems management affects real people trying to get their job done.

I won't even get into the mess that can happen if you try the reverse (a development-only systems administrator in a production role).

I'm finding that there are very few administrators who can successfully balance both mindsets. As geeks, we seek out uniformity because it regularizes our workloads, but you simply can't reconcile the two: to be successful at both, you have to treat both as the unique environments that they are. I've talked before about administrative geeks needing to step beyond their job title, and this is part of it: working with a mindset of "value to company" rather than the micro-view of what you happen to be doing today.

Anyone can say "no" all the time.

I had a good reminder today of what Erik Naggum was talking about when speaking with a co-worker. He was trying to come up with a "good" solution to a Perl problem, so I had him describe it to me. It turns out that he has an object, which may or may not contain the attribute he's looking for. If it doesn't have it, the object has an attribute referring to another object. This other object, in turn, may or may not have the attribute he's looking for, and also has a reference to another object; this repeats until the "next object" is null.

Astute readers will have recognized this as a basic linked list.

I figure, okay, he hasn't been programming in a long time, so we'll mentally walk him through it. First, a quick nudge to see if he can remember his basic CS from a long time ago: "Why don't you write something that will just recurse through that list?" He nods, but the eyes, they don't have it. He goes away to think about it for a while, and then we wind up on a conference call in a meeting room. While the person we're calling is talking, he's quickly jotting down on the board:

  O -> O -> O -> ...

I think, okay, he has the mental idea now, because he's diagramming it correctly. We talk a bit more, and he's obviously trying to come up with a way to iterate over the list. Once again, I suggest a simple recursive function (because that's natural to me, goddamnit, I don't care what you iterative programmers say), and quickly psuedocode something up for him:

  function blah(o)
    if !o:
      return null
    if o->whatImLookingFor:
      return o->whatImLookingFor
    return blah(o->nextObject)

  found = blah(myList)

He looks at it, and appears puzzled. This appears to be a new construct to him, and he asks a few questions that confirm this. "But it'll just keep calling itself and looking at the same object all the time, won't it?" My first psuedocode example unfortunately used similar variable names in both the "mainline" and the function itself, but after renaming things, he still didn't seem to understand. Ah! Local vs. global scoping rules, maybe? So I suggest that, in Perl, you'd have something like my ($o) = @_; as the first line of that function. He still doesn't get it, and grunts something about just dumping the objects and grepping for what he's looking for. He just couldn't make himself look at the "CS" solution, because it didn't fit what he was expecting from Perl: a quick hack that did what he wanted without having to think too hard about it.

Systems administrators who spend to much time with "qwiky" languages like Perl are doomed to forget everything they ever knew about Computer Science. I'm convinced of this now. You might think I had this conversation with a newbie programmer or someone who whipped up scripts now and then, but you'd be wrong; this is a fellow who did software development professionally, and moved into systems administration later in his career. He's no idiot.

(I liken the problem to "l337 sp33k". I've known colleagues who could carry on a perfectly professional conversation face-to-face, but the moment they sit down at a keyboard, they immediately regress to "OMG r u 4 r34l?!" and, setting aside perceptions, they actually behave dumber while doing this. Perl has a similar effect on programmers; in the end, you end up with something that's a tangled web of spaghetti code and system() calls, getting the job done but disgusting anyone who has to look at it. Sort of like reading, "omg u pwn3d that bug, yo!". I wonder when someone will spec a programming language called "l337"...nevermind, Google to the rescue. Ye ghods.)

Postscript: yeah, I probably should have given him an iterative version of the pseudocode. Something like this:

  function blah(o):
    while o:
      if o->whatImLookingFor:
        return o->whatImLookingFor
      o = o->nextObject
    return null

Just as simple, conceptually. Maybe some people have trouble wrapping their heads around recursion, but it's always seemed like a very straightforward idea to me.

Go away. :-) The funny thing? I'd use IMolatr.

Code Monkey think maybe manager want to write goddamn login page himself.

Pure geeky comic gold from Jonathan Coulton's "thing-a-week". :-)

If you can read this (and in some parts of the 'net, you probably can't), then you're reading it through our new network connection via Comcast. After a pretty nasty false start over the weekend, and the cutoff date for Dataflo coming up this weekend, I bit the bullet and cut things over this morning. DNS was set up such that NS records were available for both address assignments for a while now, as well as MX records pointing at both address pools, so the only thing that's really off the air right now in some places is the webserver, and that'll just have to wait. I also managed to break my backup MX along the way, so I'll need to poke at that a bit more and see what I fat-fingered.

Bah. I like renumbering about as much as I like moving.

So, some initial observations: latency is a touch higher than it was with Dataflo, surprisingly enough. First hop averages went from 2-3 ms on the old wireless link to 8-10 ms (with occasional spikes) on Comcast. On the other hand, I'm now seeing download rates around 6Mbps (vs. 1.5Mbps), which is a nice change of pace. :-) Downstream speed is 768kbps now (vs. 1.5Mbps through Dataflo), which may prove to be a problem, but we'll see how it goes for now.

The biggest negative observation I've made so far is Comcast's complete lack of business-oriented customer service; they're obviously incredibly used to dealing with residential customers, and they've used that same contracted-out infrastructure to deal with their commercial customers as well. Phone support is excellent (when you finally get to them; getting a rep on the phone requires navigating about 10 levels of phone menus), but getting physical on-site service is a multi-day waiting game, with the typical "we'll be there sometime between 8:00 AM and 8:00 PM" kind of scheduling that you've come to expect from their residential service. There is no email interface to the helpdesk whatsoever; any kind of technical support inquiry MUST be made by phone, which is incredibly annoying when wanting to do something complicated with DNS. So far, I'm not impressed, but if I never have to deal with their customer service (much like when I was with Speakeasy, who rarely saw an unannounced service outage), then it won't matter to me. We'll see.

So, the day after I post a blog entry about being forced to switch to Comcast because of the lackluster service I've received with Dataflo, I have another rather significant service outage. There appeared to be problems last night, although I was having a hard time pinning the issue on Dataflo then. However, they definitely made a mid-day routing change today; at 12:34, all of a sudden, my backup MX starts receiving email for everything (the backup MX, in this case, is my router, which usually sees nothing but spam all day), and traceroutes to the static IP block they've assigned me are dropped on the floor the moment Cogent hands off to Dataflo.

Again.

It's not like I'm asking for a lot here. I need a service that stays up, and I'm paying a premium for that. That premium ought to include at least a bit of special attention to making sure the services provided to me are working when a major change is made, and perhaps major changes shouldn't be done in the middle of the workday, in the middle of the week, without any prior notification to the customer base of a potential outage. Screw the SLA; I shouldn't need an SLA to hold over their heads. What I really need is a service that stays up, with planned maintenance windows and some degree of customer notification.

I have no idea why I think Comcast will be any better, but at least they're half the price (actually, a third of the price, if you consider what my renewal contract pricing stated). In the event I get lousy service, at least I won't be crying about the money I'm wasting.

Ugh. I finally bit the bullet, and had Comcast "Workplace" service installed to replace the flakey fixed-point wireless service I've been fighting with for the past two years. To be fair, I should qualify that: my "last mile" link (between my rooftop transmitter and the tower) has been rock solid. The problem has always been mid-day routing and configuration changes on the part of the provider, which have knocked me offline anywhere from a few minutes now and then, to one incident that had me offline for the better part of a day. At this price and service level, that's completely unacceptable. So, since I can't get service from my preferred vendor here due to a complete lack of DSL availability in my area, I'm stuck with the local cable company: Comcast.

So, first impressions (note that I haven't moved ANY services to this yet, until I get a feel for how this will work): 6Mbps download speeds are unbelievably fun. :-) The 768kbps upload speed may end up being a bit of a hindrance; most of my traffic is SMTP, but I do receive a fair bit of HTTP traffic too, and that's where that upload bottleneck is going to suck (specifically, both I and Erica maintain pretty large photo galleries that seem to get a bit of traffic, and I'll often host larger items for people for limited times). But, we'll have no idea how that'll go until I bite the bullet and cut stuff over; I'm hoping I can run fairly well off of both links for a while, with plenty of time for DNS updates to propagate.

Ugh. I remember how much I hate renumbering now.

My initial impressions: more solid than I thought this release was going to be, given how much has changed. My biggest complaint so far: they upgraded OpenSSL to a new major version without providing a compat release for those of us upgrading. All we needed was an equivilent to the already-existing openssl097a package, which does nothing but package up libssl.so.5 and libcrypto.so.5, and upgrading would have been smooth as silk for me on one machine. Instead, I'm stuck rebuilding packages that I should have been able to leave alone until later. Bah.

More later when I've had a little more time to play with it. Playing with it on a desktop machine is proving difficult, as the only "play" machine I have right now running Fedora Core hangs the console whenever I fire up X. (Not too surprising, that machine is a bit of a hodgepodge of hardware.)

The action with the WRX was captured beautifully with my new toy: a Treo 650. It's a combination PDA and cellular phone that runs PalmOS, and with the data service I picked up with the package, the built-in web browser and email client are actually proving to be fairly handy. Definitely a big step up from the BlackBerry I had while I was at my previous job; the screen and form factor are a huge leap forward, and having a camera built-in (albeit pretty crappy) is a cute gimmicky toy. Battery life is at least as good too (actually, it looks like it's going to be quite a bit better; I should get two or three days out of a charge with my normal usage, which is pretty excessive compared to an average user). Phone and data service coverage with Sprint seems to be pretty good so far, and the data service is a LOT faster than the Nextel service I had the BlackBerry connected to. The SD media slot means this thing can also serve as a portable MP3/OGG/media player too; 2G of audio storage ain't bad. I can bolt the thing up to my desktop via bluetooth and infrared as well, which means one less cable to muck with. I'm pretty happy with it so far. :-)

So, in my new role, I'll be responsible for the shared administration of a rather large Gentoo deployment. So, in the spirit of eating your own dogfood, I'm loading my new company-issued laptop with Gentoo Linux.

First impression: I feel like I'm back in 1994. Really. Oh, the package management is generally pretty cooked; in fact, I'm really quite impressed with how they're handling a generally nebulous thing (from-source package generation) in a pretty consistant manner. I'm trying to imagine building Fedora from source RPMs, and the idea gives me the willies; they have the build dependancies handled pretty well. No, my problem is the same problem I have with Debian: choice is good, but too much choice is a PITA. You can infer from this that I disagree with the Perl axiom of "more than one way to do it"; all that means is that the language (or in this case, distribution) maintainer didn't have the intestinal fortitude to make a decision, and left the problem of bikeshed arguments to the users. It's actually worse than that: on their own, a lot of the little variances don't matter, but get enough of them together, and you have a maintenance nightmare.

This problem is compounded by the community belief that customization at all levels (specifically at the buildchain level) is a good thing. At the end of the day, you have a distribution where you are truly on your own from a support perspective in many cases. Not a big deal for an operating system targetting hackers and tweakers (in fact, I'll probably have a ball with it on my laptop), but when I put my management hat on, the idea of using this in production frightens me; you're essentially locking yourself into using senior-level talent to manage your infrastructure, and hiring junior talent that can grow into the position starts becoming less and less attractive. Not bad for me, but bad for the bottom line.

I expect I'm expounding on arguments that have been had over and over in the Gentoo community over the years, so this is more of a first-impression kind of vent. I'll skip on discussing the apparent lack of development and "stable" tracks for general deployment, and a few other similar things I've noticed missing from the "process" around the distribution, because they're all fundamentally part of the same issue: the Gentoo community appears to strongly appeal to the hacker/tweaker, which defines the community's behavior from a packaging and ongoing maintenance perspective.

So, Slackware for smarter people. :-)

After being so happy about getting the framerate up a bit last night, I decided to finally get around to updating the BIOS to the last version issued by ECS (it's a K7VZA v1.0 motherboard, if anyone's curious). Seeing as it's been out since 2000, I figured, "What could possibly go wrong?"

I ended up with a brick.

Enter the Willem EPROM burner I bought a few months back for flashing ECU chips for Erica's Laser. I finally set up a machine for doing nothing but burner duty, and pulled the image off the chip. As suspected, it was corrupt, so I tried writing the image out again with the burner...no dice, it would fail after a random number of sectors. After a LOT of searching, I turned up a bit of information: first, BIOS chips (in this case, an ASD AE29F2008) seem to have a defence mechanism against just blatting a new image onto them, and you need to disable this before you can write your image (which is the real "magic" of the flash update software that motherboard manufacturers issue you). Second, version 0.97ja of the Willem software (the most recent version available) can't actually disable it; you have to backdate your version to 0.97g. Tried out the older version, clicked the button that magically appeared to disable software protection, and viola: the image burned perfectly.

Shouting triumphantly (and waking Erica up, doh!), I rushed downstairs with my freshly flashed BIOS, plugged it in, powered the machine back up, and...BEEEEEEEEEEEP*crackle*. Same thing, just powered down. Dammit. Okay, back upstairs, downloaded and burned the older version that we were running before, ran back down, plugged it in, powered it up, and all was well again. I have no idea why the new image isn't working, but I'm perfectly happy with the BIOS revision I have now, thankyouverymuch. :-)

I also took a second to slap another 30GB drive I had lying around into it for my ogg collection and various other multimedia goodies for sharing with the rest of the machines here. A quick fdisk and pvcreate /dev/hdd1 (etc), and I think I'm about ready to call it a night.

So, on the upside, I now have a decent station to burn chips at; this eliminates the last of my reasons for waffling on getting a new chip made for the Laser, so I'll probably play with that next.

I never thought I'd be happy to see 114 frames per second out of glxgears, but that's double what I was getting before, so I claim success. I suspect if I cranked the resolution down from 1600x1200 to something a little smaller, or dropped the color depth down to 16bpp, I'd get a little better performance, but frankly, I'm not really willing to sacrifice either. Call me spoiled. ;-)

For the curious: lspci identifies my card as a Radeon RV100 QY (Radeon 7000/VE), which is apparently some bastard child of the Radeon 7000 lineup that has a bad time with DRI. It also has the fact that it's a PCI card working against it, but hey, at least it's got 128MB of painfully-slow-to-access video memory onboard. :-) Two initial problems cropped up: first, I had an MTRR conflict which required manual intervention to clear up (I found a thread over at Rage3D.com that put me onto a solution for that), and second, DRI is disabled on the Fedora build of Xorg, and needs to be explicitly re-enabled for the Radeon 7000/VE (add Options "DRI" to the Device section of xorg.conf). Basic desktop behavior is a bit quicker now, and video playback is actually doable now, so it's a good place to stop for the night, but this is truly terrible performance compared to what I was expecting.

The musical and martial arts worlds have a history long enough to learn something from when thinking about new (which is a relative term, of course) fields of study. Something they both got right was the idea of "practice"; repetition of basic tasks so as to both reinforce the basics, and to prevent the student from "practicing" on the job (how embarassing to deliver that B as a b flat during your on-stage solo).

Let's apply that to the IT world. If you're a programmer, when is the last time you sat down and worked through some of the basics in your current development tool of choice? Written a b-tree implementation from scratch lately, complete with sorting and searching? How about just a basic list or queue? If you're a systems administrator, when is the last time you tried working through a simulated emergency, so that you're better prepared for the next fire you have to put out on the job? How quickly could you get the company's website back up if the database server needed a major component replacement? How about if that component was the complete disk array?

I wish this was my idea, of course, but I'm really just re-telling an excellent concept from Dave Thomas, one of the fellows who wrote The Pragmatic Programmer (I talked about it a long time ago over on Advogato back when I originally read it; if you haven't ever picked it up, I highly recommend it). He coined the term Code Kata in a bow to the Japanese concept of 型 (Kata) in the martial arts. Literally "form", it could more practically be called "practice"; most forms of martial arts have a series of pre-determined forms, or Kata, that the student memorizes and exercises until they can be performed essentially from muscle memory.

Similarly, Dave Thomas suggests 21 Code Kata for programmers to tackle during the practice sessions he thinks we're all missing out on. I've had a rudimentary form of this that I've tackled over time, but that was targetted mainly at the acquisition of new skills, not at practicing existing skills. So, I decided to start working on at least a few of these as time permits; having just started, it's amazing the amount of knowledge from back in my university days is still there (and how much trouble I seem to be having recovering it ;-)).

Practice is good.

I read an excellent essay recently which discussed the fallacy that outsourcing programmers was akin to outsourcing manufacturing capabilities; he convincingly makes the argument that programming, unlike manufacturing, is an iterative design process. Just like you'd never see a major automotive manufacturer outsource it's design team, because design is their core competancy, outsourcing your programming talent (assuming software is your business) would similarly cripple your competitive advantage. His discussion got me thinking about my own chosen profession (systems administration, in case anyone reading this in the past might have mistaken me for one of those hippy geek programmers ;-)). Does his argument apply to systems administration and management, or do we have a job function that could be done from an operations manual?

Systems administration consists of a number of well-defined roles, combined with a lot of day-to-day vagueness. The well-defined stuff is obvious:

• Keep the hardware running, and schedule fix/replace work as neccesary.
• Monitor operating system and hardware resource usage, and notify application owners/schedule upgrades as necessary.
• Schedule operating system (and application, if that's in your job description too) patching and regular maintenance.
• Keep up-to-date with the current "state of the art" in systems administration "best practices" and software/hardware revisions.

I could go on a bit longer, but you get the idea. Keep things running, schedule stuff that helps keep it running, and fix stuff when it breaks. Simple, right? So outsourcing sounds, at this point, like it's a good idea. Bring it on: remote facilities and eyes-and-hands services cover 90% of that, and consulting resources can probably manage the remaining work, right?

This is where I bring up that second part of the job: the day-to-day vagueness. It includes things like:

• Help a windows developer become acclimated to programming on UNIX (or, alternatively, commisserate with the poor UNIX programmer forced to write in VBScript all day long). Explain select() to someone whose most complicated previous program has been an interface mockup in MS Access.
• Help project management understand why the great idea they had for streamlining their project plan will actually extend the deadline, because it doesn't take into account an implementation detail that they didn't know about, such as growing SAN capacity or adding switches.
• Serve as a liason between the technology staff and management. Explain that their carefully crafted budget from last year was exceeded by 150%, not because of "out of control geeks", but because management didn't actually ask the geeks how much their projects would cost.
• Write code, because automation gives you more time to write blog entries about how you're automating yourself out of a job.
• Convince a vendor that, yes Virginia, there really is a bug in your product. Provide truss/strace/etc. output as necessary. Step through it with a debugger if you have to, or supply the line number of the "encrypted" perl code they supplied you with that contains the bug.
• Figure out why a particular vendor-supplied operating system patch didn't apply to one machine out of fifty, in fifteen minutes, because that's how long your maintenance window is. Roll back all fifty machines if you can't figure it out.
• Sit in every meeting for a particular project, not because you have anything to contribute to any of them, but because of that one meeting where someone will suggest something utterly impossible, from a technical perspective, and you need to be there to save yourself and your team from the job of making it happen.

I could go on forever with this part. The primary role of a System Administrator, in my mind, is not to do the day-to-day technical work; management is right, all of that can be outsourced. What they can't outsource is the role of someone you can turn to and ask "does this make sense, technically?" Just like automotive design will never be outsourced, systems and network design can't be outsourced without terrible consequences. Envision a case of a large company who has outsourced all of their administrative talent. Who is making the design decisions for the network? Do you outsource that, or does management take on the role? If you outsource it, who represents the designers in new deployments? Who do you turn to when you have questions about how one system interacts with another? How do you fill in gaps in your staff's technical knowledge without technical leaders to turn to?

Make no mistake, though: this argument demands that systems administrators grow into technical leaders. We need to be architects, designers, mentors, programmers, project managers, janitors, and free-thinkers; we need to have a breadth of expertise that a specialist simply cannot bring to the table. Someone who wants to take a class and be "certified" as a "Linux Guru" doesn't have much of a future in this business (or at least, not at this pay grade) because that role can be handed off to anyone who can read an operations manual. Want to keep your fat paycheck? Recognize the areas that can't be outsourced, and excel at them. If there's a "Learn X in 24 Hours" book, it's a pretty good bet that X isn't what you should be exclusively concentrating on.

I started writing this not sure where I'd end up at the end; I half-expected to end up making the argument that I'm not necessary, but that would only be half-right. Only those of us who can't provide technical leadership and handle the "undefinables" of the job are unnecessary. I, for one, welcome the thinning of the herd. :-)

Postscript: I wrote this in a coffee shop waiting for a job interview today. I'm writing this addendum on the train ride home afterward, after finding out that I was actually being interviewed for two positions: a "pure" system administration role, where everything is clearly operationally defined and the team has clear goals and deadlines to work in, or a position which was defined as "we do the stuff that falls through the cracks" by one of the senior administrators on the team. I don't think the recruiter had any idea why I had such a huge grin on my face when she told me that, and seemed surprised when I didn't have any difficulty saying which position I felt more attracted to.

I finally got around to setting up Trac for "managing" (if that's the right word) my software development. I don't have a lot ongoing right now, but all the old stuff I worked on has been languishing on my harddrive without any visibility. while some of it is personally pretty embarassing to admit to writing, it doesn't do any good to anyone collecting dust. So, have at it, if source code is your thing. It's bolted up to my Subversion respository (in regular and XML flavors), which you can also browse with ViewVC.

So, a few more random observations on DOM browser compatibility.

First, don't bother using element.setAttribute('class', 'someclass'). Oh, it looks fine in Firefox, but it won't do squat in Internet Explorer. Use element.className = 'someclass' instead, which seems to work in both browsers. (The problem I noticed, if someone catches this in a search, is that no errors were being raised anywhere, but the styles I specified in the stylesheet weren't being applied in IE. I have no idea if this problem applies to other element attributes. I found a reference to the solution at WebmasterWorld.)

Next, dynamically creating DOM objects in JavaScript is cool. ;-) By being able to yank the navigational aids out of the HTML source, browsers like Lynx and ELinks render with less useless fluff, and if you disable JavaScript in your browser, it "just works" (and looks basically correct).

Finally, I am amazed at how well Opera "just works". I didn't have to touch anything at all to make Opera render everything as I wanted; as far as I can tell, it behaved exactly like Firefox in most cases (specifically, it looks like they implemented the W3C DOM Events specification). Happiness.

So, an old friend of mine (one of the few people who actually reads this blog, methinks) dropped me an email to let me know that my wonderful new standards-compliant navel-gazing website wasn't as up-to-date as it should be: horror of horrors, I dared to use <blah onclick="javascript goodness"> all over the damn place, giving everything that oh-so-1999 feel. Okay Ben, here you go; both the sidebar hide/show functionality and the resume section expansion has been unceremoniously ripped from the HTML (along with the plethora of id="XXX" tags I had to sprinkle everywhere) and replaced with a gaggle of JavaScript borrowed from several places and a bunch of DOM manipulation.

May I point out, however, that getting the "new DOM way" working was a huge PITA? My first cut working with Firefox worked like a champ. Then I fired up Internet Explorer (why does firing up that web browser always mean I'm going to have a late nigh?), and was greeted by...nothing. A big, fat blank screen. WTF? I notice that if I comment out the call to the external JavaScript file, the page displays properly. Hmm. On a whim, I tried changing the reference from <script ... /> to <script ...></script> and viola, it works. You have got to be kidding me.

Then, we get into the mess that is addEventListener vs. attachEvent vs. document.eventname. That took a lot of straightening out; I eventually completely ditched the code that Ben originally suggested from Scott Andrew, and ended up using Andy Smith's very nice cross-browser event addition handler, using anonymous functions so that this works like it bloody well should. (Microsoft, are you listening? Of course you aren't, how silly of me. :-P). Andy's code has the additional benefit of handling nested event handlers in a very slick manner.

Finally, I had a problem with Firefox "bouncing" back to the top of the screen every time I'd click on one of my psuedo-links for expanding and collapsing a section. Easily solved by calling preventDefault() on the event object passed to the event handler, but once again, it's not supported by IE events (nor did IE do what, in retrospect, appears to be the right thing: fall through to the default event handler if mine doesn't explicitly say not to). So, that's all fixed up, and I appear to have, once again, a working cross-browser website (with substantially simpler HTML). Isn't standards-compliance fun? ;-)

As a side note, there's still a bit more to do; rather than mangling .innerHTML in my expand/collapse code, I should really just create a couple of objects that I can swap in and out there instead. But that will come tomorrow.

I'm making a note about this here mainly to refresh my own memory later, when I find myself needing to create a decrypted version of a PDF that I have the damn password for: pdftk is a handy little program which very neatly takes a password and PDF as input, and can produce an unencrypted version (with or without any of the permissions changed) as output. I can't believe I spent all night searching for something like this (and started looking at Ghostscript hackery as possible solutions) and never came across it. My Google-fu is weak. :-P

So, I apparently can't leave well enough alone. I rewrote most of the HTML that drives this website to use <div ...> sections and semi-proper semantic markup (where possible), and came up with a quickie stylesheet for the whole mess. The end result is actually something I'm fairly happy with; it still has some rough edges, but considering I'm finally calling it a night on this version at 2:45 AM, I think I can forgive a few minor problems. At least it validates as proper XHTML 1.0 and CSS, with no warnings, so I can sleep well knowing that it's standards-compliant, and renders pretty much the same in both Firefox and Internet Explorer, and appears to be readable in both Lynx and ELinks. I'll check on the Linux laptop tomorrow, which also has Opera installed.

As an aside, I'm loving Pyblosxom's "flavors" capability. It made building and testing a completely new website using the old content a breeze; just whip up a new set of flavor templates, and modify to your heart's content. In fact, the RSS feed that Pyblosxom generates is just another flavor. Spiffy stuff.

Not really, but it's pretty close. Maybe it's because I'm using Mono instead of someone's commercial product, but I'm really not happy with how the latest incarnation of my languages project is turning out. Granted, it's short: I'm at 158 lines right now, and could probably trim that a bit, although it'll grow as I add the last few needed commands (so far, the shortest complete implementation is the Ruby asynchronous version). The problem is that the C# version of "asynchronous file I/O" is completely different from what you'd expect coming from any of the other languages I've implemented this in (that actually provide a language-offered async handler): it uses threads. Not a terrible thing in and of itself, mind you (heck, a few of versions I wrote for this little hobby project are done using threads, specifically the old Java version before NIO became more generally available). It's just not exactly what I was expecting, and made a few things more complicated than they needed to be. It seems as though select() is considered evil in the Windows world for some reason. Okay, no problem, I'll implement it their way; that was, after all, the point of the exercise...to really learn the idioms of the platform.

Doesn't mean I actually like it all that much, though. I was actually surprised by going through this exercise; I'm still a big fan of Python after this, but Ruby really proved it's worth here, and I was utterly amazed at how easy the Tcl version ended up being to implement (hear that, Prof. Dueck? one of your old students actually liking Tcl! ;-)). I still hate Perl, but less so than before (I still think it looks like line noise when you're done writing something, though), and the PHP version still amuses the heck out of me. The Java version ended up way more complicated than it needed to be, but that's mainly because I wrote it before NIO; I've only started work on a version using java.nio, but I suspect it will turn out much shorter and far less complicated. And, at the end of it all, the C version is by far the most complicated of the bunch, due to the complete lack of modern libraries of code that can be relied upon, and having to reinvent the wheel everywhere. A good learning experience, all around.

So, I took the resume update one step farther, and borrowed/mangled/rewrote a few bits of JavaScript for my resume that make it possible to switch to "printable" mode with a link and an updated stylesheet, and for certain chunks of details to be expandable/collapsable. I eneded up settling on using <div class=...> everywhere for it, because while using an unoredered list would have been more semantically correct, I just couldn't get it working the way I wanted to across multiple browsers, while this solution both validates and loads in both Firefox and Internet Explorer.

(For the curious: what I was trying to do with unordered lists was have the actual HTML itself be exceedingly simple: just a bit of <ul ...><li>...</li></ul> with some class="..." markup here and there as necessary. The idea was to have a bit of JavaScript tweak list-style: ... to change out the URL for the expand/collapse graphic, and change the display: ... attribute on an associated child list. Then I realized that, semantically, using an unordered list wasn't quite right; what I wanted to really use was a definition list (since what I'm displaying is really a title, and an associated bit of text that I want to toggle the visibility of). A definition list doesn't support bullets, which meant I'd need to add additional markup that didn't really need to be there; so much for separation of style and content. At the end of the day, I decided to just fall back to my original, working version, rather than keep fighting with something that really didn't give me much more over the original. Thus endeth Ed's foray, again, into stylesheets and markup.) need to stick another

In a fit of disgust with my online resume (mainly because it was quickly falling behind the Word version that I've been mailing to recruiters), I gave it a pretty decent facelift; even the printable version is looking better, and almost good enough to actually print, thanks to some simple Javascript and a much better stylesheet. Now I just need to address the actual content; that "skills grid" seemed like a good idea at the time, but it's proving to be a huge PITA to keep up-to-date.

So, I finally got around to updating the software that drives this blog (Pyblosxom) to the latest release, and I'm surprised at how well it went, considering all the little hacks and tweaks I'd added to it over time. At this point, I'm running it on a pure vanilla version, with a few additional plugins and filters that I've written or borrowed, and it seems to be holding up nicely. And that damnable paging plugin is now set up to start at page 1 instead of page 0. ;-)

I've uncovered the secret to creating a rabidly addicting video game. It's really quite simple: start with a starving Japanese programmer, and convince him to come work for you with promises of mediocre pay and stale vending machine food. For the first week of their employment, lace the twinkies with meth, and task them with creating a children's game. Once the basics of the game are complete (this should only take a week, given their state of mind), triple the twinkie dosage, and tell them they have five days to finish the game. Then, feed the game's text through Google Translator, and have an American crack addict "spice it up" a bit for good measure. The end result, I suspect, will be something like Katamari Damacy, and while you won't understand why, you'll be as addicted to it as a certain game programmer is to twinkies.

I finally got around to setting up a copy of Gallery for all the pictures I've taken. Not much there yet, but it's coming; we just picked up a 512MB compact flash card for my camera, so I'm no longer tied to the laptop (take 16 pictures, upload to laptop, delete pictures, repeat). The only downside: the camera is extremely slow with the new card. :-P Oh well, can't have everything. Meanwhile, Erica is still contemplating picking up the Canon 20D, since she wants a good digital camera, and as an added bonus, the 20D (sounds like a D&D die or a bust size to me) takes all of the lenses she already owns for her film camera.

This is possibly the most insightful thing I've read all day (which says something about the quality of my day-to-day reading, but that's a rant for another day). I have five terminal windows open right now, running two mail clients, editing this blog entry, and a couple of command lines hanging around just in case; I have two browsers open, one on each machine on my desk, with seven tabs open across both; I have Gaim running with a couple of conversation tabs going; I have a third email client running on my Windows machine, along with an SSH tunnel for covert communication back to the Bat-cave; and on and off I've got a mix of Remedy, various office suite programs, and the occasional video clip or audio file playing somewhere. And this, friends, is an incredibly slow day...I've been stretching for things to fill the time today, including (horrors!) actual work. I apparently have N.A.D.D.

It's out, so in usual fashion, I'm upgrading within a week of release. The web/mail server and database servers are both running FC4 now, and aside from the usual dump/restore needed with PostgreSQL, and some initial issues with Postfix and AMaViS, it went pretty smoothly. I'll do the router this weekend, since it's usually the most problematic of the three outward-facing machines (it manages four networks and a ton of iptables rules; the bridged and wireless interfaces are the two that usually give the most grief), and then hopefully find a minute or two to update the laptop before we go on vacation.

So, for the first time in my 10-year career, I'm actually enrolled in a vendor training course (thanks to $EMPLOYER). I'll be in at Sun's Chicago training center from Dec. 7 through Dec. 10 in their "Sun Fire(TM) High-End Server Administration" course, which really means I'll get to learn about some of the niggling differences between mainstream Solaris that everyone runs, and the stripped-down version they run on 15K and 25K system controllers. This, for a guy who swore he'd never fight with these damned proprietary UNIX monstrocities if he could help it. I'd still rather be running Linux, OpenBSD, or something similar, but hey, it pays the bills, and at least I have a better glimpse under the hood of how most of this works than some folks (sorry, Erica). ;-)

"Imminent death of the 'net predicted, film at 11."

Jabber hacks amuse me; it's very cool to see what folks will come up with, given an open messaging system (see: TCP/IP, SMTP, etc). Hence, I'm not too surprised to see something like JabRSS, but it's still pretty cool. ;-)

Tomcat is not my favorite thing right now. :-P I have it working in concert with Apache to provide for a couple of websites that want to do basic JSPs and bean/servlet stuff. No problem, right? Just use mod_jk2 to connect to Tomcat, and you're all good. Except that mod_jk2 renders mod_autoindex non-functional when you have a DirectoryIndex index.jsp directive in httpd.conf. I've removed the DirectoryIndex directive for now, in an effort to get things working again, but it's rather irritating that, even if an index.jsp file doesn't exist, it still hands over the handling to Tomcat. Looks like I'm not the only one having this problem, but at least the Tomcat folks seem to be aware of it for Tomcat 5 development.

Okay, Pyblosxom is finally driving this site, after a few false starts. Those of you who frequent my home page (both of you!), shoot me an email if you see something obviously not working. I've tried to put some basic redirection in place for old URLs, in my vain effort to combat the effects of the vanishing web; please let me know if there was something you found in a search engine that doesn't appear to be here anymore.

This is probably the funniest thing I've read all week.

After seeing Jeff Waugh's uber-cool website built on Pyblosxom, I was inspired. Imagine, rebuilding my entire website using tools written in Python rather than the crufty stuff I'd done in PHP previously. It appealed to the side of me that liked Wikis, but it was a little more web-focused, and since I know HTML, the formatting so common with Wikis was a little too low-tech for my taste.