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

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]