I finished my graph figure around 6 p.m. today. Since then, I’ve probably spent an hour pondering it. Two weeks or more went into working on the information in and presentation of that one little figure with three graphs in it. It’s really humbling when you think about how small the material is, and how much effort it took to produce. When it’s printed, it will be something like 6 cm wide and 12 cm tall.

If you really have an urge to see it, drop me a line and I’ll let you know once the paper’s been submitted and accepted. Till then, I’m gonna keep it on the D-L. =)

SWiK is a really intriguing wiki/database for open-source software. It collects info from all over the web, subscribes to feeds, etc. I spoke with the SWiK developers at OSCON a year ago and got really excited about it. Then I found out it wasn’t open source. Now, it is.

Thanks, Steve, for pointing this out.

Yesterday was an enlightening day. At work, I’m trying to compare two protein structures — one is a higher-resolution version of the other. I’m plotting a certain characteristic of each against the other and finding the slope of the line. Great news! There’s a really cool trend between pairs of structures. My boss asked me to switch the X and Y axes around, since one typically puts the newer data on the Y, and the data to which it’s being compared on the X.

So I did, and guess what? The slopes don’t match! That’s right, switching the axes around doesn’t necessarily result in an inverse slope when you’re doing a linear regression. Why, you ask? Because the technique only minimizes for the Y direction. Suddenly my really cool trend isn’t a trend at all, and all the slopes are equal within error.

What we’ve decided to do is put the more accurate data in the X axis, to better account for the larger error on the Y axis using linear regression.

If any of you know much statistics, I’d like to hear a more accurate, better way to come up with a slope that’s robust to flipping the axes (perhaps by minimizing both X and Y distances or residuals?). This method needs to already be implemented in some open-source program and fairly trivial to learn.

Mark Shuttleworth posted (Thanks to Steve O’Grady for the link) about how Ubuntu focuses in a few specific areas, but Debian is a more general plateau. One can trivially draw the parallel between Gentoo and Debian, so his points are equally applicable to us. Most Gentoo developers draw the most pleasure from working near the bleeding edge, not from trying to backport fixes and fix old stable software.

Perhaps this is because it requires more creativity and less monotony. I certainly feel more challenged and fulfilled by packaging new software (such as the system-config-* utilities I did last weekend) than by fixing some simple bugs for random stable packages.

But this raises some new questions: Can Gentoo develop specific “peaks” in conflicting areas, without forcing new subdistributions to form that focus on them? If so, how? Stuart Herbert and I threw around some ideas shortly after I started a discussion about whether democracy works for Gentoo, and our lack of goals.

Stuart’s idea, which I like, is preparing specific “releases” for certain vertical markets. Yeah, I said “vertical markets.” WTH is that? Just a given group of people using Gentoo for a certain purpose, such as a LAMP stack, an HPC cluster or a development workstation. One could create a LiveCD with an installer image tailored to, and preconfigured for, a LAMP server. The key here, as Stuart pointed out in our discussion, is making things “just work,” not just installing the packages and leaving the user to set everything up. But we’d need more than just the LiveCD, because clearly people want to maintain the installation. Perhaps adding a series of profiles for these vertical markets could do the trick. Some developers have already tested this concept with GNAP, the Gentoo Network APpliance, but not in a formalized way that pushes into a number of different areas.

For ages, I’ve thought Gentoo has a major lack in GUI tools to configure various stuff like X, sound, etc. Finally I got sick of it, so this weekend I packaged most of Red Hat’s tools. It really bothers me that every distro writes its own tools from scratch when they’re mostly portable, so I decided to do something about it.

I did most of the work on Friday, and then some cleanup through the rest of the weekend when I wasn’t busy with friends and such. The vast majority simply need a small patch to migrate them to the Gentoo way: chkconfig to rc-update, /etc/rc.d/init.d to /etc/init.d, /sbin/service to /etc/init.d, and the occasional difference in file locations (/etc/ to /etc/bind/, and some PAM modules for authconfig).

Here’s the list:
authconfig (system-config-authentication)
firstboot
hwbrowser
system-config-bind
system-config-date
system-config-display
system-config-httpd
system-config-keyboard
system-config-language
system-config-lvm
system-config-nfs
system-config-printer
system-config-samba
system-config-soundcard
system-config-users

There’s a couple more I may add, such as system-config-cluster and system-config-netboot.

They’re all hard-masked right now, but give them a shot. Please submit patches if something doesn’t work, rather than just whining about it. After all, they are masked.

I have some hopes that I can substitute these tools into our LiveCD builds for the current ones. Some experiments today showed that they can come up with at least the basics of autoconfiguration, and I know they have the capability to write config files as well. Anyone got an idea for how to figure out when to use binary drivers?