TED published an interesting interview with Shai Agassi about electric cars [1]. One idea that I hadn t heard before is that of moving car batteries between regions as they lose capacity. An old battery for an electric car that can only handle short journeys may be useful in a region where journeys are typically short. On a similar note I expect that in a few decades the less prosperous countries will import old electric vehicles and fit them with 4 or more batteries. Last time I checked the Prius battery pack weighed about 120Kg, so the car would be usable with 4 battery packs if driven at low speeds. Shai Agassi also gave a TED talk on this topic [2]. The real solution for the problem of providing convenient and affordable electric vehicles is to start by recharging the batteries whenever the vehicle is parked (at the office, shopping center, home, etc). Then on the rare occasions when the car is being driven for longer distances and the battery gets flat it can be swapped for a charged battery. They have apparently designed a robot for changing car batteries, so changing the battery would be like driving through a car-wash. He describes this as an economic model that decouples the expensive battery from the car, so you pay for the use of the battery not the ownership - just as with a petrol car you pay for the petrol you use not for a portion of the ownership of an oil well. He also pointed out that cars produce 25% of the world s CO2 emissions, so his plan for all electric cars everywhere seems to be an essential part of solving the environmental problems. He then compared this to the UK parliamentary discussion on ending slavery, at the time slaves provided 25% of the energy used by the UK. After a month of discussion the decision was made to make the moral choice and end slavery regardless of the cost.

• http://blog.ted.com/2009/04/from_software_e.php


• http://www.ted.com/index.php/talks/shai_agassi_on_electric_cars.html

Ok, here we go again. I do hope somebody, somewhere is finding these posts of some use. *g*

• Changeling: I ll confess I m not very fond of Angelina Jolie, and I watched this movie exclusively because it came from Clint Eastwood. I gave it 5/5, which may be a tad too much, but that s how I felt right after it finished. It s not a light movie, but I do think everybody should give it a try when they find themselves in the mood.
• One Fine Day: This romantic comedy doesn t have much of a high rating on IMDB, and maybe I m too fond of George Clooney myself, but it pleased me enormously. Thanks to Marc HE Brockschmidt for having recommended it to me in the first place, though probably you shouldn t bother if you can t stand the genre at all. Ah, and Michelle Pfeiffer.
• Sling Blade: I was left deeply in awe by this movie, and even more so when I found out the director, writer and main role are all the same person, Billy Bob Thornton. One of the things that pleased me the most was the ending, because I found it included a good share of food for thought, particularly regarding how the characters would get on with their lives afterwards, which is not shown. Again, not a light movie, I ll reckon.
• Sideways: I enjoyed this movie a lot, and I should watch it sometime again, because I think I didn t scratch it enough. Which is great, because it s rather difficult combining hilarity with reflection. Viva la escena in the fast food restaurant.
• Tiempos de az car: I ve comitted to watching some more Spanish films, and this one is the more remarkable of those I ve seen as of late. This is a bittersweet love story spawning more than 30 years, and has Ver nica Forqu and Charo L pez in wonderful supporting roles. I should watch more films of Charo L pez.

Isaac watched Love Actually recently, and I oooh ed quite a bit when he told me, because that movie has one of my favourite or should I say powerful scenes of all times for me, and recalling it brings me instant joy and often instant tears. I think these three (spoiling) minutes are so powerful because, albeit they are fully anticipated for the spectator, they come as a complete surprise to both protagonists (obviously to her, but also to him, given the dialog that takes place once she gets down the stairs; that tiny dialog is in fact the most powerful bit of it all).

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

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

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

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

For a research project, I'm looking for some real-world time series data. Time-series are an interesting thing to study, however it is hard to get access to interesting non-trivial real-world data.I was wondering if some people could contribute me some summarized web access data; no URLs or IP addresses.The data I'd like to get can best be explained by the preprocessing step:

...   perl -ne '/\[(\d+\/\w+\/\d 4 :\d\d):\d\d/
&& print $1."\n";'   sort   uniq -c

(Sorry if you aren't fluent in regexp - it extracts the date and hour out of an Apache default log file, nothing else. These lines are then summarized by counting their unique appearances.)That should produce 24 lines per day (one per hour), looking like this:

  count day-of-month/month/year:hour

It would be cool if you could send me some series for a couple of sites, if you happen to be in the position to provide this data. The data should cover at least a few weeks, the longer the better even up to a few years.Too small sites are however not very useful but might be too noisy (so probably not the personal home page of your mom). If you are providing a larger number of series, you are of course free to include them.I don't care much about what the site actually contains, I'd just ask you to give a tiny amount of meta information:

• Server timezone if not UTC
• Typical user timezone (if applicable, that mostly applies to 'regional' sites)
• Coarse classification of site (e.g. "product website", "web service", "search engine", "company site", "OSS software site" or something like that ...)
• Redistribution permission (if possible; most likely I'll only use data series where redistribution is allowed, since some conferences ask you kindly to provide such material)
• Your email address will be withheld, to increase anonymity of the data

Data use:The main project idea is to evaluate different distance metrics in their capability of separting the different data sources, assuming that there is some difference in the shape in these curves. A different problem can be constructed by breaking the series into chunks covering approximately a day and then trying do separate different days, starting hours of the series (or offset server timezone vs. user timezone) and/or weekdays from weekends.In our experiments, we've come to the conclusion that the experimental results are most interesting when there is a sufficient number of classes; so I'd like to get like 20 different interesting data series. At the same time, the series should be long enough, so I can break them into multiple chunks to have a reasonable number of 'sub-series' per class. If I have really long series, or e.g. series covering the same site but from multiple servers, I could even experiment with taking sample of different length from these sets.(Say I have series covering 2 years, that is ~17k samples, from 3 servers, then I can take 51 disjoint sub-series of length 1000, or 102 of length 500, ...)But it's obviously not possible for me to collect this data myself - I don't operate two dozen of such sites myself ...An extra project I've been considering some time is some peak prediction for web accesses. Say you're running some fast growing site, wouldn't it be useful to have a prediction when the number of accesses will likely hit some magical limit (and e.g. overload your server) so you can increase your capacity on time? Of course it would be more sensible to apply this prediction e.g. onto CPU usage, e.g. predicting when your system might hit 90% load average over a 5 minute window in regular operation. Network bandwidth and disk IO also come into mind. You get the idea.Please send them via email to erich.schubert AT gmail comThank you.[P.S. Already recieved the first series, thank you! I can take care of sorting myself, no need to worry about that. And yes, I'm aware that the series will probably all be quite similar - common computer usage patterns such as work hours - but that is common in real world data and part of the challenge. Separting apples from dinosaurs is not a challenge.]

DPL candidacy woes Well, time to face it publicly: I lost and Steve/Luk won, it is as simple as that This post is to:

• congratulate with Steve and Luk for the result, I wish you a happy and fruitful DPL term
• thanks all the people which supported me, in particular:
  • lucas, paravoid, and gismo: my candidacy started as a typical "DebConf joke"; if then it has become a reality is for friends like them insisting (or pretending :-P) I was up to the task. Actually, I'm quite happy about the result, so it was definitely worth trying!
  • all the people which contributed comments for my platform, a list in no particular order follows (in the hope of not having forgot anyone!): madduck, enrico, lucas, tbm, godog, gismo, gregoa, dato, ralf, paravoid, buxy. Thank you guys, my platform would have been much worst without your input.
  • all the people who voted for me (of course!)

All in all, standing for DPL has been worth and interesting no matter the result. Time to get back to my usual Debian duties now ...

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.

... 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've been largely offline for the last few weeks as I've just bought a flat. This means I haven't been able to do much Debian work. Although I am now back online, I have a lot of other things to be catching up on, so I've decided to to take a break from Debian stuff until 15th May. I will still do some bug work (reporting and following up) and if I somehow find the time I may well do some Debian work regardless. I just feel that having an explicit break (rather than an implicit or imposed one) will make me feel a little bit more in control of things, and hopefully when I return I will have some new positive energy.

Consider the following mod_rewrite configuration :

RewriteCond % REQUEST_URI !^/FR/fr
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /FR/fr$1 [PT,L]

The need here, is to get anything that wouldn t begin with /FR/fr from $DOCROOT/FR/fr (through, possibly, any other module rules, which was important in the setup where these rules were), except if they begin with /common/ or is /favicon.ico. Depending on the requests pattern, reordering the RewriteConds can be better. Anyways, the case at hand was to massively duplicate this setup over different countries and languages. Basically, domain.fr/foo/bar would need to come from $DOCROOT/FR/fr/foo/bar, domain.co.uk/foo/bar from $DOCROOT/GB/en/foo/bar, while anydomain/common/foo/bar would come from $DOCROOT/common/foo/bar. In such a case, you have a lot of possible solutions, each of which has its pros and cons.

• Create a virtual host per domain, duplicating all the rules in each of them.
  

  <VirtualHost *:80>
ServerName domain.fr
RewriteCond % REQUEST_URI !^/FR/fr
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /FR/fr$1 [PT,L]
</VirtualHost> <VirtualHost *:80>
ServerName domain.co.uk
RewriteCond % REQUEST_URI !^/GB/en
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /GB/en$1 [PT,L]
</VirtualHost>
( )

  Pros: quite efficient for execution time. Cons: Doesn t scale very well for humans : a lot of virtual hosts and rewrite rules to maintain ; if the list of urls that don t need rewrite increases, all set of rules need to be updated.
• Put all the rewrite rules into a single virtual host, adding a condition on the SERVER_NAME:
  

  <VirtualHost *:80>
ServerName domain.fr
ServerAlias domain.co.uk RewriteCond % SERVER_NAME =domain.fr
RewriteCond % REQUEST_URI !^/FR/fr
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /FR/fr$1 [PT,L] RewriteCond % SERVER_NAME =domain.co.uk
RewriteCond % REQUEST_URI !^/GB/en
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /GB/en$1 [PT,L] (...)
</VirtualHost>

  Pros: are there ?. Cons: Doesn t scale very well : a lot of rewrite rules to maintain ; rewrite rules being executed sequencially, the more domains there are, the more checks are done for the last domains ; if the list of urls that don t need rewrite increases, all set of rules need to be updated.
• Same as above, refactoring the common parts.
  

  <VirtualHost *:80>
ServerName domain.fr
ServerAlias domain.co.uk RewriteCond % REQUEST_URI ^/common/ [OR]
RewriteCond % REQUEST_URI ^/favicon.ico$
RewriteRule .* - [L] RewriteCond % SERVER_NAME =domain.fr
RewriteCond % REQUEST_URI !^/FR/fr
RewriteRule ^(.*)$ /FR/fr$1 [PT,L] RewriteCond % SERVER_NAME =domain.co.uk
RewriteCond % REQUEST_URI !^/GB/en
RewriteRule ^(.*)$ /GB/en$1 [PT,L] (...)
</VirtualHost>

  Pros: gives a canonical place for urls that don t need rewrite. Cons: Doesn t scale very well : a lot of rewrite rules to maintain ; rewrite rules being executed sequencially, the more domains there are, the more checks are done for the last domains.
• Use a RewriteMap.
  Pros: Scales better ; gives a canonical place for urls that don t need rewrite. Cons: a separate file to maintain ; can be tricky to setup.

The main problem with mod_rewrite is that there is no way to use variables or back references in the test patterns. In our case, we d like to be able to do something like this:

RewriteMap l10n txt:l10n.map # switch to dbm when necessary
RewriteCond % REQUEST_URI !^$ l10n:% SERVER_NAME
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ $ l10n:% SERVER_NAME $1 [PT,L]

Or

RewriteMap l10n txt:l10n.map # switch to dbm when necessary
RewriteCond $ l10n:% SERVER_NAME ^(.+)$
RewriteCond % REQUEST_URI !^%1
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ %1$1 [PT,L]

The map file would have on each line a domain name followed by the corresponding url start (/FR/fr for domain.fr, etc.). Unfortunately, the above setup is not possible. A way around this lack of functionnality is to use some nice perl regexp trick.

RewriteMap l10n txt:l10n.map # switch to dbm when necessary
RewriteCond $ l10n:% SERVER_NAME ^(.+)$
RewriteCond %1% REQUEST_URI !^(.+)\1
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ %1$1 [PT,L]

As you can see, only the second RewriteCond differs. What we really want to test is whether the % REQUEST_URI begins with the proper url start or not. Let s say we re considering domain.fr and the map gave us /FR/fr. Following the first RewriteCond, %1 contains /FR/fr. At the second RewriteCond, if % REQUEST_URI begins with /FR/fr then %1% REQUEST_URI begins with /FR/fr/FR/fr. Otherwise, it will only begin with /FR/fr. What we can test, then, is whether this %1% REQUEST_URI aggregate contains a repeating pattern at its beginning. This is exactly what the perl regexp does: it captures at least one character at the beginning of the tested string (^(.+)), and wants to find this captured string again (\1). It is worth mentioning that this obviously falls flat when the url start itself contains a repeating pattern (e.g. /fr/fr instead of /FR/fr). As we want the RewriteRule to work only when our % REQUEST_URI does not begin with /FR/fr, we negate the regexp, which means nothing will actually be captured, such that %1 in the RewriteRule will still be the last captured text, from the very first RewriteCond. Note that if all the tested url starts are the same length and/or pattern, it may be worth changing the regexp to be more precise (and faster to match or not). Such as ^(/../..)\1 in our present case.

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

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

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.

Stephen Marenka wrote to the debian-68k list lately:

So you may have noticed the following in your buildd logs for python-
depending packages.

dpkg: regarding .../python-docutils_0.5-3_all.deb containing python-docutils:
package uses Breaks; not supported in this dpkg
dpkg: error processing /srv/chroot/sid/var/cache/apt/archives/python-docutils_0.
+5-3_all.deb (--unpack):
unsupported dependency problem - not installing python-docutils

That's right, our old etch-m68k dpkg doesn't support Breaks.

The options I can think of are.

Option 1: backport dpkg to etch-m68k
Yuck. etch-m68k is old and likely insecure. Who knows what
back-porting dpkg would look like.

Option 2: lenny-lite
Build lenny with base, build-essential, and buildd-required
packages. I can probably do this one myself if there's
interest. I'll probably include anything required for d-i
too.

Option 3: lenny
Go ahead and try to do a lenny release. I think we have
nearly all the binary packages, but how to shove them into
an archive intelligently? I'm willing to help if anyone
knows how and can direct or is otherwise willing to lead.

Option 4: throw in the towel
Say it's time to retire m68k on debian. We have an ancient
glibc with borked threads. gcc-4.3 is fairly broken. A
number of packages need some bugs fixed, others need some
porting. Not so many helpers these days. Funny thing is with
aranym we have plenty of horsepower (although we need to fix
the fpu emulation) and with d-ports our buildds won't get
locked out of wanna-build. Kernel's probably in the best
shape it's been in a long time.

peace,

stephen

--
Stephen R. Marenka If life's not fun, you're not doing it right!

Yes, it's true... the Vancouver proposal seems to be a true success in killing the m68k port. Stephens mail is just a written example of what I've been thinking about for several weeks as well: does it still make sense to run my Amigas after being kicked out by Debian?

Luckily there were some new users appearing on the list asking for how to install Debian on their m68k machines, which shows that there's still interest in the port and need for a Debian on m68k. This makes me more confident in still supporting the m68k port for me by running several buildds 24/7. But as Stephens mail shows the m68k port is in trouble. It would be nice if there were more porters helping in actually porting software or fixing bugs. There are some open issues like NPTL support and such. See the list archive or the Debian wiki for more information.

Despite all the bad luck with being kicked off by Debian, the port did made some progress in the past: we're not bound by real m68k hardware anymore. Thanks to Aranym every interested developer can now contribute by running the emulator on his/her fast i386 machine. There are crosscompilers available as well.

But there's still work to do. For example to Coldfire inclusion seems to got stuck somehow. And I don't think that it makes much sense to try to build all of Debian >>6000 packages for m68k, but to concentrate on maybe below 2000 packages. So if you want to help to m68k port staying alive, please join us at debian-68k mailing list! :-)

It's been a long time since I've done any reasonable work on X stuff, so it's also been a long time since I've blogged. But Julien and Brice* just finished off the major task of getting 7.4 in to unstable, and I've been trying to help out with some of the inevitable fallout from that. Overall, the transition has been relatively smooth, although we've had a few major classes of bugs that have popped up. Since dealing with the BTS is rather complicated and doesn't lend itself to simple summaries, I created this wiki page for the team to track the major classes of bugs currently plaguing unstable. This isn't meant to track every bug (that's what the BTS is for), but for major regressions or problems with new features, we'll be trying to use this page to give ourselves and users a way to easily see what's going on with some of the more recent problems. And yes, this does include the infamous hal depends bug, which we are currently discussing, and will deal with accordingly.

* Edit: Removed by request

I just uploaded nvidia-graphics-drivers 180.44 that work with Debian's 2.6.29 thanks to package team member Len Sorensen. If anyone wants to be as amazing as Len you may join the packaging team too.

I also did some BTS cleaning in regards to bugs reported by people not using the debian packages (and even said so) but reassigned to us anyway.

I am also battling a bad cold. I always get sick on holidays.

Oh one more thing. Go Canucks!

I got interesting comments on my previous post about SSH through jump hosts, that made me think a bit. The first one of them suggested to use a syntax that unfortunately doesn t work on anything other than zsh, but had the nice idea to add a login for each jump server. Sadly, this only works when there is only one hop, for reasons similar to those we will explore below. The second one suggested / would not be so good a separator, because it would fail in svn+ssh urls and such, which is a good point that I didn t think of only by lack of such use case. The simplicity of the resulting configuration was nice enough. This decided me to take a shot at implementing something that would allow adding both login and port number for each jump server. The first implementation detail to set was which characters to use for login, port number and hop separators. I chose respectively % (@ is unfortunately impossible to use because ssh would take it, leaving out any hop before the character), : (pretty standard) and + (not allowed in DNS, and not too illogical as such a separator, I thought). The result can look like dark magic when you are not savvy with sed and regular expressions:

Host *+*
ProxyCommand ssh $(echo %h sed 's/+[^+]*$//;/+/! s/%%/@/;s/:/ -p / ;s/\([^+%%]*\)%%\([^+]*\)$/\2 -l \1/ ) PATH=.:\$PATH nc -w1 $(echo %h sed s/^.*+//;/:/!s/$/ %p/;s/:/ / )

The syntax you can use to connect through jump hosts is the following:

ssh login1%host1:port1+login2%host2:port2+host3:port3 -l login3

We ll see further down why we can t put a login for the final destination host. Or if you want to skip the boring implementation details, you can also skip to the end, where a slightly more compact version lies: while writing this post, I got some optimization ideas. Let me try to split the sed syntax to make it a little more understandable:

s/+[^+]*$//; # Remove all characters starting from the last + in the string (i.e. keep the n - 1 first hops)
/+/! # If the string doesn t contain a + after the previous command (i.e. there is only one hop remaining), do the following, otherwise, skip until the closing curly brace
s/%%/@/; # Replace % with @ (% is doubled because of the ProxyCommand)
s/:/ -p / # Replace : with -p . Combined with the previous command, we rewrite login%host:port as login@host -p port
;
s/\([^+%%]*\)%%\([^+]*\)$/\2 -l \1/ # Rewrite hop1+hop2+login%lasthop as hop1+hop2+lasthop -l login

The second sed goes like this:

s/^.*+//; # Remove everything up to the last occurrence of + in the string (i.e. only keep the last hop)
/:/! # If there is no : in the string, do the following, otherwise, skip the next statement
s/$/ %p/; # Add %p at the end of the line
s/:/ / # Replace : with . These last three instructions prepare a host port combination for use with nc.

Let s see what the ProxyCommand looks like for some examples, skipping PATH setting and nc option for better readability:

host1+host2

ssh host1 nc host2 %p

login1%host1+host2:port2

ssh login1@host1 nc host2 port2

login1%host1:port1+host2:port2

ssh login1@host1 -p port1 nc host2 port2

Now, maybe you start to see why we can t put a login on the last hop: not only does it make no sense for nc, but also the main ssh process that runs the ProxyCommand and will actually talk to the remote host won t have any knowledge of it. From the above examples, it also appears obvious why we replace login%host:port with login@host -p port : so that the ssh command in the ProxyCommand gets the proper arguments for login and port. Note we could also replace with host -p port -l login for the same effect. With even more hops, this is what happens:

host1+host2+host3

ssh host1+host2 nc host3 %p

login1%host1:port1+host2:port2+host3

ssh login1%host1:port1+host2:port2 nc host3 %p

Each of these ProxyCommands will trigger another ProxyCommand quite looking like our first few examples. In the first hops, if we d just replace all % with @ , in cases where logins are given everywhere, we d end up with a ProxyCommand like the following:

ssh login%host1+login%host2 nc host3 %p

As we saw above, we can t use a login on the last hop, which means this ProxyCommand wouldn t work as expected and is why we have to rewrite login1%host1+login2%hop2 as login%host1+host2 -l login2 with the last instruction in the first sed. In the end, this is what happens:

login1%host1+login2%host2+host3

ssh login1%host1+host2 -l login2 nc host3 %p

login1%host1:port1+login2%host2:port2+host3:port3

ssh login1%host1:port1+host2:port2 -l login2 nc host3 %p

In this last example, you see the :port2 part is not changed into -p port2 . Actually, it would still work with the latter form : the ProxyCommand ssh login1%host1:port1+host2 -p port2 -l login2 would itself have ssh login1@host1 -p port1 nc host2 %p as ProxyCommand, in which %p would be replaced by port2, given as argument to -p. Based on this and with further small optimizations, we can slightly shorten our ProxyCommand to the following :

Host *+*
ProxyCommand ssh $(echo %h sed 's/+[^+]*$//;s/\([^+%%]*\)%%\([^+]*\)$/\2 -l \1/;s/:/ -p / ) PATH=.:\$PATH nc -w1 $(echo %h sed s/^.*+//;/:/!s/$/ %p/;s/:/ / )

sed instructions decryption is left as an exercise to the reader ;). Update : modified the shortened version to fix the issue spotted in the comments.