The Opera-Mini Dispute I have just read an interesting article about the Opera browser [1]. The article is very critical of Opera-Mini on the iPhone for many reasons most of which don t interest me greatly. There are lots of technical trade-offs that you can make when designing an application for a constrained environment (EG a phone with low resolution and low bandwidth). What does interest me is the criticism of the Opera Mini browser for proxying all Internet access (including HTTPS) through their own servers, this has been getting some traction around the Internet. Now it is obvious that if you have one server sitting on the net that proxies connections to lots of banks then there will be potential for abuse. What apparently isn t obvious to as many people is the fact that you have to trust the application. Causes of Software Security Problems When people think about computer security they usually think about worms and viruses that exploit existing bugs in software and about Trojan horse software that the user has to be tricked into running. These are both significant problems. But another problem is that of malicious software releases. I think that this is significantly different from Trojan horses because instead of having an application which was written for the sole purpose of tricking people (as is most similar to Greek history) you have an application that was written by many people who genuinely want to make a good product but you have a single person or small group that hijacks it. Rumor has it that rates well in excess of $10,000 are sometimes paid for previously unknown security vulnerabilities in widely used software. It seems likely that a programmer who was in a desperate financial situation could bolster their salary by deliberately putting bugs in software and then selling the exploits, this would not be a trivial task (making such bugs appear to be genuine mistakes would take some skill) but there are lots of people who could do it and plausibly deny any accusation other than carelessness. There have been many examples of gambling addicts who have done more foolish things to fund their habit. I don t think it s plausible to believe that every security flaw which has been discovered in widely used software was there purely as the result of a mistake. Given the huge number of programmers who have the skill needed to deliberately introduce a security flaw into the source of a program and conceal it from their colleagues I think it s quite likely that someone has done so and attempted to profit from it. Note that even if it could be proven that it was impossible to profit from creating a security flaw in a program that would not be sufficient to prove that it never happened. There is plenty of evidence of people committing crimes in the mistaken belief that it would be profitable for them. Should We Trust a Proprietary Application or an Internet Server? I agree with the people who don t like the Opera proxy idea, I would rather run a web browser on my phone that directly accesses the Internet. But I don t think that the web browser that is built in to my current smart-phone is particularly secure. It seems usual for a PC to need a security update for the base OS or the web browser at least once a year while mobile phones have a standard service life of two years without any updates. I suspect that there is a lot of flawed code running on smart phones that never get updated. It seems to me that the risks with Opera are the single point of failure of the proxy server in addition to the issues of code quality while the risks with the browser that is on my smart-phone is just the quality of the code. I suspect that Opera may do a better job of updating their software to fix security issues so this may mitigate the risk from using their proxy. At the moment China is producing a significant portion of the world s smart-phones. Some brands like LG are designed and manufactured in China, others are manufactured in China for marketing/engineering companies based in Europe and the US. A casual browse of information regarding Falun Gong makes the character of the Chinese leadership quite clear [2], I think that everything that comes out of China should be considered to be less trustworthy than equivalent products from Europe and the US. So I think that anyone who owns a Chinese mobile phone and rails against the Opera Mini hasn t considered the issue enough. I don t think it s possible to prove that an Opera Mini with it s proxy is more or less of a risk than a Chinese smart-phone. I m quite happy with my LG Viewty [3] but I wouldn t use it for Internet banking or checking my main email account. Also we have to keep in mind that mobile phones are really owned by telephone companies. You might pay for your phone or even get it unlocked so you can run it on a different network, but you won t get the custom menus of your telco removed. Most phones are designed to meet the needs of telcos not users and I doubt that secure Internet banking is a priority for a telco. Update: You can buy unlocked mobile phones. But AFAIK the Android is the only phone which might be described as not being designed for the needs of the telcos over the needs of the users. So while you can get a phone without custom menus for a telco, you probably can t get a phone that was specifically designed for what you want to do. The Scope of the Problem Mobile phones are not the extent of the problem, I think that anyone who buys a PC from a Chinese manufacturer and doesn t immediately wipe the hard drive and do a fresh OS install is taking an unreasonable risk. The same thing goes for anyone who buys a PC from a store where it s handled by low wage employees, I can imagine someone on a minimum income accepting a cash payment to run some special software on every PC before it goes out the door that wouldn t be any more difficult or risky than the employees who copy customer credit card numbers (a reasonably common crime). It s also quite conceivable that any major commercial software company could have a rogue employee who is deliberately introducing bugs into it s software. That includes Apple. If the iPhone OS was compromised before it shipped then the issue of browser security wouldn t matter much. I agree that having the minimum possible number of potential security weak points is a good idea. They should allow Opera Mini users to select that HTTPS traffic should not be proxied. But I don t think that merely not using a proxy would create a safe platform for Internet banking. In terms of mobile phones most things are done in the wrong way to try and get more money out of the users. Choose whichever phone or browser you want and it will probably still be a huge security risk. Harald Welte is doing some really good work on developing free software for running a GSM network [4]. But until that project gets to the stage of being widely usable I think that we just have to accept a certain level of security risk when using mobile phones.

• [1] http://counternotions.com/2010/02/18/mini/
• [2] http://www.faluninfo.net/
• [3] http://etbe.coker.com.au/2009/05/31/lg-u990-viewty/
• [4] http://laforge.gnumonks.org/weblog/2010/02/13/#20100213-six_weeks_to_bcch

As some people had problems finding our booth, here's a small explanation. We are guest at the booth of Univention in Hall 2, stand B36. It's quite near to the north entry, where you arrive by the tram lines 8 and 18. Look for the univention booth:

If you are direct in front of the Univention booth, we are on the right hand side of the booth:

If you come from the other side, from the rest of the Open Source Area, it looks like this:

PS: And now, dear zobel, you have three guesses, what Pia is going to get for her birthday...

I spent the day working with Daniel. He has been trying to get the correct runes for a GCC build in a strange environment. Turns out all he needed was me to throw stupid ideas at him until one caused him to examine some of the generated intermediate symbol maps...

RCBW - #23 Wacky week, last week. Not only I've (almost) completed my moving to the new house, but we have also had guests in the lab for some full-immersion-paper-writing. That had left very little time for RC squashing, but I've catched up a bit in the week-end. Without any further ado, here are this week's squashes:

• bug #516336 - haskell-utils - requested removal (superseded by haskell-devscripts)
• bug #547278 - elvis - downgrade, unwarranted RC severity
• bug #559833 - imagemagick - libltdl CVE, investigated and closed as false positive
• bug #567706 - mailcrypt - drop support for emacs flavours older than 23
• bug #547810 - ccsm - fix FTBFS with python 2.6
• bug #571185 - padre - requested removal from testing
• bug #561524 - pyjamas - fix FTBFS with python 2.6 (Ubuntu patch by Fabrice Coutadeur)

Random points:

• call for help, if you are a libtool guru there is some work for you: bugs like bug #559822 need your help (very old code, using very old libltdl stuff, need to be ported to recent, non-buggy libltdl code and to use the system copy of the library ...).
• my personal RC bug monitor (hence very biased) currently reports 278 RC bugs. Also, I've the impression that the ratios of new bugs coming in vs ancient ones getting fixed equate. If that is true, it would be a pity not to freeze this month.
  ... what are you doing here? still reading this blog post? go squash a RC bug!

In totally unrelated news: I've bought my ticket for DebConf10 (YAY!), according to my usual debconf customs: 4 days of debcamp + all the conf. See you there (in a while). ... and congrats to Adnan for the winning DebConf11 bid!

Experimental 2.6.33 will do the switch to UUID based root args, if you haven't switched already. Please test it out and report bugs on it, before we add the libata switch to squeeze 2.6.32. 2.6.32-9 includes 2.6.32.9 and several other fixes. For the following 2.6.32-10 Ben Hutchings pulled in newer drm for lots of intel fixes: Status of kernel X drivers. It also features radeon and nouveau KMS modules. Current 2.6.32 is stabilizing well and we are seeing lots of external patches lining up. Update: Sorry due to jet lag got aboves version number wrong. You might want also to checkout: The season I have mostly been building kernels.

Protecting our privacy is important. For example, I wouldn't like if my mailing list subscriptions get known to anybody else (except the relevant listmasters of course as part of their job), for the simple reason that this is just my own decisions which lists I get mail from (and read, but that's not necessarily the same). This is an classical example of "personal information are handed out on a need-to-know-basis" (like to listmasters if necessary), and is also in line with european laws (I don't know the legal situation in other parts of the world enough). Now, publishing mailing list subscriptions hased sounds like an good idea to protect privacy. But if thinking twice, this just doesn't work. Most peoples subscription addresses could be known by other means or are even the addresses they use for sending mails (some systems even enforce this). So this is a huge privacy fail. Getting back to debian, and speaking the obvious out: The new interface to udd is just broken and wrong. Please remove all my adresses from being displayed, either in direct or hashed form, even in restricted mode. Thanks.

I was reminded this morning after a bit of chatter on #debian-cli that my previous write-up on setting one s locale on Ubuntu is out-of-date. Instead of running dpkg-reconfigure locales and selecting your locale, the new incantation is as follows: Magic

$ sudo locale-gen en_US.UTF-8

Environment Variables You ll also want to set some environment variables. Put something like the following in your ~/.bashrc:

LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_ALL=en_US.UTF-8
export LANG LANGUAGE LC_CTYPE LC_MESSAGES LC_ALL

You would of course replace en_US.UTF-8 with whichever locale you want to generate.

We re in the middle of Fairtrade Fortnight and it seems like the most advertised one yet, with Cadbury s adverts joining the push of this year s big swap theme: replace some of the stuff you d usually buy with Fairtrade alternatives. For IT workers, this is easier said than done. It s difficult enough to find more sustainably-produced products, let alone fairtrade ones. Our co-op has failed to achieve full marks on Prioritise and promote Fairtrade and other ethical and sustainable initiatives so far and I don t expect us to reach 100% any time soon. Just last Friday, Greenpeace International reported on more toxic electrical equipment, which shows that IT s environmental sustainability is far from a solved problem. Meanwhile, it doesn t seem like the fairness side is being addressed much yet. There are no fairtrade electrical product standards yet. Isn t there demand for fairer as well as greener production? Anyway, if you re looking for faitrade products this fortnight, you could try some fairtrade chocolate from the New Internationalist worker co-op. Food is further along, which is a good thing because it s pretty fundamental to life

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

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

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.

During last weeks I finally got upset with state of developer documentation for Gammu and python-gammu. Not that it would be non existing, but it was spread over various places in various formats and partially outdated. I decided to write all documentation in Shpinx as I know this tool and it seems to fit quite well in mixed C/Python environment. The first step was to migrate existing docs into same format (reStructuredText) and create documentation structure. I believe this is now completed and you can check results here. Yes there are still lot of rough edges and lot of work to do, but I anyway think that current state is better then mess we used to have before.

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.

The most common criticism of the Anti-Counterfeiting Trade Agreement (ACTA) is the lack of transparency. Before the nations disclose the terms of the agreement under negotiation, we are unable to gain an idea of the big picture, let alone voice our opinions and push for changes. Our politicians don t want us to know. We rely on leaked documents for our information. This is backwards in a world where a state should represent its people. This smells foul to me. There are undoubtedly some good reasons for the treaty, and if we can contain worldwide, large-scale trade of counterfeited goods and medicine, then that would be a net benefit to us all. However, we must not allow certain governments to succomb to the pressure of (commercially-motivated) lobbyists, to extend that pressure onto other nations using trade as a means of pressure, and to slash our freedom as if it were an inconvenient obstacle in their way. Only if the terms under negotiation become publicly available, and the public is given a voice, then we can help our governments in entering an agreement that is in the interest of its people, rather than a threat to us. It is hardly surprising that total capitalist nation USA are the strongest opponents of transparency, because the public might delay or even prevent the treaty. I was also not surprised to see South Korea and Germany in the list of supporters of secrecy either. It is interesting to see that the leaders of Singapore, Belgium, Portugal, and Denmark also seem to believe that these negotiations should be withheld from the public. Does anyone know about Switzerland? I tip my hat to New Zealand, Canada, Australia, Netherlands, Sweden, Finland, Ireland, Hungary, Poland, Estonia, and Austria for their support of transparency.

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.

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.

In the past, several of my Puppet modules have been tightly coupled. A perfect example is Apache and Munin. When I install Apache, I want munin graphs set up. As a result my apache class has the following snippet in it:

munin::plugin   "apache_accesses":  
munin::plugin   "apache_processes":  
munin::plugin   "apache_volume":  

This should make sure that these three plugins are installed and that munin-node is restarted to pick them up. The define was implemented like this:

define munin::plugin (
      $enable = true,
      $plugin_name = false,
      )  
   include munin::node
   file   "/etc/munin/plugins/$name":
      ensure => $enable ?  
         true => $plugin_name ?  
            false => "/usr/share/munin/plugins/$name",
            default => "/usr/share/munin/plugins/$plugin_name"
          ,
         default => absent
       ,
      links => manage,
      require => Package["munin-node"],
      notify => Service["munin-node"],
    
 

(Note: this is a slight simplification of the define). As you can see, the define includes munin::node, as it needs the definition of the munin-node service and package. As a result of this, installing Apache drags in munin-node on your server too. It would be much nicer if the apache class only installed the munin plugins if you also install munin on the server. It turns out that is is possible, using virtual resources. Virtual resources allow you to define resources in one place, but not make them happen unless you realise them. Using this, we can make the file resource in the munin::plugin virtual and realise it in our munin::node class. Our new munin::plugin looks like:

define munin::plugin (
      $enable = true,
      $plugin_name = false,
      )  
   # removed "include munin::node"
   # Added @ in front of the resource to declare it as virtual
   @file   "/etc/munin/plugins/$name":
      ensure => $enable ?  
         true => $plugin_name ?  
            false => "/usr/share/munin/plugins/$name",
            default => "/usr/share/munin/plugins/$plugin_name"
          ,
         default => absent
       ,
      links => manage,
      require => Package["munin-node"],
      notify => Service["munin-node"],
      tag => munin-plugin,
    
 

We add the following line to our munin::node class:

File<  tag == munin-plugin  >

The odd syntax in the munin::node class realises all the virtual resources that match the filter, in this case, any that is tagged munin-plugin. We've had to define this tag ourself, as the auto-generated tags don't seem to work. You'll also notice that we've removed the munin::node include from the munin::plugin define, which means that we no longer install munin-node just by using the plugin define. I've used a similar technique for logcheck, so additional rules are not installed unless I've installed logcheck. I'm sure there are several other places where I can use it to reduce such tight coupling between classes.

After getting sick of having to underclock my existing home server to get it to remain up for any period of time, along with the horrendous noise, I finally found the time and budget to rebuild. My goals were:

• Quiet enough to have in the living room
• Cool enough to live inside the TV cabinet with little ventilation
• Large, redundant storage
• Powerful enough to re-encode video
• As power efficient as possible

In the end I went with

• Antec NSK 1380
• Asus AT3N7A-I motherboard with a dual-core Atom 330 CPU and Nvidia chipset
• 4GB of RAM (for which I am still waiting for the mail-in rebate, as usual!)
• 1 Western Digital Green 1TB SATA disk
• 1 Samsung Ecogreen 1TB SATA disk
• 30GB Patriot SATA SSD
• Recycled DVD writer + PCI IDE card

The case is really awesome. Very easy to access, and the fan is extremley quiet. It very cleverly holds 3 full-size hard-disks; two mounted vertically on either side, and one horizontally in the middle. The final space is for a DVD -- after that it's pretty cramped inside! It makes claims it is a very efficient power supply. It has a very bright blue LED on the front, and the face-plate over the DVD looks nice but the button doesn't quite reach the eject button on my drive, so it's software eject only. All over, definitely recommend. The motherboard is fairly good. One annoying thing is that it only has 3 SATA ports -- I think it's reasonable to want to have a primary drive, two mirrored large disks plus a DVD for a nice little media server. It also has no parallel-IDE, which is reasonable these days. However, if you wanted to install a wireless card you'd be out of luck if you also wanted to put in another SATA card, as it only has one PCI slot. There are plenty of USB ports for a USB wireless card, however. It also comes with two SATA cables, which isn't mentioned anywhere I could see (hopefully this saves you a trip back to Fry's to return your extra cables :). The CPU fan is a little on the loud side, as mentioned in some other forums. It is also located right where the power supply cables come down in this case, making for a fairly tight fit. Here's a lspci for those interested in such things I know there are issues with the controller of the Patriot SSD, which would probably worry me for a general purpose machine. However for the primary disk of a server machine I'm not too fussed. The silence is golden and cool-running and low power consumption really helps too. I wouldn't really say it seems that blazing fast. It comes with a handy mount so it fits in a full-size hard-disk slot. Hard to beat for the price. One concession I made to avoid excessive writes was mounting /tmp on tmpfs; this is where it's nice to have 4GB of RAM. Handbrake seems to do a lot of work in /tmp for example. The two green hard-disks (software mirrored) are also inaudible. I'm hoping different brands should at least not fail at the same time. I'm not sure if they're auto-spinning down, but you can't really tell if they're on or not, even under load. Even when running flat-out re-encoding a DVD in the enclosed cabinet with minimal airflow the CPU temperature hasn't gone above 60C; normal CPU temp is around 40C. Performance is adequate -- running PlayOn in a VMware workstation XP VM almost works. It's kind of hard to take photos inside a case, but here's an attempt: <object height="300" width="400"> <param name="flashvars" value="offsite=true&amp;lang=en-us&amp;page_show_url=%2Fphotos%2Fiwienand%2Fsets%2F72157623509152266%2Fshow%2F&amp;page_show_back_url=%2Fphotos%2Fiwienand%2Fsets%2F72157623509152266%2F&amp;set_id=72157623509152266&amp;jump_to="> <param name="movie" value="http://www.flickr.com/apps/slideshow/show.swf?v=71649"> <param name="allowFullScreen" value="true"><embed allowfullscreen="true" flashvars="offsite=true&amp;lang=en-us&amp;page_show_url=%2Fphotos%2Fiwienand%2Fsets%2F72157623509152266%2Fshow%2F&amp;page_show_back_url=%2Fphotos%2Fiwienand%2Fsets%2F72157623509152266%2F&amp;set_id=72157623509152266&amp;jump_to=" height="300" src="http://www.flickr.com/apps/slideshow/show.swf?v=71649" type="application/x-shockwave-flash" width="400"></embed></object> Debian unstable installed without issues (except for some weird bug with the boot hanging for 60 seconds due to the RTL driver). It is also very strange installing from USB to an SSD no noise!