A while ago, I was asked to recompile Tinyproxy to enable transparent proxying support, which was not being compiled in etch's Debian package. As it tends to happen, once I got the source and looked into doing a quick rebuild with --enable-transparent-proxy, I noticed the package was in such a bad shape, that I couldn't just leave it like that, so I found myself doing a few more changes, which mostly involved updating the packaging so it didn't suck a lot, and splitting the Debian patches so things could be sent upstream or dropped when new versions appeared. However, even if Ed had asked me to go ahead and take over the package, this was meant to be a one-day effort, and soon I had forgotten about Tinyproxy, except for the ocassional bug mail getting through the PTS. It also didn't help that Tinyproxy had been pretty much dead upstream for years. So lately, a few bug reports were reporting a gasp new major Tinyproxy release, after 7 years of basically nothing. OMG, what do I see, there's a Git repo! And an upstream Bugzilla! Somehow, feeling I owed Ed a reply to his unanswered request, I went ahead and tagged tinyproxy 1.6.3-3.2 in collab-maint, and started working on the new version. Adding myself to Uploaders, and getting rid of the make no unnecessary changes vetto, I rewrote most of the packaging. And for a change, I looked for and found a #tinyproxy channel on IRC and told muks and obnox that the days of Tinyproxy's stay in the Debian/Ubuntu limbo were over.

They were happy to get a few bugs and patches forwareded upstream, and asked me why all of this hadn't happened before. Pitty is that a few longstanding issues were well known in Debian but not so obvious for the new upstream maintainers, and are present in 1.8.0. Hopefully all will be dealt with in 1.8.1 or the next major version. The lesson is: if you work on an apparently abandoned package, after cleaning the mess in your NMU, try to spend 15 more minutes trying to contact upstream (if available), pointing them at the patch tracker and our list of bugs: chances are many are still useful. Also, contact the Debian maintainer, and if they ask you to take over, at least post a RFA so someone else can. If you're a Tinyproxy user, I'd be happy to hear if the current package in Debian unstable works for you. If you were having weird issues with 1.6.x, chances are 1.8 will fix them. The package can be installed on stable with no extra dependencies, so if you're feeling adventurous, go ahead and upgrade.

Diagnosis A few weeks ago I was referred to a specialist for the treatment of Carpal Tunnel Syndrome. I first noticed the symptoms in early January, it started happening at night with a partial numbness in the fingers of my left hand. I didn t think much of it at first as it s the expected symptom of sleeping in a position that reduces the blood flow. But when it kept happening with my left hand and never happening with my right and then started getting worse (including happening during the day) I sought medical advice. The doctor asked me to bend my hand down (as if trying to touch my left elbow with the fingers of my left hand). Within about 10 seconds this caused numbness this result from bending one s wrist is a major symptom of CTS. Treatment On Thursday I saw a specialist about this, she agreed with the GP s diagnosis and made a wrist brace for me. She started by cutting off a length of a tube of elastic woven material (similar to a sock) and then cutting a thumb hole, that became the lining. Then to make the hard part she put a sheet of plastic in an electric saucepan (which had water simmering) until it started to melt and then used a spatula to fish it out. The melting temperature of the plastic wasn t that high (it was soft at about 50C when she put it on my arm), it wasn t at all sticky when it was partially melted, and it didn t seem to conduct heat well. After wearing the wrist brace non-stop for a few days I have noticed an improvement already. Hopefully I will make a full recovery in a matter of a month or so, I will probably have to wear a wrist brace when sleeping for the rest of my life, but that s no big deal it s more comfortable to sleep with a wrist brace than a partially numb hand. I ve also been prescribed a set of exercises to help remove scar tissue from the nerves. I haven t done them much yet. In terms of being annoying, the wrist-brace has 3mm diameter holes in a square grid pattern with a 25mm spacing. This doesn t let much air through and in warm weather my arm gets sweaty and starts to itch. I m thinking of drilling some extra holes to alleviate this the part which makes my arm itch doesn t need much mechanical strength. The only task which has been really impeded has been making peanut butter sandwiches, maybe it was making sandwiches not typing that caused CTS? ;) In any case I m not giving up typing but I would consider giving up peanut butter sandwiches. I really hope to avoid the surgical option, it doesn t seem pleasant at all. Other One final thing to note is that Repetitive Strain Injury (RSI) is entirely different. RSI is a non-specific pain associated with repetitive tasks while CTS is a specific problem in one or two nerves where they go through the wrist. RSI apparently tends to reduce the effective strength of the afflicted limb, while milder cases of CTS (such as mine) cause no decrease in strength of course a severe case of CTS results in muscle atrophy due to reduced nerve signals, but I shouldn t ever get that. Many people think that RSI and CTS are essentially the same thing I used to think that until a few weeks ago when I read the Wikipedia pages in preparation to seeing a doctor about it. I want to obtain some of the plastic that was used to make my wrist brace, it could be really handy to have something that convenient for making boxes, containers, and supports for various things among other things it doesn t appear to generate static. The low melting temperature will prevent certain computer uses (the hot air that comes out of a cooling system for a high-end CPU would probably melt it), but it could probably be used to make the case for an Opteron system with careful design. I m guessing that the cost of the plastic is a very small portion of the $150 I paid to the specialist so it shouldn t be that expensive and I m sure it would be even cheaper if it wasn t bought from a medical supply store. If I ever get time to do some work on an Arduino system or something similar then I will definitely try to get some of this plastic for the case. Also the Wikipedia page has a picture of what appears to be a mass-produced wrist brace. I think that it might be improved by having the picture of the custom one that I wear added to the page. I unconditionally license the picture for free use by Wikipedia and others under the CC by attribution license. So if anyone thinks that a picture of my hand would improve Wikipedia then they can make the change.

• [1] http://en.wikipedia.org/wiki/Carpal_tunnel_syndrome

Recently I was flirting with the idea of creating an online game, but I got distracted by wondering how to make the back-end more flexible. To communicate the state of the game to N connected clients I figured I needed some kind of server which would accept "join"/"quit" requests and then make changes available. To that end I came up with the idea that a client would make requests via HTTP such as:

http://example.com/server/game/chess/join

This would regard the originating client as part of a new chess game, for example, and return a UID identifying the "game channel".

http://example.com/server/changes/1-2-3-4

This will retrieve a list of all events which had occurred in the game which had not already been sent. (Here 1-2-3-4 is obviously the UID previously allocated.)

http://example.com/server/submit/1-2-3-4/move

This would submit the move "move" to the server.

After mulling this over for a while it seemed like a great reusable solution, I'd make an initial "join" request, then repeated polling with the allocated UID would allow game moves to be observed. All using JSON over HTTP as the transport. It was only this morning that I realised I'd have saved a lot of time if I'd just proxied requests to a private IRC server, as the functionality is essentially the same. Still I'm sure this pattern of "join"/"poll"/"quit" could be useful for a lot of dynamic websites, even in the non-gaming world. So although the idea was mostly shelved it was an interesting thing to have experimented with. D'oh. ObFilm: Conan The Barbarian

For over 6 years now I've been running Buildd.Net as a service for additional information about Debian autobuilder network. The reason for running Buildd.Net was simple: until then there was a web interface running on kullervo.debian.org, but generating the webpage took more and more time on that m68k box as Debian was growing in number of packages. That webpage was always a nice plus for m68k over other architectures and it was often asked for having such a page for those other archs as well. With taking over the webpage from kullervo the other archs were added as well and Buildd.Net was born.

Buildd.Net was open for other archs and flavours, as I called the different dists like unstable, non-free or even volatile or skolelinux. Buildd.Net was always buildd centric, contrary to buildd.debian.org, which is more package centric. Yes: was - as I'm shutting down Buildd.Net soon.

The reason for this is a change of interest after m68k has been removed from Debian because of the Vancouver proposal. Vancouver caused the death of m68k. Well, anyway. Without being an official Debian arch, the development on m68k came to an end. There was no progress anymore and on the other hand there were changes in the backend of the Debian autobuilder network, which made changes on Buildd.Net necessary. Requests for help in maintaining to adopt the changes were fruitless. The changes that Buildd.Net is needing are beyond my capability of programming.

And as a consequence I'm going to shutdown Buildd.Net in the near future. Not entirely, but significantly. It will return to its origins: being a m68k (and m32r) autobuilder informational page instead of trying to follow up the whole Debian autobuilder network. Just for the chance that m68k will be revived again somewhen.
Andreas Barth told me that most of the functions of Buildd.Net is available on buildd.debian.org as well, although not yet visible. I offered cooperation and help when he wants to implement Buildd.Net functionality into buildd.debian.org. I still believe that Buildd.Net is offering a worthwhile alternative view of the autobuilder network. But, as I already said, I can't maintain Buildd.Net code source any longer on my own. So I better shut the service down instead of delivering a broken service any longer, if there's noone interested in helping.

Anyway, I hope that you all enjoyed the service in the past!

This post is about an upcoming feature in Zeitgeist 0.3.3 and is so far only available in checkouts from trunk or our PPA. It is expected to be released within the next weeks. Some weeks ago I implemented a new feature in Zeitgeist and I figured I d drop some lines about it. I m talking about a data-source registry. You may be wondering, what the hell is that even, a data-source? . So Zeitgeist is a database, a global event log, but it doesn t do any magic indexing or monitoring by itself; the information it logs needs to come from somewhere be it applications sending it to Zeitgeist themselves, daemons, plugins for applications, etc. Any such entity is called a data-source . Having a register of all data-sources interacting with Zeitgeist provides some benefits, like for example:

• Having a list of them. Lists are nice :).
• Being able to disable data-sources from a centralized place instead of requiring each to write its own preferences dialogue.
• Being able to set up a blacklist rule considering which data-source the information comes from as a condition (not implemented yet).

More details When they register, data-sources will need to provide the following information: an unique ID, a name (may be localized), a description (may be localized) and optionally a template specifying what sort of events it logs. Additionally, the last timestamp the data-source was seen by Zeitgeist, whether it is running right now and whether it is enabled will also be available. It is important to note that registration is not compulsory; while it is highly encouraged for data-sources to use it, is it still possible to anonymously insert information into Zeitgeist (for example from a shell script). The event template is also only informational, and will not be enforced by Zeitgeist at this time. Avoiding duplicates from GTK Recently Used You may know that zeitgeist-datahub provides basic support for applications which have no direct Zeitgeist support but do use GTK s RecentManager, which is not as detailed as we would like, but it is better than nothing. However, until now we had a problem: when applications had support for both, GTK s Recently Used and Zeitgeist (be it native or as an extension), it was possible for duplicate events to be inserted or other sorts of conflicts between both data-sources. Now that we have the information from the registry available, we ve been able to solve this modifying our Recently Used data-source to ignore any events concerning applications which already have another data-source logging the same types of events.

---

In case you don t care at all about what I m talking here and you just want to see fancy interfaces, go check this out. Related posts:

1. Zeitgeist is out!
2. Introduction to Zeitgeist 0.2 s API
3. Zeitgeist Hackfest (II)

---

No comments
Siegfried-Angel Gevatter Pujals, 2010. Permalink License Post tags: gnome, Programari lliure, zeitgeist

As some people noticed, a driver update to support a major hardware release in my day job and a long series of trivial patches motivated by Debian kernel work combined to make me joint most prolific change author for Linux 2.6.33. This was a fluke, and 2.6.34 is likely to be fairly quiet for me. Team work Meanwhile the kernel team is still working hard on fixing bugs in Linux 2.6.32. As previously announced, this kernel version will be used in both Debian 6.0 'squeeze' and Ubuntu 10.04 LTS. It is also known to be the kernel version for RHEL 6 though this has not been officially announced. If you find a serious bug that was fixed in 2.6.33 or later, please ask the author to send the fix to stable@kernel.org so that it will be included in all these distributions. Note that this happens automatically for commits with the line 'Cc: stable@kernel.org' in their description. We are also continuing to backport new drivers and new hardware support in existing drivers into Debian 5.0 'lenny' (stable). Missing support for common hardware is considered an important bug and suitable for stable updates. However, if there were major changes to a driver before those that added new hardware support, we may be unable to produce a backport. We are not able to carry out comprehensive hardware testing and do not want to risk a regression existing hardware support. libata transition - call for testing Finally, a major change I have been working on is the transition from the old IDE drivers for PATA controllers to new drivers based on libata. The old IDE subsystem is no longer developed and some drivers do not properly support all the hardware that their libata-based counterparts do. However, while the IDE drivers generate device names beginning with 'hd', libata presents PATA devices as SCSI devices and generates device names beginning with 'sd'. In a system that already has other SCSI or SCSI-like disks, names may change somewhat unpredictably. Similar problems exist for PATA CD/DVD and tape devices. So, while the transition doesn't involve any kernel hacking, it does require a complex upgrade process. Any configuration files that refer to IDE or SCSI device names may need to be changed. It is not enough to switch to only SCSI device names, since we cannot know what they are in advance and the configuration files should continue to work with kernel versions from before and after the transition. In the case of disks we can normally use the partition label or UUID: many tools understand the LABEL= and UUID= syntax, and for others we can refer to the symlinks under /dev/disk created by udev. In the case of CD/DVD devices, we can use the aliases /dev/cdrom etc. created by udev. In the case of tape devices, however, you're on your own. In experimental, kernel image packages depend on a new package linux-base which implements this transition (from 2.6.33-1~experimental.2; the previous version was broken). The postinst script will prompt you to make changes automatically or manually. It can convert most bootloader configuration files, /etc/fstab, the udev CD aliases configuration and the initramfs-tools resume partition. It can also label partitions that don't have a label or UUID. Please do test it and verify that its changes are correct. All changed configuration files are backed up with a suffix of '.old' (or '^old' in one case).

Review: Coders at Work, by Peter Seibel

Publisher:	Apress
Copyright:	2009
ISBN:	1-4302-1948-3
Format:	Trade paperback
Pages:	601

Coders at Work is a collection of edited interviews by Peter Seibel (probably best known previously for his book Practical Common Lisp) of an eclectic and excellent collection of fifteen programmers. It opens with an interview with Jamie Zawinski (one of the original Netscape developers) and closes with Donald Knuth. In between, the interview subjects range in programmer generations from Fran Allen (who started at IBM in 1957) and Bernie Cosell (one of the original ARPANET developers) to Brad Fitzpatrick (LiveJournal founder and original developer). Techniques and preferences also range widely, including two people involved in JavaScript development and standardization (Brendan Eich and Douglas Crockford), a functional programming language designer and developer (Simon Peyton Jones), language designers and standardizers such as Guy Steele, and people like Dan Ingalls who have a different experimental approach to programming than the normal application development focus. All of the interviewees are asked roughly the same basic questions, but each discussion goes in different directions. Seibel does an excellent job letting the interview subjects shape the discussion. Two things immediately stood out for me about this book. First, it's huge, and that's not padding. There are just over 600 pages of content here, much of it fascinating. The discussions Seibel has are broad-ranging, covering topics from the best way to learn programming to history and anecdotes of the field. There's some discussion of technique, but primarily at the level of basic approaches and mindset. One typical question is how each programmer organizes their approach to reading code that isn't familiar with them. Each interviewee is also asked for book recommendations, for their debugging techniques, for their opinions on proving code correct, and how they design code. The participants are so different in their backgrounds and approaches that these conversations go in fifteen different directions. This is one of the most compelling and engrossing non-fiction books I've read. Second, the selection of interview subjects, while full of well-known names in the field, is not the usual suspects. While I'm interested in the opinions of people like Larry Wall and Guido van Rossum, I've already heard quite a lot about how they think about programming. That's material that Coders at Work doesn't need to cover, and it doesn't. Many of the interview subjects here are people I'd heard of only vaguely or not at all prior to this book, often because they work in an area of programming that I'm not yet personally familiar with. Those who I had heard of, such as L. Peter Deutsch, I often knew in only one context (Ghostscript in that case) and was unfamiliar with the rest of their work. This gives the book a great exploratory feel and a lot of originality. There is so much good material here that it's hard to give a capsule review. This is a book I'm highly likely to re-read, taking more detailed notes. There's entertaining snarking from Jamie Zawinski and Brendan Eich, fascinating history of the field (including in gender balance) from Fran Allen, and an intriguing interview with Joe Armstrong (creator of Erlang), who seems to have a far different attitude towards languages and libraries than the other interviewees. Every interview is full of gems, bits of insight that I now want to research or play with. A couple of examples come to mind, just to provide a feel of the sort of insights I took out of the book. In the interview with Joshua Bloch, who does a lot of work on library APIs, he mentions that empathy is one of the most important skills for designing an API. You have to be able to put yourself in the shoes of the programmer who's going to use the API and understand how it will feel to them. This came up in the context of a discussion about different types of programmers, and how programmers can be good at different things; the one who can do low-level deep optimization may not have that sense of empathy. Another example: Bernie Cosell talked about how he did debugging, and how he got a reputation for being a fantastic debugger who was able to fix just about anything. He confessed that he often reached a portion of the code that he didn't understand, that seemed too complex and tricky for what it was attempting to accomplish, and rather than trace through it and try to understand it, he just rewrote it. And after rewriting, the bug was often gone. It wasn't really debugging, but at the same time it's close to the more recent concept of refactoring. Several of the interview subjects commented on a subjective feeling of complexity and how when it gets too high that's a warning sign that code may need to be rethought and rewritten. A third example: I was fascinated by the number of interviewees who said that they used printf, assert, and eyeballs to debug rather than using any more advanced debugging tools. The former Lisp developers would often bemoan the primitiveness of tools like gdb, but many of them found that print statements and thinking hard about the code were usually all that's needed. (There was also a lot of discussion about test suites and test-driven development.) The general consensus was that concurrency problems were the hardest to debug; they made up a disproportional number of the responses to Seibel's question about the hardest bug the programmer ever had to track down. I could go on giving similar examples at great length, but apart from the specific bits of wisdom, the strongest impact this book made on me was emotional. Coders at Work is full of people who love programming and love software, and that enthusiasm, both in general and for specific tools and ideas, comes through very clearly. I found it inspiring. I realized while reading this book, and I suspect I'm not alone among programmers in this, that I largely stopped learning how to program a few years back and have been reusing skills that I already have. Reading Coders at Work gave me a strong push towards finding ways to start learning, experimenting, and trying new techniques again. It also filled me with enthusiasm for the process of programming, which immediately helped my productivity on my own coding projects. This is obviously a book whose primary target audience is practicing programmers, and while it doesn't go too far into language theory, I was relying on remembered terms and structure from my master's degree for a few of the interviews. I think it's approachable for anyone who has a working background in programming and a few languages or a CS degree, but it might be a stretch for someone new to the field. But even someone without any programming knowledge at all would get a lot out of the anecdotes and snapshots of the history of software development. Coders at Work is also full of jumping-off points for some additional research on Google or additional reading in other recommended books. I only have one complaint, which I have to mention in passing: for such a large book full of interesting ideas and book recommendations, the index is wholly inadequate. I tried looking up five or six things in it, including the source of some of the book recommendations that are collected in an appendix, and I struck out every time. It's very hard to find something again in 600 pages, and more attention paid to the index would have been greatly appreciated. But, despite that, for people within the target audience, I cannot recommend this book too highly. Not only was it full of useful information, at the level of programming above the code details that's often the hardest to talk about, but it's consistently entertaining and emotionally invigorating and inspiring. It made the rounds of tech blogs when it was first released, to nearly universal approval, and I can only echo that. If you're a practicing programmer, I don't think you'll regret spending a few weeks reading and thinking about this book. Rating: 10 out of 10

The German supermarket chain Aldi recently had a special deal of a wine-fridge for $99. A wine fridge really isn t that specialised for wine, it is merely a fridge that has a heater and is designed for temperatures in the 11C to 18C range. An good wine fridge will have special wood (or plastic if cheap) holders for wine bottles. A particularly cheap wine fridge (such as the one from Aldi) doesn t even have special holders for wine bottles. But this does however make it more convenient for storing other things. In the hotter days in summer outside temperatures of over 35C are common and it s possible for an uncommonly hot day to be in excess of 45C. My home air-conditioning system is only able to keep the ambient temperature about 10C cooler than the outside temperature if there are a few hot days in a row. According to the Wikipedia page the best chocolate is supposed to have type V crystals which melt at 34C [1]. So if the outside temperature is 45C then the temperature inside my home is almost guaranteed to be hot enough to melt chocolate. If I m not at home (and therefore the air-conditioner is off) during a moderately hot day then it s common to have a temperature of about 30C inside my house. The Wikipedia page also notes that moving chocolate between extremes of temperature can cause an oily texture and that storing chocolate in the fridge can cause a white discoloration. I ve experienced these effects and find that they significantly decrease the enjoyment of chocolate. So now I have a fridge in my computer room set to 16C because according to Wikipedia the ideal temperature range for storing chocolate is from 15C to 17C (the photo was taken shortly after turning it on and it hadn t reached the correct temperature). Every computer room should have a fridge full of chocolate! If my stockpile of chocolate reduces I may even put some wine in the fridge (I could probably fit some now if I organised the chocolate in a better way). But that depends on the supermarkets, if they have a special on Green and Black s Maya Gold organic fair-trade chocolate then my fridge will become full again.

• [1] http://en.wikipedia.org/wiki/Chocolate

Time for a little end-of-the-month looking back. (Looking back o-ver my shoul-der ) What about X11-based graphical installer? After the one-week rush early this month, a summary of my findings was posted on debian-boot@, including udebs, patches, and source packages, labelled as v1. People seemed to like the idea, and I received a bunch of comments to fix or improve various things. It took some time to implement everything in a satisfying (at least to me) manner, but I reached a point where I was confident enough to publish a v2 set of udebs, patches, and source packages. That was also announced on debian-boot@, and then re-announced once I ve been able to rebuild the image with speakup enabled again. Hopefully, that ll be (more or less) the final plan, and d-i folks should either give us a green or red light based on that v2 set. Some details will have to be ironed out (some items were mentioned in both v1 and v2 summaries), but they shouldn t prevent us from starting adding the needed udebs; or at least not too long. Speaking of X11, xserver-xorg-video-intel is buggy as hell! Basically, yes, and that s known. Many bugs were due to kernel issues, and regressions got fixed in the series of 2.6.32.y stable updates. Usually, upgrading to at least 2.6.32-3-$arch (from linux-2.6 s revision 2.6.32-9) helps, as well as running latest libdrm, xserver-xorg-core, and mesa from sid. Trying with some 2.6.33-ish kernels from experimental would be nice as well. You re of course very welcome to keep us posted through the bugs you opened already, closing them if appropriate. And before reporting more bugs, please make sure you re running recent versions of all those components. That should help people walking the list of remaining bugs to deal with them more efficiently. A very annoying bug which can still be experienced with an up-to-date sid environment is described in freedesktop s #26723.

DebConf 11 will be held in Banja Luka, Bosnia and Herzegovina. Munich, Germany arrived on a close second and our bid, Quito, Ecuador, arrived last, allegedly because some points flipped over since DC 11 was meant to happen in Europe. So, after having three DebConfs hosted in America in the last four years, DebConf 11 will travel to Europe in 2011! Good news for all our fellow DDs and contributors over there. The Banja Luka team managed to get an important support from their Government. They even met with the Prime Minister and got him to sign an offer of full support. I think this becomes dangerous for a DebConf, given that I ve worked and have had mishaps while funding conferences with at least three governments (Ecuador, Venezuela and Brazil) with stronger levels of support (Law-like level) for free software and I know that at least other two governments in the World have unfortunately done this in the past. So we need backup plans and lots of follow-up activities with the stakeholders. However, this agreement sets an important milestone in government support for free and open source software as well as Debian. I ll use it in my Debian slides, and congratulations! IMO, Munich would have made a great host for DC11 in terms of air travel connectivity, at a bigger hit on local costs, but nothing that would differ that much from DC7, though! I don t think I ll be able to make it at this moment to Bosnia (struggling for NYC) and at this point it s premature to think on supporting Quito s again for DC12. People and sponsors get gradually tired, even with spiritual commitment. The DC10 decision meeting was long and lots of things needed to be improved. At that moment I thought the Project learnt useful lessons for future meetings, but we re repeating ourselves now on the DC11 decision meeting. And now, I m just hoping for the best, for the sake of the time and sanity of all us here. Ditch the priority list altogether, increase the stakeholders on the global team, filter bids early in the process and use more technology to improve the information flow before the decision!

Debconf11 This evening, the final decision on which city will host Debconf11 next year will be taken. For the last half year, mostly Andreas Barth, Jan-Marek Glogowski and I have been working hard to make the Munich bid as good as possible. One thing we wanted to make clear from the beginning was that we would go for a conference in the city center - not some conference center in some nearby village or in an industrial area far away from where the city life happens. It was not easy, since the german-wide decision, we had to reshuffle venue plans a couple of times. In the end, thanks to Jan-Marek, we managed to get an excellent venue offer. Our bid consits mostly of:

• Venue: Computer Science building (recently built) of Munich University for Applied Science, we can get as much as we need, for free. The only thing we would have to pay for is additional security personell during the night.
• Network: Leibniz Rechenzentrum is the operator of the Munich Research Network (MWN), the venue is connected with at least 1 GBits fibre optics, and the MWN is connected to X-Win at the same speed. This will be free as well.
• Food: We can either take up the offer from the Studentenwerk, the organisation operating the university restaurants. Of course, the quality is not like in a Michelin-star restaurant, but I have eaten there for several years during my studies and it is on par with previous Debconf offerings. Alternatively, we could look into food catering.
• Accomodation: We tend to go for hostels, similar to Edinburgh, probably 4-6 bed dorms. Munich is pretty expensive for lodging, so this is something we decided early on to keep the costs reasonable. Again, I think this is in line with previous Debconfs. Of course, hotels at a broad price range are available.

The biggest strong points about Munich are, in my opintion:

• Our local team has lots of experience with Debian and Debconfs, as well as organizing conferences
• We have government support via the LiMux-project, and the city mayor of Munich, Christian Ude, has agreed to be the patron of the conference
• Munich is very easy to get to, both for european (via train or car) or american/asian attendees (via plane). The airport is one of the biggest in europe and has direct connections to e.g. Atlanta, New York, Boston, San Fransisco, Los Angeles, Sao Paulo and Tokio.
• Network connection via LRZ/MWN/X-WIN should be superb, especially to Debian machines hosted at euro

It the end, it seems Banja Luka seems to have the stronger bid, especially due to their 150000 EUR governemnt sponsorship. We will see who wins, I believe we did the best we could.

update: success, I got a copy. This means by talk will be that much better. Thank you all! So I am giving for the upteeenth time (but I am going to retire it!) my talk on Anonymous and Scientology next week and I have decided that I want to show a clip from the South Park episode on the topic - Trapped in the Closet Season 9, Episode 12 (Original Air Date: 11/16/2005). I made the mistake of buying it on Amazon cuz it is super DRM-FSKCING-ED and I can t play it on Linux and I don t know how to crack it. Anyway I also want to cut it to the relevant part, which is the wonderful history of Scientology. Does anyone have a copy free of DRM? Or point me to where I can find one? This is within the purview of fair use, given that I am a serious academic giving serious attention to this topic :-). Any help or pointers appreciated!

update: success, I got a copy. This means by talk will be that much better. Thank you all! So I am giving for the upteeenth time (but I am going to retire it!) my talk on Anonymous and Scientology next week and I have decided that I want to show a clip from the South Park episode on the topic - Trapped in the Closet Season 9, Episode 12 (Original Air Date: 11/16/2005). I made the mistake of buying it on Amazon cuz it is super DRM-FSKCING-ED and I can t play it on Linux and I don t know how to crack it. Anyway I also want to cut it to the relevant part, which is the wonderful history of Scientology. Does anyone have a copy free of DRM? Or point me to where I can find one? This is within the purview of fair use, given that I am a serious academic giving serious attention to this topic :-). Any help or pointers appreciated!

If you want to help the Debian/GNOME team, now is the time. For two days, we are going to triage as many bugs as possible. I have prepared a little wiki page that explains what you need to help and how to start. Of course, the team members will remain available on IRC to give advice.

We had a visitor on #mono today who needed help with his homework. It seems that Reggie is happy to have forgotten everything about using ODBC to connect to MySQL. I was curious and feeling helpful, so I figured it out. Install the MySQL ODBC driver $ sudo apt-get install libmyodbc You can also grab the package directly from MySQL Configure the MySQL ODBC driver ODBC looks in /etc/odbcinst.ini for driver configuration. In order to let it know about the MySQL ODBC libraries, append the following to your /etc/odbcinst.ini file:

[MySQL]
Description	= MySQL driver
Driver	= /usr/lib/odbc/libmyodbc.so
Setup		= /usr/lib/odbc/libodbcmyS.so
CPTimeout	=
CPReuse	=

Configure your DSN If you expect that you will be using this database connection often, you may want to create a short name for it, so you don t have to enter all of the parameters every time you want to connect. ODBC uses something called DSNs (Data Source Names, if I recall correctly) to make it easier on the user. If you want to create a DSN, append something like the following to your /etc/odbc.ini file:

[myodbc3]
Driver       = MySQL
Description  = MySQL ODBC 3.51 Driver DSN
Server       = mysql
Port         =
User         = testuser
Password     = password
Database     = test
Option       = 3
Socket       =

You will also need to update the ODBC Data Sources list near the top of the file to mention the new DSN:

[ODBC Data Sources]
myodbc3     = MySQL ODBC 3.51 Driver DSN

C ODBC connection example Here is some example code to get you connected:

using System;
using System.Data;
using System.Data.Odbc;
class ODBCTest  
  public static void Main(String[] args)  
    // Connection string using explicit parameters
    string ConStr = String.Format(
      "DRIVER= 0 ;SERVER= 1 ;DATABASE= 2 ;UID= 3 ;PWD= 4 ",
      " MySQL ","mysql","test","testuser","password" );
    // Connection string using DSN
//  string ConStr = String.Format("DRIVER= 0 ;DSN= 1 ",
//                                " MySQL ","myodbc3");                       
    //Create the connection object
    var OdbcCon = new OdbcConnection( ConStr );
    try  
      Console.Write("Opening connection... ");
      //open the database connection
      if (OdbcCon.State == ConnectionState.Closed)
        OdbcCon.Open();
      Console.WriteLine("connection opened!");
      catch (OdbcException Ex)  
      Console.WriteLine(Ex.Message);
      finally  
      //close the database connection
      OdbcCon.Close();
     
   
 

I am MJ Ray and I have not blogged for a week</bloggers-anonymous> Sorry about that. Basically, it s been hectic and I don t want to write about some of the things that have been going on between the co-op and its clients (nothing bad for our co-op, don t worry!), but I ve one tip and one request which I d like to write about now. The tip: make disaster recovery plans! Have both a general set of principles and specific plans for any mission-critical services. Think about reasonably common sources of problems and try to set policies to minimise the risk. For example, would unauthorised access to your social media accounts be a problem? If so, teach your workers not to enter their usernames and passwords into sites linked from direct messages, like in the latest example. For another example, do your workers have authentication details for your key servers? Plan what you will do about those passwords if a worker vanishes for a few days without warning after an argument at work. The request: I m meeting North Somerset Enterprise Agency about cooperatives and local strategic partnership representation does anyone have tips or advice about this, please? If so, please leave me comments.

After a whole bunch of drastic changes, lots of bugfixes, rewriting and refactoring, I released DAViCal 0.9.8 on Christmas day last year. I didn't release it very publicly, because I knew it sucked significantly. In an increasingly fast turnaround I've subsequently released 0.9.8.1 to a somewhat wider audience while I was at the recent Calendaring and Scheduling Consortium meeting in Costa Mesa at the beginning of the month. Earlier this week I released 0.9.8.2 to the more interested of the DAViCal userbase. So finally, yesterday, I released DAViCal 0.9.8.3 to fix the few significant problems that were left with that, and this is the release that I'm telling everyone about, because I believe it should be a good stable platform to people who want to upgrade their production DAViCal servers, or who have been hanging back from using DAViCal until the platform was a little more stable.
<!--break-->
This release marks some significant departures from previous DAViCal. I've decided to walk away from some of the more ancient legacy software I tried to work with in the past (PHP4 & PostgreSQL 7.x), to move to support the most ancient-but-not-superseded legacy Linux release I know of, which is CentOS / RHEL, so DAViCal now has a minimum requirement of PHP 5.1 & PostgreSQL 8.1. The biggest changes to DAViCal are under the covers. It is server software, after all, so the largest changes often are not visible on the surface. What has changed is that the architecture for constructing responses as been refactored into a core object which is used to access any DAV resource in the system. This greatly simplifies the general coding and reduces a fair bit of code duplication which had been happening. Another long overdue change is to get rid of the old arcane & obtuse permissions model, replacing it with something which will be radically faster in installations with more than a few hundred users, as well as being more consistent, easier for people to control, and directly in alignment with the DAV ACL specification. Some of the work here was assisted by NZ Registry Services who gave me a Macbook to help with my compatibility testing. Not all of the changes are under the covers though. The new DAViCal also has a thoroughly revised administrative interface, and over the last couple of releases I've gone through the system trying to uncover all the places which were not properly localisable, too, so if you see DAViCal displaying strings in a language you didn't configure it for, it should be a fixable thing. I'd like to particularly thank Masahiro Mikami for turning around some Japanese translations very quickly which enabled me to quickly and visually see what was not properly translatable. There's still more work to do (there's always more work to do) but a fully translated DAViCal should, I hope, be quite usable by non-English speakers now. The new DAViCal also supports some rather significant extra functionality beyond the CalDAV standard, in particular we can thank Rob 'Cave' Ostensen for providing an implementation of pub/sub event change notifications. This version also supports draft 2 of the proposed WebDAV synchronisation standard - that's still under development, but we expect to track pretty close to released versions of that. Of course with all of this work there are some areas that didn't get changed. I didn't manage to finish an implementation of the scheduling extensions draft, much as I would have liked, but that is going to become very much a focus in the coming couple of months, and I'll be calling it "1.0" when things settle down after we get that done. Other things I will be working on include a ticketing system for providing targeted, controlled access to a specific collection or event, and making a start on CardDAV support for addressbook storage. DAViCal seems to be fitting a need for people, and I know there are several thousand installations around the world, even if I'm not sure where they all are. I know some people are running DAViCal on their 8-way server, where I've no doubt it gurgles along pretty happily, and that there are some people running it on their OpenWRT installation, with some tiny amount of resources - just enough for a family calendar. Traffic on the wiki has increased to several hundred thousand hits per month, perhaps three times what it was a year ago, and I hope that I can continue to provide a valuable and useful piece of infrastructure for that little calendaring corner of your organisation. What heartens me the most in this ongoing experience is the nascent community that appears to be forming around my software, with people writing 'tip sheets' and helping to answer questions on the IRC channel and mailing list. These small contributions made by many people - people whom I have never met, for the most part - are enabling me to put more time into feature development and expansion, and that's what I really love.

This afternoon, a box arrived from Advanced Circuits, containing 108 fully assembled TeleDongle boards! This is not only the first "intended for sale" build of hardware from the Altus Metrum family of projects, it's also the first time that I've ever sent out one of my board designs for someone else to assemble. I therefore approached the turn-on and test of the first board out of the box with more than a little trepidation... fortunately, for no reason! I'm immensely pleased to report that TeleDongle serial number 100 turned on and works entirely as expected! I celebrated by packaging it in a cool little Hammond translucent blue plastic box with a USB cable, yielding the first prototype of a fully packaged TeleDongle board such as we anticipate selling for use receiving data from rockets carrying TeleMetrum boards. We also intend to sell these boards as-is (flashed with default firmware and measured oscillator cal value) to folks who'd like a robust wireless link for their next microcontroller project, whether rocket-related or not. I will, of course, post something here when we're ready to start taking orders. Now we just need the weather to cooperate long enough to log more test flights of TeleMetrum. The new version looks great so far, but I want a few more flights before I'll be confident enough to place an order with our assembler for a run of those too... Stay tuned!

At the FSF's Libre Planet conference this year in March, there will be a track focusing on increasing the participation of women in free software. If you are able and support this cause, consider donating to fund additional women's travel to this event. Being able to meet in person with other people like you is such an energizing opportunity. Give this gift to someone who wouldn't otherwise be able to make it!

This is what I set up for backups recently using a cheap USB-enclosure which can house 2 SATA disks and shows them as 2 USB mass-storage devices to my system (using only one USB cable). Without any further introduction, here goes the HOWTO: First, create one big partition on each of the two disks (/dev/sdc and /dev/sdd in my case) of the exact same size. The cfdisk details are omitted here.

  $ cfdisk /dev/sdc
  $ cfdisk /dev/sdd

Then, create a new RAID array using the mdadm utility:

  $ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1

The array is named md0, consists of the two devices (--raid-devices=2) /dev/sdc1 and /dev/sdd1, and it's a RAID-1 array, i.e. data is simply mirrored on both disks so if one of them fails you don't lose data (--level=1). After this has been done the array will be synchronized so that both disks contain the same data (this process will take a long time). You can watch the current status via:

  $ cat /proc/mdstat
  Personalities : [raid1]
  md0 : active raid1 sdd1[1] sdc1[0]
        1465135869 blocks super 1.1 [2/2] [UU]
        [>....................]  resync =  0.0% (70016/1465135869) finish=2440.6min speed=10002K/sec
  unused devices: 

Some more info is also available from mdadm:

  $ mdadm --detail --scan
  ARRAY /dev/md0 metadata=1.01 name=foobar:0 UUID=1234578:1234578:1234578:1234578
  $ mdadm --detail /dev/md0
  /dev/md0:
          Version : 1.01
    Creation Time : Sat Feb  6 23:58:51 2010
       Raid Level : raid1
       Array Size : 1465135869 (1397.26 GiB 1500.30 GB)
    Used Dev Size : 1465135869 (1397.26 GiB 1500.30 GB)
     Raid Devices : 2
    Total Devices : 2
      Persistence : Superblock is persistent
      Update Time : Sun Feb  7 00:03:21 2010
            State : active, resyncing
   Active Devices : 2
  Working Devices : 2
   Failed Devices : 0
    Spare Devices : 0
   Rebuild Status : 0% complete
             Name : foobar:0  (local to host foobar)
             UUID : 1234578:1234578:1234578:1234578
           Events : 1
      Number   Major   Minor   RaidDevice State
         0       8       33        0      active sync   /dev/sdc1
         1       8       49        1      active sync   /dev/sdd1

Next, you'll want to create a big partition on the RAID device (cfdisk details omitted)...

  $ cfdisk /dev/md0

...and then encrypt all the (future) data on the device using dm-crypt+LUKS and cryptsetup:

  $ cryptsetup --verbose --verify-passphrase luksFormat /dev/md0p1
  Enter your desired pasphrase here (twice)
  $ cryptsetup luksOpen /dev/md0p1 myraid

After opening the encrypted container with cryptsetup luksOpen you can create a filesystem on it (ext3 in my case):

  $ mkfs.ext3 -j -m 0 /dev/mapper/myraid

That's about it. In future you can access the RAID data by using the steps below. Starting the RAID and mouting the drive:

  $ mdadm --assemble /dev/md0 /dev/sdc1 /dev/sdd1
  $ cryptsetup luksOpen /dev/md0p1 myraid
  $ mount -t ext3 /dev/mapper/myraid /mnt

Shutting down the RAID:

  $ umount /mnt
  $ cryptsetup luksClose myraid
  $ mdadm --stop /dev/md0

That's all. Performance is shitty due to all the data being shoved out over one USB cable (and USB itself being too slow for these amounts of data), but I don't care too much about that as this setup is meant for backups, not performance-critical stuff.