Sun, 21 Mar 2004
Nexus
"Network theory" has been on my reading list for a while. My first question: what are people talking about when they say network theory? Nexus answers this in such an accessible way that even a humanities major such as myself could follow. The answer to my question is "small world" theory, which deals with the abundance and properties of networks that allow surprisingly short links between nodes in large networks. This is of general interest because a "network" in this context can mean many things, from the neurons in your brain to connections between Hollywood actors (think of the Kevin Bacon game). There's no sense in summarizing all the material, but there are a couple notes of local interest. Buchanan looks at the social networks of neighborhood activists in the West End of Boston and Charlestown during the 60s and suggests that the latter had more of a small world structure, which could account for their greater effectiveness in surviving the city's destructive program of "urban renewal." Similarly, during the 70s Boston's Route 128 companies were vying with their counterparts in Silicon Valley to become the world leader in high-technology development - a struggle that Boston obviously lost. Buchanan:
A freewheeling and open Californian culture, in contrast to the more closed and proprietary nature in New England, seemed to make a huge difference.
This kind of statement sounds typical of the social "sciences", plausible but ultimately impossible to prove. Small world theory provides the tools to model such scenarios and produce testable hypotheses.

Very readable, and the theory has enormous potential to help us understand important stuff. Recommended to one and all.
[/book_review]
Sun, 07 Mar 2004
Proprietary Drivers Hurt Companies
Eric Raymond is a little nuts but he's thought through the economics of open source software as much as anyone, and my personal experience keeps validating many of his conclusions. Today's example: the afterword to his essay The Magic Cauldron. In this afterword, ESR lays out the case for hardware companies to release open source drivers for their products, or at least make the interfaces public so that somebody else can write the drivers.

As I alluded to before, I've learned this lesson the hard way. Back when it was just starting to threaten 3dfx, Nvidia announced that it would supply linux 3d drivers for its current card (the TNT). I had recently converted my home machine to linux and wanted to voice my support, so I ordered one of their better cards (a TNT2, with 16 megs of RAM). My first surprise was that the 2D quality was worse than my old card, an S3 Virge (not a software problem but still irritating). My second surprise was that Nvidia did not release any actual drivers for something like a year after their announcement. My third surprise was that, once released, the drivers were absolute torture to get working. Maybe it was because my card was installed in an AMD system, or because I was running Debian and not Red Hat, but the driver never quite worked. I did get it working briefly once, but after upgrading the kernel, it never worked again. I also tried to get another TNT2 working in a PIII system, without any luck.

I knew that many were using Geforces under linux and didn't have problems, so Nvidia's drivers couldn't have been totally defunct, but they sure didn't work for me. I have installed and configured a variety of OSes on a variety of hardware and I've never had half the trouble that I did with Nvidia graphics cards. Lesson learned: no more hardware with binary-only drivers for me. My next video card was an ATI Radeon, which worked just fine with the default, open-source driver built into X.

Now that I'm weighing my options for a new AMD motherboard, any with the Nvidia chipsets are out of the question, as some of their functionality requires binary drivers. It looks like the situation with the nForce chips is similar to what I experienced with the TNT2: they work for some, don't work for others, there is no consensus on what the problems are, and little hope of figuring more out given that the drivers are binary-only. Life's too short to work around what ESR convincingly argues is a self-defeating strategy for Nvidia. I'm still working Ebay for a deal so it's not clear exactly which motherboard I'll end up with, but I do know that it will have a VIA chipset and not one from Nvidia.
[/code]
Wed, 03 Mar 2004
My Motherboard Died
dead mb I put my computer together about three years ago, and selected parts with an eye towards reliability and value. Based on the reviews I could find, I picked an MSI 6330 motherboard. Today it seems to have croaked, and according to the posts I've found, this is extremely common with these motherboards, often happening six months to a year after being put into service - something to do with cheap voltage regulators, it is suggested. With the benefit of hindsight, I can guess that I would have been better off considering not just reviews but also the manufacturer's reputation for quality, which would have pushed me to buy an Asus or maybe Abit.

This leaves me with the question of what to do: either replace just the motherboard, or spend a few more dollars and get a reasonably modern motherboard, processor, and RAM. The best value in processors is, again, from AMD, and the best motherboards seem to be those with Nvidia's nforce2 chipset. Unless you'd like to run linux, which I would. Nvidia has a long history of providing binary drivers of questionable stability for their products under linux, and traffic on the kernel list indicates that the problem has spread from their graphics cards to their chipsets. Some people report success and stability, but I know that this isn't the sort of thing I'd like to spend days working out. So, it's off to Ebay for one of the very motherboards I should have purchased over three years ago, at a cost of $20-30 shipped.
[/general]
Tue, 02 Mar 2004
why's guide to Ruby
The Pragmatic Programmers recommend learning a new {programming} language every year or so. I think this is great advice for the professional, and have always intended to do follow it. This {financial} year I'm working on Python, which I have come to appreciate more than I'd anticipated, coming from a perl and java background. Next fall, as financial year 2005 gets underway, I will seriously consider turning to Ruby, if no other reason than as an excuse to spend some time with why's (poignant) guide to Ruby. Cartoons, sidebars, programming examples - there's something there for everybody. Another advantage of waiting is that it may actually be done by then.
[/code]