Mostly of interest to friends and family: our renovation has started. I stopped by today to find our kitchen and family room were gone. Alas.

Before (on a snowy day):

Now (follow the link for more photos):

Technorati Tags: Renovation, Hitchhiker’s Guide to the Galaxy

Share This

Daniel notes that self-delusion is a necessary component of all voluntary work.
Any human activity can be over-analysed into oblivion, especially if the terms of reference for "meaning" are impacted by a view of the real world that is overly abstract. Even paid work needs some self-delusion because no matter how much money you earn, the old maxims bite back - "you can't take it with you" and "no point earning it unless you can enjoy it".
Before I started with voluntary software work, I was heavily involved in voluntary charity work and the motivation is much the same. "The grand scheme of things" will never be sufficiently affected by any activity such as to provide the sole justification for that activity. The vast majority of people and the vast majority of actions simply are not and cannot become that important. (This is where religion is important for some people, the hope that despite all evidence to the contrary, acts of random kindness have some meaning to the person doing the act instead of just to the recipient.)
Voluntary work is generally for the benefit of others. In free software it is about writing code to solve our own issues in a way that others can use without facing the problems that we had to solve. Writing new code to solve a problem or fixing bugs in existing code to solve a new problem can only help others if the solution is shared. So the validation of that work is in helping someone else accomplish a task without having to spend the time fixing that issue, leaving them time to fix the next one.
Working on free software of all kinds is worthwhile simply because it is a way of helping others.
"When all things are considered", most people working on Debian are the lucky ones. Born into an environment where good education is available and where parents/relatives were able to indulge our fascination with electronic and computerised widgets that had no direct bearing on whether our basic human needs were met with regard to food, warmth and health. Trained at great expense and able to use that training not only to meet our personal financial needs but also to make time available for other unpaid tasks that benefit others who do not have those things. Living in a time of peace and stability, where the more esoteric and "frivolous" tasks can be undertaken without causing hardship or neglect of others. (My nephew frequently sums up this whole idea as like having won the lottery just by existing.)
There is an element of justification that can be derived from such a view - an element of responsibility and duty. After experiencing all those good things and after realising that we have such an opportunity, it can engender a feeling of obligation to do something that justifies what we have already received to balance out those who have the skills to do what we do but, for reasons of birth alone, do not have that opportunity or the means.
That is a form of secular humanism - validation of our own situation in the use of our skills and time to make things easier for those who are less fortunate.
OK, Debian isn't about providing clean water for all, or the redistribution of food and medicines to those without but the organisations that do that work can be assisted indirectly by making the systems used by such organisations work more efficiently, with greater stability and with more flexibility.
Not everyone can (or should) be on the front line of whatever acts of kindness will solve the problem of inequality but there is an obligation on those of us who have received the benefits of inequality to do what we can to make it easier to redraw the balance.
Debian is one such way and it is a truly international way of benefiting others too. It is more beneficial than the charity work that I did previously - chiefly because that was a very local service that was very labour-intensive and so could only benefit small numbers of people.
Improving Debian won't make us more important to the universe, life and everything (the answer to that is 42 as we all know), but it will help others do what they do, it will improve their lives and their ability to spend their time on what they want to do instead of having to fix problems that we have already solved.
Debian, to me, is about sharing solutions. Helping someone else do something that Debian could not do before, without requiring them to fix all the problems that I had to solve to devise the solution in the first place. Sharing not just the solution but the method of the solution and the means to extend the solution to new problems.
We, as Debian developers, have been granted the access and tools to solve these problems for the benefit of those who do not have upload privileges. Those rights come with responsibilities (as always) to use our skills and time to find the solution and without making things more difficult in the process.
In the grand scheme of what I can actually do as opposed to what might be possible if X, Y and Z were different, what I do in Debian and Emdebian is worthwhile. In fact, it is just as worthwhile as my paid non-IT employment in healthcare provision because, within healthcare, I can only help the single person in front of me. In Debian, I can help all those people who I will probably never meet but who want Debian to do something that I am able to achieve.
What is particularly nice about Emdebian is that there are people who tell us that our work is worthwhile by putting up the hard cash to fund work sessions and conferences that bring the various developers into one place. The international aspects of Debian can be a barrier in some ways and things always happen more quickly when the various members of the team can be brought from the four corners of the planet into one place for a week or so. It is these gatherings that boost the motivation and the enjoyment of making progress towards a common goal. Debian can be a solitary world where communication is limited to plain text. Probably the best way to "oil the wheels" in Debian is to get a group of Debian people together and just let them hack.
Voluntary work of all kinds requires personal motivation and working alone with only limited means of communication with others can be quite demotivating. Getting people together is a very useful antidote.

Here’s the free-to-air satellite details for the first big French cycle race of the year. Please add any updates in the comments, particularly any RAI or ITV coverage. Sun 09.03 Prologue: Individual Time Trial Amily (5 km) France 4 13:40 - 15:00 (live?); France 3 15:00 - 15:35 (live?); ZDF 16:15 approx -17:00, in ZDF SPORTextra (highlights?); Eurosport 23:30 - 0:15 (highlights); Mon 10.03 1st stage: Amily-Nevers (185 km) Eurosport 15:00 - 16:45; France 4 15:25 - 16:35; Tue 11.03 1st stage highlights: Amily-Nevers (185 km) Eurosport 14:30 - 15:00; 2nd stage: Nevers-Belleville (201 km) Eurosport 15:00 - 16:45; France 4 15:25 - 16:35; Wed 12.03 3rd stage: Fleurie-Saint tienne (165,5 km) Eurosport 14:30 - 16:15; France 4 15:25 - 16:35; Thu 13.034th stage: Mont limar-Mont Ventoux (176 km) Eurosport 15:30 - 16:45; France 4 15:25 - 16:35; Fri 14.03 5th stage: Althen des Paluds-Sisteron (172,5 km) France 4 15:25 - 16:35 (live); Eurosport 17:15 -18:00 (highlights); Sat 15.03 6th stage: Sisteron-Cannes (206 km) France 4 15:25 - 16:35 (live); Eurosport 17:15 -18:15 (highlights); Sun 16.03 7th stage: Nice-Nice (119 km) France 3 15:05 - 16:55 (live); Eurosport 20:00 - 21:00 (highlights); Mon 17.03 7th stage highlights: Nice-Nice (119 km) Eurosport 13:15 -14:15 All times CET. France 3 and 4 are at 5 west (in French), Eurosport is at 19 east (German digital, German and English analogue) and ZDF is at 13 and 19 east (in German). Sources: France 4 Sport, Eurosport.DE, ZDF

I’ve released dsyslog 0.2 tonight with support for BSD syslog facility and severity decoding, as well as some other nice features. You can download the source here. In other news, my computer died, so I got a new one with an Intel Core2Duo E6550, and it surprisingly outperforms my old Opteron 265 system. I’m confused as to why, after all… less cores. Also, daytime business has been forcing me to keep a schedule opposite to the one I am used to. Luckily enough for me, that will end soon and I might actually be able to get more than five hours of sleep. Sadly the lack of sleep results in weird grammatical and spelling mistakes, so it’ll be great when that’s over with! Umm, what else is new? I’m working on a Debian-derivitive which is more community-oriented: think Ubuntu except less corporate; a true grassroots project to enhance and bring Debian to the masses. Big selling point? No static releases, so users always get the latest and greatest. I don’t want to make any big claims about planned success or anything, we’ll see what happens. It’s called Defusion (you could claim it means “debian fusion” or something, but that sounds ricetastic, and if I wanted rice, I’d clearly be running Gentoo, not Debian (or Defusion for that matter)). Hmm, perhaps it’s the Debian version of ArchLinux? Well, we’ll see about that — anyone who cares is invited to participate, the requirements of entry for joining Defusion is much less than joining Debian (no keysigning parties needed here, instead we intend to do a peer review sort of thing where people who do good work get their keys added to our keyring eventually — kind of like how Ubuntu works if I understand it correctly; no flames please). As for Ubuntu, I guess I need to debug why my patch to make pulseaudio be used as default didn’t work. Hopefully this blog will be updated more in the next few weeks!

I'm sure most people have one of these, but here is my yet-another email-me-when-I-need-to-upgrade-something crontab entry, after I found cron-apt too complex:

0 */8 * * *     apt-get -qq update && apt-get -dqq dist-upgrade && apt-get -qq --simulate dist-upgrade   grep ^Inst

If your root mail goes to some place you read (probably a good idea), you will get a list of packages it wants to upgrade. When running stable, this will also effectively send you alerts about security updates.

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

Being fairly interested in this whole mobile phone software thing, it's pretty hard not to sit up and take notice of the iPhone SDK that was just announced. A few thoughts:

• Of course it's nice, polished, and lets you do some interesting things with the phone. That was not too surprising though.
• The "investment fund" seems like something of a response to the Android Developer Challenge, and is certainly an interesting move on Apple's part. Strategically, it certainly alters the focus of the money flowing into the equation. Comparing the two, the dollar amounts in the ADC are much smaller, but they are also more "concrete": N people will get X dollars in time frame T. As an independent developer, that works fairly well for me as something to have a go at and then move on from, win or lose. An investment fund backed by Kleiner Perkins is on a whole different scale and level. The amount of money is huge (they won't even bother with less than 100K), but who knows how that works out in practice, or how much of that is actually 100% committed to iPhone companies. KP aren't the sort of people that are going to just hand that out to any old company that does an iPhone app. They're also going to want to be involved in the companies, which means there won't be too many of them. In short, it brings in all the good and bad aspects of venture capital. In short: in one corner, lots of money for relatively big, organized players, and in the other, small, quick incentives to do cool things that anyone has a shot at. We won't really be able to judge the results until we see how it plays out. (As an aside, I still have some bad memories of the management that KP foisted off on Linuxcare).
• The system for selling applications is smart. You will have one place to go to to get your apps, and as a user you'll have some assurance that they're up to certain quality standards. People will like that kind of thing, and is far nicer than anything JavaME ever had. Instead of multiple, fractured marketplaces, you get one big one. Of course, it also keeps Apple in control of everything, which also has some negative implications as well.
• 37 Signals seem to be wildly ecstatic about Apple's potential, but I'm a bit less sanguine. I don't doubt that the iPhone has a bright future, that much is pretty obvious. However... dominate? First of all, if it's so widespread, it loses some of its cachet, doesn't it? I don't think Apple wants that. I don't see them licensing the system so that other phone manufacturers can use it, so it will only be adapted as widely as Apple sees fit. Cheaper Nokia models are very popular over here in Europe. Will iPhones at those price points (less than 100 euro) be available and competitive with Nokia's offerings? Open and adaptable aren't necessarily things that Apple is known for, which might be the difference between "strong presence" and "dominate", as we saw with Mac vs Windows. Getting 10-15% towards the high end of the market might be what they aspire to, rather than ubiquity.
• I could, however, very easily envision Apple getting into some kind of business niche and dominating that completely, as they did with education for a while. That might not extend to the broader market, though.
• Moving on to other considerations, this one is important to me: apparently, according to the license agreement, you can't run an interpreter that fetches code and executes it, amongst the various other restrictions! That's kind of a deal breaker for Hecl, which counts that ability as one of its strengths. I don't think a port was in the works in any case since Hecl is written in Java. Still, though, that's the kind of annoying restriction that reaffirms my commitment to open source.
• As an aside, I wonder what Sun is up to at this point - between this and Android, they have to be under enormous pressure to release a successor to Java ME, which was a good effort for its time, but is beginning to look dated and limited, even though it is very widely deployed.

I'm an open source guy at heart. I love openness and source code and the freedom to tinker... and while I'll certainly give Apple their due for making some fine products, closed and controlled is simply not for me. Others may feel differently - it's a matter of taste and preferences. So for the moment, my efforts will be focused on Android, which I see as the best, most open thing out there at the moment.

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?

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:

Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey

I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…

---

• Crypto in main: It’s getting hard to remember the days when strong crypto software was classed as munitions and even getting a web browser to do SSL properly was a legal challenge; but for a long while that’s how it was, and as a result we had to keep all our security tools hosted separately to our main, US-based archive. The laws for that changed in early 2000, introducing a new exemption to the prohibition for software whose source code was available royalty-free (I think they called it “public source”). Unfortunately there were still drawbacks: it wouldn’t apply to some stuff in non-free, it wasn’t clear how far you had to go with the source code (is libssl’s source enough, or do you need the source for the apps that use ssl too?), and the biggest problem was you had to notify the export bureau and the NSA for everything you wanted to distribute. And all of that’s couched in the sort of confusing language you’d expect to find in, well, export regulations. So we ended up getting nowhere on merging crypto into the main archive for a long while because we couldn’t be confident of what we actually needed to do. We’d more or less already missed the opportunity to do the merge for the potato (2.2) release because it was frozen more or less exactly when the new regulations came out, and according to my mail archives Ben Collins (DPL at the time) got a team organised to review the legal issues by mid-May 2001. By July 2001, though, we still weren’t really getting anywhere; the lawyer we were talking to was looking at the ENC exception (which was for closed source stuff, and requires an active review by the BXA), instead of the TSU exception (which just requires notification). While it wasn’t terrible legal advice – following the ENC exception had a lower risk of misunderstandings on our part leading to problems later – it wasn’t useful in achieving our aims, ie, getting crypto stuff into main with a minimal level of ongoing effort, as well as a minimal level of risk. So moving onto August, we’d moved on from the lawyer we’d been using for this and other issues, to talking to a lawyer who specialised in export issues (and whose time was being covered by HP). That actually got us somewhere, with the end results being a matter of public record – we got the advice we wanted by November, we got a new incoming system so we could make sure we didn’t publish anything we hadn’t advised the NSA and BXA about, and most of all, we got cryptographic software in main for woody’s release. ssh at standard priority, apt by default checking archive signatures before downloading code to run as root, iceweasel coping with https:// urls out of the box all suddenly became possible, rather than artificially blocked due to pointless legal constraints. Yay! The way we notified BXA/NSA was somewhat interesting – we ended up notifying once for each package, when it passed through NEW: which is easy to automate, and limits the amount of software we block from review by other developers as best we can. OTOH, it also means a lot of notifications: the initial notification was a huge box of paper that got faxed off (there should be pictures somewhere on the net, but I don’t know where), and the vague hope that the ongoing reporting would not only comply with the regs, but manage to be something of a denial-of-service by compliance. As it turns out it apparently got noticed, with the following mail arriving in September 2005:

  From: Encryption 
  Date: Fri, 23 Sep 2005 12:51:02 -0400
  Subject: Addition to Debian Source Code updates
  Dear Mr. Collins,
  Your diligent reporting of updates to the Debian source code to the Bureau
  of Industry and Security has been an excellent example of perspicacity.
  However, you no longer need to do so per the following update to the EAR:
  [...]
  

  (The mails have always been sent with Ben's name attached) That mail was followed by another suggesting a phone conversation; unfortunately nobody seemed to notice the mail, at least until a year later (to the day!) when Joerg pointed out he was getting bounces form the BXA email address we'd been using... (Since then, based on the above mail, we've been recording notifications, but not passing them on; I sent a reply to the mails above indicating that, but didn't receive a response. There's been about 5000 notifications since then)
• Security and the architecture explosion: with crypto-in-main out of the way, along with lots of RC bug squashing, woody was looking good to come out in April or May, but unfortunately that all fell apart because of a lack of automation for handling security updates. Taking a step back, woody managed to introduce five new architectures compared to the previous release -- HP's pets, hppa and ia64; the IBM mainfram arch, s390, and the SGI/embedded mips and mipsel chips. That came just short of doubling our supported architectures (which had been i386, m68k, alpha, arm, sparc and powerpc), and was working really impressively well: testing was watching that they kept in sync, and the buildd network was keeping them all up to date with the latest source uploads, and the toolchain maintainers were making sure new kernels and compilers didn't cause massive breakages. It was great fun to be a part of, and I'm not sure how much is just blurry memories, but from here, it sure feels like it was a golden age on that score... Anyway, all the extra architectures freaked the security team out, given they were already having to worry about ssh'ing to half a dozen machines and manually do builds, and fix them when they broke, and to deal with that there'd been plans afoot for "rbuilder" to get rolled out, which never actually happened. All of which means it escalated from being the security team's problem, to a problem for everyone, particularly the release manager... The result of which meant knuckling down and coming up with a new security build infrastructure, which involved doing a dak install for the security archive, then building on the changes just rolled out for crypto-in-main to allow for packages to be autobuilt before actually being included in the archive, then updating official buildds for all the various architectures to target stable-security and testing-security and prioritise them and upload to the right place. But as stressful and last minute as that was, at least it worked, and woody made it out the door on July 20th 2002 -- and it's a good thing it worked, given woody ended up getting security support until June 30th 2006 -- the usual year after it's successor is released -- for four years support. (The same rule applied to sarge has resulted in two years and ten months' security support; eighteen month release cycles in general should result in two years and six months of support) Since then, with security managed by dak, there's been a few more bits I've been involved in. The most interesting of which (to my mind) was splitting the security upload queue from being completely secret and restricted to folks who are allowed to access updates prior to public announcement, into separate secret and non-secret queues. That was December 2005, and since then we've gone from having Joey Schulze basically being the sole person doing security updates to two separate teams, with ten new members. It's not without it's problems -- particularly for packages that get (mis)classified as NEW, or that get lost on their way for inclusion in the next stable point update, but it's nevertheless lightyears from where we were in April 2002, or even November 2005.
• Playing other people for suckers: with woody released, the whole "redo to release process" thing was essentially done -- it had been implemented, it had worked all the way to getting a release out, and in a fair few respects had improved things. Instead of the eight months of hand-approved uploads for the potato freeze, things had gone it automatically, albeit with gradually stricter constraints, right up until April; and even when the security problems delayed things, the manual updates only lasted a bit under three months. So at that point I was pretty happy, and looking forward to making things work a bit better and basically passing the buck to someone else. The first bit of buck passing that worked exceptionally well was jumping on Colin Watson, who'd been offering some debbugs patches on IRC, and after a delightfully brief discussion with some of the other debbugs folks, got getting him added to the group and able to make changes directly on the site. His advogato post the next day was:

  Yesterday I was invited onto the group that administers the Debian bug tracking system. I can't decide whether to be intimidated or excited. There's a great deal to do: my first couple of major projects look set to be integrating some of the existing QA interfaces to release-critical bug tracking, and developing a tool to help us edit spam out of bug histories.

  There's a lot to be said for grabbing people at the point where they're still intimidated by what they're joining; sure there's a definite risk that they'll break something you'll have to clean up, but that's pretty easy to deal with, and well worth all the extra excitement and energy that comes with a little bit of nerves. I did a talk on debbugs a few years later, at the 2005 DebConf, at which point we managed to entice Pascal Hakim and Don Armstrong into signing up, if I'm remembering right. At the same time Colin rolled out his implementation of version tracking support for debbugs (which I'd specced up a while ago, and helped design, but cannily avoided actually coding). Shortly after, Pasc put together bug subscriptions, and these days Don's pretty much the primary maintainer of debbugs. How cool is that? Passing on release managership was a bit less fortuitous though; it's a big job, and it's not something that you can offer "patches" for, generally. So after a bit of cogitating on just how to do it, I went with an open recruitment call in March 2003, and then a bunch of practical assignments to get the volunteers used to what RM work actually entailed and to see whether they actually like it. The recruitment call was mostly focussed on all the negatives, half to avoid people volunteering to be RM for the power (to decide which release policy wins, to tell maintainers what to do, to drop packages, or to just decide what name/number the next release gets) instead of wanting to actually do the work to get the next release out and keep developers happy; and the other half was the theory that if you make a job look hard, technical, but not terribly risky, it starts looking interesting to the right kind of people. The assignments generally were two parters -- first to introduce some stuff about release management that they mightn't be familiar with, and the second a bunch of problems that needed resolving that'd use those skills. The first set was RC bug fixing, followed by working out why packages aren't getting into testing, followed by dealing with packages with mutual dependencies and removing packages. At some point that evolved into the testing scripts accepting "hints" from the release team as to what packages to try in combination, or which packages to force out of testing. That turned out pretty successful, with Steve Langasek, Colin Watson and Joey Hess becoming official release assistants in August, and Colin and Steve replacing me as RM in mid-2004. It was also pretty satisfying to see Andi Barth do some more release assistant recruiting in 2005 following much the same model, and indeed using much of my mail verbatim. You can't really ask for better than that, I figure.

Geez, this was meant to be briefer...

My rogue memory wasn't so rogue after all. Kyle and Joel helped find some evidence of gaming activity, and now I've found all the details in my mail archives of the trip, and also attending CSLUG, in February '97. Turns out that I do remember the other part of the trip, which was visiting Anna at Swarthmore. Nice to have electronic archives, as the meat ones fade away..

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.

As many of you might not know I love steam. Steam power, specifically. Steam engines represent one of the most interesting engineering developments in history as far as I'm concerned, (closely followed by the accurate mechanical clock). Why? When I was a kid I had a computer. Each part of it was labeled and described in a manual. I knew what it was. I understood how it worked. I could build one myself if I had the time and re$ources. Nowadays? Hell no. Sure I can assemble the different components, but I can no longer visualize the whole entity, and I couldn't build one from scratch. I'm amazed at youngsters (~18 yrs old) who can understand a modern PC. Me? I do, but only barely, and that is primarily because I've watched the transition: Hercules Graphics -> CGA -> VGA -> SVGA -> & etc. Coming in cold? Right now? I'd be lost. I'm impressed (saddened? That this stuff isn't more accessible?) that people can pick up technology and understand it, without having watched the developments along the way. "Southbridge"? "Northbridge"? "APIC"? It's the same with everything. Fixing a car engine? These days? With electronics? Hell no. My (non-existant) car breaks, I'd be fucked. I can strip a simple engine. I could repair it if I had to. I could build a steam engine. I could, given a suitable template and collection of eye-glasses, build a mechanical clock. But computers? Modern Cars? Aeroplanes? More complex than a simple person like me can understand. And somehow I think that's a bad idea. It almost reminds me of the old Asimov stories where only computers could design new machines. People just didn't undestand them anymore.   So, in conclusion. I have new steam car. It works, as you can see in this adhoc video. (Randomly captured by my partner whilst I was too busy squee'ing. Excuse the quality and lack of editting. Notice too that I've removed the seats for the test drive, just to give me a safe place to pick it up without burning my fingers!) Lets hope the rise of the machines is soon, otherwise mankind will have collectively lost all knowledge of things less advanced than hot & cold electricity and the microprocessor. (As you can tell it is late and I've just had many beers and a beautiful curry. All is well! Thanks for reading!)

Madduck complains about the lack of attractive data plans for mobile phone providers in Switzerland. Madduck: As always, you will have to remember there are many people confronted with a much worse situation than yours.
Up to a month ago, I never envisioned using my phone for anything besides... Well, talking. But yes, since I got my new gadget, I keep playing with GPS or using it for simple things that require Web access and do not require much interactivity (the suckiness of a 12-key keyboard is berhuge!) - Provided, of course, that I am near a WiFi hotspot, of course. My mobile service provider, Telcel, just publicly launched its 3G network - this means, of course, prices are well over the roof:
The cheapest plan starts at MX$59 (around US$5.5) a month, and gives you a whooping 1MB of allowed transfer - Anything you do over 1MB will cost you MX$0.06 per kilobyte. Yes, Telcel offers a 1.5Mbps connection, so it'd theoretically take only 6 seconds to exceed the monthly plan. After the joyful first seconds of network access, each second of full-fledged data transfer will cost you 9 pesos - Around US$0.85. How nice!
Now, there are plans for 1, 3, 5, 10, 15, 20, 30, 50, 100 and 1000MB. Their price increases at a slow pace up to MX$459, which is still somewhat expensive if you even thought on using your cell phone as a gateway (say, over Bluetooth) for your regular computer's connectivity. Of course, if I buy 1GB of data transfer, I'd expect a much lower price for each additional Kb. Well, no, it only goes down to MX$0.03. Per Kilobyte, yes, you read right. Those little things your Vic20 was full of.
There is even an unlimited plan. Well, yes, unlimited but limited - For MX$579 (~US$55) you get a nice deal, right? After all, I pay MX$350 for my 1024/128 DSL connection - it is on the right range. Well, no - If you get over 3GB in one month, your data rate will drop to 128Kbps for the rest of the month. Nice. No good as a gateway either.
So, I'm not hiring a 3G plan at all. But that's also a danger - If I open a net-using program at the wrong moment, I'll be billed at MX$0.14 per Kilobyte.
Bah.
[update] There is another similar service in Mexico, IUSAcell's BAM. Pricing is equivalent, though.

Good news everyone, new stable Gammu release is out. Since 1.18.92 it brings only few small fixes in build system, but there is quite big list of changes compared to 1.18.0:

• Add option to disable compiled in protection.
• Fixed detection of PostgreSQL.
• Improve debug messages when connecting to phone (bug #508).
• Fixed handling of some charsets in AT engine (bug #525).
• Identify more Nokia phones (thanks to Iv n Gabriel).
• Fixed regression with DKU2 cables on Windows (bug #533).
• Better compatibility with iCalendar files (bug #538).
• Do not link with irprops.lib on Windows.
• Various MSVC compilation fixes.
• Improved AT model parsing and added tests.
• Fixed possible crash in reading SMS from AT phones (bug #515).
• Proper fall back to automatic model when user enters wrong one.
• Added identification of several phones.
• Fixed reading of messages from AT phones without ME memory.
• Improve charset detection on Motorola phones (bug #522).

You can download from usual place: http://cihar.com/gammu/.

New version of python-gammu has been just released. It fixes annoying problem with reporting wrong Gammu version and brings compatibility with Gammu 1.19.0. Full list of changes:

• Compatibility with current gammu.
• Fixed Gammu version reported by python-gammu.

Download from usual place: http://cihar.com/gammu/python/

1. Bzr Exactly 2 years ago I started using bzr. I wanted to start using one of the new distributed VCS for my small projects, and I chose bzr. Not having the time/energy to do an exhaustive comparison among them and try them all to see which one I liked most, I read some articles about them, and decided that bzr would be the most appropriate for me, and that I’d stick to it if I was satisfied enough. (JFTR, at that time it was very important for me the ability to serve branches over plain HTTP, and bzr was the only one in which HTTP was a first-class citizen.) I’ve found bzr easy to use and to learn, powerful enough, customizable enough via plugins, and in general, not requiring a whole lot of attention to get things done. Also, not slow enough as to abandon it. 2. Git Yesterday somebody posted in #bzr a link to this post by Elijah Newren, where one comment said:

There’s one thing I keep telling people though: Learning git is like learning vi — it’s different from the VCS/text editors you know on a fundamental level. But once you’ve overcome that problem, you’ll not want to go back. Ever.

Which pretty much matched the idea I had of git. In the summer after my first year at Uni, I told myself: “OK, let’s learn vim.” And I think it’s one of the decisions that has paid off the most. Like learning to touch type. Reading the above quoted paragraph made more urgent the doubts I had been sporadically having during the past year: maybe I would have been better served by choosing Git instead of Bzr in the first place. What would be my life like if I had stayed with joe? 3. More about Git So yesterday I decided to spend a couple hours (or three) getting the feel of it, trying to find cool stuff. Until now, whenever I had had the need to use git, I just sticked to the bare minimum, without diving into it. I’m going to mention only two examples of the cool stuff I found. And I’ll confirm that, in my opinion, the comparison to vi really holds.

1. commands have lots of options. Tons. And some are incredibly cool, for example git log -S. It allows you to show entries whose diff contains the given string (or pattern, with --pickaxe-regex). I was missing bzr’s log --message, but it was obviously there, as log --grep.
2. Elijah has another entry that talks about what he dubs the “libmo”, and how it’s different between git and the rest, because of the “index is not automatic” schema. In particular, that entry opened my eyes about one very useful use of the index: putting there parts of an upcoming commit that are known to be correct, and that need no further inspection. Doing that with git add -p makes those parts no longer appear in your git diff, which is... whoa. I like to review before committing a lot. However, with other VCSen I always find myself reviewing/glancing at the same parts over and over. So having a way to review what’s pending or WIP is something to die for. And I know even before getting addicted to it!

4. More about Bzr I’m not sure I want to completely switch from bzr to git, not yet anyway. However, I think I’ll try it for some new projects, or migrate some minor ones. Before I can migrate everything I’ll need a bzr frontend for git-fast-import. One of the bzr authors, Ian Clatworthy, has written bzr-fastimport, and he tells me a simple exporter would not be very hard to write, and that he may even put some work into it. Also, I’m (still?) not very sold with some of the git standard practice of throwing away parts of your history regularly. We’ll see about that. Finally, one feature of bzr I would love to see in git is indented formatting for non-mainline revisions in log output (for git, in --topo-order mode only). This is most needed when you’re not rewriting your history for submission to mainline, I’ll reckon. Compare —date-order to —topo-sort to —topo-sort with —indent. Update: For this —indent thing, one could use tig, which after pressing g offers a sort of tree view in a curses-based interfaces. Somebody had mentioned this on IRC, and Peter Baumann kindly mentioned again over e-mail after reading this entry.

It’s here! In contrary to the estimated delivery time of about ten weeks, my Brompton arrived at Velofix at Saturday the 16th of February after only three weeks. The orange color is much nicer than the apple green I initially favourited from what I saw in the catalouge and the axle dynamo also proved to be a good idea, so I’m really happy about my choice. I used the Brompton to go to work everyday the last two weeks, even when it’s snowing like today: Although I’m starting slowly and taking the bus (hey, it’s a folding bike! :-) for the steepest parts (either from Am B rtli to Waidbadstrasse or Gsteigstrasse)… I even managed to fold the bike although I saw the bus already coming around the corner when I still was in the saddle. That was the day I was at work in less then 10 minutes — Perfect timing. :-) Since the local H ngg bus (route 38) only makes it’s round every 30 minutes, with the bike I’m now much more flexible and don’t have to hurry in the morning to catch the bus. (OTOH I had to notice that “being more flexible” doesn’t mean “having more time”… :-) I also use it on the campus for visits in other buildings. Although there are mostly stairs between the different levels of the campus, it’s no problem with the Brompton since it’s easy to carry, even if not folded. It’s much more comfortable than daduke’s little kickboard scooter whose hard wheels don’t feel healthy for bones and especially knees on ETH H nggerberg’s paths made out of washed-out concrete. Air tyres and rear suspension are much better… :-) Regarding the choice of gears: The MountainDrive would surely be helpful in hilly Z rich, especially since my fitness isn’t the best one at the moment, but 6 ears are ok, too, and will be even more ok as soon as my fitness gets better. The slower transmission wasn’t a bad choice either, although a wider transmission range would have been better.

JoeyH wrote a while back some thoughts on why he hates the DGT SVN repo (mainly our policy to import just the incomplete source of packages - usually just the debian/ directory).

He updated that blog entry and latter said:

Update: I realized after posting this that while the space gains on alioth might be illusory, there is certianly a space gain for people checking the whole repo out. What's really needed is a way to keep all the upstream sources in svn, but check them out only when wanted, and check out all the debian directories for cross-game work.

I was thinking, how about having a different area of the repo where the full source is present and which pulls the debian directory as an external from the current location?

I know it has the huge disadvantage that anything outside of the debian/ directory, but part of the diff, is, for sure, lost. (Still, there is also another team policy to not track anything outside debian directly, except through patches[1], except for really exceptional cases, but even then, there is a need for a strong justification).


Would that work? (I know git-svn doesn't support externals properly, yet, so there's not much gain).


[1] I know Joey, you hate those, too