Rethinking annotate: I was recently reminded of Bonsai for querying vcs history. GNOME runs a bonsai instance. This got me thinking about 'bzr annotate', and more generally about the problem of figuring out code. It seems to me that 'bzr annotate', is, like all annotates I've seen pretty poor at really understanding how things came to be - you have to annotate several versions, cross reference revision history and so on. 'bzr gannotate' is helpful, but still not awesome. I wondered whether searching might be a better metaphor for getting some sort of handle on what is going on. Of course, we don't have a fast enough search for bzr to make this plausible. So I wrote one: bzr-search in my hobby time (my work time is entirely devoted to landing shallow-branches for bzr, which will make a huge difference to pushing new branches to hosting sites like Launchpad). bzr-search is alpha quality at the moment (though there are no bugs that I'm aware of). Its mainly missing optimisation, features and capabilities that would be useful, like meaningful phrase searching/stemming/optional case insensitivity on individual searches. That said, I've tried it on some fairly big projects - like my copy of python here:

time bzr search socket inet_pton
(about 30 hits, first one up in 1 second)...
real    0m2.957s
user    0m2.768s
sys     0m0.180s

The index run takes some time (as you might expect, though like I noted - it hasn't been optimised as such). Once indexed, a branch will be kept up to date automatically on push/pull/commit operations. I realise search is a long slope to get good results on, but hey - I'm not trying to compete with Google :). I wanted something that had the following key characteristics: * Worked when offline * Simple to use * Easy to install Which I've achieved - I'm extremely happy with this plugin. Whats really cool though, is that other developers have picked it up and already integrated it into loggerhead and bzr-eclipse. I don't have a screen shot for loggerhead yet, but heres an old one. This old one does not show the path of a hit, nor the content summaries, which current bzr-search versions create.

Just in case you haven't yet watched it: Big Buck Bunny. Great animated video created mainly using Blender, released under the Creative Commons Attribution 3.0 license. The soundtrack/score is now also available under a CC license (as is lots of other "raw" material for the movie).

Russ Nelson announces that the newer version of Gnash has been released. I’ve already created newer packages for it, but I cannot upload them to Debian yet, as they’re blocked for the poppler, c-ares and ffmpeg transitions. I hope to have them uploaded soon. In any case, I’ve put them here, if someone wants to try them. As the backends for the rendering, widgets and media must be decided on compile time, there’s not much to do if you want to use the most uncommon ones. The most stable and conservative option is agg and GStreamer, but I’ve also added the possibility of using OpenGL, which would be better for hardware-accelerated machines. Versions for both GTK and KDE widget systems are compiled. In a week or so they will probably be in Debian, in time for Lenny. Improvements since 0.8.2 release are:

• Native fullscreen support (from AS) implemented.
• Long command-line options properly supported.
• View detailed movie information from GTK gui.
• Added an option in Preferences to initially display a movie as a blank (”Click here to start”) screen.
• Added “dump” GUI to dump a movie to disk.
• Improved Cairo rendering performance.
• Fix support for OpenOffice Impress SWF exporter (malformed..)

Lucas asks about how he hates reformatting paragraphs in text documents he keeps in Git, because it creates unnecessary noise in the diffs. He also hates, though, not reformatting the paragraphs, because lines can become very long then, and he wants some kind of “smart formatter”. My take on this is that you shouldn’t change your preferred workflow to adapt it to how your tools work, but to adapt your tools to work well with your preferred workflow (here, reformatting paragraphs). Or, even better, reading the manual page to discover that your tools can already adapt to it. In particular, for this problem, I recommend reading diffs for text documents with git’s --color-words. A couple screenshots to show it in action:

While free speech rights are valued and recognized in most liberal democracies, the degree and scope of these rights are by no means uniform. The United States, which has the most expansive free speech protections in the world, actually stands apart as this New York Times article on the subject makes clear. The article covers familiar ground (at least for those who follow free speech debates) but it does so well and discusses an interesting case now unfolding in Canada, concerning a pretty inflammatory magazine article denouncing Islam. The magazine is currently under trial for violating provincial hate laws.

As I am one of those who have read “able” instead of “unable”, I had to find a really cheap flight. This may sound crazy, but an Iberia flight to Buenos Aires from Berlin costs far less than from Lyon (where I live) or even from Madrid: 781.12 EUR from Berlin instead over 1,200.00 EUR from Madrid and over 1,300.00 EUR from Lyon (in both cases with a change in Madrid Barajas). I wonder if Iberia pays you 420,00 EUR if you flight from Berlin to Madrid… Now I have to find a cheap way to go to Berlin from Lyon (probably an EasyJet flight). I plan to spend a few days of holiday in Berlin before flying to Argentina.

I have this IPv6 issue with my ADSL. It's kinda bizarre and I'd be interested in whether anyone has any ideas or has seen anything similar themselves.

I don't get IPv6 packets smaller than 71 bytes (excluding the PPP header).

Small IPv4 packets? No problem. Sending small IPv6 packets? Also fine. Getting them back again? No go.

I first noticed the problem because I couldn't get to Google's IPv6 site. I ended up getting some quite useful help from various Google engineers, who were prepared to take my report seriously even though I'm just an end user these days. I've promised to get back to them with what the problem was when I find out. If.

My ADSL is provided by Enta, through a reseller. My parents also use them, but via a different reseller. My understanding is this shouldn't make a difference, as Enta are responsible for terminating the connection in both cases. On my parents' line IPv6 seems to work fine. They have a Linux box with a Conexant based PCI card. I have an AR7 router running OpenWRT. My first thought was that it might be some weird hardware issue, so I dug out my Speedtouch, hooked it up to my laptop and tried that. Still no small packets. I tried a different AR7 ADSL router. I downgraded to a 2.6.16.x kernel (which is what my parents are on). All gave the same results; anything over 70 bytes would get through fine, anything under wouldn't.

So I took my router to my parents'. I unplugged their kit and plugged the router in, with only my laptop attached. I left it configured with my username/password. And it worked. Small packets came though fine. To make absolutely certain I tried the same thing again at home. And it didn't work.

Now. Exactly the same kit at my end in both instances. Exactly the same ISP at the other end (who confirm all their end points are configured identically and even if they're not I'd have expected to get a duff one at my parent's once or twice and a working one at my end given the number of reconnections I've made over the period of trying this all out). That leaves BT as the variable (we're about 100 miles apart, so very different exchanges).

My questions to you, the reader:

• Does this line of logic seem reasonable? If not, what have I missed?
  
• Have you ever heard of anything similar? I know BT used to have an issue with IPv6 and PPPoE and corruption of the packet length field, but I'm using PPPoA (I've tried PPPoE as well and it wasn't any better).
• Is there an ATM packet sniffer for Linux, along the lines of Wireshark? If I could hook up the Speedtouch to my laptop and try a connection while sniffing the ATM packets I could see if there was any corruption or oddities happening at that level, which might provide a clue.

Update: will-h has pointed out it's 70 bytes excluding the PPP header, not including it.

Personally, I like Friday 13th. It's usually been pretty good for me. But for this one, I won't be surprised if computer abusers are planning some big attack tomorrow. I've just spent a big chunk of my day upgrading and securing some of the websites that our free software cooperative supports for a customer. The number of attacks in the access logs is surprising - and I've been fixing other people's cracked servers for over a decade. It makes me wonder if someone is finding and recruiting exploitable systems for tomorrow. If you have a website, please check that any web applications on it are installed correctly and the latest secure versions. I've been seeing a lot of attack attempts for Joomla and WordPress in particular, even on sites which don't run them. That says something bad about either the success rate of attacks for them, or the stupidity of their attackers. In our case today, the damage seems to have been minimal (touch wood!), with the customer merely being banned from some networks for a while. It could be so much worse, like this BBC News report about Cotton Traders Card details stolen in web hack (which is part of why I suggest small online shops avoid storing credit card details on their site - leave it to the payment gateway). Finally, there are some new scams like Conmen abuse web address checks on the horizon for online shops, so make sure you've got your 3D-Secure rules set correctly by now and be cautious about sending goods before you're sure you've got the money. I think all web card payment systems are a risk, so please try to limit your risk. Update: If you do get attacked, try to help track the attackers down so we can get other results like the Jail sentence for botnet creator. I wish our governments would concentrate on toughening up blatent computer misuse law and stop tightening copyright law in secret.

A common myth in the computer industry seems to be that ECC (Error Correcting Code - a Hamming Code [0]) RAM is only a server feature. The difference between a server and a desktop machine (in terms of utility) is that a server performs tasks for many people while a desktop machine only performs tasks for one person. Therefore when purchasing a desktop machine you can decide how much you are willing to spend for the safety and continuity of your work. For a server it’s more difficult as everyone has a different idea of how reliable a server should be in terms of uptime and in terms of data security. When running a server for a business there is the additional issue of customer confidence. If a server goes down occasionally customers start wondering what else might be wrong and considering whether they should trust their credit card details to the online ordering system. So it is obviously apparent that servers need a different degree of reliability - and it’s easy to justify spending the money. Desktop machines also need reliability, more so than most people expect. In a business when a desktop machine crashes it wastes employee time. If a crash wastes an hour (which is not unlikely given that previously saved work may need to be re-checked) then it can easily cost the business $100 (the value of the other work that the employee might have done). Two such crashes per week could cost the business as much as $8000. The price difference between a typical desktop machine and a low-end workstation (or deskside server) is considerably less than that (when I investigated the prices almost a year ago desktop machines with server features ranged in price from $800 to $2400 [1]). Some machines in a home environment need significant reliability. For example when students are completing high-school their assignments have a lot of time invested in them. Losing an assignment due to a computer problem shortly before it’s due in could impact their ability to get a place in the university course that they most desire! Then there is also data which is irreplaceable, one example I heard of was of a woman who’s computer had a factory pre-load of Windows, during a storm the machine rebooted and reinstalled itself to the factory defaults - wiping several years of baby photos… In both cases better backups would mostly solve the problem. For business use the common scenario is to have file servers storing all data and have very little data stored on the PC (ideally have no data on the PC). In this case a disk error would not lose any data (unless the swap space was corrupted and something important was paged out when the disk failed). For home use the backup requirements are quite small. If a student is working on an important assignment then they can back it up to removable media whenever they reach a milestone. Probably the best protection against disk errors destroying assignments would be a bulk purchase of USB flash storage sticks. Disk errors are usually easy to detect. Most errors are in the form of data which can not be read back, when that happens the OS will give an error message to the user explaining what happened. Then if you have good backups you revert to them and hope that you didn’t lose too much work in the mean-time (you also hope that your backups are actually readable - but that’s another issue). The less common errors are lost-writes - where the OS writes data to disk but the disk doesn’t store it. This is a little more difficult to discover as the drive will return bad data (maybe an old version of the file data or maybe data from a different file) and claim it to be good. The general idea nowadays is that a filesystem should check the consistency of the data it returns. Two new filesystems, ZFS from Sun [2] and BTRFS from Oracle [3] implement checksums of data stored on disk. ZFS is apparently production ready while BTRFS is apparently not nearly ready. I expect that from now on whenever anyone designs a filesystem for anything but the smallest machines (EG PDAs and phones) they will include data integrity mechanisms in the design. I believe that one such features become commonly used the need for RAID on low-end systems will dramatically decrease. A combination of good backups and knowing when your live data is corrupted will often be a good substitute for preserving the integrity of the live data. Not that RAID will necessarily protect your data - with most RAID configurations if a hard disk returns bad data and claims it to be good (the case of lost writes) then the system will not read data from other disks for checksum validation and the bad data will be accepted. It’s easy to compute checksums of important files and verify them later. One simple way of doing so is to compress the files, every file compression program that I’ve seen has some degree of error detection. Now the real problem with RAM which lacks ECC is that it can lose data without the user knowing. There is no possibility of software checks because any software which checks for data integrity could itself be mislead by memory errors. I once had a machine which experienced filesystem corruption on occasion, eventually I discovered that it had a memory error (memtest86+ reported a problem). I will never know whether some data was corrupted on disk because of this. Sifting through a large amount of stored data for some files which may have been corrupted due to memory errors is almost impossible. Especially when there was a period of weeks of unreliable operation of the machine in question. Checking the integrity of file data by using the verify option of a file compression utility, fsck on a filesystem that stores checksums on data, or any of the other methods is not difficult. I have a lot of important data on machines that don’t have ECC. One reason is that machines which have ECC cost more and have other trade-offs (more expensive parts, more noise, more electricity use, and the small supply makes it difficult to get good deals). Another is that there appear to be no laptops which support ECC (I use a laptop for most of my work). On the other hand RAID is very cheap and simple to implement, just buy a second hard disk and install software RAID - I think that all modern OSs support RAID as a standard installation option. So in spite of the fact that RAID does less good than a combination of ECC RAM and good backups (which are necessary even if you have RAID), it’s going to remain more popular in high-end desktop systems for a long time. The next development that seems interesting is the large portion of the PC market which is designed not to have the space for more than one hard disk. Such compact machines (known as Small Form Factor or SFF) could easily be designed to support ECC RAM. Hopefully the PC companies will add reliability features in one area while removing them in another.

• [0] http://en.wikipedia.org/wiki/Hamming_code


• [1] http://etbe.coker.com.au/2007/08/01/ecc-ram-in-a-cheap-machine/


• [2] http://en.wikipedia.org/wiki/ZFS


• [3] http://en.wikipedia.org/wiki/Btrfs

Share This

In a perfect world, when we design some aspect of our infrastructure, we'd get it right the first time, and would never have to change our design once it had been deployed. Back in this world, however, we regularly have to change things as we expand our infrastructure. Sometimes we made a mistake originally, other times new requirements pop up. In either case we will end up doing things differently in the future than how it was done in the past. The danger here is that if you only create your new machines or services differently, you've got effectively two separate and different systems to maintain. This may not sound like much, until it happens again... and again... and again... and then suddenly you've got 18 different ways of setting up backups, depending on how long ago you set it up and (if you're really unlucky) who did it and what the phase of the moon was at the time. If you've been here before, you probably remember the pain of having some disaster happen and needing to fix it NOW NOW NOW, only to wade into the setup and realise that it's been done in a way that (you thought) died out six months ago -- and so you don't really remember how it works, and yeah, the documentation's been updated so many times since then that it doesn't mention the old way of doing things, and here comes your boss to ask how long it's going to be until it's all working again... If you haven't had this experience (yet?), you'll have to trust me when I say that it's no fun to hit an older, out-of-date system. It's especially painful because the most common reason you change things is because the old way sucked. So you turn up at a critical moment to fix something in a poorly documented and sub-optimally configured system. Fun, fun, funnity fun. There are only two ways to avoid this problem: never change the way you do anything, or else plan your changes so that retrofitting is part of the plan every time you're modifying an existing service. Assuming that never changing anything isn't an option, you need to plan to retrofit. When you're putting together the design for your system change (you do design your changes, right?) you need to audit what's out there, determine what's needed to bring it all up to date, and put together a plan to make that happen. It's like documentation and testing -- if you don't make an explicit effort to make it happen, it'll never get done. That sounds like a lot of work, and it is. Luckily, if you're already working in a well-maintained infrastructure you should only really have one existing config to upgrade, which shouldn't be too painful. However, if you've got a lot of machines to change there's no way around the fact that they've all got to be changed, and that can take time. If you accept that you don't want configuration skew, you can start to think about how to engineer your systems and processes to make it less of a hassle to keep everything up to date. Putting some extra thought into how you set things up in the first place so that it's easier to update is at the heart of this. Automating deployment is an easy way to take some of the pain away from rolling out new configs, but there's also plenty of smaller decisions that help with updating configs: putting everything in revision control, making extensive use of templating and pulling out common config fragments, and making sure that you've got good notes and records of what has been done where. The more you automate your deployment and maintenance, the less pain you feel when you need to retrofit. With something like Puppet, you can eliminate a lot of the pain because you're describing what you want done for all the relevant machines, and then the machines themselves work out what needs to be done to bring themselves up to date. With an advanced automation system in place, you can say "I want all my mail servers to have setting X turned on" and off they go and set the option. Or you might want to have some of your mail servers to have a different config setting, triggered based on a config setting or class of machine. Of course, you might not already have that config setting or class defined, so you'll need to add it. Don't forget to retrofit that new config setting or class to your existing machines. That might involve finding the config for all the existing machines and modifying them. Yep, no matter how much automation you've got you can't get away from the need to retrofit, but given the choice between editing a bunch of config files on my local machine (with all the power of my text editor to back me up) or logging into dozens of machines all over the globe to edit their configs and restart services (with all the risks of making a mistake) I know which one I'd choose...

Yes, Manu Chao was really home yesterday in Paris Bercy. And he was obviously feeling like being home. The concert began at 21:30 and ended up at 00:30. Yes...that makes 3 full hours concert. All that for 25 euros. The crowd support, dance, participation was *amazing*. I often go to concerts in the Bercy arena and never saw the crowd in the upper rows being stood up all concert long. Radio Bemba played their usual tracks first. As usual, the very Manu way to mix songs, themes from all his carreer and mix them up, distord them and make new songs from old ones. This is what always made Mano Negra, then Manu Chao oncerts unique experiences. Just imagine 20,000 people singing Clandestino a capella, most of us not knowing any damn word of Spanish... After about 2 hours of magic without any stop, the very special moments came in. Manu, Gambit, Majiv (what a guitarist when playing rumbas de Barcelona!), Julio (de Barcelona!)...and all others were just feeling like being home with a few friends. So the encores lasted...and lasted...and lasted. They just didn't want to stop (Manu probably said about 3 or 4 times "c'est fini"). Then, they did something I never ever saw in a big 20,000 people concert since my first one back in....long time ago. Manu asked "do you have 5 more minutes?". So, they stopped for 5 minutes to get the guitars re-accorded(sp?)....the crowd just...waited...and the gig re-started again with songs from "Si Sib rie m' tait cont e", the special book-album he made with friends, inspired by the sad winters he spent in Paris in his early years. Soooooo special and, believe me, that *was* special. Seeing all roadies, crew, friends just dancing backstage and partying clearly showed this was not to always happen (this will probably happen again on today's concert). He was just feeling like home. And so were we. Not wanting to leave and shut down the light. Finally, at 00:30, all of us were dead tired and we just hugged around with Manu and left. Just like old friends. I don't know if that will happen everywhere in the upcoming tour (some dates in France, some in Europe, a few in USA....nothing unfortunately in South America as of now)....but if you have the opportunity to go to Radio Bemba concerts, just do it. And (IRC reference), really, Erinn, this was not about "ethnic music for white people" (really wondering where you got this idea...or if you were just kidding me). I dunno what Manu ever did to kill your ears, but just try again and, even more important, go to the gig in your fair city on August 22nd. Radio Bemba concerts will be cheap, about half the price of regular bug size concerts....just use that opportunity.

Mr Levsen and Mrs Rodrigo will land in EZE on Wed, July 30th, flight IB6845 (Iberia) at 19:40.

We are now just about to celebrate the rise in oil prices and our my procastinating in booking (2428.72 EUR in total) with a cold Mahou beer. But I am thankful I didn t need to ask for sponsorship this year.

See you down there!

After thinking it over a couple of times, I did it. I told you here about the World Naked Bike Ride. Thousands of bikers, in over 130 cities around the world, voiced their concerns about the lack of caution drivers have towards us, about the abuse of fossil fuels for urban transportation, about the easy we are not to be seen. Many among us have been run over by careless drivers (in my case, no consequences except a broken helmet - And yes, MJ: although the impact was on the flat surface of the road and not on the kerb, the strength of the impact still amazes me). We feel naked against the motorized traffic. So, the WNBR decides to show it by taking the streets of our many cities - Naked.
It was a completely different experience of the massive naked Spencer Tunick photo, as we were there not just to show our freedom and enjoy, but to get the people to look at us. There were some of the same elements of comradeship and trust we had there (and, of course, that many of us learnt in Finland when we became GNUdists at DebConf 5's unforgettable saunas).
Anyway... I did not make the full route (I rode Chapultepec-Z calo-Diana, ~15Km, but missed the Diana-Gandhi-Cibeles part, maybe some 5Km) as I had an appointment I was already late for. But it was a unique, great experience. If you are interested, we got a fair share of press coverage. Oh, and I must say: I am famous now. And in my favorite newspaper, nothing less :).

I'm impressed at how much Google street views are growing. From a high level view, it looks like some sort of 1950's B movie alien invasion: link. What's even more impressive are some of the out of the way places they've been: link. I can't imagine what they were doing up that road. Perhaps they wanted someplace secluded to go smoke a joint, and they left the camera rolling? It's sure a beautiful road in any case - it looks like a great place to go for a bike ride.

Watched De Gr nne slagtere (great black comedy even if it moves a bit slowly. I think if you have to chose you'd better watch Adams bler with which it shares writer/director Anders Thomas Jensen and a big part of the cast). And this just has to be said: I can't believe anybody could call eXistenZ “quite a good see”. One of the worst movies I've ever seen, on a level with “Tweed” (a late 90s Bond parody I distinctly remember having seen but can't find on imdb right now.) I agree with Adeodato's assessment of Billy Elliot, though.

We eventually released liquidsoap 0.3.7 !!
For those who don't know about this software, liquidsoap is a scripting language designed for building audio streams. It was initially aimed at web radios, as an alternative shoucast/icecast source client, but quickly turned to a much more general tool.
For those who read debaday, I already blogged about it few months before. There, you'll find more explanations on how the program operates.
A simple example could be: #!/usr/bin/liquidsoap # (...)

Lev t t pour tre frais et dispo pour la premi re s ance, je me suis pr par rapidement. La nuit a t assez courte, couch vers minuit pour finaliser le support de cours. Enfin, il est pr t. J'ai juste quelques ajustements y apporter et il partira pour l'impression. Mieux vaut tard que jamais ;) J' tais donc pr t 7h30 pour un petit d jeuner ma foi agr able au bord de la piscine et accompagn de Tisserin et de la superbe Grue Couronn e quelques dizaines de centim tres de moi ;) Un petit tour au coin wifi internet pour envoyer 2 ou 3 mails et me voil attendre. Tout compte fait, j'ai d attendre jusqu' 10h30 pour que l'on vienne me chercher. La salle n' tait pas disponible, les petits tracas administratifs de derni re minute. Une fois sur place l'ENA (Ecole Nationale de l'Administration) je me suis lanc pr senter le syst me 25 personnes. Mais impossible de faire fonctionner loe r troprojecteur mis ma disposition. Pb de configuration Xorg voir ce soir. Donc j'ai projet mes transparent fait avec MagicPoint g n r s en HTML sur une machine sous Windows. Apr s une br ve introduction nous voil partis dans le vif du sujet. Les stagiaires taient tout ou e et donc je n'ai pas m nag les informations dispens es. Repas 14h frugal pour ma part, je n'avais pas trop faim. Poulet en sauve, crudit s, riz, pommes de terre. Me voil reparti 15h pour la deuxi me partie de la journ e. J'ai demand aux stagiaires de se pr senter... Bon, il va falloir que je fasse les bases des syst mes Unix pour tout le monde sans exception. Seance fini vers 18h o je suis rentr l'h tel, seul. Donc au programme de la soir e, remplir mon billet quotidien, r cuper la conf Xorg me permettant d'utiliser le r troprojecteur, manger et ensuite rododo ;)

Things in your computer that you do not have the source code for:

• Your BIOS
• Your video BIOS
• Your ACPI tables
• Your ethernet card (in almost all cases)
• Your wireless card (in almost all cases, though there are efforts to write open source firmware for Prism 54 and Broadcom hardware)
• Your CPU microcode
• The embedded controller that responds to things like the power button being pressed and makes your computer go and controls your fan and turns on LEDs and the like
• Your keyboard controller (which is often the same thing as above)
• The firmware running your disks
• The firmware running your DVD drive
• In many cases, the firmware that runs your disk controllers
• For AMD and Nvidia, the code that's running on your graphics card
• The firmware running your trackpad

Anyone think of anything I've missed?

Things people have suggested:

• Laptop batteries
• Modems (wired and wireless)
• Embedded controller in any docking station
• UPSes

More suggestions:

• Some sound cards
• Network card boot roms
• Fingerprint readers
• USB card readers
• Flash media
• USB mass storage
• Webcams
• Touchscreens
• Any lights out management
• TPM firmware
• Monitor itself
• Intel's AMT madness hardware
• Mice
• Various firewire and USB peripherals

Dirk often blogs about running and generally posts his running paces as minutes/mile. Well, we're both geeks, so numerical challenges are logical for us..:) I follow my own 'performance' (or lack of) in terms of speed in kilometers per hour. Which makes the conversion fairly hard. Just to confirm that we live on different planets, this week, I tried to get a rough idea and then calculated my usual pace (for distances ranging from 15km to 25km, as well as short distances such as 5km):

• On short distance (5km), my best pace is currently 11.75km/h, which turns to 5'06" per kilometer, or 8'19" per mile. I run such distance fairly rarely. It probably could be improved to about 12km/h. For those who care, that makes 25 minutes for 5000m while the world record is less than 13..:-)
• On medium distance (15km), my pace is around 10.75km/h, turning to 5'33" per kilometer, or 9'05" per mile.
• On my longest distance (27km), the pace was 10.16km/h, turning to 5'54" per kilometer, or 9'37" per mile (however, that time, I had to stop a few times to have a look at my map as I was using new paths). I once ran 26km at 10.5km/h, so nothing really reproducible there, still.

The challenge I give myself currently is not really running faster (I apparently reached a level which I can't easily break), but more running longer. My current estimate is that 30-35km could be achievable (I only need to find enough time for this) while a marathon is still out of question. Frankly, I couldn't even imagine this when I (re)started running, less than 1 year ago. Anyway, for people going to Debconf, I plan to gather the Debian runners and share the pleasure of running together during the conference. I'll probably open an "event" for this in Pentabarf. Of course, the point there will be sharing the pleasure, not performance. So, even if you are a very occasionnal runner, you're welcome.

What's the weather like in Debian? One of the cool things developed during EDOS (now Mancoosi) has been edos-debcheck. Using it it is possible to check (incredibly quickly) whether some package in a given distribution cannot be installed according to its dependencies. When there are such packages it usually means that the distro is buggy s it is shipping uninstallable packages (there are some corner cases, but they are rare). In fact, edos-debcheck has been run daily (as a service maintained by Ralf) on Debian's main suites and some derivatives for years now. The resulting list of uninstallable packages is linked from http://edos.debian.net and is being used by the QA team; I've no idea if it is being used by the Release Managers too, but it probably should be. A cool toy built on top of edos-debcheck was the Debian weather (part of a more generic service called Anla, I'll blog about it sooner or later ...). Debian weather basically used to present the status of a given Debian-based distro in term of how many uninstallable packages were shipped using the weather metaphor: the fewer the uninstallable packages, the better the weather. I wrote "used to" because Anla was stopped about 1 year ago, and is being re-engineered these days. In the meantime it was a pity not to have the Debian weather (as Enrico pointed out with me), so I spent some time to resurrect it on top of edos-debcheck daily runs: Debian weather is back, enjoy!