On Sunday the annual March Madness Half Marathon in Cary took place, which (at least informally) opens the running season in greater Chicago. Following my participation in 2005. 2006, 2007, 2008, 2009). and 2010, I kept that streak going. Weather was pretty bad: A forecast of rain materialized with a shower at the start, another at about the halfway mark and a more solid downpour at the end, while temperature where in the lower 40s. And as I train less than I used to, I was also few just a few second slower than last year at 1:39:55 (hand-stopped) but managed to sneak in just under 100 minutes (and having taken six seconds to the starting lime, the official non-chip time has me just over that mark). All-in-all another nice half-marathon and I was appropriately sore yesterday.

This seems an active time for conference planning in two of the projects I like:

1. KohaCon11 is being planned for Thane, India. Registrations are open and I m helping to admin the conference system (OCS). If you d like to talk, submissions are also open now, although how we review and choose has yet to be decided (should be at the next volunteer meeting). If you d like to sponsor the event, please register as a potential sponsor.
2. DebConf12 s location will be picked at an IRC meeting today (Tuesday). Bids from Belo Horizonte, Brazil and Managua, Nicaragua are on the web and you are invited to help choose between them.

Are there any other Free and Open Source Software community conferences you d like to mention?

Let's assume that all low-level and file-layout work is done, and we need specifications how to make Debian high-level package managers multi-arch aware.

What we have now: only one package of the same name can be installed in the system, and packages can declare dependencies only against packages of the same architecture.

What, hence, needs to be specified:
a) are certain packages of the same name but different arches co-installable or not;
b) allow to specify foreigh arches in dependencies.

Then, how our high-level multi-arch spec could be written?

a) new field 'MultiArchCoinstallable: yes' for co-installable packages;
b) new dependency syntax: package_name[:[!]arch[,arch]...], for example: 'perl' (assuming 'perl:native' for forward dependencies like 'Depends' or 'Recommends', and 'perl:any' for Conflicts and Breaks), 'perl:amd64', 'perl:amd64,i386', 'perl:!i386', 'perl:native', 'perl:any'.

That's all. Looks easy and mostly intuitive, doesn't it? However, some people are going to implement this instead.

I have been working in the last weeks in the removal of the last pieces of KDE 3 from the Debian archive and I have found there are a lot of packages that is sad having to remove. If you are looking for a good idea/excuse to learn and improve your KDE 4 / C++ /Qt4 skills, have to do a small application for school or you just feel like some useful coding, here is the list:

• creox real-time guitar effects
• kbarcode barcode and label printing application for KDE
• kbiff KDE mail notification utility
• KKBSwitch keyboard layout indicator for KDE (see this post also)
• kmyfirewall iptables based firewall configuration tool for KDE
• kpogre a graphical administrator tool for PostgreSQL
• kredentials KDE taskbar applet to update kerberos/AFS credentials
• ksociograma technical educational software to make sociograms
• ktechlab circuit simulator for microcontrollers and electronics
• qalculate-kde Powerful and easy to use desktop calculator KDE version
• score-reading-trainer trainer for reading music notes

Note that I do not list here software whose port in KDE 4 is being developed although it is still not finished and therefore it is not packaged in Debian. By the way, even if all those packages are being removed from Debian testing and unstable, they will remain in Squeeze, so you can keep using them or install it from there.

Now that I sent an update about my running activities, I have to report about what I'm doing these weeks in Debian to try keeping a fair balance for those of you who read this blog through Planet Debian. Most January was spent in preparing the release of squeeze. Of course, I didn't work directly on the release, not being involved in the release team. However, last bits of preparation for Debian Installer as well as rushing out the last remaining bits of localization work took most of my time. After the release of squeeze, time came to resume back some activities. First of all, on the l10n front, I resumed the work on "l10n NMUs", trying to get old l10n bugs fixed. I restarted proposing NMUs or, more precisely, help to perform translation updates rounds to these maintainers. Most of them had "old" l10n bugs because of the freeze. So, I indeed did not end up in doing many NMUs...but got several l10n bugs closed anyway. Work being resumed in unstable also lead to many changes in packages' debconf templates (new packages using debconf, packages introducing new templates, etc.). As these are the trigger for Smith reviews (reviews of English in debconf templates and packages' description, this activity, which was very low during the freeze, resumed again (we'll soon celebrate the 4th anniversary of this project). I also decided to invest more time in D-I again. The D-I team is currently more active than it was last years. Thanks to a few individual, work resumed in some areas and bug triaging has been very active. I recently resyned a nice improvement which had been contributed by a user to iso-scan, then polished by Frans Pop. This will allow to choose among several different ISO images when installing Debian from a USB stick while, previously, only the first found was being used. I also worked with a new translator, to prepare the activation of Uyghur translation in D-I. Some work happend in the pkg-fonts team. I had a few fonts adopted by the team, as part of the general effort to get rid of defoma. I sent patches for a few others, but many remain. If you maintain font packages, please help us in getting rid of defoma. Changes are easy to do; ask the team if you need help (pkg-fonts-devel@lists.alioth.debian.org). Samba packages also ate a significant part of my time. First of all, DSA-2175 lead to prepare fixes for samba in squeeze and lenny. Then, upstream released samba 3.5.8 which I uploaded to unstable. I briefly considered trying to get the Stable Release managers approval to push that version in squeeze, but the number of fixes made by upstream was discouraging. So, I chose to examine them slowly and cherry-pick those I consider important enough to warrant an upload for squeeze. More git wizardry learned doing so (thanks to Julien Cristau for his help). And I now have a pending proposal for three of these fixes (that represent 14 atomic patches from upstream) to be included in squeeze.

The first two months of this year have seen me quite busy preparing for my March-April peak of activity. So, most of these were spent accumulating kilometers, mostly on trail runs with mud, slope, obstacles, etc.

• January: 240km, 21h17', 3000m positive slope
• February: 170km, 15h10', 1900m positive slope

January was meant to accumulate kilometers, which succeeded quite well..:-). Not as crazy as November 2010 (close to 300km) but the point was also testing a few long runs, over 25km and up to 32. February saw my first official race, with Bullion half-marathon. This is a nice race which I already ran last year. It features small roads in the Rambouillet Forest. Not the best place to achieve a personal best because the race is not flat, with two hills in the first half. Moreover, I was just recovering from a small flu, so I wasn't really planning to achieve a PB. Still, I managed to do it in 1h39'49", two minutes more than my PB. Moreover, I managed to do it in a small negative split, with first half in 50'38" and second half in 49'11". More encouraging, I ran a 35km solo trail the next week-end after this and completed it fairly well with the pace I plan for the 50km Eco-Trail. Still, that flu introduced some minor perturbation in this preparation and, thus, I included more activity in early March. I was originally planning to run Paris half-marathon on 6th, but an invitation for a friends 50th birthday made me cancel that one. So, most of the first 3 weeks of March were spent in 15-18km style runs, plus running daily to go to and back from work. The last preparation was today with a short 12km run with all equipment needed for Eco-Trail (backpack, 2lit. waterbag) and the targeted pace (10km/h). So, on Saturday, will be the Paris Eco-trail 50km race from Versailles Castle to Eiffel Tower....through woods in the South and South-West neighbourhood, with 1000m positive slope. This will be my first ultra race, so I'm a little bit in a grey area, here. As a consequence, the only ambition is finishing. I expect it to be in aroung 5h30 or so. Most importantly, I have to keep reserves, as, two weeks later, I'll run my yearly Paris marathon. Two long distance races in two weeks...we'll see if I'm crazy or not..:-) Now, I'm heading for a quiet week: grow glucides reserves, eat pasta, do one or two footings...and wait for Saturday! You may want to watch my blog on Sunday to see whether I survived this first stage.

For the users of Debian Squeeze we, the KVIrc maintainers, plan to upload the soon-to-be-released upstream bug fix release 4.0.4, packages of RC2 are available. RC2 is most likely going to be identical to the final 4.0.4 release. The update will be, if the SRMs agree (still need to ask them, but I wanted to wait for the final version before I do that), uploaded to stable-proposed-updates, maybe squeeze-updates and fix a few nasty bugs, which some users might experience, including graphical glitches when used under Gnome (upstream bug #1010), some crashes (e.g. upstream bugs #878, #879, #1093, #1098 and some without bug numbers like r4796), a regression in the Perl scripting support and a lot of translation updates (btw: if you use KVIrc and the translation for your mothertounge is lacking, consider to help! Coordinate your efforts on IRC.) Apart from that I just uploaded a new SVN snapshot of 4.1 into Sid, the next will follow in about ten days unless you report bugs, which make an earlier upload necessary. ;-)

A bit of history One of the greatest criticisms of Debian is that its release cycles are too long. Debian stable release is seen as often as Ubuntu s LTS release. As a server solution this doesn t present a problem at all, it can even seen as a pro. However, for desktop use and for your average Joe who needs to have the latest software and is unable to get it, this may well present a problem. Of course he can always turn to backports to get what he needs but by the time you have finished reading this very sentence, Joe has already moved to Ubuntu. For those who are completely unaware how things work within Debian, let me try to shed some light. Debian has 3 main branches:

• stable
• testing
• unstable

Unstable , is a branch used mainly by developers, where the latest changes to the software they are working on are made. Usually, after approximately 10 days this software is pushed to testing , branch which is going to become next Debian stable release. For comparison, in the process of a new Ubuntu release at one point in this process, changes from testing/unstable are frozen where Ubuntu fixes bugs until they are ready to release new Ubuntu release. Debian s testing branch is said by some to be more stable then most of the stable distributions out there. Last but not least is stable branch, which follows the (in)famous mantra it s released when it s ready , although last two releases have been released in a more timely manner. Okay, so what is Debian CUT? The idea stretches back more then 2 years, to Joey Hess proposing the idea of Constantly Usable Testing . For users/developers who can t wait ~2 years to see new Debian release, they usually turn to Debian testing branch. To clarify, testing images are released weekly, but most of us in Debian don t recommend you jump to testing by installing it from weekly image, but rather by upgrading from stable. To make the situation even worse, these builds frequently don t work due to all the changes that have been pushed from unstable. But this is where Constantly Usable Testing idea comes in, where the installer is always installable and you re already using what s going to be next stable release. You wouldn t have to worry about whether the next update is going to break your system, but would get regular security updates, while the big updates would come in shape of new testing snapshot versions. Frequency of release of these snapshots is ought to be on monthly basis, so you can plan on seeing the next release on April 6th (exactly one month after the current release, provided of course if there are no showstopper bugs). To sum it all up, you wouldn t have to wait ~2 years before new Stable release shows up, nor (in case you have already switched to testing) would you have to worry whether your next update will break your system. You would get your updates in form of timely (ie: monthly) snapshots until it s time for major milestone which would turn out to be new Debian release. Even though this might be long term goal, in these early stages no one can guarantees this. Rolling release? The simplest way to explain this concept is that there are two types of Linux distributions: one with milestone version numbers and other where new updates keep coming through their rolling release cycles. Some of the rolling distributions are Gentoo and Arch Linux, while on the other side you have RedHat and Suse. Novell announced that OpenSuse is moving to rolling release with project codename Tumbleweed. It s also worth mentioning that Debian already has its rolling counters and perfect examples are: LMDE and aptosid. It is a way to continuously develop software, a way that best fits Debian as a platform where software is continuously developed. Especially because most of its greatest values could get lost with the release of that big stable version . Perfect case of that could be the almost drop of Chromium in Squeeze. Another great example could be Android, which is criticised most for its versioning. Companies are refusing to release new Android versions to their current phones, because they want you to buy new phone with latest Android version, even though your current one is perfectly capable of running latest Android. Personally, I m sure the future will reveal that rolling releases are the future, towards which all Linux platforms should be heading. Perhaps the definition of rolling releases I gave earlier is why I believe this project has such bright future ahead of it. Debian would be somewhat of a hybrid of this definition, it would be rolling release until it s time to mark a big milestone with a version number, and before you know it, we re rolling again. Unofficial Debian Monthly Testing Snapshot Release (version 2011.03 final) Michael Gilbert took on a big responsibility, trying experimentally to prove the feasibility of such a project. He has released a first wheezy snapshot installer (versioned 2011.03) as a test for the development community to try out and evaluate. Please read official announcement along with download links. While you can use this snapshot to have constantly working installer, after it is installed you could move to testing altogether if you wish. Conclusion As I have already mentioned, this project is still in the development/experimental stage, which makes all of this its very conception. Also, apart from rumors of Ubuntu becoming rolling release, if Ubuntu is to get its rolling release this how it s going to get it If you d like to find out more about Debian CUT, I suggest you read Raphael Hertzog s article A constantly usable testing distribution for Debian , and watch the video of Joey Hess CUT BoF on DebConf10 in NYC. Of course, if you d like to get involved into this project, please use the project s mailing list. If you have any comments, please do share, as I d be happy to answer any of your questions.

I ve just written some small scripts to help me manage spam emergencies on a mail server. I ve been doing this thing with a bit of manual effort for a while, but after having done it once from a phone I want to optimise it a bit to reduce painful typing.My observation is that when a system I run is used as an outbound mail relay for spamming I will notice this reasonably quickly by the queues getting big. Some portion of mail that is queued is delayed due to general network issues and anti-spam measures that neither accept nor reject mail cause a typical spam message to be more likely to be queued than a typical non-spam message. So I look for accounts that send large amounts of mail.The biggest mail server I run (and the only one to have an outbound spam problem) is configured to not allow users to fake their sender address (IE use an address from gmail.com or another server) unless they pay extra. So the spam I deal with tends to have a valid origin email address that I can use.Queue CountingThe following command provides a sorted list of the accounts that have the most mail in the queue. This usually means a maximum of 2 or 3 spammers at the end of the list:mailq grep ^[A-F0-9] cut -c 42-80 sort uniq -c sort -n tailThe following function declaration makes the command get-top-sender find the sender with the largest number of queue entries (which has been a spammer every time I ve checked such things) and assign their email address to the environment variable $TOP_SENDER. It has to be a shell function so that the environment variable will be set in the context of the shell and available to child processes.function get-top-sender() TOP_SENDER_LINE=$(mailq grep ^[A-F0-9] cut -c 42-80 sort uniq -c sort -n tail -1) ; export TOP_SENDER=$(echo $TOP_SENDER_LINE cut -f2 -d\ ) ; TOP_COUNT=$(echo $TOP_SENDER_LINE cut -f1 -d\ ); echo "Top Sender is $TOP_SENDER with $TOP_COUNT messages" ; Viewing the QueueThe following script uses the first parameter or the environment variable $TOP_SENDER to specify the user who s mail should be read. In the normal course of events user email won t be read by the sysadmin, but if we are to determine whether a slew of email is spam or not there s no other way. So far I haven t seen a large number of queued messages not be spam, but I expect it ll happen eventually and the user will be happy that I checked it instead of locking their account and deleting all the queued mail. For readers who don t do sysadmin work, this is why we always have entries in the Terms of Service about the possibility of your email being read to fix technical problems or to investigate possible breaches of the ToS from your end.#!/bin/bash
set -e
mkdir -p ~/tmp/$$
cd ~/tmp/$$
if [ "$1" != "" ]; then
TOP_SENDER="$1"
fi
if [ "$TOP_SENDER" = "" ]; then
echo "Specify the sender on the command-line or in \$TOP_SENDER"
exit 1
fi
for n in $(mailq grep ^[A-F0-9].*$TOP_SENDER cut -c 1-10) ; do
FILE=$(echo $n sed -e "s/^\(.\)/\/var\/spool\/postfix\/deferred\/\1\/\1/" -e "s/ .*$//")
if [ -f "$FILE" ]; then
postcat "$FILE" > $n
else
echo "File $FILE missing, probably active"
fi
done
less *
rm -rf ~/tmp/$$Note that this needs to be done with a single less command so that I can terminate it by pressing q and easily go to the next file with :n . It does waste some server resources by running postcat on all queue files relating to the user in question, but that doesn t matter, servers are supposed to be powerful enough to cope with some inefficiency in processing uncommon operations.The Final CommandAfter that I have a script that connects by ssh to all outbound mail relays and deletes bad messages from the queues and then connects to the database server to lock the account that was used for sending the mail. I m not publishing it because it s specific to the servers I run.So when NAGIOS reports that the queue is too large I have one script to find the most likely culprit, one script to view the queued email from that account, and a final script to lock the account and purge the spam.I ve also added a reminder of the command names to /etc/motd as I don t want to be running ls and set on a phone to discover command names that I ve forgotten.Any suggestions for improvements to this will be welcome.

I spent part of today looking at packaging Peter Gutmann's CryptLib for debian. My conclusion: it may not be worth my time. One of the main reasons i wanted to package it for debian is because i would like to see more OpenPGP-compliant free software available to debian users and developers, particularly if the code is GPL-compatible. Cryptlib makes it quite clear that it intends to be GPL-compatible:

cryptlib is distributed under a dual license that allows free, open-source use under a GPL-compatible license and closed-source use under a standard commercial license.

However, a significant portion of the cryptlib codebase (particularly within the bn/ and crypt/ directories) appears to derive directly from OpenSSL, and it retains Eric Young's copyright and licensing. This licensing retains the so-called "advertising clause" that is generally acknowledged to be deliberately incompatible with the GPL. (A common counterargument for this incompatibility is that OpenSSL should be considered a "System Library" for GPL'ed tools that link against it; whether or not you believe this for tools linked against OpenSSL, this counterargument clearly does not hold for a project that embeds and ships OpenSSL code directly, as CryptLib does) This does not mean that CryptLib is not free software (it is!), nor does it mean that you cannot link it against GPL'ed code (you can!). However, you probably can't distribute the results of linking CryptLib against any GPL'ed code, because the GPL is incompatible with the OpenSSL license. The un-distributability of derived GPL-covered works makes the CryptLib package much less appealing to me, since i want to be able to write distributable code that links against useful libraries, and many of the libaries i care about happen to be under the GPL. I also note that Peter Gutmann and CryptLib Security Software (apparently some sort of company set up to distribute CryptLib) may be in violation of Eric Young's License, which states:

 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *    "This product includes cryptographic software written by
 *     Eric Young (eay@cryptsoft.com)"
 *    The word 'cryptographic' can be left out if the rouines from the library
 *    being used are not cryptographic related :-).

A Google search for Eric Young's name on cryptlib.com yields no hits. I do find his name on page 340 of the Cryptlib manual, but that hardly seems like it covers "All advertising materials mentioning features or use of this software". I suppose it's also possible that CryptLib has negotiated an alternate license with Eric Young that I simply don't know about. In summary: i think CryptLib could go into debian, but its incorporation of OpenSSL-licensed code makes it less useful than i was hoping it would be. I have a few other concerns about the package after looking it over in more detail. I suspect these are fixable one way or another, but i haven't sorted them out yet. I'm not sure i'll spend the time to do so based on the licensing issues i sorted out above. But in case anyone feels inspired, the other concerns i see are:

embedded code copies

In addition to embedded (and slightly-modified) copies of bn/ and crypt/ from OpenSSL, CryptLib contains an embedded copy of zlib. Debian has good reasons for wanting to avoid embedded code copies. I've got it CryptLib building against the system copy of zlib, but the bits copied from OpenSSL seem to be more heavily patched, which might complicate relying on the system version.

executable stack

lintian reports shlib-with-executable-stack for the library after it is built. I don't fully understand what this means or how to fix it, but i suspect it derives from the following set of object files that also have an executable stack:

0 dkg@pip:~/src/cryptlib/cryptlib$ for foo in $(find . -iname '*.o'); do
>  if ! readelf -S "$foo"   grep -q .note.GNU-stack ; then
>   echo "$foo"
>  fi
> done
./shared-obj/desenc.o
./shared-obj/rc5enc.o
./shared-obj/md5asm.o
./shared-obj/castenc.o
./shared-obj/bfenc.o
./shared-obj/rmdasm.o
./shared-obj/sha1asm.o
./shared-obj/bn_asm.o
./shared-obj/rc4enc.o
0 dkg@pip:~/src/cryptlib/cryptlib$ 

They probably all need to be fixed, unless there's a good reason for them to be that way (in which case they need to be documented).

non-PIC code

lintian reports shlib-with-non-pic-code on the library after it is built. I don't fully understand what this means, or how to resolve it cleanly, but i imagine this is just a question of sorting out the details.

Anyone interested in using my packaging attempts as a jumping off point can start with:

git clone git://lair.fifthhorseman.net/~dkg/cryptlib

Oh, and please correct me about anything in this post; I'd be especially happy to hear that my analysis of the licensing issues above is wrong :) Tags: cryptlib, gpl, licensing, openssl

A few weeks ago, at work, we were looking for a solution to a tricky printing problem: how to manage, in a centralized infrastructure, a large number of locations, worstations and printers? One of the consultants working for us came up with a great idea. With only a 20-line patch to CUPS, workstations would be able to find which printers are on the same location. 20 lines of code, instead of a complex virtualisation solution? This is exactly the kind of reasons why we use free software: when there s something wrong, you can fix it. When you need something more, you can code it. Now, many others could benefit of such an improvement, and we don t want to maintain a forked version of CUPS, so we forwarded it upstream, who looked interested. But upstream now being Apple, they requested a stupid copyright assignment agreement. I will leave to the reader s imagination the complexity of getting such a document signed in a Fortune 500 company with no business with Apple. This will, of course, not happen - and if the decision was mine, the answer would have been a clear No. No, because I want to improve free software, not to contribute to Apple s proprietary version. No, because copyleft is about giving as much as you take. How many contributions are being left out of CUPS because of this stupid copyright assignment? It looks to me that such software is doomed to remain crippled as long as companies like Apple are in charge of their maintenance. There is free software. And there is free software by Apple. And Oracle. And Canonical.

You know it already, since Debian 6.0 non-free firmware are no longer provided by a standard Debian installation. This will cause some troubles to users who need them. I m thus going to do a small overview on the topic and teach you what you need to know to deal with the problem. What are firmware and how are they used? From the user s point of view, a firmware is just some data that is needed by some piece of hardware in order to function properly. The driver for that hardware typically loads the firmware on the device as part of its initialization. In the Linux kernel, the drivers are all using a standardized interface (request_firmware) to retrieve the firmware before sending it to the device. Thanks to this standardization, it s possible to either embed the firmware in the kernel or to have it request the firmware from user-space when needed. Debian (like most distributions) has selected the latter option. Thus when the kernel needs a firmware, it sends out a request to user-space. udev is getting the request with the name of the firmware, and in its default configuration (see /lib/udev/rules.d/80-drivers.rules) it executes /lib/udev/firmware.agent in response. Where are firmware stored? firmware.agent is a simple shell script that tries to locate a firmware before sending it back to the kernel through a sysfs entry. It looks into the following directories:

• /lib/firmware/$(uname -r)
• /lib/firmware
• /usr/local/lib/firmware
• /usr/lib/hotplug/firmware

Firmware provided by packages are thus usually in /lib/firmware and you can use /usr/local/lib/firmware for manually installed firmware. How do I know whether I need a firmware? First of, you can notice messages from the kernel telling you that it tried to load a firmware but it failed. They look like this:

e100: eth0: e100_request_firmware: Failed to load firmware "e100/d101m_ucode.bin": -2

But you might be informed sooner. When you install a new version of the Linux kernel with the official Debian packages, the post-installation script will go through all loaded modules (those listed by lsmod) and it will verify whether this module as provided by the newly installed kernel might require firmware files. This information can be retrieved with modinfo:

$ modinfo -F firmware /lib/modules/2.6.32-5-amd64/kernel/drivers/net/e100.ko
e100/d102e_ucode.bin
e100/d101s_ucode.bin
e100/d101m_ucode.bin

If one (or more) of those firmware is (are) not yet available on the system, you will get a warning message similar to this one:
update-initramfs will also generate a similar warning on the terminal:

update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
W: Possible missing firmware /lib/firmware/e100/d102e_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101s_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101m_ucode.bin for module e100

The Debian installer also detects when you have hardware that might require a missing firmware file. You have the option to supply the missing files on a USB stick (either directly or through the corresponding package). How do I find and install the missing firmware? Now that you have the name of the firmware file that you want, it s relatively easy to identify the package that provides the required file. You can use apt-cache search <filename> because the firmware packages embed the list of firmware files in their description. You can also use apt-file (provided by the package of the same name) or the web interface at packages.debian.org.

$ apt-cache search d101m_ucode.bin
firmware-linux-nonfree - Binary firmware for various drivers in the Linux kernel
$ apt-file search d101m_ucode.bin
firmware-linux-nonfree: /lib/firmware/e100/d101m_ucode.bin

If the above commands return nothing, you probably need to enable the non-free repository in your /etc/apt/sources.list (you can also enable it within synaptic). And you also want to run sudo apt-file update to have the latest information. Now you can install the right package, in the example above it was firmware-linux-nonfree. How do I install all firmware just to be sure I don t miss any? There s no meta-package depending on all firmware packages so there s no easy answer to this question. Furthermore not all firmware packages respect the naming convention firmware-* (there s for example zd1211-firmware). So your best bet is to look up all the packages with a generic search like this one:

$ apt-file --package-only search /lib/firmware/
atmel-firmware
[...]

And then install them all. Are there DVD or CD images with non-free firmware? Yes. Debian provides an unofficial netinst image for i386/amd64/powerpc with the non-free firmware, you can find it here: http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/. I provide complete DVD sets with firmware, and Multi-Arch CD/DVD with firmware, it s over there in my DVD shop: http://raphaelhertzog.com/go/debian-cd/ (i386/amd64 only) When using those installation discs, the Debian-installer will be able to find the required firmware immediately. There s no need for you to provide them on a USB stick. Other questions? I think I covered the most important things you have to know about firmware on Debian. But should you still have a question, feel free to share it in the comments so that I can improve this article.

Click here to subscribe to my free newsletter and get my monthly analysis on what s going on in Debian and Ubuntu. Or just follow along via the RSS feed, Identi.ca, Twitter or Facebook.

6 comments Liked this article? Click here. My blog is Flattr-enabled.

Sam Varghese has written an article that is very skeptical of the educational value of the OLPC project [1].Are Laptops Any Good for Schools?Sam cites an article in the New York Times by Winnie Hu about schools removing laptop programs due to a lack of success [2]. Winnie s article gives an example of a school shutting a program because of getting new teachers who lacked computer skills and some examples of schools which had issues with the repair cost. The solution to that would be computers that are more robust and easier to use by all accounts the OLPC systems are solidly constructed and easy to use!It is claimed that using laptops doesn t increase test scores. Using only test scores to compare educational methods is a way to lose, probably any school which does nothing other than try to increase test scores is worth avoiding. One example from Winnie s article is a report by Mr. Warschauer of students at a middle school in Yarmouth, Me., who used their laptops to create a Spanish book for poor children in Guatemala and debate Supreme Court cases found online . What value can you place on having students develop books for poor children in other countries and debate Supreme Court cases? If this sort of program became popular then it would lead to the countries which do it becoming better places to live in future decades!Mr. Warschauer also claims that If the goal is to get kids up to basic standard levels, then maybe laptops are not the tool. But if the goal is to create the George Lucas and Steve Jobs of the future, then laptops are extremely useful . I would go further than that, I think that providing the educational environment that involves international charity work and analysis of important court cases would lead to students having the skills to become good engineers, designers, and artists who work for people like George Lucas and Steve Jobs. No matter what you might do the vast majority of children will not grow up to be like George Lucas and Steve Jobs, there is a very limited number of positions for such people. But those people employ a huge number of creative people who do interesting and enjoyable work for good pay.I don t think that Winnie s article supports criticism of the OLPC project. I don t think that Winnie s article even contains sufficient evidence to match the headline.Playing GamesSam also cites an article about the misuse of school computers for playing games [3]. Of course there are ways of limiting access to games based on time etc. For a Linux system you could have a root cron job that runs chmod on /usr/games at various times, and preventing users from easily running programs that they install isn t difficult.Not that games are all bad, the flash-based games on www.physicsgames.net do teach kids some things about physics although I admit that much of that could be learned by playing with balls, skate-boards, etc.The Problem with the OLPC ProjectI think that the policy change to make OLPC systems only available to disadvantaged children was a mistake. The give one get one program was a great idea, maybe not the most effective way of getting funding but good for getting developers. While the new Sugar on a Stick project to put the OLPC GUI on a bootable USB device [4] it doesn t compare well to having dedicated hardware IMHO.Minimal Use of ComputersI have previously written about the weight of school bags and how laptops can alleviate the risk of health problems related to carrying heavy text books [5]. Since that time ebook readers and tablets have become incredibly cheap. Ebook readers are really light and the recent tablets are also very light (particularly the smaller ones). It seems to me that every school should at least be moving towards every student having an ebook reader and to use ebooks for all books that are part of the curriculum.At the moment there are a bunch of tablets on sale for about $150, that includes tablets that can access the Internet via Wifi or via 3G and a cheap 3G plan costs less than $150 per annum. If tablets were used for some of the computer tasks related to schools then a lot of the difficulty of repairing hardware would be removed. Tablets don t offer as many options for messing up the software configuration and if the hardware breaks it s easy to transfer the data onto a new tablet from the cloud with a maximum cost of $150 to replace the hardware.Also a cloud-based computing model could permit students to access all the same data from school and home while using desktop computers at both locations.Current SuccessNatalie Craig wrote an interesting article for The Age about The Lab a drop-in computer center for kids on the Autism Spectrum run by Dale Linegar and Stefan Schutt [6]. The fact that kids who have communication difficulties can find it easier to communicate electronically should be fairly obvious to everyone in the free software community, but the creation of an organisation to support such kids is noteworthy I think that such centers should be funded by the government and run in every city.Salman Khan gave an interesting TED talk about his project the Khan Academy [7] which is an online video-based teaching system that evolved from some Youtube videos he produced to tutor his cousins. Salman pointed out that his cousins said that they would rather watch his videos than have him teach them in person, it seems that they liked being able to pause and rewind the talk as well as avoiding the pressure of human interaction. The Khan Academy has videos in Adobe flash format, but conveniently they have download links so those of us who don t have the Flash plugin can still view the content [8].One of the interesting things about the Khan Academy is that in school use the videos are being assigned to kids as homework and the class time is used for teaching children to do worked examples what has traditionally been homework.So it seems that there are real examples of special-needs kids and average kids benefiting from different types of electronic learning.ConclusionI think that almost everything about the education system is broken. I also think that in many ways the education system has reached a local maximum, so there is no small way of improving things, and adding computers without making any of the significant changes needed to fix the big problems probably can t do a lot of good. In spite of this computers can provide some real benefits and I expect that those benefits can be better than the benefits of other potential ways of spending the money (IE it s worth the opportunity cost). I also have no doubt that almost anything can give a negative result if done badly enough, so I don t interpret examples of computer use failing in a school as anything other than evidence of a failing school.While the Khan Academy has some results that seem very positive I think that s only the first step of what needs to be done. It also seems to be based around users who have good Internet access which often isn t the case in places where the OLPC is being deployed. This implies that we need to get systems like the Khan Academy designed to operate in a disconnected manner, maybe with a remote server that s not connected to the Internet. This should be possible if funding is available.Sam suggested that there needs to be a scientific study of the effectiveness of the OLPC. I think that every project which involves significant amounts of public funding should be researched to ensure that it s an effective use of resources. 400,000 laptops is going to cost something more than $40,000,000 so it seems reasonable to devote a few person-years of research to determine how effective they are and which of the possible ways of using an OLPC will give the best results.I am confident that a good study of the effectiveness of the OLPC would demonstrate that it provides real educational benefits when correctly incorporated into an educational program. I also expect that such a study would show some significant differences in the effectiveness of various ways of using them. But we shouldn t be relying on confidence, we need some test results.

• [1] http://www.itwire.com/opinion-and-analysis/open-sauce/44673-lca-2011-is-the-olpc-about-technology-or-education
• [2] http://www.nytimes.com/2007/05/04/education/04laptop.html
• [3] http://www.nytimes.com/2010/07/11/business/11digi.html?adxnnl=1
• [4] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick
• [5] http://etbe.coker.com.au/2008/05/24/school-bag-weight/
• [6] http://www.theage.com.au/victoria/autistic-kids-learn-to-fly-in-cyberspace-20110219-1b0fj.html
• [7] http://www.ted.com/talks/salman_khan_let_s_use_video_to_reinvent_education.html
• [8] http://www.khanacademy.org/

There have been ongoing news reports about the nuclear power plant problems in Japan following the earth-quake and tidal-wave. The Wikipedia page about the Fukushima I nuclear accidents seems to have the best current summary of the situation [1].I think it s worth noting that Potassium Iodide can be ingested to reduce the incidence of thyroid damage in the event of radiation leaks (which apparently usually contain radioactive iodine). KI can be ingested immediately after exposure and there s apparently little harm in taking it before a time of risk (it can be good to take it for a couple of days before exposure). So getting some KI right now might be a good idea for people who live in the vicinity. Apparently the Japanese government have issued iodine tablets to the people closest to the disaster, but it s probably worth spreading the word to people who are further away.Leigh Krietsch Boerner gave a good explanation of how Iodine significantly reduces the risk of thyroid cancer [2].The Nuclear War Survival Skills site has a good description of how to make your own KI solution [3]. This probably isn t a viable option for anyone in Japan unless they can raid a chemistry lab as mail-order of chemicals will surely be too slow. This is probably something that s best considered for future plans for anyone who lives near a nuclear reactor.It would be good if airport pharmacies sold packs of KI tablets for the benefit of travelers who don t live near a reactor but who are visiting a country that has them. It s something I d like to buy before my next trip to Japan.

• [1] http://en.wikipedia.org/wiki/Fukushima_I_nuclear_accidents
• [2] http://ljkboerner.wordpress.com/2011/03/12/why-give-iodide-for-radiation-poisoning/
• [3] http://www.oism.org/nwss/s73p924.htm

One of the biggest differences between working on most other OSs and working upstream on drivers for the Linux kernel is that elsewhere the core is usually a fixed thing that has been released and can t really be changed, even if source is available (which may not even be the case). If whatever subsystem you re working in can t cope with the thing you re trying to express then one of the things it s really useful to be good at is working out ways to implement the behaviour that s required behind the back of the subsystem. It s very common to see such code in drivers submitted by hardware vendors, particularly those that are new to Linux, as this is such a big mindset shift. With kernel development the approach is much more to make sure that the core can cope with whatever needs expressing. It s not always done in the core for example, sometimes the issue is due to unusually limited hardware and very likely to never come up again but it s very unusual to see code merged that doesn t at least fit in with the design of the subsystem. This post is inspired by a brief exchange with Thomas Gleixner on linux-kernel who articulated the advantages of doing things this way very well:

 - It's usually simpler and faster as the core code has all the
   necessary information. So that's even an argument which managers
   might understand.
 - Such workarounds, when not caught, tend to spread themself
   magically because driver writers checkout the existing code of
   similar devices and copy/paste/modify^Wuglify them over and over.
 - In the worst case such workarounds make the core maintainence
   harder and in some cases impossible, because they silently imply
   semantics on the core w/o the core maintainer knowing about them.

The last point is the most important one to me as a subsystem maintainer I really don t want to be merging code that is going to create issues with ongoing development of the subsystem. This is all another facet of the policy on stable APIs: APIs are only worth working around if they re fixed, and the assumptions that end up embedded in a workaroud are as much part of the API as the explicit interfaces. It s things like this that make Linux such a pleasure to work on.

Although I promised in my previous entry that I'd made my last mention of the redisfs - replication friendly redis-based filesystem I have to disappoint. Ben Sykes informed me that he'd made a fork of redisfs, called shredisfs. I like forks. Forks are good, and this particular one was very welcome - from the README:

Steve's original managed around 250k per second for writes on my test machine, this version does about 15MB a second writes. ... Read speed on the test machine here now is around 180MB/sec..

Needless to say I "stole" the improvements and rolled them into my original release. Thanks all round to those of you that submitted bug reports, suggestions, and codez. I also had a release out briefly which used zLib to compress the values of keys stored in memory. Unfortunately that lead to a net-slowdown for files which were bigger than a single block - due to the overhead of file-system appends which translated to: "fetch", "compress", "append", and "decompress". Finally on the subject of qpsmtpd, my favourite SMTP-server - the exceptionally talented Matt Sergeant released a proof of concept rewrite in Javascript. Using nodejs this new SMTP server is heavily asynchronous and you can find it online under the name Haraka. Although my javascript-fu is weak I'm very impressed by the codebase out there so far, and I'd expect good things of it in the future. Even if it does use Javascript and not my beloved Perl. Finally I'm a year older. But birthdays aren't important. ObQuote: "Do you wanna know what makes all my candy taste so special? " - Epic Movie.

Out of curiosity, and because it is Sunday morning and I have a cold and can't get my brain to do anything tricky, I counted the number of candidates in each year's DPL elections.

Year	Count	Names
1999	4	Joseph Carter, Ben Collins, Wichert Akkerman, Richard Braakman
2000	4	Ben Collins, Wichert Akkerman, Joel Klecker, Matthew Vernon
2001	4	Branden Robinson, Anand Kumria, Ben Collins, Bdale Garbee
2002	3	Branden Robinson, Rapha l Hertzog, Bdale Garbee
2003	4	Moshe Zadka, Bdale Garbee, Branden Robinson, Martin Michlmayr
2004	3	Martin Michlmayr, Gergely Nagy, Branden Robinson
2005	6	Matthew Garrett, Andreas Schuldei, Angus Lees, Anthony Towns, Jonathan Walther, Branden Robinson
2006	7	Jeroen van Wolffelaar, Ari Pollak, Steve McIntyre, Anthony Towns, Andreas Schuldei, Jonathan (Ted) Walther, Bill Allombert
2007	8	Wouter Verhelst, Aigars Mahinovs, Gustavo Franco, Sam Hocevar, Steve McIntyre, Rapha l Hertzog, Anthony Towns, Simon Richter
2008	3	Marc Brockschmidt, Rapha l Hertzog, Steve McIntyre
2009	2	Stefano Zacchiroli, Steve McIntyre
2010	4	Stefano Zacchiroli, Wouter Verhelst, Charles Plessy, Margarita Manterola
2011	1	Stefano Zacchiroli (no vote yet)

Winner indicate by boldface. I expect Zack to win over "None Of The Above", so I went ahead and boldfaced him already, even if there has not been a vote for this year. Median number of candidates is 4.

For one of our experiments, we ended up analyzing all versions mentioned in a Debian Packages file if mentioned in a constraint or in a version field of a package. It seems that there are a lot of DDs that like to use strange 'formatting' when writing down a versioned constraint. This is might be not a choice done directly by the debian maintainer, but just a consequence of a particular version schema from upstream. The debian policy is rigorous with relation to the algorithm to compare version .

 The strings are compared from left to right.
 First the initial part of each string consisting entirely of non-digit characters is determined. These two parts 
 (one of    which may be empty) are compared lexically. If a difference is found it is returned. The lexical 
 comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters 
 and so that a tilde sorts before anything, even the end of a part. For example, the following parts are in sorted 
 order from earliest to latest: ~~, ~~a, ~, the empty part, a.[34]
 Then the initial part of the remainder of each string which consists entirely of digit characters is determined. 
 The numerical values of these two parts are compared, and any difference found is returned as the result of 
 the comparison. For these purposes an empty string (which can only occur at the end of one or both version 
 strings being compared) counts as zero.
 These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a
 difference is found or both strings are exhausted.

I think the important part is about the numerical comparison The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison . Our tool finds a number of examples of equivalent versions :

• version 0.1-1 is equivalent to (0.00001-1,0.001-1,0.01-1,0.1-1)
• version 2.1.0-1 is equivalent to (2.01.00-1,2.1.00-1,2.1.0-1)
• ... etc . I've one page full of equivalent versions.

For example version '0.00001-1' is from package libbenchmark-progressbar-perl. I don't know why so many equivalent way of writing a version string are used. Probably they appear in completely unrelated packages I'm pretty sure no harm is intended :) However, to avoid confusion, it might be a good idea to settle on a non-normative canonical representation of versions. Like no '0' in front of dots and hyphen... Maybe we could add a warning in lintian ? If somebody is interested I can generate a full report that associates each version to a package name.