Archive for February 2006
Came across a fun story in the Minneapolis Star Tribune today about the 10 best beer experiences in the Twin Cities. Those of you in the Midwest may be interested in heading up to some of the bigger festivals.
Remember a while back when I posted a review of a great book on performance optimization? I just found a USENIX paper by the same guy talking about how he tracked down a performance problem to discover that glibc’s malloc() implementation is optimized for system-wide memory efficiency, not performance, and how to change that.
It’s very easy going, suitable for someone with some slight knowledge of C. Recommended reading.
Update: The paper is from 2001, and I haven’t personally verified that this is still the case but it really wouldn’t surprise me at all. glibc’s behavior is definitely still the same (see the malloc() info page), but perhaps mmap() no longer results in a minor page fault. But the really interesting part of the paper to me is the process of tracking down the problem.
Update 2: Val Henson and Arjan van de Ven have written a patch to change this behavior. Here’s her patch page. I coincidentally found this out because Val’s speaking at our LUG meeting tonight.
Another great post from the Passionate Users blog. Working in a boring cubicle keeps you from growing new brain cells.
I guess I’ll have to add some more stuff to my lab bench.
I’ve been trying to fix the Makefile for Gabedit, a computational chemistry GUI, for a few days. It was completely broken for parallel builds (make -j#). Finally I came across an excellent post by GNU make maintainer Paul D. Smith that allowed me to fix the problems. The key was a make-defined variable called MAKECMDGOALS, which is defined to whatever targets were set on the command line.
We’ve got Northwest Airlines tickets to go to Florida to spend spring break with my family. But now, I’m not even sure it’ll happen.
While the pilots stated Friday that they would have the right to strike, Northwest management has argued that a strike under these conditions would be illegal. Northwest has informed the bankruptcy court that it would seek an injunction to block a strike.
In 1998, Northwest pilots went on strike for about two weeks and the carrier lost about $1 billion.
A Northwest executive testified last month that a pilots strike could lead to liquidation of Northwest Airlines.
I’ve added VIDEO_CARDS capabilities to x11-drm and mesa in addition to xorg-x11 now, so you have complete control over which video cards and input devices your X will support. If you happen to use binary drivers, you’ll probably want to set VIDEO_CARDS=”none fglrx” or “none nvidia”; that will prevent the 3D drivers in mesa from building.
Makes for a nice reduction in space — each 3D driver on my system takes up about 13M, when built with debugging. Installing 7 instead of 15 makes quite a difference. Also there’s the savings in build time.
If people clamor enough, I might split ati out into r128, radeon and mach64, as well, but probably won’t split radeon up any further.
I’ve come across an interesting via LWNeWeek article on their use of open source. It’s intriguing to see some of the reasoning that goes on in the minds of people like vice president of architecture Lee Thompson.
A couple of Gentoo-relevant excerpts follow my comments. The main gist is that the ability of your system to survive a larger rate of change is what makes it a survivor, that he wants a Gentoo server distro, and that his goal is to balance the agressive change of the first point and the stability of the second point.
OK, so you know the phenomenon—the phenomena is, the amount of change
that you are sustaining on a Gentoo system is orders of magnitude larger
than the amount of change that a typical proprietary operating system
from anybody—Solaris, HP-UX, mainframes, whatever—[would go through].
Whatever operating system, the rate of patches coming out of the vendor
is much lower than what you enjoy on, you know, my Gentoo laptop or your
And then I started looking, kind of watching this, obviously, from a
technology management perspective. … If you can sustain change faster
than somebody else, you’re going to survive, and the person who can’t
sustain the change is not going to evolve, and they’re going to die off.
This is almost more important a realization than the direct cost
savings, which is still phenomenal.
Yeah, I’ve been running Gentoo for the 2002 to 2003 time frame, and I’ve
had several issues. I’ve said to myself, well, you know, the change rate
is worth it. Change destabilizes, but change is good, and that’s kind of
a classic problem. I don’t want to suffer from innovator’s dilemma at
E-Trade. I want to keep pushing this company very, very hard. So I want
to drive change. The downside of that is if you try to change, you can
destabilize the system.
[Gentoo's Chief Architect] Daniel Robbins always wanted to do a server
variant of Gentoo, which the project, I don’t think, ever started, but
it’s always been something that was kind of on the mind of the Gentoo
community—that there should be the top-of-tree distro, and behind it
something a little more stable, almost exactly mirroring what the Fedora
community project is and the Red Hat AS series of servers.
So, here I am, the guy who’s trying to push change. I work on a Gentoo
box, while our production system is Red Hat AS 3.4, which is very
stable. And so that’s kind of a good way of balancing aggressive change
and stability, in our mind.