So, we are still mostly able to keep our release each two weeks promise. For this release we have two big additions to the support side of the project: translations support, and gtk-doc support. The former is made of the usual makefile rules used by gettext-enabled projects with a rework to fit in the non-recursive build process of WebKitGTK+. The later is not as well integrated yet, so you have to go manually to WebKit/gtk/docs and type make, but not before editing WebKit/gtk/webkit/webkitprivate.cpp and adding a call to g_thread_init(NULL); to webkit_init(). You get the idea, we need help in polishing this one. As for code, Xan Lopez has been doing some serious work on accessibility support, using ATK. After the a11y hackfest he landed a number of patches moving forward in this direction. It looks like we will be able to meet the requirements for becoming blessed for use by GNOME. We also got a nice printing API, that allows applications to stop using the nasty hack that would send a print() call through javascript. They are also able to control/monitor the print process, or automate it, so that no print dialog is shown, if they wish. That s it, come join the party =D. Now, for 1.1.6, I m hoping Diego finishes the spelling check patch, and it would be awesome to have Jan s proper error reporting!

Do you listen to the radio? I don t, and there are multiple reasons for that: First and foremost, I don t like the music they play these days. Even though there are stations which will occasionally play a more eclectic tune, the Swiss government does not, to my knowledge, dictate any quota, like New Zealand actually requires stations to broadcast New Zealand music at least 20% of the time. The result is music made by producers, who stand pop icons with little clothing in front of microphones, instruct them to move their bodies in obscene ways, and coach them to croak songs someone else wrote en masse in some basement somewhere. All those songs sound alike. To ensure a constant supply of pop dolls, they hype television shows with titles such as Germany s seeks the next superstar , when most of Germany actually couldn t care less, and only those with vacuous brain capacity follow with excitement, because they wouldn t know what else to do. Second, I don t have the time or energy to listen to discussion rounds on the radio, especially not when topic are about society , which noone can define in the first place. Wittgenstein always had it right. The same goes for most commentaries. If I don t have anything to do, I prefer to listen to birds in the trees, rather than someone s polished opinion. The scariest aspect is that those people actually believe that they have something worthwhile to say, and so do their producers and the other staff, when in most cases, they don t. At least not worthwhile to people who have other things occupying their minds. I also don t like someone to make a pre-selection of news and squash that into 5-15 minute time slots, to be read out by dull-sounding speakers. I d rather skim over articles, and the Web ensures that I get the information I want much quicker than the radio stations can transmit them. And sports over the radio waves makes me come close to aural epileptic seizures. I am painting the sky black a bit. I am fully aware that there exist people with thought-provoking arguments, that some stations play interesting music I would otherwise never discover, and that the radio is a source of entertainment in the lives of thousands of other people who are less privileged than me. But when the Billag rang my doorbell today and wanted CHF 14,10 per month for posession of any device capable of turning radio waves into sound, including those radio waves broadcast over the Internet these days, I got a bit furious. In the past, they concentrated only on actual radio and TV receivers. When I moved into my previous flat in Zurich in 2002, they wanted money because my stereo had a tuner button. I refused to pay, opened the device, unsoldered the radio coil, and sent it to them with an angry letter of refusal; they let me off the hook. Since then, they changed the law in 2007 (but haven t actually updated the forms they force you to sign) to include audio players, cellular phones, and computers, which are all radio-capable. I d really prefer if they used their funds to revert that trend, or at least remove the loudspeakers from all mobile phones. But instead, this morning, I skid right into their claws. As I said before, the radio is also a social support system, and as such I have less of a problem to subsidise it. However, given that I strongly disagree with the quality level broadcast, I would prefer to direct my money towards causes I consider more useful, and with which I could better identify. Unfortunately, the whole system is governmentalised to the point where this choice is taken away from me. The Billag website helpfully offers answers to the common questions, including one along the lines of quality. They suggest that you get in touch directly with the programme directors to complain about their content, and offer suggestions. Shortly after I moved to Zurich, Radio Lora offered me a radio show. Radio Lora is a private station, but they also receive subsidies from the monies exacted by the government, so I am using them as an example here. I suggested that I concentrated only on progressive and psychedelic rock from the sixties and the seventies. They refused the show in the end, claiming that this would not be what their listeners want. So instead I now get to pay for content that is deemed more appropriate. I can only imagine the pains I d have to go through to be able to host a radio show concentrating on eclectic tunes on one of the public radio stations. And even if I succeeded (without becoming a full-time public radio broadcaster), then I could only contribute a few hours a week to that content. If you ask me, the Swiss government is overstepping its competencies a bit. NP: Mono: Hymn to the Immortal Wind

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.

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!

Myon recently posted a nice statistic about popular single letter package name prefixes. Just out of curiosity I started wondering about popular single letter package name suffixes: On a machine with Debian oldstable, stable, testing, unstable and experimental in its sources.list, I ran the following command:

$ apt-cache search -n .   \
    awk ' print $1 '   \
    sed -e 's/.$//'   \
    sort   \
    uniq -c   \
    sort -n

And to my surprise there is a non-obvious winner:

$ apt-cache search -n '^gp.$'
gpa - GNU Privacy Assistant
gpc - The GNU Pascal compiler
gpe - The G Palmtop Environment (GPE) metapackage
gpm - General Purpose Mouse interface
gpp - a general-purpose preprocessor with customizable syntax
gpr - GUI for lpr: print files and configure printer-specific options
gps - Graphical Process Statistics using GTK+
gpt - G-Portugol is a portuguese structured programming language
gpw - Trigraph Password Generator

But since I searched through the binary packages many other hits are more obvious, like the seven packages hbf-cns40-1 to hbf-cns40-7:

      [...]
      4 ar
      4 aspell-f
      4 automake1.
      4 cpp-4.
      4 e
      4 g++-4.
      4 gappletviewer-4.
      4 gcc-4.
      4 gcj-4.
      4 gcompris-sound-e
      4 gfortran-4.
      4 gij-4.
      4 go
      4 gobjc-4.
      4 gobjc++-4.
      4 h
      4 iceweasel-l10n-e
      4 iceweasel-l10n-k
      4 kde-i18n-f
      4 kde-i18n-h
      4 kde-l10n-e
      4 kde-l10n-s
      4 kile-i18n-e
      4 koffice-i18n-e
      4 koffice-i18n-s
      4 koffice-l10n-e
      4 koffice-l10n-f
      4 libqbanking
      4 myspell-f
      4 myspell-h
      4 openoffice.org-help-e
      4 openoffice.org-l10n-b
      4 openoffice.org-l10n-h
      4 openoffice.org-l10n-k
      4 sd
      4 tcl8.
      4 tk8.
      5 aspell-e
      5 aspell-h
      5 iceweasel-l10n-s
      5 kde-i18n-b
      5 kde-i18n-e
      5 kde-i18n-t
      5 kde-l10n-k
      5 openoffice.org-l10n-e
      5 openoffice.org-l10n-t
      5 pa
      5 tc
      6 gc
      6 kde-i18n-s
      6 libdb4.
      6 m
      6 openoffice.org-l10n-n
      6 openoffice.org-l10n-s
      6 s
      7 hbf-cns40-
      9 gp

But there are also some other interesting observations to make:

• OpenOffice.org seems to have by far the biggest number of localisations, with KDE being 2nd.
• There are 6 version of the Berkeley DB in Debian: libdb4.2 to libdb4.7 (including oldstable as mentioned above)

I leave it as an exercise to the reader to find the full names of the other package names starting with s, m, gc, pa or tc and having just one additional character. ;-)

... 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.

I did some work on kbd today. I basically took an old Debian patch, the only significant divergence from the original tarball, and altered it in a way that I can read and understand it more easily (so I can send it upstream in good conscience). This process naturally involved a lot of errors. As I m talking about loadkeys here, they became unpleasantly obvious whenever I tested my code: First I messed up everything but plain printable ASCII characters (so the return key was mapped to Unicode U+0201 instead of the correct K(0x02, 0x01)), then I managed to completely freeze everything. In both cases, Alt+F7 was affected by the damage. Just like Ctrl+Alt+Del. Time for the good old boring elephants. I learn from mistakes when I make them twice, so a while sleep 60; do chvt 7; done loop saved me from further reboots. I nuked /dev/tty1 once more (in the really cool, irreversible way that disables all keypresses), but I could move on to the next VT. After a final adjustment, my modified patch finally worked. I sent it upstream, forgot about the troublesome debugging and went on to something else. Later in the evening, I decided to end the last school holidays in my life with a bit of instant messaging. BitlBee, a Jabber IRC gateway, is running on my virtual private server for this purpose. Being the occasional chatter that I am, I haven t touched it since the recent upgrade to Lenny. The format of its account configuration files has apparently changed, so I started to set up BitlBee anew. It kept telling me that there is an Authentication failure ; given the peculiar setup of the XMPP server I use, this didn t really surprise me. But still, this thing had worked before. Perhaps I really got my password wrong? I haven t typed it for ages, BitlBee stored it for me. As the administrator of my Jabber server, I could easily reset my password to what I thought it was. BitlBee still refused to get past the identification stage. I decided to install Gajim, entered my account information and told it to connect. Gnah. One or the other Python exception caused an eternal stream of error dialogue boxes to appear simultaneously and steal my focus. I don t have a keyboard shortcut for xkill and I couldn t type anything in a Urxvt (error message #54321 would receive the keystrokes). Ctrl+Alt+F1, get me out of here! Oh, right, I broke that one! At that point, I burst into a laugh. Somewhere in this post, there are a few bugs to report.

In college at the students union elections we once had the pleasure of seeing a candidate run into the lecture theatre during a break, give a 30-second stump speech, run out, and (accidentally), run in the other door to the same theatre, give the same speech to the same class, and leave without realising his mistake. But at least this was college politics, and a friendly audience. It takes a government minister to stand up in front of a rally of his opponents supporters and accidentally denounce them ... (Wrong rally blunder in India poll, thanks to the BBC). Tags politics, humour, links

This is a short summary of how I'm currently experimenting with dpkg to generate, check and install TDebs in a pbuilder chroot. Do NOT use my modified version of dpkg outside a chroot!. Also, I don't expect any of this to be useful or usable by anyone not running Debian sid. If you're reading this via an aggregator other than planet.debian.org, please don't try this on your own systems. (Comments complaining that it breaks Ubuntu will be deleted - I'll have good fun laughing at you but the comments will still be deleted.)

The code (such as it is) lives at git.debian.org and it's safe to build the package on the normal system, as long as you install it in the chroot. I actually use a --prefix to allow

sudo make install

to copy the executables into the right places in the chroot. I find that quite simple to do via the terminal plugin in Anjuta.

Building a TDeb for the first time:
I expect lots of comments here, this probably won't be entirely workable initially, but the idea is to get the source for a package that has translations, that is easy and quick to build, few build dependencies and one with which you are already familiar. Adapt that package to support a TDeb by adding the relevant Package: to debian/control. All you need to include is: XC-Package-Type: tdeb and ensure that the new package is Architecture: all. Current convention is to call it $sourcepkg-tdeb. (Yes, although TDebs are initially going to be for debconf support in Squeeze+1, initial experimentation is with program translations because it's easier.)

/usr/share/emdebian-tools/dh_gentdeb (from the emdebian-tdeb package in Debian) can help prepare the translation files by creating the debian/$sourcepkg-tdeb/ directory hierarchy but you could also do the same by installing all /usr/share/locale/ content in the tdeb package in debian/rules or debian/foo.install. Remember to remove the translation files from any other package.

Building the TDeb should be as simple as:

dpkg-deb --tdeb -b debian/pilot-qof-tdeb ../pilot-qof-tdeb_0.1.7-1_all.tdeb


You do not need to build the source itself but you may want to do that for other reasons. You can then view the contents using:

dpkg-deb -c ../pilot-qof-locale_0.1.7-1_all.tdeb

or

ar -t ../pilot-qof-locale_0.1.7-1_all.tdeb

Install (dpkg -i ../pilot-qof-locale_0.1.7-1_all.tdeb --lang vi) used to work but I've messed up something there, so any ideas on what I've done wrong would be appreciated.

Subverting git with subversion

Yes, I'm a git phobe. Don't flame me and any comments about my git foo by the git fanboy contingent will also be deleted.

I have to use git for this because the dpkg maintainers like git. That doesn't mean I have to like it or even use it. So, I use a local SVN repository. I do all my development work against that (because it's more friendly) and make local commits to it. Then, when I'm reasonably happy with the results, I copy the files across into git, fake a git commit message that more or less covers the real changes and use a script to "push" git to do what I intended. If (more likely, when) git decides to be all unfriendly and throw a completely unintelligible error message, I simply rm -rf git/path/, check out a fresh git, copy the real stuff from SVN and send the lot back as a single commit to git. Hah!

(For those who are not so blinded by their git obsession that they may actually care about my process, I can only say that local SVN is blisteringly fast and never, ever, fails.)

========================================================================
/tmp/lab announces the second Hacker Space Festival
(Paris, 26-30 June 2009)
======================================================================== Hacker Space Festival 2009 Call For Proposals HSF2009 In 2008, we organized HSF[1] on the spot, as an ad-hoc meeting for
hackerspaces-related networks, technical and artistic research emerging
from them and social questionning arising from them. This sudden
experiment proved to be a huge success, as much as on the
self-organizing level as on the participants and meetings quality, as
well as the emotionally-charged ambient, the kind of which you make
fond memories. The 2008 edition generated a strong emulation in France, from its
historical role as the first official hack meeting there, and in Europe
with the subsequent creation of the Hacker Space Brussels[2], the
rapprochement with The Fiber in Amsterdam and the hackerspaces.org[3]
network. Initiatives of hackerspace openings in Grenoble or Lille, or
the upcoming FrHack[4] conference show an actual enthusiasm in the
French hackers community that was doomed to the underground not so
long ago. We salute these initiatives and their diversity! Soon enough, we wanted to reiterate the HSF experience : however, it
was out of the question to institutionalize this temporary autonomous
zone, nor make it an ersatz of the previous edition, nor even to wrap
it into an elite or underground aura. On the opposite, we ardently
desire; and especially to explore further, in all directions some
lesser known domains (see below) et foster meeting and sharing around
experiences at the confluence of art, technology and politics. The world financial crisis, the decay of democracy in Europe, the
obscurantism, paranoia and lack of culture presiding over legislation
(Internet and Reaction Err Creation Law[5][6]) seem a fertile
environment for the sensible development of new (social ) life forms.
Quick! Let s rest for a few days in jubilation and ecstasy to take a
deep breathe of freedom under the indelicate smells of the medicine
factory nearby! For if the public space is shrinking to oblivion, where any side-step
becomes suspect, and that, from an early age (deviant behavior
detection in nursery school), where moving without a mobile phone
becomes suspect (hello you Julien Coupat[7], a French political
prisoner in France!), there s a domain that the Leviathan would have a
lot of trouble to contain, and for a reason: that of sensitivity. Even
the desperate attempts of the State to block the free and premonitory
expression of sense (hello you Demeure du Chaos![8]) cannot do anything
against a loud laughter or a knowing glance, a sensual kiss or an
explosion of colors. Sensitivity, we could say, is what is left to a human being when she
has nothing anymore, and differenciates her from the body corporate or
the institution, that are, in essence, devoid of it. Therefore, Art
definitely remains the public space to share between humans, and only
between us. And if it the last one to share, we propose to explore it
and take it over during the upcoming edition of the Hacker Space
Festival, from the 26th to 30th of June, 2009 at Vitry sur Seine[9]. ========================================================================
Keynote Speakers: Sergey Grim and Larry Fake with Eric Schmoudt
Groogle Summer of Crode, Survivor style
VLC, I vote against you because you really fucked up when ========================================================================
== W A N T E D ========================================================= Focus on solutions rather than problems. * The Final (Hardware) Frontier: Open FPGA Cores, Reverse Engineering
* Designer Religions and Creative Beliefs Systems
* WiFiDoors & WiFi System-on-Chip controllers firmware hacking,
infection & backdooring
* Telecom Core Network Equipment Reverse Engineering: MSC, STP,
Switches,
* Algebraic Attacks and Modern Cryptography Attacks
* Autonomous, Parasitic and Viral Drones
* Enhanced or Infected Reality Swarms
* Auto-Builders / Self-Fabrication
* Embedded OS breakins stories & recipes
* Actualization rather than mere concepts
* FPGA & ASIC hacking / backdooring
* Cloud+Privacy+Open Source: O Brave New World?
* Explosion-Proof clothing
* Radio Appz & Hackz: Mesh @ RF Layer 1-3
* Database & Privacy
* Problematic & Ethical Open Source/Content Licenses
* Institutional Relationships: Lobbying or Licking?
* Non Lethal Protection (anti-taser vests?)
* Survival in the Age of the Ministry of Immigration and National
Identity
* Mental asylum improvised visit
* Open Source Legacy Media(TM) Production Solutions (TV, Radio, Press,
DRM)
* Gas Sensors & Environmental Benchmarking
* Building Hackerspaces Without Money
* Milsatcomm hacking: Military satellites shots, broken birds in the
sky
* Other research topics on security and insecurity
* Academics and Hackers
* Organics and Fermentation
* Clean Food in Tainted Environment
* Low Impact Energy & Recycling
* Media Sandwich: layers of crap makes good food?
* Deconstructing Carla Sarkozy
* Knitting DIY Factory (jazzy, eh?)
* Signs of life among industrial wasteland
* Hallucinogenic & Computing: Can you Code on Acid?
* Mesh Networking (Wireless BattleMesh Royal!)
* Legal Sabotage: When Democracy Needs You And anything that does not fit. ========================================================================
== P R O P O S E ======================================================= Send you contributions to HSF2009-CFP@lists.tmplab.org + Type of the proposal: 1. conference (45min. presentation + 10min. for questions)
2. workshop / demo (30min. 2 heures)
3. installation / performance (music, plastic, sound, video) Lightning talks can be proposed and organized until the last moment,
according to available space and schedule, in the form of BarCamps or
Blitz Conferences. + Required Information: * Title of the presentation
* Type (see above)
* Language : French or English
* Name of speaker(s)
* Affiliation (organization / company)
* Short biography
* Abstract (5 to 10 lines)
* Topics / Keywords
* Includes a demo? YES NO
* Release during the festival? YES NO
* Internet connection required? YES NO + Acceptable Formats * Open Document
* PDF
* Plain Text
* RTF + Agenda * beginning of proposals : now
* end of proposals : 01 May 2009
* selection notification : 07 May 2009
* publication of program : 15 May 2009 + Evaluation criteria for proposals: 1. Innovating Topic
2. Open Technology
3. Demonstration / Live Act
4. DIY Reproducibility
5. Fun Potential The Programming Committee resembles that of last year
See : http://hackerspace.net/committee ========================================================================
== V E N U E =========================================================== /tmp/lab
6 Bis rue Leon Geffroy
94400 Vitry sur Seine
France http://hackerspace.net/directions ========================================================================
== P A R T I C I P A T E =============================================== Email : http://lists.tmplab.org/listinfo.cgi/hsf2009-talk-tmplab.org
CFPmail: HSF2009-CFP@lists.tmplab.org
IRC : irc://irc.freenode.net/frlab
Jabber : xmpp:hsf2009@space.cepheide.org?join
Wiki : http://hackerspace.net/hsf2009 ========================================================================
== L I N K S =========================================================== The CFP is available online at http://hackerspace.net/cfp [1] http://hackerspace.net/hsf2008
[2] http://hsb.wikidot.com/
[3] http://hackerspaces.org/
[4] http://www.frhack.org/
[5] http://jaimelesautistes.fr/
[6] http://laquadrature.net/
[7] http://fr.wikipedia.org/wiki/Julien_Coupat
[8] http://www.demeureduchaos.org/
[9] http://hackerspace.net/
Philippe Langlois
Email: philippelanglois@free.fr
PGP Key: 8DAEE244

This week seems like ugly fonts week. First, KDE4 was uploaded to unstable. Now I'm not a KDE user, but I do cherry-pick a few KDE applications which I find useful or interesting, and use them in my IceWM environment; these are mainly korganizer (with konsolekalendar in my .bashrc), kdebluetooth, and digikam. First thing I noticed is that something went horribly bad with the fonts -- see this screenshot for an example of what the problem is; the korganizer window in the background has ugly artifacts, while the kbluetooth menu in the foreground is still a KDE3 window which does what I was expecting. Second, someone thought it good to add console-setup as a dependency of Xorg 7.4. Now by itself, there's nothing wrong with that, except for the fact that console-setup by default changes the console font to something else. I had, in fact, tried out this setup a while back, but eventually (after a few weeks), decided that I did not like this font, because it's a) ugly and b) unreadable on a high-resolution 12" display. So I changed /etc/default/console-setup to get the VGA font back, ran the console-setup initscript, and all was well. Until my laptop was resumed from suspend-to-RAM. Apparently the console font is changed at that point in time, too, with some other configuration, and I'm not sure how to fix it. Oh well.

I agree. This is the book that really engages with the craft of writing.

I agree. This is the book that really engages with the craft of writing.

I have found myself, at least on a few occasions, talking to a person whose relationship to the Internets is much thinner than my own, trying to explain the nature of certain Internet memes. I find this a pretty tough task to pull off as I tend to make memes sound really infantile (and perhaps that is just what they are). To explain this world to the uninitiated, I either: 1) very quickly give up and move onto some other less obscure 2) go into semi-professorial lecture mode and give a mini-low down on memes, some of the early examples, a small theory of self-referential irony, 4chan, rickrolls, encyclopedia dramatic etc etc and then show a bunch of memes as really you can t do it justice without the audio visul component. Now, I can just point people to the Meme Factory to three youngish guys from Brooklyn who put together a **fantastic show**** a few weeks ago on, yes, Internet Memes. It was a dazzling ride into the (sometimes very obnoxious) territory that is memeology, addressing and displaying both the happy-cheery-cute side of memes as well as its darker side. The video they have on their site documents their presentation and the word is out that they will soon craft something more like a stand-alone video-essay about Internet memes. As we wait for this next step in their project, this video is an amusing watch (though the interesting stuff starts about 3 minutes in).

I have found myself, at least on a few occasions, talking to a person whose relationship to the Internets is much thinner than my own, trying to explain the nature of certain Internet memes. I find this a pretty tough task to pull off as I tend to make memes sound really infantile (and perhaps that is just what they are). To explain this world to the uninitiated, I either: 1) very quickly give up and move onto some other less obscure 2) go into semi-professorial lecture mode and give a mini-low down on memes, some of the early examples, a small theory of self-referential irony, 4chan, rickrolls, encyclopedia dramatic etc etc and then show a bunch of memes as really you can t do it justice without the audio visul component. Now, I can just point people to the Meme Factory to three youngish guys from Brooklyn who put together a **fantastic show**** a few weeks ago on, yes, Internet Memes. It was a dazzling ride into the (sometimes very obnoxious) territory that is memeology, addressing and displaying both the happy-cheery-cute side of memes as well as its darker side. The video they have on their site documents their presentation and the word is out that they will soon craft something more like a stand-alone video-essay about Internet memes. As we wait for this next step in their project, this video is an amusing watch (though the interesting stuff starts about 3 minutes in).

So, following the recent announcement that kde4 was uploaded to unstable, and following the positive feedback from Christian Perrier, I decided to give kde 4 a try.. Ironically, I am exactly in the same context as when I opened this blog, to complain about the state of kde 4 back at that time... So, I am quite satisfied by the current state. Clearly, it is usable, and most of the criticisms I had in the previous try are resolved now. Only the IRC plugin is still missing for Kopete. To me (...) - Linux / debian