Random plea for free stuff. If anyone out there has any geeky stickers (or anything a bit random for a sticker) lying around, please send them to me! I d rather not put my address on the intarwebs, so please feel free to email me on martin AT sourceguru DOT net if you have something to send me, and I will happily send you out a Stamped Addressed Envelope. The stickers will be put to good use decorating my laptop Edit:- I ve just realised that sending a SASE to another country really doesn t work particularly well, different countries use different stamps after all!!!!
I m trying to think up a solution, but please let it be known that I am in the U.K., so if you re outside and want to send me stickers, you may have to help me come up with a solution for getting round the whole stamp thing!

So I love biting irony as a way to make A Point and one of my favorite essays in this regard is If Men Could Menstruate. For a while now, I have been waiting for some biting irony, really mockery, to be launched at the free wheeling Internet punditry that is so common today . Well, here is one amazing video morsel directed at the social media guru (pictured below). Since the social media guru is just one class of Internet pundit, I hope more mockery will follow. <object height="344" width="425"><param name="movie" value="http://www.youtube.com/v/ZKCdexz5RQ8&amp;hl=en&amp;fs=1&amp;"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed allowfullscreen="true" allowscriptaccess="always" height="344" src="http://www.youtube.com/v/ZKCdexz5RQ8&amp;hl=en&amp;fs=1&amp;" type="application/x-shockwave-flash" width="425"></embed></object>

So I love biting irony as a way to make A Point and one of my favorite essays in this regard is If Men Could Menstruate. For a while now, I have been waiting for some biting irony, really mockery, to be launched at the free wheeling Internet punditry that is so common today . Well, here is one amazing video morsel directed at the social media guru (pictured below). Since the social media guru is just one class of Internet pundit, I hope more mockery will follow. <object height="344" width="425"><param name="movie" value="http://www.youtube.com/v/ZKCdexz5RQ8&amp;hl=en&amp;fs=1&amp;"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed allowfullscreen="true" allowscriptaccess="always" height="344" src="http://www.youtube.com/v/ZKCdexz5RQ8&amp;hl=en&amp;fs=1&amp;" type="application/x-shockwave-flash" width="425"></embed></object>

I just put online new Wammu and Gammu website at http://wammu.eu/. The reason for this change is that I want all relevant information about Gammu and related programs to be available in one place. You can find there information about Gammu, SMSD and python-gammu as well including some information and documentation which used to be spread in wiki and various other documents. Also all Gammu and Wammu related announcements will be published only on that website and will no longer pollute my blog (and all planets where my blog is being syndicated). If you followed RSS feed, you should update your reader to http://wammu.eu/news/rss/. The new website also includes updated Gammu Phone Database, which will look almost same to users, but has been completely rewritten underneath, what will allow some extensions in future and allows easier management of entries for me. What currently lacks behind old website is Czech translation. The reason is in simple fact that new website contains much more texts and I did not yet have time to translate it. If you want to help, just go to l10n.cihar.com, or just follow translators instructions. This time it will be also possible to add other translations, so if you want to translate website to other language, you are welcome!

If this product should fail in your lifetime, we will replace it at no charge. If the proeducts is damaged by aggressive music listeners sliding a rail, sliding down the emergency ramp of your aircraft, slammed in your locker, slammed in your car door, run over by a car, running into a wall, getting run out of town, mountain biking, road biking, sky diving, beating your boyfriend unmercifully, getting beat down by the man, blown up in an accidental experimentation with flammable substances or damaged in any other every day experience, it means you are living your life the way we want our product used! In these, or any other damaging events, we will replace the product for a 50% discount from retail.

Skullcandy rock! I m loving my new headphones

I ve been considering for some time now to create a merge tool specifically suited for debian/changelog files. My goal was to let Git use it automatically thanks to gitattributes. I ve just gone ahead, so let me introduce you git-merge-dch. Grab it with git clone git://git.debian.org/~hertzog/git-merge-dch.git, you can build a package if you wish. Beware, you need to have a dpkg-dev 1.15.5 that is not yet published (so you need to build dpkg from its git repository, git clone git://git.debian.org/dpkg/dpkg.git) as I rely on features that I introduced recently you will also need the libalgorithm-merge-perl package. Using it in a git repository requires two changes:

• defining a new merge driver somewhere in the git configuration (in .git/config or ~/.gitconfig for example):

  [merge "git-merge-dch"]
          name = debian/changelog merge driver
          driver = git-merge-dch -m %O %A %B %A
  

• defining the merge attribute for debian/changelog files either in .gitattributes in the repository itself or in .git/info/attributes:

  debian/changelog merge=git-merge-dch
  

Now you can safely maintain two branches of a package with changelog files evolving separately and merge one into the other without creating undue conflicts. Suppose you created an experimental branch for version 2.28 (you use a version 2.28-1~exp1) when 2.26.2 was current stable in the master branch. In the mean time, 2.26.3 got out and was packaged in master. Next time you merge stable into experimental, the changelog entries for 2.28 and 2.26.3 won t collide despite being at the same place in the changelog file compared to the common ancestor. Let s continue with this example, 2.28 is out. Instead of adding a new changelog entry with New upstream release without further changes, you keep the current changelog entry and simply change the version into 2.28-1. While preparing this you discover a branch with fixes that was based on 2.28-1~exp1, if you merge it it will reintroduce a 2.28-1~exp1 entry that you don t want. Fortunately you can use the --merge-prereleases (-m) option of git-merge-dch so that it strip the prerelease part of the version string and considers 2.28-1~exp1 and 2.28-1 to be the same entry really. The only limitation is that this merge tool will remove any lines which are not parsed by Dpkg::Changelog (and which in theory are not supposed to be there). Feel free to test, share your comments, report bugs and send patches! Partagez cet article / Share This

don't set DEBEMAIL in /etc/pbuilderrc That's pretty much it. The reason is that, if you do set DEBEMAIL pbuilder/cowbuilder configuration option (most likely, to the same value of your $DEBEMAIL envvar) you will end up generating .changes file containing fields like:

    Maintainer: Stefano Zacchiroli <zack@debian.org>
    Changed-By: Stefano Zacchiroli <zack@debian.org>

even when you're not the maintainer, e.g. when the maintainer is a team address or when you are doing an NMU (which I've been doing quite a lot recently). I discovered this thanks to Ana about a month ago and it quite shocked me, since I've been using the same pbuilder (and then cowbuilder) configuration for quite a while (years ...) without realizing that. The complicity of a missing lintian check has surely helped (wishlist bug filed) as well as a weird/buggy behavior on the *builder side (there are some bugs on that line, I just haven't taken the time yet to understand what should be the correct behavior). Bottom line: just check whether you are screwing up *.changes file due to overzealous attitude in *builder configuration

So I finally got around to checking out the TED site; I ve quickly become a fan. One of the first talks I watched was Steven Levitt s child carseats talk. Both the talk and the feedback comments on the TED site reminded me of things I see in software development. Here s the video if you haven t seen it. Steven Levitt shows in his talk how 30 years of data on car crash fatalities imply that carseats do not outperform regular seatbelts for children ages 2 and up. Anyone who has a child or grandchildren will probably bristle at hearing that; as the father of a pre-schooler, it certainly gave me pause. We spent no small amount of time and decent chunk of money in selecting carseats for our child, thinking we had done our best to ensure our child s safety. For that matter, it would be illegal for us not to have done so. To see a decent-sized data sample suggesting my child would be better off in a seatbelt at her age is rather unsettling. By the end of the talk, I took away these observations:

• This great swath of an initiative was started by a very small yet vocal group of proponents whose assertions received little scrutiny.
• A solution tailored to the specific constraints of a portion of the audience has been put forth as the de facto solution for the entire audience.
• There is an ongoing assumption that the more complicated and costly solution must be superior to the simpler, existing solution.
• Cursory evaluation of a data set without rigorous attention to mitigating factors can lead to wildly inaccurate conclusions.
• The acceptability of a given solution is often tested against a narrow band of the overall criteria, and the solution is often optimized to pass that test.
• The likelihood that people will continue to choose the more expensive and complicated solution despite any data is high.

So, software professionals, does any of that sound familiar? It reminds me of numerous initiatives over the years that have led us inexorably to the software productivity morass we have slogged through for years now. I suppose the most heinous case study in my own experience would be J2EE and the insistence that it was the solution that any reasonable business application would choose for a platform. (Before you .Net folks jump on that one, DCOM and later the .Net enterprise stack was much the same.) And who hasn t read a benchmark or white paper with seemingly incontrovertible data depicted in highly-polished graphics insisting that Product Y is the one solution to address them all? I noticed that there were comments below the video on its page at the TED site, largely because the negative verbiage of the topmost comment jumped out at me. I took the time to read through them all (there were 36 at the time of this writing), and to my amusement, I saw parallels between them and how people react to questioning and examining our existing practices and means of developing software. See if any of these strike a chord:

• The idea that what we re doing might be wrong unsettles some people, and their response is often ferocious and irrational defense of the status quo.
• Those who have a financial stake in the current mode of operation are less likely to be open to scrutinizing it.
• There will be some people whose primary objection to the scrutiny is that they didn t think of doing it first; these people will sometimes attack the person questioning things on the grounds that it s all a selfish, attention-mongering endeavor.
• There are some people who will also be open to examining why and how we re doing things; whether they conclude the same thing or not, they are a welcome presence among the larger mass of those who ardently refuse to entertain the possibility of a need to change.

In recent years I ve been greatly encouraged by the willingness of companies to question whether or not the heavyweight frameworks and technology stacks are what they should be using. Helping companies slough off high-ceremony processes in favor of right-sized process that focuses on delivering the right software in a timely manner has been some of the more rewarding work I ve done the past several years. I think we have an encouraging number of people in the industry who are challenging the more expensive and complicated always equals better mantra. For the brave individuals willing to put these questions to the community at large, I hope you find some comfort in knowing that the resistance and rejection you will encounter is a thing to be expected; you are not alone in that respect. Here s hoping we continue to be open to self-examination, no matter what emotional responses it might provoke or what fear of the future it may stir up within us.

Today I branched the (LaTeX) source of my Debian book in preparation of the second edition, targetted for the forthcoming Debian 6.0 squeeze . I am very excited to come back to this project after deprioritising it in favour of my research for too long. Thanks to my publishers Open Source Press and No Starch Press for their patience. If you want to be the first to receive announcements about the book, such as release dates, previews, or other information, please sign up to the announcement mailing list. The second edition has two goals:

• Bring all existing content up-to-date with what has changed in Debian in the last four years.
• Add additional material, such as (but not limited to): SecureApt, backporting, using version control for packaging, IPv6, dm-crypt, Unicode, and virtualisation. If you have any suggestions or wishes for topics I should write about, let me know at feedback t debiansystem d t info.

I want to re-establish the book as the standard Debian reference, but also to give my existing readers a good reason to buy the book again. While we re on the topic of buying: yes, the book is pay-ware, and yes, in some ways that goes against the spirit of open-source, and Debian in particular. However, this is a choice I made. If this book didn t have a commercial basis, then I could not put as much time into it, and I would not be able to profit from the outstanding help from the folks at Open Source Press and No Starch Press it is thanks to their advice and experience that the book turned out to be as it is. The book will be available as PDF from the start, so if you care as much about the environment as I do, you ll prefer to get that over the Dead Tree Version. And if you re as haptic as I am, then you still have the option to buy the book so you can hold something real in your hands. I am looking forward to working on this project, to working intensely with the Debian community throughout, and to your input.

Like make(1), ikiwiki knows about dependencies between the files that it is building, and will rebuild a file if its dependencies change. I've always known that it was possible to greatly reduce the amount of work ikiwiki does, if it gets smarter handling of different types of dependencies. It would be as if make knew that changes to comments inside header files did not change the resulting binary, and avoided rebuilding it for such a change -- but did rebuild the doxygen documentation. Except that, in ikiwiki, this can be done sanely, since it figures out the dependencies by examing the wiki's files, not by using a Makefile. Also, there were some nasty bugs with certian complex dependencies not being handled right. Fixing one of them, the transitive dependency problem, would require ikiwiki doing significantly more work. So fixing all this has been on my todo list for a while. Though when I mentioned "transitive dependencies" at the ikiwiki BOF @ DebConf, eyes glazed over. :) And I expect I've lost most of my readers already here too.. Which is a pity, because I've just gotten to the fun stuff. So, a few (how many?!) days ago I started my current insane hackfest, and began adding dependency types into ikiwiki. The first special type was a presence dependency -- a dependency that only cares if a page is created, or deleted, but does not care about changes to the page. Next type was a links dependency -- a dependency that only cares if the page changes what pages it links to. That was great, except it often didn't work. For features like gathering "posts/*" together into a blog, or displaying a tag cloud of "tags/*", ikiwiki uses a PageSpec. This is a small, domain specific language, that can specify a set of pages with lots of control. For example, "(index or backlink(index)) and created_after(oldpage)". The problem is that when using a PageSpec like the one above in a presence dependency, it doesn't only matter if pages are added/removed. Certian changes to "oldpage" or "index" can also change what it matches. So now, I had this PageSpec DSL, that I needed to somehow analyise to find these influences. While thankfully not turing-complete, parsing it to extract the influences would still be annoying. Except: Operator overloading to the rescue! The solution was this perl:

package IkiWiki::FailReason;
use overload (
        '""'    => sub   $_[0][0]  ,
        '0+'    => sub   0  ,
        '!'     => sub   bless $_[0], 'IkiWiki::SuccessReason' ,
        '&'     => sub   $_[0]->merge_influences($_[1]); $_[0]  ,
        ' '     => sub   $_[1]->merge_influences($_[0]); $_[1]  ,
        fallback => 1,
);
package IkiWiki::SuccessReason;
use overload (
        '""'    => sub   $_[0][0]  ,
        '0+'    => sub   1  ,
        '!'     => sub   bless $_[0], 'IkiWiki::FailReason' ,
        '&'     => sub   $_[1]->merge_influences($_[0]); $_[1]  ,
        ' '     => sub   $_[0]->merge_influences($_[1]); $_[0]  ,
        fallback => 1,
);

Ikiwiki already dealt with pagespecs by translating them to perl (which is then compiled (yes, perl can), and happily memoized). A pagespec is translated to something like this:

(match_glob("index")   match_backlink("index")) & match_created_after("oldpage")

The match_* functions return IkiWiki::SuccessReason or IkiWiki::FailReason objects. These objects are special in a lot of ways; they act like boolean values most of the time, but if viewed as a string, you get a user-understandable message saying why the pagespec didn't match. And when ANDed or ORed together, they build up a list of influences, that can be accessed at the end to get all the influences for the whole pagespec. (Why am I using what's supposed to be bitwise operations & and , rather than "and" and "or"? Because perl doesn't seem to consider the latter to be operators. Odd.) Anyway, this stuff should be available in an ikiwiki release just as soon as I've finished making it smoking fast.

Today, Fabio and I extended the deadline of the call for papers of the upcoming Distro Summit until 18 October 2009. We have already received a number of great proposals, but not enough to complete the schedule. So if you have anything to say on the topic of distributions (such as, but not limited to the various Linux distributions), and especially on cross-distro collaboration, please launch your mailer and compose a message as detailed in the instructions. Distro Summit will take place as part of LCA 2010 in Wellington, New Zealand. Yes, that is on the Southern Hemisphere, and yes, that is far away from where many of you live, but it s well worth a visit, if you ll take my word for it. Unfortunately, we are unable to provide sponsorship for speakers, so talk to your employer or your distro now and get the ball rolling. You have a little more than a week to get your bids in! What are you waiting for? This is a once-in-a-lifetime chance: Distro Summit, LCA, and Wellington, all-in-one. It doesn t get much better than that. Let s hear your proposal! PS: I loved Wellington (and its people) so much that I picked up my very own pet Wellingtonian!

Like written in a former blog entry I am working on preparing for getting Kalle's Debian Redesign tested and installed. Even though some unfortunate events happened which made me reconsider my efforts and a lot of things changed for me I am still up with the effort. Mostly because I didn't became part of the webmasters just to chicken away in the face of obstacles, and also not just because yet another image-hack did pop up that neither showed anything usable or overall-thoughts or actual code/concepts or even tried to get in contact with the webteam. I only remember to have received positive feedback in which I also include minor change suggestions like that the exact hits and other hits sections in the packages site aren't as clearly distinguishable as before. I have of course forwarded these to Kalle and we are looking for a solution that would go with the style. Speaking of the packages site I finally managed to get the packages from the main pool displayed too so it shouldn't behave differently to the old one anymore in that respect (see e.g. wesnoth for some more distributed package). The next step I finished these last days was setting up a testsite for www as you can find it on www.deb.at. Please notice that you might want to surf that site in English (either change your Accept-Language settings or click on the English links at the bottom of the pages) because some of the changes are only recognizable there; like, the main page in other languages look immensely different. Where to go from here? Kalle also has proposal for the BugTracking System and the Planet so that targets are the obvious next steps. I can't tell yet when they will be done, depends on how complicated it is to set up an environment for it, but I will keep you updated.

I'm going to this year's Debian developers meeting, the DebConf9. Unfortunately the conference overlaps with even more important events, so I will only be there half the time from 27^th of July, but I will stay to the end. Being a first time visitor of DebConf I'm curious about what's going to happen there and about getting in touch with all the other geeks... *grin* See you there!

I m back from Taiwan since Thursday already. It was a nice trip, the whole week and I do like Taiwan. We had a transit stop in Bangkok, pretty annoying useless stop (I m sure the smokers disagree, seeing how fast they got into the smokers lounge :) ). One nice detail at Bangkok airport are the ramps down to the Gates. If you use a wheelchair, you might end up having some fun in case you ever lose control of it. Better don t. The ramp down directly ends in a set of stairs, with nothing between which would stop you. Makes too great a jump down, hehe. We arrived in Taipei Thursday (the 24th) evening and so got rid of our luggage and went out for Dinner. Which was the only time in Taiwan I wasn t happy about the food, only one of the dishes was ok, the rest not for me. But the rest of the group did like em, so maybe it was just me after a long flight. On Friday we had nothing planned, except for Dinner, so took a very relaxed day. Somewhere around noon we went out for food, after that a bit sightseeing around the hostel . There are two attributes that are always true for Taipei:

1. It s a busy place, lots of people. No matter where.
2. It has more scooters than you ever saw before. (True, there are two times more scooters than cars).

Oh, and of course there are the same rules of the road than in Mexico: Something might be written on paper, but better don t count on that. Red traffic lights are followed (mostly), and then its whoever is stronger. But if everyone is following this, it does seem to work out. :) Friday evening we had Dinner in a place run by Taiwan aborigines where we met the other people attending the mini-DebConf. Oh, and as it was the third time I had to use them, I was slowly growing accustomed to chopsticks, a thing I was never able to get done before. (Ok, fine, if its the only way to get food and all the others are stealing your food if you can t handle them, now thats a good reason to learn to eat with chopsticks fast :) ). Saturday and Sunday we had the mini-DebConf as part of the ICOS. I took no pictures there, but a number of other people have, you can find them on gallery.debconf.org. It was a pretty nice event where I held one talk about the Debian archive and lead one discussion round about SPI and non-profit organizations behind OpenSource Projects. The slides for the archive talk are available (beware of the kittens!), the SPI stuff only had a small introduction, no slides here. Oh, before I forget it: Taiwan does feel very hot. And we found a nice notice in our hostel Monday til Wednesday was planned for just play the Tourist game and see stuff . There was a plan made to visit the Taipei 101. It turned out that Canonical has an office within that building, as well as Google. So people planned to visit their offices too. Just - what the hell would I want to visit a Canonical office? Or a Google one? Besides that it was much too early in the day and promised to be boring, so h01ger and myself skipped it. Luck did mean it good with us, we managed to get Sabrina as a local guide for the day and so went to the Taipei 101 later. The 101 is a pretty nice building, though I would have loved to be able to get up to the real top. And not just in the upper part. Anyways, we had been lucky and had a pretty nice view from it. Getting up from the 4th floor to the 89th is also an experience one has to take: The elevators go up with 1010m/min, which makes it a 37second trip only. Down is much slower, only 600m/min, pretty boring (though you do feel it more than enough in your stomach. I wouldn t want to do lift-boy job there). After the 101 we went and visited the Lungshan temple and in the evening a night market. As it was Monday the market was empty. (Where empty translates to enough people around that you never ever feel alone. Nor think its dead). Good that, I don t think I want to experience it during weekends when its busy We had a pretty good time there, with all the various little shops. Fun how many old-style game places there are. Like, playing basketball, throwing things at other things to win stuff, all those non-computer-using games. In a country where lots of the high tech comes from this is not exactly what you would expect. On Tuesday our trip continued as good as it started on Monday, as we had the pleasure to keep Sabrina as guide for Tuesday and Wednesday. So our Tuesday started out with a visit to the National Palace Museum. Which has a large enough collection that you can spend multiple days exploring it. We didn t have the time nor memory for all of that, so left it after half a day. Lunch we took in a Japanese restaurant and here it was the first and only time during my Taiwan visit that I used a fork. Well, none of the dishes would have worked otherwise. The afternoon we spent in the Yangming Park, so we actually saw a bit of nature near Taipei. Tuesday did end early for us, as we planned to attend the TOSSUG meeting, where I met some more people from debian.org.tw and had an interesting chat about non-profit organizations in Taiwan, their way of operation and what to think of when trying to create a new one. I ve also got a nice debian.org.tw shirt, but I won t ever be able to wear it. They didn t expect someone that large when producing them, oh well. (Hrr, people, if you make Debian shirts of any kind, always do some XXL too. There might be fat, large guys like me visiting. :) ) Anyway, they have another thing, one which I like very much. They created a map of usergroups of other open source projects in Taiwan. It s a foldable map style, titled FLOSS Community Manual , and a lot of different Projects/Usergroups/ are listed there. While its all written in Chinese and I can t read it, it does list them, then describes what they are/do (I think), gives contact information and further links. The backside of it also seem to list events happening there. You can find more information (so you can read it :) ) at their website. Does seem a very nice idea to take. Sometime during the evening I also managed to pick up a Chinese name. Or better, Andrew did so for me. I don t even know how to type it, so copy&paste it has to be. :) There: . And that is:

• Definition in English: long, far, remote, distant; liesurely; Mandarin Pronunciation: YOU1
• Definition in English: axle; personal name of mencius; Mandarin Pronunciation: KE1

Wednesday was our last day in Taiwan, unfortunately. We went out of Taipei, visting the Golden Mountain City. Another nice place, with a market and a history, but as our Taxi was leaving at 1630 we didn t have much time for sightseeing. You could spend a lot there. Especially not as we still needed to buy postcards, something people left home always request from one. Tssk. I really enjoyed the time I had there. Not only was the organization of the conference we attended good (especially the mini-DebConf is what I saw. The event around it, while named International, was so much chinese spoken, that I couldn t make much of it), but the details around the whole stay had been nicely taken care off. And then people in general did appear very friendly. Now, it might have to do a bit with me not being exactly their height, but I dont think that is all of it. Even without such a conference as an opportunity I think I will visit the country again, but that time I will have much more time available. Like two or three weeks. And I certainly will see more than Taipei City then. Like the whole country. :) (And hope I am lucky again with local guides :) ). So thank you SLAT, Andrew, Arne, (Sabrina), Rita, (Candy) and all the people who worked for the event which names I forgot. Oh, if you didn t find it yet with all the links, a set of my pictures is available from here.

Here we are back from our german week-end... The major event of this week-end was running the K ln Cologne marathon. Why Cologne? Mostly because my marathon Debian friends Ralf Treinen and No l K the ran it last year and enjoyed it. So, when we ran the Paris marathon together back in April, we decided to run either Berlin or Cologne later on. I finally settled for Cologne because this is closer from Paris and the date was more convenient. That was great also for No l, who lives close to K ln, so of course he planned that race in his (busy) schedule. Unfortunately, Ralf got tendinite problems since last Spring and could not join us. We really hope this will be temporary and we will enjoy running together in the future. So, I spent most of the week-end both visiting Cologne with Elizabeth...and running these 42,195 km. That was great, really. Even if there were much more Germans than in Debian, they were really as friendly and welcoming as Debian Germans are...:-). The race happens in Cologne center city and is well arranged for followers to be able to see runners several times, as the track comes back in the city center several times....with a memorable finish through the cathedral place, then central pedestrian streets and the bridge over the Rhein river (well, climbling it at km.42 is a small PITA, but still..). Animation nearly all along the streets with many K ln inhabitants and tourists encouraging the runners and shouting and applausing and playing percussions, and.... My own race was really as I planned to do it. I targeted 4h exactly (Paris was 4h10) and thus tried to keep a pace of 5'41"/km....which I nearly respected. I had a small alert around km13-15 when my legs where kind of heavy....and I was already imagining a terrible second part for the race. Finally, seeing Elizabeth encouraging me at km.19 in the middle of a big crowd, then passing through Friesen Platz in a great noise and with huge encouragements, just made it. I then completed the first half in 1h59'20", which was just fine. I slightly slowed down between km. 24 and 28, mostly because I was trusting my GPS watch to keep the pace...while it is indeed a bit inaccurate (its kilometers are about 950m long). So, when I realized that I was about 1-2 mins late at km. 30, I decided to accelerate a little and thus target 5'30"/km on the watch...which I could sustain up to km.38. I was fearing cramps and a very hard finish, just as it happened to me in Paris...but finally could finish in a quite good shape and keeping my pace. My final time is officially 4h00'47". So, I missed my target by very few seconds but I am really very happy with the result and the way I finished. Recovering in the hotel's sauna was amazing, after this, and I could then remember all the great moments of that race by viewing Elizabeth's pictures (soon online on my gallery, promise made). And, finally, today, we had another day off to drive back home and continue recovering....and register for Paris Marathon on April 11th 2010..:-)... Hopefully, No l (who did an amazing 3h15) will convince self that he should come with his running friends. So, dear readers, if you reached that part of my blog...I'm afraid you will again read about marathon stories from me.... As everybody was telling me: once you start, you never want to stop..:)

High-speed internet links are something that makes FOSS development much easier, but I m still having reliability problems with my ADSL. A fringe benefit of moving to a more open Linux-based router is that I can see what s going wrong in more detail. But now I have to gamble nearly two hundred pounds in order to get the service providers to continue trying to find the bug! Sorry for the length, but let me explain how bad broadband in rural England is just now Outside the big cities with their cable networks, Company A owns the lines, Company B provides the services and we buy those services from reseller Company C. Sometimes the same company is A and B or B and C, but never all three. Most of the companies who are B won t be C themselves - in other words, they don t sell retail, but they nearly always seem to have a main or preferred retail partner. Company A is nearly always OpenReach, part of BT Group, the telephone monopoly privatised back in the 1980s but still somehow keeping its landline monopoly. Why is that allowed? Company C has been The Phone Co-op for me for the last few years. Back in February, I changed how I bought my services, combining phone and broadband into one purchase. They d been two purchases mainly because I switched my ADSL from Pipex to the co-op at a different time to switching my line to them. As I understand it, this change had the side effect of changing Company B from OpenReach to Opal Telecom. Opal are the provider business behind TalkTalk, hardest to use Broadband ISP 2009. Since the change, I ve been suffering unexplained disconnections, especially in the early evenings and at weekends. I m pretty sure it s Opal s equipment to blame for two reasons:- Firstly, this wasn t happening until Opal became Company B, while Companies A and C are the same as before (when I had a stable but unspectacular 4Mbps connection). Secondly, since changing my router, I can see LCP TermReq being sent by Opal s PPP peers. Opal insist their equipment isn t sending TermReq messages. My Netgear router disagrees, but I can t seem to get anyone to take its pppd debug logs seriously. So, I ve complained to my supplier (Company C), they ve pretty straightforwardly passed it to Company B and I ve jumped through all the bloody silly hoops like using only wired connections to the router (yay, wires across the house), plugging the router into different phone sockets (yay, more wires across the house) and disconnecting everything from the phone sockets so Company A can run some voltage test (yay, uncontactability - just as well other software.coop workers can cover for me). Now the next step is for some phone engineer to call. For this to happen, I have to agree that I will pay GBP 164 if a fault is found on my phone network instead of theirs. If I don t, they will give up trying to find the fault. I don t really see why this is necessary: surely if there was a line fault, it would have shown itself on the old service? Also, the router says the line has no fault and the SNR and Attenuation are both fine but not great. Unlike most people, I ve already had my house phone network tested with professional equipment (yay for network engineers in the co-op trying to avoid the painful state of British broadband bugfixing), but I m still left betting hundreds of pounds on the phone engineers not pointing the finger at my network. What choice do I have? I ve read elsewhere about people giving up on ADSL and switching to mobile internet because then they have only one company to deal with. I can see some attraction in that, but I live in a village with poor mobile service and I suspect the forthcoming T-Mobile/Orange and T-Mobile/Three link-ups will soon make that less straightforward too. A confusopoly is probably more profitable to telephone companies. Do most people bet a couple of hundred pounds to get their broadband fixed? How many broadband faults get ignored at that point? Why don t the retail company Cs have access to enough Company B systems to lead the fault-finding instead of only being able to pass it on to people who seem to give replies that contradict the logs and won t talk directly to customers? Is fixing this A-B-C three-companies-pass-the-buck system a necessity for Digital Britain? Why isn t the government intervening to end the OpenReach monopoly outside the big cities?

Three weeks ago, I announced the automatic rule-based time tracker here, and it seems that there are actually users out there :-). Since then, it has recorded more than 240 hours of my computer s uptime in about 15000 samples. Until now, this data was stored in a simple text file, one line per entry, and relying on Haskell s Show/Read instances to do the serialization. Although not quite unexpected, this turned out to be a severe bottleneck: Already, it takes more than 25 seconds to parse the log file on my computer.Following an advice given to me on the #haskell IRC channel, I switched to a binary representation of the data, using the very nice Data.Binary module. The capture program will automatically detect if the log file is in the old format, move it away and convert the entries to binary data. And voil , the statistics program evalutes my data in about two seconds! This should be fast enough for quite a while, I hope.In my binary instances, which you can find in Data.hs, I prepended a version tag to each entry. This hopefully allows me to add more fields to the log file later, while still being able to parse the old data directly and without conversion. To still be able to manually inspect the recorded data, the program arbtt-dump was added to the package. The new version is uploaded to hackage as 0.3.0.One thing still worries me: With the old format, I could easily throw away unparseable lines in the log file (e.g. from a partial write) and still read the rest of it. With the new code, there is no such robustness: If the file breaks somewhere, it will be unreadable in its whole, or at least to the broken point. I m not sure what to do about that problem, but given the very low number of bytes written each time, I hope that it will just not happen.

debmirror 2.3 should be hitting the mirrors about now. Main change is that it will now use the available diffs to update Contents files, which should give a nice bandwidth reduction for users who mirror those. With that the option --pdiff (for "package diff") no longer really covered its function, so I decided to change it to --diff. There's also a fix for mirroring archives that don't have a Release file. Question for users The option --add-dir has been marked as deprecated (for quite some time now I suspect). I'm considering to remove it in the next release as I cannot see any use cases for it, but it's quite possible I'm missing something and there are still people using it. If you would like that option preserved, then please mail me at debmirror@packages.d.o with an explanation of why and how you use it. Managing the size of a local mirror The archive has grown a lot over the past Debian releases and keeping even a partial local mirror can require quite some disk space. Luckily debmirror offers quite a few options to tune what is mirrored. My own mirror covers testing and unstable 'main' for 6 architectures (i386, amd64, armel, hppa, sparc and s390), no source, no D-I images. It uses only 61G. I say "only" as that's about 33GB less than it could have been without tuning. In other words, I'm saving a bit more than one third! Here are the options I added to achieve this:

--exclude-deb-section='^debug$'
--exclude='/(xen-)?linux-[a-z]+-2\.6[.0-9]*-[-[:alnum:]]*(openvz vserver xen)[-[:alnum:]]*_'
--exclude='(k/kde g/gnome o/openoffice\.org).*/.*_(armel hppa s390)\.deb'
--exclude='(a/axiom/ d/debian-edu-doc/ e/ember( -media)/ e/eclipse(/ -))'
--exclude='(e/erlang g/(gcl(cvs)? ghc6)/ l/llvm(/ -) p/paraview/ o/openturns/)'
--exclude='(s/scalapack(-doc)?/ f/festvox- g/gcc-snapshot/)'
--exclude='(/acl2-books_ /digikam-doc_ /fluid-soundfont-gm_ /deal.ii-doc_)'
--exclude='(/libxmpp4r-ruby-doc_ /lilypond-doc_ /qt4-doc_ /vtk-doc_)'
--exclude='/i18n/Translation-.*\.bz2' --include='/i18n/Translation-(nl de)\.bz2'

And the explanation is:

• I rarely use debug packages and they are relatively big; if I do need one I'll download it manually from a remote mirror.
• I don't run vserver or xen kernels (and if I did I'd probably compile custom kernels anyway). I do want "regular" kernels because of D-I work.
• I doubt I'll ever want to install KDE, GNOME or OpenOffice on my armel, hppa or s390 boxes, but I do want them for the other three arches.
• Selected individual (mostly scientific) source packages that I doubt I'll ever use but use up significant disk space (and bandwidth when updated). These were found by a simple:

  du -s pool/main/*/*   sort -rn   head -n 50
  

• Selected individual huge binary packages (mostly documentation), found using:

  du -s pool/main/*/*/*.deb   sort -rn   head -n 50
  

• I'm only interested in Dutch and German translations of package descriptions. Well, actually I'm not even interested in those, but it's useful to have them for testing debmirror.

Obviously I have nothing against any of the packages that I exclude. It's just that I don't need them.