This evening, I arrived at church for mens chorus practice. I was surprised to see this sign on the door:

Rudy Schmidt died rather unexpectedly, but peacefully on Wednesday morning at his home .

One of the benefits of living in a small community is that I get to know people of all ages around here. Not just people my own age, or coworkers. A few years ago, I worked on a history project for our church s centennial. Back in the 1960s, Rudy was one of the people in charge of building our current church. So he was a person I was interested in visiting with. Here he is, on the left, during the 1964 groundbreaking ceremony for the new building (the old one is visible in the background). I and a few others went to his home one time a few years ago and we had a wonderful evening. Rudy shared all sorts of stories with us which I am happy to say I recorded. But moreover, Rudy was an avid photographer. There were some rare and brilliant color slides of the church being built in his collection. He let me borrow and scan some of them. Here are my two favorites: Back in 1965, there was a ceremony at the setting of the cornerstone of Tabor Church. The people at the time assembled some papers and memorabilia and put them in a time capsule. Rudy Schmidt sealed the capsule and it was placed in the spot for it behind the cornerstone. Here is a photo of that ceremony. 44 years later, on the occasion of Tabor s centennial, it was time to open the time capsule. The other building committee people, such as Jake Koehn, had passed away, so Rudy was the one to open it. He gave a few words in front of the large crowd, and mentioned that when he sealed it away, he smelled some smoke when he soldered it shut. Jake Koehn told him, Don t worry, nobody will ever see it again anyway and they had a little laugh about it. Now he was going to open it up and see if anything survived. It all did just a few minor burn marks. We enjoyed looking at all the items. Then the church placed some new items into the capsule. It was closed up again, to be opened in maybe 50 years. With luck, I ll still be around to see it opened again. Even if I m not, maybe Jacob and Oliver will be able to. And so it seems very fitting that the last hands to touch that box for the next 50 years were Rudy Schmidt s, when he placed it back in its spot on Oct. 12, 2008.

• Running 24fps films at 23.976fps allows them to be converted to NTSC with a minimum of misery
  
• Hulu's streams, despite film and NTSC both seeming to be pretty irrelevant, seem to be at 23.976fps
  
• If mencoder is asked to remux one of these streams into another flv stream, it'll set the fps to 24
  
• A 42 minute episode will end up about 3 seconds out of A/V sync due to this difference

Yes, of course this took far too long to work out.

Three thousand lines of code is not a huge program, but it is enough to get a pretty good feel for a language. Now that I've completed my first real Haskell program I feel that I've gotten over several of the humps in the learning curve and am starting to get a good feel for it. Actually, I've written closer to five thousand lines, since there were several big refactorings. One was when I stopped manually threading my program state around and added a StateT monad. I did know from the beginning I would need one, but it seemed easier and a better learning exercise to let the program start out with a vesigial tail and gills before growing up into a modern Haskell program. (I suppose it's still written in baby-Haskell, really..) Another refactoring came when I realized I needed to use a custom data type, not String, to represent keys. That was a great experience in type-based refactoring. Being able to keep typing ':make' and landing on the next bit of code that needed fixing was great, and simply adding that one type exposed several non-obvious bugs. I found myself writing code that is much more solid and reusable than normally comes easily. And yet it's also very malleable. Actually, pulling out better data types and abstractions can get a bit addictive. When I realized that I had a similar three-stage control flow being used for each of git-annex's subcommands, and factored that control flow out into a function that used the 3 data types below, I felt I'd gone down that rabbit hole perhaps far enough for now.

type SubCmdStart = String -> Annex (Maybe SubCmdPerform)
type SubCmdPerform = Annex (Maybe SubCmdCleanup)
type SubCmdCleanup = Annex Bool

(That will allow for some nice parallelism later though, and removed dozens of lines of code, so was worth it.) Since git-annex is a very Real World Haskell type program, there is a lot of impure code in it. I could probably do better at factoring out more pure code. I count 117 impure functions, and only 37 pure. Anyhow, from my perspective of a long-time perl programmer, some other random impressions..

• ghc --make is handy, but every time it spits out a new 13 mb executable I can feel my laptop's SSD groan!
• It was surpisingly easy to get into nasty situations with recursive dependencies between the 19 haskell modules I wrote. Sometimes solving them was really messy. I lost hours to this. More time than I've lost to the problem in all other languages combined over 15 years. It's not clear to me if it was due to the overall design of my program, or if Haskell's types tend to encourage this problem. Or if there's some simple "please let me have recursive dependencies" switch to ghc that I missed..
• I'm used to being able to use man to get at mutiple books worth of detailed documentation for perl, and work easily offline or with limited bandwidth. With Haskell, I spend much more time searching online for documentation than I an comfortable with (although Hoogle is pretty neat). And the haddock-produced documentation is often pretty sketchy. The saving grace is that the source to any library function is a click away, and tends to be very readable.
• I'm used to being able to use pretty much any Unix syscall by name from perl: mkdir, chmod, rename, etc. In Haskell, there is a Windows smell to the names, like createDirectoryIfMissing and setPermissions. And there are pointless distinctions like renameFile vs renameDirectory. These long names are not memorable and I have to look them up every time. Most of POSIX is available, but it's scattered amoung many disparate libraries, and I can't find an interface for sysconf(3) at all. There is a certian temptation, that I am so far resisting, to make a library for C/perl refugees that exports the sane Unix names for everything.
• Anything involving the IO monad, or probably most monads, has a certian level of syntactic clumsiness about it. Compare:

  if ($flag foo  && length $l = <>)  
  

  vs

  foo <- getFlag "foo"
  l <- getLine
  if (foo && not $ null l)
      then do
  

  When writing lots of impure code, that got old, and while I could use ifM, or make up some other similar thing, its syntax would also be somewhat clumsy.
• The fixity levels for a lot of stuff seems a bit off. I too often found myself writing error $ "foo: " ++ (show bar) or return $ Just $ ... (Still a lot better than Scheme thanks to $!)
• I've leveled up a couple times now, but this particular video game seems to have more levels going up and up, forever. Can't even see the top from here!

First there was mr, then etckeeper. Now git-annex completes my triptych of software tools that use git in ways that were never intended. Git's original tagline was "the stupid content tracker". Git-annex inverts that, by managing files with git, without checking their contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, checksumming time, or disk space. I've been working on git-annex for two weeks, and have been trusting my data to it for a week. Not a little data, but terabytes spread amoung multiple archival drives, file servers, laptops, and portable USB drives. In situations too complex for unison or rsync to be of much use. Applying git to this problem in an unconventional way has simplified things enormously. At this point it should be very usable, and solid. A package will be uploaded to Debian shortly; or git clone it.

First there was mr, then etckeeper. Now git-annex completes my triptych of software tools that use git in ways that were never intended. Git's original tagline was "the stupid content tracker". Git-annex inverts that, by managing files with git, without checking their contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, checksumming time, or disk space. I've been working on git-annex for two weeks, and have been trusting my data to it for a week. Not a little data, but terabytes spread amoung multiple archival drives, file servers, laptops, and portable USB drives. In situations too complex for unison or rsync to be of much use. Applying git to this problem in an unconventional way has simplified things enormously. At this point it should be very usable, and solid. A package will be uploaded to Debian shortly; or git clone it.

A couple of month ago, my step-father-in-law encountered quite some problems with the Windows installation on his Notebook and therefore showed a great interest in dem Linux da. So we installed him a Debian in a dual-boot setting. It was interesting to see how a basic school teacher (who is technical interested, but has no deeper technical knowledge of computers) worked with Linux, what problems he found, and how he solved them. But a big obstacle for him to work more or less entirely with Linux has always been power management problems with his notebook. To be more precise: While it was always possible to send his notebook into suspend or hibernate, it was also always impossible to wake the notebook up again. It seems that the (non-free but needed) NVidia driver was a part of the problem. Last weekend we again tried to solve the problem by installing the latest backported kernel and updating the NVidia driver, but failed again. So we decided, that with the squeeze being frozen for quite some time, it would be safe to upgrade his Notebook to that system. And believe it or not: It works! We can suspend the notebook without any problems and it will wake up again! And to his (and our) special delight waking the notebook up is a lot faster, than it used to be with his Windows (Vista?) installation. Not to mention that for some reason a suspended Linux-System seems to consume less power (he lend some kind of energy consumption measuring device from his power company to track energy saving potential, and while playing around, we also measured his notebook), than the suspended Windows on the very same system! I don't know why, but finally the installation of dem Linux da was a complete success :) So kudos to those who worked on that area :)

In the past, I ve helped customers run native Windows applications using emulation (wine) and/or virtualization, and in few cases, native support for C# by open source projects such as Mono. But, as it s been said, there are great benefits of having source code, and I recently worked around an issue in Mono by recompiling a whole .NET project in Debian. So here s a brief guide reviewing the issues that I found and how I solved each one of them leading to a natively-compiled C# application that runs seamlessly in Debian and Windows, and please remember I m not a C#/.NET/Mono developer:

• Missing assemblies: sometimes gmcs (which is the Mono compiler) will complain about missing assemblies, that is, libraries that are requested by the C# source code (files that end with .cs) hopefully because some methods are being used in that specific file. I know they re, but I still haven t found a .NET class that is not supported in Mono. So, first and foremost, you need to actually have that library installed in your system, if you re using a Debian based system run aptitude search libmono.* or the packages.debian.org site to find which package has the library file (ends in .dll) and then, when you re calling gmcs, remember to use the r: flag, for example r:System.Drawing.dll
• Missing resource indicators: apparently .NET projects consume stuff from resource files which also seem to be XML files. Since I don t know how to handle this situation, I resorted to the fine MonoDevelop IDE, since I had a .csproj file (a Visual Studio Project file) in place which hopefully could join the dots. So just use MonoDevelop (you need to install it separately) and then open the .csproj file and rebuild the entire project (F8) which in my case just left 2 errors to go
• Issues with configuration management: it seems that the .NET Framework has some classes that help with application configuration via generic XML configuration files, and the project that I was trying to compile used that indeed, so there were some tags in the configuration file that weren t properly handled by Mono, e.g., the default system proxy configuration parameter, so I just deleted it from the XML. Be also advised that you do need to have the .config XML file in place together with the resulting .exe file if your application access configuration parameters in runtime.
• SSL- and TLS certificate-related issues: finally, if your application uses an SSL or TLS Web Service (or any other SSL/TLS application FWIW) you might get some errors like authorization or decryption failed which are basically related to non-existent certificate handling in the application. The easiest way to solve it is to download and import the CA Certificate Files from Mozilla and also download the certificate for the site you re trying to access; you can run (as the user that will run the application):
• mozroots import ask-remove
• certmgr ssl https://your.site/

That said, I had a great time fiddling with this C# application and Mono on my Debian Sid laptop. I was able to properly compile without errors nor framework-related warnings, using an IDE such as MonoDevelop, and have a full-featured native binary that s interoperable.

I'm thinking about getting a Kindle, and I thought I'd write down some thoughts, even if they're a bit jumbled, and invite commentary. Good: One thing I really like, living here in Italy, is that I would be able to get English language books instantaniously, and not pay shipping or import duties on them. Whatever disadvantages there may be, that is a huge advantage. Closely tied to that: if we ever move back to the US, shipping all our books will be very expensive. Having some of them in an electronic format would lighten that load considerably. It's fairly cheap. At $180, it's not something I'd want to treat carelessly, but it's significantly less expensive than various existing tables. Long battery life means it's not something you have to worry much about. E-ink looks like it's easier on the eyes than LCD screens. I'm not sure, but also its slow update speed might be a "feature not a bug" in the sense that you're not so easily distracted by the internet being just one click away. Bad: I love having real, physical books in my house. I grew up in a house full of books, and I want the same thing for my daughter. I like being able ot look through them, pick one up, and read about something. Real books are very convenient, as long as you're not lugging around hundreds of them. I like not having to worry too much about dropping them, about getting a bit of water on one or that sort of thing. You can cart them around in a backpack with little worry, take them to the beach, and so on. As far as I can tell, Knuth's books are not available for, nor would appear like they do on paper. That's the golden standard for me: once "The Art of Computer Programming" looks good on an e-reader, it will be really and truly ready. We're not there yet. It's not general purpose. Like I said above, maybe this is good for reading, but there are also times when it'd be nice to have a general purpose device, with email, maps, applications, and so on. A while back, Amazon announced some sort of beta program for a kindle SDK. I haven't heard much of anything since. So it looks like it's not really possible to code for it, which is a bit disappointing. I like to have that option available, even if I don't always exercise it. Unknown: The pricing: sometimes Kindle versions are cheaper (especially, in my case, considering shipping, and, potentially, import duties), but sometimes they aren't, which seems a bit unfair, given that you cannot sell the book if you don't like it. I'm not sure how it would work out for me in the aggregate. Digital Rights Management, or DRM, means you can't, say, sell someone a "used" ebook. This is, in some ways, understandeable, because it's not like an e-book degrades with time as a physical one might. Were it possible to sell on your old books, that might radically change the market. I could see that having both good consequences (cheaper books), but also negative ones for authors (less money). I suppose this topic merits a post or two, or even an entire book of its own, because it's a complicated subject without, in my opinion, "easy" answers. Suffice it to say, though, that there are some drawbacks, but I suppose it's also nice that Amazon "knows" which books I have, so even if I switch to a different reader, I still have my books. And it's good that authors can get paid to work on a book. Not having actually bought it yet, I have no idea how it actually 'feels' to read a book with one. I love curling up with a good book, something I certainly can't do with my laptop. The Kindle looks light and small enough that it could work, but maybe it's just too high tech and sleek to provide that same comfortable coziness. Or maybe I'm just a luddite where books are concerned?
Do you have one? Do you use it? For all kinds of books or just certain kinds (technical books, cheap 'fun' reads, whatever...)? What's the experience like?

I use ratpoison as window manager on my ASUS EeePC netbook nemo for more than two years now. But although I m very happy with ratpoison in the EeePC, there are two feature wishes which have been refused by upstream: One is more flexibel window name matching for the unmanage command. The other one is focus follows mouse between ratpoison frames. Well, I always guessed that it was possible, but it took until now to find outhow to implement focus follows mouse for ratpoison. There s an ancient but still useful tool called Not a Window Manager (nawm) which is a small awk-like interpreter offering mostly window handling functions. The following .nawmrc implements focus follows mouse in nawm:

window newwin;  # stores window to raise
window lastwin; # stores previous window to prevent race conditions
leave  
    lastwin = currentwindow;
 
enter  
    newwin = pointerwindow();
    if (name(newwin) != "" && newwin != lastwin)  
        raise newwin;
        sync;
     
 

The leave hook is necessary to prevent flapping between two windows if switched between them via ratpoison s commands. I also had to add the following hook to my .ratpoisonrc to work around some cases where ratpoison s own window switching didn t work anymore. Only happened with more than one frame with one frame banishing the mouse cursor was annoying, so I filtered that case:

addhook switchwin exec if [  ratpoison -c fdump fgrep -o frame wc -l  -gt 1 ]; then ratpoison -c banish; fi

Unfortunately nawm has been removed from Debian Sid about a year ago due to being buggy and orphaned. There was not upstream development for seven years or so either. So for the moment you can get nawm either from Debian Lenny or from snapshot.debian.org. But I had to fix a segfault in nawm when calling name() on a window without name to be able to use it at all, so you will probably have to rebuild it anyway with the following patch:

diff -u nawm-0.0.20030130/builtins.c nawm-0.0.20030130-patched/builtins.c
--- nawm-0.0.20030130/builtins.c        2010-10-25 06:00:02.000000000 +0200
+++ nawm-0.0.20030130-patched/builtins.c        2010-10-25 04:15:25.000000000 +0200
@@ -546,8 +546,12 @@
     *name = gcstrdup("");
   else
      
-      *name = gcstrdup((char *)nm);
-      XFree(nm);
+      if ((char *)nm)  
+        *name = gcstrdup((char *)nm);
+        XFree(nm);
+        else  
+        *name = gcstrdup("");
+       
      
  

And yes, I m thinking about adopting and reintroducing the nawm package into Debian Sid. But I d prefer if anyone could give me a hint how to do this with more current and still maintained tools (or a patch against ratpoison :-). I looked into suckless-tools, but I haven t found anything in there which provides hooks on X events. And the Perl module Tk seems to be able to set X event hooks, but only within the application being written itself.

The phpMyAdmin thing on Flattr has been around already for some time. I just created it together with other my stuff and somehow did not find time to discuss it with other project members and push it to our website. Despite this fact it got some attention and even recommendations. Today, being pushed by Linus Olsson from Flattr (who just forwarded questions about authenticity of phpMyAdmin on Flattr), I finally find time to get an agreement from other project members and placed the button on phpMyAdmin's website. Let's see how popular it will become now :-).

Filed under: Phpmyadmin 0 comments

Sunday. A good day to take some time to myself, and get some much needed excercise. And the pseudo-meditation that comes with it: That's one of the factors I love the most about cycling. It's possibly my favorite way of just idling, of allowing for the time to pass without me noticing, just watching the movie of life, watching the world go around me with very little effort. I just love cycling. I have posted here several mentions of the Ciclot n: Every month, the last Sunday, our city government closes a ~32Km circuit to make it for cycling (and skating, and walking, and jogging, and other human-powered locomotion) use. Whenever I am in the city and have the possibility, I do the Ciclot n. Two months ago, I even did it twice in a row, for a total of almost 70Km. But this Sunday was not the last Sunday of the month! So, why am I writing this? Well, because when I left home today at ~10AM, I thought it was. Only when I reached Circuito Interior and had a this is full of cars moment, I remembered October has 31 days. And next Sunday I'll very probably be in Oaxaca city (for the Hackmitin 04h4ck4 2010). And I didn't want to miss the fun of a nice Sunday ride! I don't care if streets are closed just for bikes I am used to riding in traffic. Of course, this meant I would not take the central lanes in Circuito Interior on the way back, taking the ~10 bridges (which are quite tiring, to be honest!). It also meant I was free to make my own route. So, I thought, a nice small ~20-30Km ride will do. I'll just get to Eje 2 Sur or so, and back by another route (i.e. Plutarco E. Calles or so). But as I got closer to Reforma, I realized that every Sunday (independent of a Ciclot n), Reforma is closed for the "Paseos Dominicales" - Shorter than a Ciclot n, but still a nice way to share the streets with other cyclists. So I headed for Reforma. Part of Reforma (from the ngel roundabout westward) was closed due to a precisely cyclist race. But from there eastwards we had the street for us. Good, lets head downtown. The surprise came when I saw that it was not only towards downtown, but passing Av. Ju rez, Reforma continued to be closed just for cyclist use northwards. Great! Lets see how far does it go. The first surprise there: A couple of days ago, it was the "Noche de los Alebrijes". The alebrijes are a beautiful and very elaborated Mexican typical handicraft, depicting psychodelic dragons or dragonic representations of animals. Of course, alebrijes are usually ~30cm long... But here we had huge ones! And verrrry elaborated! How much so? You tell me. And as I started off... A nice thing about cycling is that you get to meditate. My body continued cycling, taking care not to run over the kids that are not so proficient, stoping at each red light... At some point, my mind entered back the body, and I realized we were passing by Tlatelolco (ok, to be honest, the picture was taken when crossing southwards, on my way back), about to cross Circuito Interior on the North, in that symbolically very strange place where Paseo de la Reforma (a long, beautiful avenue named after the war that marked the complete separation between church and Mexican state, in 1860) becomes two streets... Calzada de los Misterios and Calzada de Guadalupe. And, yes, it is among the greatest peregrination routes in the world. On December 12, the Holiday of the Guadalupe Virgin, up to 7 million people go visit her temple. And also around here, when my mind was busy inside my body, I noticed a pair from the Un paseo a ciegas (roughly translated, a blind ride) program was riding just by me. I knew about this program, but had never seen them before So I took the opportunity to get to know this program. Basically: Two people ride a tandem bike. The one in front, as always, drives and steers. The one in the back is a blind person, who gets the amazing sensation of freedom and enjoyment that only a bike gives you. Un paseo a ciegas is held every Sunday at 9AM except for the last Sunday every month. And I definitively want to be part of it! They told me the program has been adopted as well in Puebla, and if I recall correctly, it will soon be started in Quer taro and Guadalajara. Anyway, by then I realized the ride was probably going to reach the Bas lica, a very impressive church I had just visited for the first time ever a couple of weeks ago. And yes we went all the way up Guadalupe until the place where the street gets impossible to bike on, then left along a small street, and back to the South by Misterios. Then, all the way along Reforma again, saying goodbye to Cuitlahuac, Jos de San Mart n, Sim n Bol var, El Caballito, Cristobal Col n, Cuauhtemoc, La Palmera, El ngel... And back home. Of course, not without the sight of some bizarre signs we enjoy so much to find, point at and laugh. Have I ever told you, my nameless reader, that I love this city? I love getting surprised with so many great things. I love the distances I can safely ride on my bike without ever being far from a bike repair shop (which are only needed when they are far away). I love being surrounded by people breathing their freedom to take the streets. I love the safety of our wide, long streets (and no, I'm not joking here Mexico City is among the safest places for cyclists I have been to). I love its weather, that allows me to go out and enjoy the street at any time of year. And I love biking in it, one of the best ways to get to know so many bits of the city I would have never ventured into otherwise.

Kanzepharaz of the one thousand and eight spires. Kanzepharaz capital of the Empire of K'thorv and since the succesful end to the war that led to the annihilation of the Pleiadic Oligarchy in K'threl, the richest and most splendid city in the Middle World. Kanzepheraz whose real estate prices have soared e'en beyond the calculation of the rainbow abacus of Thobis Himself. Anathomelis, a princeling of the Imperial Clan needs a location for his new and expanded orgy dome. Yet the only available and affordable on a seventh rank civil allowance place left in the city of one thousand and eight spires is the tomb of Pharaz the First and Subsequent, lich-emperor of the Jerelite dynasty and his eldritch retainers. Before the construction-serfs can move in, the tomb must be cleared of its unshriven and non-rent-paying denizens. As His Principalities' chief swordbearer it has fallen to you to make the tomb of Pharaz safe for gentrification. Treasures and honors await you if you succeed. Aeons of torment in the Planes of Unlife await you if you fail. WILL YOU RISE TO THE CHALLENGE? rec.games.roguelike.development is having another challenge, this time to complete a roguelike game in four days. My previous attempt to write one in seven days was a failure but as I can build upon my previous work, I think I can make it this time. This time I did not waste lots of time thinking of a name. S.Y.T.Y.C.D...OMG? and The Real Housewives of Mordor were the only ones under serious consideration. With that crucial task out of the way, I spent the morning ripping code out of A.L.F. wherever possible. In the afternoon, I looked into dungeon generation. My previous experiments with this sort of thing were pretty convoluted but now I think I have a simpler algorithm which still provides a random yet plausible-looking map. It basically goes like this:

1. Divide the map into a grid of sectors.As the S.Y.T.Y.C.D...OMG? map is 60 80, my sectors are 20 16 giving 3 5 grid.
2. Mark each space on the map as impassable.
3. In each sector, pick a random square as its "center" not too near the edge of the sector.
4. Join each pair of centers first W -> E and then N -> S. with passable spaces. These will be the corridors and doing it this way ensures all sectors will be connected. Last time, my mistake was making rooms first and then corridors which is much more complicated to get right.
5. For each sector, there is a 2/3 chance it contains a room. If there is, randomly a number of spaces to each side of the center square. These will be the dimensions of the room. Make all the spaces in the resulting rectangle passable.
6. Randomly take a quarter chunk out of some rooms making them "L" shaped for a bit of variety. (at some point I can add round, polygonal or other shapes.)
7. Create "walls" by making all the outer boundary spaces of the room impassable again. This also ensures rooms do not touch or overlap.
8. If a wall meets a corridor, turn it into a "door." Doors don't do anything yet but eventually will be locked, trapped etc.
9. Finally, place monsters, treasure, and items in the room.

Two weeks ago, nekohayo posted a blog entry on Recipe Manager, a (you guessed it) cooking recipe manager for GNOME. Looking good, I fetched the bzr tree from Launchpad and played a bit with it, and soon discovered it had no internationalisation support. I've tried to add i18n properly, but I've not had enough time to do it. Before tackling that, the authors need to give it some bootstrapping love so the app can actually install, look for its files in /usr/share, etc. My fugly, unpostable current patch does allow for a preview of how Recipe Manager will teach the world about the best rice dish ever, arr s a banda. Yum!

Recipe Manager, showing off the zenith of Valencian culture

I brought my cat Leo to the house in the hollow a week ago. He settled in quickly; this was his 7th move. He seems both more kittenish, and more predatory out here. This was a trial run, I'll bring him back to town soon for a few weeks. Since early August, I've for one reason and another been away every other week, and I got tired of worrying about the cat home alone. With a cat, and with electricity seemingly sorted, it's getting homelike here. As the days shorten, I'm being power wasteful with computers and radio and lights, and the batteries still never drop below 13.5 volts. Bodes well for winter. All that remains to be done is refrigeration that does not involve hauling ice, and more water. Winter will help with both. Still remains to be seen if I will continue bouncing back and forth, or if there will be an inflection point. I've regained a tranquility that had been eluding me for ages. It's been a lot of work, but it seems worth it. (git-annex announcement soon!)

Dear Gnome people. Is there a reliable way to right-attach panel applets? May laptop screen and my external monitor have different resolutions, and I havn't found a reliable way (except making two panels) of getting some of my applets to stick to the right. I usually keep my launchers on the left, while vairous system status icons on the right part. But when switching to a higher resolution, at most one will move to the right end of the panel at the new resolition, while the others just stay in place (i.e. left-attached at a given pixel position). There are so many smart layout managers, GTK pretty much always uses flexible layout managers, why is the Gnome panel relying pixel offsets? It has been suggested to me a couple of times that I could achieve this via gconf. However, since the gconf changes are not reflected at runtime but frequently overwritten I did not get this to work reliably even just for two applets. Thank you. If you have any comments, please email me via erich () debian org. On a side note, this is also the first true post to my new blog. :-)

While I have spent countless hours working on the new source format known as 3.0 (quilt) , I ve just realized that I have never blogged about its features and the reasons that lead me to work on it. Let s fix this. The good old 1.0 format Up to 2008, dpkg-source was only able to cope with a single source format (now named 1.0 ). That format was used since the inception of the project. While it worked fine for most cases, it suffered from a number of limitations mainly because it stored the Debian packaging files as a patch to apply on top of the upstream source tarball. This patch can have two functions: creating the required files in the debian sub-directory and applying changes to the upstream sources. Over time, if the maintainer made several modifications to the upstream source code, they would end up entangled (and undocumented) in this single patch. In order to solve this problem, patch systems were created (dpatch, quilt, simple-patchsys, dbs, ) and many maintainers started using them. Each implementation is slightly different but the basic principle is always the same: store the upstream changes as multiple patches in the debian/patches/ directory and apply them at build-time (and remove them during cleanup). Design goals for the new formats When I started working on the new source package format, I set out to get rid of all the known limitations and to integrate a patch system in dpkg-source. I wanted to clear up the situation so that learning packaging only requires to learn one patch system and would not require modifying debian/rules to use it. I picked quilt because it was popular, came with a large set of features, and was not suffering from NIH syndrome. This lead to the 3.0 (quilt) source format. I also created 3.0 (native) as a distinct format. 1.0 was able to generate two types of source packages (native and non-native) but I did not want to continue with this mistake of mixing both in a single format. The KISS principle dictated that the user should pick the format of his choice, put it in debian/source/format and be done with it. Now the build can rightfully fail when the requirements are not met instead of doing something unexpected as a fallback. Features of 3.0 (quilt) This is the format that replaces the non-native variant of the 1.0 source format. The features below are specific to the new format and differentiate it from its ancestor:

• Supports compression formats other than gzip: bzip2, lzma, xz.
• Can use multiple upstream tarballs.
• Can include binary files in the debian packaging.
• Automatically replaces the debian directory present in the upstream tarball (no repacking required).
• Creates a new quilt-managed patch in debian/patches/ when it finds changes to the upstream files.

Features of 3.0 (native) This format is very similar to the native variant of the 1.0 source format except for two things:

• it supports compression formats other than gzip: bzip2, lzma, xz.
• it excludes by default a bunch of files that should usually not be part of the tarball (VCS specific files, vim backup files, etc.)

Timeline Looking back at the history is interesting. This project already spans multiple years and is not really over until a majority of packages have switched to the new formats.

• January 2008: the discussion how to cope with patches sanely rages on debian-devel@lists.debian.org. My initial decisions are the result of this discussion.
• March 2008: I have implemented the new formats and I request feedback. dpkg 1.14.17 (uploaded to experimental) is the first release supporting them.
• April 2008: I ask ftpmasters to support the new source packages in #457345.
• June 2008: Lenny freeze. dpkg is not supposed to change anymore. Several changes concerning the new source formats are still accepted in the following months given that this code is not yet used in production and must only be present so that lenny can cope with new source packages once squeeze starts using them.
• February 2009: Lenny release.
• March 2009: Work on squeeze has started, ftpmasters have done nothing to support new source formats, I submit a patch in #457345 to speed things up. I start a wiki page to track the project s progress and to answer common questions of maintainers.
• November 2009: After an ftpmaster sprint, it s now possible to upload new source packages in unstable. This draws massive attention to the new format and some people start complaining about some design decisions. The implementation of 3.0 (quilt) changes a lot during this month. dpkg in lenny is even updated to keep up with those changes.
• March 2010: Up to now, I was planning to let dpkg-source build new source packages by default at some point in the future. After several rounds of discussions, I agree that it s not the best course of action and decides instead to make debian/source/format mandatory. The maintainer must be explicit about the source format that s/he wants to use.
• October 2010: The new source formats are relatively popular, a third of the source packages have already switched: see the graph. The squeeze freeze in August clearly stopped the trend, hopefully it will continue once squeeze is released.
• June 2013: Project is finished?

As you can see this project is not over yet, although the most difficult part is already behind me. For my part, the biggest lesson is that you won t ever get enough review until your work is used within unstable. So if you have a Debian project that impacts a lot of people, make sure to organize an official review process from the start. And specifying your project through a Debian Enhancement Proposal is probably the best way to achieve this. If you appreciate the work that I put into this project, feel free to join Flattr and to flattr dpkg from time to time. Or check out my page Support my work .

12 comments Support my work

For some time now, we ve been gearing up to begin development on Ubuntu 11.04. While some folks have been putting the finishing touches on the 10.10 release, and bootstrapping the infrastructure for 11.04, others have been meeting with Canonical stakeholders, coordinating community brainstorm sessions, and otherwise collecting information about what our priorities should be in the next cycle. We re using what we ve learned to plan the Ubuntu Developer Summit next week in Orlando, where we ll refine these ideas into a plan for the cycle. We re organizing UDS a little bit differently this time, with the main program divided into the following tracks to reflect the key considerations for Ubuntu today:

• Application Developers Making it faster, easier, and more enjoyable to develop and distribute new applications on (and for) Ubuntu
• Cloud Delivering the best experience of cloud computing, whether hosting in a public cloud or building your own private cloud
• Hardware Compatibility Measuring and improving compatibility with a wide range of laptops, netbooks, servers and desktops
• Multimedia Formulating the best software stacks for graphics, audio and video in Ubuntu
• Package Selection and System Defaults Choosing the right components to keep Ubuntu lean, flexible and ready-to-run, while ensuring that the pieces fit and work together cleanly
• Performance Squeezing the best performance out of today s free software stack, from the Linux kernel and GNU toolchain through user interfaces
• Ubuntu the Project Continuously improving the way we work together to produce Ubuntu, both within the project and with our upstream and downstream partners

You can click on the links above for a preview of the schedule for the week, with links to more detailed blueprints which will develop during and following UDS. If you ll be joining us in person, then I ll see you there! If not, be sure to review Laura s guide on how to participate remotely.

After getting a flood of spam, I became suspicious that there was an exploit in my blog software allowing easy robo-posts. Despite a code audit I couldn't see anything, and thus wanted to log the incoming POST requests before any local processing at all. It took me a while to figure out how to do this, hopefully this helps someone else. Firstly install libapache-mod-security, then the magic incarnation is So, to break it down a little, the default action says to do nothing during phase 2 (when the body is available for inspection); the allow means that we're indicating that nothing further will happen in any of the remaining phases, so the module can shortcut through them. The two SecRules work together -- the first says that any POST requests should be tested by the next rule (i.e. the chained rule), which in this case says that any request should be sent to the audit log. After that, the similar allow/phase argument again says that nothing further is going to happen in any of the subsequent phases mod_security can work on. As per the parts between A and Z, we'll log the headers, the request body, the final response and trailer. So, as it turns out, there is no exploit; it seems most likely there is an actual human behind the spam that gets through, because every time they take a guess it is correct. So I guess I'll take a glass-half-full kind of approach and rather than being annoyed at removing the spam, I'll just convince myself that I made a small donation from some spam overlord to one of their poor minions!

I recently uploaded new upstream versions of two neat small X tools to Debian Experimental:

• xrootconsole displays on a transparent or shaded layer on the root window what it gets as input on STDIN, from a FIFO or from a file, and
• keynav, a way to control your mouse cursor efficiently with the keyboard.

Both packages introduce several new features and I d be happy if users of these packages in Debian Sid or Debian Sid users curious about them could test the versions in Debian Experimental. xrootconsole 0.6 + patches xrootconsole saw no love since 2006 with the last maintainer upload having been in 2002. Nevertheless it never got kicked out of Debian just because of this. The package had been forcibly orphaned just less than a year ago. So it s no big wonder that this new upstream version I packaged was released already back in 2004. :-) But besides packaging a new upstream version, bumping Standards-Version and debhelper compatibility, fixing tons of lintian warnings and some bugs, I also added two patches which add new features not (yet) available upstream:

• UTF-8 support: Upstream xrootconsole just drops all bytes where the 8th bit is set which only allows ASCII. Miroslav Jezbera submitted a patch to allow at least displaying localized text containing single byte 8 bit characters as used in all ISO-Latin encodings. Inspired by the patch to add UTF-8 support to ratmenu, I wrote a patch to add UTF-8 support for xrootconsole, too.
• ANSI color support: Last year, Julien Viard de Galbert, who is also active in Debian, posted a patch in his blog to support ANSI colors as produced by many log colorizers like e.g. loco (RIP), colortail, lwatch, or ccze. (Didn t get colortail and lwatch to work with xrootconsole yet, though.) I included this patch and made it compatible with my UTF-8 support patch. The patch raises the memory consumption per displayed character by one byte, but effectively I just saw an overall memory usage increase of about 25% which seems acceptable.

Of course I informed upstream about these feature patches, but I haven t got any feedback yet. But I got feedback from Julien Viard de Galbert, and he ll join me in packaging xrootconsole as co-maintainer. keynav 0.20101014.3067 I adopted the Debian package of keynav recently, subscribed to the keynav mailing list (well, it s a Google group), got a nice welcome mail from the very friendly upstream developer Jordan Sissel who offered to help with any keynav issues. I told him what features I d like to see in keynav to fit better the setup where I m using it. And just a few days later there was a new upstream release including both features I suggested, some more neat new features, and one bug fix. Jordan Sissel writes in the upstream changelog (emphasis and italic text by me):

• Added restart command. Makes keynav restart. Useful for binding a key to reload the config.
• Added loadconfig command. This lets you include additional config files to load on the command line or in one of the default keynavrc files. (requested by Axel Beckert) and already in use here.
• keynav will now restart if it receives SIGHUP or SIGUSR1
• Map Enter by default to warp,click 1,end (requested by Axel Beckert)
• Fix a bug causing the point under the mouse cursor to not click through the keynav window in certain conditions. Reported via mailing list by Eric Van Dewoestine and Krister Svanlund.

Both packages will be reuploaded to Debian Sid (Unstable) after the release of Debian Squeeze (currently testing ).

Debian NYC will be holding a workshop next week: What's in a Package? will happen at 7:00pm New York time on October 27, 2010. If you're in the New York area, interested in packaging things for debian and related systems, or just want to understand the packages in your system better, you should RSVP and come on out! This workshop will provide advanced theory useful for people modifying or creating packages. For people modifying packages, you'll learn many typical motifs and about various build systems. For creating packages, you'll be much better prepared to read and understand guides a deep level. However, this is still not a step-by-step guide in "how to build packages", but will get you very close to there. See you there!