Today was the MCC Flatlander bike ride, or as Terah put it, the day we build a cistern with our bicycles.

I've never gone this far on a bike in a single day before. I rode 35 miles for the Flatlander, plus I rode to and from home, for a total of 55 miles (88km). When I got home, I was sore pretty much all over. But it was a good experience, and I'll surely do it again next year.

Yesterday evening, I was getting our bikes ready. I noticed that Terah's bike had a problem: a large gouge that had punctured the tube and ripped apart part of the tire. I had a spare tube on hand, but not a spare tire, and it was too late to get one. I went inside to discuss it with Terah. After a few minutes of pondering, she remembered that the local bike shop I go to was a sponsor of the Flatlander -- maybe if I call before they close, they'd bring one. I called, the owner happened to answer. I explained the situation, and she said, "Of COURSE will get you all fixed up! Look for me at just after 7." I gave her the tire specs, and sure enough, there she was this morning. She also did the repair and tossed in a free tube. I'm continuing to be a big fan of Bicycle Pedaler.

Here's my shirt tag for the day:



So after I got home, the lawn was way overdue for some mowing. Hence the extra mile on a mower.

After releasing a new Free Software project to the world, you may be interested to see it included by the main Linux or Free Software distributions. After all this is the easiest way for end-users to download and install your software.

Here are a couple of technical details that will increase the chances that your project will be picked up by a distribution.
Can I distribute this software?The first question that a distribution maintainer will need to answer is this one: can my distribution legally distribute this piece of software?

There are two ways you can help here:

• Make your chosen license clearly visible (normally in a file called COPYING or LICENSE).


• Include a clear copyright statement in your documentation (inside README for example).

Once your software has past this check, the next question will be of course: does it actually work?
Will it work on my distro?To answer this question, the maintainer will have to install the software and figure out all of the external dependencies that need to be installed at the same time.

Therefore, your tarball should include:

• all of the steps (and exact commands) that are necessary to install your software on a standard Free Software distribution


• a list of the external libraries and tools that your software requires to run

What's changed?Another element that can make life easier for the maintainers of your software in downstream distributions is to include indications of what changes from one release to the next.

One important detail is to use a sane versioning system. In a nutshell, this means:

• Version numbers should always be increasing (e.g. in normal ASCII sorting, 1.0pre1 comes after 1.0).


• Any change to the contents of the tarball should trigger a version bump.


• The difference in version numbers from one version to the next should give an indication of the magnitude (minor v. major) of the change.

Another thing that you should include is a changelog (normally in a file called Changes or ChangeLog). This document will be used by maintainers to decide when to upgrade to a new version and to figure out which bugs may be fixed by the new version. It should contain:

• release date
• version number
• summary of the changes since the last version

Finally, to make sure that distro maintainers don't miss new releases of your software, make sure you sign your project up on Freshmeat and announce new releases there.
Proposing your Package to DistrosOn Debian, the main way that users and upstream developers can suggest packages for inclusion in the archive is through the Debian Bug Tracking system. Bugs are filled against the special wnpp (Work-needed and Prospective Packages) pseudo-package and are titled something like RFP: superfoo -- bringing more foo to the desktop where RFP stands for "Request For Package".

Alternatively, if you are a Debian/Ubuntu user, you may also want to build and maintain the package yourself. In which case, you will need to find a sponsor.

Other distributions have different procedures. Feel free to leave a comment explaining what these may be.

More detailed information on getting packaged for Debian is available on the Debian wiki.

This is the highest bug number as of now. Will we turn bug #500000 this week-end? This is fairly unlikely. So, the best chances to win the bet are for Rene Mayorga. If I'm wrong and #500000 is reached before Sunday 23:59 UTC, then Fabian Fagerholm wins the bet. Suspense... Fabian, I *will* watch your own bug reports! MBF forbidden for you...:-)

Writing the software is only one component of a successful Free Software project. If you want to build a community around your pet project, there are a number of important things you need to do but which typically fall outside of the "coding" job. One of these tasks is choosing a license.

A license choice is very personal since it involves putting in writing the permissions and protections that you want to give with respect to your code. However, your choice of license will have a number of implications.

"A license can ruin a perfectly good piece of software"

- Jon Stevens

Whenever possible, try to avoid:

1. writing your own license
2. choosing a license which is incompatible with the GPL

To make sure that your project can be included in a Free Software distribution like Debian and to make your code most useful to other people, it is highly recommended that you choose a standard license. Common ones include the GPL, LGPL, the Modified BSD license and the Apache license. You can find a more exhaustive list on the Free Software Foundation website.

Common licenses are well understood by the community and have stood the test of time. Their compatibility with other licenses are also much clearer. This is important if you'd like your code to be reused inside other projects, but also if you want to include code from other sources inside yours.

The standard licenses are also more likely to make sense in different countries. The latest version of the GPL, for example, was reviewed by lawyers from all over the World. Whatever you come up with is unlikely to have this level of scrutiny. If you think that the existing licenses don't fit your needs, please write to licensing@fsf.org to discuss your specific situation and avoid practical problems.

So take the time to familiarize yourself with common licenses and then decide for yourself what protections you want to give to your code. Then, add the following to your tarball before you publish your source code online:

1. a copy of the license
2. a clear copyright statement in a file like README
   

Here's an sample copyright statement for a piece of software under the latest version of the GNU General Public License:

Email-Reminder - Receive emails for events like birthdays and anniversaries
Copyright (C) 2004-2008 by Francois Marier (fmarier@gmail.com)

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.

This helps distributors and contributors by explicitly stating the license version as well as the name and contact details of the copyright holder.

Next up: some tips and ideas about what to provide along with your source code

Hectic days... The last l10n teams are waking up and alarming messages seem to be sent in various places after my various blog posts, messages to lists, private messages, etc. (I think that the only place where I haven't yelled out for D-I translations is the street I live in). As of now, 7 languages are still in danger to be de-activated: Amharic, Estonian, Latvian, Macedonian, Northern Sami, Albanian, Tagalog Among these, Latvian and Macedonian should make it: Arangel Angov for Macedonian and Aigars Mahinovs for Latvian will probably complete the required minimum. For others, I'm afraid that Estonian, Albanian and maybe Tagalog will be deactivated. I have to think about it. I will be very sad for all of them if I have to do it. But I haven't got news from these translators for ages and I haven't been able to find any possible backup translator. For Albanian and Tagalog, that's not a surprise. For Estonian, I call this very disappointing. Northern Sami is a special case: this is the language of the Sami people in Norway, teached there in schools and important for DebianEdu...which originated in Norway and has been the pilar of D-I development a few years ago. As finding Sami translators is very difficult, I will probably keep the language (also, because it has a solid backup with Norwegian). Amharic is also special for me. The l10n effort is very specific: the translator works on ships all around the world, from his words, and can only communicate with me when he reaches a harbour. He has also been very committed to reach completeness (which he did) and the translation was only fuzzied by last minute changes in August. I'll probably fight to keep that language in D-I..:-) Still, there's one day left. So if your language is not 100% on D-I statistics for level 1, then try to do something. And, guess what? After the deadline is reached, I'll still have work to do: get as many levels 2-5 translations completed. All of these belong to regular Debian packages so they're not dependent on D-I release schedules!

Readers of my blog will want to update their URLs. As of right now, I've moved my blog to http://blog.fortytwo.ch/.

To this… (and I know there are readers of the blog in Manchester and close by who just may be interested in the a one-day seminar and evening lecture on the 1858 cable and later transatlantic communications link). Full details below. ***
2008 marks the 150th anniversary of the first communications link laid beneath 1600 nautical miles of the Atlantic Ocean. That telegraph cable was the first in a series of cutting-edge technologies enabling fast and accurate communication between Britain and the United States of America, linking the old and new worlds. To mark the occasion, the IET in conjunction with the Museum of Science and Industry, Manchester, are holding a one-day seminar and evening lecture on the 1858 cable and later transatlantic communications links, including wireless and satellite, on Tuesday 28th October 2008. Both events are open to the public and admission is free of charge, but pre-booking is a must. The programme is given below. Both events will be held in the Cardwell Theatre, MOSI and there will be a small exhibition on the history of transatlantic communications to accompany the event. To register for the seminar and/or the lecture, please contact Anne Locker (details given at the end of the email). SEMINAR 1000-1030 Arrival and coffee 1030-1045 Bob Martin-Royle :Chairman s welcome, introduction and overview 1045-1115 Neil Barton: First steps to transatlantic - crossing the Irish Sea 1852-1854 1115-1130 Donard de Cogan: Background to the 1858 telegraph cable 1130-1145 Pauline Webb: John Pender and Manchester s contribution 1145-1215 Donard de Cogan: Insights into the landing of the 1858 cable 1215-1230 Pat Wilson: Lord Kelvin s contribution to submarine telegraphy 1230-1300 Questions and discussion 1300-1400 Lunch 1400-1430 Bob Martin-Royle: Marconi and the first transatlantic wireless links 1430-1515 Phil Kelly: TAT1 (includes film) - the first telephone cable 1515-1545 Tea 1545-1615 Des Prouse: Telstar - the birth of transatlantic satellite communications 1615-1630 Transatlantic communications: the present and future 1630-1700 Questions, discussion and closing remarks EVENING 1800-1830 Light refreshments 1830-1930 Nigel Linge: An interactive public lecture on The Transatlantic Telegraph Cable - the birth of global communications 1930- 2000 Questions and closing remarks Regards, Anne Locker
IET Archivist The Institution of Engineering and Technology
IET

Savoy Place
London
WC2R 0BL
United Kingdom

The IMSc recently installed a desktop machine for me that is powerful enough to run Xen virtualised domU's. (My previous desktop machine was removed at my request; explanations at a later date!) One task was to get Fedora Core running under this Debian Etch machine. Since the information required for this task was rather difficult to find (rant later!), here is a quick 2-paise tip (to borrow a phrase from the linux gazette) on how to get Fedora Core running under a Debian Xen machine. The helpful packages under Debian are xen-tools and rinse.¹ Since the latter is only available with "lenny", this requires an schroot installation about which I have written elsewhere. So let me assume that we have a lenny chroot inside the dom0 in which xen-tools and rinse have been installed. One can either bind mount /etc/xen from the dom0 into the lenny chroot or one can just create this directory to hold the configuration file for the domU to be created. Creating the domU is as simple as:

xen-create-image --ip=192.168.17.71 --hostname=fedora \
  	--arch=amd64 --lvm vg0 --install-method rinse \
  	--dist fedora-core-8

   

with ip address, hostname, lvm volume group and arch chosen appropriately. (Be careful and choose a hostname that does not match a hostname that you have already used in the same Xen system). This will create the logical volumes /dev/vg0/fedora-disk and /dev/vg0/fedora-swap containing the appropriate images for use with the Fedora domU. Before you can boot into this domU there are some minor issues you need to fix; see #499476. The fixes are to create /etc/shadow and /etc/gshadow and set a usable password as follows. Mount /dev/vg0/fedora-disk somewhere and chroot to it. Then run the following commands:

  pwconv
  grpconv
  passwd root

   

Then exit the chroot and unmount /dev/vg0/fedora-disk and then exit the lenny chroot. If necessary, copy the file etc/xen/fedora.cfg from within the lenny chroot to /etc/xen/ in the dom0. You should now be ready to boot your Fedora Core 8 domU with

  xm create fedora.cfg

   

It would be nice if one could install Fedora Core 9 the same way; see #499477.

Yesterday on NPR's Diane Rehm show, one of the commentators made this point: (paraphrased)

The "bad debt" that all the banks are carrying, and that everyone talks about as the cause for this problem, is mortgage-backed securities. It's bad because there are so many foreclosures, meaning that people aren't paying back their loans. And that's a problem because the banks turn out to have a much less solid investment than they thought.

Instead of spending $100 billion or more bailing out bank after bank, the government ought to spend that money to stabilize the real estate sector. Invest it in programs to help people stay in their homes and avoid foreclosure. This will help both the individuals, and simultaneously fix the problems with the banks, because the mortgage-backed securities will regain their value.

Sounds way too sensible to do, doesn't it?

After all, we wouldn't want to encourage risky behavior on the part of the common folk that don't know better. No, we only want to encourage that with our large multi-national financial institutions that can wreck the entire economy.

I make heavy use of pdfcrop (the version by Heiko Oberdiek included in texlive) for printing, as it allows to remove all the white spaces around the text before nupping and printing. However, with recent ghostscript, the bounding box detection is dreadfully slow, anything from one to ten seconds for a single page ! When you have a 60 pages article to print, it can be quite tedious... Well, I've just discovered that the --trim option of pdfnup can do very similar things too. It removes a given amount of margins on the side, with the syntax 'left bottom right top'. Most of the time, a well-thought pdfnup --trim ... will work as well as pdfcrop while in the meantime being much faster...

Myself and a colleague were both getting Joe-jobbed yesterday. I had an easy time telling Exim to reject mine at SMTP time, but the colleague receives mail on our only Plesk server, so it’s using qmail. I’ve noticed before that qmail admin tools are primitive and incomplete, so I looked for the appropriate rocks to bang together to put this fire out. (I think I just sprained a metaphor.) My best attempt so far is to edit the user’s .qmail file to start with a pipe to a command that exit 100s if it detects an error for an email which the user obviously didn’t send (wrong email client or whatever). qmail understands code 100 as a hard error, so I think that should generate an SMTP error, but I didn’t figure out from the logs whether it was SMTP-time or later and my testing was inconclusive. I suspect Plesk will remove my pipe when the user next edits their email account, too. How do qmail/Plesk users not drown in spam? In related news, I’ve started getting “Challenge Response” emails from users of Merak Mail Server Software for emails I never sent. I’m answering the challenges so that challenge-response users get spam if their server spams me. Challenge-response is evil - I don’t want spam from your mailserver just because you accepted spam that said it was from me. If you are using Merak Mail Server Software, change away now! One of my current anti-spam tactics is to read my email in batches (which Suw suggests is a good idea) and group messages which look “similar”. Very similar messages appear for very few reasons: people resending messages, mailing list threads, stuff from spam-nets and a few others. Apart from spam-nets, most of the others match one of a few keywords. My current method of doing this is part-automatic and part-human. Are there automated anti-spam tools which exploit this local similarity? I think DCC used to include this idea, but then there were software patents and hoo-ha and I stopped paying so much attention. Finally, a small discussion has broken out in the comments of Is Yahoo Now Even Worse On Spam? about whitelisting and business-critical uses of free webmails.

Being an American guy married to an Italian woman and living in Austria, I don't really have a problem with "globalization". Actually, I'm something of a fan, which is one reason I'm disappointed in the globalization of Amazon's services. If you order a book from Amazon.com in the US, it will be shipped to you from the nearest shipment center. If you go to a large site like Google, Microsoft, or Yahoo, it's quite likely that they provide services in your language. Amazon, however, appears to be completely split up along country lines. Your amazon.com account is completely seperate from your amazon.co.uk account, and amazon.de isn't even available in English! This completely violates the sensible reasoning behind the two features outlined above. If you're somewhere like Italy or Denmark or Eastern Europe, you should be able to log in to amazon.com, in your language, order a book, and have it shipped from the nearest shipping center. Instead, you have to log in to each site (they don't share account info), which is only available in one language. So, for instance, an English speaking guy in Austria wanting to order books from the nearest country with an Amazon site goes to amazon.de and finds that there is no option to get the site in English. If I want to order from amazon.co.uk I have to enter all my login information from amazon.com again, and don't get the same recommendations and other features that come from Amazon knowing about my purchasing history.

I have just installed Domain Key Identified Mail (DKIM) [1] on my mail server. In summary the purpose is to allow public-key signing of all mail that goes out from your domain so that the recipient can verify it’s authenticity (and optionally reject forgeries). It also means that you can verify inbound mail. A weakness of DKIM is that it is based on the DNS system (which has many issues and will continue to have them until DNSSEC becomes widely adopted). But it’s better than nothing and it’s not overly difficult to install. The first thing to do before installing DKIM is to get a Gmail account. Gmail gives free accounts and does DKIM checks. If you use Iceweasel or another well supported browser then you can click on “Show Details” from the message view which then gives fields “mailed-by” and “signed-by” which indicate the DKIM status. If you use a less supported browser such as Konqueror then you have to click on the “Show Original” link to see the headers and inspect the DKIM status there (you want to see dkim=pass in the Authentication-Results header). Also Gmail signs outbound mail so it can be used to test verification of received mail. The next thing to do is to install the DKIM Milter. To make things exciting this is packaged for Debian under the name dkim-filter so that reasonable searches for such functionality (such as a search for milter or dkim-milter - the upstream project name) will fail. After installing the package you must generate a key, I used the command “dkim-genkey -d coker.com.au -s 2008” to generate a key for my domain. It seems that the domain is currently only used as a comment but I prefer to use all reasonable parameters for such things. The -s option is for a selector, which is a way of specifying multiple valid signing keys. It’s apparently fairly common to use a different key every year. But other options include having multiple mail servers for a domain and giving each one a selector. The dkim-genkey command produces two files, one is named 2008.txt and can be copied into a BIND zone file. The other is named 2008.private and is used by the DKIM signing server. Here is a sample of the most relevant parts of the config file /etc/dkim-filter.conf for signing mail for a single domain: Domain coker.com.au
KeyFile /etc/dkim/2008.private
Selector 2008 The file /etc/default/dkim-filter needs to be modified to specify how it will listen for connections from the MTA, I uncommented the line SOCKET=”local:/var/run/dkim-filter/dkim-filter.sock”. One issue is that the Unix domain socket file will by default not be accessible to Postfix, I devised a work-around for this and documented it in Debian bug report #499364 [2] (I’ve hacked a chgrp command into the init script, ideally the GID would be an option in a config file). A basic configuration of dkim-milter will sign mail for one domain. If you want to sign mail for more than one domain you have to comment out the configuration for a single domain in /etc/dkim-filter.conf and instead use the option KeyList file to specify a file with a list of domains (the dkim-filter.conf(5) man page documents this). The one confusing issue is that the selector is taken to be the basename of the file which contains the secret key (they really should have added an extra field). This means that if you have an obvious naming scheme for selectors (such as the current year) then you need a different directory for each domain to contain the key. As an example here is the line from the KeyList file for my domain:
*@coker.com.au:coker.com.au:/etc/dkim/coker.com.au/2008 Now one problem that we have is that list servers will usually append text to the body of a message and thus break the signature. The correct way of solving this is to have the list server sign the mail it sends out and have a header indicating the signature status of the original message. But there are a lot of list servers that won’t be updated for a long time. The work-around is to put the following line in /etc/dkim-filter.conf:
BodyLengths yes This means that the signature will cover a specified number of bytes of body data, and any extra which is appended will be ignored when it comes time to verify the message. This means of course that a hostile third party could append some bogus data without breaking the signature. In the case of plain text this isn’t so bad, but when the recipient defaults to having HTML email it could have some interesting possibilities. I wonder whether it would be prudent to configure my MUA to always send both HTML and plain-text versions of my mail so that an attacker can’t append hostile HTML. It’s a pity that Gmail (which appears to have the most popular implementation of DKIM) doesn’t allow setting that option. So far the only message I have received that failed DKIM checks was sent from a Gmail account to a Debian mailing list. Ideally it would be possible to have the messages sent to mailing lists not be signed or have the length field used. That would require a signing practice based on recipient which is functionality is not available in dkim-milter (but which possibly could be implemented as Postfix configuration although I don’t know how). Implementing this would not necessarily require knowing all the lists that mail might be sent to, it seems that a large portion of the world’s list traffic is sent to addresses that match the string “@lists.” which can be easily recognised. For a service such as Gmail it would be easy to recognise list traffic from the headers of received messages and then treat messages sent to those domains differently. As the signature status is based on the sending address it would be possible for me to use different addresses for sending to mailing lists to avoid the signatures (the number of email addresses in use in my domain is small enough that having a line for each address to sign will not be a great inconvenience). Most MUAs have some sort of functionality to automatically choose a sender address that is in some way based on the recipient address. I’ll probably do this eventually, but for the moment I’ll just use the BodyLengths option, while it does reduce the security a bit it’s still a lot better than having no DKIM checks.

• [1] http://en.wikipedia.org/wiki/Dkim


• [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499364

Share This

For a long time publishing source code under a freedom giving license was considered bad. What if people would take your code and reuse it? What if you don't like how they reuse it? History has shown that this has happened in only rare cases. And even then, having your code reused is an homage towards your creation. People started to understand that and it gladly became very common practise. But it seems like the story starts over from the very beginning again, the field though is a different one. It's now graphic artists and especially musicians who are facing the same fears this time. But I think, it shouldn't be me writing this because I'm neither (well, only very few people consider ASCII art as proper art. Probably even less than consider good code to be art..). Good thing is, I don't have to. One of the wesnoth graphic artists did it, and way better than I would ever be able to get the idea across. So here you go: Jetryl about GPL Policy in wesnoth. It might be long, but it's definitely worth the read, and I hope it will help to make some people understand better and fear less.

Wow, don't even remotely remember anymore when I was last blogging about going to the cinema. Granted, I wasn't that often in recent times, but I haven't mentioned some movies... Whatever. Yesteday I have been to cinema again, and we watched "The Dark Knight". To be honest, I regret to have gone. The movie is as dark in its setting as the title says, even darker than what was common in previous Batman movies. They turned Batman into James Bond style, turning Morgan Freeman into Q, and using cheap Eminem quotes. I feel sorry for Heath that this was his last movie to star in. Even his great performance wasn't able to save the movie, and it's sad that this should be the movie people will remember him with... You deserve better, buddy.

After I (on purpose) posted an alarming blog entry yesterday about some languages being "endangered" in Debian Installer, I got two mail exchanges today. One with Vanja Cvelbar, who completed enough in Slovenian translations of D-I for the language to requalify for Lenny. Kudos to Vanja, the Slovenian users owe you a lot (I hope they won't hate you because the translation is bad...:-)) Another with someone from the Macedonian users group who committed self to complete Macedonian translations. So, two languages saved. What will I have to do for saving others? Should I make the promise to run naked all around the next Debconf hacklab or something similar? (I should be careful, though, they could even do it just to see this) So, well, continue to make me happy and saved a few of these languages ! PS: ah, and Jordi completed Catalan as well. So, he will still be allowed to dream about World Domination, now.

Sitting next to the fire after heating up fajitas for dinner. Making sure that no hot coals make it over to the canvas topped yurt. Maybe I should have made the fire further off. I've gotten 1/3 of the way through Anathem, and Neal Stephenson has thoroughly hooked me now. I know I won't have enough battery power to read all I'd like to tonight. But for now, I've been enjoying the evening, which has been unusually long today. Maybe it's a remnant of Hurricane Ike that's led to such a cool, cloudy day, but it's seemed to be on the verge of dusk for hours. Someone asked if the yurt has wifi. Nope, but I measured the distance today, and at 400 feet it's too far for cat 5 ethernet w/o a repeater. Anyway, I seem to be in a very good frame of mind for starting Anathem, and am enjoying its take on the Long Now. Out at the falls this weekend I kept imagining how they'd change in geologic time, tracking where the water seemed to have fallen earler, downstream. And sitting up under the overhang of the falls, was briefly nervous about it coming down (as it will in oh, a few thousand years perhaps), before getting back into the present moment.

stew has announced on the Debian NYC social list the bug squashing party to happen in his place at Brooklyn, NY. If you are around the area and willing to attend, write your name down on the wiki page and get ready to be rewarded by home-brewed beer and grilled bounties per squashed RC bug! stew also offers sleeping facilities in case you need it.

I was watching So You Think You Can Dance [1] and thinking about the benefits that it provides to the dancing industry. The increase in public appreciation for the sport will increase the amount of money that is available to professionals, and getting more people interested in dancing as a profession will increase the level of skill in the entire industry. While the show hasn’t interested me much (I prefer to watch dancing in the context of music videos and avoid the reality TV aspect) I appreciate what it is doing. On a more general note I think that anything which promotes interest in the arts is a good thing. I have been wondering whether similar benefits can be provided to the IT industry through competitions. There are some well established programming contests aimed at university level students and computer conferences often have contests. But the down-side of them in terms of audience interest is that they are either performed in exam conditions or performed over the course of days - neither of which makes for good viewing. The audience interaction is generally limited to the award ceremony and maybe some blog posts by the winners explaining their work. There are a number of real-world coding tasks that can be performed in a moderate amount of time. One example is debugging certain classes of bugs, this includes memory leaks, SEGVs, and certain types of performance and reliability problems. Another is fixing man pages. A way of running such a contest might be to have a dozen contestants on stage with their laptops connected to a KVM switch. They could choose tasks from the bug list of their favorite distribution, and when they completed a task (built a deb or rpm package with the bug fixed and updated the bug report with a patch) they could request to have their port on the KVM switch and their microphone enabled so that they could explain to the audience what they did. Points would be awarded based on the apparent difficulty of the bug and the clarify of the explanation to the audience. A major aim of such an exercise would be to encourage members of the audience to spend some of their spare time fixing bugs! Basically it would be a public Bug Squashing Party (BSP) but with points awarded and some minor prizes (it would be best to avoid significant prizes as that can lead to hostility).

• [1] http://en.wikipedia.org/wiki/So_You_Think_You_Can_Dance

Share This