I usually use this blog to post about stuff I have written or that is somehow related to my work / professional life. This time, however, I'll just use it to share with you a short text my father published in the column he writes in the La Uni n de Morelos newspaper, Academia de Ciencias de Morelos: La Ciencia, desde Morelos para el mundo. My father has lived for over 20 years in Cuernavaca, la Ciudad de la Eterna Primavera (the city of the eternal Springtime), ~80Km south of Mexico City. Cuernavaca was for long years known mostly as a weekend city for Mexico City's middle-upper class, but it has grown way beyond that. According to Wikipedia, in Cuernavaca's metropolitan area there are about 700,000 inhabitants. And the city is blatantly built with no planning, no urbanistic analysis of any kind. I have been familiar for many years with the program to put some rational order renumber Cuernavaca's streets. Roberto Tamariz, the sociologist who built my father's house (yes, in a stroke of genius he acted as an architect for a piece of land he had bought - the results are quite decent, given his real occupation, but his lack of architectural background tends to literally come up from the floor every now and then), was involved in a municipal project to renumber Cuernavaca's streets, probably some 15 years ago. Anyway, Roberto's work was never really finished due to the severe lackings of our political culture. In this (one-and-a-third pages long, quite easy to read) text I am attaching to this post, my father writes about Cuernavaca's strange street naming system, the mathematical solutions (and political intrincacies) about renumbering a two dimensional space (and, of course, he could not help but wander into the third- and fourth-dimentional spaces, although very briefly). I like how this guy writes, all in all. Enjoy!

Attachment	Size
Calles y numeros de Cuernavaca.pdf	231.99 KB

I visited Seoul last week to represent the Open Source Initiative (OSI) at an open source conference and to sign a Memorandum of Understanding (MOU) with the Korea Software Copyright Committee (SOCOP). SOCOP organized a conference with the title "Free Open Source Software License Insight Conference", and the international speakers included Brett Smith of the FSF, Brendan Scott of Open Source Law, Michael Cot of RedMonk and myself. From the questions we received, it seems that there is a lot of interest in legal questions related to open source. There were a number of folks from hardware companies that asked specific questions what they could do and couldn't do (e.g. related to including sources for GPL code and properly giving credit for BSD code). I think the conference was a great success. The talks were of high value and we got good questions. The audience was quite mixed, ranging from managers to developers. Even though they had simultaneous translation of the talks, the majority of the people listened in English... this gives me hope that some of these folks will end up becoming involved in the international open source community. SOCOP is working on a number of activities related to open source, including:

• An information portal called OLIS.
• The translation of all OSI approved licenses to Korean.
• The verification of open source code to identify which code uses which license.
• More promotional activities, including workshops and conferences.

The day after the conference, I went to the SOCOP office to sign the MOU between SOCOP and OSI with Mr Yung Bo Koo, the chairman of SOCOP. The MOU says that we'll share knowledge and expertise, help with promotional activities and support each other's activities in other ways. I was delighted to sign the MOU between SOCOP and OSI, and I look forward to a fruitful cooperation between our organizations in the future. It's great to see so much interest and so many activities around open source in the Republic of Korea.

I don't know what votes are in a bug tracking system, but it's almost enough to distract me from sharing my opinion about Seb Ruiz, whoever he is.

My SE Linux Play Machine [1] has a file named thanks.txt for users to send messages to me [2]. On a number of occasions people have offered to give me things in exchange for the password for the bofh account (the one with sysadm_r privileges). I ve been offered stolen credit cards, a ponzi scheme of root access to servers on the net, and various other stuff. Today I received an amusing joke entry: Hello Kind Sir, I am Dr. Adamu Salaam, the the bank manager of bank of africa (BOA) Burkina Faso West I am sending you this message about the $3.14159 million dollars in bank account number 2718281828450945. I will give you this money in exchange for the password to the bofh account. The amount of money is based on the value of Pi. The account number is based on the mathematical constant e [3]. It s a pity that the author of that one didn t sign their real name. Whoever created that should have claimed credit for their work.

• [1] http://www.coker.com.au/selinux/play.html


• [2] http://doc.coker.com.au/computers/thankstxt-on-my-play-machine/


• [3] http://en.wikipedia.org/wiki/E_(mathematical_constant)

So in three weeks time, two once large Unix vendors are gone SGI on april 1st, and now Sun. SGI as a Unix vendor had been dead for years anyway, but still.

Today's announcement also kind of finalizes the answer to my wonderings last year. Sun somehow seems to have managed to send off MySQL into limbo, and it remains yet to be seen if Oracle would have any imperative to bring it back.

One thing I do find bothersome with the new situation is that at the moment I write this, the opensolaris.org website appears to be unreachable. Which might just be coincidence, but I do hope that neither Sun until the deal is finished or Oracle afterwards turn away from their current opensource backing positions.

Somehow I managed to forget to blog about this for some time - version 2.1-1 of gimp-plugin-registry is available in testing since several days. For detailed changes please have a look in the changelog, for the impatient - here is the summary:

• New plugins: btn4ws, sprocket-hole, cmyk-tiff-2-pdf, dustcleaner (back again, was removed for stable as it was not mature enough)
• New upstream versions of the following plugins: lqr, DBP, diana-holga2, focusblur, GREYCstoration, LayerEffects (now using Python), normalmap, save-for-web, seperate+, wavelet-denoise
• Removed plugins: exposure-blend

As usual let me know if there's a nice plugin you'd like to see in the package.

When Kubuntu switched to KDE4 as it s main desktop, I was disheartened. KDE 4, at the time was just, well, pretty unusable for me. It kept crashing, I couldn t do the things that I wanted to, and I spent more time fighting with KDE than I did actually doing work. After about a week, I d had enough, and I switched to Gnome. Now, a lot of people are probably going to respond to this with Gnome vs KDE flames, but let me explain my viewpoint on the whole Desktop Environment war I prefer KDE, but if a desktop will let me do the work I need to do without getting in my way and causing issues, then I can learn to use it. The above is possibly the reason that I can get along ok with Windows XP, but if I have to use Vista, I ll end up wanting to throw the machine out of the window. So, for possibly the last year or so (I m not too sure on the timescale!) I ve been using Gnome in Ubuntu, and I must say, I ve liked it. the fact that I can login, and instantly get access to my servers without having to type in my SSH key password (yes, insecure I know!), and that everything seems to integrate in a nice way, well.. it s been fun. But still, my heart lies with KDE, and I ve been flipping back to it to see how KDE4 is coming along on a regular basis. So far, I ve seen it gradually improving, and well, it looks damned sexy to be honest, but there were a few things that I felt it was missing. The ability to have multiple rows of apps on the task switcher was a big one for me. I generally have a lot of windows open, and I don t like the Grouping functionality. So when I get more than a few apps open, I could only see the icons. That s been fixed in KDE4.2, and it does it in a nicer way than Gnome does it (only switching to two rows once there are a certain amount of windows open. Next on the list is the whole password management thing. Gnome does a GREAT job at this. I login, and it unlocks the default keyring, sets up the SSH agent, adds my key, unlocking it from the keyring, and I don t have to do anything but login with my normal user and password (though I intend to switch that to biometric login once I can be bothered to setup the fingerprint reader). I ve fixed that little issue (well, for SSH) by setting up an autostart script using ksshaskpass to add my SSH key when I login. So far, KDE seems pretty usable for me now, but then, I m quite happy to plod along on my Laptop and try things out. I m feeling a bit lost with all the new functionality, and wishing that the Ubuntu Gnome Notifications (from pidgin, which I use as my IM client) didn t look so ugly in the new sexy KDE Desktop (in fact, if anyone knows a way to get pidgin to use the Jaunty style notifications in KDE, let me know, as they d fit in quite well under the new KDE look :D) - I d like to see some sort of common ground for notifications across the desktops, but who knows when that s going to happen! I ll also try using it at work, if I can use it there without it getting in the way, then I will happily switch back permanently, but that s the ultimate test. I m pretty sure that KDE 4 will be usable for me soon, and I ll let you know if that s now

xmodmap has long been the only way to modify the keyboard map of the X server, short of the complex configuration daemon approaches used by the large desktop managers, like KDE and GNOME. But it has always been a hack: it modifies the X keyboard map and thus requires a baseline to work from, kind of like a patch needs the correct context to be applicable. Worse yet, xmodmap weirdness required me to invoke it twice to get the effect I wanted. When the recent upgrade to X.org 7.4 broke larger parts of my elaborate xmodmap configuration, I took the time to finally ditch xmodmap and implement my modifications as proper xkb configuration.

Background information I had tried before to use per-user xkb configuration, but could not find the answers I want. It was somewhat by chance that I found Doug Palmer s Unreliable Guide to XKB configuration at the same time that Julien Cristau and Matthew W. S. Bell provided me the necessary hints on the #xorg/irc.freenode.org IRC channel to get me started. The other resource worth mentioning is Ivan Pascal s collection of XKB documents, which were instrumental in my gaining an understanding of xkb. And just as I am writing this document, Debian s X Strike Force have published their Input Hotplug Guide, which is a nice complement to this very document you are reading right now, since it focuses on auto-configuration of xkb with HAL. The default xkb configuration comes with a lot of flexibility, and often you don t need anything else. But when you do, then this is how to do it:

Installing a new keyboard map The most basic way to install a new keyboard map is using xkbcomp, which can also be used to dump the currently installed map into a file. So, to get a bit of an idea of what we ll be dealing with, please run the following commands:

xkbcomp $DISPLAY xkb.dump
editor xkb.dump
xkbcomp xkb.dump $DISPLAY

The file is complex and large, and it completely went against my aesthetics to simply edit it to have xkb work according to my needs. I sought a way in which I could use as much as possible of the default configuration, and only place self-contained additional snippets in place to do the things I wanted done differently. setxkbmap and rule files Thus began my voyage into the domain of rule files. But before we dive into those, let s take a look at setxkbmap. Despite the trivial invocation of e.g. setxkbmap us to install a standard US-American keyboard map, the command also takes arguments. More specifically, it allows you to specify the following high-level parameters, which determine the sequence of events between key press and an application receiving a KeyPress event:

• Model: the keyboard model, which defines which keys are where
• Layout: the keyboard layout, which defines what the keys actually are
• Variant: slight variantions in the layout
• Options: configurable aspects of keyboard features and possibilities

Thus, with the following command line, I would select a US layout with international (dead) keys for my Thinkpad keyboard, and switch to an alternate symbol group with the windows keys (more on that later):

setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch

In many cases, between all combinations of the aforementioned parameters, this is all you ever need. But I wanted more. If you append -print to the above command, it will print the keymap it would install, rather than installing it:

% setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch -print
xkb_keymap  
  xkb_keycodes    include "evdev+aliases(qwerty)"        ;
  xkb_types       include "complete"     ;
  xkb_compat      include "complete"     ;
  xkb_symbols     include "pc+us(intl)+inet(evdev)+group(win_switch)"    ;
  xkb_geometry    include "thinkpad(us)"         ;
 ;

There are two things to note:

1. The -option grp:win_switch argument has been turned into an additional include group(win_switch) on the xkb_symbols line, just like the model, layout, and variant are responsible for other aspects in the output.
2. The output seems related to what xkbcomp dumped into the xkb.dump file we created earlier. Upon closer inspection, it turns out that the dump file is simply a pre-processed version of the keyboard map, with include instructions exploded.

At this point, it became clear to me that this was the correct way forward, and I started to investigate those points in order. The translation from parameters to an xkb_keymap stanza by setxkbmap is actually governed by a rule file. A rule is nothing more than a set of criteria, and what setxkbmap should do in case they all match. On a Debian system, you can find this file in /usr/share/X11/xkb/rules/evdev, and /usr/share/X11/xkb/rules/evdev.lst is a listing of all available parameter values. The xkb_symbols include line in the above xkb_keymap output is the result of the following rules in the first file, which setxkbmap had matched (from top to bottom) and processed:

! model         layout              =       symbols
  [...]
  *             *                   =       pc+%l(%v)
! model                             =       symbols
  *                                 =       +inet(evdev)
! option                            =       symbols
  [...]
  grp:win_switch                    =       +group(win_switch)

It should now not be hard to deduce the xkb_symbols include line quoted above, starting from the setxkbmap command line. I ll reproduce both for you for convenience:

setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch
xkb_symbols     include "pc+us(intl)+inet(evdev)+group(win_switch)"    ;

A short note about the syntax here: group(win_switch) in the symbols column simply references the xkb_symbols stanza named win_switch in the symbols file group (/usr/share/X11/xkb/symbols/group). Thus, the rules file maps parameters to sets of snippets to include, and the output of setxkbmap applies those rules to create the xkb_keymap output, to be processed by xkbcomp (which setxkbmap invokes implicitly, unless the -print argument was given on invocation). It seems that for a criteria (option, model, layout, ) to be honoured, it has to appear in the corresponding listing file, evdev.lst in this case. There is also evdev.xml, but I couldn t figure out its role.

Attaching symbols to keys I ended up creating a symbols file of reasonable size, which I won t discuss here. Instead, let s solve the following two tasks for the purpose of this document:

1. Make the Win-Hyphen key combination generate an en dash ( ), and Win-Shift-Hyphen an em dash ( ).
2. Let the Caps Lock key generate Mod4, which can be used e.g. to control the window manager.

To approach these two tasks, let s create a symbols file in ~/.xkb/symbols/xkbtest and add two stanzas to it:

partial alphanumeric_keys
xkb_symbols "dashes"  
  key <AE11>  
    symbols[Group2] = [ endash, emdash ]
   ;
 ;
partial modifier_keys
xkb_symbols "caps_mod4"  
  replace key <CAPS>  
    [ VoidSymbol, VoidSymbol ]
   ;
  modifier_map Mod4   <CAPS>  ;
 ;

Now let me explain these in turn:

1. We used the option grp:win_switch earlier, which told xkb that we would like to use the windows keys to switch to group 2. In the custom symbols file, we now simply define the symbols to be generated for each key, when the second group has been selected. Key <AE11> is the hyphen key. To find out the names of all the other keys on your keyboard, you can use the following command:

   xkbprint -label name $DISPLAY -   gv -orientation=seascape -
   
   

   I had to declare the stanza partial because it is not a complete keyboard map, but can only be used to augment/modify other maps. I also declared it alphanumeric_keys to tell xkb that I would be modifying alphanumeric keys inside it. If I also wanted to change modifier keys, I would also specify modifier_keys. The rest should be straight-forward. You can get the names of available symbols from keysymdef.h (/usr/include/X11/keysymdef.h on a Debian system, package x11proto-core-dev), stripping the XK_ prefix.
2. The second stanza replaces the Caps Lock key definition and prevents it from generating symbols (VoidSymbol). The important aspect of the second stanza is the modifier_map instruction, which causes the key to generate the Mod4 modifier event, which I can later use to bind key combinations for my window manager (awesome).

The easiest way to verify those changes is to put the setxkbmap -print output of the keyboard map you would like to use as a baseline into ~/.xkb/keymap/xkbtest, and append snippets to be included to the xkb_symbols line, e.g.:

"pc+us(intl)+inet(evdev)+group(win_switch)+xkbtest(dashes)+xkbtest(caps_mod4)"

When you try to load this keyboard map with xkbcomp, it will fail because it cannot find the xkbtest symbol definition file. You have to let the tool know where to look, by appending a path to its search list (note the use of $HOME instead of ~, which the shell would not expand):

xkbcomp -I$HOME/.xkb ~/.xkb/keymap/xkbtest $DISPLAY

You can use xev to verify the results, or just type Win-Hyphen into a terminal; does it produce ? By the way, I found xev much more useful for such purposes when invoked as follows (thanks to Penny for the idea):

xev   sed -ne '/^KeyPress/,/^$/p'

Unfortunately, xev does not give any indication of which modifier symbols are generated. I have found no other way to verify the outcome, other than to tell my window manager to do something in response to e.g. Mod4-Enter, reloaded it, and then tried it out.

Rules again, and why I did not use them in the end Once I got this far, I proceeded to add option-to-symbol-snippet mappings to the rules file, and added each option to the listing file too. A few bugs [[!debbugs 524512 desc=later]], I finally had setxkbmap spit out the right xkb_keymap and could install the new keyboard map with xkbcomp, like so:

setxkbmap -I$HOME/.xkb [...] -print   xkbcomp -I$HOME/xkb - :0

I wrote a small script to automatically do that at the start of the X session and could have gone to play outside, if it hadn t been for the itch I felt due to the entire rule file stored in my configuration. I certainly did not like that, but I could also not find a way to extend a rule file with additional rules. When I looked at the aforementioned script again, it suddenly became obvious that I was going a far longer path than I had to. Even though the rule system is powerful and allows me to e.g. automatically include symbol maps to remap keys on my Thinkpad, based on the keyboard model I configured, the benefit (if any) did not justify the additional complexity. In the end, I simplified the script that loads the keyboard map, and defined a default xkb_keymap, as well as one for the Thinkpad, wich I identify by its fully-qualified hostname. If a specific file is available for a given host, it is used. Otherwise, the script uses the default.

And while I'm on the subject of bitching about hardware support, I had some time to poke at the Qualcomm Gobi hardware a bit more last week. With the aid of Dan Williams of Network Manager fame we identified[1] that the hardware actually does rather more than is obvious from the qcserial driver. There's two extra ports - one is for diagnostics, and the other claims to be an NMEA port. Poking support for these into qcserial is easy enough, but they don't seem especially chatty. The more interesting factor is that the fourth interface on the endpoint is a network device. This isn't unusual in modern hardware - PPP isn't a terribly helpful layering for data transfer, so most recent high speed data cards also provide support for some kind of network device. If you're lucky it's a spec-compliant cdc device. If you've got a gobi then it claims to be a vendor defined class and type and the .inf file for the driver claims that it's a proprietary cdc device. Testing this got cut short by us not actually having an account on Verizon[2], so we don't have any data dumps to work out what the framing looks like.

Interestingly, doing USB dumps revealed that Windows seemed to do everything via the network device. We didn't see any traffic from the other ports, even when attempting to turn on the GPS. So it may also have some magic out of band configuration that doesn't simply use AT commands.

If anyone has this stuff working under Windows, it'd be interesting to try getting some dumps to try to work out what's going on here.

[1] By the simple process of opening the device manager under Windows. Ahem.

[2] The test machine was a Vaio P, which came with a gobi but no SIM slot. Thanks, Sony. Thony.

Drivel 2.0.4 ("Alive again")
============================

* Improvements:
- Add current patches from Debian and Ubuntu
- Add patches from bugzilla that have accumulated since 2.0.3
- New member of upstream team: Neil Williams
- Add tag support for LiveJournal. Closes #307967

* Translation updates:
- Added Italian translation (Vincenzo Campanella)
- Updated Germann translation (Mario Bl ttermann)
- Updated Portuguese translation. (Am rico Monteiro)
- Updated Canadian English translation. (Adam Weinberger)
- Updated Nepali translation. (Basanta shrestha)
- Updated Portuguese translation. (Miguel Figueiredo)
- Updated Russian translation. (Yuri Kozlov)

Drivel 2.0.4-1 has also arrived in Debian unstable - Ubuntu will update in due course but there's an Ubuntu release to get out before then (I assume).

http://incoming.debian.org/drivel_2.0.4-1_amd64.changes

Description:
drivel - Blogging client for the GNOME desktop
Closes: 465805 521452 521903 522335 522661 523425
Changes:
drivel (2.0.4-1) unstable; urgency=low
.
* New upstream release.
* [INTL:ru] Russian program translation update (Closes: #521452)
* [INTL:pt] Updated Portuguese translation (Closes: #521903)
* Update Standards Version (no changes)
* Drop previous patches and dpatch support, patches implemented
upstream.
* Switch to libcurl4-gnutls-dev instead of libcurl4-openssl-dev
to avoid linked against OpenSSL (Closes: #522335)
* Add LiveJournal tags support (Closes: #465805)
* [INTL:ru] Russian program translation update - added string
(Closes: #522661)
* [INTL:it] New Italian translation (Closes: #523425)
* Add gnome-doc-utils to build-depends

So I wanted to see what web browsers are available in Debian. The first stop was http://packages.debian.org/. Going to the page of one browser package and clicking on "Browser" in the tags area only gives you the explanation of the tag, but not the list of other packages with that tag. Is that available somewhere?

So next try maybe grep-dctrl ... oh, grep-debtags appears to be the ticket.

$ grep-debtags -n -sPackage web::browser
arora
browser-history
caudium-dev
caudium-modules
caudium-perl
caudium-pixsl
caudium-ultralog
chimera2
conkeror
cookietool
dhelp
edbrowse
elinks
elinks-lite
elvis
elvis-console
epiphany-browser
epiphany-browser-dev
epiphany-extensions
epiphany-gecko
ezmlm-browse
galeon
galeon-common
gtkcookie
iceweasel
jsmath
junior-internet
kazehakase
konq-plugins
links
links2
lynx
lynx-cur
lynx-cur-wrapper
mozilla-firefox-adblock
mozilla-noscript
netrik
netsurf
saods9
stripclub
sugar-web-activity
surfraw
w3m
w3m-el
w3m-img
wapua
claws-mail-dillo-viewer
dillo
konqueror
midori

How many of those are actually web browsers? Probably about half of them. (Example: caudium (not listed) is a web server, caudium-dev is its development package, not very close to a web browser.)

This would actually be quite a useful interface if the tags had any relationship to reality. I was in fact looking for a lightweight graphical browser, so this is a plausible command:

$ grep-debtags -n -d -sPackage web::browser -a interface::x11 -a -! suite::gnome -a -! suite::kde

which gives me 15 hits, of which 8 or 9 are actual web browsers.

Well, my search for a lightweight browser stopped here:

iceweasel
lightweight web browser based on Mozilla

Yeah! ;-)

There are a lot of little git scripts and tools being written by a lot of people. Including a lot of tools written by people I have a lot of respect for. And yet, they are mostly useless for me. Take git-pkg. Can t use it. Does not work with git submodules. Then there is our nice, new, shiny, incredibly bodacious 3.0 (git) source format. Again, useless: does not cater to submodules. I like submodules. They are nice. They allow for projects to take upstream sources, add Debian packaging instructions, and put them into git. They allow you to stitch together disparate projects, with different authors, and different release schedules and goals, into a coherent, integrated, software project. Yes, I use git submodules for my Debian packaging. I think it is conceptually and practically the correct solution. Why submodules? Well, one of the first things I discovered was that most of the packaging for my packages was very similar but not identical. Unfortunately, the previous incarnation of my packages with a monolithic rules file in each ./debian/ directory, it was easy for the rules files in packages to get out of sync and there was no easy way to merge changes in the common portions an any sane automated fashion. The ./debian/ directories for all my packages package that they are instrumental in packaging. So, since I make the ./debian/ directories branches of the same project, it is far easier to package a new package, or to roll out a new feature when policy changes the same commit can be applied across all the branches, and thus all my source packages, easily. With a separate debian-dir project, I can separate the management of the packaging rules from the package code itself. Also, I have abstracted out the really common bits across all my packages into a ./debian.common directory, which is yet another project, and included in as a submodule in all the packages so there is a central place to change the common bits, without having to duplicate my efforts 30-odd times. Now people are complaining since they have no idea how to clone my package repositories, since apparently no one actually pays attention to a file called .gitmodules, and even when they do, they, and the tools they use, have no clue what to do with it. I am tired of sending emails with one off-cluebats, and I am building my own porcelain around something I hope to present as a generic vcs-pkg implementation soon. The firs step is a wrapper around git-clone, that understands git submodules. So, here is the browsable code (there is a link in there to the downloadable sources too). Complete with a built in man page. Takes the same arguments as git-clone, but with fewer options. Have fun.

Over the Easter holidays, I finally did a bit of real programming again, adding some quantum chemistry related C++ code to OpenBabel and Avogadro. I added support for molecular vibrations to the NWChem and Molden file formats, as well as writing support for the MOLPRO input and output formats mostly from scratch. The latter was something I wanted to do for a long time, as I have been almost exclusively using MOLPRO for my Ph.D. over the last couple of years. The event which sparked my interest was the addition of animated vibrations in the Avogadro 0.9.3 release on April 1st, something I considered one of the last missing features in Avogadro in order for it to be useful as a general purpose quantum chemistry visualization app. Once I had started coding, I decided to also do contribute to the visualization of molecular orbitals in Avogadro. So far, it was required to have formatted Gaussian or Q-Chem checkpoint files (both seem to use the same format, but you do not usually have those around) or Mopac2000 logfiles (Mopac2000 is non-free, unlike Mopac7, which is in Debian). My patch adds support for reading orbitals from MOLPRO logfiles on top of that. It has to be said that rendering molecular orbitals (while a bit unintuitive from a GUI perspective) is really impressive in Avogadro, thanks to the work done by Marcus Hanwell. See for exampe this picture for a Povray rendered molecular orbital exported by Avogadro. If I manage to find some more time, I would like to (i) move the basis set and molecular orbital parsing code to OpenBabel, where it rightfully belongs and (ii) enhance and unify the OpenBabel quantum chemistry input file export code, so that they can be used by Avogadro directly. Right now, Avogadro reimplements a GUI and code for exporting an input file for each supported quantum chemistry package (Gaussian, Q-Chem, GAMESS and Mopac2000, currently).

SSH is really the Swiss Army pocket knife of sysadmin tools. When I needed to periodically synchronize log files from an old server (old as in customer-would-never-update-it-or-install-anything-new), I built a simple and secure solution using rsync and ssh. This is what I did: (I will call remote the system where the logs I want to retrieve are, and local system where I want them to be copied to) First I created an account with a restricted shell (ideally this should be a system account, but we ll get there!):

remote# adduser --ingroup nogroup --shell /bin/rbash rlogs

Then locally, I created a new, password-less ssh key pair, copying it to my remote system:

local$ ssh-keygen
>>> When asked where to save it, I chose a different name, like .ssh/rlogs
local$ ssh-copy-id -i .ssh/rlogs.pub rlogs@remote
...
>>> You can delete the password of user rlogs, so it, effectively,
>>> cannot log-in with it (almost like a system user).
remote# passwd -d rlogs

Now you should be able to run password-less rsync already (note that I use -e option to point to a different key):

local$ mkdir logs
local$ rsync -av -e "ssh -i $HOME/.ssh/rlogs" rlogs@remote:"logs/" logs/
receiving file list ... done
./
file1
file2
...
fileN

But even with a restricted shell, I wanted even less possible things to happen. That s what command= directive is for It will only allow that command to be run in a session started by that key. Since rsync translates a lot of its command-line options, I run it again with a dirty ps-in-a-loop in the remote host, just to see what running rsync locally causes remotely:

remote$ while 1; do ps wp $(pgrep rsync); sleep 1; done
...
local$ rsync -av -e "ssh -i $HOME/.ssh/rlogs" rlogs@remote:"logs/" logs/
>>> in the remote loop you should be able to get the command:
  PID TTY      STAT   TIME COMMAND
 6183 ?        Ss     0:00 /usr/bin/rsync --server --sender -vlogDtpre.i . logs/

Here comes the authorized_keys magic. At the remote host I edited .ssh/authorized_keys to add a command= line with what I found out in my dirty loop. Also, I added a couple of directives to restrict it even further (they are pretty self-explanatory):

rlogs@remote$ cat .ssh/authorized_keys
command="rsync --server --sender -vlogDtpre.i . logs/",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa (...) myuser@local

Now everything is set. I just added the rsync command to the local crontab and it s done.

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm-crystalhttp://www.fvwm-crystal... as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm crystal as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

django-dumpslow is a reusable Django application that logs requests that take a long time to execute and provides an tool to summarise the resulting data. Modelled on mysqldumpslow, django-dumpslow is intended as a tool to determine which parts of a project might benefit most from optimisation and to provide valuable empirical data. The tool groups requests that are similar by exploiting Django's ability to reverse URLs - requests that use the same view are not counted distinctly. Views can then be grouped by the total accumulated time spent by that view or simply by their raw frequency in the logs. An example output is:

$ ./manage.py dumpslow
View                                         Accumulated time
=============================================================
example.views.slow                                     92.88
/unknown (unreversible url)                            16.84

If the log entries contain timestamps then django-dumpslow can optionally limit queries by a user-defined interval. This can be useful for generating regular reports of slow pages, perhaps by regularly emailing the "top 10 worst pages" to a development mailing list. Source, tarballs, etc. Patches welcome.

Last night, I stayed up late reworking the avionics bay in my Giant Leap Vertical Assault kit. This is the rocket I set my personal best altitude to date of 14,141 feet above ground level with. The Missile Works RRC2 mini will move to a lesser airframe to keep it below 10k feet AGL since it's an early unit with the supposedly-buggy early firmware. In its place, I've mounted a PerfectFlite MiniAlt/WD to handle primary deployment duties... and serial number 1 of TeleMetrum! Meanwhile, Keith has completely rewritten the guts of the firmware in the last few days to eliminate FreeRTOS since it turns out to just be too heavy for our needs on this project. My board is now running a snapshot of his latest work, and in bench testing I've confirmed that it can do launch detect, log sensor data until the non-volatile memory chip is full, and dump the raw data over USB for analysis after a flight. Weather has been an issue in Colorado recently, but as soon as we get a decent launch day (maybe as early as this weekend?), I'm looking forward to flying this rocket on one or all of the Cesaroni I205, I540, and J285 currently in my box to get some initial flight data recorded. Keep your fingers crossed for me that the storm front headed towards us clears out by the weekend!

... finally I'm tiling too! Short story: I've just switched to xmonad as my window manager of choice within a Gnome desktop environment; I give some tips on how to achieve that quickly on a current Debian/unstable machine. /me and tiling window managers I switched to Gnome a long time ago. The benefit of that over good old window managers is enjoying an integrated environment and a workplace that you can find on other machines (e.g., the netbook you installed for your mother, the office desktop, the student lab machines, ...). Still, I've never been particularly happy about Gnome's default window manager: metacity. The feature I was missing the most is the ability to configure windows programmatically so that they appear where and how I want by default; sadly enough, the Gnome session mechanism is not yet able to do that properly. Hence, I've tried various time switching to a tiling window manager, imposing the extra requirement that it should integrate with Gnome. The coolest guy on the block of that area seems to be awesome and I gave it a try some months ago. I liked most of its (sometime revolutionary) principles, like window tagging, but I equally hated various aspects of it:

• Documentation back then was horrible, starting from the manpage speaking of mod 1,2,3,4,5 without giving a hint about where the heck they are mapped to by default, ranging to the lack of references manual about what you can call from LUA configuration files. ... use the source, Luke ...
• Community was mainly composed by super-users, which is good if you want to do some super-configuration. ... but is deeply bad if you are trying to get hints on how to make awesome cope with Gnome. I remember having been treated as a total luser on IRC, with people more interested in convincing me that I should stop using Gnome than in helping out achieving what I wanted to.

People nowadays tell me that awesome works fine with Gnome, so maybe I've just been unlucky back then, but sometime the first impression does count. I've never considered seriously xmonad, thinking (with no sound reason, apparently) that it was a project of the series: "I'm a fan of programming language $LANG, all my apps should be written in $LANG, my window manager is no exception", with LANG=haskell. Then two things happened:

1. a couple of weeks ago I stumbled upon the xmonad wiki and documentation, and I was impressed by the average quality of the information shipped there. It is not something you usually find in "language showcase" projects.
2. Patrick blogged about its switch to xmonad + Gnome, with enthusiastic feedback. If that's not a sign I don't know what it can be

Getting started with xmonad + Gnome on Debian There is a page explaining how to use xmonad with Gnome in the xmonad wiki, but a handful of additional tips will help you get started in Debian, even if you know (almost) nothing about Haskell (yet).

• You should install packages xmonad and libghc6-xmonad-dev. Without the latter you will not be able to configure your xmonad; in particular you will not have access to the Gnome configuration library, which offers sane defaults for using xmonad with Gnome. (See below for a rant on the disk usage of installing the second package ...)

The (crazy) way in which xmonad works is that you create your config file as ~/.xmonad/xmonad.hs. That file is a full fledged Haskell program, which gets compiled to obtain your own xmonad executable which you run as your own window manager. /usr/bin/xmonad is the executable you initially run, but is just a wrapper around the compilation + run mechanism

• Since you have installed libghc6-xmonad-dev, you have access to a module pre-configuring xmonad for Gnome, just use the following as your starting xmonad.hs:

  import XMonad
  import XMonad.Config.Gnome
  main = xmonad $ gnomeConfig  
           modMask = mod4Mask
          
  
  

The modMask setting means that ALT will get delivered to applications, while all xmonad commands are delivered via the infamous windows key: no more conflicts between apps and WM \o/.

• At this point you can configure xmonad as your Gnome window manager. Disable re-spawning of metacity in your session option, and run somewhere killall metacity ; xmonad & . For the next session runs you will have to remember the running xmonad in your Gnome session, as usual.

The default Gnome configuration is quite nice: you can retain your Nautilus desktop (in spite of what is written on the wiki), mod-p will get you a gnome-run dialog box, and appropriate padding for the (upper!) Gnome panel. The only glitch is that you will get 9 desktops which can clutter your workspace switched. My solution is to have the appler show workspaces on 2 rows but beware of bug 524065, which is really annoying.

• Compositing works as well, by the means of xcompmgr. Just install it and register in your session the result of running xcompmgr -c &. No wonder that it is way faster than compositing manager support in metacity.
• Finally, you can configure window placement in your xmonad.hs by doing something like the following (it already includes the shorter snippet given before):

  import XMonad
  import XMonad.Config.Gnome
  myManageHook = composeAll [
                  (className =? "Pidgin" <&&> title =? "Buddy List") --> doFloat
                 , (className =? "Gnome-panel" <&&> title =? "Run Application") --> doFloat
                 -- , (className =? "XEyes") --> doShift "7"
                 ]
  main = xmonad $ gnomeConfig  
           modMask = mod4Mask
         , manageHook = myManageHook <+> manageHook gnomeConfig
          
  
  

The above example will make the pidgin buddy list and run application dialog box float by default. The commented line is an example of how to deliver specific windows to arbitrary workspaces. To find out window properties on which match in your xmonad.hs, my magic command is xprop egrep "CLASS NAME". Note that you don't need to care about panel placement because it is already taken care of by the default gnome config. Still beware of not using myManageHook as your only management hook, you should update the default one using the <+> monad as I did above. xmonad rant So, what's wrong with xmonad + Gnome in Debian? Well, the fact that it will take about 200 Mb of disk space on amd64 by default. o_O Why so? Because xmonad is affected by the static linking hell which seems to be shared by modern statically typed functional languages, including in the category both Haskell and my beloved OCaml. In short, applications written for those language link statically code written in the implementation language in most cases; they rely on legacy shared libraries only for bindings to C libraries. For xmonad that means that if you are fine with the default configuration you will get a cheap 2 Mb binary package. If you are not, you will need to write your conffile ... which is a Haskell program ... using several contrib libraries ... and needing ghc6 to be compiled and run as your own window manager executable. This is plainly dumb and induces all the usual problems of static linking, like disk consumption due to non-shared (Haskell) code, and worries about staying up to date with the latest library release in case of fixes (including security fixes) need to be propagated to user executables. Truth to be said, /usr/bin/xmonad does a wonderful job in hiding all this to the final user, but still the design choice is an unpleasant one.