Jim Gettys wrote about a problem regarding localisation that the OLPC project will face in the future. The One Laptop Per Child project aims to provide the famous $100 laptop to children in the developing world. They are Free Software based, and as most GNU/Linux distributions, the bundled software will be available in a number of languages. For now, it'll only be ten or so, but as OLPC grows, the number will skyrocket... just think about the number of languages spoken only in Africa. The $100 laptops don't have a hard drive. Instead, they have a 1 gigabyte of compact flash memory, which is enough to run the software, but it can't store that much extra data. The most common way of internationalising and localising Free Software is to use GNU gettext, which provides an easy to handle text file format for translations, with a series of sentences and labels that the translators need to fill in in their language. The applications ship these translations in .mo files, which are the same .PO files, in compiled binary format the gettext enabled programs can read. Each application installs one .mo file per language it is translated into. When the apps are big enough, these files can amount to several megabytes per application, which is a problem for embedded systems or projects like OLPC. Ubuntu has been trying a different approach to the distribution of translations. Instead of packaging all the translation files with the applications .deb packages, they are stripped off from the packages, and provided by language packs. Language packs offer the translations for all the applications and libraries of the main component of Ubuntu. This includes GNOME, KDE and many other popular applications. When you install Ubuntu, you select the main language of the interface, and the installer program will download the appropriate language pack, plus a selection of useful localisation-related packages like dictionaries, translated manuals, etc. These language packs are generated periodically by Rosetta, a web-based translation portal which is sponsored by Canonical, Ubuntu's and Launchpad.net's parent company. Rosetta offers a very easy to use translation infrastructure, and Ubuntu users can start translating the applications they are running with just two clicks on the application's interface. With Rosetta lowering the barrier for people wanting to translate Free Software, Ubuntu can have, and is now having, lots of people improving the translations of not only the next version of the software, which is what translation groups have traditionally worked on, but also the version you are running at that same moment. There is no need to wait for the next version of Ubuntu to see your translations complete. Help your team translate whatever is missing, and wait for the next language pack update. Voil ! If the OLPC project adopted the language pack scheme and Rosetta, they could install a raw OLPC laptop without translations, and only install the language packs that are needed in the target country or area. The langpacks are currently split into GNOME, KDE and the rest , but any derivative could fine-grain the components they wish to include. Furthermore, the system helps improving the localisation of the system after the laptops have been deployed. Just stick a USB drive to the laptop, and use your usual package manager to install the updated language packs contained in it. Or just use the Internet if it's available. In environments where network access is completely impossible, making the availability of updated packs from a remote server a no-op, as well as online translation in the Rosetta server, other solutions could come in place. Generating langpacks from a set of local PO files should be pretty easy.

Hi! This is Comas, the conference management system we all know and love! Perhaps you remember me from /www.consol.org.mx/">/www.consol.org.mx/">CONSOL 2004 and 2005, Debconf 5 and 6, CICOL, Seminario Globalizaci n, Conocimiento y Desarrollo or other such great conferences! Well, it is a pleasure for me to announce I am moving.
That's right - My developers have felt too constrained by CVS to keep being merry and productive, and decided to move away from it and to Subversion. If you are tracking my development history, you should have noticed a new file in my base CVS directory, called DONT_USE_THIS_REPOSITORY_ANYMORE. I will reproduce it here following Gunnar's wishes, and hoping it is useful to you.

PLEASE DON'T USE THIS REPOSITORY ANYMORE! Just in the meantime, while we migrate our current installations to point to the correct server, while our users take note, and while the kind GBorg admins lock down this project: PLEASE DON'T USE THIS REPOSITORY. WE HAVE MOVED. The Comas project will no longer be hosted at GBorg - We are moving to Debian's Alioth.
Comas' webpage (although it is still ugly :) ) is still the same as always. The repository will no longer be handled through CVS - We switched to Subversion. Don't worry, the usage is basically the same. You can use anonymous access to get the Subversion tree. If you want to participate in the project, register at Alioth and ask us for commit access. You can also use the very nice SVN Web interface, which allows you to look at each of the files, view the changes, and even subscribe to the Comas RSS feeds! Development goes on. Stay tuned! Greetings, - Gunnar Wolf

Of course, as in any migration, there is still a lot of things to do. Mail the other contributors and interested people notifying them of the move. Migrate (and check the validity of) any tickets we have in the old site. Point all the places where there is Comas-related information to the new repository. Close the existing project page at GBorg. Sanely re-structure the repository in a more standard and functional way (and hope it does not break current installations ;-) ). Rework the documentation that has been neglected in the last months. Rework the bits of logic that never smelt very good but -as a dead rat- now positively stink. Fixe the things that will eventually stink as well... Anyway, I'm sure this will speed up my growth!
I am very excited on which way my dear authors will continue to push me - I know I'm quite a lousy program for many things, and I know there is a lot for me to learn until I am a military-grade conference management system - But my many parents have written me with deep love, and I understand they had to write hastily parts of my code. I understand their mistakes, but I hope they make them go away soon.

Yesterday, I added Wolfgang Kechel as a committer to the Hecl project, because of the good work he's been doing on it. He's demonstrated consistency and quality over a number of months, and has also shows he understands where I want to go with the language, so it was a natural thing to do. Adding a new committer is not always so clear cut, though, and it's sometimes a difficult decision, especially with smaller projects. I find that it's much more fun to work on projects with other people, so I want to encourage them to get involved, and granting access is something that ought to give people a bigger stake in the project, and reward/encourage them in their efforts. In practice, it doesn't always work out that way, though. Often, after a bit of initial work, they dissappear, which means they weren't really that interested in the first place, and you shouldn't have bothered granting them access to the code - they could get by just fine by submitting patches. The question of openness vs control also plays a strong part in the difficulty of the decision. I think the Apache Software Foundation way of doing things (decisions by consensus of those who work on the code) is pretty successful for well established projects, but I'm also convinced that the "benevolent dictator" model is best in some cases. Design by committee doesn't work very well for projects like a programming language where you really want to have one coherent vision, rather than some sort of frankenstein mishmash of pieces. (As an aside, Larry Wall, has done a fine job of proving that you can have - even revel in - a mishmash, even with a 'dictator'!). The point being that it's a little scary to hand someone the keys to your project, because you take a risk on them working counter to your goals, especially in new projects without a self-propagating culture in place. An established language like Python has a fairly large number of people who can instinctively tell you if a new feature is "pythonic" or not. But for a small, new project like Hecl, the risk is that there is more room for unproductive arguments, or having to back out "bad" changes should someone really take off in a direction you don't like. Of course, with Hecl, I think it is at a great point in its life. There *is* a lot of room to hack, because it isn't used by many people, so we don't have to worry about angry users if we break it while trying to improve it! All things considered, it's a positive step to get more people involved, but it's important to start building a culture in order to keep your code going in a healthy direction. Depending on the project, that culture might include a healthy dose of what is and what isn't within the project's scope, or it might simply regard the quality of code considered acceptable. For instance, Tcl's standard library is pretty open to whatever people want to implement, however you must accompany your code by either tests or documentation, and preferably both. I think the most interesting phase is when you are "bootstrapping" - going from just one person to a group. Judging by the number of small projects that have fallen by the wayside without ever getting more than one person to work on them, it's also the most difficult period in a project's life. What do other people think? What tactics do you use to get people involved, yet still make sure they are the right people?

Google updated it's famous Google Earth software (which is a really nice toy, actually) with new data. There are now high-res shots available for most (or maybe all?) of Germany. However in regions like eastern Munich, where Google Earth already had high-quality shots, these have been replaced with older imagery. I believe that these "updated" images are one to two years older, judging by some missing construction sites. I'd date the previous shots to October 2004, the new ones to October 2003. Given that Google just added satellite imagery for germany, I guess they'll add map/street data to google maps for germany soon, too. And did you know that you can run Google Earth using Wine on Linux, too? The 3D display is working okay, just the menus don't render correctly. Oh, and some fun: type "Frankfurt, Germany" into Google earth. It won't take you to the well known financial city in germany, with the international airport, but instead to the "less important" "Frankfurt an der Oder" close to the border to poland. If you want the other Frankfurt, you have to type "Frankfurt am Main, Germany". Oh, and "Torino, Italy" is the only continental european region with street maps available on Google maps.

I just read a story on The Register entitled Oklahoma city threatens to call FBI over "renegade" Linux maker. Quite hilarious. Apparently Jerry Taylor, city manager for Tuttle, Oklahoma, noticed that the city's webpage wasn't working right. He got the default "test page" for the Apache webserver on CentOS. Instead of calling the hosting company, he sent a series of vicious emails to CentOS, even threatening to call the FBI. The CentOS folks really went out of their way to help this guy -- he was not even their customer. And he repaid them by saying they should have helped him sooner. Of course, there was the obligatory comment about being computer literate: "I am computer literate! I have 22 years in computer systems engineering and operation. Now, can you tell me how to remove 'your software' that you acknowledge you provided free of charge? I consider this 'hacking.'" The Register story is hilarious, and the original discussion even more so because it includes a full transcript of the event. Favorite quote (to the city manager):

If you will not let me help you, or at least talk to someone who knows what Linux is, then you will look like an idiot. Your choice.

Should anyone wish to write to the city manager of Tuttle, OK, to complain about his outrageous behavior, his e-mail address is citymgr@cityoftuttle.org. Assuming they have figured out how to properly configure e-mail. He's probably not worth his $63k salary and with a personality like this almost certainly isn't giving his employees the "feeling that we're 'working together'" (see that link). Sigh. Why do people hire a guy like this in the first place?

I've now moved my blog into ikiwiki. I think that I've managed to do this without breaking (many) permalinks to old blog posts, and without flooding any aggregators. .. Well, almost. Some of you may have seen a double post, which was due to me not having an url set right the first time.

I've now moved my blog into ikiwiki. I think that I've managed to do this without breaking (many) permalinks to old blog posts, and without flooding any aggregators.

When I donated blood at the Red Cross blood drive at work, they also took an extra vial to test donor suitability for apheresis (platelet donation). Sure enough, I was a suitable candidate, and got a letter in the mail a while ago inviting me to donate. Back when I used to donate in Brisbane, I'd seen the plasma donors in the other room, all hooked up with blood coming out one arm, getting the plasma spun out, and the red cells going back in the other arm, and it totally grossed me out. The concept of having that for 2 hours wasn't all that appealing either. The letter said my donation would be helping out cancer patients, and as I recently lost an uncle to cancer, I thought I'd give it a go, just once, to see what it was really like. Man, I'd hate to have renal failure and need dialysis, that's all I can say, because having to have this done to you every week would be a real drag. Better than dying I guess... I had the "out" hose hooked up to my right arm, and the "in" hose on my left. They had a bit of trouble getting a good flow out that way, so if I ever do it again, I'll probably try it the other way around. The recliner you lie on is heated, as apparently the "in" hose is a bit cool, but I didn't notice (the nurse did say my left hand got pretty cold at the start though). They also heap the blankets on you. You get a selection of movies to watch, so I watched War of the worlds, which was a good length. It finished just as they were unplugging me from everything. I did feel a bit tingly towards the end, and felt a bit woozy when I got up, but that could have been as much from lying down for 2 hours as anything else. So would I do it again? Not in a hurry. It's pretty time consuming. We got up early and drove to Oakland, both because that was the only place with a slot available today, and we haven't been to the eastern side of the Bay yet. So we hit the road just after 8am, and weren't out of the blood bank until midday, so it's not the sort of thing I'd be wanting to do regularly. So that's my good deed for the day. Oh, and having hairy arms really sucks.

Over the last 2.5 weeks I have built the complete Debian archive on a quad-core MIPS machine donated by Broadcom using the recently released version 4.1 of GCC. In parallel, I have done the same on an EM64T box donated to Debian by Intel. The purpose of this exercise was three-fold:

• Find out about compiler problems in GCC 4.1 itself as well as in packages that may fail with the new version before GCC 4.1 is uploaded to unstable. GCC, in particular G++, is becoming stricter regarding adherence to standards and packages may fail to build with 4.1 due to invalid code that was accepted previously.
• Find out about MIPS specific problems in GCC 4.1 and to answer Matthias Klose's question as to which platforms can move to GCC 4.1 as the default compiler once it is uploaded to unstable.
• Find MIPS specific assembler warnings and create a list of all users of xgot (a MIPS specific toolchain problem).

Executive summary GCC 4.1 itself appears to be very stable, both on MIPS and AMD64. There are, however, a large number of packages using code (especially C++) which GCC 4.1 treats as errors. Fortunately, most of them are trivial to fix. By compiling about 6200 packages, over 500 new bugs have been discovered and submitted, 280 of which are specific to the increased strictness of GCC 4.1. Patches for 2/3 of those GCC 4.1 specific bugs have been submitted. Based on my findings, Ben Hutchings has prepared a summary of the most common C++ syntax errors (that weren't treated as errors before G++ 4.1). Most common programming errors Basically, it all boils down to broken C++ code. There were a few bugs in C code, but the majority was in C++. The most common errors I found are:

• extra qualification
• reliance on friend injection
• wrong escape characters (e.g. "\.", most commonly seen in regular expressions)
• iterator problems (such as assigning 0 or NULL to an iterator)
• template specialisation in wrong namespace
• template reliance on a function declared later
• use of template's base class members, unqualified, where the base class is dependent
• use of assert without #include <cassert>
• dereferencing type-punned pointer will break strict-aliasing rules (a warning) combined with -Werror

I've posted a detailed report to debian-devel. Acknowledgements (abridged)

• Broadcom for supporting our MIPS port through the donation of hardware to the project and developers. Without Broadcom, our little and big endian MIPS ports would have a hard time meeting the release criteria regarding autobuilders.
• Google for supporting my PhD, thereby allowing me to spend two weeks compiling the archive with GCC 4.1 and sorting out failures.
• Intel for supporting some PhD work which led to this experiment.
• Ben Hutchings for explaining many of the C++ bugs I found to me. I've learned more about C++ in these two weeks than I ever wanted to know. ;-)

Or more precisely: not at all. I wanted to find out what the performance difference between the opensource radeon drivers and the proprietary fglrx drivers from ATI is. But it seems that the drivers from ATI do not support my former top-notch ATI mobile chipset I have...

ATI Technologies Inc Radeon RV200 LX [Mobility FireGL 7800 M7]

is the output of lspci, this is a IBM Thinkpad A31p (so a long-time top model of the Thinkpad series, with a great 1600x1200 display and 64 MB video ram) The opensource driver works fine, with 3D acceleration. The proprietary driver returns the error message "[fglrx:firegl_init] *ERROR* Device not found!", from deep within the binary blob provided by ATI. No way for me to get that working. The docs at ATI suggest that they don't intend to support that video card. I want opensource drivers (because they just work a lot better), so please stay away from me with that non-working proprietary stuff, and open up your software interfaces, please. Thank you. And please stop requesting interfaces to load your binary stuff into the kernel... I doubt that there is any real trade secrets involved in the software interface... but maybe, as suggested before, "competing hardware manufacturers are violating each others patents so much that they cannot publish specifications of their hardware without showing which patents they are violating"?

So I watched this Australian movie (Somersault) the other day and the cute accent reminded me again how much I miss the country. It has almost been 2.5 years since I left and I'd really like to visit again. Maybe I should try to make it to LCA next year. In a related note, I'm looking for Rob Weir who has mysteriously disappeared from the Internet. Does anyone know what's up with him? As much as I like Cambridge, staying at the same place for 2.5 years obviously doesn't work. ;) Next week I'll therefor go to Vienna for some "holidays" the first thing I did was to sign myself up for a talk... if anyone wants to hear me babbling about quality in free software on Monday, check out the Debienna site. Right after my return from Vienna I'll go to Spain where I'll spend three months working in the Libre Software Engineering research group around Jesus Barahona (a Debian developer) and Gregorio Robles. I'll actually work on my PhD for a change during that time and do cool quantitative work to support the qualitative studies I've done so far. Obviously, instead of packing, I spent the last few days and weeks hacking on Debian stuff, in particular making sure it works on the MIPS and ARM devices I support and which I cannot take with me to Madrid. So we finally have 2.6 kernels for MIPS in the archive now and debian-installer will move to it tomorrow. I've also compiled the whole archive on MIPS with GCC 4.1 but a more detailed report on that is forthcoming. P.S. In terms of Spanish movies, I can highly recommend The Lovers of the Arctic Circle and Talk to Her.

A nasty little bug snug into 0.8.5: price data without open/high/low/volume (as e.g. for mutual funds) failed with the new SQL chunk creation -- this is now fixed. We now also pick up $host if set in ~/.beancounterrc, and made the two helper scripts setup_beancounter and update_beancounter actual bash scripts as they were reported to fail under the smaller/simpler dash shell. The bug fix release 0.8.6 is now in Debian's incoming area, uploaded to CPAN and onto my beancounter page and an announcement has been registered for the corresponding Freshmeat record.

By now, you would think that I would have learned that Breakfast + Freshmeat = mess. Today, we have an unimaginatively named program called "font manager". Some day, in the future, we may have a font manager -- but we don't yet. Here's the description, direct from the horse's mouth:

font manager is a font manager for GNOME. It cannot do any font management tasks yet, but is already useful for picking fonts.

It's quite adamant that font manager is a font manager. Yet it can't manage fonts. Interesting. I suppose this is an example of the curious issue of true identity -- are you who you are because of what you are called, or because of what you are? The author(s) of "font manager" obviously believe that your true identity stems from your name, regardless of what you may actually do. I disagree somewhat -- in a lot of ways, I identify more closely with the term "computer geek" than with my name -- I think it's essentially social conditioning and a need to be uniquely identified from all the other computer geeks out there that makes me remember to respond to a call of "oi, Matt!". An interesting book on this subject is Jennifer Government, by Max Barry (ISBN 0349117624), in which people's surnames are determined by who they work for (so take a guess as to who Jennifer works for). There's something very wrong with me when a quick scoff at a freshmeat article turns into pseudophilosophy and a book review...

I wrote a wiki engine last week, maybe I should write a weblog engine next week? Here's my own take on converging the two, which has been done before, but which some differences in ikiwiki perhaps allow to be approached slightly differently.

• ikiwiki supports pages that are subpages of others, for example, "Page/Discussion".
• Various parts of ikiwiki allow users to select a set of pages using globs. For example, "SomePage OtherPage OtherPage/* !OtherPage/Bar"
• ikiwiki renders pages statically, and can render rss statically too. This makes rss rather less expensive to serve..

First, I plan for all pages in the wiki generate a rss feed for that single page, which can be subscribed to if you want to track changes to the page alone. Then, pages can have a blog embedded in them by adding a special tag to the page, which includes a list of globs for the pages on the wiki that comprise the blog. Something like "Blog/* !*/Discussion", to exclude discussion subpages from the blog. This makes the most recently created of those pages be inlined into the html version of the page (with a form at the bottom to make a new post, if you don't want to commit to svn by hand) ... and enables creation of a regular rss feed too. Some nice features that just fall out of this:

• It's easy to set up subfeeds for categories. Just make blog pages for the categories, and an overall blog page that includes everything.
• All blog pages get discussion pages, without having to worry about people spamming your blog (unless they're already spamming your wiki of course).
• You can subscribe to an rss feed for any of the discussion pages if you like. Discussion pages can even be turned into little blogs of their own. Or they could even all be aggregated into a discussion blog (Containing anything matching "*/Discussion").
• Permalinks are just links to the wiki pages that are combined to form the blog.
• You can refer to any other blog posts using wikilinks; the wiki will automatically add backlinks to pages that link to a post, too.
• Since I keep my blog in plain text .mdwn files alredy, I can migrate from pybloxm to ikiwiki using pretty much just an svn mv ...

ikwiki's TODO has the details (about half way down; that page needs to be implemented as a collection of pages/blog itself).

I love reading about the new packages in Debian Weekly News. It's one of the regular bits of it I always look forward to. This week, I was very pleased to read about rpmstrap being packaged. Finally, I can create a RedHat chroot to muck around in to test RPM building, without having to resort to running an entire RedHat box (or messing around with virtualising one).

Umm no. The krooger effect is that every time krooger appears MJ. Ray and some other people start defending jonathan/ted walther regardless of what loony things he has done in past. Somehow absolutely obvious things like "You get banned from women-targeted mailing list for sending sexists mails" get turned upside down into "poor krooger is a victim of religious discrimination".

[ 7 ] Choice 6: Jonathan aka Ted Walther
[ 6 ] Choice 8: None Of The Above

Make sure your ballot includes it. It's not religious discrimination, and it's not again universal human rights declarations vote that someone is just not fit as our DPL.

Even those who rank Ted Walther low should admit that he asked some of the trickiest questions in part III and mixed it up a bit.

"Mixing up issues" is about the last quality a DPL should have. His questions where not hard, but irrelevant. Most Debian Developers couldn't care less about arguing in the internet about Tax registrations or religious discrimination on IRC.

Martin: Strange... Here setting up a company is so much of a hassle that most people only register as Persona f sica con actividad empresarial instead - Physical person with enterprise activity. That means, you can print your invoices with "Madduck Consulting Inc." if you so wish, as long as under that, in tiny letters, you print your real name and fiscal data.