More updates:

* I can now walk to the mailbox on my own, and I only need to rest once on the way.
* I'm generally leaving the walker alone. It causes me more grief than it solves.
* I feel confident making the three steps up and down the balcony - which is good because the main doors are still too heavy for me.
* I've had a shower. I smell much better.
* We're starting to take visitors now - Jim and Sarah were here last night, Andrew and Sarah are coming tonight. It'll be nice to feel a little less isolated.
* I haven't spoken to my dad in a couple of days, but they were still scheduling his angiogram when I last spoke to him. All the walking and stuff that I've been doing means that I'm spending the balance of my day sleeping, so hopefully I'll catch up later today.

At this point, I'll probably post updates a lot less frequently, because it feels like the initial touch-and-go part is done. I'm looking forward to being off the steroids, and slowly spacing out the medications and such, but we're just in that zone where I'm getting up and around and am just waiting for lifting restrictions and such to be removed.

In the last few days, I've managed to sort out the various school extensions I need, the short term disability paperwork, the DMV disabled sticker paperwork, and all that.

Phone calls are much appreciated - the number is in my Orkut and Facebook profiles, it gives me a chance to interact with people and I'm starting to worry that I have too much time and am bothering the ones I talk to al the time. I'm still quite behind on emails, mostly because typing on the blackberry gets to be a bit much after a while.

I suspect I'm about to go into that annoying phase of recovery where nothing is urgent anymore, and we're coping, but we go stir-crazy because I'm not actually better enough to interact with the world yet and Angie still has to do almost everything for me. Any suggestions on making that part of the recovery suck less are appreciated! I've watched it a pile of times, but everyone seems to forget about it (including the people going through it).

Sunrise is 7:11 here this morning, I think I'll try to sit outside for it.

Oh god, sometimes I HATE life. Like right now. In train, back home from work. Short after the train started it stopped. Long time nothing, then an announcement:

 This train stopped due to signal box problems in front of us

A little later a similar announcement, now adding

 We cant go back and take another route, as we have trains behind us, also waiting.
It is unknown when we can continue.

GAH. HATE. What I especially hate is the fact that TODAY I LEFT MY POWER CONNECTOR FOR THE LAPTOP AT HOME, as I had so much other stuff to take. FUCK YOU, LIFE!

I first read about Metblogs when Matt wrote about the new design and the move from one publishing platform to another. Metblogs is now based on a multi-user installation of WordPress. The idea behind this collection of blogs is that you can take back your local media. Read about a small club in Paris named La Fleche D Or, the E train and Q 39 Buses in New York City or a photowalk in Chennai. Metblogs covers local issues in over 50 cities around the world.

We are bloggers first and foremost, and we love our cities. Even the parts we hate.

A new city will be launched when ten or more bloggers from that area are commited to the site, and willing to contribute. Author slots on existing city sites are given to people on an invite only basis. If your local media does not want to cover the opening of a new chocolate factory, then you can do it. You don’t need to blog on metblogs to do just that, though. Every big site has a few flaws here and there, and Metblogs is no exception. On the list of what to fix is the problem with the sites being too wide, the fonts are either too big or too small and some links are broken. I have my own, but very short, list of changes I would like to see on metblogs.com. The link to visit a random city should be placed somewhere more visible to the reader, and the link to the author of a comment should point to the author’s profile.

I was just editing a file with vim and was about to do the same few strokes repeatedly. I vaguely remembered something about recording macros, so I tried it: I pressed q-1 to start recording, did my steps (a yank, a movement, an insert, a paste, a movement), and finished the recording with q. Now I could repeat these steps with @-1.I then noticed that I forgot something at the end (moving the curser to the beginning of the line). I re-started recording (q-1), thought hey, maybe I can insert the old recording here and pressed @-1. Surprisingly, that worked. I added the missing movement and finshed the recording with q.When I then tried to recall these commands with @-1, the editor froze and I was wondering whether the network connection went down (I was working over SSH). But it wasn t, and it dawned me that vim did not insert my old commands when re-recording the macro, but just inserted the call to the macro itself. My text editor was caught in a infinite loop...Not too bad, I just killed vim, did not lose anything and everything was fine. But I think an editor, even vim, should somehow prevent such behaviour.

It's funny sitting down to finally write something on LJ and not being sure what to write. I can tell stories of Angie's mom coming to support her and giving me time with my wife. I could rant about students putting in some of their first IVs (or not, actually since after the third try I got bitchy and she ran away. Literally. Oops.) I could talk about recovery, the joy that is delaudid, the devil that Valium turned out to be, or wonderful nurses who were so helpful and encouraging (and the ones who bent the rules and let me see Leif on his first year birthday) or the ones who lied, failed to check in on me and left me in distress for several hours.

On the whole, the people and experience were very good. From almost immediately after I woke up, things have been better. I hadn't realized there was pain associated with all this until it was gone post-surgery. The numbness is still there, but better that it was before by a long shot.

I do want to make sure I say thanks for all the energy, thoughts, and prayers. I felt good on Monday going in with the power and energy of literally hundreds behind me. Religiously, I have a complex relationship with this stuff, but I believe that at moments where a yes or a no gets to be decided by luck or external unknown forces, this can really help the answer be a yes. And I think we'd be surprised at how much of life fits into that category.

There are lots of emails and posts I haven't replied to yet. My lifting restrictions are such that I can't pick up my laptop. So if you see emails or LJ posts from me, its been typed on the iPhone or the Blackberry. Same with the instant messenger. I have my status set to "do not disturb" when I'm around so that I don't exceed my ability to type by getting into talking to too many people at once. My lifting restrictions continue for the next 6 weeks.

That said, I do enjoy chatting and writing. It just takes a while and is quite tiring.

I haven't figured out how to upload pictures to flickr such that the pictures are public, but that are not forced onto people who just wanted to see pictures of Leif. :)

Tired now. If there is any particular part of the surgery/recovery you want details on, let me know and i'll write about it.

*hugs and love*
Jeff

This October, our church celebrates its hundredth anniversary. All this year, every so often, we are having brief "historical moments" during church.

Today, our temporary choir director -- and my high school band teacher -- was a Vorsanger. He got up during church and discussed how hymn singing was done in the early days of the church. Today, our Mennonite church sings in a variety of styles, most commonly 4-part music accompanied by a piano, and no director. But we also sing more "contemporary" styles.

Back in the earlier days, the church didn't have hymnals with music for everyone. The Vorsanger -- song leader -- would sing each phrase, then the congregation would sing it back in unison, throughout the whole song. Hymns that the congregation already knew well would just be sung normally, in unison, with the Vorsanger directing.

Not only did the Vorsanger lead the singing, but he or she also chose the music -- not the pastor. As the church purchased first a pump organ, and later a piano, the instruments would sometimes be used to accompany the singing. The musicians never knew what would be sung in advance. One 80-year-old member of our congregation remembered the she started to play for church at 8th grade. But much of the time, there would be no instrument, not even to pick the starting pitch.

This morning, we sang Holy God, We Praise Thy Name with the Vorsanger. It's a familiar song in our church, but we generally sing it in English. The Vorsanger taught it to us in German, the older people in church would have remembered it. He finished his introduction, stepped away from the microphone, and rang out with the first phrase.

Gro er Gott, wir loben dich

Then we all sang the phrase back to him, in unison. On to the next phrase, back and forth for the rest of the hymn. Terah and I were in the choir area, behind him, but could hear him -- and the rest of the congregation -- just fine.

At the end, our Vorsanger for a day said he thought we got it, so we sang through it again, still in unison, but without him leading us on each phrase.

Gro er Gott, wir loben dich,
Herr, wir preisen deine St rke,
Vor dir beugt die Erde sich
Und bewundert deine Werke.
Wie du warst vor aller Zeit,
So bleibst du in Ewigkeit.

What a powerful way to feel connected to the people that worshiped at the same place so many years ago.

As our director said before we sang in choir this morning, music can say so much more than words.

dpkg-cross updates
uploaded to Debian unstable

   * General support for querying endianness of an architecture.

   * Update standards version (no changes)

   * Add Cvs-CVS field to debian/control

   * Reinstate detect_arch for improved build test checks in emdebian-

     tools

   * get_endianness: new function for Emdebian TDeb support

This provides support for architecture-dependent TDebs in Emdebian as well as adding detection of armel.

emdebian-tools 0.8.3
Uploaded to Emdebian

   * Interim Emdebian release.

   * emsecondstage: ensure cdebconf environment is setup before

     configuring packages

   * emdebian.gpe: Add extra packages needed to allow the gpe package set

     to boot.

   * Emdebian::Tools, (create_patches) : skip generated files.

     [*.debhelper, *.substvars, files]

   * em_installtdeb: support special modes via debian/xcontrol

   * Support unpack method in basic emsandbox rootfs

   * embootstrap: continue after some errors

   * Support unpack method in gtk emsandbox rootfs

   * Simplify basic empdebuild chroot and copy in hostname files

   * empbuilderlib: add support for creating skeleton versions of

     /etc/group and /etc/passwd.

   * empbuilderlib: add an approximate time set func for use when no

     network is available.

   * emsecondstage: configure cdebconf before others so that the database

     is ready

   * embootstrap: use the new support in empbuilderlib for group, passwd

     and date

   * Add --arch support to em_installtdeb

   * Depend on new support in libdebian-dpkgcross-perl

   * empdebuild: force the -S argument to apt-cross to prevent

     intermittent failures

   * empbuilderlib: parse the .list contents from dpkg

   * embootstrap: ensure buildplace is clean before starting a fresh

     debootstrap

   * emdebuild: use dpkg-cross support for detect arch to distinguish

     between arm and armel binaries

   * Emdebian::Tools. add parse_xcontrol function for easy queries of

     debian/xcontrol

   * pbuilder/emdebian.crossd gpe gtk : Tidy up the scripts with routine

     calls to the empbuilderlib library

   * pbuilder/empbuilderlib: Add some common routines to help make the

     rootfs bootable

   * pbuilder/emsecondstage: bring into line with other changes in the

   * empbuilderlib.3 : Add a manpage for the expanded set of common

     functions in empbuilderlib

   * Suggest file-roller for inspection of rootfs tarballs

   * emdebhelper.mk: sync with recent changes in CDBS for debhelper

     support

Reasoning
OK, so why upload emdebian-tools to Emdebian when it depends on the update to dpkg-cross in Debian?
Well, emdebian-tools is becoming a bit of a behemoth. I mean a package that has only existed for 12months and has had over 30 releases, increasing in size from 30kb to over 500kb (without counting dependencies) and which encompasses a gammut of scripts with different roles is just begging for a functional package split.
Package splits take time - not just the time in NEW but all the testing to ensure that each split can be installed separately without falling over "Unable to find foo in @INC" etc.
At the same time, emdebian-tools is both rapidly developing and becoming remarkably stable (which gives some indication of just how diverse it has become).
So I'm heading for a 1.0.0 release before Lenny and to achieve that, I want to split it:

1. emdebian-tools - umbrella package consisting of the core build scripts (perl) - these are becoming quite stable - that depends on all the others.


2. emdebian-archive-keyring - tiny package that just implements SecureApt for the Emdebian repository.


3. emdebian-rootfs - the rapidly developing (shell and perl based) root filesystem management scripts, based on debootstrap and pbuilder.


4. libemdebian-tools-perl - a standard perl module of common functions for the other packages.

This allows people to use the toolchains with the smallest package, prepare root filesystems from prebuilt binary packages with just three of the four and only those who build packages will need all four.
So the plan, overall, is to keep updating emdebian-tools in Emdebian unstable during the time that emdebian-tools 0.9.0 goes through NEW in Debian. Then, when 0.9.x is in testing and any issues from the split are resolved, 1.0.0 can be uploaded to Debian.

Package split issues in general
Something that bugs me with package splits is this stable vs development issue within the same source. I think it would be sensible to only upload emdebian-tools (the stable bit) if it changes but to upload emdebian-rootfs as often as necessary whilst still building from the same source.
This issue will also bite when Emdebian deploys other functional package splits and seeks to improve apt itself to handle many, many more binary packages.
It's also a similar idea to allowing translators to upload TDebs separately from normal package updates.
Why should I have to split the source in $RCS in order to upload package splits separately? Other upstream teams won't do that so Debian needs a solution.
Why should users have to download emdebian-tools 1.0.1 which is absolutely identical to 1.0.0 just because emdebian-rootfs needed lots of updates in 1.0.1. (Remember, emdebian-tools will depend on emdebian-rootfs so when emdebian-rootfs is updated, all users of emdebian-rootfs and all users of emdebian-tools will get the update. Yet I don't see why emdebian-tools itself needs to be touched.)
It is plain daft.
I've seen similar issues in other environments where, for various very good reasons, users need to limit the bandwidth and duration of apt downloads. For Emdebian, we also need to limit the total amount of data downloaded by apt-get upgrade simply because free space on the device can be severely restricted - my target device will have about 7Mb free space and that is regarded as "under-utilised". Downloading an entire package just to update /usr/share/foo/changelog.gz in such circumstances is just plain stupid. I know we can do better than that.
Apt needs to become much more intelligent and have a way of only downloading the changes in packages instead of the entire .deb - something along the lines of an rsync method. To get that working, the actual package names need to be munged so that rsync can compare foo_1.2.3-1_all.deb against foo_1.2.3-2_all.deb by having both symlinked as foo_current_all.deb. (dpkg-name can restore the original name if needed.)
Such a method must be possible and would have enormous benefits for packages like OOo where each upload can't be changing 100% of the code each time, yet we all have to download Mb after Mb of content that is identical to what dpkg is about to replace.
Am I just ranting or does this strike a chord on the lazyweb in general?
The slowest part of many desktop experiences of Debian could well be the time taken to download updates - not everyone has multi Mb broadband.

OCaml(Core) GForge enters beta testing status Since a few weeks we have set up a team of people which is working on offering software services for the OCaml community, which in this respect has been lagging behind other programming language communities for too long. By chance, the team has turned out to be composed by Debian DDs and contributors (Sylvain Le Gall which is leading the effort and also offering hardware via his new company, Pietro Abate, Romain Beauxis, and myself). The name of the project is OCamlCore. A few weeks ago we announced the availability of an OCaml-related planet, which since yesterday is also being advertised on the resource page of the language. The other relevant service we are setting up is a forge for hosting OCaml-related software projects. Yesterday we have finally announced the beta testing of the forge, which is available at http://forge.ocamlcore.org. We are now looking for people which has a OCaml-related software projects which want to go to a forge or want to migrate there, and are willing to help us in discovering and fixing potential pending issues. If you are interested please read the announcement, register to the forge, and submit the project request. Please state explicitly in the project description that you are aware of the current beta testing status. Your help is needed and will be very much appreciated!

So I was impatient enough and took a stab at writing a bzr frontend for git-fast-import(1). (By the way, the idea behind git-fast-import rocks, and is being adopted by other projects, e.g. bzr-fastimport.) I announced it here, and for now it lives in:

http://chistera.yi.org/~adeodato/tmp/other/bzr-fast-export.git

Often if you see a block diagram like this, what comes to mind is a compatability layer in between a program and several operating systems. Generally something that's general-purpose like java, or a web browser, or a widget toolkit.

-------------
             
             
-------------
             
-------------
             
-------------

(Generally it's drawn up all purty, but I'm lame.) But lately I've seen and written a lot of code where the diagram is more complex:

-------------
             
   program   
             
             
-------------
  V  C  S    
-------------
     OS      
-------------

Sometimes the program code is littered with multiple switch statements, as in debcheckout, debcommit, and etckeeper.

case "$vcs" in
git)
svn)
hg)
esac

Sometimes it pushes the VCS-specific code into modules.

use IkiWiki::Rcs::$rcs;
rcs_commit();

But if it does, these modules are specific to that one program. This isn't a general-purpose library. dpkg source v3 doesn't need to use the VCS is the same way as ikiwiki, and even ikiwiki's rcs_commit is very specific to ikiwiki, in its error handling, conflict resolution, locking, etc. pristine-tar injects and extracts data directly from git, using low-level git plumbing, in a way that probably can't be done at all with other VCSes. But even as I was adding that low-level, very git-specific code into pristine-tar, I found myself writing it with future portability in mind.

if ($vcs eq 'git')  
    # git write-tree, git update-index, and other fun
 
else  
    die "unsupported vcs $vcs";
 

When Avery Pennarun talks about git being the next unix, he's talking about programs like these, that build on top of a VCS. But if git is the next unix, then so is mercurial, so is darcs, so is bzr, so too even svn (unless it's Windows?). In other words, we're back to the days when every program had to be ported to a bunch of incompatible and not-quite-compatible operating systems. Back to the unix wars. In Elija's discussion of the "limbo" VCS state he gives several great examples of how multiple VCSes that each seem on the surface to offer similar commands like "$vcs add" and "$vcs commit" can behave very differently.

echo 1 > foo
$vcs add foo
echo 2 > foo
$vcs commit

What was committed, "1" or "2"? Depends on which $vcs you use. Compare with unix where open(2) always opens a file, perhaps with different options, or different handling of large files, but portably enough that you generally don't need to worry about it. Even if you're porting to Windows, you can probably get away with a compatability layer to call whatever baroque monstrosity Windows uses to open a file, and emulate open(2) close enough to not have to worry about it most of the time. A thin compatability layer that calls "$vcs add" isn't very useful for a program that builds on top of multiple VCSes. mr is essentially such a thin compatability layer; it manages to be useful only by being an interface for humans, who can deal with different limbo implementations and other quirks. The VCSes are to some degree converging, but so far it's mostly a surface convergence, with commands that only look the same. Where will things go from here?

• Maybe there will be a standardisation effort like POSIX for VCSes. Though it seems harder; VCSes have a wider interface than just syscalls and filesystems, so there's more scope for incompatibility.
• Or will complicated compatability code like cygwin be developed, to let a program that was written for git use bzr instead, carefully hiding all the differences?
• Another option would be that one VCS wins. So far I'm seeing some consolidation, but little indication that one VCS will emerge as the choice for everyone.
• Maybe the VCSes might begin to support each other's repositories. If a program only supports git, and you use svn, that's fine, if git can transparently access the svn repo.
• Or will we go on for decades spending a lot of time on portability code?

Between February 29 and March 4, 2008 I attended the Sage Days 8, hosted at the Enthought headquarters in Austin, Texas. This was my 5th time in the USA and it was a marvelous experience, as with all my visits in the states.

As usual, I had some adventures in Atlanta, that interested readers can find at the end of this post. Anyway, on the Austin's airport I met Peter and his wife Crystal, Fernando, Benjamin, Jarrod, Eric and Clement. We went to have a dinner and then me and Clement were staying at Peter's house:



You can see the neighbor's cat and Peter's dog Trinity behind the window. The next day we went to Enthought, that was providing us with a breakfast and a lunch each day - and it was delicious. After the breakfast, we gathered in the room and introduced ourselves. Enthought rents 3/4 of the 21th floor in the Bank of America building, so when I looked left I saw:



When I looked behind I saw:



and in front of me, I saw all the participants (I took photos of all participants together with names). As you can see, there were really good people in there, like Travis (creator of NumPy), William (main author of Sage), Eric (CEO of Enthought), Fernando (author of IPython), Jarrod (the release manager of SciPy), Michael (the release manager of Sage) etc. See also the Fernando's welcome speech and the video of each of us introducting himself.

The views from the windows are terrific. I enjoyed working on each of the 4 sides of the skyscraper with completely different scenery, or when the sun is going down, that's also very cool.

We spent the whole Friday doing presentations, some of which you can find here. Then we went to Eric's house to have a big dinner together.

On Saturday, Sunday and Monday we were all hacking on many different things. I joined Fernando, Benjamin, Brian and Stefan on ipython1, Travis was implementing a new type (gmp integer) in NumPy, William wrote a manipulate command in Sage, Eric did the same in Traits, Gary and Michael implemented parallel testing of Sage, ...

On Tuesday we had final status reports and people left in the afternoon. In the evening we went with Clement to have a dinner and then we visited some bars on the 6th street, having a beer in each.

On Wednesday I visited John and Roy from the Computational Fluid Dynamics Lab at the University of Texas, Austin, who wrote the libMesh library, that I extensively used and also created a Debian package of. It was very influential to see the libMesh "from behind", also John and Roy are cool people (not mentioning the Debian tradition of having good relations with upstream:). Then I visited some professors at the same campus, after which I went into the Capitol and then I took the bus to the Barton Creek Square Mall to buy some ipods and jeans, so that I can say I have jeans from Texas. BTW, the ipod works excellent in Debian - I plugged it in and it just shows on my Gnome desktop. It's true that naively dragging mp3 files on it didn't make it play, but these instructions made it work.

On Thursday I fixed the remaining release blockers in SymPy and made a new release. In the evening, I am going to meet Aswin, he also uses SciPy and also is a friend of Kumar, who is now maintaining python-numpy and python-scipy Debian packages with me (Kumar also knows Prabhu, the author of Mayavi2 hosted at Enthought, so it's all connected).

Anyway, the whole workshop was an excellent experience for me. I learned a lot of new things and being able to speak with people who wrote tools that I use almost everyday is important. We also extensively discussed the future of all the projects (Sage, SciPy, NumPy, IPython, Cython, SymPy). See my summarizing email to the SymPy mailinglist.

Another thing, that I find very interesting is that Microsoft is financing the windows port of Sage, that will make basically anything that uses Python/Cython/C/Fortran very easy to install on windows (just a spkg package in sage). I find it really cool that MS is not only supporting but even financing a truly opensource project.

Finally the promised adventure in Atlanta: we took off the Prague airport on February 28th with a 2 hours delay (due to some paperwork as we were told by the captain). As I had 3 hours in Atlanta for the connection to Austin and I had to go through immigration, it was clear that I'll miss it. But I was not surprised, last time I was flying through Atlanta, they canceled my flight to LA completely. We arrived in Atlanta an hour and a half before my departure, then I was waiting for about an hour at immigration, it was incredibly slow. When I had around 20 min to departure, I had to ask people standing in front of me if they let me in, they were very nice and did. I was leaving immigration 10 min to my departure, then I was running to get my luggage and myself through customs and screening, it was 5 min to my departure when I ran down to the display with departure times. Then I was sprinting like hell to the terminal D to only see the clerk doing some final paperwork with all the people already boarded and the jetway door shut. After a little persuading he let me in too, fortunately there was still one seat left, so I made it. You can imagine my pleasant surprise in Austin when I discovered, that my luggage made it too, considering that I handed it to the Atlanta's airport personnel exactly 10 min prior the departure.

Many of you have seen the net classic If Operating Systems Were Airlines. Today, let's consider what the world might be like if version control systems were airlines...

Before anyone gets mad, this is all in fun, OK?

RCS Airlines: One of the first airlines, from way back when this whole aviation thing was new and exciting. Each RCS flight carries exactly one passenger, which RCS believes is a superior way to fly. Although most RCS airplanes are rusty and battered today, RCS Airlines still retains its historic dedication to security. Each airplane is kept locked as much as possible for safety. Occasionally flights will be delayed for hours because the pilot can't open the locked plane. When this happens, the pilot will frantically try to get the cell phone number of whoever it is that has locked the plane. When the plane finally gets unlocked, you may be tempted to ask why it was locked for so long. Veteran RCS users have learned that the answer is usually disgusting, and never ask anymore. Main competitor: CP/M airlines.

CVS Airlines: Founded on the belief that they could be more efficient than RCS by carrying multiple passengers per flight. They still carry each passenger in a separate RCS-built airplane, but the airplanes fly in a goose-like ",V" formation. Watch out for layovers, though. It can take hours to merge new passengers into the formation properly, and it might take several attempts to take off afterwards.

CVS flights often feature fights over who gets to fly. CVS piloting fights are legendary; rumor has it that OpenBSD got started after CVS airlines refused to allow a passenger to board on the grounds that he had in the past refused to stow his tray table in the upright and locked position.

CVS airlines mostly counts as customers the "over-50" crowd who grew up using CVS and don't like change. Its in-flight magazine features advertisements for balding-reversal treatments and uuencode tools.

Main competitor: AIX airlines.

Subversion Airlines: Started by some grey-haired CVS executives with long, wispy beards, Subversion airlines got started by trying to be "CVS, but better". Subversion airlines was the first major airline to use planes that seat more than one passenger. Unlike CVS airlines, all passengers on a Subversion flight travel in the same plane.

Subversion airlines is famous for its Soviet-like centralized control. All operations must be approved by the Kremlin, and you are allowed, by the grace of the Party Leader, to gaze at the massive airplanes. Those that have served the Party and Airline well for many years are allowed to enter the Great Shrine of the First-Class Comitter, and actually make changes to the airplanes themselves. Plainclothes Subversion Airlines security agents lurk on every flight, and you should not be surprised to be thrown out an airplane window if you make a joke in bad taste about the pilot's flying skills.

Subversion airlines thrives on the concept that "photocopying is cheap". You are encouraged to make photocopies of your ticket, or to photocopy your photo ID, and give copies of each to as many people as you can. At checkin time at the gate, if more than one person arrives with a copy of the same ticket, they are ushered into the "merging room" and each person is given a brick. The door is closed, something magical occurs, and the one person that emerges still able to walk is allowed to board the plane.

Main competitor: Windows airlines with no Administrators allowed.

tla airlines: Founded by one of those eccentric British noblemen, Lord Tom's airline is the utopian philosopher's airline. Chafed by the heavy-handed control of Subversion Airlines, tla airlines wants every passenger to be created equal. As you approach the gate area in the terminal, you will find many philosophers occupying the gate area, extolling the virtues of tla airlines. They compare tla airlines to reaching out and touching the heavens, leaving behind the bonds of a ground-based life, actually merging with the stars. Oh, the gorgeous beauty of it all! The things we will see!

As you see people arriving from another flight, you observe that some of them have burn marks. One of them comments that "merging with the stars doesn't work." Immediately, a dozen philosophers get in a fight with him, claiming that he simply doesn't understand what it means to merge with the stars, and that if he gets his inner being in the proper state first, he'll have a much better experience.

As you board the tla airplane, you obvserve that the jetway is a mile long. The airplane itself reminds you of something of a cross between a gothic cathedral and a level of Doom. There are spectacular archways everywhere, sometimes where they don't really belong. Each archway is supported by ornate curly braces which you don't normally see on airplanes, and frankly, you'd rather not, because they look all pointy and confuse the kids.

As you arrive as your destination terminal, you see it too is full of philosophers, most of them dining.

Main competitor: VMS airlines.

Darcs Airlines: Unlike every other airline, this one uses physicists instead of engineers to design its airplanes. One brilliant Darcs physicist has finally come up with The Theory of Everything, and as such, Darcs knows where you want to go before even you do. Darcs airlines prides itself on customer service, and asks your preference for even the tiniest details about your trip.

Each seat pocket features a copy of the Theory of Everything for your reading enjoyment, but nobody actually understands it.

Occasionally, you will find that Darcs pilots get into angry conflicts with the control tower in mid-flight. This results in the control tower revoking your permission to land. Legend has it that one Darcs pilot of a plane with exceptionally large fuel tanks actually resolved his conflict with the tower and landed two weeks after taking off. Experienced Darcs users board with several parachutes: one for themselves, and a few more for the newbies.

The Darcs physicists claim that the Theory of Everything predicted the pilots would act this way, and that all pilots eventually act this way throughout the entire universe. They toil day and night finding a way to adjust the gravitational constant of the universe, thereby reducing the anger factor of the pilots.

Main competitor: OS/2 airlines.

bzr airlines: Founded by a South African who had been injured by a curly brace on tla airlines, bzr airlines aims to be "tla done right". They have shortened the jetway, gotten rid of the curly braces, chased out the philosophers, and no longer have a vision of merging with the stars. Many that were injured on tla airlines fly bzr airlines, and out of respect for tla airlines, bzr airlines will still honor tla tickets.

bzr passengers consider themselves part of an exclusive club because each flight takes off from a launchpad. They often can be seen standing in the terminal passing out bzr literature, trying to get passengers of other airlines to fly bzr, and can't understand how other airlines continue to exist while people keep walking past their airplanes.

Main competitor: BeOS Airlines.

Bitkeeper Airlines: One of the world's faster airlines, Bitkeeper airlines occupied that obscure gate for rich people at the end of the terminal for many years. Tickets on Bitkeeper Airlines were rumored to cost thousands of dollars, and were rare and jealously guarded. Then for awhile, Bitkeeper Airlines started giving away tickets for free, though they also kept around the expensive tickets for those with discriminating tastes. Free tickets were made widely available, but the 3-point type on the back of tickets said that you were never allowed to think about another airline before, after, or during your flight, and some people claimed they actually saw the small print morphing right before their eyes.

Bitkeeper flights often featured arguments over whether people were harboring secret thoughts of other airlines. If you were caught thinking about another airline, you were expected to scream vigorously while being thrown out the escape hatch without a parachute. All of this commotion tarnished the rarified air that the rich people paid to experience, so one day it was decided that there would be a Great Purge, because obviously all free ticket holders had harbored lustful thoughts of other airlines, so they were all thrown off the airplanes simultaneously. Today, people aren't exactly sure where the Bitkeeper gate is, but everyone suspects it still lurks somewhere.

Main competitor: SCO Airlines.

Mercurial Airlines: The "there's one right way to do it" airline, Mercurial is a sterile, agile, and shiny airline. Every Mercurial airplane looks identical to every other one, shiny and clean. You could swear that all the passengers look alike too, and as you approach the gate, it seems like you too look like everyone else. Mercurial passengers tend to be a happy bunch, who can't comprehend anybody that flies Git Airlines. Specks of dirt and dust confuse the pilots, so it is best to make sure you have showered before boarding. It is rumored that, through bolting on more engines, some Mercurial airlines can fly to as many places as Git airlines can, but most Mercurial passengers are content to not worry about that.

Main competitor: Python Airlines.

Git Airlines: The "there's more than one way to do it" airline, Git flies the world's largest and fastest airplanes. Git Airlines was founded by some priests who were flying for free on Bitkeeper Airlines and survived the fall after the Great Purge. Git airplanes start as spartan, empty cabins, with no carpeting, chairs, or piloting controls. At the departure gate, each passenger is handed a bag containing 173 standard airplane components, accompanied by a 4x5" sheet of information on the theory of flight, written in 1950. Once onboard, the passengers use these components to finish out the airplane for flight: installing chairs, rudder controls, etc. Every flight results in a plane assembled in a different way, and passengers on each flight believe they are flying the world's best airplane. Arguments in the terminal after a flight are common, as passengers from different flights debate the merits of their particular design.

Despite all this, Git planes turn out to be safe, and Git passengers believe they get to their destinations in half the time it takes any other passengers, though sometimes they secretly wonder if the Mercurial flight got there faster. Occasionally, passengers on Git airlines build an airplane that appears to go into a tailspin. When that happens, they simply assemble a tool that lets them go back in time and change history so that it doesn't crash, although it is rumored that if you are a member of the public watching this happen from the ground, it will lead to seizures.

Git airlines takes special pride in the one piece that passengers don't have to assemble: the plumbing. Every Git lavatory is equipped with state-of-the-art never-fail plumbing, and the best porcelain washroom fixtures money can buy. None of these cheap plastic toilets like you get on every other airline. Here, we have fine porcelain fixtures.

During a flight, after passengers use the lavatory, they frequently get into arguments with each other about which style of porcelain toilet is the best. These arguments are only resolved by the Zen-like Git Priests, who insist that only inferior passengers need to use a toilet while in the air.

Main competition: Perl Airlines.

ABI changes that break woody chroot. There's some talk on older releases chroots, so I'll add a note. We can't create woody chroots, because 'mmap' behavior on 0-byte file has changed in the Linux Kernel since, and dpkg depends on it. I wonder if people keep older Debian releases (bo, hamm, rex, ??) in virtual machine these days. It's probably not possible to run them inside chroot.

I use the enhanced commentify script from vim.org to easily comment and decomment parts of code. It knows about comment delimiters in a ton of languages, and it’s generally nice. Lately, I’ve been a bit annoyed about commenting several lines with different indent levels. In particular, given for example this snippet:

  def foo():
      if duck.is_hungry():
          grab_food()
          feed_duck()

If one instructs the script to comment the three last lines, the result is:

  def foo():
      # if duck.is_hungry():
          # grab_food()
          # feed_duck()

When what I would like is:

  def foo():
      # if duck.is_hungry():
      #     grab_food()
      #     feed_duck()

There is one variable one can set to achieve this behavior: EnhCommentifyUseBlockIndent. However, it only works when commenting from visual mode. From normal mode (what I normally use — that is, going to e.g. line 2 above, and pressing 3,c), it doesn’t work, because from normal mode the commenting function does not receive the block, it just gets called three times, once per line. To solve this, the solution I found was to create a custom command that accepts a range, and calls the function exactly once, for the whole block. In particular, this is all my enhanced commentify configuration from ~/.vimrc:

  let EnhCommentifyPretty = "yes"
  let EnhCommentifyUserBindings = "yes"
  let EnhCommentifyRespectIndent = "yes"
  let EnhCommentifyUseBlockIndent = "yes"
  " The MyEnhancedCommentify bit is needed because the normal nmap just
  " calls EnhancedCommentify() <count> times, thus UseBlockIndent can't
  " work.
  nmap <Leader>c :MyEnhancedCommentify<CR>
  vmap <Leader>c <Plug>VisualTraditional
  command! -range MyEnhancedCommentify 
      \ call EnhancedCommentify('', 'guess', <line1>, <line2>)

So today is the third anniversary of my first upload of the ISC DHCP v3 package to Debian. It all started back in the days of the linux.conf.au 2005 organising committee. Bob Edwards, who ran the ANU Department of Computer Science computer labs (which ran on Debian at the time), was constantly complaining about bugs like #286011, once he'd found out I was a Debian developer. So I figured I'd try and do something about it, so I think I emailed the maintainers, who had been fairly inactive (the last upload before mine was in July the year before), and asked if they'd like me to NMU the package. I think Matt Zimmerman emailed me back and told me to knock myself out, and add myself as an uploader while I was at it, and well, the rest is history... I've had fun fixing bugs, trying to clean things up, deal with a pretty archaic upstream build system and get the package up to current Debian standards compliance. One of the highlights was being able to finally get rid of Debian Installer's dependence on the v2 DHCP client package, so we could finally jettison the v2 packages for Lenny (which reminds me, I still have to figure out how to handle the transition from Etch with respect to that). I've been working hard to try and get as many of the patches in Debian's DHCP packages incorporated upstream. Unfortunately, they have a totally unpredictable release cycle, and they have feature releases and bug fix releases. The feature releases are very few and far between, and they won't introduce new features into a bugfix release. Speaking of patches, my personal philosophy is that distribution packages shouldn't differ radically in behaviour or functionality from their upstream source, so I've resisted incorporating some of the more deviant patches from Ubuntu, instead forwarding them directly upstream. There's still a bit of work to be done with the package. The ISC released version 3.1.0 a while ago, and that's the version I'm trying to standardise on for Lenny. It's got new support for a domain-search option, which means people can stop abusing the domain-name option to set a domain search list in their clients. The domain-search option is also honoured by Mac OS X (Leopard), and I dare say Windows Vista probably supports it as well, but I haven't checked. Unfortunately the client-side support for the domain-search option is a bit flaky in 3.1.0, so I'm hoping the ISC will release 3.1.1 real soon now, as I believe most of the flakiness issues are addressed in it. Of course, for Lenny to do the right thing consistently with this new option, #460609 and #465158 need to be resolved also. The last thing I'm trying to sort out for Lenny is the reasonably in-demand LDAP patch. It's been floating around out-of-tree for longer than I've been maintaining the package. Jos L. Redrejo Rodr guez has been kind enough to clean up the patch for me, so that rather than bastardising the standard DHCP package to build a dhcp3-server package that has LDAP support, it basically builds DHCP twice, once with the patch and once without, and the dhcp3-server-ldap package just diverts /usr/sbin/dhcpd3 out of the way and plonks in the LDAP-enabled binary in its place. I hope to upload a new revision of the package that builds this new binary package within the next week (hopefully this weekend). After that's done, and hopefully 3.1.1 has been released, and Lenny is out of the way, I'm going to focus on transitioning away from a versioned set of DHCP packages. The whole "3" in everything was to allow the v2 and v3 packages to coexist. I've sought advice from the release team about this, and they said not to bother, but it feels really gross to have the version 4 package (4.0.0 has been released by the ISC for a while now as well) be still called dhcp3, and to install into /etc/dhcp3 and other such versioned directories. The final thing I want to look into is collaborative maintenance. I've been wanting to do this for a while, but I wanted to get the package into a revision control system (shock horror, it's not currently) and I've been baulking at how to do it the "right" way. I'm pretty sold on using Git for the revision control system, I just haven't figured out the right approach yet. Martin Krafft's articles about it have been interesting, but feel a bit overly advanced, and don't quite suit my situation. I've been hesitant to start using Git, then discover I've done it all wrong, and have to start again. I need to just bite the bullet. My upstream also doesn't use Git, and doesn't make their revision control system publicly available, so I just get the tarballs when they're released. Speaking of upstream, I made the discovery last year that they're just down the road from me in Redwood City, so I've been trying to improve relations by getting the main folks who work on DHCP at ISC to pop up to Google for lunch every now and then, which so far has happened twice, and been good a opportunity to have a chat. In fact, they're keen for Debian to join the DHCP Forum (Debian is already a member of the BIND Forum) and I think they've started talking to the Debian folks responsible for our BIND Forum membership about extending that to cover the DHCP Forum as well. So that's about it. I think after three years of being the sole uploader, I'll formally put myself in as the maintainer and Eloy as an uploader until I get around to implementing collaborative maintenance.