Spent last night halfway up Holston Mountain in what I call Bear Meadow, since I saw a bear the first time I was there.

I haven't been backpacking or otherwise rough camping in years.

Random tech note: Last time I backpacked, a GPS was fairly new tech and IIRC rather big and bulky in its own device. This time, GPS and camera ability were a given; even my flashlight was just another program to run; and when I used it I had to turn off the network to stay away from it all.

So, Debian is still trying to decide if it likes upstream developers including debian directories in their source. Unlike the rpm world, where including a spec file in the tarball is expected, there has historically been some dislike about this being done on the deb side, mostly because of tool limitations.

In the meantime, an interesting thing is happening in the wider world. Developing "apps" for mobile phones is appealing to lots of developers. And in an inversion of the linux distro status quo, part of making such an "app" is packaging it. Typically, for linux-based phones, into a .deb package, or something very close to it.

• For Android, there is apparently a aapt tool that is used to generate .apk files. These are a zip file with some metadata.
• For the Palm Pre, there is a palm-install command that is run in Windows, and generates a control file and builds a '.ipk' that is really just a (limited) .deb.
• For the Nokia N900, this describes cargo-culting debian/rules, debian/control, and debian/changelog files to build a standard .deb.

Since N900 apps can fairly easily be ported to/from desktop linux, I won't be suprised if debian directories start popping up in lots more upstream sources. Like it or not.

In May, Frans and I worked on making a code swarm video that covers most of the history of commits to debian-installer. Then at DebConf, Christian bravely gave a short presentation of the video, with witty commentary. Here I've combined the two, so we have Christian's commentary, with video that allows reading the names of the committers.

Click image to play. (Also on vimeo).

In Spain this summer, I gave a talk about new features in debhelper. It seemed to help a lot of people get started. So if you were not at DebConf, this is your chance to learn about dh, overrides, addons, and mimimal rules files.

(low quality | higher quality)

The audio gets much better half-way through, and slides become visible. (We all also wake up a bit midway through -- it had been a late night!) The full slides are here.

Wonderful day on Roan Mountain, kiteing, blueberries..

Only could have been improved by The Ridgewood Barbeque being open, and my cellphone camera handling exposure more consistently for the above panoramas.

The Debian Installer has a USB boot image that is supposed to be written raw to the USB stick. Problem is that means the image has a fixed size, 256 MB, and all the other gigabytes on your typical USB stick are unusable after writing this image to it. It's a bit of a cheat for me to blog about this, since I'm slighly responsible for the thing that I'm working around. But still.

The real problem is not the fixed size of the image, but that it is written to the USB stick as a "super floppy", without any partition table. If there were a partition table, you could make a second partition in the rest of the space of the USB stick, and use it to store files, etc. So, let's set that up. It's not really hard:

1. Use your favorite partition tool to partition the USB stick. Make a 256 MB DOS partition, that will be used to hold the installer, and set it bootable. Make a second, or more partitions for your own use.
2. Unplug and replug the USB stick so the device files show up, and write the installer image to the first partition (/dev/sda1 in this example). zcat boot.img >/dev/sda1
3. Make the USB stick bootable by installing the mbr package, and running install-mbr /dev/sda
4. Copy a Debian ISO image to the USB stick somewhere. You can put it on the first partition, as ususal, or if you prefer, can put it on one of the later, larger partitions. That's useful if you want to use a larger ISO than the netinst. The installer should find it anywhere.

Hauled this stove into the yurt today, across a creek that was flooded yesterday.

Putting a stove in a space changes/refocuses it so much.

I was thinking about how I often end up in a directory path where the names of one or more components repeat. It seemed there should be a name for when this happens.

/home/joey/src/ikiwiki/doc/ikiwiki/
/home/joey/src/pdmenu/src/
/home/joey/src/joeywiki/joey/
/lib/modules/2.6.26-2-686/kernel/lib/
/proc/1/task/1/

Then I realized there was a name already: Fractal. While directory structures are supposedly hierarchical, different levels in the hierarchy are self-similar, and so sometimes the same name is duplicated, with a subtly, or vastly different meaning, at different levels in the same directory path.

I had wondered if we were doing something wrong, that this happens so often. It is occasionally confusing. But aside from using a deep, nominally hierarchical directory structure, and displaying a slice through it (as if talking about electron orbitals in a rock orbiting sol), I don't think we're doing anything wrong.

Here is a oneliner that will find all such directories inside a specified start directory. You will probably find some amusing ones you've never noticed.

perl -MFile::Find -le 'find(sub { if (-d $_) { my %bits; foreach $bit (split "/", $File::Find::name) { if (++$bits{lc($bit)} > 1) { print $File::Find::name; return } } } } , shift || ".")'