Warning: this is a rant against BSD (specifically FreeBSD , but don t let me get started on DragonFly, who think it s wise to drop all shells except ash from the base system and rely on pkgsrc yay let s compile a dozen packages just to get a shell with tab completion, not to mention boxen with no network access for the task although others seem to go into that direction too ; you know, there s BSD, and then there s FreeBSD ) don t like, don t read. If you want to change something in the BSD world, you gotta fork your own BSD no other way around the thickheads. Ok, back then, I ran into a particularily thick one, but others tend to not be much better. Users share the thickness. If you want to change something in the GNU/Linux world, just make a package, have someone upload it, prod (or pay, Hanno got a Radler) people to do it, or just upload it yourself. At the BSD booth at FOSDEM, despite me bringing the Windows Mobile 6 Professional devive, strictly for Geocaching mind you, Macintosh boxen had a share of more than 50% I didn t manage to tip the scale. At the Debian booth, almost everyone had a I want to buy a new laptop some day, but it just keeps on working and doesn t break pre-Lenovo IBM laptop. No hyping of Google either. (Last year s CLT saw BSD people advocating pro-Schily the guy with the broken encoding in his name shockingly.) Honestly, tcsh, FreeBSD people? Sorry. While I agree that there is merit on having the same script and interactive shell, as someone has pointed out (copy-paste examples into the command line), there s those zsh users who use mksh or GNU bash for scripting. Or just POSIX shell. And that s with an interactive shell which can be used for scripting. On the other hand, the C shell (both csh and tcsh) cannot. And what s with pretending the accent gravis is non-combining, called backtick (such a thing does not exist); and advocating it? Sorry, if your csh/tcsh doesn t handle the POSIX $( ) you should just drop it. (By the way, there is a convention that example command lines are prefixed with % for csh and $ for sh (or # but we write $ sudo instead, these days). Use it. Or leave it. If you have examples that substitute another process output, be specific.) It s funny to see how one person tries to defuse my arguments against csh by telling me it s just an interactive shell , while the other argues that people copy-paste between them, to which that was my response. Read the thread! And please, get your facts right. I would prefer that the standard shell be at least Bourne-compatible. You don t want Bourne ( ^ instead of for pipes), you want POSIX. That GNU bash is called the Bourne-Again Shell in one of their usual semi-bad puns doesn t help the global perception of such things any. Also, the root shell and /bin/sh are disjunct. (Plus, why change the root shell, use sudo(8), plain and simple.) ObNote: in jupp (should I package that for Debian, btw? rather upload, packages are ready ) the key is used as pr fix for Ctrl-X ( X) or to directly enter numerical (decimal, octal, sedecimal/hexadecadic) ASCII, 8-bit or Unicode codepoints. Yay!
And even the FSF has seen the light; for a few releases already, GCC uses ' ' instead of ' for quoting in messages, even without locales. Great job there! (LC_MESSAGES=en_GB.UTF-8 usually works, too, though.) ObDisclaimer: I have an (yes, Google ) Alert on the word mksh , so I know when it s being discussed. This obviously includes certain fora. Also, I m a shell implementer and bound to know a certain amount of details. Plus, mksh s build script runs with pretty much any Bourne/POSIX/Z Shell which has functions and not too many bugs. I wrote it. Go figure. No lowly trolling. FWIW, mksh(1) has the cat(1) builtin both because Android has no cat(1), and as speed hack. Almost all other shells have worse speed hacks, like a printf(1) builtin. And recently, builtins have become direct-callable, so this actually reduces the overall system footprint. (Its inclusion also provides for some other possibilities, internally.) And as two final side notes, if you haven t seen this: determine which shell we are run under (CVS) and I still offer a prompt conversion service (send me any GNU bash or oksh $PS1 and I ll send that to you in mksh(1) syntax optionally with adjustments/improvements, like cwd uses only up to 1/3 of screen width).

This little blog is created/compiled with Chronicle, coded by Steve Kemp, and one of the cool features is that you can specify a command run before/after your blog gets compiled from the input files. This presents us with one problem and a lot of opportunities. First to the problem: the singular "a command" (from the manual page) might not be enough. Maybe you want to run more than one command. This can be achieved by creating a directory for the commands you want to run before the compilation and one for the commands you want to run after the chronicle run. Then you create a small shell script one directory above and call that from chronicle, the script for the post-run might look like:

#!/bin/sh
set -e
WORKDIR=" dirname $ 0  /post"
find $ WORKDIR  -name "*.sh" -exec " " ";"

This script makes the assumption, that the scripts to run have a .sh suffix and are in a subdirectory named "post". But you can surely adapt this to your needs. Now to one of the oppurtunities this offers: you can now, for example, create static pages, which share the general visual appearance with your blog entries but don't show up in the tags or archive system. I'm using this to generate an imprint for this blog. The script to generate the imprint looks like:

#!/bin/sh
set -e
OUTPUT_PATH= grep output $ HOME /.chroniclerc   cut -d= -f2   tr -d [:blank:] 
sed -ne'/<\?xml version/,/blosxomFirstDayDiv/  /blosxomFirstDayDiv/b;p ' \
        $ OUTPUT_PATH /index.html > $ HOME /tmp/imprint.html
cat  dirname $ 0  /imprint.data >> $ HOME /tmp/imprint.html
echo -e "\n" >> $ HOME /tmp/imprint.html
sed -ne'/imprint_match/,$p' $ OUTPUT_PATH /index.html >> $ HOME /tmp/imprint.html
mv $ HOME /tmp/imprint.html $ OUTPUT_PATH /imprint.html

There are again some assumptions made here, which you'd need to adopt to your setup:

• I'm using a modified version of the "Copyrighteous" theme (one of the modifications was detailed yesterday).
• The script expects the output setting in your .chroniclerc.
• The content/body of the imprint is stored in a file imprint.data in the same directory as the script which generates the imprint.
• There is a tmp directory below $ HOME (this is there to cope with a chroot environment).

Now you have a very powerful system to modify/extend your chronicle-generated blog. I hope you enjoy it as much as I do! A little P.S.: you might want to use version 4.5, as 4.4 had a nasty encoding bug.

This little blog is created/compiled with Chronicle, coded by Steve Kemp, and one of the cool features is that you can specify a command run before/after your blog gets compiled from the input files. This presents us with one problem and a lot of opportunities. First to the problem: the singular "a command" (from the manual page) might not be enough. Maybe you want to run more than one command. This can be achieved by creating a directory for the commands you want to run before the compilation and one for the commands you want to run after the chronicle run. [UPDATE]Then just add run-parts /path/to/ before,post .d to your .chroniclerc for the pre,post -build configuration entries.[/UPDATE] (Thanks to Steve for pointing the obvious out to me, don't know why I didn't think of run-parts myself.) Now to one of the oppurtunities this offers: you can now, for example, create static pages, which share the general visual appearance with your blog entries but don't show up in the tags or archive system. I'm using this to generate an imprint for this blog. The script to generate the imprint looks like:

#!/bin/sh
set -e
OUTPUT_PATH= grep output $ HOME /.chroniclerc   cut -d= -f2   tr -d [:blank:] 
sed -nre'/<\?xml version/,/blosxomFirstDayDiv/  /blosxomFirstDayDiv/b;p ' \
        $ OUTPUT_PATH /index.html > $ HOME /tmp/imprint.html
cat  dirname $ 0  /imprint.data >> $ HOME /tmp/imprint.html
echo -e "\n" >> $ HOME /tmp/imprint.html
sed -ne'/imprint_match/,$p' $ OUTPUT_PATH /index.html >> $ HOME /tmp/imprint.html
mv $ HOME /tmp/imprint.html $ OUTPUT_PATH /imprint.html

There are again some assumptions made here, which you'd need to adopt to your setup:

• I'm using a modified version of the "Copyrighteous" theme (one of the modifications was detailed yesterday).
• The script expects the output setting in your .chroniclerc.
• The content/body of the imprint is stored in a file imprint.data in the same directory as the script which generates the imprint.
• There is a tmp directory below $ HOME (this is there to cope with a chroot environment).

Now you have a very powerful system to modify/extend your chronicle-generated blog. I hope you enjoy it as much as I do! A little P.S.: you might want to use version 4.5, as 4.4 had a nasty encoding bug.

Christian is a figure of Debian, not only because of the tremendous coordination work that he does within the translation project, but also because he s very involved at the social level. He s probably in the top 5 of the persons who attended most often the Debian conference. Christian is a friend (thanks for hosting me so many times when I come to Paris for Debian related events) and I m glad that he accepted to be interviewed. He likes to speak and that shows in the length of his answers but you ll be traveling the world while reading him. My questions are in bold, the rest is by Christian. Who are you? I am a French citizen (which is easy to guess unless you correct my usual mistakes in what follows). I m immensely proud of being married for nearly 26 years with Elizabeth (who deserves a statue from Debian for being so patient with my passion and my dedication to the project). I m also the proud father of 3 wonderful kids , aged 19 to 23. I work as team manager in the Networks and Computers Division of Onera the French Aerospace lab , a public research institute about Aeronautics, Space and Defense. My team provides computer management services for research divisions of Onera, with a specific focus put on individual computing. I entered the world of free software as one of the very first users of Linux in France. Back in the early 1990 s, I happened (though the BBS users communities) to be a friend of several early adopters of Linux and/or BSD386/FreeBSD/NetBSD in France. More specifically, I discovered Linux thanks with my friend Ren Cougnenc (all my free software talks are dedicated to Ren , who passed away in 1996). You re not a programmer, not even a packager. How did you come to Debian? I m definitely not a programmer and I never studied computing (I graduated in Materials Science and worked in that area for a few years after my PhD). However, my daily work always involved computing (I redesigned the creep testing laboratory and its acquisition system all by myself during my thesis research work). An my hobbies often involved playing with home computers, always trying to learn about something new. So, first learning about a new operating system then trying to figure out how to become involved in its development was quite a logical choice. Debian is my distro of choice since it exists. I used Slackware on work machines for a while, but my home server, kheops, first ran Debian 1.1 when I stopped running a BBS on an MS-DOS machine to host a news server. That was back in October 1996. I then happened to be a user, and more specifically a user of genealogy software, also participating very actively in Usenet from this home computer and server, that was running this Debian thing. So, progressively, I joined mailing lists and, being a passionate person, I tried to figure out how I could bring my own little contribution to all this. This is why I became a packager (yes, I am one!) by taking over the geneweb package, which I was using to publish my genealogy research. I applied as DD in January 2001, then got my account in July 2001. My first upload to the Debian archive occurred on August 22nd 2001: that was of course geneweb, which I still maintain. Quite quickly, I became involved in the work on French localization. I have always been a strong supporter of localized software (I even translated a few BBS software back in the early 90 s) as one of the way to bring the power and richness of free software to more users. Localization work lead me to work on the early version of Debian Installer, during those 2003-2005 years where the development of D-I was an incredibly motivating and challenging task, lead by Joey Hess and his inspiring ideas. From user to contributor to leader, I suddenly discovered, around 2004, that I became the coordinator of D-I i18n (internationalization) without even noticing You re the main translation coordinator in Debian. What plans and goals have you set for Debian Wheezy? As always: paint the world in red. Indeed, this is my goal for years. I would like our favorite distro to be able to be used by anyone in the world, whether she speaks English, Northern Sami, Wolof, Uyghur or Secwepemcts n. As a matter of symbol, I use the installer for this. My stance is that one should be able to even install Debian in one s own language. So, for about 7 years, I use D-I as a way to attract new localization contributors. This progress is represented on this page where the world is gradually painted in red as long as the installer supports more languages release after release. The map above tries to illustrate this by painting in red countries when the most spoken language in the country is supported in Debian Installer. However, that map does not give enough reward to many great efforts made to support very different kind of languages. Not only various national languages, but also very different ones: all regional languages of Spain, many of the most spoken languages in India, minority languages such as Uyghur for which an effort is starting, Northern Sami because it is taught in a few schools in Norway, etc., etc. Still, the map gives a good idea of what I would like to see better supported: languages from Africa, several languages in Central Asia. And, as a very very personal goal, I m eagerly waiting for support of Tibetan in Debian Installer, the same way we support its sister language, Dzongkha from Bhutan. For this to happen, we have to make contribution to localization as easy as possible. The very distributed nature of Debian development makes this a challenge, as material to translate (D-I components, debconf screens, native packages, packages descriptions, website, documentation) is very widely spread. A goal, for years, is to set a centralized place where translators could work easily without even knowing about SVN/GIT/BZR or having to report bugs to send their work. The point, however, would be to have this without making compromises on translation quality. So, with peer review, use of thesaurus and translation memory and all such techniques. Tools for this exist: we, for instance, worked with the developers of Pootle to help making it able to cope with the huge amount of material in Debian (think about packages descriptions translations). However, as of now, the glue between such tools and the raw material (that often lies in packages) didn t come. So, currently, translation work in Debian requires a great knowledge of how things are organized, where is the material, how it can be possible to make contribution reach packages, etc. And, as I m technically unable to fulfill the goal of building the infrastructure, I m fulfilling that role of spreading out the knowledge. This is how I can define my coordinator role. Ubuntu uses a web-based tool to make it easy to contribute translations directly in Launchpad. At some point you asked Canonical to make it free software. Launchpad has been freed in the mean time. Have you (re)considered using it? Why not? After all, it more or less fills in the needs I just described. I still don t really figure out how we could have all Debian material gathered in Rosetta/Launchpad .and also how Debian packagers could easily get localized material back from the framework without changing their development processes. I have always tried to stay neutral wrt Ubuntu. As many people now in Debian, I feel like we have reached a good way to achieve our mutual development. When it comes at localization work, the early days where the everything in Rosetta and translates who wants stanza did a lot of harm to several upstream localization projects is, I think, way over. Many people who currently contribute to D-I localization were indeed sent to me by Ubuntu contributors .and by localizing D-I, apt, debconf, package descriptions, etc., they re doing translation work for Ubuntu as well as for Debian. Let s say I m a Debian user and I want to help translate Debian in my language. I can spend 1 hour per week on this activity. What should I do to start? Several language teams use Debian mailing lists to coordinate their work. If you re lucky enough to be a speaker of one of these languages, try joining debian-l10n-<yourlanguage> and follow what s happening there. Don t try to immediately jump in some translation work. First, participate to peer reviews: comment on others translations. Learn about the team s processes, jargon and habits. Then, progressively, start working on a few translations: you may want to start with translations of debconf templates: they are short, often easy to do. That s perfect if you have few time. If no language team exists for your language, try joining debian-i18n and ask about existing effort for your language. I may be able to point you to individuals working on Debian translations (very often along with other free software translation efforts). If I am not, then you have just been named coordinator for your language I may even ask you if you want to work on translating the Debian Installer. What s the biggest problem of Debian? We have no problems, we only have solutions We are maybe facing a growth problem for a few years. Despite the increased welcoming aspects of our processes (Debian Maintainers), Debian is having hard times in growing. The overall number of active contributors is probably stagnating for quite a while. I m still amazed, however, to see how we can cope with that and still be able to release over the years. So, after all, this is maybe not a problem Many people would point communication problems here. I don t. I think that communication inside the Debian project is working fairly well now. Our famous flame wars do of course still happen from time to time, but what large free software project doesn t have flame wars? In many areas, we indeed improved communication very significantly. I want to take as an example the way the release of squeeze has been managed. I think that the release team did, even more this time, a very significant and visible effort to communicate with the entire project. And the release of squeeze has been a great success in that matter. So, there s nearly nothing that frustrates me in Debian. Even when a random developer breaks my beloved 100% completeness of French translations, I m not frustrated for more than 2 minutes. You re known in the Debian community as the organizer of the Cheese & Wine Party during DebConf. Can you tell us what this is about? This is an interesting story about how things build themselves in Debian. It all started in July 2005, before DebConf 5 in Helsinki. Denis Barbier, Nicolas Fran ois and myself agreed to bring at Debconf a few pieces of French cheese as well as 1 or 2 bottles of French wine and share them with some friends. Thus, we settled an informal meeting in the French room where we invited some fellows: from memory, Benjamin Mako Hill, Hannah Wallach, Matt Zimmermann and Moray Allan. All of us fond of smelly cheese, great wine plus some extra p t home-made by Denis in Toulouse. It finally happened that, by word of mouth, a few dozens of other people slowly joined in that French room and turned the whole thing into an improvized party that more or less lasted for the entire night. The tradition was later firmly settled in 2006, first in Debconf 6 in Mexico where I challenged the French DDs to bring as many great cheese as possible, then during the Debian i18n meeting in Extremadura (Sept 2006) where we reached the highest amount of cheese per participant ever. I think that the Creofonte building in Casar de C ceres hasn t fully recovered from it and is still smelling cheese 5 years after. This party later became a real tradition for DebConf, growing over and over each year. I see it as a wonderful way to illustrate the diversity we have in Debian, as well as the mutual enrichment we always felt during DebConfs. My only regret about it is that it became so big over the years that organizing it is always a challenge and I more and more feel pressure to make it successful. However, over the years, I always found incredible help by DebConf participants (including my own son, last year a moment of sharing which we will both remember for years, i think). And, really, in 2010, standing up on a chair, shouting (because the microphone wasn t working) to thank everybody, was the most emotional moment I had at Debconf 10. Is there someone in Debian that you admire for their contributions? So many people. So, just like it happens in many awards ceremonies, I will be very verbose to thank people, sorry in advance for this. The name that comes first is Joey Hess. Joey is someone who has a unique way to perceive what improvements are good for Debian and a very precise and meticulous way to design these improvements. Think about debconf. It is designed for so long now and still reaching its very specific goal. So well designed that it is the entire basis for Joey s other achievement: designing D-I. Moreover, I not only admire Joey for his technical work, but also for his interaction with others. He is not he loudest person around, he doesn t have to .just giving his point in discussion and, guess what? Most of the time, he s right. Someone I would like to name here, also, is Colin Watson. Colin is also someone I worked with for years (the D-I effect, again ) and, here again, the very clever way he works on technical improvements as well as his very friendly way to interact with others just make it. And, how about you, Rapha l? I m really admirative of the way you work on promoting technical work on Debian. Your natural ability to explain things (as good in English as it is in French) and your motivation to share your knowledge are a great benefit for the project. Not to mention the technical achievements you made with Guillem on dpkg of course! Another person I d like to name here is Steve Langasek. We both maintain samba packages for years and collaboration with him has always been a pleasure. Just like Colin, Steve is IMHO a model to follow when it comes at people who work for Canonical while continuing their involvment in Debian. And, indeed, Steve is so patient with my mistakes and stupid questions in samba packaging that he deserves a statue. We re now reaching the end of the year where Stefano Zacchiroli was the Debian Project Leader. And, no offense intended to people who were DPL before him (all of them being people I consider to be friends of mine), I think he did the best term ever. Zack is wonderful in sharing his enthusiasm about Debian and has a unique way to do it. Up to the very end of his term, he has always been working on various aspects of the project and my only hope is that he ll run again (however, I would very well understand that he wants to go back to his hacking activities!). Hat off, Zack!I again have several other people to name in this Bubulle hall of Fame : Don Armstrong, for his constant work on improving Debian BTS, Margarita Manterola as one of the best successes of Debian Women (and the most geeky honeymoon ever), Denis Barbier and Nicolas Fran ois because i18n need really skilled people, Cyril Brulebois and Julien Cristau who kept X.org packaging alive in lenny and squeeze, Otavio Salvador who never gave up on D-I even when we were so few to care about it. I would like to make a special mention for Frans Pop. His loss in 2010 has been a shock for many of us, and particularly me. Frans and I had a similar history in Debian, both mostly working on so-called non technical duties. Frans has been the best release manager for D-I (no offense intended, at all, to Joey or Otavio .I know that both of them share this feeling with me). His very high involvment in his work and the very meticulous way he was doing it lead to great achievements in the installer. The Installation Guide work was also a model and indeed a great example of non technical work that requires as many skills as more classical technical work. So, and even though he was sometimes so picky and, I have to admit, annoying, that explains why I m still feeling sad and, in some way, guilty about Frans loss. One of my goals for wheezy is indeed to complete some things Frans left unachieved. I just found one in bug #564441: I will make this work reach the archive, benefit our users and I know that Frans would have liked that.

---

Thank you to Christian for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

As mentioned earlier this week, I changed the server for my hoster from server4you to Hetzner. Because the contract for my old server is still running until the 14th of April, I thought I can make some good use of it by running an Tor exit node on it. Tor, The onion router is a world-wide network of server to anonymize network connections, and used for example by freedom-loving people in repressive countries, or by Facebook users in repressively proxied university networks Naturally, such a system is also used by people with lesser motives, and after nearly one week of running the server, some complaints were reaching server4you a honeynet supposedly detected botnet activity from my IP address, another company hired by Paramount Pictures claimed that someone downloaded Iron Man 2 over BitTorrent via my server. These were forwarded to my by server4you, demanding an explanation. I explained that I am running a Tor node, that such things are unavailable, and that neither I nor server4you is going to be held responsible. Nevertheless, they insist that I should stop whatever I am doing (I am not sure if they really understood what tor is), and when I said that I won t, they decided to unilaterally and immediately end my contract by tomorrow. Thus a powerful exit node that might have made life better for Tor users is doing to disappear again. They will not reimburse the advance fee that I had paid in advance and made a non-specific threat about further claims they might have. So server4you was, at least in my case, not only an unreliable and inflexible provider, they also prefer to cut off their customer s server just because of two complaints by third parties. I conclude that this is not a hoster that you should trust important services to. And I am not a unique case: There are reports of similar server shut-downs by server4you (in German).

Well not really. The simple reason is that it does not make sense without further integration with other services. However if you want to deploy such solution, you can now base on example script, I've just pushed to our git repository. It is definitely meant only as example, major reason being storing MySQL user names and passwords in clear text in the PHP script.

Filed under: English Phpmyadmin 0 comments Flattr this!

Australia s Department of Finance has mandated that the MS-Office document format should be the standard document format for all agencies [1]. Paul Wayper notes the fact that MS doesn t plan to support it s own standards and suggests ODF, also known as ISO/IEC standard 26300:2006. [2].Psychology Today has an interesting blog post by Marnia Robinson about scientific reasons for avoiding porn addiction [3]. Her post links to a number of other posts on the topic on Psychology Today.Psychology Today has an interesting post by Noam Shpancer titled What Doesn t Kill You Makes You Weaker [4]. It seems to me that the belief to the contrary is due to people rationalising bad things that happened to them, it s not all bad as it made me stronger .Psychology Today has an interesting article by Noam Shpancer about the soldier as hero myth [5]. He argues that soldiers are really just employees, the risk to American soldiers in war zones really isn t that great and that they are just pawns to the military-industrial complex.Anders Ynnerman gave an interesting TED talk about visualising medical data which includes many startling 3D pictures of humans and animals that are being scanned [6]. He describes how this is useful in forensic analysis by the police and in better understanding biological processes.Margarita Manterola gave an interesting Debconf talk titled Making Debian Rule, again , she has some interesting ideas for improving Debian [7]. She is most focussed on social problems and the questions and comments had some interesting ideas. The Center for Non-Violent Communication [8] was mentioned in the questions, apparently their success includes teaching better communication skills to violent criminals, so it seems that they can help with some big problems.Benjamin Mako Hill wrote an interesting article about the ratio of writers to readers on Wikipedia [9]. While he makes some good points I m wondering about the measure of an editor , there have been few months where I have made 5 edits, so I guess I m just a reader. I probably should take more care in logging in when I make changes though, I ve made more than a few small changes from random systems (client sites, Internet cafes, etc) without bothering to login. This would mess up the stats a bit.The Reid Report has an interesting article about Bush being limited in his international travel due to the fact that he has admitted being a war criminal [10].Understanding Prejudice is an interesting article that summarises a lot of psychological research [11]. It gives many ideas for anyone who wants to reduce prejudice.Robin Harris wrote an interesting ZD Net article about vibrations and the impact on disk performance [12]. Apparently it s very common to be able to get more performance from drive arrays if you dampen vibration, previously I believed that unless you had extreme vibration to cause catastrophic problems then nothing would go wrong. But it seems that even smaller amounts of vibration can cause a 30% performance loss or worse! There is work in progress on vibration-damping racks.In a story published in The Australian about the NSW ambulance service being shut down due to a virus, Professor Caelli cites SE Linux as an example of a technology to make computers more virus resistant [13]. Professor Caelli also states that there should be a legal requirement to have backup systems for computers that have such grave consequences if they crash.Sinclair Community College is offering a new class Fundamentals of Linux Security , it includes SE Linux [14].Slate has an interesting article about Pickpockets [15]. Apparently they are becoming extinct in the US as law enforcement has prevented the Fagins from training younger people, and it s only in Eastern Europe that the skills base remains.

• [1] http://www.itnews.com.au/News/245276,australia-mandates-microsofts-open-office-xml.aspx
• [2] http://www.mabula.net/tbfw/blosxom.cgi/2011/01/19#2011-01-19-minister-leigh-letter
• [3] http://www.psychologytoday.com/blog/cupids-poisoned-arrow/201007/not-all-warnings-about-porn-are-moralistic-or-unscientific
• [4] http://www.psychologytoday.com/blog/insight-therapy/201008/what-doesnt-kill-you-makes-you-weaker
• [5] http://www.psychologytoday.com/blog/insight-therapy/201101/soldier-hero
• [6] http://www.ted.com/talks/anders_ynnerman_visualizing_the_medical_data_explosion.html
• [7] http://penta.debconf.org/dc10_schedule/events/627.en.html
• [8] http://www.cnvc.org/
• [9] http://mako.cc/copyrighteous/20110206-00
• [10] http://blog.reidreport.com/2011/02/bush-cancels-geneva-and-other-consequences-of-torture/
• [11] http://www.understandingprejudice.org/apa/english/
• [12] http://www.zdnet.com/blog/storage/bad-bad-bad-vibrations/896
• [13] http://www.theaustralian.com.au/australian-it/world-focus-on-ambulance-system-failure/story-e6frgakx-1226005951185
• [14] http://www.sinclairclarion.com/home/campus/2011/02/07/new-linux-class-starting-in-spring-quarter/
• [15] http://www.slate.com/id/2286010/pagenum/all/

I was going to make this a comment against Ritesh Raj Sarraf's post about patents and pharmaceuticals but the comment got way too long.

The basic problem is that patents on pharmaceuticals cannot be directly compared to patents on software and the explanation gets a bit involved. It's worse than apples and oranges, it's more like comparing an algorithm to a piece of DNA.

Patented pharmaceuticals must declare the precise chemical formula of the molecule (and a whole lot else besides) before the molecule can be brought to market but the company holding the patent is legally prevented from protecting themselves against slightly different molecules which are blatantly based on the protected molecule. All modification results in a new patentable product, legally separated from the original.

Therefore, the first company to patent a molecule from a new class is instantly joined in the field by other companies who are (obviously) watching the research news channels very carefully. (In their shoes, you would do the same or you go bust.) These companies simply add a flourine ion or change a hydrogen to a hydroxl group or any other number of minor, apparently inconsequential, changes. Changes which, in software, would be deemed a derivative work and would be roughly equivalent to changing a single local variable from a 16bit integer to a 32bit integer in a single function in a single file in the entire codebase. i.e. a trivial bug fix or even a typo.

A molecule with a couple of hundred atoms can have a change affecting one atom and be a completely new patentable item without any risk of the other company being sued for patent infringement, plagiarism, copyright violation (there is no copyright) or any other barrier. It's common to find that molecule foo is joined on the market by a desoxyfoo and a flourofoo etc. with a chlorofoo just around the corner, within months of the class-leader being launched. It can't be compared to software - effectively, every new release gets a new patent which covers the entirety of everything contained in that release, even if 99.999999999% of it is precisely the same as is covered under other several other patents held by extremely litigious competitors.

Modification is simply not prohibited - copying without making any changes whatsoever to the active molecule is prohibited. Changes to the inactive ingredients will be prosecuted - changes to the active ingredient will not. Comparing this with software is likely to drive you insane.

For example, the mere process of packaging an upstream release for a distribution would be patent infringement in pharmaceutical terms - UNLESS you deliberately patch the original source to make an utterly trivial and apparently pointless change. At that point, the upstream completely disown your entire release and you would have to fix every bug yourself - without the original upstream even telling you whether they fixed the same bug themselves, because they aren't ABLE to modify the upstream code without starting a whole new project and they won't tell you why or how they changed things. There is no such thing as an alpha-release of a molecule. Every release is final and no subsequent modification is possible - unless it only affects the inactive ingredients, e.g. by adding a slow release coating. These changes can affect the way that the molecule acts on the test subject / patient but must not change the active ingredient itself in any identifiable way. So the upstream can make a new wrapper (new packaging) but nobody else is allowed to do so until the patent expires. Once the patent expires, every one and their dog is allowed to make identical copies of the active ingredient in their own inactive packaging and these are called generics. Generics still need testing to ensure that the active ingredient truly is the same and that the generic behaves in the same way as the original but this process is cheaper than making a change to the active molecule.

A changed active molecule is an entirely new substance, it gets a new patent and it needs to go through largely the same amount of testing as the patented original but the new company still gets a head start on what the molecule is likely to do and what side-effects (by now noticeable with the class-leader product which is in large scale trials or even on the market) would be harmful to the future usefulness of their new, derivative, molecule. The new company simply jumps onto the bandwagon shouting "I want a piece of that action!" and there is absolutely nothing the original company can do about it, except try to show that their original molecule is better than the new competitors and to try and build a substantial market share before everyone switches to the new derivative. (Prescribers are human and tend therefore to be lazy, so unless there's a reason to change, the class leader will still have substantial share even after several derivatives exist.)

It's an arms race - each company tries to create as many of these potential "me-too" variants as possible in-house, put as many as can be (financially) supported through trials, keep pursuing those which don't have prohibitive side-effects / problems in tests and hope that, at the end, one of their versions will actually turn out to have better effectiveness or fewer side-effects. If not, they just have to market one as "as-effective-and-no-more-harmful-but-CHEAPER-than" the class leader. The majority of "me-too" molecules come under this category - even if the company concerned would try to point to infinitesimal differences in trial data to pretend otherwise. All this with the knowledge that the very hour that the patent expires, a dozen generic manufacturers will flood the market with copies which do not need to recover the massive costs of the original research and are therefore massively cheaper.

How much cheaper? patented molecules may cost 30 for 28 doses on Monday and one generic may cost 3p for 500, another may cost 40p for 10,000 on Tuesday, the day after the patent expiry. Generic houses only need to cover the actual costs of manufacture, not the costs of the original patent etc. and by the time the patent expires, the efforts of the patent holder to generate market share mean that economies of scale become evident. The absolute cheapest isn't necessarily the one who gets the contract either, these things all have expiry dates and all 10,000 have to be sold / supplied from a single location within that date to actually deliver the full savings. So then you get satellite generics who buy in quantities of a few million and pack down into 56 or less so that the total purchased quantity can sit on many shelves instead of just one. It's the same tablet in the end, with the same markings too. All that differs is the marking on the foil and the colour of the cardboard. (Oh and the same foil and colour cardboard can contain tablets with different markings from different manufacturers from one batch to the next, all within the branding of the same repackaging company.)

The original patent-holding company also has an interest in generating their own "me-too" derivatives, sometimes marketed under the name of a company which turns out to be solely owned by the parent of the original company. It can get horribly recursive.
Sometimes, the derivative from the sibling company hits the market before the "true" competitor from a different company - simply because all companies try to have many molecules in development at any one time (because most changed molecules fail in testing) and sometimes they get lucky and come up with two v.similar molecules and have to do something to justify the cost of developing both. That can turn out to be a poisoned chalice rather than two golden geese.

Sometimes, the company fails to get enough variants through testing and the company then gets bought out by a rival - who then gains their research and continues experimenting with other derivative molecules based on the ones already tested and dismissed. The limiting factor is the money.

At this point, I must now declare my cards. I used to be a pharmacist and although I am still entitled to call myself the holder of a Batchelor of Sciences degree in Pharmaceutical Sciences I am most definitely no longer a pharmacist. I therefore defer to my still-registered colleagues in case I've messed up any of the detail here. The above cannot be declared as the opinion of a pharmacist. I am an ex-pharmacist who voluntarily chose to resign his registration to take up full time work as a software developer rather than pay the exorbitant costs of maintaining such registration and all the "proof-of-competency" requirements which such registration requires.

Finally, before you ask, I am very happy to be an ex-pharmacist - my erstwhile colleagues have my ongoing sympathy but no matter how much some of them may beg, they all know that I will not be rejoining them on that side of the dispensary bench if I've got any choice in the matter.

Software is just better. It's all just recycled electrons.

We have customers, which require a report about what we've done during maintenance windows. Usually this includes a report about upgrades, newly installed packages etc. and obviously everything we've done apart from that.
Till now we've prepared them manually. For a greater bunch of systems this is a big PITA, because to be somehow useful you have to collect the data for all systems and after that, prepare a report where you have:

• The upgrades done on all systems (e.g. a libc or kernel update)
  
  seperated from
  
• the updates specific to a certain system or system class

Its also error-prone because humans make mistakes.

Perl to the rescue!
At least the part about generating a report about installed/upgraded/removed packages could be automated, because dpkg writes a well-formed logfile in /var/log/dpkg.log. But I noticed that there appearently is no library specialised at parsing that file. Its not a big deal, because the format of that file is really simple, but a proper library would be nice anyway.
And so I wrote such a library.
It basically takes a logfile, reads it line by line and stores each line parameterized into a generic object.

Its features include:

• Parsing the logfile (obviously)
• Storing each line in a logfile as a DPKG::Log::Entry object that holds informations about the entry type (e.g. action or status update), the package associated (if any), timestamp, verbatim line, line number etc.

• Limiting the number of lines parsed to a time range specified by DateTime objects

Based on that, I wrote another library DPKG::Log::Analyse, which takes a log, parses it with DPKG::Log and then extracts the more relevant information such as installed packages, upgraded packages, removed packages etc.

This, in turn, features:
- Info about newly installed packages
- Info about removed packages
- Info about upgraded packages
- Info about packages which got installed and removed again
- Info about packages which stayed halfinstalled or halfconfigured at the end of the logfile (or defined reporting period)


These libraries are already uploaded to CPAN and packaged for Debian.
They passed the NEW queue very quickly and are therefore available for Sid:

http://packages.debian.org/sid/libdpkg-log-perl

As an example use (and for my own use case, as stated above), I wrote dpkg-report, which uses the module and a Template::Toolkit based template to generate a report about what happened in the given logfile.
It currently misses some documentation, but it works somehow like this:

Report for a single host over the full log:
dpkg-report

Report for a single host for the last two days:
dpkg-report --last-two-days

Report for multiple hosts (and logfiles):
The script expects that each log file has the name <systemname>.dpkg.log so that it can guess the hostname from the system and can grab all such log files from a directory if a directory is specified as log-file arguments:</systemname>

dpkg-report --log-file /path/to/logs

This will generate a report about all systems without any merging.

Report for multiple hosts with merging:
dpkg-report --log-file /path/to/logs --merge

This will do the following:

• Report packages which where installed/removed/etc. on all systems seperate from the upgrades only done on the specific systems
• If systems start with a common name and end on a number (e.g. mail1, mail2, mail3 etc.), report packages which where installed on all systems with that common name seperate from the upgrades only done on the specific systems
• For a specific system list only the changes on that particular system and nothing else.

A (fictive) report could look some what like this:

dpkg-Report for all:
------------------------
Newly Installed:
abc
Removed:
foo
Upgraded:
bar (0.99-12 - 1.00-1)

dpkg-Report for test*:
------------------------
Newly Installed:
blub

dpkg-Report for test1:
------------------------
Upgraded:
baz (1.0.0-1 -> 1.0.0-2)

dpkg-Report for test2:
------------------------
Upgraded:
zab (0.9.7 -> 0.9.8)

Currently this report generator is only included in the source package or in the git(hub) repository of the library. I wonder if it makes sense to let the source package build another binary package for it.
But its only a 238 lines perl script with a dependency on the perl library so I'm unsure if it warrants a new binary package. What do others think?

...For the cases where, yes, you actually do want it. For the impatient assuming you're in a clean checkout on the tip of your current branch:

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

you can then double check that everything is as you expect with git diff ref-to-be-merged, which should be empty. The longer story It's noted from time to time that git does not have a -s theirs option to complement the -s ours strategy when merging (or, it did, but it was removed long ago, see below). For those not savvy the idea with git merge -s ours is to pretend as though a merge from some other branch has occurred, though the result remains the current branch's contents, unchanged. This is a neat trick that can be used to show that all changes in some branch have been superceded by the current branch, which can help ease merges further down the line as parallel devlopment continues. However, there is no corresponding -s theirs option, which would conversely say that "everything developed up to here is superceded by this other branch". This feature was discussed and discarded by one of the git authors, who instead advised a developer to throw away the previous work and start on a fresh branch:

One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you cannot offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.

In what would probably qualify as "most cases", he's right, but sometimes you do want to do this, and not because you have "crap" in your history, but perhaps because you want to change the baseline for development in a public repository where rebasing should be avoided. In debian, for example, it's pretty common for maintainers who use git-buildpackage to build debian packages from git to have two branches: an "upstream" branch and a "debianized" branch. The upstream branch will follow the changes from the upstream project (either by importing tarballs, or by pulling directly from the project's git repo if they also use git), while the debianized branch contains all the packaging related changes as well as any debian-specific changes to the code. In this context, if the upstream project uses git and rebases their history (out of your control), or if they shift development to a different branch, you might want to have a way to merge with their latest changes without rebasing/abandoning your current debian branch. Hence, a "theirs" merge. The author is totally right that the upstream project may be less interested in pulling from such a repository (since they would drag in the entire previous history), and if that's a problem you might need to splinter off the old branch and start a fresh branch instead. But at least for the projects with which I work, I find that it's more likely that pulling is pretty much one way upstream to debian, and that the patches flow back to the upstream project by way of bug trackers, git format-patch sendmail, or quilt patches sitting in the patch-tracker. And if it becomes a problem later you're no worse off, you can still split off a new branch or take some other action. So anyway, I asked Teh Internetz and found a few hits in the right direction, such as this guy at stack overflow, or this guy here. But from an aesthetic point of view I thought their solutions still left some room for improvement--they were both more complicated, involved setting up temporary branches, and I don't know, just weren't pretty on the eyes. So, ending where I started, this is the relatively clean and easy to follow 3 lines I conjured up, which I will give to teh internetz for posterity.

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

Alternatively, if you want to keep the local upstream branches fast-forwardable, a potential compromise is to work with the understanding that for sid/unstable, the upstream branch can from time to time be reset/rebased (based on events that are ultimately out of your control on the upstream project's side). This isn't a big deal and working with that assumption means that it's easy to keep the local upstream branch in a state where it only takes fast-forward updates. However, on the debian branch your less interested in the clean upstream development, and instead want to keep a sane history of the debianization work, so on this branch you still do something like a merge -s theirs (though in this case, you probably want to amend the previous version's ./debian dir back in post-merge). So applying the same approach as above with the slight modification, in practice (assuming you're on the clean tip of the debian unstable branch, that'd be):

git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff ref-to-be-merged   git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend

PS In spirit, this is a similar approach to what's done by the XSF team, though I would argue that with what I'm describing both the approach and the resulting history are a bit cleaner and easier to follow. Also, thanks to ron, mrvn, jcristau, and nthykier on #debian-devel for some quick reviewing of this.

One of the reasons I like Scotland is the fun that Scottish people have with language. I'm going to use two examples to illustrate my point:

• "Mind" is often used as "Remember"
• "How" is often used as "why".

The last one is particularly fun when you use questions such as "How no?" - meaning roughly "Why not?". Languages, and idioms, vary wildly in different parts of the world, even when you restrict yourself to English-speaking languages. I'll not even get started on Accents. The UK is tiny compared to many other countries, yet we have a wide array of accents - Australia, by contrast is huge, but I can think of only two accents across the country. (Rationally I expect that there are many accents in different parts of Australia, and I'm merely ignorant.) In conclusion languages are fun, and some places this is more evident than in others. I will most likely contintue to say "The shop is open from 9 while 4" rather than the more typical "From 9 til 4" - I'm allowed to do that, having grown up in Yorkshire!

(PS. PHP still sucks - Even if you post it upon a PHP-powered blog. ;)

ObQuote: "People take you for granted, you know. We gotta make people miss you." - Hancock

A bug-fix release RQuantLib 0.3.6 is now on CRAN and in Debian. RQuantLib combines (some of) the quantitative analytics of QuantLib with the R statistical computing environment and language. There are only two changes to two files where an explicit conversion as per Rcpp::as<double> was called for. A Debian archive rebuild had triggered one of those fails to build from source bug reports as the compiler version seems to be more finicky now than when version 0.3.5 was uploaded in November. No other changes were made. Thanks to CRANberries, there is also a diff to the previous release 0.3.5. Full changelog details, examples and more details about this package are at my RQuantLib page.

What Yes, I have not used this kind of outfit for over 20 years. And I hope it will be 20 more years before I do it again. But today, I was seen like this in public. Why? Well, I won't explain the whole background yet again I did it a bit over a month ago in this same space. Much much in short, I never attended university, so after many years of working without any formal validation for my knowledge I followed the CENEVAL Acuerdo 286 procedure to get a "Software Engineering" title and the corresponding c dula profesional. Today I did the last portion of this procedure: Presenting an oral exam, defending the work I developed. Not precisely a thesis, but you can see it as an equivalent. One of the requisites was to go on formal attire Of course, I have some beautiful shirts I am very fond of, but I didn't want to risk it to such a detail, so I asked my friend and almost-neighbour Miguel Barajas to lend me the needed bits of clothing, and presented the exam. Was it easy? No, not by a long shot. Did I pass? Yes! Now, back to work!

git-annex is a recent tool allowing to manage files with git without having theirs contents checked into git. I've been looking at it with some interest in the past few weeks in order to use it to handle my music collection on the various computers I use. My laptop just got a new SSD drive which is quite small and cannot handle the whole collection. By using git-annex, I'm now able to only check out part of my music collection and keeping it synchronized with all my others computers. Using git-annex is pretty trivial once you understand the concepts. I've set up a a git repository in my Music directory, like that:

% git init
Initialized empty Git repository in /home/jd/Music

Then I initialized git annex:

% git annex init "Music on keller"

So now I'm able to import all my date into git annex. git-annex offers several backends to store data. WORM is the default, but is not a good choice for file that could be modified, and music files can be, at least when editing the metadata. Therefore, I chose the slow but more reliable SHA1 backend.

% git annex add --backend=SHA1 .

That can be long, so you should be patient. Then you should commit the fact you annexed files:

% git commit -a -m "Imported my music collection"
[master 82d060f] Imported my music collection

Now, it's done. You can go on another computer and clone the repo:

% git clone ssh://keller/~/Music
% cd Music
% git annex get "Incubus - Light Grenades"

And then let the magic happens. It will retrieve the whole directory for you. Do not forgot to commit the fact that you got those album on that machine! The concept used by git-annex is quite simple. All files are replaced by symlinks pointing to .git-annex/SHA1:filechecksum.log. This file contains lines, whose format is:

retrieval-timestamp is-file-present uuid-of-the-repository

Indicating if the file is present in a repository. This logs file are commited into the repository, whereas the real content is stored in the .git/annex directory and therefore not commited. I recommend to take a look to the walkthrough page to get more idea and what you can and cannot do with git-annex.

My server, which is among other things hosting this weblog, is a dedicated server originally hosted by the German webhoster webperoni. It was a bargain at that time, and still a good price, and I was satisfied with webperoni s performance and reliability. Unfortunately, they were taken over by another web hosting company, best known for their server4you brand. They moved my server to a different data center and continued to run it there. Unfortunately, server4you was less reliable and less flexible than my original hoster: For example, when one sector on the hard drive turned bad, they were not able to put in a new drive in my system, let me mirror the content, and then remove the old drive. In another, even worse, instance, my second IP address, which I bought from webperoni, was given to another customer. When I finally noticed and complained, they refunded me the charges that I paid for the IP. But understandably, I wanted to get away from that hoster. The contract is automatically prolonged for one year if not canceled in time, and I missed the deadline last year. This year, I finally got around to rent a slightly better and slightly more expensive server from Hetzner, which whom I already made good experience. I would have preferred to switch when I am back from India, but server4you would not even let me prolong the contract by just two months only a whole year or nothing. So they got nothing, and I started to work on the move yesterday. At first I set off installing the new system from scratch, setting up all the various services and copying over data and configuration. But quickly, I gave up and moved the system by completely by copying programs, configuration and data from the old server. The new system has its root partition on a LVM share on software RAID, and now uses grub2 to boot. I had a hard time to get it booting, and a hard time to debug the issues without access to the physical console. I finally understood the problem by running kvm -hda /dev/sda -hdb /dev/sdb -curses from the recovery system and observing that the initial ramdisk is having problems finding the root partition. The problem was that I thought addressing partitions via file system labels is the way to go now and manually added root=LABEL=root to the Linux command line in /etc/default/grub. But then the initial ramdisk would not activate the logical volume. If I had just left it to the grub package, which inserted root=/dev/mapper/vg-root, everything would work fine. The new IP address (88.198.48.143) has not propagated throughout the Internet yet. Running the following command for a variety of ports on the old machine (80.86.81.20) makes sure nobody notices:

port=443
iptables -t nat -A POSTROUTING -p tcp --dst 88.198.48.143 --dport $port -j SNAT --to-source 80.86.81.20
iptables -t nat -A PREROUTING -p tcp --dst 80.86.81.20 --dport $port -j DNAT --to-destination 88.198.48.143:$port

The only question remaining is: What to do with the old server for the remaining six weeks? I am considering to erase the system, set up a plain Debian system and run a tor/freenet/whatelse node at full speed.

Short version: Dear FSF, thanks for your appreciation of Debian Squeeze achievements in getting rid of non-free firmware blobs. We still disagree on the overall freeness assessment of Debian, but I'm positive that steps like this one can further future collaboration, in the interest of both projects. Long version follows.

---

Historically, the relationships among Debian and the FSF have gone through mixed fortune (and that's quite an euphemism). On the one hand, Debian is committed to 100% Free Software, is an open project explicitly inspired by "the spirit of GNU", has been sponsored by FSF in its infancy, and properly calls itself "GNU/Linux" (or even "GNU/kFreeBSD"). On the other hand, Debian is the project who considers the GNU FDL license to be only conditionally free and which is not considered to be an entirely Free system according to FSF.
So much for the history corner. As a long time member of the Debian Project, as well as an FSF(E) fellow, I've always felt a bit sad about this state of affairs. Not because the two projects should have aligned goals; they clearly focus on different aspects of the quest for a Free (Software) world. Not even because they should agree on how to build a Free distribution: history has shown that FSF technical positions do not always get along with Debian's more "pragmatic" style, as embodied by point 5 of the Social Contract. Rather, my sadness is rooted in the belief that not getting along have encouraged duplication of efforts which could have been easily avoided (e.g. multiple distributions concurrently freeing up kernels). Furthermore, I'm more and more convinced that Debian nowadays enjoys a rather privileged position among Free Software vendors. Indeed, even though GNU/Linux distributions have reached a popularity we didn't dare to imagine 15 years ago or so, most distributions are under the direct or indirect control of commercial vendors. Those commercial vendors play a very important role in the promotion of Free Software. For instance, they are structured in ways that enable them to seal OEM deals with hardware manufacturers to sell computers with GNU/Linux pre-installed. Commercial vendors, by their own nature, are also in general better at marketing than non-commercial vendors. On the flip side however, commercial vendors are not yet relevant enough to drive proprietary drivers out of the market and, as a consequence, cannot yet afford not to support hardware which need such proprietary bits to work. Among mainstream GNU/Linux distributions[1] Debian is one of the very few vendors if not the only one that is both very relevant and, thanks to its independence, can afford taking Free Software's side: no commercial urgency can force Debian to negotiate on that. That is quite an asset to be used in the promotion of Free Software, especially to a public that is interested in and willing to understand what Free Software really is about. Such an "aware" public is on the rise as of lately, together with the general awareness increase of risks entailed by living a digital life, when that life is not under our control (think, as an example, at how often the "Facebook privacy debate" has hit mainstream medias in the last year). The "aware" public is the natural target of both Debian and the FSF. Dividing it would not serve well the cause of Free Software. With all that in mind, last August I took the chance of being on the "right" side of the Atlantic Ocean for DebConf10, to discuss possible venues of collaboration among Debian and the FSF. I sat down and discussed at length with John Sullivan, who I happen to know for his Debian involvement, in his capacities of FSF representative and operations manager. We discussed various topics, with the intention of bringing them up to the respective communities[2]. Then, inevitably, we ended up talking about the overall freeness of Debian and his exclusion from FSF listing of Free systems. (FSF is of course entitled to such judgements, pretty much as Debian is entitled to its own judgements on FSF licenses. Nevertheless those judgements contribute to dividing our public and might lead to wasteful duplication of efforts, where Free Software could better be served by collaboration.) The main ground for exclusion from that list used to be the compromises Debian has made in the past about non-free firmware blobs. But, as I pointed out back in August, those compromises would have been gone starting with Squeeze, making that argument moot. Today 6 months later I'm delighted to cheer at FSF's decision to publicly recognize the achievements Debian has delivered with Squeeze.
Thanks! It's a nice gesture that I've very much appreciated. I'm confident steps like this one will help future collaboration if, on both sides, we will be able to spot actual venues for collaboration. Needlessly to say, I still disagree with the overall FSF assessment of Debian non-freeness. Apparently, it still stands on the basis that Debian also provides a repository of nonfree software [ ] [which] is not part of the Debian system. [ ] but users would be hard-pressed to make a distinction and that people can readily learn about software available through it by browsing Debian's online package database. I respect the principle of non advertising non-free software and I even agree that it is a good principle. But unfortunately it's also a very blurry principle on which, in my opinion, Debian actually scores very well. No non-free software is offered to users by Debian; it's just for users that really want to have non-free software (or need to, in order to run a Free OS on their computers), that Debian tries to stay out of their way. For the "aware" public discussed above, I think it's much better to draw the line where software freedom ends and use that line to explain what does crossing it entails, than locking them up pretending non-free software do not exist. But fair enough: for the time being, I guess, we will need to agree to disagree on this one. Getting a little bit closer in the occasion of the Squeeze release is still an important step forward. It's up to each of us now to seek out initiatives which attract the interest of both projects and that can benefit from synergies.

---

[1] Sorry, I've no decent definition of "mainstream distribution" to offer, besides folklore and well-established distribution review sites. (Heck, I don't even have a decent definition of "well-established distribution review site" to offer!).
[2] which hasn't happened yet, due to the proverbial amount of available spare time.

We have many orphaned packages in Debian. Those are packages that no longer have a maintainer willing to care for them. They are a problem for several reasons. Often, there have better alternatives (that s often why the maintainer gave up maintenance), but users keep installing them because they show up in apt-cache search. Or, they might be broken, without anybody noticing because they only have a few users. Also, developers need to take them into account. They might slow down transitions, have RC bugs that need fixing, etc. So, there are good reasons to remove some of the orphaned packages from the Debian archive. Not all of them. But those that have been orphaned for a long time without anybody stepping up to take over the maintenance, have very few users according to popcon, etc. Removing some of them also makes it easier to expose the ones that should really find an adopter. Also, that removal is not final. The good reason to do this now is that we are at the beginning of a release cycle, and that it will be easy to reintroduce packages that are really needed during the next two years. Also, packages (both source and binaries) are still available on snapshot.debian.org, so users can still install them from there, and re-uploading them to Debian is very easy if someone wants to adopt them. So, how do I proceed? I use bapase, and go through specific sets of packages (using a custom version of bapase to restrict the list to those packages). For example, orphaned packages that have a popcon lower than 50, have been orphaned for more than 500 days, and whose orphaning bugs have not been modified in the last 100 days. Then, I read the bug log, and decide if there s a reason to keep the package. If there s not, I request the removal. As of today, there are 471 orphaned packages in Debian. The goal is not to get down to zero, but it s certainly possible to get down to 200 or 250. How can you help? Start from the list, and find some easy targets. You can take a look at bug #483252 if you want to re-use my template. Also, one thing that is currently missing in the process is that orphaned packages that have reverse-dependencies should not be removed without removing their dependencies (if appropriate). An easy and efficient way to know if a given package has reverse (build-)?dependencies would be great, so I could integrate this info into bapase and exclude those packages from the list, or mark them somehow.

Enough news to release another Debian XSF News issue, after less than a week.

• Given HAL is deprecated, and going to die for real at some point, I ve tried to look for alternatives since it s still used on GNU/kFreeBSD to handle input hotplug in the X server. There s devd on the FreeBSD side, but that only lets us know about device updates. I tried to get some input (pun intended) through debian-bsd@/freebsd-x11@/xorg-devel@, played a bit with devd and came up with a proposal. It s quite ugly but it looks like it would work with minimal efforts, and I could then forget about HAL entirely. Guillem proposed something more generic/universal, but unfortunately, I have seen no replies yet.
• I uploaded a new xserver-xorg-video-ati upstream release to unstable, which comes with plenty of bug fixes, and better Evergreen support.
• It looks like the switch to r600 Gallium in mesa was a bit premature, so it s going to be reverted in the next upload.
• I prepared stable updates for xorg-server and xserver-xorg-video-intel, which got both accepted quickly by our nice release managers. Our todo-list for squeeze is now empty again: no more bugs usertagged squeeze-candidate but not squeeze-accepted.
• I also updated xorg-server in unstable, including an important fix to the EXA acceleration layer, especially fixing a bunch of issues with the radeon driver. In other news, a big clean-up happened there, making the good ol build system ( xsfbs ) go away.
• The missing video drivers for 1.9 were uploaded: Julien sponsored qxl, I uploaded the sparc drivers (suncg14, suncg3, suncg6, sunffb, sunleo, suntcx) from a porter box (thanks to the very responsive DSA team for the quick installation of needed build dependencies), and Aur lien Jarno kindly uploaded the newport driver for mips.
• In the meanwhile I uploaded the newly-released xorg-server 1.10rc2 to experimental, but only built a few drivers against it. On the video side, the API didn t change much, so most drivers build without modifications: fbdev, then ati, mach64, r128 (ati depends on the other ones), as well as intel, nouveau, dummy (useful when there s no monitor connected), and vesa. On the input side, many changes happened and one needs new upstream releases, except for the evdev driver (which I uploaded accordingly). Upstream is currently in the process of releasing other input drivers, so the following drivers should hit experimental soon: keyboard/kbd, mouse (both for non-Linux ports), and synaptics (better than evdev for touchpads).
• I put some bits of documentation in xorg-server s README.source mentioning what to keep an eye on when upgrading to a new upstream release. For example, forgetting a version bump in xserver-xorg-dev s dependencies could lead to build failures when xorg-server.pc is used, which is why I uploaded a new xorg-server revision

Enough writing for now, I m getting new mails in xorg-announce@.

There are many ways to run some commands simultaneously on multiple hosts like cssh or dsh. They come handy for example when you are installing software updates on a set of hosts. dsh is a rather simple comandline tool allowing to execute a command over ssh on multiple hosts. However it doesn't allow any interactive input -- so you can't look at the potentially upgrading packages and press y to accept and you can't go through debconf promts or similar. This is solved by cssh which opens a XTerm for every host and a input area that is broadcastet to all of them. this is working really well -- you can execute your update on all hosts and still do individual adjustments just as needed: switch focus from the broadcasted input to one of the terminal windows and anything you type just goes there. Now cssh has a big disadvantage: it requires a running X server (and doesn't do too well with a fullscreen windowmanager). Requiring X is quite a blocker if you need to run that ssh multiplexer on a remote host, for example if the firewalling doesn't allow direct connections. Fortunately you can make tmux behave as we want -- in a simple terminal: First you need a script spawning the ssh sessions in separate tmux panes and direct input to all of them -- here called ssh-everywhere.sh (you could also write a tmux config I guess):

#/bin/sh
# ssh-everywhere.sh
for i in $HOSTS
do
  tmux splitw "ssh $i"
  tmux select-layout tiled
done
tmux set-window-option synchronize-panes on

Now start the whole thing:

tmux new 'exec sh ssh-everywhere.sh'

And be done. Update If you want to type in just one pane (on one host) you can do that as well: C-b : set-window-option synchronize-panes off and moving to the right pane (C-b + Arrow keys)

Nokia is in the news for it s CEO announcing that they have a Burning Platform , Jeff Waugh gives an interesting analysis of the situation [1].What is a Platform for Phones?This whole scenario makes me wonder about what a platform should mean in terms of mobile devices. Wikipedia says A computing platform is some sort of hardware architecture and software framework (including application frameworks) that allows software to run. Typical platforms include a computer s architecture, operating system, programming languages and related user interface (run-time system libraries or graphical user interface). [2]I think that Nokia s problem was that it didn t leverage it s strength in making great phone hardware. Nokia used to have a commanding share of the market due to simply making better phones. They had phones that were upwardly compatible (the same UI and used the same chargers), their phones were always very solidly constructed, and they had some good design features such as having the battery comprise part of the case which allowed a replacement battery to be physically larger for longer battery life. Even now they have hardware features which are better than the rest such as the N8 which is widely regarded as having the best camera of any phone. Nokia also did some smart things like releasing their N800 series of phones with more open software than most companies used, they supported running arbitrary Linux applications.While they kept the platform as the API interface on a phone OS and maintained several different OSs (with multiple versions in production at any time) they made a less desirable platform for developers and a lot more development work for themselves.Nokia fragmented their own market. There is no technical reason why they couldn t manufacture a phone that is capable of running a choice of their own OS as well as Android (or alternatively their own OS or the Windows Phone OS). There may be technical issues that prevent designing a phone to run either Android or Windows phone, but they could have got two out of three options available.On top of a hardware phone platform we could have multiple software platforms, Android, Windows, Meego, etc. The users could then decide which one to use.A Hardware Platform for PhonesI think that it would be ideal if a phone company offered phones with a choice of OS and allowed the user to change the OS. The N8 is a great phone and the hardware is really appealing, I would have definitely bought one for my wife if it ran Android. Also the resale value of phones can be improved if they can be re-purposed. If someone knew that people on ebay were paying good rates for an old phone because it could be re-programmed then they would be more likely to buy it. As phones are essentially free for most people due to telco deals, a phone that has a resale value of $200 is a lot more desirable than one with a resale value of $100 if all other things are equal.I would like to see the mobile phone as a platform just as the IBM PC compatible was a platform. Imagine if IBM had sued Compaq into oblivion when they first cloned the PC, if that had happened I don t think that I would be using an IBM PC (Thinkpad) right now. The early IBM PCs really weren t great systems for home use, for pretty much anything you might want to do the early PCs didn t compete well with CP/M systems and systems from Commodore and Apple. It was only when cheap clones flooded the market that the PC platform took off. Modern PCs can boot from disks that were created 20 years ago. At every time during the PC s history there has been a choice of OSs available that work with the standard BIOS boot loader and expect certain essential hardware (such as a BIOS interface for video, keyboard, and storage). This choice increased the market allowing economies of scale in production. It also allowed competition between vendors which forced the margins to be low and resulted in PCs becoming cheap over the last 20 years every aspect of a PC apart from Intel CPUs and Microsoft Software has steadily dropped in price.I would like to see phones designed with a common boot loader, a common core set of CPU functions (I believe that with ARM CPUs a lot is optional), and common interfaces to the touch-screen and the GSM system. The boot loader would ideally have support for booting multiple OSs, in a typical end-user case the store would provide the phone configured to quietly only boot one of the available OSs but it would be trivial to offer the user a choice of OS at boot time for advanced users. The process of installing a custom ROM image in a phone is regarded as dangerous at the moment and most people who would like to do such things are hesitant due to the risk of bricking their phone. If booting the last good OS was an option then more people would try new OSs. With the current situation I am a little hesitant to re-program my new phones (and I m braver about such things than most people).One of the many problems with the current situation is that the phone vendor has to officially support every phone OS. One example of the problems with this is the Sony Ericsson Xperia X10 which is a fine piece of hardware that has been saddled with an older version of Android for it s entire life, Sony has stated that they won t produce any more updates and thus the demand for this phone is a lot lower than it might be. I believe that this is why the Xperia X10 is significantly cheaper than any other phone with similar features. Sony is losing money because they have a closed hardware platform and don t support the recent versions of Android!Ways of Booting the OSIt shouldn t be a technical challenge to have support for basic touch-screen IO and 3G Internet access in the boot loader of the phone. Then an OS such as Android could be loaded from the network before being booted without needing an older version of Android running. 80386 systems with a few megs of RAM used to be able to boot from a LAN, a modern phone has much more powerful hardware and a network connection that s at least as good as 10base2 networking so it should be able to do the same.Modern phones have micro-SD cards for local storage. There s no reason why the OS couldn t be loaded on micro-SD card. Fixing the OS on a phone that was bricked could be achieved by putting the micro-SD card in a PC and then copying the files across just as I often fix PC OS problems by installing the hard drive in a working system.Changing the OS of a phone should be easier than changing a PC between Ubuntu and Fedora (the Linux distributions that seem to have the most usage by less technical users).ConclusionIf Sony had made their platform the hardware then they could have spent their effort on what they do well (making great phone hardware) and delegated almost all of the work related to creating the OS to other companies (Google, MS, telcos, etc).If the entire industry moved to a hardware platform for phones then the result would be lower prices and some thin margins for manufacturers. This would be good for users and OK for manufacturers. The current situation however is quite bad for users who can never get phones to do exactly what they want and not so good for phone manufacturers such as Nokia (and everyone else who does business with Microsoft) who find themselves on the wrong side of market forces. The phone as a hardware platform shouldn t be too bad for Microsoft either, they did OK on the PC hardware platform.

• [1] http://bethesignal.org/blog/2011/02/11/elopocalypse-nokia-chooses-microsoft/
• [2] http://en.wikipedia.org/wiki/Computing_platform