In a recent blog post, Kai complained about various existing tools for marking up email in HTML. He also asked for pointers to other tools. Since he didn't specify good tools :-), I took the opportunity to promote my work in progress plugin for ikiwiki to do that very thing. When asked about demo sites, I realized that my blog doesn't actually use threaded comments, yet, so made a poor demo. Follow the link and you will find one of the mailboxes from the distribution, mostly a few posts from one of the debian lists. The basic idea is to use the Email::Thread perl module to get a forest of thread trees, and then walk those generating output. I think it would be fairly easy to make a some kind of mutt-like index using the essentially same tree walking code. Not that I'm volunteering immediately mind you, I have to replys to comments on my blog working (which is the main place I use this plugin right now).

One thing I am known to do is complain how the public/academic discourse surrounding/around technology/computers is overwhelmingly male (Lessig, Benkler, Zittrain, Shirky and I can go on and on). But one day I realized that if I am bothered by it, I should do more than talk the (often) empty talk of complaint. So I decided to enroll in a day long training for writing OpEds, which kicks off tomorrow. I am not sure if engaging in public debate is what I want to do, mostly because of piling more work and time commitments on a very full plate but I am starting to explore what it means and what it may take to leave the Ivory Tower. Here is a little more info about the OpEd Project:

The OpEd Project - featured by The New York Times, Feministing.com and Katie Couric on CBS News - is an initiative to expand public debate, with an immediate focus on targeting and training women experts across the nation to project their voices on the op-ed pages of major newspapers, online sites and other key forums of public discourse. The lack of diversity on the op-ed pages - which are a source for all other media - deprives the public of robust, democratic debate, especially important in this space which is intended to showcase divergent opinions. It also means we are only hearing from a tiny sliver of the nation’s best thinkers. Imagine a baseball team of only pitchers - how well would it do?

One thing I am known to do is complain how the public/academic discourse surrounding/around technology/computers is overwhelmingly male (Lessig, Benkler, Zittrain, Shirky and I can go on and on). But one day I realized that if I am bothered by it, I should do more than talk the (often) empty talk of complaint. So I decided to enroll in a day long training for writing OpEds, which kicks off tomorrow. I am not sure if engaging in public debate is what I want to do, mostly because of piling more work and time commitments on a very full plate but I am starting to explore what it means and what it may take to leave the Ivory Tower. Here is a little more info about the OpEd Project:

he OpEd Project - featured by The New York Times, Feministing.com and Katie Couric on CBS News - is an initiative to expand public debate, with an immediate focus on targeting and training women experts across the nation to project their voices on the op-ed pages of major newspapers, online sites and other key forums of public discourse. The lack of diversity on the op-ed pages - which are a source for all other media - deprives the public of robust, democratic debate, especially important in this space which is intended to showcase divergent opinions. It also means we are only hearing from a tiny sliver of the nation’s best thinkers. Imagine a baseball team of only pitchers - how well would it do?

On my parents' small laptop, Windows would just reboot. Even the repair functions of Windows would just reboot. No error message you could read, just reboot, repeat. Linux still worked fine (and my family is fine with using Linux, fortunately).Linux also allowed us to quickly find out what is wrong with Windows: the hard disk is damaged (I like operating systems that give you useful error messages such as "Unrecoverable Error" on your harddisk). And most likely the laptop is out of warrenty since a month ago, as usual.So I'm now investigating if the Linux partition also contains hardware errors, or if we might get away with just disabling Windows altogether for some time, until I get around to buy a replacement harddisk (and a replacement battery, too). So far, our experiences with Medion/Aldi/Tchibo have been rather bad. The TFT screen for the main computer is often flickering, but they failed to repair it in two attempts now. The MP3-CD-Player had stopped reading and the replacement didn't play MP3 at all. And the laptops batteries were crap (and why did they put in two small batterys instead of a reasonably sized one?), I know of a friend where the CD drive of that same model doesn't work anymore, and now our harddisk is dead with just some 11 days of use total (it was meant to be a portable system, and my parents have better computers for daily use at home).If we buy a replacement, it will most likely be a so called "Netbook" with Linux preinstalled. These tiny systems often come preinstalled with Linux (because a Windows licence would increase the price by like 50%) and would fit our requirements pretty well. Not sure which one, though. Maybe an EEE.

A comment on Facebook yesterday got me thinking what American "traditional values" are all about. We hear it a lot, and I suspect it means something different to different people.

Here's what it means to me.

It starts with an ethic fundamentally informed by the central tenets of Christianity -- which are also excellent standards of decency by secular standards. We are called to have a relentless drive to care for the repressed, poor, downtrodden. As Jesus said, "whatever you do to the least of these, so you do to me." It means extending the hand of friendship and compassion to all, in our own neighborhood and around the world. It means taking good care of the resources we have, acting responsibly, and affirming and supporting others so they can do the same. It means that, as our founding fathers emphasized, remembering that all people are created equal, are equally deserving of a good life, and deserve liberty and freedom. Finally, it means a constant realization that we are creating a human institution, and will always have an imperfect answer to these ideals, but that we can -- and must -- recognize our faults and strive to make things better.

How do these apply to our time?

We must start with the poor, the repressed, and habitually think of their situation in everything we do. That means remembering that when we drop a bomb in Afghanistan to kill a terrorist, we also usually kill 50 innocent bystanders, and devastate their families. It means remembering that illegal immigrants from Mexico come here because all they want is refuge from drug wars, food on the table, and a roof over their head. It means showing compassion in deportation proceedings: when illegal immigrant parents have a child born in the United States, the child is an American citizen and can't be deported, but deporting the parents will create an orphan. It means actively helping the repressed people of the world, whether they be in Sudan, Georgia, or AIDS victims in Africa, Muslims in New York. It means reducing taxes on the poor, giving them the skills and tools they need to make their way in life. It means caring for those with alcohol drug addictions, helping them to summon the strength to get past those problems, rather than locking them up or throwing them out on the street. In days past, this might have meant sharing firewood with the family down the road that was at risk of freezing in winter. Today it might mean assistance with winter heating bills.

Remembering that all people are created equal means that we must provide good education for everyone, whether they live in suburban California, inner city Detroit, or rural Appalachia. We owe quality health care to everyone; those without means to pay for health care, or to pay for a car to get to a clinic, should be treated with dignity and respect, and have equal access to medicine.

Remembering that all people are created equal also means that we must provide equal justice under law, and give everyone a fair trail. We must abandon the death penalty, because we have a shocking number of people on death row -- hugely disproportionately black and poor -- that have been shown innocent of their crimes thanks to advances in DNA testing. We must maintain the integrity of checks and balances in government, and support judicial oversight over search and seizure. We must avoid warrantless wiretapping because it subverts judicial oversight and corrupts our justice system by making the exercise of power secret. We must denounce torture, and refuse to employ it, because no human, being created equal, deserves to be treated in such a way -- and we have been applying it to innocent humans.

We owe the opportunity to grow up in a loving family, in a safe community, to every child. We must make sure that gangs no longer have the run of our streets, that drugs aren't displacing hard work as the currency of the community, and that adoption is inexpensive and practical for more families, rather than costing thousands of dollars. Doing so will help every child grow up knowing that they are valued, are important, rather than being unwanted and therefore abused or neglected.

Extending the hand of friendship and compassion to all starts with being a good example -- that shining city on a hill that Reagan talked about. We have to run an open, just, and fair society ourselves. We must not fear those that are different than us, just because they're different. We have to recognize that citizens of Iran, Russia, North Korea, Palestine, and the United States fundamentally are humans, created equal, seeking the same thing: a safe and secure future for themselves and their families. Being able to coexist peacefully means starting from that point, and being willing to talk to them, and yes, even their leaders, regardless of how distasteful they may be.

Acting responsibly with our resources starts at home -- things like not driving up credit card debt, not living outside our means. The same applies to government: massive deficits each year are exceptionally irresponsible and place us at great risk both at the present and in the future. We also have a duty to care for the planet and the environment in which we live, which means actively working to curb the things we do to harm the planet and cause global warming.

What about recognizing our faults? Perhaps the most patriotic duty asked of Americans is dissent. It is never easy, but is essential to keeping our democracy functioning. This country has a long history of successes, and also a long history of failures. We failed so many by keeping slavery legal for so long, and discrimination and lynching legal for even longer. We failed that Native Americans by forcing them from their lands and treating them with brutality. We have, to some extent, risen above these failures thanks to the ability to recognize them and try, to the best of our ability, to fix them. This is what the civil rights movement was about, and why we have a holiday for Martin Luther King, Jr. He spoke out against a society that said some couldn't eat in a restaurant because of the color of their skin, or who were repressed because of their economic status. He recognized that problem in America, and by speaking out against it, helped to change this country for the better.

Today we have to recognize the things we are doing wrong, and try to change them. We are torturing potentially innocent people. We are discriminating against Muslims and homosexuals in our midst. We are giving extraordinary power to big media companies through changes in copyright law, to big communications companies through failure to enact network neutrality laws. And we are labeling people that disagree with war as unpatriotic.

Notice some things I didn't mention, such as abortion. It's not really relevant, and the lines we are fed by both sides present us with this false pro choice vs. pro life debate. In reality, it seems to me that both sides want the best for the children: for every child to grow up in a loving family, where he or she is wanted. We all know from research that laws banning abortion do not actually reduce it. So we ought all to come together and try to make it more rare by providing more support to single parents, by making it easier to adopt children, by trying to make the perceived need for an abortion to go away.

So, in this election, I look at the candidates and it seems pretty clear which one is promoting traditional values and which one isn't. Obama is actively trying to reach across the aisle and find common ground. Even in his convention speech, he suggested ways to work together on abortion like I just mentioned. In the debate, he listened carefully to his opponent and acknowledged when he thought McCain was right. This is a necessary first step in working together to move forward. McCain subsequently released an ad mocking Obama for this.

What about caring for the poor? Again, Obama's tax policies, education policies, and health care policies take care of them far better than McCain's. About responsibility? McCain supported these deficit-busting budgets of the last 6 years, supported the oil-centric energy policies, and has been only lukewarm towards dealing with global warming. McCain and Palin mock Obama for trying to help poor Chicago neighborhoods 20 years ago, for being willing to just talk to our supposed enemies, for actually reaching across the aisle.

So yes, I am a values voter, and that's why I can't possibly do anything but vote for Obama.

There's a lot of debate these days about the impact of the increasing number of paid developers in FOSS communities that started as volunteer efforts and still have significant numbers of volunteers. Evangelia Berdou's PhD thesis "Managing the Bazaar: Commercialization and peripheral participation in mature, community-led Free/Open source software projects" contains a contains a wealth of information and insights about this topic. Berdou conducted interviews with members of the GNOME and KDE projects. She found that paid developers are often identified with the core developer group which is responsible for key infrastructure and often make a large number of commits. Furthermore, she suggested that the groups may have different priorities: "whereas [paid] developers focus on technical excellence, peripheral contributors are more interested in access and practical use". Based on these interviews, she formulated the following hypotheses which she subsequently analyzed in more detail:

1. Paid developers are more likely to contribute to critical parts of the code base.
2. Paid developers are more likely to maintain critical parts of the code base.
3. Volunteer contributors are more likely to participate in aspects of the project that are geared towards the end-user.
4. Programmers and peripheral contributors are not likely to participate equally in major community events.

Berdou found all hypotheses to be true for GNOME but only hypothesis two and four were confirmed for KDE. In the case of GNOME, Berdou found that hired developers contribute to the most critical parts of the project, that they maintained most modules in core areas and that they maintained a larger number modules than volunteers. Two important differences were found in KDE: paid developers attend more conferences and they maintain more modules. Berdou's research contains a number of important insights:

• Corporate contributions are important because paid developers contribute a lot of changes, and they maintain core modules and code.
• While it's clear that the involvement of paid contributors is influenced by the strategy of their company, Berdou wonders whether another reason why they often contribute to core code is because they "develop their technical skills and their understanding of the code base to a greater extent than volunteers who usually contribute in their free time". It's therefore important that projects provide good documentation and other help so volunteers can get up to speed quickly.
• Since many volunteers cannot afford to attend community events, projects should provide travel funds. This is something I see more and more: for example, Debian funds some developers to attend Debian conference and the Linux Foundation has a grant program to allow developers to attend events.
• Paid developers often maintain modules they are not paid to directly contribute to. A reason for this is that they continue to maintain modules in their spare time when their company tells them to work on other parts of the code.

Personally, I'm also wondering why there are some significant differences between GNOME and KDE. For example, about 67% of contributors where paid to work on GNOME whereas only 38% were paid to work on KDE. Why do some projects attract more commercial involvement whereas other projects continue to be mostly volunteer based? (Originally published on FOSSBazaar)

On Sep 23rd I had an accident coming back home from work, and I've been hospitalized until this afternoon, with no internet access.

Nothing too dramatic, but my right knee is broken, so I got to stay put for another month or so.

I'm spending this period away from my home, hence even from my usually Debian box (with my tools, GPG keys, and so); that said, my contribution to Debian in these days will be a little bit "restricted".

I'll be catching up with emails soon: I already saw some needing an input from me, so just wait a little longer and I'll be back to you.

Don't worry, I'll be back!! :)

I would like to add some clarifications to the debate on linux sound APIs that happened last friday on planet. First, despite being portrayed as such, I am nothing like an OSS zealot. I was just recently surprised that OSS developpement still exists and that no one cares. Hence, my initial motivation for my post was to correct false informations, not to advocate for any solution. Now, since the debat has been opened to the issue of linux sound APIs, I feel like adding my two bits. In particular, unlike Josselin, I don't believe that the debate is irrelevant. I, too, would like that we consider two levels for sound APIs:

• Low level, decidated to some specialized applications
• High level, used for simple sound applications, in particular in a desktop environement.

However, there are few points that are missing in Josselin's claim:

• This distinction was not an initial design for ALSA. ALSA was aimed at being both low level and high level, in particular with the pcm virtual devices. However, the lack of documentation and the absence of any high level programming interface for the high level pcm virtual devices just made this goal totally fail.
• Desktop environements didn't agree on a common standard. Even though there seems to be some solutions that are emerging now, like pulseaudio, this is not at all a standard yet. For instance, all graphical mixers I know about only support ALSA.

So, yes, I believe there is still a debate which should not be closed be throwing away idealistic solutions, but by discussing the real issues and trying to settle real solutions. Lennart also commented on previous message that he had adressed most of the remarks concerning the initial guide. In particular, he notices that OSS4 does a lot of audio processing in-kernel, objecting that this means that OSS4 will never be part of the official kernel. This is true, but it doesn't mean there are no life outside of the stock kernel. Here, again, it is a matter of liberty of choice. If some audio applications are better suited for OSS4, then I don't see why we shouldn't provide this alternative.

Our webmaster cooperative is just switching from a building society to a cooperative bank because of support for free software and web standards in their online banking - I’ve just given up waiting for it. That’s disappointing, but the building society has given pretty good service over the years and were early accepters of our LLP company type. For comparison, look at this list of building societies which converted to banks late last century, which have been in the news lately:-

1. National and Provincial Building Society was taken over by Abbey National
2. Abbey National was itself taken over by Banco Santander
3. Alliance + Leicester is being bought by Banco Santander
4. Birmingham Midshires was bought by the Halifax
5. Halifax was bought by Bank of Scotland to form HBOS, which is now merging into Lloyds TSB
6. Cheltenham and Gloucester was bought by Lloyds TSB
7. Bristol and West was bought by the Bank of Ireland
8. The Woolwich was bought by Barclays plc
9. Northern Rock, nationalised earlier this year
10. Bradford and Bingley, nationalisation announced today

So that’s it. All gone. 0% survival rate of demutualised building societies. I’ll be amazed if any more convert in future.

OpenSSH can be compiled against OpenSC. Since the latter has support for the Belgian electronic ID card, that means you can use your eID card to log on to a remote server using OpenSSH. To do this is fairly simple, once you know how it works. First, obviously, you need to have ssh compiled against opensc. Unfortunately, the Debian package comes with that option disabled, but it's easy to enable that:

sudo apt-get build-dep openssh
sudo apt-get source openssh
cd openssh-*
$EDITOR debian/rules

Find the "Common build options", and add another line:

confflags += --with-opensc=/usr

Now add another changelog entry, so that your next apt-get upgrade won't overwrite your locally-modified SSH package:

dch -i

Next, build and install the package:

dpkg-buildpackage -rfakeroot -b -uc -us
cd ..
sudo dpkg -i openssh-client*

You now have an OpenSSH that can access smartcards. So, how do you use it to log on to a remote system? Simple:

pkcs15-tool -c
ssh-keygen -D 0

The first command will tell you the order of the certificates on the card. In my case, the Authentication certificate is first, while the Signature certificate is second. You do not want the Signature certificate; you only want the Authentication certificate. The second command will output the RSA public keys that are on the smartcard in both SSH1 and SSH2 format, in the same order as in the pkcs15-tool output. You only want the SSH2 version, and you only want to get the Authentication key. That key needs to be added to your ~/.ssh/authorized_keys on the remote host. Note that the '0' assumes that your smartcard is in slot 0; if that doesn't work, 'pkcs11-tool -L' should tell you which slot you need. After we've done this, we're ready to start using the smartcard to log in. While ssh-add has an option to load keys from a smartcard, this only works with smartcards that allow one to download the private key from the smartcard into the computer's RAM. This is not possible with the eID (and for good reason), so you can't use ssh-agent with your eID card. However, you don't really need it.

beid-pkcs11-tool -l -t

This will log in to the Authentication key on the smartcard (note that while it is possible to log in to the Authentication key, it is not possible to do the same with the Signature key). You will get the familiar belpic login window now, and the smartcard will now allow use of the private key. In order to actually use this key, you need to specify one extra option to ssh:

ssh -I 0

The -I option instructs SSH to use a smartcard key as a private key. Since we're already logged in to the smartcard, we do not need to enter a PIN code (and regardless, SSH does not know how to do that). You will now be logged on to the server. Note that there is no way to 'log out' of a smartcard; the proper way to do that is to remove your card from the cardreader...

I found a machine which is not so ancient and did some tests with Xen on it.

Dear Adrian, I can only but complain about the "Guide Through The Linux Sound API Jungle" that you mention in your last post. All that is said there about OSS is pure FUD and only reflects a deep ignorance of the current project. It is a pitty to spread misinformations that deprecate the work of others without even trying to understand it. Here is what is said about OSS in this document:

The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.

And here is what one of the devs from OSS answered to this [1]:

It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's author, right? I'd have expected him to know better). He's basically judging OSS per the old OSS/Free drivers, which is like 5 years ago, and even that he does wrong. First, *all* current implementations/emulations of OSSv3 do sample conversion. It's not even a property defined by the API but by the underlying drivers. Second, even OSSv3 supported surround, USB cards, etc. Third, arguing that "it cannot be virtualized" is disproven by the amount of emulations and alternative implementations existing out there and working in practice. (The main difficulty is mmap() API, which is very rarely used anyway, and even that can be done with, say, oss2pulse). Fourth, complaining about OSS API being awkward, is... well, awkward when you compare it to ALSA API, if you could compare it, since most ALSA API isn't documented. It's kinda funny he advocates using ALSA API (not in the quoted part above, but last time I read his blog he suggested it). Actual ALSA devs advocate against it, but using a sound library with multiple backends [2].

If you read some documentation, you can understand that OSS has been the target of some kernel developpers that didn't like it to be reused in a commercial product, back in the 90s. Hence, ALSA was launched, and OSS was progressively discarded, while constantly being the target of FUD like this. OSS has then lived for almost 10 years in the dark side of the force, but eventually did the way back in July 2007. Ironically, now most of the developpement in the linux kernel is driven by commercial interests. Most of the original complains about OSS are now fixed, including all the FUD written in this guide. In particular, software mixing is now supported. Being also part of a project that writes code to handle sound input and output, I can only but complain about the mess in the area of sound APIs in linux. However, OSS should really be reconsidered. In particular, its API is designed in order to abstract as much as possible access to the sound card, so that application writers have as less as possible to do with sound conversion and the like Those who have tried to use ALSA may for instance compare that to the "set rate near" call in its API: this call will set the rate to what the hardware support and let you handle the conversion... For each application... Also, OSS API is available across all unices, except OSX, and there is even a BeOS port going on. Finally, OSS API is POSIX oriented, reading and writing on the sound card, being a matter of calling few ioctls and then reading from the device file. In the future, OSS developpement will most probably be done as a community project, and I believe it is now time to stop spreading false ideas about the project, and give it as much attention as the other projects. For the debian users who want to try OSS4, a package is available in the packaging team's svn repository. It has been sitting in NEW for some time, I hope it gets accepted at some point.

I wrote before about datapacker, but I didn't really describe what it is or how it's different from other similar programs.

So, here's the basic problem the other day. I have a bunch of photos spanning nearly 20 years stored on my disk. I wanted to burn almost all of them to DVDs. I can craft rules with find(1) to select the photos I want, and then I need to split them up into individual DVDs. There are a number of tools that did that, but not quite powerful enough for what I want.

When you think about splitting things up like this, there are a lot of ways you can split things. Do you want to absolutely minimize the number of DVDs? Or do you keep things in a sorted order, and just start a new DVD when the first one fills up? Maybe you are adding an index to the first DVD, and need a different size for it.

Well, datapacker 1.0.1 can solve all of these problems. As its manpage states, "datapacker is a tool in the traditional Unix style; it can be used in pipes and call other tools." datapacker accepts lists of files to work on as command-line parameters, piped in from find, piped in from find -print0. It can also output its results in various parser-friendly formats, call other programs directly in a manner similar to find -exec, or create hardlink or symlink forests for ease of burning to DVD (or whatever you'll be doing with it).

So, what I did was this:


find Pictures -type f -and -not -iwholename "Pictures/2001/*.tif" -and \
-not -wholename "Pictures/Tabor/*" -print0 \
datapacker -0Dp -s 4g --sort -a hardlink -b ~/bins/%03d -


So I generate a list of photos to process with find. Then datapacker is told to read the list of files to process in a null-separated way (-0), generate bins that mimic the source directory structure (-D), organize into bins preserving order (-p), use a 4GB size per bin (-s 4g), sort the input prior to processing (--sort), create hardlinks for the files (-a hardlink), and then name the bins with a 3-digit number under ~/bins, and finally, read the list of files from stdin (-). By using --sort and -p, the output will be sorted by year (Pictures/2000, Pictures/2001, etc), so that photos from all years aren't all mixed in on the discs.

This generates 13 DVD-sized bins in a couple of seconds. A simple for loop then can use mkisofs or growisofs to burn them.

The datapacker manpage also contains an example for calling mkisofs directly for each bin, generating ISOs without even an intermediate hardlink forest.

So, when I wrote about datapacker last time, people asked how it differed from other tools. Many of them had different purposes in mind. So I'm not trying to say one tool or the other is better, just highlighting differences. Most of these appear to not have anything like datapacker --deep-links.

gaffiter: No xargs-convenient output, no option to pass results directly to shell commands. Far more complex source (1671 lines vs. 228 lines)

dirsplit: Park of mkisofs package. Uses a random iterative approach, few options.

packcd: Similar packing algorithm options, but few input/input options. No ability to read a large file list from stdin. Could have issues with command line length.

Ten Easy Ways to Attract Women to Your Free Software Project? I am a little to sick with a cold now to say anything substantive. I agree in spirit with a lot of what the author says though I still think that part of the problem emerges way before the free software project. I still want to know, in other words, why girls/women are not hacking away at a younger age, which puts them at a disadvantage when and if they decided to join a project. Also, though the author as an important caveat in one of his footnotes:

[10] Throughout this article I make a lot of generalizations about how men and women behave. Obviously men and women are not monolithic groups, and there s a lot of variation, so this is just short hand. There are some important differences that apply in the real world, though, whether because of nature or nurture. Indeed, in writing this article, I have taken the assumption that many of the issues are really just manifestations of lifestyle differences, and it s largely because of lifestyle issues that I feel I can identify with many of the problems that women face when dealing with hacker culture in general and free software in particular.

I am still more than a little bothered by the essentialized portrayal of females/males and the concomicant technlogical determinism as well. Thoughts?

I was invited to participate at Festival Internacional de Software Libre (FISOL), in Tapchula, Chiapas. The other invited speakers were Sandino Flores (tigrux), Alexandro Colorado (jza), Eric Herrera (crac), John Hall (maddog) and Fernando Romo (pop), all well-known due to very different contributions to the Free Software movement in Mexico and abroad. Several other people also presented tutorials, but I was not involved in that part, and mentioning one while not the rest would be unfair.
The conference was quite massive - Tapachula is a medium-sized city (~200,000 people) in Mexico's Southernmost point - Sadly, due to its geographical location, it is mainly famous for being the region where illegal immigrants from Central America enter Mexico towards the USA, and it is a known spot for all kind of abuses, both from the authorities and from gangs of thieves.
This is the third time I come to this conference. The first two years (2005, 2006) it was organized by the local CUCS university and it was reasonably large, but this year it counted also with many other universities in the region. Attendance was... HUGE. We were told around 1600 students were registered to participate, and I expect at least 1000 to have actually been there. Very amazing and encouraging!
It is, by far, a base-level conference - Most attendees had had no previous contact with Free Software at all, or had at most toyed around with a distro for some hours. Some people, of course, _are_ already working and involved, on various different degrees. All in all, quite encouraging.
But not only I had fun (and got extremely tired!) at the conference, or at the beer sessions afterwards. I also got to push some more publicity (and work, of course!) towards my new favorite pet project: OpenStreetMap.
As many other Debianers, I joined the fever last August, during Debconf. So far, I have been quite busy tracing and mapping; I am quite fortunate to get the OSM addiction while living on the edge of the well-mapped area of Mexico City. So far, I have mostly worked on the Ciudad Universitaria and Coyoac n areas, where some sensible improvement can be felt. Lots yet to do, for sure, but I'm making progress.
Still, mapping Coyoac n sometimes feels a bit futile. Why? Because all of my cycling/tracing/mapping sessions look almost like a little blip on the overall state of my city, which is way better than what I expected - Most of the central city is done (although lots of work is still pending on the very large outskirts - but getting there can be a trip just by itself!)...
But this time, I had the opportunity to do something new, something better and sensible. And, yes, it feels very good. How does the map of Tapachula look for just a weekend of mapping activity? And, yes, I only went out once (morning running) expressely to get some new traces, the rest of it was while being transported by car to the conference-related activities. And I didn't even have to say once "lets go by a different route"! ;-)
Just for comparison: Last week, Tapachula's state was quite similar to what they have today on Google Maps - Just the major highways in the area. Besides, if you look at the satellite map for Tapachula, I estimate I managed to map around between a fifth and a tenth of the city's surface.
So, have you got a GPS? Do you enjoy going out on the street, be it walking, running, cycling on driving? Or even if you don't enjoy it, are you sometimes forced into it? Start contributing to OpenStreetMap now!

You know, that you did the right thing, when you leave the company building on your last working day, and the first thing comming to your mind is: Free at last!

I don’t have the expertise to intelligently explain the entire global financial meltdown myself, but here are a few resources that merit wide dissemination, especially if you are a podcast-listener:

• The Planet Money Podcast. NPR’s Adam Davidson hosted one of the most memorable episodes of This American Life on the Giant Pool of Money (complete PDF transcript). He has springboarded that show into a frequent short podcast in these times of peril. He finds a near-perfect balance between accessibility and complexity for a non-specialist but educated audience. It’s also entertaining. Of all major media outfits, NPR is miles ahead on the podcast front.
• Paul Krugman’s blog. Admittedly on the partisan side (”Conscience of a Liberal”), Krugman’s analysis is deep both on politics and economics. Steve drew my attention to this excellent illustration of the flaws with the current approach to bailout:

The other night I was relishing in the irony that during the era when the American government became most regulation averse, fully touting and embracing the idea of free markets, it also had to save a core sector of our market, leading effectively to a partially nationalized financial sector. I was going to write about the irony made visible by our current financial crisis but Karl beat me to it and said it better than I could or did. Most papers have not mulled over this irony but here is one place where it was raised

Having already done some Debian packages of OCaml libraries, I wish to share my experience on what are the most common problems. The intent is to help people releasing OCaml libraries to have a good interaction with (Debian) packager. I think most of the tips should also apply to other distributions as well. I consider the use of findlib mandatory for this task as described in the Debian OCaml packaging policy. Problems listed here are common, and I have encountered them for my libraries... In fact, most of the time when I finished building a personnal OCaml library I package it for my own and to test that everything is fine. Being a packager and an upstream author is really a different job. "Upstream author" is used for people developing and releasing OCaml libraries and "packager" for people doing packages for a distribution. Here is the list of the most common problems and their solutions:

• Missing the "static link clause" in COPYING/LICENSE

Libraries are linked statically in OCaml. It is an advantage and a problem. But upstream author should remember that the LGPL license doesn't support static link directly. If you link an executable with the library statically, the executable is contaminated by the license. This error is probably the most problematic, because it requires to go through the whole project fixing license header for explaining that there is an exception to the LGPL. There is no way for a packager to fix this problem. Packager are not allowed to change the license. Library having this problem can be still packaged but complicate the legal aspect of building application using this library. Good example of this can be found in OCaml LICENSE itself :

As a special exception to the GNU Library General Public License, you
may link, statically or dynamically, a "work that uses the Library"
with a publicly distributed version of the Library to produce an
executable file containing portions of the Library, and distribute
that executable file under terms of your choice, without any of the
additional requirements listed in clause 6 of the GNU Library General
Public License.  By "a publicly distributed version of the Library",
we mean either the unmodified Library as distributed by INRIA, or a
modified version of the Library that is distributed under the
conditions defined in clause 2 of the GNU Library General Public
License.  This exception does not however invalidate any other reasons
why the executable file might be covered by the GNU Library General
Public License.

Followed by the text of the LGPL. Each file header looks like:

This file is distributed under the terms of the GNU Library General
Public License, with the special exception on linking described in 
file ../LICENSE.

• Forget that some architecture doesn't have an ocamlopt compiler

By far this is the most common error I have seen. Upstream author consider that you are able to build a native and byte version of their library. Unfortunately this is not the case for most architectures. This error is pretty simple to fix by separating byte and opt targets in Makefile. The ultimate test is to rename /usr/bin/ocamlopt and /usr/bin/ocamlopt.opt to something different and try to rebuild the library from scratch.

• Missing or incomplete META file

META file is the base of everything in findlib. This is very important to provide good META file because it helps other people to easily build thing over OCaml library. Each library should provide its own META file. Until now, Debian packager was used to write this missing META file and contribute it to upstream author. I think that now findlib has become a standard in OCaml developement, so upstream should take into consideration this file. A good test for META file is to install it and:

~$ ocaml
        Objective Caml version 3.10.1
# #use "topfind";;
- : unit = ()
Findlib has been successfully loaded. Additional directives:
  #require "package";;      to load a package
  #list;;                   to list the available packages
  #camlp4o;;                to load camlp4 (standard syntax)
  #camlp4r;;                to load camlp4 (revised syntax)
  #predicates "p,q,...";;   to set these predicates
  Topfind.reset();;         to force that packages will be reloaded
  #thread;;                 to enable threads
- : unit = ()
# #require "ZZZ";;

If you are able to load your library in ocaml toplevel, this is a good point.

• Doesn't use ocamlfind to install library

ocamlfind allow to install library. Using it is the best way to install your ocaml library. Moreovoer, you should use the most simple way to install. For pure OCaml library this is straightforward and allow Debian packager to override destination directory by using environment variable OCAMLFIND_DESTDIR.

install:
      ocamlfind install toto META toto.mli toto.cmi toto.cmxa toto.cma toto.cmx

For non-pure library, you could add a OCAMLFINDFLAGS variable to allow Debian packager add "-ldconf ignore":

install:
      ocamlfind install $(OCAMLFINDFLAGS) toto META toto.mli toto.cmi toto.cmxa toto.cma toto.cmx

• Doesn't distribute .mli files

".mli" files is the human-readable interface to the library. Even if most OCaml programmers use the ocamldoc HTML API of the library, it is best to distribute these files. In particular, Debian packager use it to automatically generate up-to-date HTML API documentation directly.

• Doesn't distribute .cmx files

".cmx" files contain more informations than ".cmxa". Distributing these files allow application based on the library to be more optimized.

• Forget about other OS files

This one comes from my "Windows experiment". Most of the time upstream author doesn't forget about "*.a" but doesn't add "*.lib" (yes is this windows counterpart of ".a" file).

• Use bad wildcard for file to distribute

This one is not very OCaml specific. In Makefile and sh you have the same wildcard "*.mli". But if the wildcard is not expanded into sh, it just stay as is. It will make the executable called looked for a file "*.mli" literally. Mixing Makefile wildcard and sh is the best option here:

install:
     ocamlfind install $(OCAMLFINDFLAGS) toto META $(wildcard *.mli *.cmi toto.cmxa toto.cma *.cmx)

This way you test and expand to only existing files.

• Use a custom build system

This is more or less a problem. In fact, if everything is fine, there is no problem and you should just forget about this point. If the custom build system is complex and if there is an error in it: it becomes a big problem. I must confess that I have myself done this kind of mistake a lot of time. But looking back, I think that most of the time I should have used directly OCamlMakefile. I think relying on ocamlfind for library installation, simple Makefile, OCamlMakefile, OMake or ocamlbuild, is just enough.

• Missing BTS

This point is a problem for upstream author and communication with packagers (from Debian and other distributions). A bug tracking system is a way to publish, comment, work on and find solution of bugs. If you have a single problem in a library having the bug public helps people to show you what is wrong. Of course, Debian (and Fedora, FreeBSD...) has its own bug tracking system and upstream author can use it directly. This is less work for upstream but tends to make the bug "distribution specific". Having an upstream author BTS helps to track the bug across distributions. If upstream author doesn't like maintaining their own BTS, he/she should consider hosting part of the project on a forge like OCamlCore.org. Even if they don't host the source code, this is still a good idea. That's all. If you have other common problems, feel free to comment, i will add it to the list.