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.

Following the release of Debian Lenny, I have updated my set of Debian QEMU images. The following images are now available:

• AMD64 (Etch and Lenny)
• ARM (Etch and Lenny)
• ARMEL (Lenny)
• i386 (Etch and Lenny)
• MIPS (Etch and Lenny)
• MIPSEL (Etch and Lenny)
• PowerPC (Etch and Lenny)
• SPARC (Etch)

There is no Debian Lenny SPARC image available, as QEMU does not fully support SPARC64 yet, and Debian Lenny now only supports 64-bit kernels. Note also that the README.txt files (which among other things contain the md5sums of the images) is now GPG signed. Read carefully these files as they contain details on how to use the images, and especially the minimum QEMU version to use.

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

With tonight s upload of kernel-package, the recent flurry of activity on this package (8 uploads in 6 days) is drawing to a close. I think most of the functionality I started to put into place is now in place, and all reported regressions and bugs in the new 12.XX version have been fixed. The only known deficiency is in the support of Xen dom0 images, and for that I am waiting for kernel version 2.6.30, where Linus has reportedly incorporated Xen patches. In the meanwhile, kernel-package seems to be working well, and I am turning my attention to other things. But, before I go, here is another example kernel postinst hook script (which, BTW, looks way better with syntax highlighting CSS on my blog than it does in a rss feed or an aggregator site).

    1  #! /bin/sh
    2  
    3  set -e
    4  
    5  if [ -n "$INITRD" ] && [ "$INITRD" = 'No' ]; then
    6      exit 0
    7  fi
    8  version="$1"
    9  vmlinuz_location="$2"
   10  
   11  
   12  if [ -n "$DEB_MAINT_PARAMS" ]; then
   13      eval set -- "$DEB_MAINT_PARAMS"
   14      if [ -z "$1" ]   [ "$1" != "configure" ]; then
   15          exit 0;
   16      fi
   17  fi
   18  
   19  # passing the kernel version is required
   20  [ -z "$version" ] && exit 1
   21  
   22  if [  -n "$vmlinuz_location" ]; then
   23      # Where is the image located? We'll place the initrd there.
   24      boot=$(dirname "$vmlinuz_location")
   25      bootarg="-b $boot"
   26  fi
   27  
   28  # Update the initramfs
   29  update-initramfs -c -t -k "$version" $bootarg
   30  
   31  exit 0

========================================================================
/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

At some point I might document my current e-mail setup, but for now, here's the bit that caused plenty of frustration on Friday. Many howtos for postfix and dspam will tell you that if you embed user IDs in the signature with PgSQLUIDInSignature on (or the MySQL equivalent, you can do something like this for retraining, and set it up to receive spam@example.com:

# master.cf
dspamretrain unix -     n       n       -       10      pipe
  flags=R user=dspam argv=/usr/bin/dspam --user dspam
      --class=$ nexthop  --source=error
# mailbox_transport map
spam    dspamretrain:spam
notspam dspamretrain:innocent

in which --user dspam names an arbitrary user (dspam will extract the uid from the signature and switch from "dspam" to the correct user, but the command line argument is still required, for no particular reason). I said it named an arbitrary user, but actually that's a lie. The things to be careful of are:

• the dspam user must be listed in your database (e.g. in dspam_virtual_uids for postgres users with the default setup)
• if you're running dspam in opt-in mode, dspam must have opted in (so create /var/spool/dspam/opt-in/local/dspam.dspam)

Having failed at both of those, my retrain address wasn't working, and sadness ensued.

I bought a new machine recently; for the flat at present with the aim of it becoming an upgrade for the media box once my lease is up. Nothing spectacular; E5200 Dual Core Pentium at 2.5Ghz, MSI G41M-FIDP mobo and 4G of OCZ DDR2 800. I don't need that much, but for 30 how could I resist? Total price, including the extra postage tax to NI and a small case, 200 from eBuyer. I had an existing HD I could use and also managed to find a spare DVD writer too.

I did a 64 bit lenny install from the multiarch netinst CD. There was a slight issue with partman getting confused at one point but I couldn't reproduce it so it might well have been user error. Network, graphics, sound all detected fine out of the box.

Anyway. Part of the reason for a G41 based board is that it's a fairly recent Intel chipset but slightly cheaper than the cutting edge G45. And Intel have been pretty good about getting decent support for their chipsets, both in X for 2D and Mesa for 3D. Unfortunately the X support in lenny isn't great; the driver (2.3.2) works, but I found I needed to disable acceleration for it to be reliable. And I wanted to take advantage of what the chipset could offer.

Helpfully there was a push of various shiny new bits of X into unstable last week, including libdrm 2.4.5 and xserver-xorg-video-intel 2.6.3. So I thought I'd give that a try. I don't want to track unstable on this box as it'll have pretty dire connectivity (Orange 3G at best). Testing may be a possibility but I'd need to sort out a way of pulling the updates via a USB stick on a better connected box - pretty sure I've seen things about doing this in the past so will have to investigate. For the moment I added an entry for unstable, set pinning to prefer lenny and told aptitude to install xserver-xorg-video-intel and mesa from unstable. While I can't possibly recommend this unless you're confident about being able to repair any resulting mess yourself I found it went quite smoothly and didn't pull in nearly as much new stuff as I feared.

The newer X/Mesa packages alone weren't enough. The PCI IDs for the G41 aren't yet in mainline kernels, let alone the 2.6.26 variant in stable. So I compiled up 2.6.29.1 with this patch and figured I'd enable Kernel Mode Setting at the same time. 2 reboots later (when setting KMS you don't want to enable the intelfb driver, but you do still need to enable the "Console on Framebuffer" option. Ooops.) and I had a shiny X install proclaiming OpenGL 2 hardware acceleration support and Xv. Plus switching between X and a text console was pretty damn smooth. Rockin'

On the whole I'm quite impressed, though I am seeing occasional freezes with Xine and Xv output - not sure what it's tickling as mplayer seems to be ok and I can't actually get any error output when it happens. Will try and hook it up to the network and see if I can still login that way at some point. For the moment it's still perfectly usable aside from that.

With the new kernel-package hitting Sid today, and the fact that it no longer does symlink handling by default, I thought it was time that we had an example script that shows how to do that. This is a fairly full featured script, feel free to cull down to use just what you want. I ll post a couple of ther scripts, if there is interest in this. BTW, this script does far more than the old kernel-package postisnt script ever did. Have fun.

    1  #!/bin/sh -
    2  #                               -*- Mode: Sh -*- 
    3  # 
    4  # This is an example of a script that can be run as a postinst hook,
    5  # and manages the symbolic links in a manner similar to the kernel
    6  # image default behaviour, except that the latest two versions (as
    7  # determined by ls -lct) are kept. You can modify this script 
    8  # 
    9  # Copyright 2003, 2004, 2005, 2006, 2007, 2008, 2009 Manoj Srivastava
   10  # Copyright 2009 Darren Salt
   11  
   12  set -e
   13  
   14  # The dir where symlinks are managed
   15  SYMLINKDIR=/
   16  
   17  if [ $# -ne 2 ]; then
   18      echo Usage: $0 version location
   19      exit 2
   20  fi
   21  
   22  version="$1"
   23  vmlinuz_location="$2"
   24  vmlinuz_dir="$(dirname "$2")"
   25  
   26  cd $SYMLINKDIR   exit 1
   27  
   28  if [ -n "$DEB_MAINT_PARAMS" ]; then
   29      eval set -- "$DEB_MAINT_PARAMS"
   30  fi
   31  
   32  if [ -z "$1" ]   [ "$1" != "configure" ]; then
   33      exit 0;
   34  fi
   35  
   36  rm -f vmlinuz vmlinuz.old vmlinuz-rd vmlinuz-rd.old initrd.img initrd.img.old 
   37  
   38  # Create a temporary file safely
   39  if [ -x /bin/tempfile ]; then
   40      outfile=$(tempfile -p outp -m 0600);
   41  else
   42      set -e
   43      mkdir /tmp/kernel-image-$version-$$
   44      outfile=/tmp/kernel-image-$version-$$/output
   45  fi
   46  
   47  (cd "$vmlinuz_dir" && ls -ct vmlinuz-*) > $outfile
   48  
   49  STD="$(head -n 1 $outfile               sed 's/vmlinuz-//')" 
   50  OLD="$(head -n 2 $outfile   tail -n 1   sed 's/vmlinuz-//')" 
   51  
   52  if [ "X$STD" = "X" ]; then
   53      exit 0;
   54  fi
   55  
   56  # If you want version-specific links, here's how to start
   57  STD24="$(grep vmlinuz-2.4 $outfile   head -n 1   sed 's/vmlinuz-//')"   true
   58  OLD24="$(grep vmlinuz-2.4 $outfile   head -n 1   tail -n 1   sed 's/vmlinuz-//')"   true
   59  
   60  STD25="$(grep vmlinuz-2.5 $outfile   head -n 1   sed 's/vmlinuz-//')"   true
   61  OLD25="$(grep vmlinuz-2.5 $outfile   head -n 1   tail -n 1   sed 's/vmlinuz-//')"   true
   62  
   63  echo Booting $STD, old is $OLD
   64  
   65  if [ -f "$vmlinuz_dir/"initrd.img-$STD ] ; then 
   66     ln -s "$vmlinuz_dir/"initrd.img-$STD initrd.img
   67     ln -s "$vmlinuz_dir/"vmlinuz-$STD vmlinuz-rd
   68  else
   69     ln -s "$vmlinuz_dir/"vmlinuz-$STD vmlinuz
   70  fi
   71  
   72  if [ "X$OLD" != "X" ]; then
   73      if [ -f "$vmlinuz_dir/"initrd.img-$OLD ] ; then
   74      ln -s "$vmlinuz_dir/"initrd.img-$OLD initrd.img.old
   75      ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz-rd.old
   76      else
   77      ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz.old
   78      fi
   79  fi
   80  
   81  # if [ "X$STD24" != "X" ]; then
   82  #     if [ -f "$vmlinuz_dir/"initrd.img-$STD24 ] ; then 
   83  #     ln -s "$vmlinuz_dir/"initrd.img-$STD24 initrd24.img
   84  #     ln -s "$vmlinuz_dir/"vmlinuz-$STD24 vmlinuz24-rd
   85  #     else
   86  #     ln -s "$vmlinuz_dir/"vmlinuz-$STD24 vmlinuz24
   87  #     fi
   88  # fi
   89  # if [ "X$OLD24" != "X" ]; then
   90  #     if [ -f "$vmlinuz_dir/"initrd.img-$OLD24 ] ; then
   91  #     ln -s "$vmlinuz_dir/"initrd.img-$OLD24 initrd24.img.old
   92  #     ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz24-rd.old
   93  #     else
   94  #     ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz24.old
   95  #     fi
   96  # fi
   97  
   98  # Run boot loaders here.
   99  #lilo
  100  
  101  rm -f $outfile 
  102  if [ -d /tmp/kernel-image-$version-$$ ]; then
  103      rmdir /tmp/kernel-image-$version-$$
  104  fi
  105  
  106  exit 0

At work, we have a bit of a vested interest in the Puppet and Facter packages that are in Debian, because we ultimately consume them in Ubuntu. We noticed that what was in Debian unstable was lagging a bit behind what was released upstream, and when one of my co-workers tried getting in contact with the Debian developers that were maintaining the Puppet package and got no response, I got involved. I got in touch with Micah Anderson and got myself and Nigel Kersten added to the Alioth project for Puppet. Despite Jamie Wilkinson being listed as the maintainer of the facter package in Debian, he claimed this was news to him, and Matt Palmer, who was listed as an uploader, didn't really claim much knowledge of maintaining the package either, so we took that as blessing to take over that package as well. This is where the fun begins. I've been meaning to try out Git ever since Debconf 7, where all the cool kids were using it and raving about it. I've been meaning to make the Debian DHCP package collaboratively-maintained, and use Git for the revision control, but I haven't quite gotten off my good intentions and done it yet. Part of the problem is not knowing exactly what workflow I should use, and suffering from paralysis by analysis, reluctant to experiment, because I don't want to go down the wrong path. Anyway, this is about Puppet, not DHCP. The Puppet package, as it turns out, is already maintained in Git on Alioth, so the problem here was more one of figuring out what the current workflow was, and trying to follow it. This is where Nigel came in. Conveniently, the upstream Puppet development is done in Git also, and Nigel is a contributor to Puppet upstream, so he had some Git-fu. So between the instructions on how to get started with Git on Alioth and what he knew, we could start fumbling around. It seems like the Alioth Git repository was also tracking the upstream Puppet repository, as there were commits in the Alioth one by Luke Kanies, and we didn't really imagine that he was doing Debian-specific stuff. Here's what we ended up doing to try and get what was in the Alioth repository up to the upstream version 0.24.8 of Puppet:

git clone ssh://apollock@git.debian.org/git/pkg-puppet/puppet.git

This part was fairly straight forward. Clone what's in Alioth locally.

git remote add reductive git://reductivelabs.com/puppet
git remote update
git fetch --tags reductive

Next, we added a remote branch that tracked upstream. We called it "reductive", and we updated it. The bit that took some fiddling with was fetching the tags. Nigel later figured out that tags are inherently private to a repository, and normally stay that way. So if I have a local clone of say the upstream Puppet repository, I can tag it to my heart's content, and normally those tags would stay in my local repository, because they're probably only meaningful to me.

git checkout -b upstream/0.24.8 0.24.8

This bit took a bit of work to arrive at as well. What we wanted to do was create a new branch called upstream/0.24.8, which was at what was tagged 0.24.8 in the reductive repository. Nigel pondered what would happen if you already had a tag or a branch called "0.24.8" before you added the remote repository. This is also why we had to fetch the tags from the remote repository, so we had something to check out.

git checkout master
git merge upstream/0.24.8

Next, we switched back to the master branch and merged the contents of our local upstream/0.24.8 branch that we just created. This now got the Puppet source in the master branch up to what was released as version 0.24.8. (and this is better than just running uupdate?) We did some fiddling with the debian/control file and debian/changelog and fixed up a few things that Lintian was bitching about, and were done. I'd set up a sid chroot with cowdancer previously, and had to do some faffing around with git-buildpackage to convince it to use pbuilder. I ended up using

git-buildpackage --git-builder="pdebuild --debbuildopts '-i\.git -I.git' --basepath /var/cache/pbuilder/base-unstable.cow"

So now we've got most of what we want to ship checked into Git on Alioth. I have no idea if we've done it "right", I suspect we may have done something wrong by operating on the master branch. Looking at the revision history in the Git repository on Alioth, it looks like previously things have been done a few different ways. I certainly want to write up a definitive workflow once we've figured one out. We haven't uploaded the new package to unstable yet, because we're still trying to give it a modicum of testing, and we'd like to sort out the Facter package as well. The Facter package was a more greenfield exercise, as while there was already a Git repository on Alioth for it, it was empty. So Nigel had to do some futzing around to get it checked in the right way to make git-buildpackage want to build it. He did this by himself, so I'm not sure exactly what he did. I've since discovered that it's probably lacking some dependencies it needs, so that'll need to get fixed before it gets uploaded. I look forward to reading blog posts from the smart people who actually know how to use Git properly, telling me how we should have done it. I'm still very interested in coming up with a proper workflow for preparing packages and committing the changes, and for doing code review.

Debathena Beta was rolled out to something along the lines of 10% of formerly RHEL-based computing cluster machines about a month ago. I talked about the plans for this some time ago, and it's exciting to see it actually occurring on vaguely the intended schedule. Now I can tool on campus on Debian (well, almost), and thanks to a generous application of magic**, I can even install any package in Ubuntu's universe repository on cluster machines if I need it (the machine will be restored to a good state on session logout). Rock on.

** I hear it involves schroot and LVM snapshots, but at any rate it appears to be approximately indistinguishable from magic.

A long while back, I wrote a blog entry about debconf4, which became fodder for a section in my dissertation, and which will be published as a stand alone article this summer or fall in Anthropological Quarterly. I am including a number of images, most of which are mine or taken from the Debconf Gallery but I have a few images of unknown source/origin and it would be great to help me find it. The first is the photo pictured above, which I uploaded to my flickr page. Someone sent it to me a long time ago and all I know that it is from one of the Dutch Hacker Conferences, possibly HIP. Does anyone know where I can find a copy on the web? Seen it before? Are the kid pictured in the photo? Think you are the kid pictured in the photo? Sort of look like the kid pictured in the photo? Know of a service where you can upload a photo on a page and it will locate other copies?? Know of another similarly awesome photo? The second picture is of two Debian developers Gustavo and Jonas dancing at Debconf. I can t seem to locate it in the gallery and I am not sure who took it but I would love to find out to get permission to use it in the piece. Finally: do you have any pictures (in the gallery on not) that capture the joy of conferencing that you would not mind published either in this article or my book? If yes, feel free to send any along!

A long while back, I wrote a blog entry about debconf4, which became fodder for a section in my dissertation, and which will be published as a stand alone article this summer or fall in Anthropological Quarterly. I am including a number of images, most of which are mine or taken from the Debconf Gallery but I have a few images of unknown source/origin and it would be great to help me find it. The first is the photo pictured above, which I uploaded to my flickr page. Someone sent it to me a long time ago and all I know that it is from one of the Dutch Hacker Conferences, possibly HIP. Does anyone know where I can find a copy on the web? Seen it before? Are the kid pictured in the photo? Think you are the kid pictured in the photo? Sort of look like the kid pictured in the photo? Know of a service where you can upload a photo on a page and it will locate other copies?? Know of another similarly awesome photo? The second picture is of two Debian developers Gustavo and Jonas dancing at Debconf. I can t seem to locate it in the gallery and I am not sure who took it but I would love to find out to get permission to use it in the piece. Finally: do you have any pictures (in the gallery on not) that capture the joy of conferencing that you would not mind published either in this article or my book? If yes, feel free to send any along!