Ludoo

The Python Library is a continue source of amazement: I just discovered the very useful unicodedata module, which pairs the u'N{LETTER NAME}' escape sequence.

The N{} escape sequence works like this:

>>> u'N{LATIN SMALL LETTER M WITH DOT BELOW}'
u'u1e43'

The unicodedata module, among other things, allows you to lookup the unicode character associated with a name, which allows you to build mapping tables using character names:

>>> import unicodedata
>>> unicodedata.lookup('LATIN SMALL LETTER M WITH DOT BELOW')
u'u1e43'

The reverse of lookup() is name():

>>> unicodedata.name(unicodedata.lookup('LATIN SMALL LETTER M WITH DOT BELOW'))
'LATIN SMALL LETTER M WITH DOT BELOW'
>>>

If you want to check unicode names, a very useful site is the Letter Database at the Institute of the Estonian Language. An example is the search for LATIN SMALL LETTER S WITH DOT BELOW, which yields this page.

Yesterday I finally received a copy of the latest MadHatter beta available to clients, and installed it on my office desktop. Our Sun representatives warned me that there are bugs, many of which are already fixed in the latest betas which are only for Sun internal use.

As was to be expected, I found good things and bad things in MH, a few of which are undoubtedly due to SuSE 8.1, which is the distro around which MadHatter is built. Before proceeding to recount my first impressions, I have to say that I'm not so much excited in MadHatter (which at this point is little more than just another distro), as in the overall design of Sun's Unix Business Architecture. IMHO Sun is doing something very interesting, offering an attractive per-seat licensing scheme that grants you the rights to use most of Sun's server (messaging, directory services, etc.) and desktop (StarOffice, MadHatter) products.

When you throw in Sun Rays with Linux support (which should be available next year), Sun's offer looks like it has the potential to revolutionize Enterprise IT. The only glitch is that you're supposed to use ONLY Sun hardware, even if your server OS is Linux. I hope Sun realizes this is a huge mistake, as I don't see many companies willing to replace most of their expensive i386 servers with Sun i386 servers.

Back to MadHatter, or the Java Desktop System as everything from desktop icons to console graphics proclaim it to be. This is the thing that annoys me most about MadHatter. Not a bug or some missing feature (it's a beta of a Linux distribution after all, so I can live with those), but the feeling that it's just some sort of fancy packaging, or worse a not so clever marketing tactic. Things like this discredit the technical soundness and innovative potential of the Unix Business Architecture, and IMHO should be avoided at all cost.

Where's Java in MadHatter Desktop? A JRE is installed by default, but the same thing can be said for most modern Linux distributions. If you dig deep enough into the desktop menus you can find a link to Java Web Start, and a link to a Java application that displays disk usage. Not enough to call it the Java Desktop System. Wake up Sun, please don't try to rebrand Linux and Gnome.

On the technical side, there are a few things still out of place in MadHatter. A few of them expose a lack of coherence and vision in the overall architecture of MadHatter, others are the product of insufficient testing and can be expected in an early beta release.

First of all, MadHatter refuses to bring up my Intel EtherExpress Pro100. The desktop where I installed MadHatter has a prefectly working Slackware 9.1, which uses the same card without a problem. MadHatter sees the interface and brings it up, but can't use it either with dhcpcd or by assigning it a static IP. I tried swapping the e100 module with eepro100, but things did not change. What's worse, modprobe spits out errors about missing modules, which in fact are there and can be loaded fine with insmod. The problem is definitely kernel related, since when I tried booting MadHatter with the 2.4.22 kernel I compiled under Slackware, dhcpcd could assign a valid address to the interface and everything worked ok. While this may just seem a technical glitch due to the underlying SuSE 8.1 distro, I think it instead reveals a certain lack of planning in MadHatter: how can a distro come with the very latest stable Gnome release (2.4, released on September 10, 2003), and at the same time with an old stable kernel (2.4.19, released on August 3, 2002)? I think the MadHatter team has a bit overstated the desktop part of the equation, forgetting the importance that a latest stable kernel has for overall system stability, and support for new chipsets. The same goes for productivity languages like Python, which on MadHatter is stuck at the old 2.2.1 version. I suspect most of the other non-desktop programs and libraries to be slightly outdated too.

Another thing I did not like at all is MadHatter wiping out my Lilo MBR, without even acknowledging the presence of a second OS installed on my system. Editing Grub's menu is not a difficult task, but neither is recognizing other bootable partitions on installation.

The last (minor) annoyances I found in my first day of use of MadHatter are the Gnome clock set to GMT in spite of the system's timezone (which you can see in the picture above), and the default widgets theme messing up TTF fonts when using freetype compiled with the TTF bytecode interpreter turned on (here MadHatter's default theme, here the default Gnome theme on the same desktop).

What did I like in Madhatter then? Well, as I already said I like its role in UBA's architecture. As a day-to-day distro I like its polished look, which is not limited to Gnome's desktop but encompasses every part of the system with which the user can interact, including the console. I like it having StarOffice preinstalled (not that I use it much). I like its simple setup, with a limited set of options. I'm sure there will be more good stuff after having used it for a while, and after a few more betas.

update: I noticed from my logs that somebody requested a Google translation of this entry to Spanish so, being the ever curious type, I went to check it out. The best part is this one:

Nuestros representantes del sol me advirtieron que haya los insectos...

Which is a perfectly valid literal translation of Our Sun representatives warned me that there are bugs..., but takes a whole different meaning.

Many of you may already know about RFC1149 A Standard for the Transmission of IP Datagrams on Avian Carriers, which details CPIP (aka Carrier Pigeon Internet Protocol). For those who don't, the date when RFC1149 was issued should tell you something about its origins: April 1st 1990.

Tonight, while browsing new posts on alt.os.linux.slackware I stumbled upon a link to a site recounting the first (and only, I guess) implementation of CPIP.

The ping was started approximately at 12:15. We decided to do a 7 1/2 minute interval between the ping packets, that would leave a couple of packets unanswered, given ideal situations. Things didn't happen quite that way, though. It happened that the neighbour had a flock of pigeons flying. Our pigeons didn't want to go home at once, they wanted to fly with the other pigeons instead. And who can blame them, when the sun was finally shining after a couple of days?

Just what I needed for a good laugh after the second day of the advanced DB2 class I'm following this week (BTW DB2 is very interesting, if a bit archaic).

I have been trying for a while to get Mozilla Firebird to open .pls playlists with xmms. It turns out that you can get the helper applications back (along with a bunch of other options) by installing the Things They Left Out extension.

The latest Joel article is an explanation of Unicode and character encodings for programmers. As for many other things, the Python community has produced wonderful tools, libraries, and documentation on Unicode too.

• Unicode for Programmers, Jason Orendorff
• Unicode Support in Python (PDF), Marc-André Lemburg
• Dive Into Python, chp 6.4. Unicode, Mark Pilgrim

Little more than two days left for the Rugby World Cup 2003. My .icl calendar with the World Cup schedule in CET times is the 2nd most downloaded file from my site.

Italy will play on Saturday (at 6:30 am CET!) against NZ, not a soft start. Can't wait to see the big matches, and the teams we never get to see, like Fiji and Samoa.

This should give you an idea of the status of Rugby in some countries:

SUVA, Oct 7 (AFP) - Fiji's government introduced emergency electricity measures Tuesday, saying they would ensure the nation gets to see Rugby World Cup matches televised live.

[...]

Energy Minister Savenaca Draunidalo said the cabinet had provided emergency funding to the Fiji Electricity Authority to run diesel generators for a month.

A few minutes ago I saw the second mention in just a few days of the XML résumé library and I really don't understand the benefits of writing a CV (or any other document) in XML.

It may be that my tastes are retro, but LaTeX is still the better option for writing documentation. I tried using DocBook a while ago, but the drawbacks are too many:

• the text disappears under the XML tags
• XML catalogs are a pain, and they become almost necessary if you're behind a proxy
• you have to type too many characters for simple things, like creating a new paragraph
• PDF output is awful, and image support requires installing extra Java classes

You may argue that with XML you get validation, but you get the same thing with LaTeX error messages, plus excellent output of typesetting quality, and lots of packages covering every possible need, since LaTeX and TeX have been around for a long time.

To write a CV in LaTeX, you could use the currvita package by Axel Reichert, which usually comes preinstalled on reasonably modern LaTeX installations. Currvita has a cleaner syntax than the XML Résumé Library, produces a better output, and allows you to use other LaTeX packages like BibTEX. Compare for example a job entry in the XML Résumé Library format

<job>
  <jobtitle>Junior Bedpan Cleaner</jobtitle>
  <employer>Framingham Palace</employer>
  <period>
    <from>
      <date>
        <month>October</month>
        <year>1633</year>
      </date>
    </from>
    <to>
      <date>
        <month>October</month>
        <year>1634</year>
      </date>
    </to>
  </period>
  <description>
    <para>Analyzed bedpan cleanliness strategies for royal
      family.  Learned how to make soufflés.
    </para>
  </description>
</job>

to the same one using currvita

item[10/1633--10/1634] textbf{Junior Bedpan Cleaner},
Framingham Palace
Analyzed bedpan cleanliness strategies for royal family. Learned how to
make soufflés.

Can you see my point? And I don't believe you'd find an XML CV useful, because you can query it using XPath, or extract lists of employers, dates, and so on. Have you ever needed to do it? And how long would it take to do the same thing using regexps on the LaTeX file, or using a parser on an HTML file generated by the LaTeX source? It's a CV, not enterprise data.