Just some stuff I've been rotting my mind with late at night lately..

• The British reality series Shipwrecked (of all things!!) is the only reality TV I've ever really enjoyed beyond the first few seasons of the Amazing Race. I enjoy it for many low reasons, plus it tickles a sociological interest, without being real enough for that to be anything but an idle entertainment. But the best parts are that many of the people don't treat it as a game (especially the thirdies after 3 months), and that they seem to have come up with a format this season that can never be done again. So, mind rotting entertainment with a built-in expiration date, and a pesudo-intellectual tang. What's not to like?

• David Gerrold's Jumping Off The Planet channels Heinlein basically perfectly, modulo being written for a comtemporary audience. Sorry, Spider, I know you tried, but I could actually hear RAH talking in the pages of this juvenile.

• The Website Is Down is both the funniest and the most depressing web video ever. Meanwhile, the mini-documentary Possessed explores a trap that's hardwired into us -- I wish that other human foibles could be highlighted like this does, because if you identify with the people in it at all, you'll change. (If you still can.)

Dear LazyWeb,

I use the standard ciabot.pl script in a git post-receive hook. This works ok, except in the case where changes are made in a published branch, and then that branch is merged into a second published branch.

In that case, ciabot.pl reports all the changes twice, once when they're committed to the published branch, and again when the branch is merged. This is worst when I sync up two branches; if there were a lot of changes made on either branch, they all flood into the irc channel again.

Am I using the ciabot.pl script wrong, or is there a better script I should use? Or maybe there's a CIA alternative that is smarter about git commits, so it will filter out duplicates?

Here, FWIW, is how I currently use it in my post-receive hook.

while read oldrev newrev refname; do
    refname=${refname#refs/heads/}
    [ "$refname" = "master" ] && refname=
    for merged in $(git rev-list --reverse $newrev ^$oldrev); do
        ciabot_git.pl $merged $refname
    done
done

Update: After hints and discussion from Buxy, I arrived at the following:

while read oldrev newrev refname; do
    branchname=${refname#refs/heads/}
    [ "$branchname" = "master" ] && branchname=
    for merged in $(git rev-parse --symbolic-full-name --not --branches | egrep -v "^\^$refname$" | git rev-list --reverse --stdin $oldrev..$newrev); do
        ciabot_git.pl $merged $branchname
    done
done

With this, changes available in another published branch are not sent to CIA.

There might still be some bugs with this.

I spent a week recently working on the nonfree firmware problem in debian-installer. The problem of course, is that nasty nonfree firmware is needed to use many wireless cards, some other NICs, and some disk controllers, but cannot be included in d-i images.

The fix/workaround landed in unstable today. d-i will detect if a driver needs firmware that is not available. It'll then prompt the user to put the firmware on removable media (such as a USB stick, or floppy, or really anything you can plug into a machine without drawing blood).

The debian-cd team will be building some zip files and tarballs containing all the firmware that debian ships in non-free. (images here) Extract one of those onto a USB stick (vfat formatted), and you're good to go.

The installer will also tell you the names of the firmware files it needs, so if they're some of the ones that Debian cannot even legally distribute (such as the ipw2200 firmware), you can go hunt them down, and dump them onto your USB stick too.

The installer can find firmware files loose on the USB stick, or packaged up in a .deb (or .udeb). The firmware will be used during the installation, and also installed into the finished system. So providing it in .debs is cleanest.

(BTW, if you package a firmware deb for debian, please avoid putting anything but firmware and documentation in it. These firmware debs are also installed into the d-i environment now.)

This could be considered a little clumsy, needing to manually find the bits and put them on a USB stick. I think that people who install Debian frequently will probably end up gravitating toward the "hd-media" installer that boots from USB stick. The firmware can then be put on the same USB stick that contains the installer, and only one thing be needed to install.

Still to do: Use discover's capabilities to scan for firmware that is needed by other devices on the machine, that are not needed to install, but can be used later, and install that firmware too. (This will also support installing non-free kernel modules and other such evil.)

Though I'd mention that I'm thinking a lot about distributed bug tracking right now.

LWN had an article a while ago about distributed bug tracking, and one interesting suggestion that came out of it was that a bug report could somehow be passed around from one project to another while still somehow remaining the same bug report and connecting together the info from the different systems it passed through.

That would really be excellent, but getting there seems hard, since there are many different bug tracking systems, all incompatible, and all storing incompatible data. Launchpad tries to pull together info from all of them in a centralised, top-down way. I'm thinking much more decentralised, ad-hoc, and bottom-up. And more subversive. Amoung other things, I'm thinking about microformats.

Anyway, I think it would be good to get a group of interested people together to look over my ideas once they're a bit more refined, and generally beat on the distributed bug tracking problem. If you're interested, get in touch.

This is not exactly new, but it was new to me..

A guy on a trikke is zooming around downtown today. The swerving motion is bit of a traffic hazard, but it looked like fun, and pretty efficient. It's basically inline skates for those who lack balance. With brakes.

Have you ever chewed over a problem a user was having on IRC or mail for hours, trying to narrow it down? And then, finally figured out how to reproduce it locally, and solved the bug in minutes?

I hate that. Sometimes getting to the reproduction point can require getting a ssh account on a machine with the problem, with all the pain of dealing with an account, and passwords or keys, and etc.

So I was thinking, it would be nice if there were a way you could ask, "Hey, can I type into your console for a few minutes?"

All it would take is a program that they can run, that generates a one-time password, that lets you into a screen -x session. So they can see what you're doing, and hit the panic button ("screen -D") if you start typing "rm .." :-)

Well, I guess I have a project for this evening. Though many people might be reluctant to install it.

discussion

We tried the Harvest Table restaurant in Meadowview, Barbara Kingsolver's place and an outgrowth of her book Animal, Vegetable, Miracle: A Year of Food Life (which I have yet to read).

All the food is local (or as close as possible) and seasonal. A great time was had by all, and the food was amazingly flavorful and fresh. Nicest of all was that we kept finding ingredients that you just don't normally find in restaurant food -- because typical restaurant's don't bother using quirky local produce. For example, I'd not expect to find lamb sausage in a burrito.

Looking forward to going back and enjoying whatever's in season once my wallet has recovered.

code_swarm videos are lots of fun. The ultimate geek music video.

• Here's one where I make a cameo appearance as the great disruptor: Debian Perl Group code_swarm

• And this one features me and a band of defenders holding the line against the ravaging wiki hordes: ikiwiki code_swarm ;-)

• Looking forward to: d-i and git

  (Oh and also to a video editor for linux that doesn't suck. Not holding my breath; kino is actually tolerable if it could only read more formats than dv.)

discussion

After many years with ion, I've switched to using the Awesome window manager. This took three tries; the latest try seems to have stuck.

I wish I had a good analogy to explain to my nontechnical readers what changing to a new window manager is about.

One way to think about it is that it's like driving a car down the road, and suddenly swapping the steering wheel and brakes out for a tiller and gear shifter. And having to downshift for braking until you learn that the brakes moved to the turn indicator lever. By trial and error.

But that's really only part of it. Another way to look at it is adopting a new philosophy. Or, in some cases a cult. (In some cases, with crazy cult leaders.) Whether they use Windows or a Mac, or Linux, most computer users are members of a big established religion, with some implicit assumptions, like "thy windows shall be overlapping, like papers on the desktop, and thou shalt move them with thy mouse".

So, changing to a new window manager is a process of being dumped into a different environment, where nothing works like you've come to expect, and trying to construct a mental model that you can use to make sense of it. But it's also a process of modifying that environment to behave the way you like.

And when done whole-heartedly, this doesn't just mean trying to make it like the environment you were used to before. It means trying to absorb the underlying philosopy of the window manager, and think up new ways of doing things, inspired by that philosopy, and modify the environment to allow doing those things.

So ideally, "I switched to a new window manager" doesn't mean "my screen has some different widgets on it now". It means "I'm looking at the screen with new eyes."

discussion

Went swimming in the Clinch river (the real one) @ the River Farm. Failed to find sinking creek's spring. Installed debian on Anna's new laptop, which went swimmingly though the wireless is a bit odd. Best pasta in recent memory. In bed @ Yurt.

I'm envisioning a graphical app that displays a file. Like a pager, the up and down arrows move through the file. But the left and right arrows move through time. As each successive change to the file is displayed, the committer's name appears in a column to the left of the lines changed in that commit. Hover the mouse over it to see the commit message. Names of old committers will fade out as time advances, but still be visible for a while. (A menu option will disable the fade out entirely.)

A nice bonus feature would be to allow opening multiple windows, with multiple files from the same repo. Moving back and forward in time would affect them all at once.

A nice, but getting harder feature would be to have a horizontal timeline at the bottom, including branches, so you could click on a specific branch to visit it. (Without this, when passing a fork or merge point, it would have to choose a branch heuristically?)

A tricky subtle feature would be to attempt to keep the current code block centered in the display as lines are added/removed from the file, adjusting scroll bar position to compensate.

There seems to be a gannotate for bzr, that may do something like this. Offline so I can't try it.

Google-and-caffine-fed update: bzr gannotate is closest to what I envisoned, though without a few of the bonuses (fade-out, smart scrolling, multiple files). qgit's "tree view" includes the same functionality, but the interface isn't as nice.

discussion

Nobody I know knows how to cut a watermelon.

I've seen it done by experts once: A family attacked one, sitting on a picnic table. In their hands, it became a wholly different fruit than our stodgy sliced seedless. They had a small knife. Chainsaws would not have made it more exciting.

I saw it done, but I don't know how.

discussion

So for those of you who arn't aware, as of yesterday, it's easy for any spotty teenager/script kiddie to make you see content you didn't expect to when you go to google or your bank, etc. Maybe you're lucky and someone has fixed the problem on your network. Most likely you're not so lucky.

(Confidential to Anna, Maggie, Adrianne, Errol, Barbara, Mark: You're lucky! But only when you're at home.)

At the moment, the idea that DNS can be trivially poisoned seems like a really serious problem.

Will there come to be a point when we just regard this as "DNS spam", basically accepting that it's happening all the time, indeed that a given DNS query is as likely spoofed than good, and nothing can be trusted, or indeed, fixed? If you don't think this can happen to a internet techology, just look at the average inbox now, and compare it to the average inbox circa 1993.

I can't claim to be an expert in this area, but based on what I'm reading, the current "fix" increases the time-to-exploit from 11 seconds to maybe 1 week. (BTW, is there a reason why DNS servers are caching in-baliwick responses.. would it work to entirely disable that caching? Any chance for a second round of more targeted fixes now that the cat is out of the bag?) Also, I get the impression DNSSEC will never be successfully deployed, barring a miracle. And we seem to have just run out of miracles.

So, the good news is that I'm the only one who will be flooding planet Debian by upgrading ikiwiki. Bad news of course is that I didn't notice the bug until I was testing the new release in my own blog. :-)