Interesting, two ultra-long-term goals of mine were finally wrapped up today.

First, we have this:

joey@kodama:~>madison boot-floppies
zsh: exit 1     madison boot-floppies

Thanks to oldstable being moved to archive.debian.org, the ugliness that had kept the boot-floppies source around in unstable is finally fixed and I can finally finish forgetting about them.

Second, the /usr/doc transition tracking bug is finally no longer blocked by any unfixed packages. The only remaining piece of that long-delayed transition seems to be removing the now hopefully empty /usr/doc directory itself.

Marc, I disagree. Solving every issue and whim that every user files against a popular package, while not letting the package degenerate into a mess, is hard. Taking some time to gather opinions and produce a well-designed fix that strikes to the core of an issue, rather than treating symptoms, is a good thing for many classes of bugs. (Other classes should instead be fixed immediately.)

The existence of many open bugs against a package in Debian is not an indication that it's of lower quality than the corresponding package in Ubuntu -- which in fact probably has 99% of the same bugs anyway.

As a user, I also regard a BTS as perhaps the best form of documentation there is about real-life problems that I might encounter while using the package, the general quality of the code in the package, etc. It's the first thing I look at when installing some new peice of software. It's also a good way to gauge how well the package is maintained -- not by counting bugs, but by reading how the maintainer responds to bugs.

What I look for in a BTS is an indication that the maintainers care about a bug. The fact that Debian bug #725 took ten years to get fixed doesn't mean that X's maintainers suck, it means that for ten years, we were able to document a minor problem to the few users who cared about it, and that we were able to keep track of it until someone finally figured out how to fix it. That's quite an accomplishment.

Another example, to keep picking on X, the fact that Debian bug #216933 is marked wontfix is not an indication that the bug is worthless; in fact the bug documents a quite subtle issue in the Crusoe's code morphing software, and has been an invaluable reference to a lot of Crusoe users.

I'm much more concerned about all our users who don't know about the BTS and are unwilling to bother to file bugs than I am about the total number of unfixed bugs in the BTS. Getting 100% of our users to file good bugs on every issue they run into would do much more to increase the overall quality of Debian than fixing every > 1 year old bug in the BTS would.

On a real cooking kick right now. For some reason I felt this strong urge to download and watch Iron Chef shows, which I'd not seen in years. In between watching those, I've been cooking quite a few things, nothing directly related to the shows except for mapo tofu. I've got untried dishes in the fridge, which is very unusual for me, but then I don't normally cook at 11 pm either..

So for the whatever's-available-in-Joey's-fridge battle, the menu is:

• mapo tofu
• frozen yogurt with clementine infused chocolate sauce
• rice salad with balsamic parsnip and carrot garnish
• paprika fried baby squash rings and green beans (planned)

If anyone else reads Planet Debian upstream and wonders where it went/why the flood, it's been broken for about a week, just noticed and fixed it.

I've also switched it over so that only OpenID can be used to log in and edit it, FWIW.

Sometime this month, debootstrap turns six years old. I was thinking about this last night as I tweaked a new xen instance that the hosting provider had installed Debian on using debootstrap, while in the other window using a debootstraped system to investigate a weird apt premissions problem. All very standard, and between this kind of thing, installing Debian with d-i, and building packages with pbuilder, a lot of us would be lost without debootstrap now.

The story of exactly how it came about is interesting, though it's blurred by time in my memory. Maybe AJ will correct me, but I think it went something like this:

• Aeons ago, every Debian system was bootstrapped using a root filesystem tarball, which was built using the basedisks.sh script in the boot-floppies source. That ugly thing hardcoded a bootstrap sequence that managed to work most of the time, and had a lot of code to work around issues in various packages in bae. IIRC it needed a local mirror, and lots of babysitting to keep it working.

• When I suggested that boot-floppies be rewritten, and modularised, I'm fairly sure that I pointed to basedisks.sh as one thing that would make a useful standlone module, but I can't find proof of that.

• In late 2000, AJ posted to a thread about one of the first d-i demo systems with something he was calling "base-deb", that is a recognisable prototype of debootstrap. It downloaded debs from a mirror and built a chroot on the fly.

• After some back and forth over the next couple weeks regarding how it would work with d-i, AJ released the first version of debootstrap on January 30th.

• It's sorta hard to believe now, but there was a lot of push-back on the idea of bootstrapping Debian on the fly, rather than using the old tarball. Much of it was inertia; some of it was legitimate concerns about whether it would work robustly. IIRC these concerns kept coming up right through the release of woody in 2002, the first version of Debian to install using debootstrap. In fact, woody still included a basedebs.tar, although it was built using debootstrap.

• While various rough edges were filed off over the years, there were no really big changes after that to debootstrap until 2005 then debootstrap finally got smart enough to resolve dependencies, rather than using the hardcoded lists of what packages to install in what order, that it had inherited from the boot-floppies.

Debootstrap is one of my favorite examples of a tool that ends up being much more general purpose than was first envisioned (at least by me; AJ may have known all along). The collection of stuff that has grown up around it and the way it's changed how both Debian developers and users work is pretty impressive.

Prompted by a friend who finds a dialup internet connection about as appetising as being food for mosquitoes, I thought I'd share some tips for using the current internet on dialup.

It's easy to say that dialup is dead, but I've transitioned from dialup to broadband and back something like 4 times so far, and since I don't want to rule out spending time in the middle of nowhere in Costa Rica, or at McMurdo, or in an RV, or in a Bigelo orbital hotel, amoung other dream destinations, I don't let availability of bandwidth deter me.

Here's some habits you can learn to lessen the pain:

work local

This is the most important thing. ssh is great, but latency sucks. If you need to edit a file on a remote system, edit it locally, and copy it across. Since I keep most of my files in subversion, I edit it locally, commit it, and update on the remote machine. If ssh isn't appropriate, use rsync or something.

Editing files is just one example; I try to avoid doing anything on a remote machine if I can do it locally. For example, even though an irc client in screen on a remote machine is a nice setup, it's to be avoided on dialup. Another example is using offlineimap to download your mail, so you can read it locally.

Yet another example: I have all my projects scripted so I can make a complete release with just single locally ran command, that goes off and automatically triggers everything that needs to happen on the server. Same for blogging, and for making changes to my wikis.

cache everything

This is an obvious one, but worth mentioning.

The most important cache is probably actually a caching dns server. Dns lookups are an easily missed slowdown (true even for many cable/dsl connections). Other useful caches include a squid web cache, and a shared apt cache.

Also get in the habit of squirelling files away, instead of deleting them, to avoid re-downloads.

know your traffic

Look at everything that causes internet traffic, and turn off the fluff. Even the small fluff will make a difference on dialup. This includes turning off VPNs, not keeping chat programs running in the background. If you're not currently using irc, close it. Use a remote irc proxy server to cache messages while you're away, to avoid missing anything. Avoid sitting on web pages that refresh or stream content. Keep iftop running all the time, and know what all the sources of traffic on it are. You can easily waste 25% of a dialup pipe with fluff if you don't keep it under control.

downloads are batch jobs

Learn to treat downloads (and uploads) as batch jobs that go on in the background or overnight. Don't let your work be blocked waiting on a download if at all possible; don't sit staring at the screen every time a five minute download pops up; go do something else instead. When possible, try to anticipate what you'll need and download it the night before.

Set up a remote download queue, of things you want to download at some point, sorted by priority, and rsync from it as a batch job overnight or when you don't need bandwidth for anything else. If you upload a lot of stuff, set up an upload queue too.

don't try to do everything on dialup

Some things are just not appropriate for dialup. There's no point in trying to download CD images, or much music, or apt-get dist-upgrade, or watch the latest videos on YouTube, or whatever. Even things like Google Maps are just not designed for dialup; the one square you want to see is always the one that will fail to download while the other 8 squares slooowly download in parallell. And AJAX sucks. So avoid this stuff on dialup, don't frustrate yourself. Schedule pit stops where there's high bandwidth to do this kind of thing.

Find alternatives you can use while on dialup -- use old fashioned mapping services, and instead of pursuing the latest and greatest videos, download an e-book -- a whole book downloaded in just 5 minutes -- who said this dialup was slow?

discussion

I'm up in Charlottesville this week at work -- after over a year, it's nice to spend some time in the office, and Cville is a nice town to visit. Over at the Gravity Lounge last night, we got to hear the fiddle-bow-destroying Wilders and the Red Stick Ramblers. A real treat in such an intimate and relaxed setting.

Number of ports used on the 6 foot long, 24-port power strip now bolted to my home office's wall: 17

Number of ports blocked by wall warts, despite the 1.5 inch separation between each port: 3

Free ports: 4

Urge for power over ethernet or USB for everything: uncountable

Number of obsessive-compulsive blog posts: One more than before. (You think I keep count of them too?)

discussion

Today Robert Millan announced http://goodbye-microsoft.com/, which makes loading and booting d-i from Windows easy.

These screenshots show how it works, and I like this one especially:

The Windows program is even compilable from Debian, so this can be wrapped up into a Debian package and go into the official archive eventually. Gorgeous.

Update: slashdotted -- screenshot mirror here, front page mirror here

discussion

This is something I do when I'm working on a hard or perplexing bug. I'll write down a verbose description, as if I'm describing the bug to someone, or having a conversation with myself. I include all the debugging data I find, as I come up with tenative hypothesis, write them down, as I disprove them go on to say why that hypothesis failed, etc.

I just dealt with an OpenID signin bug in ikiwiki, which ended up being several hundred lines of text descibing my process for solving the bug, including amusing blind alleys involving a sha1sum implementation being broken (it wasn't).

And then I committed the one line fix, and :q!'d out of the buffer containing my bug solving log, because all that text now seems both boring, and, given the cause, embarrasing..

Anyone else do that?

It has its good and its bad points. I suspect most of the time that I spend typing into the log, I'm also spending organising my thoughts, and it makes sure that all relevant debugging information is all in one place and well organised to look at, and avoids me looping back into blind paths that I've visited before. On the other hand, I could probably go read a book (or in some cases, an appropriate man page :-/) or sleep and process the bug in the background without all that typing.

discussion