J rg is a very active contributor within Debian, and has been for a long time. This explains why he holds so many roles (FTPmaster and Debian Account Manager being the 2 most important ones) Better known as Ganneff (his IRC nick), he s not exactly the typical hacker. He has no beard and used to drink milk instead of beers. Check out his interview to learn more about some of the numerous ways one can get involved in Debian, managing its infrastructure and without having to be a packager. Raphael: Who are you? J rg: My name is J rg Jaspert and I m 35 years old working for a small company doing system administration and consulting work for our customers. I m married for a little while now and sometime soon a little Ganneff will be crawling out of my wife. (Whoever didn t think of the movie Alien now is just boring). Raphael: How did you start contributing to Debian? J rg: I started using Debian somewhere around 2000, 2001. Before that I had the misfortune to try SuSE and RedHat, both with a user experience that let me fully understand why people think Linux is unusable. (Due to my work I m in the unfortunate situation to have to use RedHat on two machines. Funny how they are still utter crap and worse than bad toys). And all of this lets get a Linux running here came up because I was trying to find a replacement for my beloved OS/2 installation, which I had for some years. So after I got Debian installed, good old Potato, I got myself active on our mailing lists, starting with the German user one. A bit later I replied to a question if someone can help as staff for a Debian booth somewhere. It was the most boring event I ever visited (very nice orga, unfortunately no visitors), but I got a few important things there:

• a signature from a DD on my key (Hi grisu),
• a discussion with an upstream author with some useful piece of software to package and
• an impression that this can be fun, if there are just some visitors for an event. So I tried again and did help as staff on a LinuxTag booth a while later.

The software I packaged, found me a sponsor and voila, maintainer I was. Some more packages got added and at some point my sponsor turned out to be my advocate. The NM process run around 2 months, and mid April 2002 I got THE MAIL. Raphael: Some Debian developers believe that you have too many responsibilities within Debian (DAM, FTPMaster, Debconf, Partners, Planet Debian, Mirrors, ). Do you agree that it can be problematic, and if yes, are you trying to scale down? J rg: It s DebConf, tssk. And yes, I do have some extra groups and roles. And you even only list some, leaving out all I do outside Debian. But simply counting number of roles is a plain stupid way to go. Way more interesting is how much work is behind a role and how many other people are involved. And looking at those you listed I don t see any I am a SPOF. Let s look at those you listed: DAM: Here I did start out assisting James to get the huge backload down which had accumulated over time. Nowadays I am merely the one with the longest term as DAM. Christoph Berg joined in April 2008 and Enrico Zini followed during October 2010, both very active. Especially Enrico, lately with the redesign of the NM webpages. FTPMaster: The basic outline of the FTPMaster history is similar to the DAM one. I joined as an assistant, after the oh-so-famous Vancouver meeting in 2004. Together with Jeroen, we both then got the backload down which had accumulated there. He did most of the removals while I had a fun time cleaning up NEW. And we both prepared patches for the codebase. And in 2007, as the last action as DPL, Sam made me FTPMaster. Since then I haven t been alone either. In fact we have much more rotation in the team than ever before, which is a good thing. Today we are 3 FTPMasters, 4 FTP Assistants and 1 Trainee. Though we always like new blood and would welcome more volunteers. DebConf: I am very far outside the central DebConf team. I am not even a delegate here. Currently I am merely an admin, though there are 4 others with the same rights on the DebConf machines. I ve not taken any extra jobs this year, nor will I. Probably for next year again, but not 2012. Planet: I am one of three again, but then Planet is mostly running itself. Debian developers can just edit the config, cron is doing the work, not much needed here. Occasional cleanups, every now and then a mail to answer, done. In short: No real workload attached. Mirrors: My main part here is the ftpsync scriptset. Which is a small part of the actual work. The majority of it, like checking mirrors, getting them to fix errors, etc. is done by Simon Paillard (and since some time, Raphael Geissert is active there too, you might have heard about his http.debian.net). Having said that, there is stuff I could have handled better or probably faster. There always is. Right now I have 2 outstanding things I want to do a (last) cleanup on and then give away. Raphael: You got married last year. I know by experience that entertaining a relationship and/or a family takes time. How do you manage to combine this with your Debian involvement? J rg: Oh well, I first met my wife at the International Conference on OpenSource 2009 in Taiwan. So OpenSource, Debian and me being some tiny wheel in the system wasn t entirely news to her. And in the time since then she learned that there is much more behind when you are in a community like Debian, instead of just doing it for work. Even better that she met Debian people multiple times already, and knows with who I am quarreling Also, she is currently attending a language school having lots of homework in the evening. Gives me time for Debian stuff. How that turns out with the baby I have no idea yet. I do want to train it to like pressing the M key, so little-Ganneff can deal with NEW all on its own (M being Manual reject), but it might take a day or twenty before it gets so far. Raphael: Thanks to the continuous work of many new volunteers, the NEW queue is no longer a bottleneck. What are the next challenges for the FTPmaster team? J rg: Bad link, try this one. Also, no longer sounds like its recent. It s not, it s just that people usually recognize the negative only and not the positive parts. Well, there are a few challenges actually. The first one, even if it sounds simple, is an ongoing one: We need Debian Developers willing to do the work that is hidden behind those simple graphs. Yes, we are currently having a great FTP Team doing a splendid work in keeping that queue reasonably small this is a/THE sisyphean task per excellence. There will always be something waiting for NEW, even if you just cleaned the queue, you turn around and there is something else back in already. Spreading this workload to more people helps not burning one out. So if one or more of the readers is interested, we always like new volunteers. You simply need to be an uploading DD and have a bit of free time. For the rest we do have training procedures in place. Another one is getting the multi-archive stuff done. The goal is to end up with ONE host for all our archives. One dak installation. But separate overrides, trees, mirrors, policies and people (think RMs, backports team, security team). While this is halfway easy to think of in terms of merging backports into main it gets an interesting side note when you think of merging security into main . The security archive does have information that is limited to few people before public release of a security announce, and so we must make sure our database isn t leaking information. Or our filesystem layer handling. Or logs. Etc. Especially as the database is synced in (near) realtime to a DD accessible machine. And the filesystem data too, just a little less often. There is also a discussion about a good way to setup a PPA for Debian service. We do have a very far developed proposal here how it should work, and I really should do the finishing touches and get it to the public. Might even get a GSoC project on it. So far for some short to middle term goals. If you want to go really long term, I do think that we should get to the point where we get rid of the classical view of a source package being one (or more) tarballs plus the Debian changes. Where a new version requires the full upload of one or more of those parts of the source package. I don t know exactly where it should end up. Sure, stuff like one central DVCS, maintainers push there, the archive generates the source tarballs and prepares the mirrors do sound good for a quick glance. But there are lots of trouble and pitfalls and probably some dragons hidden here. Raphael: The Debian repositories are managed by DAK (Debian Archive Kit) which is not packaged. Thus Debian users pick tools like reprepro to manage their package repositories. Is that how things should be? J rg: Oh, Mark Hymers wants to do a package again. More power to him if he does, though yes, DAK is not exactly a quick-and-easy thing to install. But nowadays it is a trillion times easier than the past thanks to Mark s work people can now follow the instructions, scripts and whatever they find inside the setup directory. Still, it really depends on the archive size you are managing. A complex tool like dak does not make sense for someone who wants to publish one or a dozen of his own packages somewhere. Thats just like doing a finger amputation with a chainsaw it certainly works and is fun for the one with the chainsaw but you probably end up a little overdoing it. I myself am using dpkg-scan[packages sources] from a shell script but also mini-dinstall in places (never got friend with reprepro when I looked at it). Works, and for the few dozen packages those places manage it is more than enough. Also, using dak forces you into some ways of behaviour that are just what Debian wants but might not be what a user wants. Like inability to overwrite an existing file. One of the reasons why mentors.debian.net won t work with dak. Or the use of a postgres database. Or that of gpg. Sure, if you end up having more than just a dozen packages, if you have many suites and also movement between them, then dak is sure a thing to look at. And how should things be : however the user and admins of that certain install of reprepro, mini-dinstall, dak, whatever want it. This is not one-tool-for-all land Raphael: What is the role of Debian Account Managers (DAM)? Do you believe that DAMs have a responsibility to shape Debian by defining limits in terms of who can join and what can be done within Debian? J rg: Quote from https://lists.debian.org/debian-devel-announce/2010/10/msg00010.html:

The Debian Account Managers (DAM) are responsible for maintaining the list of members of the Debian Project, also known as Debian Developers. DAMs are authoritative in deciding who is a member of the Debian Project and can take subsequent actions such as approving and expelling Project members.

Now, aside from this quote, my OWN PERSONAL OPINION, without wearing anything even vaguely resembling a DAM hat: DAM is the one post that is entitled to decide who is a member or not. Usually that is in the way of joining (or not), which is simple enough. But every now and then this also means acting on a request to do something about whatever behaviour of a Debian Project member. I hate that (and i think one can easily replace I with WE there). But it s our job. We usually aren t quick about it. And we don t act on our own initiative when we do, we always have (numerous) other DDs complain/appeal/talk/whatever to us first. The expulsion procedure , luckily not invoked that often, does guarantee a slow process and lots of input from others. Are we the best for it? Probably not, we are just some people out of a thousand who happen to have a very similar hobby Debian. We aren t trained in dealing with the situations that can come up. But we are THE role inside Debian that is empowered to make such decisions, so naturally it ends up with us. Raphael: You did a lot of things for Debian over the years. What did bring you the most joy? Are there things that you re still bitter about? J rg: The most joy? Hrm, without being involved in Debian and SPI I would never have met my wife.
Or my current job. Or a GR against me. Not many running around with that badge, though I m still missing my own personal Serious problems with Mr. Jaspert thread. Bad you all.
Or visited so many places. Think of all the DebConfs, QA meetings, BSPs and whatever events.
Or met so many people.
Or learned so many things I would never even have come near without being DD. Raphael: Is there someone in Debian that you admire for their contributions? J rg: Yes.

---

Thank you to J rg for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

One comment Liked this article? Click here. My blog is Flattr-enabled.

Sometime the network you re connected to is either untrusted (e.g. wireless) or castrated in some way. In both cases you want a tunnel to your trusted home base. Following I ll show you three completely different tunneling tools which may helpful while travelling. sshuttle sshuttle is a tool somewhere in between of automatic port forward and VPN. It tunnels arbitrary TCP connections and DNS through an SSH tunnel without requiring root access on the remote end of the SSH connection. So it s perfect for redirecting most of your traffic through an SSH tunnel to your favourite SSH server, e.g. to ensure your local privacy when you are online via a public, unencrypted WLAN (i.e. easy to sniff for everyone). It runs on Linux and MacOS X and only needs a Python interpreter on the remote side. Requires root access (usually via sudo) on the client side, though. It s currently available at least in Debian Unstable and Testing (Wheezy) as well as in Ubuntu since 11.04 Natty. Miredo Miredo is an free and open-source implementation of Microsoft s NAT-traversing Teredo IPv6 tunneling protocol for at least Linux, FreeBSD, NetBSD and MacOS X. Miredo includes not only a Teredo client but also a Teredo server implementation. The developer of Miredo also runs a public Miredo server, so you don t even need to install a server somewhere. If you run Debian or Ubuntu you just need to do apt-get install miredo as root and you have IPv6 connectivity. It s that easy. So it s perfect to get a dynamic IPv6 tunnel for your laptop or mobile phone independently where you are and without the need to register any IPv6 tunnel or configure the Miredo client. I usually use Miredo on my netbooks to be able to access my boxes at home (which are behind an IPv4 NAT router which is also an SixXS IPv6 tunnel endpoint) from whereever I am. iodine iodine is likely the most undermining tool in this set. It tunnels IPv4 over DNS, allowing you to make arbitrary network connections if you are on a network where nothing but DNS requests is allowed (i.e. only DNS packets reach the internet). This is often the case on wireless LANs with landing page. They redirect all web traffic to the landing page. But the network s routers try to avoid poisoning the client s DNS cache with different DNS replies as they would get after the user is logged in. So DNS packets usually pass even the local network s DNS servers unchanged, just TCP and other UDP packets are redirected until logging in. With an iodine tunnel, it is possible get a network connection to the outside on such a network anyway. On startup iodine tries to automatically find the best parameters (MTU, request type, etc.) for the current environmenent. However that may fail if any DNS server in between imposes DNS request rate limits. To be able to start such a tunnel you need to set up an iodine daemon somewhere on the internet. Choose a server which is not already a DNS server. iodine is available in many distributions, e.g. in Debian and in Ubuntu.

Svalbard The things you find when cleaning out a disk; preparing for re-installation of your laptop on a larger disk once the laptop comes back from repair... I thought I had posted this in early January, but apparently not. As it would be a shame to just throw this away, here goes: I am sitting in the Oslo airport, waiting for boarding back home to start. Seeing the sun after a week of darkness still feels strange. Inital trouble It's been a very interesting week, starting with our trip to Oslo in the other direction. We spent New Year's Eve in Oslo, timing our forced overnight stay before reaching Svalbard to coincide with something interesting. The close timing of our travel meant that there was exactly one flight to Oslo we could take. Never having heard of Air Baltic before and finding out that they are a discount airline, my gut feeling told me to be be wary. I refuse to fly with those airlines on principle, not wanting to support their business model while hurting airlines with decent treatment of customers. Unfortunately, I was forced to book with them in this case. As it turns out, my gut was right. More on that below. Our plane was late in landing and my luggage was lost. As it was New Year's Eve, the staff at Oslo airport understandably wanted to be home, not at work. Still, getting them to file a report was tedious and finding out days later that the report was incomplete was, well, not good. The express train from the airport to Oslo central station had closed early without any advance notice or local signs, presumably because of NYE. The gates were simply closed and that's that. We figured out how the bus system worked, got our tickets from a vending machine, saw the one bus to central station drive away, and proceeded to wait in the outside waiting area; at least we had a front spot in the queue. While we don't get cold easily, it was funny to see Norwegians in thin clothes stand around in the biting wind, apparently being comfortable. A young mother with a baby, who didn't anticipate being forced to wait outside at -15C, as opposed to just sitting down in a train, had no warm clothes for her son; something that was fixed by wrapping him in spare clothes from Ilona's luggage. After waiting for about thirty minutes for the next bus to appear, it parked twenty or thirty meters away from the designated parking spot. The rough queue disintegrated and if not for Ilona's leaving me with luggage and backpacks and storming off to fight the masses, said mother with baby and ourselves would have waited for another thirty minutes. More than hundred people were left stranded at the airport to celebrate there or on the bus. Meh. We hurried, by taxi, from central station to hotel to harbour and arrived about five minutes to twelve. NYE itself was nice. We stood on top of the opera house and watched a rather impressive show of fireworks through the thickening mists. Norwegian fireworks pack lot more punch than German ones; you actually feel your clothes shake when they go off. Getting to Longyearbyen The flight from Troms to Longyearbyen had free in-flight Wi-Fi and flying over the edge of satellite coverage demonstrated how far we were from everywhere else rather impressively. Arriving at Longyearbyen, I fixed the lost luggage claim with the help of an extremely nice woman working at the airport. She confirmed that Air Baltic is legally required to reimburse me after an arcane system based on a virtual IMF currency to the tune of about 1.500. That may sound like a lot, but seeing as I had most of my scuba gear with me, that's not even half of what my luggage was worth. I was forced to get by New Years with what I had on my body and went shopping the next day when I could buy at least a few things. I got by with spending about 180 by going for non-fitting bargain bin clothes, wanting to reduce impact on Air Baltic. Shortly after that, my luggage arrived, unannounced. Air Baltic refused to reimburse me even though they are legally required to, again the airport staff confirmed this. But unless I sue in the country of destination, Norway, I won't see any money. Long story short: Avoid Air Baltic if possible. They will break the law to cheat you out of money when they have a reasonable expectation of getting away with it. Update: Yep, seems they got away with it unless I take legal measures. You have been warned. Longyearbyen itself was very nice. We started off with a short, guided taxi tour around the city, seeing literally everything of it as there's not a lot of Longyearbyen to start with. Dogsledding Next day, as noted earlier, we went shopping and spent the "evening" with dogsledding which turned out to be tons of fun. We helped with harnessing the dogs which is somewhat cumbersome as the dogs are so eager to burn off their energy that they want to run all over the place, not being put into a harness and snapped onto the pull-line. Never having been dogsledding before I was a bit wary, but riding over not too rough terrain is almost trivial once you get the hang of it; listen to what the musher in front of you yells and emulate the same shouts with your own dogs. If the dogs become too fast, step onto the brake pad which simply drives spikes into the snow. If the dogs slow down while going uphill, skate with one foot to help them. That's it for speed. As the dogs are following the musher's sled anyway, steering the dogs was not a concern. Fun fact: The musher used a laser pointer to steer his dogs; simple, efficient, and presumably fun. We learned, by demonstration, that sledding dogs can eat snow, take a leak, and take a dump while running at full speed and pretty much all at the same time. The dogs are left either in cages or on long chains far away from the city as they tend to bark and howl a lot. We were surprised to learn that, even when there are seals left to hang dry as dog food nearby, there are no problems with bear attacks. Apparently even the extremely aggressive and hungry one year old males will not go near dogs. Still, while out in the ice and snow, our guide carefully flooded all crevices and cliff bases to root out female bears with young ones early. They hide their children from the wind and they will attack, dogs and all, if we get too close. That's why our musher carried rifle in his sled and flare gun on his body. Snowmobile The next "morning", we drove around by snowmobile. This turned out to be extremely boring as it was a curated trip with over half a dozen snowmobiles in our group; a stark contrast to our two-sled tour the day before. The last time I went snowmobiling, we raced each other up and down a two-star black (i.e. steep, bumpy, and curvy) ski slope, jumping several meters when racing over larger bumps and crossing streets, so riding single file at 30 km/h was... anticlimatic. Again, the guide had rifle and flare gun with him. We spent the afternoon and evening walking around the city. Ice bears, part I As the ice caves and the glacier were still closed, we decided to have another walk around the city. Having planned make it a quick tour, we lost track of time due to lack of sun and ended up walking around for seven hours. A note about that trip.. If you are alone with your wife, unarmed, climbing up a very steep and slippery mountainside over a sheet of ice with deep snow underneath and loose rocks in between, and then start shining around with your flashlight under the stilts of an abandoned mine that looks like in a horror movie, the correct answer to "What are you doing?" is never ever "Looking for ice bears". Even if it's the truth, this is not an acceptable answer. I crawled up the last part on all fours, camera and tripod in hand while Ilona stayed about two dozen meters below the mines' entrance, refusing to go another step towards the mine. As soon I made it up the creaky and shaky, for a lack of a better word, let's call it ladder, she forced me to come down again. Bleh, but I guess I deserved that. Armed photographer Next day, we got final confirmation that we would not be allowed to rent snowmobiles to explore the hinterland on our own and that other for some, and I quote, "crazy Russians", no one would even attempt to cross over to Barentsburg. Thus, we ended up renting a car for the ~20 kilometers of total road length. That turned out to be a great idea as it allowed us to get away from the light and take some very nice long exposures. It was then that I got a rental rifle, as well. There is a law against leaving the town unarmed and I was not about to test my luck too much. Turns out that, as part of Germany's WWII reparations, Norway received our all hand guns and as they still function perfectly when dirty and in cold climate which makes them still popular in Svalbard, today. The Karabiner 98 Kurz which I received is built incredibly well. It's somewhat scary inasmuch every detail is designed to make this weapon ready to fire. If you hurry or are inexperienced, you will end up with an unlocked and loaded rifle after putting in the bolt. Putting the safety in and not chambering a bullet takes conscious effort and knowledge of the weapon. This is in stark contrast to other weapons I had the chance to dissect, which all defaulted to being safe. Even other military weapons such as the AK74 and the M4A1 are inherently more secure, designed to be locked and safe. The Mauser K98... not so much. As an aside, they didn't bother to remove the Reichsadler and Swastika from the rifle, contending themselves with striking out the German registration number and stamping the rifle with a Norwegian one. I guess Norwegians don't really "care" about these signs as much as we Germans do. In a way, that's a good thing I guess, at least as long as it's an indication of indifference towards the sign, not one of forgetting or ignoring the underlying issues. Still, I was very glad to have rented the rifle. While Ilona tended to stay in the running car with heat and lights on, I went out and away from the car. Even when standing near a street, a medium snow storm will make you appreciate the four powerful arguments against being eaten by a random bear which are at the ready over your shoulder. We even went to the shooting range so I could get some practice. The procedure is very trusting, as is anything in Longyearbyen. After accessing the interior of one of the houses in a particular way which I won't specify here, you simply switch on the floodlights, put up the red flag, position a target and write your name into the guest book. Once you're done shooting, toss a few coins into the bowl next to the guest book, remove the targets and flag, turn off the lights, close the door and that's that. Unfortunately, the way in was under a few meters of snow so I couldn't get in any practice shots. Ice bears, part II Later, as I was standing on a wind-polished slate of ice taking pictures of the Seed Vault (located here), I heard an ice bear roar behind (i.e. to the north of) me. I consciously remember hearing the bear, I consciously remember facing the other way around, half-crouched, rifle raised in the direction of the roar. I also consciously remember smacking the safety off and chambering a bullet after having regained control of my body. I do not remember spinning around on a wind-polished slate of ice, so treacherous I hand to balance with my arms and didn't even lift my feet when walking over it, without losing balance or footing, nor do I remember crouching and raising the gun. Evolution really is amazing; no matter what primal chord that roar struck, it certainly saved a ton of people over the years. In my case, thankfully, there was no bear to be seen down the slope. There may be no sun or anything, but the snow reflects the starlight so you tend to see surprisingly far and as I was on on the mountainside and the roar came from down from the coast, and as I had my rifle, I decided to finish the photo session while keeping the slope in close view. In hindsight, I am still glad I decided to do that as the shots came out rather nice. Next day, we drove out to Mine 12, the farthest you can away from Longyearbyen. The dump truck transporting coal alternated between driving a full load of coal back to the city and being its own snowplow. One quick trip to get coal, one slow and empty trip to plow away snow, rinse, repeat. If not for that, our 4WD would never have made it all the way up to the mine. Neither snow storms in North America nor around the Alps prepared me for what people on Longyearbyen consider normal wind in their backyard. This is where the word wind-swept was invented. The main reason that Svalbard is inhabited at all, other than the Gulf Stream, is coal. We have been told that the coal up there is of extremely high quality and while I can't say much about that, I can say that it's hard as stone. This is nice as it does not smear when you get coal all over yourself. Just shake out your jacket and pants and you are good as new. On our way back, we met two locals who had just prepared the glacier and ice caves for tourists. Had I known that in advance, I would have tried to go with them to take pictures completely away from all artificial light. Oh well, can't have everything. Speaking of not being able to have everything, the outdoor hot tub in our hotel which integrated ice bar and BBQ grill was still under several meters of snow so we couldn't use that, either. Finally, the few divers who are in Longyearbyen didn't have time to take me onto a trip while I was there. As I already missed my opportunity to dive the Arctic circle when the one diver on Gr msey happened to be on the mainland and barely missing it by diving Str tan instead, this was kind of a bummer. On the plus side, this has given me a goal to pursue and achieve. Random notes For the rest of my notes, I will resort to a largely unsorted list of bullet points as there's just too much to talk about in prose.

• There are a lot of things in Norway that are similar to the Iceland (where we spent our honeymoon over June, experiencing permanent sunshine)
  • Norway uses Torx screws everywhere and for everything. This makes sense and I can't understand why Germany is lagging behind so severely.
  • There is free coffee everywhere.
  • The coffee is horrible.
  • Roads are built onto an artificial ridge, increasing wind speed. This ensures that sand, snow, and debris are always swept off the road and can't pile up too much.
  • As easy as it is to lose track of time when the sun is always up (in Iceland, we come down from a mountain after an extended walk at 01:30 in the morning and never realizing how late it was until we wanted to drive a few more kilometers), it's just as easy to lose track of time when it's always dark. We went for a "short" walk to take a few pictures and, on coming back to the hotel, realized that it had taken us seven hours.
  • You start to realize where sagas, trolls, little people and other folklore is coming from when exposed to raw nature. Especially once vision becomes bad and you see shadows dance in the snow (and sand, in Iceland's case) storm.
  • The concept of Common Land is pervasive. Just walk anywhere, no one cares.
  • No one has ever heard of OpenStreetMap, which is weird as people up there rely on GPS a lot.
• Locals tend to keep all lights on 24/7. I guess that's understandable.
• There is an eerie shine all over the land as the snow reflects and re-reflects the little light given off by the moon and stars.
• Almost all houses are built from wood. Drift-wood in the early days, imported wood today. The few concrete cause massive problems when the cold makes their floors and walls crack. Also, concrete is very hard to heat when it's sitting right on the perma-frost.
• Houses are not built on the ground, but on stilts. Drill a few holes into the ground, put long trunks into them, wait a few months for the perma-frost to freeze them into place and build your house on that. This insulates your house and gives you storage space below. Simple and efficient.
• Winter is so cold that people in Longyearbyen are forced to build water, sewage, and electricity infrastructure over ground, on stilts, and put in active heating. Else, it would burst or rupture.
• Our hotel had the taps running 24/7 as they already had a pipe burst a week before we arrived.
• The air is incredibly dry even though Longyearbyen is a coastal city. This is great as snow does not stick to anything, including clothes and camera lenses during long exposures against the wall in a snowstorm. Not so much when you suddenly realize that this means all rocks will be loose, scraping your shin open quite thoroughly.
• It's very hard to judge distances in permanent darkness; you will usually underestimate distances by a lot.
• This also means that you should not trust people when they tell you that Mine 2 is "not far away".
• Ice bear danger is real.
• Locals will not tell you about hiking trails unless you assure them that you are armed.
• Snow storms are amazing, impressive, and frightening. They will also make distances appear a lot farther, all of a sudden.
• While Longyearbyen does not have any sales or alcohol taxes and alcohol is still more expensive than in Germany.
• Stating that you won't drink before the sun goes down is a neat trick.
• Coldness and dryness mean your lips will burst open within seconds after holding a flashlight in your mouth as I usually do. As it's dark all the time, I tended to do that a lot. I learned quickly not to, though.
• I saw an arctic fox run through Longyearbyen, we saw two reindeer and we saw what we think are ice bear tracks behind our hotel.
• Timing your travel to catch the Quadrantids is useless when there are several independently moving layers of clouds for a full week.
• The Aurora Borealisis an elusive thing. We have a few long exposures with it showing, but we didn't see anything with our bare eyes.
• The few minutes when we saw stars, meteors, the moon, Jupiter, and Venus all at once were worth it and more.
• Survival is no joke up there. They keep a coal mine running just to power their local plant.
• That plant has its own storage facility for coal in case the mine shuts down.
• There are several independent "fire houses" that can provide energy and heat in case the power plant shuts down.
• The seed vault is somewhat boring on the outside, but it's one of the most important sites on Earth and visiting it was nice.

All in all, it was well worth it. PS: If you know anyone working with Google Maps, ask them to consider improving their coverage of the Arctic. This is a real pity. As is the rest of the Arctic and the fact that Google Earth cheats you out of the North and South Pole by stretching adjacent tiles into and over them.

The annoucement below just went to the R-SIG-Finance list. More information is as usual the the R / Finance page:

Now open for registrations: R / Finance 2012: Applied Finance with R
May 11 and 12, 2012
Chicago, IL, USA
The registration for R/Finance 2012 -- which will take place May 11 and 12 in Chicago -- is NOW OPEN! Building on the success of the three previous conferences in 2009, 2010, and 2011, we expect more than 250 attendees from around the world. R users from industry, academia, and government will join 40+ presenters covering all areas of finance with R. This year's conference will start earlier in the day on Friday, to accommodate the tremendous line up of speakers for 2012, as well as to provide more time between talks for networking. We are very excited about the four keynotes by Paul Gilbert, Blair Hull, Rob McCulloch, and Simon Urbanek. The main agenda includes nineteen full presentations and eighteen shorter "lightning talks". We are also excited to offer six optional pre-conference seminars on Friday morning. Once again, we are hosting the R/Finance conference dinner on Friday evening, where you can continue conversations while dining and drinking atop a West Loop restaurant overlooking the Chicago skyline. More details of the agenda are available at:

http://www.RinFinance.com/agenda/

Registration information is available at

http://www.RinFinance.com/register/

and can also be directly accessed by going to

http://www.regonline.com/RFinance2012

On behalf of the committee and sponsors, we look forward to seeing you in Chicago!

Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson,
Dale Rosenthal, Jeffrey Ryan, Joshua Ulrich

Our 2012 Sponsors:

International Center for Futures and Derivatives at UIC Revolution Analytics
Sybase
MS-Computational Finance at University of Washington Google
lemnica
OpenGamma
OneTick
RStudio
Tick Data

See you in Chicago in May!!

This weekend, I launched an extremely ambitious effort to collect evidence of extremely ambitious efforts. The result was a short program that searched the web and revealed the:

• Manhattan Project for the 21st century
• Manhattan Project for Advanced Batteries
• Manhattan PRoject for AI
• Manhattan Project for AIDS
• Manhattan Project for Alzheimer's
• Manhattan Project for autism research and treatment
• Manhattan Project for Big Cats
• Manhattan Project For Bio-Defense
• Manhattan Project for Biomedicine
• Manhattan Project for Bioterrorism
• Manhattan Project for cancer
• Manhattan Project for Cellulases
• Manhattan Project for chemists
• Manhattan Project for climate change
• Manhattan Project for Cold Fusion
• Manhattan Project for computers
• Manhattan Project for creativity
• Manhattan Project for Cyber-defenses
• Manhattan project for Detroit
• Manhattan Project for the development of post-nuclear superweapons in seven fields
• Manhattan Project For Economics
• Manhattan Project for the economy
• Manhattan Project for ending the prostate cancer as a socio-economic crisis in our country and a public health disaster among African American men
• Manhattan Project for Energy
• Manhattan Project for Energy Independence
• Manhattan Project for the Environment
• Manhattan Project for Excellence in Radiochemistry
• Manhattan Project for exploiting extraterrestrial technologies and communication
• Manhattan Project for Finance
• Manhattan Project for fluoride damage
• Manhattan Project for fuel
• Manhattan Project for Fuel Cell Manufacturing
• Manhattan Project for future generations
• Manhattan Project for genetics
• Manhattan project for global hunger
• Manhattan Project for Global Peace, Prosperity and Stability
• Manhattan Project for Green Innovation
• Manhattan Project for Guitar Exercise
• Manhattan project for Hawkeyes
• Manhattan Project for a healthy nation
• Manhattan Project for Homeland Security
• Manhattan Project for Iowa
• Manhattan Project for IT
• Manhattan Project for Legal Education
• Manhattan Project for life
• Manhattan Project for Maine,
• Manhattan Project for materials that could resist corrosion by fluorine or its compounds
• Manhattan Project for medical treatment in the field of obesity
• Manhattan Project for Michael
• Manhattan Project for Miracles
• Manhattan Project for modular instruments
• Manhattan Project for National IDs
• Manhattan Project For Natural Disasters
• Manhattan Project for the NES
• Manhattan Project for Network Computing
• Manhattan Project for network security
• Manhattan Project for the Next Generation of Bionic Arms
• Manhattan Project for online identity
• Manhattan Project for Our Time
• Manhattan Project for Pb-Free Electronics
• Manhattan Project for Public Diplomacy
• Manhattan Project for Racial Achievement Gap
• Manhattan Project for real time biomedical research on human populations
• Manhattan Project for the restoration of motor function
• Manhattan Project for a revival of the Sacrament of Penance
• Manhattan Project for simulation with pseudo-random numbers
• Manhattan Project for the social and behavioral sciences
• Manhattan Project for stove testing and design
• Manhattan Project for systems engineering
• Manhattan Project for Texas Water
• Manhattan Project for transforming patient care for men and ending prostate cancer
• Manhattan Project for the war on terror
• Manhattan Project for Wildcat Service Corp
• Manhattan project for wind, electric, solar, geothermal, hydro and other renewable sources of enengy we've not even thought of yet
• Manhattan Project for XBLA
• Manhattan Project for yourself
• Manhattan Project for Zinnias

[Previously in this series: frailty, the invisible hand, science as dance.]

Debian Med prepares a metapackage for multi-purpose image machines, containing packages for bioinformatics that can be used in command line or via scripts, and that do not depend on too many other packages. I would like to prepare such an image for the Amazon cloud in the most secure manner, and the simplest way is to build it automatically in order to not have to clean anything at the end of the process. I tried for months so use the Debian installer, but banged my head against walls repeatedly, as it was impossible to re-partition the volume on which the installer was started. In the end, I figured out that this was not necessary. For instance, one can start an image containing the installer on a micro instance (-t t1.micro), with an additional volume of one gibibyte (-b /dev/sdb=:1:false) to install Debian on, and preseed the installer via instance metadata (-f preseed.txt) using a file prepared in advance. When the installation finishes, the instance terminates instead of stopping (--instance-initiated-shutdown-behavior terminate), and its volumes disappear, except the one where Debian was installed (/dev/sdb=:1:false). Debian-installer in Stable is not often updated, and its size is very small. One can therefore think of releasing one machine image per zone and architecture. I did so for T ky (ap-northeast-1) on amd64. It contains the kernel, its initrd, and a GRUB 1 menu for pvgrub, that passes the following options: console=hvc0 auto=true priority=critical url=http://169.254.169.254/latest/user-data DEBIAN_FRONTEND=text. Two key pieces are missing in the resulting system. When the kernel is installed or updated, the GRUB 1 configuration file for pvgrub must be refreshed. Also, the system must be able to retrieve a public SSH key provided through the instance metadata, to allow one to log in without using a predefined password. These two functions are provided by the cloud-init package, available in Ubuntu and Fedora. I am looking for volunteers to maintain or co-maintain cloud-init in Debian.

Over the past few weeks, I upgraded my Ubuntu hosts to the Precise release due to be published next month. While the upgrade on my desktops from Oneiric to Precise went mostly well, the upgrade of my terminal server from Lucid to Precise was more daunting. In short: too many packages leave an undue amount of cruft behind, namely tons of obsolete configuration files that are not correctly handled by maintainer scripts, to either delete obsolete files or to rename them to the currently valid filename. At Debian, these oversights are periodically monitored using piuparts and reported to the package maintainer, but Ubuntu doesn't seem to offer this sort of automated Quality Assurance process yet. Perhaps this would be something worth developing? PS: For those who wonder how I spotted those obsolete configuration files, I simply enabled the FLAUSCH environment variable before running upgrade-system.

Around two years ago, the OECD presented a study on residential bandwitdth available per country that triggered quite a bit of debate all over the world I have seen at least criticism to it in Mexico, in the USA and in Australia. It's very easy to take a simplified view of a statistic and bitch on how sorry the state of our country is. In our case, the outcry was that Mexico was the lowest of all of the OECD countries, and I have seen this repeated on so many topics that it what surprises me is that people keep getting surprised at it! OECD does not represent the 200 countries in this world (only the top 30, and the meaning of "top" is not unambiguous). I found this graph that helps me illustrate this point: While that graphic is part of a report illustrating how sorry the USA should be for their low position, it shows the OECD member countries. And yes, the only country Mexico could be compared in general terms from those in the list is Turkey. Coherently, they are located at positions 28 and 30. But what prompted me into writing this post? That some weeks ago I was reading a viewpoint article at the Communications of the ACM magazine: What gets measured gets done: Stop focusing on irrelevant broadband metrics, by Scott Wallsten (might be behind a paywall for you If you are interested, I can share a copy with you, just ask me by email). Wallsten's article contains the following graph: I found it pretty telling that, although Mexico sits at the extreme of the graph (and the height of our bar makes it very hard to get a real value out of this particular rendering), our ISPs join a very select group of countries (Sweden, Germany, Belgium, Luxembourg and Ireland, in my very subjective measure) by delivering what they promise. In 2010, the dominant broadband offering was 1Mbps, although higher options have long existed. I always got basically the 100% of what my ISP (Telmex) has promised, even though I have always had the cheapest package available. Some months ago, I got a call announcing we were being pushed 5x into the future, and starting right then, I had a 5Mbps connection. And although I didn't really expect it to be true, I have had a clean 6Mbps (yes, 6 instead of 5) connection. So, that's it. This post contains no hidden truths, but just what grabbed my attention from a series of data points :-)

Attachment	Size
Residential Internet speed comparison per country (2010)	397.15 KB
Measured and advertised download speeds (in kbps)	252.86 KB

FedEx has had some issues in my area. There for awhile, they kept returning packages as undeliverable, saying the address was bad. It wasn t. Just because their GPS can t find it or their driver doesn t know it doesn t mean it doesn t exist. A map, a real map, would have done it. I had this kind of conversation with them once. Me: So you re returning my package to the sender. FedEx: Yes sir, the address was wrong. Me: No, it wasn t. [ we confirm we're talking about the same address. ] FedEx: Our driver says it doesn t exist. Me: I ve lived here for [x] years. I do know my address. FedEx: Maybe it s just new. Me: Someone has lived at this spot since the 1890s. FedEx: Hmm. I don t know then. Me: How about I give you directions? FedEx: Well, OK, I guess I could send directions. But they probably won t see them for three days. Me: Where will my package be by then? FedEx: Hard to say. Me: Do you people have cell phones maybe? FedEx: No. Me: Well, OK then Lately we have been noticing that the driver throws the package from the truck without stopping. We find them all over the yard. Unless it s big, in which case he puts it on the porch, puts a completely useless sticker on the door saying We delivered your package to right here! , and doesn t ring the doorbell. And panics due to the muddy road. The FedEx driver once told Terah, I almost got stuck on that muddy road! What s the good one? Terah: Well, which one did you take? [ he describes ] Terah: [ serious ] That IS the good road. FedEx: [ turning pale ] Oh my. I don t know if I can make it back to the highway. Terah: Well, I suppose I could get the boys in the car and drive you into town FedEx: [ embarrassed and more pale ] Uhm that s OK uhm I think A *month* later, we got another FedEx package. The driver called me at work, saying, I just don t know how I m going to get down those roads. Can I deliver the package to you here? (10 miles away). I said yes, and managed to suppress a significant snicker at his obvious relief. FedEx drivers seem to come and go. The UPS driver, on the other hand, knows the names of our boys, our cat, and puts anything small behind the storm door so it won t blow away if we re not home. And he gets a great big laugh when I tell him that the FedEx drivers are afraid of our roads. Haha, he thinks THAT S mud? Obviously he never drives in Butler County.

I followed Gregor s evolution within Debian because I used to be somewhat active in the Perl team. His case is exemplar because it shows that you don t need to be an IT professional to join Debian and to make a difference. His QA page is impressive with hundreds of packages maintained and hundreds of non-maintainer uploads too. While he started out slowly, I remember meeting him at Debconf 7 in Edinburgh and after that he really got more implicated. Again a case of someone joining for technical reasons but getting more involved and staying there for social reasons! Let s jump into the interview and learn more about him. Raphael: Who are you? Gregor: I m 41 years old, and I live in Innsbruck, Austria, in a shared apartment with a friend of mine. In my day job, I m working at the regional addiction prevention agency, so I m one of the few Debian guys who s not an IT student or professional. I started maintaining packages in 2006, and I am a DD since April 2008. Raphael: How did you start contributing to Debian? Gregor: After having used Debian on servers for some years, I finally switched to it on the desktop after some procrastinating. Soon afterwards I wanted to know more about the making-of , started to join mailing lists, filed bugs, and tried to learn packaging. Luckily I quickly found a permanent sponsor Tony Mancill, and we re still co-maintaining each others packages. And when I packaged my first Perl modules, Gunnar Wolf invited me to join the Debian Perl Group, an offer I accepted a few days later. And I m still there Later, the NM process, although it involved some waiting times, was also a good learning experience due to my AM Wouter Verhelst. (And in the meantime the organization of the NM process has vastly improved, from what I hear.) So my starting point for joining Debian was my curiosity but what really helped me to find my way into the project was the support of the people who invited and helped me. Raphael: What s your biggest achievement within Debian or Ubuntu? Gregor: I m not sure I can name a single big achievement but I guess I can say that my contributions to the Debian Perl Group have helped to make and keep the team a success story. Raphael: The pkg-perl team seems to work very well. As an active member, can you explain us how it is organized? How do you explain its success? In particular it seems to be a great entry point for new contributors. Gregor: The team is huge, both in numbers of members and packages (over 2200). Since last DebConf we manage our source packages in git, we have 2 mailing lists and an IRC channel, and we manage to keep an overview by using PET, the Package Entropy Tracker. It s true that we get new members on a regular basis; we try to invite people (like it happened to me 6 years ago ) but there are also quite a few new contributors who find our docs and introduce themselves on the mailing list. Maybe someone should conduct a study and ask them what motivated them to join. We hand out group membership/commit access quickly, and we try to mentor new contributors actively during their early times in the group. Some of them leave for other projects after some time, but many also stay and become DDs later. I m not sure what the reasons for the group s success are, maybe a combination of:

• a culture in the group (and also in the upstream Perl community) that s based on fun, cooperation, and respect;
• the fact that packaging Perl modules is most of the time quite easy;
• a great set of tools, and also (hopefully) useful documentation;
• a bunch of relaxed people who are open to newcomers and try to help each other.

For everyone interested in joining the Debian Perl Group, our Welcome page on the wiki is a good starting point. Raphael: What are your plans for Debian Wheezy? Gregor: Nothing overly exciting. What I should do is getting a newer JabRef into Debian (which involves packaging some new Java libraries any takers?). A solution for libdatetime-timezone-perl (which ships timezone data converted to Perl modules and tends to get outdated when the timezone data change) would be nice; let s see if #660404 leads to some results And some Perl packages will also need a bit of work for the hardening build flags release goal (cf. #657853). Raphael: What s the biggest problem of Debian? Gregor: Inertia. While I really like the fact that Debian is a volunteer project, and that every contributor works when and on what they decide to work on, I get the feeling that Debian could do better in moving forward, innovating, taking decisions. I also think that more uniformity in managing source packages would make things easier; it s quite amazing to see how many source formats, packaging helpers, patch systems, RCSs etc. are used all over the archive. I m not advocating for mono-cultures, and I consider this diversity a strength in general, but having to find out first how this particular package works when preparing a bug fix can be annoying. On the bright side, I think that the myth Debian and its mailing lists are mostly about flames can be seen as dispelled in the meantime. Sure, sometimes the tone could be a bit more civil, but in general most of the interactions I ve seen in the last years were friendly and helpful. IMO, the Debian Project consists of mostly nice and cooperative people, and that s what makes it fun for me. Raphael: You re one of the most dedicated participants to RCBW (Release Critical Bugs of the Week), an initiative to fix RC bugs every week. How much time do you spend on it? What would you advise to people who are considering to join the movement? Gregor: I got into the habit of fixing RC bugs after having been invited to my first Bug Squashing Party in Munich some years ago. During this weekend I saw that fixing RC bugs can be fun, is often not that difficult, and gives a warm fuzzy feeling I can definitely recommend attending a BSP if one happens to be organized near you. After tasting blood at this first BSP I tried to continue looking at RC bugs, and I guess I spend something around half an hour per day on it. I usually blog about it once a week, in order to motivate others to join in. And joining is easy: just take a look at the tips people like Zack, Vorlon, or me have written. You don t have to be a DD to help, many of my NMUs are based on patches that others kindly prepare and send to the BTS kudos! Another nice aspect is that the RC bug list contains problems from different fields: general packaging problems, language-specific issues, policy violations, etc. So there s something for everybody, and you don t have to be an expert in all fields to fix a specific bug. What s rewarding about fixing RC bugs is not only the feeling of accomplishment and the knowledge about having helped the next release I also received quite a few Thank you mails from maintainers who were busy at that time and appreciated the help. Raphael: Do you have wishes for Debian Wheezy? Gregor: Well, there s not so much left of the Wheezy release cycle if we manage to freeze in June Some quick thoughts for Wheezy and Wheezy+1:

• Obviously, getting multi-arch and the hardening build flags as far as possible would be good.
• What I like is the idea of the time-based freeze, and I hope it will work out in June. And then I hope that the freeze will be shorter this time than during the last 2 releases.
• Unless I m missing something, the CUT discussions have more or less died down; IMO that s a pity because there are users who run testing and would like to avoid the several month long freeze. Maybe someone can come up with new ideas for Wheezy+1
• Too late for broad adoption in Wheezy but still: What constantly annoys me is the handling of conffiles during upgrades (when I want to keep changed values but at the same time want to add new variables). Config::Model seems to be the best idea so far for configuration upgrades but it s not yet widely adopted.

Raphael: Is there someone in Debian that you admire for their contributions? Gregor: There are many people in Debian I admire, too many to name them all. The first one that comes to my mind is Russ Allbery who not only does great work from lintian to Debian policy but who also sets a great example of communicating in a perfectly polite and respectful way even in heated discussions.

---

Thank you to Gregor for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

I have just released version 0.2 RC1 of my hardlink program. Compared to the 0.1.X series, the program has been rewritten in C, as Python was to memory-hungry for people with millions of files. The new program uses almost the same algorithm and has almost completely the same bugs as the old version. The code should be portable to all UNIX-like platforms supporting nftw(). I have tested the code on Debian, FreeBSD 9, and Minix 3.2. For storing path names, it uses a flexible array member on C99 compilers, a zero-length-array on GNU compilers, and a array of length 1 on all other compilers (which should work everywhere as far as I heard). The new version may have slightly different behaviour compared to 0.1.2 when regular expressions are specified on the command-line, as a result of the switch from Python s regular expression engine to PCRE (if compiled with PCRE support, you can also use POSIX extended regular expressions if you like). The code is significantly faster than the old code (in situations where it s not I/O bound), and uses much less memory than the old one. Per file, we now store a <tt>struct stat</tt>, a pointer, an int, a char, and the filename; as well as three pointers for a binary search tree (which uses tsearch()). It should also be compatible to Red Hat s original hardlink tool now command-line-wise, there is at least a -c option now. The history and the name conflict are interesting, but probably nothing for this post. We re even less resistant against changing trees than Fedora s tool (and derived) currently, but should otherwise be better (and far more complicated and feature-packed). And we don t require mmap(), but use fread() instead. There was no real performance difference in testing. And we are not GPL-licensed, but use the MIT/Expat license. The package is currently entering Debian experimental for testing purposes. If you have used hardlink previously, or are just curious, give it try. And the makefile is now compatible with the various BSD makes out there, if that s interesting for you. Link to website: http://jak-linux.org/projects/hardlink/
Filed under: General

This leap day saw me driving along the river on a rainy, with 4 chickens in the car's trunk, and 3 terabytes of disk (and a half a bale of straw) in the back seat. I may have not been blogging much lately about life, because these situations can be hard to explain. (Or because "joined the Debian haskell team and spent two days working on rebuilds for the ghc 7.4 transition" is not thrilling reading.)

hens in a car

The Light Sussex chickens are my sister's spare flock, which are "too tame". They're now cozily installed into a coop we built last weekend. In return I gave her a 6 foot long APC power strip, which had been mounted on the wall of my office. I'm preparing my house in town to be rented, and have little need for two dozen power outlets here in solar power land. Indeed, today is a gift economy day all around -- when I arrived at the cabin, there on the porch was an unexpected package from Google. Particularly surprising since I never get deliveries here, since the driveway is a mile long and often seems like it could dead-end into the woods at any moment. The combination of technological wackiness (I also debugged a laptop whose USB hub hangs when a particular trackball is plugged in) and in your face country texture (including coal trains, being stuck behind a tractor, and miles of amazing tree-height mist) made this a memorable day.

SQLAlchemy, MySQL and sql_mode=traditional As everyone should know, by default MySQL is an embarassing stupid toy:

mysql> create table foo (val integer not null);
Query OK, 0 rows affected (0.03 sec)
mysql> insert into foo values (1/0);
ERROR 1048 (23000): Column 'val' cannot be null
mysql> insert into foo values (1);
Query OK, 1 row affected (0.00 sec)
mysql> update foo set val=1/0 where val=1;
Query OK, 1 row affected, 1 warning (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 1
mysql> select * from foo;
+-----+
  val  
+-----+
    0  
+-----+
1 row in set (0.00 sec)

Luckily, you can tell it to stop being embarassingly stupid:

mysql> set sql_mode="traditional";
Query OK, 0 rows affected (0.00 sec)
mysql> update foo set val=1/0 where val=0;
ERROR 1365 (22012): Division by 0

(There is an even better sql mode you can choose, though: it is called "Install PostgreSQL") Unfortunately, I've been hired to work on a project that relies on the embarassing stupid behaviour of MySQL, so I cannot set sql_mode=traditional globally or the existing house of cards will collapse. Here is how you set it session-wide with SQLAlchemy 0.6.x: it took me quite a while to find out:

import sqlalchemy.interfaces
# Without this, MySQL will silently insert invalid values in the
# database, causing very long debugging sessions in the long run
class DontBeSilly(sqlalchemy.interfaces.PoolListener):
    def connect(self, dbapi_con, connection_record):
        cur = dbapi_con.cursor()
        cur.execute("SET SESSION sql_mode='TRADITIONAL'")
        cur = None
engine = create_engine(..., listeners=[DontBeSilly()])

Why does it take all that effort is beyond me. I'd have expected this to be turned on by default, possibly with a switch that insane people could use to turn it off.

More than two years ago I wrote arbtt, a tool that silently records what programs you are using and allows you to do statistics on that data later, based on rules that you define afterwards, hence the name automatic rule based time tracker. I wasn t doing much with it recently (the last release has been half a year ago), but it nevertheless was running on my machine and by now has tracked a total time span of 248 days in 350000 records. Yesterday, I had a use for it again: measuring the time spent creating a certain document with LaTeX. So I added a rule to my categorize.cfg and ran arbtt-stats. I knew that it was not very fast, and that my data set has grown considerably since I last used it. And indeed, it took more than 6 minutes to process the data and spit out the result. Since I m currently working on the GHC 7.4.1 transition in Debian anyways, I decided to check what happens if I compile the code with that version of the Haskell compiler, instead of the previous version 7.0.4. And behold: The whole process took merely 17.3 seconds to complete! At first I did not believe it, but the result was identical, both binaries were built with the same option, i.e. no profiling enabled or anything like that. Wouldn t you also like to have such speed ups for free, just by waiting for someone else to improve their work?

I tried to find out the reason for the speed up and created profiling output from both the old and the new binary. The old binary spends 83% of the time in Categorize.checkRegex, which basically just call Text.Regex.PCRE.Light.match. Since the version of pcre-light is the same in both binaries, I conclude that the Foreign Function Interface that GHC provides to interact with C libraries (libpcre in this case) is much faster now, although I do not find any mention in the release notes. And even if I do not count the 83% time spent in checkRegex, the code from the new compiler is still 2.7 times faster. Thanks, GHC devs, great work!

Flattr this post

Today I had the first running race of 2012. Well, actually, it was my first race in Switzerland ever so double first. And, if I have to be precise, it was my first run with a shiny new Garmin 910XT; while I had it ordered for more than a month, out-of-stock and other delays converged such that I received the new toy the evening before the run. After getting it, I walked around a bit to confirm it's not DOA, read the manual, and hoped it's not too different in basic operation to my old Garmin. So a triple first. Also, (this is the last one, I promise!) this was the first time I ran with a foot pod (pedometer), so it was the first time I got actual cadence measurements. The run I went to the Bremgarter Reusslauf, which is an 11km flat run held in the woods near Bremgarten, a very very nice small town. I have never before visited it (even though it's quite close to Z rich), and I was pleasantly surprised by it. I should go sometimes back and visit a bit more. The weather was cloudy (and just a tiny bit foggy), a bit cold but not much. From this point of view, it was good running weather, but it detracted from the scenery. Otherwise, the course itself was very very enjoyable, I could have used a camera lots. At one point, in the middle of the (light, not dense) woods, the course passed beneath the arm of an excavator which was like a mechanical arch (in the middle of nature); at another point, we crossed the river, and the sight was so nice I had to stop myself from stopping and admiring the view . The course is marked as a 'flat' one, but I've read some blog posts saying that this is not entirely true, so I was prepared for 'the worst'. Actually, I found it to be surprisingly well behaved; even though the finish was near the start, it seemed to me to be 60% downhill, 30% flat and only 10% somewhat-uphill. Garmin 910XT I didn't quite know what to expect, upgrading from my Forerunner 205. I read the very nice review on dcrainmaker, but in practice I didn't know what to expect (review awesome, but soo detailed). The new toy seems more stylish, so I expected worse UI or behaviour. On the contrary, it worked very well; much more responsive to changes in direction/pace (my 205 used to delays tens before adjusting the pace, the 910 is very fast), and new minor features (like auto-lap) were nice (I was able to track average speed on each 1KM lap, very useful). It's a ++ on the upgrade, with the big downside that so far it doesn't seem to work under Linux . It also has a barometric altimeter, but I didn't calibrate it (explicitly); so while the absolute measurements might be off, the relative elevation changes were much more sane than with 205 (GPS is not too good at elevation changes, as far as I know). One funny thing about the delays in getting the device: before the race, another runner asks me (note: the conversation was in German, accuracy not guaranteed):

Is that the new Garmin? Yes, it is, just got it last evening. (showing me his identical watch) Ha! Me too, I got this only two days ago!

So yes, I think a few people were happy to get their new toy before the race. I also have now a heartbeat sensor, but as I never used one before, I didn't want to try it the first time during a race; so I skipped on that. The foot pod on the other hand is practically ignorable, so I took that along (sometime I think I run just because there are nice running toys ). As to accuracy, it was quite OK; it measured 10.86 km instead of the official 11 km, but most/all of the difference was in the first km of the run (inaccuracy while starting to run? who knows). I'll have to see how the watch performs while cycling (uh, I didn't do that in a long while) or swimming ( I didn't do that in an even longer while), but for running it's a good upgrade from my old watch. Results My normal run pace is about 6min/km, which is quite slow. So I didn't expect anything of the race, except to finish it. There were lots of people participating (> 2,600 in the main 11km category). I started slow, because I know I usually start too fast and get tired quickly. This allowed me to not feel the first, and only, significant hill, and after that it was or seemed all downhill (literally, I mean, not figuratively), so in the end I had (for me) a very good time. By the Garmin, I run 10.86 km in 59:01, to an average 5.26 min/km. By the official results, I had 11 km in 58:56, with a pace of 5.21 min/km. I have never before run 10k faster than 5:30, so I was very very happy. As for individual laps (1 km) as recorded by the Garmin:

• first km, 6:09
• second km, 5:35
• third km, 5:42
• after that, all laps were below 5:30 (except the 8th, 5:32)
• 10th lap was 5:03
• 11th partial lap was 4:09

On the overall ranking, I ended up 362 out of 394 in my category. Hah! I'll try to remember this race simply for my own pace results, and ignore the ranking . Honestly I'm not sure how people can run twice as fast need to train more! The foot pod gave me a cadence of 83 steps per minute (average, max 88). This was quite surprising for me, I expected to be significantly below the much talked about 90 steps per minute. But anyway, I have lots of work ahead of me to improve my running speed. Overall, it was an excellent day, and I'm looking forward to the next races in/around Z rich. But I should be careful not to overdo-it, like I do whenever I get excited about something .

Ben Hutchings writes:

There is an alternative to using C-c, and that is M-#. This adds a '#' to the start of the line, commenting it out, and then behaves as if you pressed Return. The result is that the command is cancelled but still remains on-screen and in your history. You can then copy the command later using the mouse or keyboard.

Naturally, there is a zsh equivalent for this (there always is...): pound-insert. Quoth the manpage:

pound-insert
If there is no # character at the beginning of the buffer, add one to the beginning of each line. If there is one, remove a # from each line that has one. In either case, accept the current line. The INTERACTIVE_COMMENTS option must be set for this to have any usefulness.

So if you want the same for zsh, a simple

bindkey '^[#' pound-insert

is all you need. Update: Clint Adams noted another way to do (almost) the same.

phpMyAdmin is quite popular software (to give some numbers let's mention 10000 downloads daily on SourceForge.net or 122685 reports in Debian's popcon) and as such is quite attractive target for various scripted attacks. If you run phpMyAdmin installation somewhere you should really make sure it is enough secured, so that these script kiddies don't get through. In past month I've looked at what kind of attacks are these guys trying and in all cases these are pretty old vulnerabilities, some of them fixed years ago. So the first thing you should do is to update. It is always good to run latest stable version, but in case you can not for whatever reason, try at least taking the most important fixes and using them. In ideal world your distribution would do this job for you, but in case it did not, you can for example take patches from Debian, which is pretty good at taking our patches (surprisingly it is not much related to my involvement there). To check which patches they have applied you can use excellent patch-tracker tool, which exposes patches from all released packages. To give you overview of which issues are mostly being attempted to exploit by script kiddies right now, here is the list:

• PMASA-2010-3 - yes, more than two years old, but still unpatched in some places
• PMASA-2011-5 - "only" half year old
• PMASA-2011-6 - only useful together with wrongly configured PHP

If you have fixed these, you should be pretty safe for now, but follow our security announcements for possible future issues (you can use RSS feed or subscribe to news mailing list, where all security issues are announced as well). However there are more things you can do to keep you safer:

• remove setup directory from phpMyAdmin, you will probably not use it after initial setup
• prevent access to libraries directory from browser, as it is not needed, supplied .htaccess file does this
• properly choose authentication method - cookie is probably the best choice for shared hosting
• in case you don't want all MySQL users to be able to access phpMyAdmin, you can use AllowDeny rules to limit them
• consider hiding phpMyAdmin behind authentication proxy, so that MySQL credenticals are not all users need to login

So these are the basic steps which will help you against possible compromise, I might return to some of these in more details in future posts.

Filed under: Debian English Phpmyadmin Suse 0 comments Flattr this!

Now is the point in the Debian release cycle where I usually try to go through my packages and bring them generally up to date. In case other people are doing the same thing, here are a few new facilities or techniques that I'm rolling out across my packages. (This is apart from the obvious stuff, like multiarch where appropriate and debhelper 9, and the older stuff, like using dh.)

• dh-autoreconf is a new helper tool that runs autoreconf on the package during the build and cleans up properly afterwards. I've started switching all of my packages that use Autoconf and Automake and can use autoreconf over to it. (Some upstreams have more complex scripts that have to be run to regenerate the build system.) It plugs in trivially as a dh add-on, and even adds support for --as-needed (see below). I'm doing this even for packages where I don't patch the build system, on the grounds that rebuilding everything from source, including the build system, is a good idea. It also means that I can patch the build system when I need to without having to add additional machinery at the time.
• Linking with --as-needed. As I build new packages, I'm looking for anything that has warnings about generating unnecessary dependencies and adding --as-needed to the linker flags. The combination of dh-autoreconf and the new dpkg-buildflags support makes this trivial to do for most packages. Just add something like:

      export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

  to debian/rules. It's worth being aware that --as-needed can break some unusual uses of special cases around shared library loading, but I've not run into any of those cases with any of the software that I package.
• dpkg-buildflags comes essentially for free with debhelper 9, but it's worth mentioning that, as mentioned above, it's a really easy way to add additional flags. And if you have to pass in flags via some other mechanism, use dpkg-buildflags to get the default flags.
• Once you're up to debhelper 9 and are using dpkg-buildflags, adding hardening flags is easy. You get the default ones for free, and that's a pretty good start. (Install hardening-includes and use hardening-check to check the status of the binaries built by your package.) I always add at least hardening=+bindnow to DEB_BUILD_MAINT_OPTIONS (set with export in debian/rules), since the minor speed hit at startup doesn't matter for anything that I'm packaging. (It might for something like ls that runs all the time.) I usually try to also add +pie, but be careful of that. Libtool will cope correctly with it and switch it back to PIC for shared libraries, but other shared library build processes may not. And it doesn't always work; for example, gnubg (GNU Backgammon) just immediately dies if built PIE, for reasons that I didn't track down.
• If, like me, you maintain your packaging in Git without using a separate tool that exports a patch series, and therefore use the single-debian-patch option, there is new support for applying that option only to your build as the maintainer but not to any other build that people do of your source package. This is good, since it means that any NMU diffs will be kept separate from your maintainer diff because they'll get the version of the NMU package added. To get this behavior, move debian/source/patch-header to debian/source/local-patch-header and debian/source/options to debian/source/local-options (assuming that's your only option; otherwise, you might need to split it). Then the patch header and options won't be included in the generated source package and hence won't apply to NMUs or other packaging changes based on the source package in the archive instead of on the packaging repository.

It's also worth mentioning that Ubuntu was responsible for breaking a lot of ground here. Due to bug reports and patches submitted from Ubuntu, several of my packages already had hardening build flags and --as-needed issues fixed before this round of packaging refresh, which made adding these features much easier than it would be otherwise.

To use an SSH agent, one usually has to:

1. launch the agent;
2. add his key to it.

The first step can be automated in the desktop or shell startup script (this is a typical use case for login shell-only startup scripts, by the way), but the second one cannot if your private key is protected by a passphrase.Opportunistic key loading GNOME Keyring includes an SSH agent which has an interesting feature I call opportunistic key loading : it asks for the passphrase to decrypt the private key the first time it is needed. This feature mimics the behaviour of PGP agents, and eliminates the second step I previously mentioned. Question Do you know if there exists another SSH agent able to do opportunistic key loading?

A few people have been using the license-count tool that I wrote to analyze the breakdown of licenses in Debian and draw some conclusions. Unfortunately, some of those conclusions can't be drawn from the output of this specific tool (which doesn't make them wrong, just unproven). So here are a few cautions. license-count was written for a specific purpose: to see how many references there are to a particular license in Debian so that we had some facts behind our discussion of whether to include it in common-licenses. It was not written to classify packages into particular categories, only to find out how many copies of a license we could save by adding it to common-licenses. This means that using it to determine how much software in Debian is covered by a particular license fails in the following ways:

1. license-count numbers cannot be added. Since the goal is to find every reference to a given license, each package is not classified as under one and only one license. If a package has material under the GPL, the LGPL, and the GFDL, it will add one to each of those counts. This means that you cannot determine, from its output, questions like "how many packages are covered under one of the GPL family of licenses?" You will double- or treble-count packages when you add the numbers together.
2. license-count counts any reference, not just "important" ones. If the license is referenced in debian/copyright, that counts, since the goal is to see how many packages might benefit from being able to reference it in common-licenses. This may not be the license that the package is under, just some small portion of the package. For example, all of my packages that use Autotools add to the GPL count because I include all the source code licensing statements, including the statements for libtool and the Automake helper scripts, which say that the files can be released under either the GPL or the license of the including package. These packages are generally under a BSD-style license (or in some cases the Apache 2.0 license), not under the GPL, but since the reproduced license text has a reference to the GPL, license-count adds one to the GPL column for each of those binary packages. For most purposes for counting GPL-covered software, these are false positives. I don't know how many people are as complete in documenting license statements as I am, but just the binary packages that I maintain probably count for at least 50 false positives because of this alone.
3. license-count numbers include dual-licensing. Whether this matters for your analysis or not depends on what question you're asking, of course. If you're asking whether the package is covered under a copyleft license, including the thousands of packages that are dual-licensed under the Artistic license and the GPL may be okay, since the Artistic license is a sort of copyleft (although it allows you to avoid the copyleft requirement by renaming executables, providing the originals, and documenting your changes). But, for example, one of my packages is dual-licensed under a BSD-style license and the GPL (for reasons that aren't worth getting into). This package is not covered by copyleft under any reasonable definition of the term, but license-count will count it as a package using the GPL.

In order to draw interesting conclusions like "how much software in Debian is protected by copyleft," I'm afraid that you'd have to write a much more sophisticated tool than license-count.