I ve never quit a job before. Well, not a real job. Quitting PC World was more than easy, it was practically required for my soul not to leave my body. Quitting Waitrose was, well, it was a freaking supermarket job. And Southampton football stadium I just stopped turning up after one girl fainted in the kitchen from heat exhaustion. But a real, proper handing in of notice is something new in no small part because I ve been in the same place since my first job as a new graduate. Not that I m ungrateful, mind. Looking after big iron at the University of Oxford has been pretty awesome more blinky lights than you can shake a stick at but there comes a time when you need to think about your career, and move on to pastures new. I m fairly sure six and a bit years is WELL past that point. When I started looking at work, I had only a few mandatory criteria a sysadmin job, working with Free Software, without any significant decrease to my monthly income. Beyond that well, in this economy, who am I to argue? What I hadn t accounted for, however, was a job whose awesomeness can t be contained. A job with a dedicated Free Software company whose entire staff roster, top to bottom, is filled with the most talented, smart, and generally awesome people you could hope to work with. Such a job would be a fevered dream, the mere ramblings of a madman. Yet, somehow, for the second time running, I find myself in an enviable job, working exclusively on Free Software. Being able to show off root access to a box with 256 cores and a tibibyte of RAM is pretty cool. But you know what s even cooler? A job where I never need to worry about openSUSE 10.1 administration ever again. A job where several of my colleagues are fellow Debian Developers, with all the prestige and knowledge that comes with such a title. And somehow, by rolling proverbial twenties, I find myself in that position. I am very, VERY proud to say that from the start of January, I ll be joining Collabora Ltd as their new Systems Manager.

The choir I sing in (Pro Musica) will be performing on January 22nd in Bremen, Germany. Together with two local choirs we will perform Verdi's Requiem, which is absolutely fabulous. See for yourself:
<object height="385" width="480"><param name="movie" value="http://www.youtube.com/v/TVjDP0vlem4?fs=1&amp;hl=lt_LT&amp;color1=0x3a3a3a&amp;color2=0x999999"> <param name="allowFullScreen" value="true"> <param name="allowscriptaccess" value="always"> <embed allowfullscreen="true" allowscriptaccess="always" height="385" src="http://www.youtube.com/v/TVjDP0vlem4?fs=1&amp;hl=lt_LT&amp;color1=0x3a3a3a&amp;color2=0x999999" type="application/x-shockwave-flash" width="480"></embed></object>
(Also try Solti's version for better sound quality, but no video.)
It's going to be a busy month preparing for the concert. Verdi's melodies are not complicated, but he's crazy with dynamics: I think it's the first time I've seen a quintuple pianissimo (ppppp) or a quadruple fortissimo (ffff) in sheet music.

Since thousands of people seem to like RSA keys these days and my key is old anyways, I thought: how about running where the other lemmings run So, here it is, my transition to a new gpg key. A properly written transition document is to be found here, obviously signed by both the old and the new key. I d appreciate signatures if your signing policy allows (and you re not insanely signing anything that looks like it could be signed).

After last fixes during yesterday evening, I've decided to put new website online today. It matches layout of my blog, uses same technology underneath (Django). The biggest change is probably simplification of the structure and also cleanup of old unused stuff. I tried not to miss anything, but I'm sure something will be discovered in next days. With this change, I've also shutdown my SVN server as all things has been migrated either elsewhere (usually Debian's collab-maint SVN repository) or are now using Git either on Gitorious or repo.or.cz.

Filed under: Django Website 0 comments

After recent switch of this blog to Django, I've also planned to switch rest of my website to use same engine. Most of the code is already written, however I've found some forgotten parts, which nobody used for really a long time. As most of the things there is free software, I don't like idea removing it completely, however it is quite unlikely that somebody will want to use these ancient things. Especially when it quite lacks documentation and I really forgot about that (most of them being Turbo Pascal things for DOS, Delphi components for Windows and so on). Anyway it will probably live only on dl.cihar.com in case anybody is interested.

Filed under: Django Website 0 comments

I m experiencing since some time (out of the blue) spontaneous reboots of some of my dom0s on lenny/i386 (others don t have this effect). As result of this, I started rolling out linux-image-2.6.32-bpo.5-xen-686 from bpo and backported xen and xen-common from testing:

# dpkg -l grep xen grep bpo
ii libxenstore3.0 4.0.1-1~bpo50+1 Xenstore communications library for Xen
ii linux-image-2.6.32-bpo.5-xen-686 2.6.32-26~bpo50+1 Linux 2.6.32 for modern PCs, Xen dom0 suppor
ii xen-hypervisor-4.0-i386 4.0.1-1~bpo50+1 The Xen Hypervisor on i386
ii xen-linux-system-2.6.32-bpo.5-xen-686 2.6.32-26~bpo50+1 Xen system with Linux 2.6.32 on modern PCs (
ii xen-tools 4.1-1~bpo50+1 Tools to manage Debian XEN virtual servers
ii xen-utils-4.0 4.0.1-1~bpo50+1 XEN administrative tools
ii xen-utils-common 4.0.0-1~bpo50+1 XEN administrative tools common files
ii xenstore-utils 4.0.1-1~bpo50+1 Xenstore utilities for Xen This fixed the problem of spontaneous reboots for all of the systems I have migrated . until now! Last week I tried this solution on my private system and it failed in some way.

A full dump of the syslog is also available. It looks like /etc/rcS.d/S03udev is hanging in some way .. the syslog for this looks like:

Oct 29 20:51:07 mordor kernel: [ 17.728120] Code: 04 00 00 00 00 83 3c 24 10 74 32 77 0c 83 3c 24 08 0f 85 9f 00 00 00 eb 12 83 3c 24 20 74 30 83 3c 24 40 0f 85 8d 00 00 00 eb 35 <0f> b6 01 8b 54 24 20 89 02 c7 42 04 00 00 00 00 eb 79 0f b7 01
Oct 29 20:51:07 mordor kernel: [ 17.731554] EIP: [<c1184d4c>] acpi_ex_system_memory_space_handler+0 189/0 221 SS:ESP 0069:ec135d74
Oct 29 20:51:07 mordor kernel: [ 17.731791] CR2: 00000000eda86000
Oct 29 20:51:07 mordor kernel: [ 17.731881] [ end trace 7b8af581772a1c55 ]
Oct 29 20:51:07 mordor kernel: [ 18.116622] input: PC Speaker as /devices/platform/pcspkr/input/input6
Oct 29 20:51:07 mordor kernel: [ 18.427607] Error: Driver pcspkr is already registered, aborting
Oct 29 20:51:07 mordor kernel: [ 232.381814] Adding 10000452k swap on /dev/sda2. Priority:-1 extents:1 across:10000452k The dom0 is there hanging in some way I don t have an exact way to get the system proceed from there usually I need to wait some seconds and pressing ^C after a while will get the box up.
Anyways I remember there are some problems with udev >= 150 and older kernels, which is also documented in the squeeze release notes. Maybe there is also a problem with older udev and newer kernels? But why is this combination working on other systems? Booting linux-image-2.6.32-bpo.5-686 works without any issue anyways, so it seems xen related. Any idea is appreciated!
UPDATE: I ve also reported this via #602109.

gregoa writes he squashed only 5 bugs in two weeks, and I think he still deserves a huge kudos too, as he squashes them for a long time now :)
And while at it, kudos to everyone who does not post their stats to planet, actually find those bugs, etc etc. Thanks that we have such a community!Now to the usual list of (pseudo) squashed bugs:

• #600782 pyca is NOT compatible with the default python version 2.6
  actually pyca IS compatible with python2.6, it just throws some DeprecationWarnings
  after discussion with maintainer, upstream and submitter, bug downgraded to wishlist, as pyca should be ported to the new libraries to be compatible with later python versions (2.7 is still fine according to upstream, though)
• #600670 libhpmud0 installs /usr/lib/libhpmud.so.0 /usr/lib/libhpmud.so.0.0.6 but sane needs /usr/lib/libhpmud.so that is in libhpmud-dev, not needed to scan
  shipping the .so in libhpmud0 instead of libhpmud-dev seems wrong, patch sent to make the sane backend look for libhpmud.so AND libhpmud.so.0, submitter confirms patch works as expected. NMU not uploaded yet.
• #600530 madplay needs rebuild, currently uninstallable due to dependency
  madplay installs just fine in sid, as it depends libesd-alsa0 libesd0, closed as invalid by the submitter after short discussion
• #601070 python-django: FTBFS in squeeze: test_correct_url_value_passes failed
  some tests need network connection patch that disables these sent
• #599523 update-manager-gnome: wants to downgrade packages without any notice
  this one is old, got updates from the submitter, reproduced the bug in a VM. This is an old known bug in apt :(
• #601186 horde3: only shows php deprecations and a warning no actual operational parts
  why does php again pollute the output with useless warnings? my approach to disable the warnings wasn t succesfull, but a patch created by sed was. However I m not confident with it (OpenSSL anyone?) and want some more eyes to look over it.

While I have spent countless hours working on the new source format known as 3.0 (quilt) , I ve just realized that I have never blogged about its features and the reasons that lead me to work on it. Let s fix this. The good old 1.0 format Up to 2008, dpkg-source was only able to cope with a single source format (now named 1.0 ). That format was used since the inception of the project. While it worked fine for most cases, it suffered from a number of limitations mainly because it stored the Debian packaging files as a patch to apply on top of the upstream source tarball. This patch can have two functions: creating the required files in the debian sub-directory and applying changes to the upstream sources. Over time, if the maintainer made several modifications to the upstream source code, they would end up entangled (and undocumented) in this single patch. In order to solve this problem, patch systems were created (dpatch, quilt, simple-patchsys, dbs, ) and many maintainers started using them. Each implementation is slightly different but the basic principle is always the same: store the upstream changes as multiple patches in the debian/patches/ directory and apply them at build-time (and remove them during cleanup). Design goals for the new formats When I started working on the new source package format, I set out to get rid of all the known limitations and to integrate a patch system in dpkg-source. I wanted to clear up the situation so that learning packaging only requires to learn one patch system and would not require modifying debian/rules to use it. I picked quilt because it was popular, came with a large set of features, and was not suffering from NIH syndrome. This lead to the 3.0 (quilt) source format. I also created 3.0 (native) as a distinct format. 1.0 was able to generate two types of source packages (native and non-native) but I did not want to continue with this mistake of mixing both in a single format. The KISS principle dictated that the user should pick the format of his choice, put it in debian/source/format and be done with it. Now the build can rightfully fail when the requirements are not met instead of doing something unexpected as a fallback. Features of 3.0 (quilt) This is the format that replaces the non-native variant of the 1.0 source format. The features below are specific to the new format and differentiate it from its ancestor:

• Supports compression formats other than gzip: bzip2, lzma, xz.
• Can use multiple upstream tarballs.
• Can include binary files in the debian packaging.
• Automatically replaces the debian directory present in the upstream tarball (no repacking required).
• Creates a new quilt-managed patch in debian/patches/ when it finds changes to the upstream files.

Features of 3.0 (native) This format is very similar to the native variant of the 1.0 source format except for two things:

• it supports compression formats other than gzip: bzip2, lzma, xz.
• it excludes by default a bunch of files that should usually not be part of the tarball (VCS specific files, vim backup files, etc.)

Timeline Looking back at the history is interesting. This project already spans multiple years and is not really over until a majority of packages have switched to the new formats.

• January 2008: the discussion how to cope with patches sanely rages on debian-devel@lists.debian.org. My initial decisions are the result of this discussion.
• March 2008: I have implemented the new formats and I request feedback. dpkg 1.14.17 (uploaded to experimental) is the first release supporting them.
• April 2008: I ask ftpmasters to support the new source packages in #457345.
• June 2008: Lenny freeze. dpkg is not supposed to change anymore. Several changes concerning the new source formats are still accepted in the following months given that this code is not yet used in production and must only be present so that lenny can cope with new source packages once squeeze starts using them.
• February 2009: Lenny release.
• March 2009: Work on squeeze has started, ftpmasters have done nothing to support new source formats, I submit a patch in #457345 to speed things up. I start a wiki page to track the project s progress and to answer common questions of maintainers.
• November 2009: After an ftpmaster sprint, it s now possible to upload new source packages in unstable. This draws massive attention to the new format and some people start complaining about some design decisions. The implementation of 3.0 (quilt) changes a lot during this month. dpkg in lenny is even updated to keep up with those changes.
• March 2010: Up to now, I was planning to let dpkg-source build new source packages by default at some point in the future. After several rounds of discussions, I agree that it s not the best course of action and decides instead to make debian/source/format mandatory. The maintainer must be explicit about the source format that s/he wants to use.
• October 2010: The new source formats are relatively popular, a third of the source packages have already switched: see the graph. The squeeze freeze in August clearly stopped the trend, hopefully it will continue once squeeze is released.
• June 2013: Project is finished?

As you can see this project is not over yet, although the most difficult part is already behind me. For my part, the biggest lesson is that you won t ever get enough review until your work is used within unstable. So if you have a Debian project that impacts a lot of people, make sure to organize an official review process from the start. And specifying your project through a Debian Enhancement Proposal is probably the best way to achieve this. If you appreciate the work that I put into this project, feel free to join Flattr and to flattr dpkg from time to time. Or check out my page Support my work .

12 comments Support my work

Alexander Wirt was so kind to upload the latest icinga (1.2) release to unstable. This will be the next candidate for lenny-backports-sloppy.
If you can t wait, just grab the package from http://ftp.cyconet.org/debian/archive/bpo/icinga/1.2-1~bpo50+1/.
If you are using nagstamon and thinking about upgrading to icinga 1.2, I backported a working version from subversion r151, which you can grab from http://ftp.cyconet.org/debian/archive/bpo/nagstamon/0.9.4r151.1~bpo50+1/. P.S. If you like nagios and/or icinga related software, there is a Nagios Maintainers Group and we would like to invite you, if you want to improve or extend the nagios/icinga ecosystem in Debian.

I've been mostly working on GnuCash the past few evenings. I added more info and a test case to Bug #593856, so that should fall into place soon. I turned my attention to ettercap this evening, and Bug #521857 - another easy one, just applying the updated patch. Except when I ran "lintian -F", I got:

lintian -F /var/cache/pbuilder/result/ettercap_0.7.3-2.1_amd64.changes 
E: ettercap: binary-or-shlib-defines-rpath ./usr/sbin/ettercap /usr/lib
E: ettercap-gtk: binary-or-shlib-defines-rpath ./usr/sbin/ettercap /usr/lib

This led me to a Jan 2008 email from Raphael Geissert about packages defining RPATH on amd64. For now, I've rebuilt in an i386 chroot - I'd need some help making a full lintian run on amd64 if I were going to propose a mass bug-filing.

A month or so ago, I published a paper with Leah Buechley that is mostly an analysis of how the LilyPad Arduino has been used. I read an earlier draft last year and loved it so, when the opportunity arose, I was honored to help out as the paper evolved. LilyPad is a microcontroller platform that Leah created a few years back and that is specifically designed to be more useful than other microcontroller platforms (like normal Arduino) in the context of crafting practices like textiles or painting. Leah's design goal with LilyPad was to create a sewable microcontroller that could be useful for making things that were qualitatively different from what most people made with microcontrollers and that, she hoped, would be of interest to women and girls. Our paper tries to measure the breadth of LilyPad's appeal and the degree to which it accomplished her goals. We used sales data from SparkFun (the largest retail source for both Arduino and LilyPad in the US) and a crowd-sourced dataset of high-visibility microcontroller projects. Our goal was to get a better sense of who it is that is using the two platforms and how these groups and their projects differ. We found evidence to support the suggestion that LilyPad is disproportionally appealing to women, as compared to Arduino (we estimated that about 9% of Arduino purchasers were female while 35% of LilyPad purchasers were). We found evidence that suggests that a very large proportion of people making high-visibility projects using LilyPad are female as compared to Arduino (65% for LilyPad, versus 2% for Arduino). Digging deeper, qualitative evidence suggests a reason. LilyPad users aren't just different. The projects they are making are different too. Although LilyPad and Arduino are the same chips and the same code, we suggest that LilyPad's design, and the way the platform is framed, leads to different types of projects that appeal to different types of people. For example, Arduino seems likely to find its way into an interaction design project or a fighting robot. LilyPad seems more likely to find its way into a smart and responsive textile. Very often, different types of people want to make these projects. Leah and I believe that there's a more general lesson to be learned about designing technologies for communities underrepresented in science, technology, engineering, and mathematics (STEM) -- and for women in particular. The dominant metaphor in the discussion on women in computer science is Margolis and Fisher's idea of "unlocking the clubhouse." The phrase provides a good description of the path that most projects aimed at broadening participation of women in computing projects seem to take. The metaphor is based around the idea that computing culture is a boys' club that is unfriendly to women. The solution is finding ways to make this club more accessible to those locked outside. It should go without saying that we share Margolis and Fisher's goal of increasing participation of women in STEM. That's LilyPad's point, after all. It it hopefully also clear that we're supportive of, and involved in, projects working to remove systematic barriers to participation by women and other groups. That work must continue. But I also think that Leah's work with LilyPad suggests another way forward based on addressing issues of self-selection that will affect even the most welcoming technological communities. Here's what we say in our paper:

Our experience suggests a different approach, one we call Building New Clubhouses. Instead of trying to fit people into existing engineering cultures, it may be more constructive to try to spark and support new cultures, to build new clubhouses. Our experiences have led us to believe that the problem is not so much that communities are prejudiced or exclusive but that they're limited in breadth--both intellectually and culturally. Some of the most revealing research in diversity in STEM found that women and other minorities don't join STEM communities not because they are intimidated or unqualified but rather because they're simply uninterested in these disciplines. One of our current research goals is thus to question traditional disciplinary boundaries and to expand disciplines to make room for more diverse interests and passions. To show, for example, that it is possible to build complex, innovative, technological artifacts that are colorful, soft, and beautiful. We want to provide alternative pathways to the rich intellectual possibilities of computation and engineering. We hope that our research shows that disciplines can grow both technically and culturally when we re-envision and re-contextualize them. When we build new clubhouses, new, surprising, and valuable things happen. As our findings on shared LilyPad projects seem to support, a new female-dominated electrical engineering/computer science community may emerge.

I have a strong belief that computing can be an empowering tool and that expanding users' control over technology is a critically important issue. Our paper argues that we should attempt to expand participation in computing by broadening the possibilities of computing, rather than only by broadening participation in extant, computing organizations, projects, and genres. Even if computing and electrical engineering communities were perfectly welcoming (which they are not) most people (both male and female, but disproportionately female) will choose not to participate. Building new clubhouses requires creativity of its proponents and risks charges of reinforcing stereotypes and existing status hierarchies. But, executed carefully and well (as I believe LilyPad has been), it suggests ways to reach the majority of people that no "unlocking" project will ever seem relevant to.

Kevin Stone gave an interesting TED talk about the biological future of joint replacement [1]. Using stem cells and animal tissue which has been prepared to destroy the chemicals that trigger immune responses the tissues can regrow. Replacing joints with titanium and ceramic lets people walk again, regrowing them with Kevin s methods allows them to compete at the highest levels of sporting contests! Derek Sivers gave a brief and interesting TED talk advising people to keep their goals secret if they want to achieve them [2]. The Parrot AR.Drone is an interesting device [3], it s a four-propeller helicopter that is controlled by WiFi. Apparently there is little security (it binds to the first WiFi client it sees) which is a significant down-side. It returns a video feed to the controlling iPhone as it flys and can hover when it loses it s connection. It will be interesting to see when people write software for other devices (Android etc). Also I wonder whether there will be open source weapons kits for it. If you could have those devices use either a nerf gun or a lance to attack each other s turbines then you could have drone jousting. Don Marti had an interesting new idea for a crime game [4]. The main concept is to use the element of mistrust that is present in real criminal gangs. The new guy you invite to join a job might inform the police and you won t know for sure. Sometimes a heist will be discovered by the police through bad luck (or good police work) and you will wonder whether there was an informant. The aim is for a simple game design and with the complexity in email discussions between the players. The C64 isn t dead, it s even on the Internet [5], an original C64 is running a web site! Tan Li gave an interesting TED talk about a new headset to read brain-waves [6]. The device in question can be applied in minutes, requires no gel or abrasion of the scalp, connects to the computer wirelessly and is relatively cheap at $300US. The developer s kit (which I think includes a headset) is $500US. I wonder if the community can develop a cheaper version of this which is more open. Lisa Margonelli gave an interesting TED talk about the politics of oil [7]. One of her insightful points is that the subsidies for oil should be shifted from the oil industry to middle-class consumers. But she goes off track a bit by suggesting gradual oil tax increases until 2020, according to the best estimates of groups such as the CSIRO they won t need to have taxes to give a high oil price in 2020! She is aiming for a 20% reduction in petrol use by 2020, but I m not aware of any serious group of scientists who have evidence to suggest that the production capacity in 2020 will be close to 80% what it is now. Slate has a good article about The Innocence Project which uses DNA tests to overturn false convictions [8], it s scarey how badly the justice system works. Rachel Sussman gave an interesting talk about the World s Oldest Living Things [9], nothing less than 2000 years old is included. Nicholas Negroponte gave an interesting EG 2007 talk about the OLPC project [10]. While some of the content about OLPC production is a little dated the OLPC history is relevant and his personal opinions regarding the benefits that children receive from computers are insightful. Jayne Poynter gave an interesting TED talk about life in Biosphere 2 [11]. Her work on mini-biospheres is also interesting. Let s hope we get a permanent Biosphere running outside the Earth sometime soon. Sheryl WuDunn gave an informative TED talk titled Our Century s Greatest Injustice about the plight of women in most of the world [12]. Daniel Kahn Gillmor wrote a good article about the use of ssh-agent [13]. You really should use it to secure your ssh keys. Mark Shuttleworth has described the development process for the Ubuntu font [14]. This is a very interesting project and IMHO one of the most significant things that Ubuntu has done. Prior to this an entirely closed development process has been used for font development. Now we are getting a major new font family developed with a free and open process and with some new legal developments for a font license! One thing to note that this project appears to have involved a lot of work from professional font designers, it sounds like Canonical spent a significant amount of money on this project.

• [1] http://www.ted.com/talks/kevin_stone_the_bio_future_of_joint_replacement.html
• [2] http://www.ted.com/talks/derek_sivers_keep_your_goals_to_yourself.html
• [3] http://toucharcade.com/2010/09/06/parrot-ar-drone-review-the-coolest-rc-toy-ive-played-with/
• [4] http://zgp.org/~dmarti/wiki/software/better-crime-game/
• [5] http://www.c64web.com/
• [6] http://www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html
• [7] http://www.ted.com/talks/lisa_margonelli_the_political_chemistry_of_oil.html
• [8] http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/08/17/reasonable-doubt-innocence-project-co-founder-peter-neufeld-on-being-wrong.aspx
• [9] http://www.ted.com/talks/rachel_sussman_the_world_s_oldest_living_things.html
• [10] http://www.ted.com/talks/lang/eng/nicholas_negroponte_on_one_laptop_per_child_two_years_on.html
• [11] http://www.ted.com/talks/lang/eng/jane_poynter_life_in_biosphere_2.html
• [12] http://www.ted.com/talks/lang/eng/sheryl_wudunn_our_century_s_greatest_injustice.html
• [13] http://debian-administration.org/users/dkg/weblog/64
• [14] http://www.markshuttleworth.com/archives/537

Working on a new feature for eSpeak GUI I started looking into language identification. Forcing users to manually choose the text s language is a botheration, so trying to guess it by checking which system dictionary contains the most words from the text or some other method would surely be beneficial. After a quick search I learned that it s much easier than this: it s possible to reliably determine the language based on statistic n-gram information. Ignoring the fact that now I officially hate Firefox, Chromium, OpenOffice.org and everyone else there for not implementing this and having me spend the day changing the spell-checker s language, I was left with the choice on how to use this in eSpeak GUI. The first option I found was TextCat, which is also the only library I ve found to be packaged for Debian. However, ignoring the fact that upstream isn t maintaining it any more (such a library shouldn t need too much maintainance, after all), the package declares incorrect dependencies (bug filled a month ago, no response yet) and the API is also pretty crappy (it requires a physical file indicating the location of the statistic models). Unrelated to that, I ve also found that the Catalan text samples it includes are incorrect, so the same may be true for other languages. I guess it d make sense to work on a new (and completely Unicode) language samples collection. I ve thought of using something like the Universal Declaration of Human Rights since this way all languages can have the same text, but being more of a legal thing it may be biased by some words being too repetitive. Looking for other alternatives to the TextCat library I ve only found the following:

• TextCat (same name, different code): PHP licensed, so incompatible with GPL projects.
• Mguesser (part of mnogosearch-mysql): it s a standalone executable and not a library.
• SpamAssassin s TextCat.pm: also a standalone executable, this time written in Perl. Apparently they were using a fork of TextCat (the original library, not the PHP licensed one) before that.

So it looks like I ll have to start by getting a good collection of text samples I can use to generate the statistic data. Then I have several options on how to actually use it. As I see it, those are my possibilities:

1. Fixing libtextcat s packaging and just using that.
2. Taking it over as new upstream maintainer. Not my preferred option as I don t really feel like maintaining a C library at this point.
3. Trying to convince the maintainer of the new TextCat (with last commit January this year and a more sane API) to re-license it in a GPL-compatible way, packaging that and seeing how that one works (haven t tried it out yet).
4. Writing my own implementation in Python, maybe based upon this example or TextCat.pm.

Any other ideas, pointers to some library I may have missed or offers to collaborate are very welcome. Please also note that my intention in writing this post is not only to rant about there being no well-maintained ready-to-use library being available, but especially raising awareness on the topic of language identification. I d love to see this feature all around the desktop, just like (and in combination with) spell-checking, which is already omnipresent. Related posts:

1. espeak-gui 0.2
2. Introducing espeak-gui

---

11 comments
Siegfried-Angel Gevatter Pujals, 2010. Permalink License Post tags: language identification, Programari lliure, text categorization

Okay, adding comments lead exactly to the expected situation of spam comments, so I just added fccv and started using typepad to help me in fighting with spam. I hope it will catch most of it (it would catch all I've had to delete manually so far) and will avoid false positives.

One of reasons of recent move my blog to custom Django based application was use of comments. Today I've finally found time to enable support for them, so you can provide me feedback directly without mailing me or reposting on some planet where my blog is syndicated. I hope it will not turn into fight with spam bots, for now I'm using only protection Django has built-in.

On January 30, 1998, Wired.com gushed about the ethical underpinnings of the free software movement. The movement was growing:

Netscape's bold move last week [was] to free the source code of its browser is a prime-time endorsement for no-cost, build-it-yourself software.

The free software movement was in its second decade. In the first decade, corporations learned to tolerate it. In the late '90s, a transition was underway. Red Hat was one of the first companies ostensibly founded on free software principles. But as free software grew, some were concerned that its name was holding it back. The article explains with a link to a page within gnu.org:

But "free software" is an ambiguous term - there is a difference in meaning between the cultures of PC-based proprietary systems and the Net-centric UNIX worlds.

Michael Stutz, the author of the piece, surveyed the writing of Eric S. Raymond and interviewed luminaries like Bob Young, Russell Nelson, and Marc Andreessen. The article is about the creation of a new term for the freely-reusable code produced by the free software movement.

As proponents of free software often point out, while this software can be free-of-cost - that is, gratis - the real issue is about freedom, or human liberty. So it is really freed software.

Yes, that's right -- freed software. The emphasis is in the original. Most of us know the names Eric S. Raymond and Russ Nelson as people involved early-on in the Open Source Initiative. I guess January 1998 is before they decided on the "open source" name. Today, the community is divided into people who think it's important to say "free software" and the rest who call it "open source." We'd all agree with the following statement from the article:

"Freed software is a big win for society in general," said Russell Nelson.

And that's today's random page from the history books.

If so, please tell me in the comments, how and for what purpose. I m pondering if this configurability is unnecessary baggage.

I was quite unhappy with nanoblogger which I was using for quite some time on this blog. Not that it is bad, but it really scales bad. Having more than 600 of blog posts is something which it really has troubles to handle. So I decided to go somewhere else. After looking and testing some ready solutions, I rather decided to implement my own engine using Django. The implementation took exactly one evening including script to migrate old posts, so it was really an easy task. As a bonus I get quite easily reusable components once I decide to change my main website to Django as well. Also while doing this change, I changed the look quite a lot, hopefully this one is easier to navigate and it did not lose any of old functionality.

I was quite unhappy with nanoblogger which I was using for quite some time on this blog. Not that it is bad, but it really scales bad. Having more than 600 of blog posts is something which it really has troubles to handle. So I decided to go somewhere else. After looking and testing some ready solutions, I rather decided to implement my own engine using Django. The implementation took exactly one evening including script to migrate old posts, so it was really an easy task. As a bonus I get quite easily reusable components once I decide to change my main website to Django as well. Also while doing this change, I changed the look quite a lot, hopefully this one is easier to navigate and it did not lose any of old functionality.