During this past weekend I tried to get Windows XP, Windows 7, OSX, Debian, and Ubuntu all on one machine. Due to some mishaps, driver oddities with Windows 7, and other things, I had to install certain operating systems multiple times. Now, the problem is, each operating system has it's own peculiar way of loading. Linux uses GRUB, Windows XP has NTLDR, 7 has the Windows Boot Manager, etc. Most of these operating systems also decide it would be helpful for the end-user that when his computer reboots, it can actually load the new OS. That's great, but I already have a bootloader.

I have a partition at /dev/sda5 which contains a GRUB installation. That's supposed to handle every OS's own method of booting, including the Linux installations which have their own GRUBs on their own partitions. But when you decide to overwrite the MBR, I don't get your nice and shiny OS. A good number of OSes use an MBR that won't boot an extended partition anyway. So instead of seeing your bright and shiny new OS, I see "NTLDR is missing". Or the ever-so-helpful "boot0: error". I'm -lucky- if I even get an OS at all, much less one that can load the grub shell so I can fix what you broke.

I understand having 3 GRUB installations plus a whole bunch of other bootloaders isn't exactly a standard use case. Most people don't go beyond dual-boot. But please, for the love of all that is holy, please just put a little checkmark somewhere,"Do not replace MBR". Ubuntu and Debian are the only OSes that actually give you that option in some form.

Or better yet, let's all just standardize on GRUB. Sure, it's not perfect, but it's as flexible as you can get.

An old friend is ranting about localization. I first considered not really reaction to Joey's post, mostly because he has very true points...and particularly when he has about the same reaction than mine about a recent post in ou mailing lists. So, I will stick to react to one part of Joey's post...the one I consider really inaccurate. "everyone uses the software in English anyway" Really, Joey, really, that's completely untrue. Of course, I do live in a country that very well known (or at least that has the reputation) for being deeply ignorant in English language. But, really....*all* computers I see around me, both in my personal life *and in my professionnal life* are nearly completely localized. It's probably now well know that I spend most of my professionnal time....providing desktop systems (or managing the people who provide them) to users in ONERA, "the French Aerospace Lab". That means about 2000 users in a scientific environment where the use of English is much more developed than the average environment. Most of these users speak a fairly decent English and are perfectly able to understand that language in some way. About 80% of these systems are Windows-based and 20% are Linux-based. Probably more than 95% of them are localized in French. Even on Windows systems, we mostly integrate free software. And for *each* of them, the most important feature we need, besides software being free, is it to be localized in French. I bet our friends from Extremadura can say the same. The success of Linux-based free systems there also happened because the software is available in Spanish. And, of course, there are tons of similar stories and counter-examples (M nchen, Bhutan, Venezuela, etc.). So, really, please don't spread out that idea. Oh, yes, geeks *do* use their software in English (and, even here, I need to be convinced if I remember well what I saw at conferences in Germany or Spain, for instance). And, yes, it's very well widespread among geeks that using software in English is "better" or "easier". Which I indeed always fight and will fight until I die..:-). We certainly agree that these l10n needs put a high load on development and sometimes slow it down. and, for sure, we sometimes need to make a balance and I really thank you for giving me the credit to try doing that balance. Anyway, all this (including your rant) had to be said and it's interesting to have that small discussion (I just should not start writing down a blog entry at 23:00...:-)) See you soon, hopefully, Joey !

In this post I will say some things about localization that I've never felt it was politic to say before. (It still isn't, but what the hey.) But I first want to mention that one of the reasons Christian Perrier is awesome is because he manages to steer projects in ways that avoid (most of) the problems below, and because he has managed to scale rather impressively far. But not far enough that these things haven't gotten under my skin. So, I hate localization. Hate, hate, hate. I wish it would die. I wish everyone spoke the same language. I hate that we have to be politically correct about it, to the point that even if everyone does speak English (hello, Denmark?), we still have to worry about localization into their native language. I especially hate that, after we waste time and resources doing that, everyone uses the software in English anyway (hello, most of Europe). I hate that the typical best effort localization of software is typically so incomplete that it's not actually usable by people who really do need the translation. Either because "best effort" == 80% translated, which is sometimes worse than 0%, or because the documentation doesn't get translated too. And that even with what we consider a complete translation, there are still all sorts of English bits that nobody would ever consider translating. Such as the names of commands, of command-line switches, of markup keywords and configuration files. I hate that translating software and documentation always involves bolting an enormous, nasty build system onto its side, and that the bulk of translations always greatly outweighs the size of the code. I hate that these systems constantly produce deltas that I have to avoid cluttering my commits with. I hate the expectation that every programmer somehow become an expert in internationalization, rather than letting them devote their time to something they're good at. But none of that is what really bothers me about localization. What really, really bothers me is that I often see the need to localize code inhibiting that code becoming better. Just two examples:

• Oh no, we worry, if we fix this a message, we will have to do 100 times more work to update the translations. Surely, then, anyone who wants to fix a bad message is an anglocentric who should be ignored.
• Rather than allow the computer to dynamically generate correct and expressive English on the fly, to actually talk to us, we have to reduce everything to gettextable static strings. The poster child for this disease is that it becomes easier to tack on "(s)" or reword entirely, than to deal with the cumulative complexity of plural forms in every language.

(PS, I also hate that we have to keep "l10n" and "i18n" straight, and that the words are so unwieldly in this f5g modern English that we represent them based on their length.)

Whilst working on update-manager I have been wondering whether I should use gettext for localizing debug output and error messages sent to stderr.
As for debug output itself I basically do not see the need for providing a localized version for each and every message sent to stderr, but as far as error messages are concerned I am uncertain. The point is that update-manager (apart from its experimental text interface) is usually not launched from a terminal at all and so most users won t even see these messages ever. Also, I believe that every developer s English skills are good enough so that he or she is able to understand simple messages.
Error messages however might be useful to all users when they experience a problem with the software, but localizing those could make handling bug reports a bit harder, possibly having to translate the error message back to English before being able to see what has gone wrong. So basically I am asking you: What do you think? Is it worth localizing these messages? What is your experience with localized or non-localized error and debug messages? I would be glad if I could get some input from you, either as a comment to this article, via email to debian(dot)sp(dot)or(dot)at or through the update-manager-devel mailing list.

As I promised to keep you updated on recent developments on update-manager I am writing this article. Just as a disclaimer: I am not going to write about any recent developments here, but would rather like to point at a piece of code I added to update-manager that could be useful in other applications too. Now, as the title suggests there are sphinx-aware Enums in update-manager. Enums are common constructs in other programming languages like C and allow simple creation of constants with, for example, ascending values (first constant has value 0, second has value 1 and so on). Python unfortunately does not include support for Enums itself, but I found it rather easy to write classes that emulate such a construct. Nothing is new about Enums in Python and there are probably quite a few different implementations out there, but I believe mine is different. The sphinx-aware part means that my implementation automagically updates the docstrings of the created instances and thus allows sphinx autodata method to include sensible information in generated API documentation. I could go on writing about and praising my method, but I believe a short example gives you a better idea how my implementation works and what I wanted to achieve with this. Have a look at this page, which is part of update-manager s new API documentation. You should see rather well-looking documentation of the UpdateManager.Backend.RELOAD_CACHE_STATUS NegativeEnum, the defined constants, their values and some additional information about each value now. Still, nothing too fancy, HTML documentation generated from docstrings. What makes this special is the code from which it was generated:

RELOAD_CACHE_STATUS = NegativeEnum(
  BEGIN = "Started reloading package cache",
  DONE = "Finished reloading package cache")

This not only gives us a RELOAD_CACHE_STATUS enum, along with the RELOAD_CACHE_STATUS.BEGIN and RELOAD_CACHE_STATUS.DONE, but also some documentation, included in RELOAD_CACHE_STATUS docstring, that can be used by sphinx. You can find the Enum code, which is rather short and should be quite easy to understand, here. I hope you find this code as useful as I do.

Wolfram Alpha was often hyped as the latest and greatest search engine.I wouldn't call it so. It's just a very minimalistic search frontend to a nice database with lots of numerical facts.Yes, it can give you the height of the eiffel tower (because that's a fact in its databases). It can even compute for you what Pi times the height of the eiffel tower is. But that is about as far as you can go in combining. In my tests, I wasn't able to compare the temperature in Munich with the temperature in Berlin (both of which WA will visualize you with a pretty graph, so these are facts in WA) - their query parser just doesn't get my question.The funniest reply so far however was to the question:

How many cars in Germany?

The answer of WA (which btw is copyrighted by WA):

No

Seriously, I doubt that there are no cars in Germany.At least it also offers an explanation why it comes to this conclusion:Cars is a town in south-western France (which as you might guess currently is not a part of Germany. :-) ) - so for WA, there are at least cars somewhere in Europe, but not in Germany!

Due to some things falling into place, I had an opportunity to attend the first two days of last week's Ubuntu Developer Summit in beautiful Barcelona. Somehow, I had never managed to attend a Debian conference either, so it was good to meet a few of the old Debian hands now moving Ubuntu along, as well as a few of the Ubuntu folks. I also gave a short presentation on R in Debian / Ubuntu and the plans for the upcoming Ubuntu release. More on that another time. All told, a well-organised conference in a nice setting -- two stone throws from the legendary Camp Nou. Unfortunately, I had to leave by Wednesday so I missed what was undoubtedly quite a scene in Barcelona following Barca's dismantling of Man U in this year's Champions League final.

According to The Registry, COBOL is now slightly over 50 years old. I wish I could say I never wrote a single line of COBOL, but I can't. In college, I was taught COBOL for three long years. Even though I've managed to purge most of that knowledge from my brain (good riddance), I still have nightmares about the horrible way in which one writes COBOL. I wish I could say COBOL is dying, but it isn't. People still write new COBOL today. I mean, seriously, there's a standard called 'COBOL 2002. 'Nuff said. I wish I could say COBOL isn't a problem, but it's the sole source of most of the Y2K issues way back when. Its features invite many of the kind of horribly wrong coding styles which cause bugs; Y2K is just one. I wish I could say COBOL code is pretty, but it isn't. Just to give one example: the first 7 characters of every line of code in each and every COBOL program are 0x20. That is, space. Nothing. Utterly useless. There is no reason for this in modern environments, yet it's still there. Note why I dislike significant whitespace. Another example is the fact that you can't just say 'foo = 1 + 1'. Instead, you have to say 'MOVE 1 TO FOO', and then add a second statement that says 'ADD 1 TO FOO'. I'll just use english if I want to write a novel, thank you. I wish I could say I didn't care about COBOL anymore, but for some weird reason, I do. And just in case you were confused: no, I do not have warm, fuzzy feelings for COBOL. If there was a button that would nuke all the COBOL code on the planet, would I push it? Probably not immediately. I'm sure it would take time for me to recover from the sheer joy of knowing that this button actually exists, before I'll be physically capable of keeping my hands steady for the amount of time required for me to actually be able to push it. COBOL is proof of either the absense of any deity, or the existence of the devil. Given the chance, no sane person, let alone a sane deity, would allow the creation of such an abomination. At least I don't have to deal with it anymore. That part is not going to change. Ever.

For everyone who is wondering why IPv6 is a good idea, there are now two new websites that explain the benefits and background of IPv6. For example Geert Coppens from AnimatedExplanations.com wrote me last week that their site offers several short instructional/educational movies. One of those movies covers IPv6:


What is IPv6? - Animated Explanations

He writes as well:

The movie was made available with as purpose to spread the adoption of IPv6. If this movie is also of interest to you, feel free to embed or forward.

So spread the word - and movie! ;-)

The other site is IPv6actnow.org, which is operated by the RIPE NCC and deals with all expects of IPv6: why is IPv6 necessary, what are the benefits or how to migrate? There FAQs, Forums and video testimonials. So, if you need some infos for your boss to argue about the introduction of IPv6 in your network, be sure to visit that site as well!

John, no need to be so alarmist, this is KDE, look at the options:

I've already had one enquiry, so I guess I'd better get writing. Despite the lawyers being really down on using this Consulate, I have to say that from my experience, it's been the easiest so far. Or I'm just getting used to the rigmarole. The one screw up was I didn't read the instructions thoroughly enough, and we rocked up to the Scotia Bank branch to deposit the visa application fee in their bank account, and I thought the fee was quoted in Canadian dollars. Turns out, it was quoted in US dollars. It wasn't the end of the world that we didn't have cash, they could sell us US dollars on a credit card, except the bank would only accept Visa card, not Mastercard. I haven't had to deal with such bullshit since the great Cabcharge/Visa card war in Australia in the late 90's. Moral of that story: read the instructions multiple times. Carry one of each flavour of credit card when traveling internationally, just in case. That minor transactional hiccup aside, everything went fine. The Consulate itself does all of the pre-interview shenanigans on one floor (the bulk of the waiting around, the fingerprinting and photographing) and then they shoot you up to another floor for the "interview". Annoyingly, they run you through the metal detectors again on the higher floor. The interview was basically "So you work for Google? How about the food?" and then he told us to come back the next day to pick up the passports. I think we were in and out in about three, three and a half hours. I have to say, the ability to collect the passports from the Consulate later is a real boon. When you're in a foreign country, the last thing you want to deal with is any glitches in the postal system, or trying to get mail delivered to a hotel. This alone makes me like the Vancouver Consulate the best. We went back at the 2:15pm allotted "passport pick up time", and they came down to the security checkpoint on the ground floor and you show your receipt and they give you your passports back. They tell you to step outside and check it, and come back if there's any problems, so I presume you can at least talk to a human at that point if there are any problems. This is my third E-3 visa. They did not ask to see any of my supporting paperwork showing ties with Australia or anything else that I had in my giant wad of paperwork, just the approved Labor Condition Application, which they kept and returned with the passport the next day.

There are great resources to help tune PostgresQL for performance, but say you've got a Postgres database which suddenly becomes very slow. How can you figure out what's going on?
General system stateA slow database server will typically be running out of:

• cpu,
• memory or
• disk.

So the first thing you should do is to get an overview of the system state using common UNIX tools such as:

• top (press c to see the full command line): look at CPU and memory usage
• iostat -x -m 5: look at i/o wait and service time

If you notice that memory is exhausted, you could play with the following postgresql.conf settings:

shared_buffers
work_mem
effective_cache_size

If you see a lot of I/O, then try adjusting these settings:

checkpoint_segments
autovacuum_naptime
wal_buffers

Finding slow queries
On the database side, start by determining whether:

• there is one large query holding up all of the resources or
• the number of queries is the main problem.
  

To do this, make sure that the following setting is turned on in your postgresql.conf:

stats_command_string = on

Then fire up psql dbname and look at the currently executing queries:

SELECT usename, current_query, query_start
FROM pg_stat_activity;

(You can also add the procid column to the query if you want to map a query to the process ID you see in top.)

If you can't get anything useful out of pg_stat_activity, you may want to enable slow query logging by adding this to your postgresql.conf:

log_min_duration_statement = 100

(All queries which take more than 100 ms to execute will be printed to the main Postgres log file.)
Examining a particular queryOnce you have identified a slow query, you can time it by running this command before executing the query manually:

\timing

To get an idea of where Postgres spends its time when executing that query, look at the query plan:

EXPLAIN your_query;

The numbers you see there are estimates. To run the query and get actual numbers, use this instead:

EXPLAIN ANALYZE your_query;

If you still can't figure out why a certain query takes so long, have a look at the ratio between live and dead rows in the relevant tables:

ANALYZE VERBOSE tablename;

Having too many dead rows is often a sign of insufficient vacuuming. You might want to turn autovacuum on if it isn't already, or to make it a bit more aggressive by tweaking these settings:

autovacuum_vacuum_scale_factor
autovacuum_analyze_scale_factor

Troubleshooting database performance is a bit of a black art, many thanks to Mark Kirkwood for sharing his Postgres wisdom with me.

If there's anything else you have successfully used to find the cause of your performance woes, please feel free to leave a comment.