...at least, in my opinion (which is obviously biased, let's admit that). There are several reasons for this loss:

• Strategic choices: Bernard Laporte deliberately chose to use the same tactic against England and New Zealand. However, the tactic that worked against New Zealand failed against England, mostly because that tactic...is just the play of the English team. So, as we say in French, "les Bleus" entered the game of England and therefore made the task easier for them.
• The choice of players. This is the result of the previous item. Reconducting the entire team that won against NZ was IMHO a bad idea. It is not a scoop that I dislike Rapha l Ibanez or Fabien Pelous and I would rather have seen the punch of Dimitri Szarzewski or, for once, S bastien Chabal beginning the game (actually, he entered pretty quickly because of Pelous' injury).
• Several failures to occupy the English side with kick play. In many occasions, kick shots by either Beauxis, Traille or Jauzion missed their target. This is IMHO the main reason for the defeat.
• Too many drop tentatives. When they were in the English side, why the hell did they choose to kick drops several times instead of just play. That sounds like a fear of not scoring and the French lost several key balls with that miserable tactic.
• Too many lost balls in mauls. That is not only a failure by the French but also good defense play by the English team.
• Discipline. It happened only once (high tackle by Dimitri Szarzewski) but that was *the* moment where no error was possible and it offered an ideal penalty kick to Wilkinson.
• Bad luck. We can't rule out that one. The difference is 5 points: this stupid 1st minute try....and the missing 50 centimeters on Chabal's action in the last minutes.

Some *bad* reasons for the English victory:

• Johnny Wilkinson influence: this is untrue. Apart from his drop goal, he missed penalty kick tentatives and his kick play was not brilliant during the same. I much preferred Andy Gomarsall during that game.
• Scrums. They didn't crush the French scrum which is one of the satisfactions of that game. The English team even had to cheat slightly during 1st half time to win their scrums.
• Good play. No. Watching the game again, there was as many bad choices in the English side than in French side. I can only enhance their defense, not their attack. So, as I wrote immediately after the game, that one was one of the worst matches in the entire WC.
• The referee. Before the game, some French newspapers were doubting of Mr. Kaplan because he's South-African (funnily, some English newspapers were also doubting because he was supposed to advantage England's opponents in the past). He was indeed perfect. Anyway, everybody knows I never blame referees in sports.

Julien's blog entry and some spare time lead me to try this powertop utility which I never heard about before. As a consequence, I ended up tine tuning a few parameters on my laptop, mostly sound card and wireless card energy saving parameters. I also finally turned "noatime" ON on my mounted partitions when the laptop runs on battery (I use laptop-mode for such automation). I was prevented to do so util now because mutt relies on access times to define whether mailboxes got new mail or not. However, recent mutt version now have "set check_mbox_size" which make mutt rely on the mailboxes sizes I still have fine tuning to do, mostly trying to get my hard disk really spin down in some occasions (mail reading, mostly) as well as automate the screen brightness, but this powertop utility is really worth it in the hunt for wasted energy. And, of course, installing it is just a matter of "aptitude install powertop", thanks to Patrick Winnertz who packages it. And thanks to Julien who blogged about Powertop, even for ranting about it...:-)

Today I've stumbled upon this old page about the GNU project.

The last update has been in 1997, it's nice to see how things are changed in 10 years... For instance:

Linux is a copylefted kernel, which uses GNU, BSD and X software to make a compleat free OS. This or FreeBSD or NetBSD are great OS's to use until the Hurd is stable.

There's also an interesting newspaper article about the impact of reward on motivation (1987).

I am a leader by default, only because nature does not allow a vacuum.

Edit: Turns out that’s a Desmond Tutu quote. Still, it’s interesting to see it as a spam subject line.

One of the things I have been tasked to do in my current assignment is to create a dashboard of the status of various software components created by different contractors (participating companies) in the program. These software components are built by different development groups, utilizing unlike toolsets, languages and tools though I was able to get an agreement on the VCS (subversion yuck). Specifically, one should be able to tell which components pass pre-build checks, compile, can be installed, and pass unit and functional tests. There should be nightly builds, as well as builds whenever someone checks in code on the release branches. And, of course, the dashboard should be HTTP accessible, and be bright and, of course, shiny. My requirements were that since the whole project is not Java, there should be no dependencies on maven or ant or eclipse projects (or make, for that matter); that it should be able to do builds on multiple machines (license constraints restrict some software to Solaris or Windows), not suck up too much time from my real job (this is a service, if it is working well, you get no credit, if it fails, you are on the hot seat). And it should be something I can easily debug, so no esoteric languages (APL, haskell and Python :P) So, using continuous integration as a google search term, I found the comparison matrix at Damage Control I looked at anthill, and cruisecontrol, and the major drawback people seemed to think it had was that configuration was done by editing an XML file, as opposed to a (by some accounts, buggy) UI is not much of a factor for me. (See this). I also like the fact that it seems easier to plug in other components. I am uncomfortable with free software that has a commercial sibling; we have been burned once by UML software with those characteristics. Cruisecontrol, Damagecontrol, Tinderbox1 & tinderbox2, Continuum, and Sin match. I tried to see the demo versions; Sin s link led me to a site selling Myrtle Beach condo s, never a good sign. Continuum and Damagecontrol were currently down, so I could not do an evaluation. So, here are the ones I could get to with working demo pages: http://cclive.thoughtworks.com/ and http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey Cruisecontrol takes full control, checking things out of source control; and running the tests; which implies that all the software does build and run on the same machine this is not the case for me. Also, CC needs to publish the results/logs in XML; which seems to be a good fit for the java world; but might be a constraint for my use case. I like the tinderbox dashboard better, based on the information presented; but that is not a major issue. It also might be better suited for a distributed, open source development model; cruisecontrol seems slightly more centralized more on this below. cruisecontrol is certainly more mature; and we have some experience with it. Tinderbox has a client/server model, and communicates via EMAIL to a number of machines where the actual build/testing is done. This seems good. Then there is flamebox nice dashboard, derivative of tinderbox2; and seems pretty simple (perhaps too simple); and easily modifiable. However, none of these seemed right. There was too much of an assumption of a build and test model and few of them seemed to be a good fit for a distributed, Grid-based software development; so I continued looking. . I finally decided CABIE

Continuous Automated Build and Integration Environment. Cabie is a multi-platform, multi-cm client/server based application providing both command line and web-based access to real time build monitoring and execution information. Cabie builds jobs based upon configuration information stored in MySQL and will support virtually any build that can be called from the command line. Cabie provides a centralized collection point for all builds providing web based dynamic access, the collector is SQL based and provides information for all projects under Cabie s control. Cabie can be integrated with bug tracking systems and test systems with some effort depending on the complexity of those systems. With the idea in mind that most companies create build systems from the ground up, Cabie was designed to not have to re-write scripted builds but instead to integrate existing build scripts into a smart collector. Cabie provides rapid email notification and RSS integration to quickly handle build issues. Cabie provides the ability to run builds in parallel, series, to poll jobs or to allow the use of scripted nightly builds. Cabie is perfect for agile development in an environment that requires multiple languages and tools. Cabie supports Perforce, Subversion and CVS. The use of a backend broker allows anyone with perl skills to write support for additional CM systems.

The nice people at Yo Linux have provided a Tutorial for the process. I did have to make some changes to get things working (mostly in line with the changes recommended in the tutorial, but not exactly the same. I have sent the patches upstream, but upstream is not sure how much of it they can use, since there has been major progress since the last release. The upstream is nice and responsive, and have added support in unreleased versions for using virtual machines to run the builds in (they use that to do the solaris/windows builds), improved the web interface using (shudder) PHP, and and all kinds of neat stuff.

If you should discover, while sitting in a airport departure lounge, that your TomTom has lost its SD card, don't despair. Provided you have a spare SD card (I stole the one from my camera) and have the laptop you've used TomTom Home with to hand, all might not be lost. I was able to do something along the lines of:

cd /media/disk
cabextract ~noodles/TomTom/HOME/Downloads/navcore_7.131.8483.one.cab
mkdir "US - Western Region"
cd US\ -\ Western\ Region/
cabextract ~noodles/TomTom/HOME/Downloads/US_-_Western_Region.cab 
cd
umount /media/disk

which got me up and running again. Of course it doesn't have the UK maps that came with the device, but as I was on my way to the US that's not so important (and Katherine has found the SD card anyway, so I can just replace it when I return). I was quite pleased with myself. And then I ended up with a rental car that had GPS of its own anyway... (Oh, yes, I'm in Fremont, CA, flying back on the morning of Saturday 18th November. I am currently jetlagged and trying hard not to go to bed. If you are in the area, know me and would like to meet up for food/beer/whatever feel free to drop me an email.)

Thanks to the outstanding work of Stephen Gran SpamAssassin 3.2.3-0.volatile1 is now available in etch-proposed/volatile. Before we accept it to etch/volatile i would like to ask some experienced SysAdmins to do some (more extended testing as we did) of the package and report back any problems you find to debian-volatile@lists.debian.org. As soon as we are convinced that SA 3.2.3 works as expected, I will move the package to etch/volatile and send an official announcement. Please consider that this upgrade might break your system, so you upgrade at your own risk. Thanks in advance for all the feedback you will send us. volatile

Over one year ago, still at DebConf 6, the Latin American Debian people (and by people I mean just interested people, regardless of whether they were/are official DDs or not) held a BoF session. One of the ideas we discussed there was that, in order to increase Debian presence in our region (which is by no means small - Let alone the geographical aspects, I'm guessing we are about 350 million people, roughly split in half between [officially] Spanish- and Portuguese- speaking countries). Yet, this is an area with very little involvement in Debian in particular, and with Free Software in general.One of our first issues seems to be language - Just by its scale and economic importance, we cannot even put in the same scale Brazil and the Spanish-speaking countries... So I'll focus on Spanish-speaking Latin America, as (I recall) we did in that session.So, we agree: We need more local involvement in each of our communities. And, so far, we have seen quite relevant results. The number of people directly involved in Debian in Argentina, Chile, Per , Colombia, Venezuela, El Salvador and Mexico (excuse me if I forget you in another country!) has notably risen since I brought this topic up, together with Christian Perrier, back in DebConf5, Helsinki. An undeniable fact is that distances in our continent, however, are huge. In the 2006 BoF, we agreed we should promote regional meetings, that would serve both for working focused on Debian topics (i.e. hack sessions, as we do in DebConf) and for spreading our work to the local population, to help them see that it is not needed to be super-skilled or anything like that to contribute to a real, important and large Free Software project such as ours. Of course, taking into account the distances in the continent, we thought it would be sensible to split it in two - and to try and hold regional mini-debconfs - One for the Northern half (i.e. Per , Ecuador, Colombia, Venezuela, Central America, Cuba and Mexico), and one for the Southern half (Bolivia, Chile, Argentina, Uruguay, Paraguay). And, for logistical reasons mainly, I strongly advocated having our first Northern meeting in Panam . Why Panam ? Because it is a place cheap and easy to get to. They have a very important international airport, connecting to most if not all countries in the region, and -as they have risen as a business center- have good connectivity. Visa is required for many of the interested countries, but trivial to get (as opposed to what happened here in Mexico :-( ). Of course, other countries also looked interesting (there was some argument pushing Venezuela, but in the end, we all conceded it would be in Panam .I have to strongly thank Guillermo Garc a - He is not (yet? :) I hope he still wants to get involved with this bunch of people) in Debian in any way, but after I contacted him, he agreed to start looking for a way to get us the right facilities in Panam . He coordinated with a team which did most of the organization - A very nice web site is still available so you can look at their work - Quite a good job, I must add.They contacted Universidad Tecnol gica de Panam , started talking with several potential sponsors, got information regarding hotels for us... But in the end, it flopped. Why? Because, although many of us were originally interested, in the end very few people (only three, none of them officially a Debian Developer, according to their last press release) confirmed their intention to attend.Which brings me again to the question: Why?First and foremost, I think it was lack of involvement. For one reason or another, all of the people that in the beginning pushed for this miniDebConf ended up busy doing other stuff, and didn't get at all involved in organization. It would have been a great present from our Panaman friends, yes, but quite unfair. And, of course, with no Debian people involved in organizing it, we got an chicken-and-eggesque situation... Where it didn't grab the attention of other Debian people.Second, what they offered us was quite different to what we intended in the first place - At least, to what I imagined. On my first messages both to debian-devel-spanish and to Guillermo, I tried to get something close to what we had in mind: Something as informal and as intimate as it could be. My original request to Guillermo was just to get us a room where we could hack and talk, and probably sleep with sleeping bags.Of course, I can perfectly imagine that when he requested the space to the university, on one hand, they didn't feel at ease having International Guests (with capital I and G - Very important for most Latin American universities!) sleeping on the floor. And, on the other hand, they would love to be able to show us around! Having an international project focus on a university in a non-technologically-well-known little country is quite something to show off!Anyway... What happened? I was among the instigators, but Real Life called me away (I've been mostly inactive in Debian since September! :-( ). The miniconf was scheduled for November 14-17. I also insisted originally on having the miniconf on a long weekend (say, Friday through Sunday), as -being a miniconf and not the Real Deal- it'd be much easier for most of us to rob one day off work than a full week. In the end, this was the most important point for my decision not to join: I cannot afford more time off my work, not at this time of year. About the other involved people? I do not want to speak for any other people.In the end, sadly, Guillermo had to inform us they cancelled - No, not postponed, but definitively cancelled. Why? Because -and I have to agree- next year we will have DebConf in Argentina... And many people in the region will focus our time and money on getting there. Ok, making this whole story short: I'm very, very ashamed and sorry, with you personally, Guillermo, and with your whole team. And I hope we can resurrect this idea - be it in Venezuela (as it was suggested once) or elsewhere.

I've been really busy lately in RL and Debian work took the hit.

Some news:

• on the 1st of November, the compendiums on i18n.debian.net managed to waste a huge chunk of disk space and made other scripts (and itself) on churro fail miserably; now there is only a 7 days backlog of the compendiums
• oolite needs an upload due to the gnustep libs transition; I'll try to prepare tonight the long due 1.65-6 version for unstable
• wormux upstream is preparing for yet another beta which should be really close to the final 0.8 version; I wish I had more time to work on this game
• sadly, no news on the naughtysvn front :-( from me
• I have been coding now and then on svn-buildpackage 0.6.23 and I intent to make yet another drop in the bug count visible on the graph:

Since the "World's First Motherboard Using LinuxBIOS Released" hype at the beginning of this year (which was incorrect btw; it was not the first supported desktop board, there were many others before), LinuxBIOS hasn't been in the news very much. That doesn't mean that there was no progress, however. We've been working hard behind the scenes to improve the LinuxBIOS code, add support for new chipsets and boards, and advance the upcoming next-generation LinuxBIOSv3 version which will brings lots of great improvements in various areas. Here's a random collection of stuff that happened in the last few months. New chipsets:

• AMD K8 / NVIDIA MCP55, contributed by Yinghai Lu of AMD
• VIA VT82C686A/B southbridge, contributed by Corey Osgood
• AMD Geode LX / CS5536, contributed by Marc Jones and Jordan Crouse of AMD
• Intel 810 northbridge, contributed by Corey Osgood
• AMD K8 / VIA K8T890 / VT8237R, contributed by Rudolf Marek / Corey Osgood
• AMD K8 / SiS761GX / SiS966(L), contributed by Morgan Tsai of SiS

New mainboards:

• Sun Ultra40, contributed by Ronald G. Minnich (LinuxBIOS project founder)
• K9SD Master-S2R (MS-9185), contributed by Bingxun Shi of MSI
• K9SD Master Series (MS-9282), contributed by Bingxun Shi of MSI
• GIGABYTE GA-M57SLI-S4, contributed by Yinghai Lu of AMD
• NVIDIA l1_2pvv, contributed by Yinghai Lu of AMD
• Supermicro H8DMR, contributed by Yinghai Lu of AMD
• Tyan S2912, contributed by Yinghai Lu of AMD
• Tyan S1846, contributed by myself
• AMD Norwich (AMD Geode LX reference platform), contributed by Marc Jones and Jordan Crouse of AMD
• IGEL Winnet III thin client, contributed by myself
• ASUS A8N-E, contributed by Phillip Degler
• IEI JUKI-511P, contributed by Nikolay Petukhov
• IEI ROCKY-512, contributed by Nikolay Petukhov
• AMD DB800 (a.k.a. Salsa), contributed by Marc Jones and Jordan Crouse of AMD
• ASUS MEW-VM, contributed by Corey Osgood
• Artec Group DBE61, contributed by Marc Jones and Jordan Crouse of AMD
• PC Engines ALIX.1C, contributed by Ronald G. Minnich
• MSI MS-6178, contributed by myself
• MSI MS-7260 (K9N Neo), contributed by myself
• IGEL-316 thin client, contributed by J rgen Beisert
• AXUS TC320 thin client, contributed by J rgen Beisert
• GIGABYTE GA-2761GXDK (Churchill), contributed by Morgan Tsai of SiS
• And a bunch of older Intel 440BX based boards, contributed by myself with some help by testers via IRC: ASUS P2B/P2B-F/P3B-F, A-Trend ATC-6220, AZZA PT-6IBD, Biostar M6TBA, Compaq Deskpro EN SFF P600, GIGABYTE GA-6BXC
• ASUS A8V-E SE, contributed by Rudolf Marek

Note that not all of these may be 100% supported, some may still be work in progress with some TODO items left... Check the LinuxBIOS wiki or ask on the mailing list for details. The future Most work will probably go into LinuxBIOSv3 in the future, in order to make it suitable for productive use.
Of course, work on new chipsets and boards will continue, too. For example the VIA CN700 chipset (plus Jetway J7F2WE board using it) is being worked on right now, probably also several others I don't know about. Call for board testers If you're interesting in trying out LinuxBIOS, please check the list of supported motherboards. If your board is not listed there, but the chipset is already supported we can probably add support for your board relatively easy with some testing help from you. Please contact us on IRC or preferrably on the mailing list if you want to help get your board supported! An (incomplete) list of good candidate boards for future support is available in the wiki. Thanks! We're very grateful for the many contributors who have helped us with testing and fixing existing code, or who even contributed code for new chipsets and motherboards. Thanks a lot! Many thanks especially to all hardware vendors who have been supporting us or even actively contributed by submitting code for their chipsets or boards (recently or in the past), including AMD, SiS, VIA, MSI, Tyan, Artec Group, and many others. Your efforts are very appreciated. Thanks!

I have often posted on the accuracy of my mail filtering mechanisms on the mailing lists (I have not had a false positive in years, and I stash all discards/rejects locally, and do spot checks frequently; and I went through 6 months of exhaustive checks when I put this system in place). False negatives are down to about 3-4 a month (0.019%). Yes, that is right: I am claiming that my classification correctness record is 99.92 (99.98% accuracy for messages my classifiers are sure about). Incorrectly classified unsure ham is about 3-4(0.019%) a month; incorrectly classified unsure Spam is roughly the same, perhaps a little higher. Adding these to the incorrect classification, my best estimate of not confidently classified mail is 0.076%, based on the last 60 days of data (which is what gets you the 99.92%). I get unsure/retrain messages at the rate of about 20 a day (about 3.2% of non-spam email) about 2/3 rds of which are classified correctly; but either SA and crm114 disagree, or crm114 is unsure. So I have to look at about 20 messages a day to see if a ham message slipped in there; and train my filters based on these; and the process is highly automated (just uses my brain as a classifier). The mail statistics can be seen on my mail server. Oh, my filtering front end also switches between reject/discard and turns grey listing on and off based on whether or not the mail is coming from mailing lists/newsletters I have authorized; mimedefang-filter However, all these numbers are manually gathered, and I still have not gotten around to automating my setup s overall accuracy, but now I have some figures on one of the two classifies in my system. Here is the data from CRM114. I ll update the numbers below via cron. First, some context: when training CRM114 using the mailtrainer command, one can specify to leave out a certain percentage of the training set in the learn phase, and run a second pass over the mails so skipped to test the accuracy of the training. The way you do this is by specifying a regular expression to match the file names. Since my training set has message numbers, it was simple to use the least significant two digits as a regexp; but I did not like the idea of always leaving out the same messages. So I now generate two sets of numbers for every training run, and leave out messages with those two trailing digits, in effect reserving 2% of all mails for the accuracy run. An interesting thing to note is the assymetry in the accuracy: CRM114 has never identified a Spam message incorrectly. This is because the training mechanism is skewed towards letting a few spam messages slip through, rather than let a good message slip into the spam folder. I like that. So, here are the accuracy numbers for CRM114; adding in Spamassassin into the mix only improves the numbers. Also, I have always felt that a freshly learned css file is somewhat brittle in the sense that if one trains an unsure message, and then tried to TUNE (Train Until No Errors) the css file, a large number of runs through the training set are needed until the thing stabilizes. So it is as if the learning done initially was minimalistic, and adding the information for the new unsure message required all kinds of tweaking. After a while TOEing (Training on Errors) and TUNEing, this brittleness seems to get hammered out of the CSS files. I also expect to see accuracy rise as the css files get less brittle The table below starts with data from a newly minted .css file. As you can see, the accuracy numbers are trending up, and already are nearly up to the values observed on my production system.

mod_wsgi 1.2 + 2.0~c1 We had two mod_wsgi uploads a few days ago:

• 1.2 to unstable, bugfix release which is supposed to go to http://backports.org after migrating to testing.
• 2.0~c1 to experimental - if you're not running mod_wsgi in a critical environment, please give this 2.0 beta a try and report bugs and problems. It comes with several new features, so you want to read the change log I've linked to the version number.

Reading MJ Ray's post on planet.debian.org and the interesting news of how spamers "crack" CAPTCHA's I keep thinking solutions like the one offered by projecthoneypot.org might be the feature of anti-spam technologies.

---

Please let me know if you see other successful ways to reduce spam or encourage good comments.

I would say using projecthoneypot's http:BL API could help (even tough I haven't actually tried it).

But the statistics and available IP data give a good impression of the system :D

I've even suggested to collaborate and use http:BL at b.d.o but at the moment there has been no reply.

Dear Blogger, Your CAPTCHA (word verification or whatever) doesn't test whether someone is spamming. It tests whether someone has good eyesight, hearing, literacy, numeracy or browser-configuration, which is correlated in one way (few spambots include captcha-crackers yet, but there are some and they already have an 80% success rate IIRC) but it is not strongly correlated for humans (are blind people more likely to spam? I doubt it) and now some spammers are using porno-trojans to get humans to crack the eyetests for them - see http://www.schneier.com/blog/archives/2007/11/spammers_using.html http://news.bbc.co.uk/1/hi/technology/7067962.stm I block spam by premoderating all comments (they're well over 95% spam), but that does mean you need to check your site dashboard a lot to avoid cooling discussions too much. Other anti-spam tactics include OpenID, URL blacklists and so on - I don't use them because I've not added support for them to my site yet. I suspect Blogger.com users can't use them because Google hasn't added support for them. They've bought captcha's false sense of security. http://www.w3.org/TR/turingtest#security As for encouraging non-spam comments, I'll generally defer to this top 10 from Darren Rowse: http://www.problogger.net/archives/2006/10/12/10-techniques-to-get-more-comments-on-your-blog/ On my sites, I find that inviting questions doesn't make much difference, asking questions has limited use because readers are suffering from "question-fatigue" these days and I have difficulty appearing to be humble or gracious (people often read it as sarcasm! Hopefully that's just my audience), but the rest of the techniques seem to work for me and I use them when I can (not all of the sites I write are under my full control). Please let me know if you see other successful ways to reduce spam or encourage good comments. Hope that helps, MJR/slef

It's exciting to read that Cloncurry is going to get a solar power generation plant that sounds something similar to the honking great big one in Spain. All for only $7 million. Apparently the Spanish one cost 1,200 million, which by my calculations is something obscene like $1.8 billion. The Spanish one is going to produce 300 megawatts though, and the Cloncurry one is only producing something like 10. I'm mildly concerned about the other Australian solar tower project that I've been watching with interest. Their latest annual report doesn't offer a status update, and the last two news articles on their website aren't very promising. It'd be a shame to see this project only ever produce the wrong sort of hot air...

Judging from the long list of exim4 bugs, especially #446036, I find myself between a rock and a hard place, and having to choose between staying with GnuTLS and accepting a probably continuing flow of technical issues, or moving over to OpenSSL, setting an example against GNU software, and probably generating a new flow of license issues. GnuTLS is the “clearer” solution from a license point of view: The client library is LGPL, and it can thus be safely linked to everything that is part of Debian main. This is the main reason why we decided to use GnuTLS for exim4 years ago, so that we do not need to worry about licensing issues when some other library is linked to by exim some time in the future. On the other hand, my impression gets stronger and stronger that GnuTLS is not ready for prime-time. There is a truckload of interoperability problems with a number of “remote sides”. The most prominent issues are TLS aborts when exim4 is SMTP server for some clients, most notably Incredimail and some mobile Phones from Nokia and other vendors. Most of them can be nailed down to misnegotiation of certain ciphers, but exim does currently not allow disabling of some ciphers at run-time, and - even worse - one would need to disable them completely since one cannot judge in advance whether we are facing a client with issues or one without. The GnuTLS maintainers of both Debian and upstream try being helpful, but I do not see a long-term solution here. Additionally, nobody upstream knows its way around the GnuTLS related code in exim, which was contributed by Nikos Mavroyanopoulos years ago. So, there is little chance to get GnuTLS-related bugs ironed out from exim. OpenSSL, on the other hand, does not have these interoperability issues. At least, I haven’t heard of any, and the recommended fix for the reporters of GnuTLS related bugs, “recompile exim with OpenSSL” (which the packaging has been supporting for nearly two years now), usually fixes their problems. I am not in a position to judge whether this is caused by people actually testing against OpenSSL, or OpenSSL generally being more tolerant towards strange implementations, or GnuTLS being buggy or poorly written. However, building exim4 again OpenSSL may post the license issues that convinced us to use GnuTLS in the first place. Exim itself has an OpenSSL exception, and from what I have been told, the MySQL FLOSS License Exception allows linkage to OpenSSL as well. At least, it does now, since historical evidence in the exim4 package either shows that it used to be a license violation to link MySQL and OpenSSL in the past, or that we (the Debian exim4 team) wrongly thought so. On the other hand, if it is illegal to have OpenSSL and “really” GPLled code in the same execution space, we already have that license violation today, brought to us by PostgreSQL, which links against OpenSSL. ftpmaster has already indicated that they won’t consider an exim4 linked against OpenSSL a license violation and that the packages would go through, the packaging can handle the change by virtue of flipping a switch and rebuilding, but I am still not fully convinced that doing so is the right thing from a political and license point of view. I might still need that final nudge by feedback to this blog article, or have my reluctance fed. Please comment. No, I do not plan to take this to debian-legal; I’d prefer exim4 staying in Debian main.

These questions came in as comments this week, but I think they're worth a whole post. Peter Swan asked:

"This may seem like a dumb question, but I have not seen anywhere the answer to it. Can a satellite dish be mounted in a loft space or must it be mounted outside?"

There are few dumb questions. DIY dish info is still rather hard to find. You can install a dish behind a window and I've read about special tiles which allow satellite frequencies through on analoguesat's pages about hiding dishes but I don't know anyone using them. A more usual solution is either a hidden location such as a flat roof with baffle boards (dishes only need to see the Clarke belt, which is an elevation of about 20 degrees in England) or to use a non-dish antenna like the digiglobe or the LX2000 pipe. I think it's a really good idea to put the dish somewhere that you can fix it easily. Even the best dish seems to age eventually. I suspect some "professional" installers put the dishes at tops of walls to encourage repair call-outs. Marcus asked:

"Is it possible to receive British satellite television in other countries? I am living in Finland and I was considering purchasing a sky system from the UK and installing it over here. Would it work? Also would I be able to connect a sky set-top box to a different dish?"

Yes, you can get British TV in other countries. Getting external TV like BBC World is easy, but BBC UK services are on Astra 2D, which is focused on the UK. Coverage maps are available on many sites and it looks like Finland isn't well-covered. You'd need a colossal dish. You can connect Sky boxes to other dishes. Sky dishes and Sky LNBs need to go together, sometimes called Skyware, but dishes and boxes are interchangeable. A Sky system will work in Finland, but will only receive services on the other beams like 2A and I doubt Sky will register you at a non-UK address (anyone know for sure?). Also, Sky boxes are horribly crippled for anything other than Sky services and hopefully BBC Freesat will make BBC UK services easier-to-use with standard boxes.

I'm just too bored that everytime I try to write a blog post I end up closing the tab and get back working on something.

---

Not even the fact that DeBaBaReTools is *almost* functional now (at least on my local PC, it will be for the rest of the world as soon as I commit the changes) except for all the hardcoded stuff in wannaBuild.

And not even the fact that there's a new DSA (weasel) stops my boredom (maybe if he could take care of a RT... that would let me spend some time spaming the BTS with over 800 bug reports from DEHS :D).

One should never loose hope apparently. After my previous posts on the topic, Sam put some more pressure and expressed strongly his disappointment in the lack of progress on the DSA front and warned that he might have to look for more radical solution. Phil Hands (who was really quiet in the discussions) decided that the situation had lasted long enough already and proposed to add Peter Palfrader (weasel@debian.org) to the team if nobody expressed any opposition in 24 hours. And this morning, Phil added weasel to the “adm” group… which make of Peter a full DSA member! I really didn’t expect this outcome after so many months of negociations and discussions. But I’m really relieved to see some new blood in the DSA team. I wish him good luck and I’ll hope he will be able to foster cooperation with non-DSA people like I tried since the beginning of the year. Thank you Phil! Partagez cet article / Share This

I have been rather quiet during the last few months. Not really because I wasn t doing anything, but because most of what I have been doing was done by private e-mail. Apparently people are expecting the DPL to disappear around the middle of their term, because I did not get many complaints. But yes, I know that sucked. And well, I now have a reason to regain motivation. \o/ DSA++ \o/ I am very, very pleased to let you know that this morning Phil Hands (fil) added Peter Palfrader (weasel) to the adm group. Which means that the DSA team now has a new member! The first since, wow, quite some time. I am grateful to everyone who made this possible, for bearing with my insistance, for making concessions, for being patient, and I hope this is only the first step to bigger and better teams in Debian. Of course the path is still long but I must admit this is truly refreshing. I wish great success to Peter for the thankless job that awaits him. Nexenta After meeting Michael Man and several Sun people at Debconf and seeing Michael s great talk I got really convinced that the technology present in OpenSolaris could benefit Debian in many ways. And the shortest path to there seemed to be Nexenta. I am currently discussing the possibility of having a Nexenta machine accessible to Debian developers to port and test their packages. I also suggested the Nexenta people to submit patches directly to Debian and try to join friendly packaging teams. Please be nice to them! Conferences Last month I attended Encuentro Linux 2007 in Arica, Chile where I gave a talk about the history and organisation of Debian and how to help and become a member of the project. Due to various issues (such as my passport being stolen when I was 2000 km away from the conference) I did not have the time to give my other planned talk about attracting developers who do not speak English to Debian and FLOSS projects. Fortunately I was able to discuss it with members of the local communities. My goal is to understand why such a large Spanish-speaking area has so few Debian developers, and what we can do about that. One of my observations was that two very important documents (the Debian Policy and the Debian Developer s Reference) were not translated into Spanish, while for instance there is a French translation of the latter. Any volunteers?