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 been provided the latest Verizon and Sprint EVDO cards to evaluate in the field for the past month. I now have to decide which to keep. It’s a close call (no pun intended). I’ve tested them both over various areas in Greater Boston and Washington DC. Key observations: (1) Speed: The Verizon card is usually faster. I’ve clocked up to 2.5 Mbps using the Speakeasy speed test on Verizon. That’s getting to be respectable enough to use a VPN without annoyance. My top rate on the Sprint card is about 2.0 Mbps, but usually it’s more like 1Mbps down / 0.5 Mbps up. (2) Coverage: There are more Verizon “dead” spots with no service at all. In those spots, the Sprint card invariably works fine. I’ve noticed this in some government buildings as well as on the T in Boston. (3) Device: The Verizon card I’m testing is a USB device (UM150) with an extendable antenna and the ability to power on/off right from the device. The Sprint card is one of those newfangled half-width PCMCIA cards, which requires an adapter for my laptop. There are pros and cons to each: the Verizon card is more compact when closed up and fits easily in my coat’s lapel pocket, but it seems quite precarious when actually plugged into the laptop. It could fall out easily or break if someone hit it with their bag walking by. The Sprint card, by contrast, is quite sturdy. I certainly can’t throw my laptop in my case with the Verizon card still plugged in, while the Sprint PCMCIA card can stay in without trouble. A colleague warns me, though, by keeping the PC card in I’ve created an opening for my dust and whatnot to enter the laptop. (4) Software: Finally, the (Windows) software for the Sprint card is much better than for the Verizon card. The updated Verizon software is as flaky as the last iteration. It definitely doesn’t like it if you try to disconnect after you go out of EVDO range. It also doesn’t usually survive a sleep cycle, and sometimes requires manual intervention in the task manager or a reboot to clean things up. It also has some silly features like a control panel to launch your web browser and email client. I’m not sure anyone wants to use their dial-up client that way The Sprint software has its own share of silliness by having nonstandard decoration (it looks like someone thought “skinning” it would be cool, so they took away any resemblance of regular window frame). But it’s stable and solid, survives suspend/resume, and I’ve yet to have to kill it even once. So there you have it. If anyone wants to speak in favor of one or the other, please do so in the comments. As a side note, I’m promoting broader use of the term “aircard” to make it easier to speak with nontechnical people about the difference between EVDO/WWAN and “WiFi.” Technorati Tags: Sprint, Verizon, EVDO, WWAN, Aircard

Share This

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...

For people who have interest in the development of gender equity in FLOSS development, here's a short news item. Yesterday, the Samba Team announced the "pre2" version of samba 3.2.0, scheduled to be released during the SambaXP conference next month in G ttingen (to German friends around: of course, I'll be there: Apr 14-18). That release was announced by Karolin Seeger, whoc is now replacing Jerry Carter as Samba's release manager. As far as I know, Karolin is indeed the first female memer of the Samba Team (which includes about 20-30 people). Guess what: that release seems to be a pretty good one. I'm already working on the Debian package. The release is indeed the first one to include many patches we bringed from Debian, for instance those aimed at following the FHS. Steve Langasek is the one to be rewarded for this as he bringed very valuable input in the discussion I had with Jerry Carter to convince him to include these patches..:-)

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.

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.

On this year’s Chemitzer Linux-Tage (CLT, engl. “Chemnitz Linux Days’) I attended a few talks of which especially formorer’s ikiwiki talk was very interesting. I attended his talk since I found out that ikiwiki is command line wiki compiler in contrary to the thousands of solely web based wikis out there. As a big fan of statically generated content this idea sounded very interesting to me. But just having a short look at ikiwiki’s web page didn’t help to get started and it seemed as if I had not the right idea of how ikiwiki works to get started. So formorer’s talk seemed to be a good possibility to get an idea of how ikiwiki works without much effort. During the talk I noticed that ikiwiki can many things I do with the Website Meta Language (WML), but can do some more things WML can’t do out of the box:

1. It’s not only a framework to generate web pages, it’s more like a content management system (CMS).
2. Versioning is intergal part of ikiwiki without reinventing the wheel: It works out of the box with — beyond others — Subversion, Git and Mercurical (Hg).

And when formorer showed that even Tobi Oetiker uses ikiwiki, I noticed that ikiwiki probably could be a WML killer, since I knew Tobi as a WML fan. And ikiwiki looks very appealing for the WML fan inside me, too… OTOH: Intergrating WML as a backend to ikiwiki could be an interesting idea, though. Hearing what kind of input files ikiwiki can process, I also got the idea of using hnb (Hierachical Notebook) files as input for ikiwiki. hnb files are already XML and so a conversion to XHTML shouldn’t be that hard. But when searching the web for “ikiwiki hnb” I found the blog postings of a few people switching away from hnb, e.g. to vimoutliner. Since I’m an Emacs addict and don’t like vim very much (if I use a vi, I use nvi or elvis), I searched for “emacs hnb” and indeed found someone who switched from hnb to org-mode – of which I never heard before. Unfortunately org-mode doesn’t seem to be in Debian (Update 00:23: Yeah, yeah, I now know it’s included in emacs22, but emacs22 hasn’t made it into kfreebsd-i386 yet, so I didn’t notice. See the comments. :-) but I’ll play around with it a little bit. Unfortunately a first test wasn’t that promising. But we’ll see.

Now playing: Men at Work — Down Under

I had a big fright this afternoon. My friend ludo asked me to shut down my main server (delmak.naquadah.org) for racking one of my new equipement. Delmak is my oldest server, hosting almost everything since 5 years. I knew I will have to shut it down some days, but after 280 days of uptime I was pretty confident everything will be allright. But obviously, it refused to boot again. Fortunately, only the power was burned, and after changing it with a new one, we manage to get delmak booting again. Now I'm really thinking about some better solution to not having everything on a server that can explose any day now.

It's very short notice but I'm giving a talk tonight (2008-03-03) at the Joan Jonas Performance Hall at the MIT Visual Arts Program. It's rather last minute. I'll be talking along with Mark Tribe as part of a series called Zones of Emergency. I'll be speaking a bit about free and open source software and why it's particularly important in the context of emergencies. Think Sahana. There's more information about the talk online here.

What's the best way to join a community, any community? Little by little.
I have been working with Ruby on Rails for well over a year already, even given a talk (at Encuentro Nacional Linux y Software Libre ENLi) inviting other people to use this very nice and well thought out environment. But, so far, I've been only a end-user, not really giving anything back besides minor bug reports.
Well, it's not as much as to say that I'm now a contributor - this is just a first statement of intent. I have worked a bit on several bits of code I keep repeating and hand-copying over my different Rails projects. Of course, that's completely not DRY - And completely not nice. So I decided to stop advancing on several projects, and learn my way on stting those bits of code as Rails plugins.
So far, it's been quite simple - and a good excercise on proper separation. I started, of course, with the easiest bit of code I could think of as useful in a general sense, and packaged it up as acts_as_catalog (of course, proper SVN tree and very basic, introductory README. And, of course, as I keep progressing with this work, I'll keep adding some plugins to my currently quite empty RubyForge page.
Anyway... Little by little, time will come where we have to think more seriously on how to properly bring together the Ruby on Rails style to work more tightly with Debian. Currently, the two have such different points of view on how to manage and ship components that I am not sure we will be able to truly bridge them together... But it is definitively worth trying. Hmh, looks like a task for Debconf! ;-)

Two or three days ago, there was a discussion on dpatch, quilt and all the other patch management systems on #debian-devel. My opinion still stands: if you change upstream source, then it better be in a way that upstream finds acceptable. But if I expect my changes to be merged quickly, why do I need an elaborate scheme to manage them? Or is a significant percentage of our upstreams unresponsive enough to warrant a fork?

I had a call last week from one of our customers that a self-managed server had been attacked and email wasn't running smoothly on it any more. The exploited web app (old version of mambo IIRC) had been repaired and there didn't appear to be a shell-gaining exploit, so what was wrong? Looking at the mail queue gave a clue. I couldn't see anything at first. Nothing. No output. Eventually, qmail-qstat returned and reported over 50,000 emails in the queue, which is pretty high for that webserver. Poking around the mailserver found lots of examples of a few types of spam. I stopped outgoing mail so I could clean up. I don't use qmail much. It hasn't been free software for long and the default upstream packaging (which was being used on that server) isn't very friendly IMO. So, I had no idea how to remove messages from a qmail queue, like exim -Mrm or postsuper -d. I looked at the qmail man pages and the qmail binaries. Nothing. I looked at the qmail FAQ. Nothing. I asked a LUG IRC channel. Something, but no answer. With some web searches, I found mailRemove.py - why is this not in qmail and not even a FAQ? No clear contact details on the FAQ, either.

On Saturday 1 March, I attended the Constitutional Review Roadshow at Explore@Bristol (pictured). The review is trying to develop the rules for the Cooperative Group after its merger with United. The event wasn't at all what I expected or hoped for. There were relatively few individual members there. I don't know the split, but most of the 60 or so attendees seemed to be elected members of some sort and this was the first chance they'd had to comment since the open consultation ended last year. Some of the elected members had travelled from the Eastern and South East regions. The initial slide "Purpose of Today" stated three aims:

1. bring members up to date;
2. give members the opportunity to ask questions;
3. and aid members in preparing their formal feedback.

I don't feel the event really brought us up to date or aided in preparing formal feedback, because the roadshow appeared to summarise a report which hasn't been published. Some of the elected members had seen it the day before, but no copies were available to use at the event, so we were pretty much in the dark for some aspects. The event didn't give us much opporunity to ask questions either, despite its length. I was expecting more of a consultation event, which was reinforced when I entered the room and saw seats gathered around tables. I did not expect an hour-long lecture followed by three hours or so of whole-group question-and-answer, broken by lunch. Even with the competent chairing (AFAICT), that was an amazingly inefficient way of working, with some people being cut short, but still leaving some people not being heard. It can be summed up by the chairman commenting

"I do not want this to turn into a discussion"

while the big screen next to him said "questions and discussion"! Headlines from the review: similar elected structures to current Group structure, but regional board nominated by individual members; merge regions to produce six new regions (West Midlands and North West, Wales and South West, London and South East, Eastern England and East and South Midlands, Yorkshire and Humber and North East, Scotland and Northern Ireland); add management and non-executive directors to national board; no clue how to fix diversity problems; no view on fees or job spec until structures are defined. I'll go through the slides in detail and post the questions and answers if anyone leaves a comment asking for them. Otherwise, I think I've lost enough time to this for now.

A few days ago, I discussed Trac and Redmine. Redmine is a project management tool, similar to Trac, with built-in download tools, bug tracking, etc.

Redmine has a lot of nice features. Chief among them is better integration between multiple projects, so I don't have to go to 17 separate pages to see the open bugs on my projects.

But I'm worried about the Redmine community. It appears to live in an insular Ruby world, without much participation outside. I wrote about some of those concerns in their forums. I've also submitted bugs to Redmine, some with patches.

Also, it's concerning that, although Redmine includes a very nice forum module, the Redmine forums are still on RubyForge. Also, there are many bugs in the Redmine BTS that have patches but little, if any, comments from the Redmine people that have commit access.

It could just be that Redmine is a fairly new project and just needs some time to get on its feet more. It's been around since July, 2006, which isn't all that long on the one hand... or quite awhile, depending on how you look at it.

The git support patch for Redmine looks very nice. However, after a month, it still hasn't been replied and there's no indication why. Which also is troubling.

So I think I'll sit with Trac for a little while until I get a better feel of how Redmine is progressing.

I’ve decided to blog about films whenever there are in my backlog five films I’d like to mention or talk about. I’ll also mention that when I moved to ikiwiki, I set up a films.rss feed, and some other stuff. Now:

• A History of Violence: short and incredible. Has flaws but I still give it 4.5/5. I’ll check more of Cronenberg (I loved, ages ago, M. Butterfly and Dead Ringers).
• Bent: gays, nazis, camp. Intense but not overly rough. Mick Jagger plays a drag singer named Greta.
• Elsa y Fred: terrific love story between two elderly people. Magnificent China Zorrilla. Ignore if you can’t stand romance or Argentinian.
• Martian Child: entertaining, has children and dogs, never ever ever ever ever give up.
• No Country for Old Men: oooh. All my friends hated it and told me: “you are going to love it”. And Bardem really steals the show. More below.

---

You may want to skip this part if you haven’t seen No Country for Old Men, though I won’t be spoiling much. My friends watched it some weeks ago, and I did yesterday (I refused to go with them to a dubbed session). One of them told me that she had disliked it very much because of the uneasiness she got from it, about how human life can result so worthless for people, and so on. Chatting a bit more, we came to the conclusion that I watch these films differently. Basically, I can unplug the empathy off from a film whenever (simplifying a bit) violence or cruelty reaches a certain level, and just consider it an entertainment completely unrelated to reality. Sort of, anyway. And I don’t think I could enjoy (some) films as much if I didn’t. For me, No Country for Old Men had no message in it, and had a single story line: following close the path of a creature portrayed by Bardem, that (maybe not) strangely enough managed to keep me hooked to the screen, not minding the low pace, and finding the end (minus the dreaming bits) very appropriate.

Someone over at Novell wrote an application to enable eID in various applications with a simple click: you can enable web authentication in firefox, and email signing in Thunderbird and Evolution. It also does stuff which I didn't even know was possible under Linux—enabling eID card use under OpenOffice.org. So I'm now a bit in dubio as to what I should do with this. I have an open bug report against libbeidlibopensc2 that claims the mozilla/firefox plugin should be automatically registered when you install the package, rather than having to go through a bit of javascript in some HTML file, and I kindof agree with that. I could analyze the C# code to see how the Novell people do it, translate that to C (since C# doesn't work on every architecture Debian supports, and besides I don't want to depend on yet another huge list of dependencies after wxWidgets and Qt), and call the relevant code from postinst to enable the relevant plugins system-wide. OTOH, allowing every user to make the choice for themselves, could be a good idea as well. Then again, that's not really the Debian way (if installed, it should just work). Then again, I don't think that enabling these plugins system-wide allows one to still disable it on a per-user basis. Guess I'll have to give it some thought—other people's insights are appreciated.