Ah, my first press release. This is the most attention anything I've done has ever received. Part of me wishes it was for something less mundane than writing a driver for some off-the-shelf consumer hardware, but I guess I can't complain. It's not often that Slashdot posts about driver releases.

What has been interesting is the response from the community that the press exposure has generated. Criticism that I was expecting—lack of kernel 2.4 support, for example—hasn't come up at all, and the response on Slashdot was decidedly positive which is almost unheard-of. The only (reasonable) complaint so far, besides the missing features like VBI and PAL which I'm planning to remedy anyway, is the price of the Plextor devices compared to similar products. The "Plextor quality costs extra" argument only goes so far, especially considering that Lifeview and Georgia Tech are selling substantially identical GO7007-based units for 25-50% less.

Plextor has been kind enough to donate a TV402U to Isaac Richards, author of MythTV, so maybe soon Myth will support these guys. Ultimately, I'd like to see ODMs develop self-contained PVRs running MythTV with WIS hardware on-board, but we'll have to see. For now, I'll be content to just get some community support around the GO7007.

Purdue is apparently well-covered. Really.

I've just released the first new version of Spook in almost six months. Embarrassing that I've let things go for so long, but at least all the features that have been accumulating in private trees since then have mostly been added. The network-side code has been overhauled which not only made things more efficient but paved the way for multiple media streams in the same RTSP session. Audio. w00t.

Since I started adding the audio support, the limitations and flaws in the current stream implementation have been bothering me. It kind of made sense at first to declare "the output from this grabber is named 'foo', and the input to this encoder is named 'foo' and the output will be named 'bar'," etc, but it's not only confusing but it prevents me from implementing a number of more useful features. It would be nice, for example, to have Spook automatically open all the video and audio capture devices it could get its hands on, compress them to some default reasonable format, and put up a template webpage with a list of everything it found so that the user could test out Spook without configuring anything at all. Not possible if all capture and transformation actions have to be declared explicitly.

There's two major changes I'd like to make to the way Spook creates media streams. The first is to change the media compression and format specification from an imperative form to a declarative form. There's no good reason (other than Unix tradition, I suppose) to force the user to explicitly list the various filters and encoders and the order they should be used, when all that's really necessary is for the user to specify the desired end result. "I want a 320x240 384kbps MPEG4 stream" is enough information to set up the entire module pipeline automatically. The main problem that arises is getting all the nuances of each type of stream correct—providing two different streams, one of 30 fps and one of 10fps, can be done by dropping frames after compression with JPEG, but with MPEG4 the frames must be dropped before they are encoded.

The other change is to convert the stream namespace into a hierarchy instead of using free-form strings. This sounds minor, but it allows modules to create new streams on the fly without causing confusion. Through the magic of sysfs, the V4L module can automatically discover all your USB webcams, configure streams for them, and create meaningful, static names for them. The two cams plugged into the hub on the lower USB port on the front of your system will be always be named something like "Device::Video::USB::2-1:1.0" and "Device::Video::USB::2-2:1.0" no matter when they were connected, because their name is based on their position on the bus. The same devices can be accessible with their device path, like "Device::Video::/dev/video1" or whatever, if you prefer that.

The real advantage of putting the streams into a tree is being able to perform transformations over an entire subtree rather than on one at a time. This would allow one part of the tree to contain a "mirror" the same streams as another part, but having passed through one or more modules. For example, the "Low Quality::" tree could contain the above streams as "Low Quality::Video::USB::2-1:1.0", etc, compressed as 100 kbps 10 fps video, rather than the native 30 fps uncompressed YUV format received from the hardware. These mappings from an existing subtree to a new one would be specified in the configuration file, of course, so the user could control which subtrees were available and the exact parameters used.

At the end of the whole chain, there still needs to be some sort of connection to make the stream available to clients across the network. This could be done through explicit pairings ("rtsp://*/webcam" will serve video from "Low Quality::Video::USB::2-1:1.0") or by exporting entire subtrees ("rtsp://*/cams/" will serve anything below "Low Quality::Video", such as "rtsp://*/cams/USB::2-1:1.0") as the user sees fit. As I mentioned, template webpages could optionally enumerate the streams in exported subtrees to simplify the initial configuration.

By now, you're probably wondering why I'm putting so much effort into automated support for large numbers of streams. It's not like most people have so many webcams that they can't configure them manually, right? Well, the ultimate goal is to turn Spook into more of a generic network media mixer, capable of importing video from any video source local or remote, performing some set of transforms on it, and exporting it over the network using a variety of formats and protocols. Re-encode video from the DCS-900 watching your koi pond into MPEG4 and relay it through another, more well-connected server via RTSP? No problem. Webcast press conferences from the room's AV system while simultaneously recording them for later retrieval over streaming RTSP or AVI download over HTTP? Makes sense to me. "Tune in" to the physics class lecture you're skipping by dialing a number from your mobile phone? Why not?

Putting as many media sources as possible into a common namespace doesn't get much closer to convergence, but it's a necessary step.

The spambots finally found my weblog, so the comment plugin is gone. Hope y'all don't miss it too much. Feel free to email me directly if you're unable to contain your rage over my scathing political commentary.

I guess I've been kind of anti-social for the past few months. I've been doing some work for Wis Technologies, who makes the world's most bad-ass real time video encoder ASIC, filling in some gaps in their reference software. They've been funding work on Spook, and although most of it hasn't yet gone back into the public tree, it's come a long ways. I also have some stream-relay code that I've yet to check in. Hm, Spook is looking kind of abandoned these days. I should poke it a bit more in the near future.

January has been consumed with a mad rewrite of the Linux driver for the WIS encoder. The old driver sucked mightily, so when Plextor wanted to their ConvertX product line to have Linux support (which didn't exist before only because it didn't occur to anybody), trashing the old code and starting from scratch was pretty much the only option. It came out pretty well though. It's in QA now and should be released via Plextor in a week or so.

For consulting I decided that I really should have a working Microsoft Office workstation, so I bought a Dell Dimension 3000 with WinXP Pro and Office SBE for just under $1000. (At retail, XP Pro and SBE would cost $710, so I figured I'd spend the extra $250 and get a rather nice PC to run it on.) I ordered seven days ago, Dell shipped it the next day, and I received it today on the third delivery attempt.

Having not owned a Windows system for almost four years, I was rather surprised at the amount of hassle it takes to get an out-of-the-box PC up and running. I can understand having to update the virus database, install a couple patches to Windows, etc (although the drive was imaged at the factory a week ago) and I can even tolerate "Windows Product Activation", but just to get the preinstalled copies of XP, Office, and McAfee running, I was not expecting:

• Clicking "I Agree" on eight different EULAs, not counting Dell's infamous "Press any key to indicate acceptance of all EULAs for all software preinstalled on this system" screen that pops up two seconds after the first boot.
• Seven required reboots, two of which occurred after nothing obvious had happened.
• A 23-meg "critical update" for XP.
• Harassment from Windows Security Manager (whatever that is) every time I boot because I have set Windows Update to only notify me when updates are available, but not to download and install them automatically.
• Harassment from "Dell Support", telling me it wants to upload "anonymous usage statistics". No, there's no way to turn it off. The only relevant option lets you toggle between asking before sending statistics or simply sending statistics without notifying you at all.
• Having to open the help browser to figure out how to update my McAfee virus definitions, even though the McAfee control panel popped up on every boot to alert me that my definitions were out-of-date.
• Language settings in all my Office applications default to "Chinese (Taiwan)". (I'm pretty sure Dell ships legal software...)
• And, of course, having fifty different preinstalled apps that I didn't ask for, telling me to sign up for music downloads, dialup Internet access, etc.

Honestly, how do people put up with this nonsense? Suffering through all this crap makes setting up Gentoo look easy!

OK, so I figured if I shut down my X session entirely, I could let emerge upgrade Gnome to 2.6 and start up a new session afterwards and everything would work fine. I even checked to make sure gconfd and friends were gone, as they have a habit of sticking around after a session ends.

Turns out that's not good enough. Apparently, during the upgrade process, some test suite started up the Bonobo activation server, and when I started my first Gnome 2.6 session there was much weird behavior, like gnome-settings-daemon failing to start.

Probably the best way to make sure everything's reset is to reboot the system entirely, but damn, that feels waaaaay too un-Unixy.

In related news, Gnome 2.6 is pretty much identical to 2.4, although that annoying dialog box in Epiphany asking whether to open or save the playlists from Shoutcast is fixed.

Webcams are surprisingly useful for discovering where heating ducts go. They are small and can be dangled by the cord for a good 15 feet down a vertical duct or look around corners under the floor. I posted a typical picture looking at the hidden side of a light fixture inside one of our returns.

I've got my process down. Update the README, `make distcheck`, upload the tarball, update the webpage, submit to Freshmeat, update the weblog.

Tonight's release adds Video4Linux support, so now the other 95% of the Linux community can use it. V4L is the API used by frame grabber cards and USB webcams, so I guess I should support it. USB webcams are pretty pathetic quality in comparison to Firewire webcams, and are also annoying to support because every USB webcam driver has its own funky API to set framerate and what-not. But it's what most people seem to have, unfortunately. Just for fun, I threw in support for the Philips webcams, but since I don't have one myself I have no idea if it will work.

Maybe tomorrow somebody will actually subscribe to the mailing list, too.

Been a while since I posted here, eh? As it happens, I've been deeply engrossed in a little toy that grew into a real project.

I've always been disappointed in the lack of decent streaming webcam software. Everyone and their dog has written a "grab an image and FTP it somewhere" app, usually complete with a crappy, useless GUI. (All you people who remember Cyclops are nodding your heads and thinking, "Yeah Nathan, you're one to criticise crappy webcam servers.") Some people go so far as to write a custom Java/ActiveX applet to pull down images real fast for kind of a redneck "streaming" effect. (Carson calls this "faux streaming".) The closest I've seen to live video is the HTTP multipart/jpeg streaming implemented by camserv and the Axis network cameras. This works, to some extent, but there's just something repulsive about shovelling JPEGs down a TCP socket as fast as possible and calling it "live video".

Come on, people! For decades we've had video compression techniques that are specifically designed to push live video down small pipes. And protocols for streaming real-time multimedia over IP networks have been standardized for over 10 years. The folks lucky enough to have multicast IP access have been holding multi-user video conferences since before most of the world had even heard the word "Internet". So why on Earth should we put up with the equivalent of mailing Grandma a stack of Polariods and telling her to flip through them really fast?

Before you say anything, don't give me that "widest possible audience" crap. I know you want your webcam to be accessible to anybody with a web browser, but how many people do you know who don't have QuickTime installed? Seriously, everybody who didn't have QuickTime installed already went and installed it to watch the Lord of the Rings trailer. And if they didn't care about the LotR trailer, they don't deserve to watch your webcam anyway.

OK, so where was I? Right—my point was that we already have the technology, standards, infrastructure, and most importantly the viewing software in place to start feeding people quality live video from our homes and offices. All we need is the server software. So, properly motivated by such an obvious need, I wrote some.

Spook is my attempt at a decent live streaming video solution. It captures video from Firewire cameras, compresses it to MPEG4 with XviD, and streams it (via unicast, no multicast required) to anybody who asks for it using RTSP. The result: true live video at 30 frames per second with a resolution of 320x240. In half the upstream bandwidth of the average cable modem. Now that is what I'm talking about.

Today was the first release of Spook. It only supports Firewire cameras for the moment, so I'm sure I'll get a few more folks interested once I support Video4Linux and all the TV capture cards and USB webcams it brings. The problem with V4L is that configuration for each camera chipset is different, so it may be a bear to support configuration of FPS and all that. I'll find out soon, I guess.

Sad is the world of Linux wireless Ethernet. Sure, the "traditional" chipsets like Orinoco/WaveLAN, Prism, and Aironet work as well as they always have, but newer hardware like the Atheros chipset, the new MPI-350 card from Cisco, and the infamous Centrino chipset are all only supported by broken/outdated closed-source drivers, or are not supported at all.

My new Thinkpad is "wireless-ready" meaning it has a built-in antenna and a mini-PCI slot for a wireless card. Nifty, right? The niftiness of having internal wireless hardware combined with the advantage of being able to select a NIC with good Linux drivers. But naturally, IBM doesn't make it this easy. For "regulatory" reasons, which I guess are understandable considering the anal retentiveness of the FCC, the BIOS is programmed to accept only one of three cards in the mini-PCI slot. You can guess which three cards they are based on the previous paragraph.

The Thinkpad shipped with a Centrino card, which wasn't looking promising as Intel has been promising Linux drivers for over a year now without delivering anything. The best option seemed to be the Aironet card, since older Aironet cards have been supported under Linux since the beginning of time. The "official" Cisco Linux driver for the MPI-350 was a closed source module last updated over a year ago, but kernel 2.6.3 was released with experimental support for the card in the airo module, so I figured my odds of getting it working were good.

I priced out the MPI-350 in the usual places, coming up with about $70, but then it occurred to me that the IBM OEM cards might have a different PCI ID and only the IBM-supplied MPI-350s would make it past the Nazi BIOS. So I bit the bullet and ordered an Aironet MPI-350 for $120 from IBM.

The day before my new card showed up, Intel announced the first release of their Linux Centrino wireless driver. Open-source and everything. I tried it out and it worked. But a bit buggy and no WEP, so I decided not to return the Aironet card.

So today I finally got around to installing the new card. Hardware installation was painless, of course. Then I booted up and found that the airo module had been loaded, but the card wasn't associating with the access point. A Google search revealed that my card's firmware was too new, and that I needed to downgrade to 5.00.03 to get it to work. No problem, I can download that from Cisco, and flash it into the card with... oops.

The open-source driver won't talk to the new firmware at all. The Cisco Linux driver also requires an older firmware, so there were zero options for flashing the card on Linux.

Two hours later, Windows XP was restored on the laptop. Three minutes after that, the card had been downgraded. An hour later, Linux was back.

One final issue. Although Linux could now talk to the card, it wouldn't associate with an access point. It seemed to be a problem with the WEP configuration due to messages like:

Setting key 0
airo: Max tries exceeded waiting for command
PC4500_writerid: Write rid Error 65535
PC4500_writerid: Cmd=0121
airo:  WEP_PERM set ffff

The solution was to download the Cisco Linux Aironet Configuration Utility (ACU), which actually works with the open-source kernel module as well as Cisco's kernel module, and use that to set the WEP key. Since the card stores the key in non-volatile memory, this only needs to be done once. Now when I boot the system, I use iwconfig eth1 enc on to enable WEP without trying to set a key, and this uses the stored key to associate with the access point. Success!

I believe at this point, my laptop is now fully functional. All I need to do now is figure out how to do some of the fancier power management to squeeze the maximum life possible out of my battery.

I finally got around to fixing my Perl script to forward email to my cell phone, which Verizon broke last month, and the first email that came through was a worm with a forged address from a whitelisted domain. That really says something about the Internet today.

I guess now's as good a time as any to jump into the Atom vs. RSS debate. (I've been meaning to post this for a while...) For those of you who don't follow the exciting world of weblog syndication, the venerable RSS syndication format is under attack by a young upstart format named Atom. While the development of Atom was started only eight months ago, it has caught on quickly in the weblog world, and most weblog software now supports it as well as a number of prominent sites such as LiveJournal and Blogger.

Why a new syndication format? Mostly the issue seems to be over the control of the RSS spec. While RSS was originally developed by Netscape, it was abandoned as the company lost market traction, and Dave Winer took over maintenance of the specification. The problem is, Dave Winer doesn't seem to understand how standards are supposed to be maintained and developed, and many people feel he is exerting undue control over the future of RSS.

So, to take advantage of starting from scratch, the Atom standard goes beyond just defining a "syndication" format. A format for accessing archived entries was created, and there are even standardized mechanisms for posting new entries and updating old entries. Soon, the variety of weblog update clients that LiveJournal users have available will be able to update and maintain weblogs running on any server software using the Atom API.

The Atom spec is cleaner and better designed than RSS, and as a result can support a much wider range of uses. Wiki sites are already using Atom to publish entries and accept new submissions. Want to publish XML-formatted security updates with Atom? You can embed your XML directly into the feed without having to entity-escape it, allowing much simpler implementation of the parsers. Atom supports feeding information from machine-to-machine, instead of just the machine-to-person format that RSS imposes by its poor design.

Hopefully, more sites will discover nifty uses for Atom, and it will become the starting point for growing the semantic web beyond the current content syndication rut we're stuck in now. The sooner we discard RSS in favor of Atom, the sooner we can move on.

Over the past week I've been installing Gentoo on my workstation, faboo. I've probably done 10 Gentoo installs so far, and I'm still figuring new things out each time.

Things I learned this time:

• The genkernel utility does a poor job of configuring the kernel. Or at least, the default config files suck.
• The "Hot plugging" option in the kernel config menu actually does something, even if you don't check any of the options inside it. You have to turn it on to get hotplug kernel messages, which Gentoo uses to configure network interfaces, sound cards, etc.
• Beware of copying an XF86Config file from the old RedHat install to the new Gentoo install on the same box. You have to remove the font config paths and change the mouse device path or X won't start, or worse, lock up your console.
• Old stage1 images may have dependencies for bootstrapping that are too old. Bootstrapping last September's stage1 will cause a bunch of stuff to be unexpectedly merged, including Python. It's all stuff that would be merged during the system build though.
• Upgrading GRUB doesn't require a re-setup, oddly enough. This is because stage1 and stage1.5 which actually get embedded into the boot sectors use a "standard" entry vector into stage2, which stays on the filesystem and therefore is upgraded directly by emerge.
• Dot files in your home directory from GNOME 2.0 will seriously screw up GNOME 2.4.

So I'm back online now, for those wondering why I haven't been on Gale in a while. :-)

Linux Weekly News posted an article about Bill Gates' solution to spam—essentially, it's the old proposition that charging "postage" on email will cause mass-mailers to think twice. (The LWN article is subscriber-only until February 12, but the Gates speech was widely reported).

I posted a comment on why the suggestion is idiotic, but I liked it enough that I reposted it here:

I wish people would stop with the "email postage" idea. It is a BAD SOLUTION. Ignoring all the problems mentioned in the [LWN] article, the premise itself is short-sighted.

If we assume we can actually build this postage system thingy, and then make the bigger assumption that it will stop spam without destroying the efficiency and convenience of email entirely, what will spammers do? Concentrate their efforts on instant messaging? Develop better software to create weblog comment spam? Auto-dial our wireless VoIP phones and play recorded messages? Maybe download advertisements directly into our brains with our neural uplinks?

The point is that putting all of our effort into designing a system specifically to tackle the RFC822 world would just push spammers into other net-based communications systems, where we'd have to start from the ground up to implement a totally new solution. (What's that you say? We'll just extend the postage system and start charging 5 cents to make a VoIP phone call? What a great idea! And a penny to send an instant message... Oh, no! My Internet bill is higher than my car insurance, because I'm paying for services with totally artificial prices!)

What we need is to create some sort of filtering or authentication system that can be applied to all Internet communications, and imposes technical limitations rather than economic ones. SPF is a step in the right direction, by adding authenticity to the sender address and accountability for abuse, and the concept can be extended to any IP communications. Once the offenders are identified, it will be much easier to filter them out than when they hide behind anonymous (and unaware) zombie relays. Maybe if the use of public key encryption software was more wide-spread, we could extend the accountability all the way down to the user, giving everybody the capability to filter and blacklist at the level at which the abuse takes place rather than indiscriminately blacklisting entire ISPs.

I wish all the hub-bub about email postage was refocused on a solution that would last longer than the keyboard-oriented human-computer interface, and didn't favor economically-advantaged users.

Most people reading this weblog have heard of ENUM by now. Or at least the promises: "ENUM eliminates printing URLs on business cards! Your 10-digit phone number will identify your email address and webpage using the magic of DNS!" Essentially, the entire E.164 hierarchy will be mapped onto DNS under the e164.arpa zone. Phone numbers will be broken up by digit, so at each digit the tree can be delegated to an organization responsible for smaller and smaller geographic areas, until potentially the individual phone number can be delegated to the owner of the phone number. The number owner can populate the zone with NAPTR records containing an IM address, email address, SIP address, webpage, and whatever else they may want to store there.

Privacy arguments aside, at first glance this seems asinine. Why, in the age of DNS, would anybody in their right mind want to revert to using numeric strings as identifiers? Isn't something like jsmith@corporatesoft.com much more memorable and self-descriptive than 17123514225? If numbers were better, the DNS system would have never been invented in the first place and we'd all be typing user ID numbers and IP addresses into our email clients.

The only vaguely permissible excuse would be backward-compatibility with devices having only a numeric keypad; telephones being the obvious one. But hold on a tic; if it's so hard to enter a real email address or IM screen name into a telephone, wouldn't it be equally difficult to type the actual message that you want to send?

So anyway. Regardless of the marketing hype, ENUM excited me because it allows SIP addresses to be tied to phone numbers. This bootstraps VoIP from the phone system, in a sense, because VoIP customers and carriers can use ENUM to determine whether a call can be carried over the Internet rather than the PSTN. Presumably, a call made from one CLEC to another can be completed through the Internet without the need for a peering agreement. This ad-hoc, peer-to-peer architecture is the basis for the infrastructure of the Internet as we know it, and is the key differentiator between the Internet and old-style circuit-switched networks.

ENUM is starting to be deployed across Europe, and a rational mechanism is used to delegate responsibility for each portion of the e164.arpa tree. Generally, the country code is delegated to the federal government or a neutral national body, who delegates the top-level number assignments to the phone companies. Then the phone companies allow the customers to control the entries for their number, much like controlling how the number is listed in the phone book.

You'd think this framework would be fine for the North American country code. Apparently not. An international body, the ENUM Forum, was formed to come up with a plan. And it couldn't be simple: the current working revision paints a complex picture defining a system of registrars to manage the ENUM tree as an entirely separate world from the phone companies.

Here's how it works: a "Tier 1" registrar will be appointed who runs the DNS servers for the 1.e164.arpa zone. Then "Tier 2" registrars will take orders from customers to register their own phone numbers. Tier 2 tells Tier 1 to delegate the phone number's corresponding zone to the Tier 2's DNS servers, and Tier 2 manages the NAPTR records for the customer.

Huh??? What's going on here? The phone companies that own the phone numbers will have absolutely no control over the ENUM zones? The 1.e164.arpa zone will be a flat namespace instead of a tree? And worst, I'll have to pay to register a phone number that the phone company already assigned me?

So much for using ENUM as a carrier-to-carrier tool. If CLECs don't get to fill their own ENUM zones, the leap from PSTN to VoIP depends on customers to bridge from E.164 numbers to SIP by themselves. Slowly it will happen, as businesses and individuals become aware of the benefits of VoIP, but it will proliferate like fax machines—the customers will build the network from the edge, rather than having a guiding organization to do it from the inside. Ultimately, the marketplace will be best off with the customer in control of his telephony choices, but the telecom industry will have to migrate to VoIP without the benefits afforded by the world-wide cooperation that fostered the Internet of today.

Puck now has 512 MB of memory! Woohoo!

So the funny part is the memory I ordered the first time is the right stuff. Dell was right; the system shipped with registered memory although the DIMM inside was not labeled as registered. So I guess I'll be returning the second stick I ordered. Man, I feel dumb.

The upgrade went fine for the most part; puck is now running Gentoo on the system image and is plugged into a nice SmartUPS with monitoring.

The memory was not upgraded. Although Dell's support system claims the server was shipped with registered memory, when I opened the case I found unregistered memory. This is unfortunate, because the memory upgrade I purchased is registered, and therefore cannot be installed next to the OEM memory.

I guess I'll take the 20% restocking fee to return it and purchase the non-registered. Stupid Dell.

With the impending termination of support for Red Hat Linux, I have been working on getting all my old Red Hat systems moved to Gentoo. I'm mostly done with the ones I care about, but the big one still remains. Puck won't be completely moved off RHL by December 31, when security patches will no longer be released, but I'm aiming to have the boot system moved over to Gentoo. (Users only see a system image inside a chroot, so there's not much in the boot image.) Ariel's boot image has already been converted to Gentoo and is working fine, but with puck there's much pressure to get it right the first time since so many people are relying on it and it's a bit of a drive to get to.

Hardware upgrades are happening as well. I'll be adding another 256MB of memory as well as a longer-lasting UPS. Of course, with the addition of a SmartUPS, I also feel obligated to set up proper UPS monitoring software, so that's consumed a bit of my time as well. It works fine on ariel, and hopefully the configuration will transfer easily.

Downtime this weekend should be a couple hours at most. Those who use puck regularly will receive a separate announcement, including a specific time for the outage.

The contracting officer just approved this, so I can talk about it here now.

Last year I was involved with the UMLWIN32 project, which is attempting to make the Linux kernel run on Windows as an application process. This allows Linux virtual machines to run on a typical unmodified PC alongside other Windows apps. It's a nice migration path from Windows to Linux. We got to the point where we could boot up a simple environment and run some basic programs. Shared libraries and networking worked. Unfortunately, the project stopped when the developers ran out of free time.

Now the Japanese government has stepped in and offered to fund the development of UMLWIN32. While I can't participate this time around, it's a cool opportunity to help bridge the gap between Windows and Linux for first-time Linux users. Hopefully the Japanese deployments will iron out any problems, and commercial Linux vendors will be able to provide "migration kits" to help all users migrate from Windows to Linux with a minimum of pain.

There should be an official announcement of the government support of UMLWIN32 RSN, but bureaucracy always moves sooooo sloooooowww...

Tonight we tried watching 24 about half an hour after it started airing, thanks to the magic of MythTV. Unfortunately, today's 24 did not appear in the "recorded shows" menu. In fact, no show had been recorded since Thanksgiving. Some debugging revealed that mythfilldatabase hadn't actually updated the program database since 11/19 due to some changes at the site that the data is ripped from, so once I hit the end of the 7-day buffer, no shows were recorded. A new version of XMLTV was released on 11/19 which would have fixed the problem, but silly me, I didn't notice that there was a problem and thus didn't upgrade.

I am now subscribed to the XMLTV project, so I can see when new releases come out and will have a minimum of 7 days to upgrade.