A few days ago, I blogged on the popularity of Debian, using Alexa ranking graphs. They showed Debian ahead of the other distributions in terms of web page accesses. Ubuntu definitely was the top growing domain there, but it didn't reach Debian yet, and there was no drop to suggest that Debian was actually losing users to Ubuntu. Here is another chart for you: (Note that it has a referrer block, if you are reading my blog via some planet I'm not aware of, I can add you to the whitelist that is allowed to refer to the image. I added this because some images from my photoblog were heavily linked from myspace and similar sites.) This is a chart from the Debian popularity contest statistics. Submitting data here is entirely voluntary; the data is used to determine which packages to put on which CDs in the CD set. The chart contains four lines, the top line is for bash; pretty much every system has bash, so this is very close to the number of submissions to the popularity contest database. Note that this number has doubled within one year. Sarge was released in June 2005, and thats where the graph changes significantly. Up to then, popularity contest was a rather uncommon package, but sarge promoted its use somewhat IIRC. So lets look only on the post-sarge part of the graph. Ubuntu Dapper was released in June 2006. Any effect? No. The other lines are gnome-session (green), kwin from KDE (blue) and openoffice.org-base (red). KDE is at about 25%, Gnome at about 50% and Openoffice goes up to 50%. This suggests that a significant amount of Debian installations are actually desktop machines (I remove popcon on all my servers, where I'm more concerned with not having too much software on it). For KDE and Gnome, these values have been quite constant. When only counting "active" users, Gnome drops to about 25% (same for OO.o), and KDE to around 10%. VIM would be at 35%, same for apache. I don't claim these numbers are accurate; it's probably more interesting to compare Gnome vs. KDE and similar things. The total number of submissions (represented by bash in this graph) shows that Debian is quite healthy. Oh, and of course I'd like to invite you to install popularity-contest and contribute your software choice to optimizing the CD layout for etch.

Zack asked for website meta languages for redoing his homepage. Well, I redid my homepage last february, using XML and XSLT. A monster XSLT stylesheet, because I wanted to keep my template outside of the stylesheet. I can not recommend XSLT. Using it for templating is quite messy. XSLT is okay if you want to transform one representation of the data to another; it's not if you want to add a lot of surrounding markup and things like a sitemap and similar navigation tools. This is next to impossible in pure XSLT, it gets better once you have some extensions (dubbed EXSLT, and supported by pretty much any xslt processor) or maybe with XSLT2. String manipulation is also a pain (at least with XSLT1); I gave up on generating a nice "last modified" date from my subversion tag. Supposedly XSLT2 has some functions that could make this easier (i.e. for parsing and printing datetime information), but the common approach with XSLT is to only supply the required minimum of function you need, and I'm not aware of an easy way to add custom functions, not to mention any large standard library that can efficiently be used (which is the true strength of Java, Python and C#, that they bring a huge collection of pre-written ready-to-use code with them). Of course there are some efforts to write XSLT libraries (especially for XSLT2), and this aforementioned EXSLT is some kind of standard library that even might be efficiently implemented in some interpreters - you can't rely on it to be there and to just work. XSLT isn't useless, but when it comes to presenting data to humans or writing clean, compact code it's not satisfactory at all. I'd give you my Makefile and XSLT file, if they weren't that messy... too many features; I'm generating two languages, a partially expanded navigation menu, etc. - my XSLT is 10k, my sitemap currently 4.5k, the template file is 5k. Anyway. Half a year ago, my favourite templating language was KID templating. I used it for some small projects such as my DNSoupdate tool to edit DNS zones via the DNS protocol (requires a nameserver such as bind which has support for DNS update, uses encryption). It was a perfect match for such tiny pages, but I'm no longer that convinced I still like it for larger projects. What's good about Kid: XML templating language, Python based, easy to use in whichever way you want by writing a few lines of python (i.e. easy to write a Makefile to generate a static version of you homepage) What's not good about Kid: only works with a Python interpreter. I'd prefer to have a templating language that can be used from multiple languages. However the Kid syntax relies on Python, which is really bad. Also I'd prefer to have some component-render model for more complex websites. The current setup is IMHO okay if you have one default layout and one content layout; but if you have multiple components that could be combined differently on the pages, it gets too messy. With my turbogears experiments, Kid was also not very performant (but that might as well be Turbogears fault). Right now, I'd probably still go with Kid. But I've been having a look at JSP 2.1, and JSF / Facelets in particular. There are some things about facelets that I really like (for example, that they use a proper XML syntax, instead of this bastardized almost-XML that JSP usually (ab-)uses). There is also some stuff that I don't like (e.g. the massive overengineering of everything surrounding it), and I have no idea how easy it will be to generate static pages in a scripted fashion, i.e. using it without a real webserver. Or I might just write it all in python, which is a nice language for manipulating XML, usually. Please don't just send me an email with your favourite templating engine. Like zack, I'm only interested in XML-based templating engines, which does not apply to most templating solutions out there. Clearsilver for example is another bastardization of XML. I'm aware of TAL/METAL, and find them quite interesting, but they were also not having this kind of componentization that I'm usually thinking in. [Update: some people have pointed me to Genshi, which is mostly Kid compatible. However, it still has mostly the same problems, e.g. the templates being not reusable in other languages than python, and that certain constructs are a pain to do (e.g. the page_specific_css recipe with more than one css file). Others have pointed me to smarty, but it's string-based and doesn't ensure valid XML output. (Which is very useful for e.g. generating atom or rss output) For example this is probably valid in smarty: if 0 <b> /if </b> - allowing errors is bad. Oh, and smarty is PHP, which is broken by design, a no-go. The best match to my ideas so far is XML::Template (for Perl, Python, Ruby, PHP) which is pretty close to what I've been doing manually when not using a templating solution. I don't know yet how well it handles recursion - I need recursive templates for the navigation menu on my homepage.]

“The Project for the New American Century” has been reduced to a voice-mail box and a ghostly website. A single employee has been left to wrap things up.

A more glorious lead sentence has never been written about the Project, which basically created and nurtured the neo-con view of the world, and the policies of the current presidency - 8 signatories have been senior members of the administration.
The Project is apparently going the way of Republicans across America with some fantastic backstabbing…. Kenneth Adelman, one of the signatories of the Project (and considered to be a member of its pro-war faction - a pretty terrifying concept, given the hawkish tendencies of the Project in general) and a member of the Defense Policy Board, has gone from

“I believe demolishing Hussein’s military power and liberating Iraq would be a cakewalk.”

to

“I just presumed that what I considered to be the most competent national-security team since Truman was indeed going to be competent.
They turned out to be among the most incompetent teams in the post-war era. Not only did each of them, individually, have enormous flaws, but together they were deadly, dysfunctional.”

in just four years.
Sadly, this isn’t the death knell sounding for neo-conservatism - but it’s always nice to see its edifices crumbling, even just a little.
Merry Christmas!

A few days ago I installed Debian/Etch on my Thinkpad. One of the reasons for converting from Fedora to Debian is that I need to run Xen and Fedora doesn't support non-PAE machines with Xen. Ironically it's hardware supplied to me by Red Hat (Thinkpad T41p) that is lacks PAE support and forces me to switch to Debian. I thought about just buying a new dual-core 64bit laptop, but that seems a bit extravagant as my current machine works well for everything else.

Feeling adventurous I decided to use the graphical mode of the installer. I found it a little confusing, at each stage you can double-click on an item or click on the continue button to cause the action to be performed. The partitioning section was a little unclear too, but given that it has more features than any other partitioning system I've seen I wasn't too worried (options of creating a degraded RAID array and for inserting a LUKS encryption layer at any level are really nice). The option to take a screen-shot at any time was also a handy feature (I haven't yet inspected the PNG files to see what they look like).

Another nice feature was the way that the GUI restarts after a crash. While it was annoying that the GUI started crashing on me (and would have prevented a less experienced user from completing the install) the fact that it didn't entirely abort meant that I could work around the problem.

I have not yet filed any bug reports against the installer because I have not done a repeatable install (there is a limit to how much testing I will do on my most important machine). In the next few days I plan to do a few tests of the graphical installer on test hardware for the operations that are important to me and file appropriate bug reports. I encourage others to do the same, the graphical mode of the installer and the new encryption and RAID features are significant improvements to Debian and we want them to work well.

I have realised that it won't be possible to get SE Linux as good as I desire before the Etch release, even if the release is delayed again. I'm not sure how many fixes can go in after the release (I hope that we could move to a model similar to RHEL - but doubt that it will happen). So I now plan to maintain my own repository of Etch SE Linux packages and for other packages which need changes to make them work in the best possible manner with SE Linux. I will append something like ".se1" to the version of the packages in question, this means that they will be replaced if a security update is released for the official package. Apart from the SE Linux policy packages (for which any security updates will surely involve me) the changes I am going to make will not be major and will be of less importance than a security update.

I will also add other modified and new packages to my repository that increase the general security of Etch. Apart from SE Linux all the changes I intend to host will be minimal cost issues (IE they won't break things or increase the difficulty of sys-admin tasks), and the SE Linux related changes will not break anything on non-SE systems. So someone who wants general security improvements without using SE Linux might still find my repository useful.

My wife Rachael and I are pleased to announce the birth of our first children, Thomas James and Katherine Elizabeth, born on Friday 22 December at 9.02pm and 9.12pm. Katherine (l), Thomas (r)The twins and their mother are all doing very well, and I'm enjoying learning some new skills. I can't think of a better way to start Christmas.

Santa Claus arriving early.


My tree. I bet that if i start looking around i will find final Etch, Duke Nukem Forever and Chinese Democracy CD's somewhere. =)

Well I have a new computer which is running Debian Etch. The process was painful though. For a start I stupidly forgot to check that the motherboard had on-board graphics (hint: no) and so I didn’t order a graphics card. Sadly the motherboard also doesn’t have an AGP slot, so I couldn’t migrate a working card from elsewhere. Instead I had to go out and buy a PCI-express card from a local store. Once that was done I figured installing Etch would be simple. Not so. Update:: Tale of woe snipped. Apparently to netboot into the Etch installer I need to add:

nosmp,acpi=off

The “nosmp” worries me since it is a dual-core processor .. but once I’ve played around and upgraded the kernel I’ll see if removing that causes problems. Update #2: 64-bit host running Xen and X.org. Took me an hour to work out that the sound being “quiet” no matter how much I raised the volume control was due to me plugging in the speaker cable to the wrong socket and not the traditional alsa weirdness I was used to! Strangly even with USB enabled I cannot mount my external USB drive - so that is NFS shared for the moment.

The first step is to configure the CRM114 files, and these are now in pretty good shape as shipped with Debian. All that I needed to do was set a password, say that I'd use openssl base64 -d, and stick with the less verbose defaults (so no munging subjects, no saving all mail, no saving rejects, etc, since I have other mechanisms that do all that). The comments in the configuration files are plenty good enough. This part went off like a breeze; the results can be found here (most of the values are still the upstream default). The next step was to create new, empty .css files. I have noticed that creating more buckets makes crm114 perform better, so I go with larger than norm crm114 .css files. I have no idea if this is the right thing to do, but I make like Nike and just do it. At some point I'll ask on the crm114-general mailing list.

    % cssutil -b -r -S 4194000 spam.css
    % cssutil -b -r -S 4194000 nonspam.css

Now we have a blank slate; at this time the filter knows nothing, and is equally likely to call something Spam or non-Spam. We are now ready to learn. So, I girded my loins, and set about feeding my whole mail corpus to the filter:

 /usr/share/crm114/mailtrainer.crm               \
   --spam=/backup/classify/Done/Spam/           \
   --good=/backup/classify/Done/Ham/            \
   --repeat=100 --streak=35000                  \
         egrep -i '^ + train Excell Running'

And this failed spectacularly (see bug #399306). Faced with unexpected segment violations, and not being proficient in crm114's rather arcane syntax, I was forced to speculation: I assumed (as it turns out, incorrectly) that if if you throw too many changes at the crm114 database, things rapidly escalate out of control. I went o to postulate that as my mail corpus was gathered over a period of errors, the characteristic of Spam drifted over time, and what I consider Spam has also evolved. So, some parts of the early corpus are at variance with the more recent bits. Based on this assumption, I created a wrapper script which did what Clint has called training to exhaustion -- it iterated over the corpus several times, starting with a small and geometrically increasing chunk size. Given the premise I was working under, it does a good job of training crm114 on a localized window of Spam: it feeds chunks of the corpus to the trainer, with each successive chunk overlapping the previous and succeeding chunks, and ensuring that crm114 is happy at any given chunk of the corpus. Then it doubles the chunk size, and tries goes at it again. All very clever, and all pretty wrong. I also created another script to retrain crm114, which was less exhaustive than the previous one, but did incorporate any further drift in the nature of Spam. I no longer use these scripts; but I would like to record them for posterity as an indication of how far one can take an hypothesis. What it did to was have crm114 learn without segfaulting -- and show me that there was a problem in the corpus. I noticed that in some cases the trainer would find a pair of mail messages, classify them wrongly, and retrain and refute -- iteration after iteration, back and forth. I noticed this when I added the egrep filter above, and was not drowning in the needless chatter from the trainer. It turns out, I had very similar emails (sometimes, even the same email) in the Ham and the Spam corpus, and no wonder crm114 was throwing hissy fits. Having small chunks ensured that I had not too many such errors in any chunk;and crm114 did try to forget a mail differently classified in an older chunk and learn whatever this chunk was trying to teach it. The downside was that the count of the differences between ham nd Spam went down, and the similarities increased -- which meant that the filter was not as good at separating ham and Spam as it could have been. So my much vaunted mail corpus was far from clean -- over the years, I had misclassified mails, been wishy-washy and changed my mind about what was and was not Spam. I have a script that uses md5sums to find duplicate files in a directory, and found, to my horror, that there were scores of duplicates in the corpus. After eliminating outright duplicates, I started examining anything that showed up with an ER (error, refute) tag in the trainer output; on the second iteration of the training script these were likely to be misclassification. I spent days examining my corpus and cleaning it out; and was gratified to see the ratio of differences to similarities between ham and Spam css files climb from a shade under 3 to around 7.35. Next post we'll talk about lessons learned about training, and how a nominal work flow of training on errors and training when classifiers disagree can be set up.

I'm pretty happy about the way the 'Ten Web 2.0 APIs you can really use' episode of the LinuxCast came out so well. I'm not very used to talking for recording, and like everyone I don't particularly enjoy hearing my own voice recorded (do I really sound like that?), but it was fun to do, and I think it's a nice adjunct to the Ten Web 2.0 APIs you can really use article itself. tags: api podcast linuxcast linuxworld

Tijuana We're on a trip in Southern California this week, so we decided yesterday to go to Tijuana for the day. Maj, Amita June and I got out of the condo we're staying at in Encinitas early in the morning -- well, early for a vacation day -- and headed down to downtown San Diego. It's a trip of about 25 miles, with one tricky turnoff at highway 805 that seems to get me every time I visit this part of the world. Going into Mexico with a car can be a bit of a hassle. Many American insurers don't cover cars going into Mexico, and you'll often get asked about insurance when you cross over. There are some quick-and-dirty insurers on the border that can give you one-day insurance or other short-term coverage, but we have a rental car right now, and most (all?) rental car companies forbid with bitter, mouth-foaming forbiddance driving the car across the border. Fortunately for us, San Diego has a great way around this problem. Their trolley system goes from downtown San Diego right up to the border in San Ysidro. So, we picked it up in the Civic Center downtown, after a brief stop at the Downtown San Diego Vistors Center (to get tourist material), a shopping foray at a stall outside of the downtown Macy's (to get Amita June a pair of purple Crocs), and a side trip into the Westin for a bathroom break. Man, the Westin in San Diego has nice bathrooms! I'd heard about these trolleys in the past, and I guess I'd expected a kind of fancy tourist train, but it's really just the Blue Line for typical light-rail trains for San Diego and its suburbs. The seats were comfortable, but the train right-of-way went through some of the least scenic parts of Southern California I've ever seen. There's something about this corner of the United States of America that's depressing and end-of-the-world; I get the same feeling about other borderlands, like around Plattsburgh and Laredo. The end of the line for the trolley is completely opaque as to how get into Mexico. We wandered around past some ugly strip malls until Maj spotted a tiny oblique walkway that said "US PROPERTY SUBJECT TO SEARCH AND FINE" and in much smaller letters "a Mexico - to Mexico". We went through a wiggly walkway and across the no-man's land between the scary metal fence at the US border and the actual Mexican customs area. Nobody was there, but we got the feeling we were being watched. At the end of this weird walk was a very nice tourist info center, where we got some maps and brochures and such. Another 10 minutes walk through the streets up against the fence, we got to Avenida Revolucion, the central way through the Tijuana/Zona Centro. It had been a while since we'd been to a city with aggressive touts, so getting yelled at by people in shop doorways or in the street was a bit of a jolt. I hate the invasion of my anonymity, and I'm pretty reflexive about saying "NO NO NO NO NO" to everyone, but Maj is a little more practical. "If everything is run by aggressive sideshow barkers, you're going to miss out on everything," she points out. "Sometimes, you have to say 'yes', even if you don't like the way the question was asked." By the time we hit av. Revolution, we were pretty tired, so we stumbled into the first restaurant we found -- El Torito, a big nightclub with go-go cages, a mechanical bull, and a tattoo parlour on premises. I was attracted by the racy Absinth Mexico posters. "Family restaurant, family place," said the touts, seeing the baby in the stroller. Sure. The food wasn't bad -- I made the mistake of ordering the fish Vera Cruz, but the waiter made a smelly-face and suggested I get the shrimp instead -- and the cocktails at 1PM were generous and inexpensive. Probably the nicest part was a guy with a guitar who came over and asked to sing. "We've got enough music," said Maj, pointing at the ceiling where loud disco tunes were booming. But he was insistent, so we let him play, and he sang a loud Besa Me Mucho that drowned out the Ricky Martin and had us, the waiter, and nearby diners singing along by the end. Amita June was fascinated by the sounds, and clapped along when he was done. After lunch we walked down av. Revolucion, which had a dense layer of souvenir shops and discount pharmacies offering Viagra and Cipro without a prescription. One weird repeated theme was donkeys painted as zebras, hooked up to carts where you could sit and get your picture taken for $2. Some of the donkeys looked pretty good in their zebra stripes, but most looked pretty bummed out. I'm not sure why tourists would expect to get their picture taken with a zebra while in northern Mexico. It got a lot nicer as we got down to the end of the block, and we kicked ourselves for being so lazy when we passed Chiki Jai, a charming little restaurant with tiled walls and rough wood furniture. Much more to our tastes than El Torito. We stopped at the monumental Jai Alai courts, with a beautiful facade and a nice statue out front. Ducking into the Tia Juana's next door, we did a diaper-change break and had some chips and salsa and pineapple juice (and Dos Equis Dark on tap for Papa). Then we started walking back to the border. On our way back, we got off of Revolucion and walked over to the city's Cathedral. It was a much more realistic part of the town -- shopping and bars and restaurants, true, but less ridiculous touristy crap. When we got to the cathedral, there was a holiday street fair going outside, with games and food stalls and people laughing and walking around with kids. It felt a little more human than the pressure-tactics-dense world of Revolucion. On our way back to the border crossing, we dipped briefly into the red light district at the head of av. Constitucion (who knew?), then made the long slog back to the USA. We didn't get much in the way of souvenirs, but Maj bought a nice set of luchador dolls for her brother, complete with a tiny wrestling ring. The line at the border was huge, and we had to wait at the trolley station for another 30 minutes before one left for SD again. By the time we got back downtown, around 5:30, we really weren't up for a dinner in the San Diego/Gaslamp Quarter like we'd originally planned. So we piled into the car, paid the $20 parking to get out, and headed right into rush-hour traffic that led to the over-populated and under-networked North County (San Diego County). Would I take the trolley to Tijuana again? Maybe. Next time, I'd probably go to one of the stops between San Diego and San Ysidro, where there are free parking lots and a little less hassle. tags: tijuana san diego travel san ysidro

Hazards of vacation homes I was just rifling through the fridge here at the condo in Encinitas and found what I thought was a delicious Abita beer, the fine drink you have when you can't handle another hurricane in New Orleans. But it turned out to be an Abita Purple Haze, a gross raspberry-wheat beverage. Unfair! It has probably been stuck in the back of the fridge of this condo for years. Fortunately there was still another Stone Pale Ale, from the North County local microbrewery, to satisfy my lunchtime beer needs. tags: stone brewing abita beer

So, today, I finally stopped the l10n NMU campaign. It started on Sept. 25th with the "Intent to Work" on hesiod. The last package I worked on has been isync today. The goal of that campaign was closing as many longstanding l10n bug reports as possible. The main goals were decided during the i18n work meeting in Extremadura, back in September. We focused on po-debconf translations, mostly, which are an easy target for NMUs. Thomas Huriaux extracted the data from the BTS and ranked packages with regards to the number of pending l10n bugs and their age. Lucas Wall reactivated a coordination page which we already used back in early 2006 when a first version of such a campaign was run. During that campaign, I worked on 102 packages. 89 of them got all their pending l10n bugs closed, 5 of them got most of their l10n bugs closed (remaining "l10n" bugs were either not really related to localisation and strange things which I left aside), 8 packages were ignored either because their respective maintainers wanted to handle the bugs themselves or because they were tagged for removal. Meny packages have also been handled by their respective maintainers, either because the NMU announcements woke them up...or because of their natural release process. I have to point out that the level of collaboration of package maintainers has been great (except for those who are MIA, and there are quite a few) with only one very proeminent exception (just guess which one). Thijs Kinkhorst and Tobias Toedter also contributed to the campaign. Thanks to them as well. As a side effect, we also made many of these packages as lintian-clean as we could, trying to balance between too invasive NMUs and trivial fixes. IIRC, I only introduced 3 or 4 RC bugs doing so (which I fixed immediately of course). A few RC bugs were also fixed by the NMUs and even a security bug has been hunted down (for screen). Meny thanks to all package maintainers, translators and everybody who helped during that work. It has been a great time. Just look at the result. Now heading to the improvement of the next pet project of the i18n task force: the Debian i18n server.

I'm in the process of converting my Fedora/rawhide laptop to Debian.

On Fedora the AES encrypted filesystems deliver about 38MB/s read speed according to dd. On Debian the speed is 2.4MB/s when running Xen and 2.7MB/s when not running Xen. The tests were done on the same block device.

Debian uses a SMP kernel (there are no non-SMP kernels in Debian), but I don't expect this to give an order of magnitude performance drop. Both systems use i686 optimised kernels.

Update: As suggested I replaced the aes module with the aes_586 module. Unfortunately it made no apparent difference.

Update2: As suggested by a comment I checked the drive settings with hdparm and discovered that my hard drive was not using DMA. After I configured the initramfs to load the piix driver first it all started working correctly. Thanks for all the suggestions, I'll post some benchmarks of encryption performance in a future blog entry.

Creating a new locale I'm currently in Cilamitay, in the east of Taiwan. There is a little meeting of Taiwanese Free Software people and people from the Amis, Taroko and Puyuma tribes, with the idea of starting localisation efforts for some aboriginal languages. These are some of the issues we are going to discuss: Language code A new ISO standard (639-3) will hopefully be formalised in January that will include the language codes for the Taiwanese aboriginal tribes. We'll have to work some temporary solution, but there's good hope that it won't have to be temporary for long. List of characters Because of Christian missionary influence, both Amis and Taroko use a roman alphabet, with accents. We need to work out the complete list of character and accent combination, see if everything is in Unicode, see how they sort. We then need to find a comfortable way to input them using the keyboards normally available here (English US layout): compose key? Dead keys? How about on Windows? Womble2 on IRC tells me that on Windows one can works with MSKLC. Technical terms and country list We need to work out how to map terms that do not exist in the language. Technical terms are usually borrowed from Japanese. Names for all the countries in the world probably do not exist. Translation interface We need to find an easy to use interface to input the translations. There is Rosetta. There is Pootle. (Thanks to Christian Perrier for pointing me at it) There is Webpot.

Sergey raised the issue of restricting use of software to non-military use, and Alan pointed out how much they've given back to the FLOSS community. However, I'd like to point out that any such restriction violates rules for opensource used by both the FSF and Debian. Debian is pretty clear about it in the social contract:

No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

And in the GNU Free Software Definition:

The freedom to run the program, for any purpose (freedom 0).

So any such restriction would mean your software is no longer free software. It's not that I'm in any way pro military, but allowing usage restrictions will cause a huge mess. Next we'll have some application which may not be used by religious zealots (of any kind), paedophiles, and at some point end up with a huge licensing mess (maybe even full of discrimination). ("No, I can't sell you a web server, because your brother-in-law is in the military."?) Actually disallowing any military use is some kind of discrimination, too. Military is not only used to kill someone, but it can serve humanitarian purposes, too. Rescue people in flooded New Orleans etc. - if you are unhappy with what your government is using your military for, vote accordingly and do politics. It's fine if you as the author point out that you disapprove of any use of it to harm anybody, or commit crimes; but don't put up restrictions you couldn't verify anyway. (As if the military would care much for any such restriction, anyway.) Always remember: it's only the good guys playing by the rules. There is no use in disallowing use of some software for cracking, is there?

I can be childish too: PHP must die I’ve been actively migrating services away from PHP for a while now, even at the cost of having to use less mature applications which aren’t as pretty. I’m definitely at the point now where I simply don’t trust it and the applications which (ab)use it. Tonights job is to look for a non-PHP blogging application which can import my wordpress content from. I even wrote 75% of one myself once upon a time, but I lacked the time to finish it off. Sure there are good PHP coders out there, I’m just sick of the rest. Somebody should write a intepretted templating system similar to PHP, but with no bugs. Although maybe thats the problem, giving people the ablity to mix presentation inline with code was a fundamentally bad idea to start with? Since it led to non-programmers producing things that were broken. I do keep meaning to look at Rails, but I’m usually turned off by the problems of mixing Debian packages with the rubyforge gems - I like to keep things from one source. (e.g. 99% of my perl modules are Debian packages, not CPAN packages.)

I'm officially on vacation. That basically means there is nobody at my office. This time, though, it does not mean I will be the only sentient being in the building - I'll take most of the three weeks at home. I hope to be able to do some Debian work and catch up with some other projects... Anyway, part of not being at the office means I don't have my usual dose of coffee. At home, I very seldom drink coffee, although I really love to have it home-style (i.e. not made by the easy-to-massify drip coffee machine). In fact, for at least a month, we had not had any coffee.
Yesterday I bought 1/2 Kg of fresh ground coffee at a nearby store. Right away, I drank two large mugs of coffee. Yummy.
Today, I felt a bit more creative. One of the things that my nutriologist taught me in the last year (wow... it's been over a year I started dieting and excercising daily! Around 40Kg less. Not bad, huh? :D ) is that I was eating too little sugar, and ordered me to get at least two portions of sugar a day. So, I'm having today's second coffee. With kahl a (coffee liquor), which would be forbidden at my workplace. And I'm enjoying it terribly.
Hmh... I do hope I don't get too much sugar during vacations! ;-) (including the family dinners over holidays)

The delay of Debian Etch caught some bad press this week. Some articles compare Debian to Ubuntu (which tries hard to have fixed-time releases), and some bloggers are amused by the fact that the next Debian release was delayed “again”. There are some important points though:

• Etch wasn’t really scheduled to be released on Dec 4th. This target date was mainly used to determine other dates in the release process, like the freeze dates.
• Ubuntu Dapper was delayed as well, for 6 weeks. Ubuntu Edgy wasn’t delayed, but I don’t think anybody can seriously compare Ubuntu Edgy’s quality with the upcoming Debian etch’s quality: edgy was more like a technology preview.

Now, the question is: how good is Debian Etch compared to Ubuntu Dapper ? It’s difficult to compare distributions: there aren’t a lot of good metrics for this. Of course, one could compare the number of packages that fail to build from source (it’s a good indicator of something seriously wrong in a package). But a lot of work has been done on etch about this, so it wouldn’t really be fair for Ubuntu. A good alternative is debcheck. debcheck checks that packages can be installed (i.e that their dependancies can be satisfied). It does so by analyzing the content of the Packages files. I compared the results of debcheck on etch as of today (I re-processed it, but the same results are available from qa.d.o), and of debcheck on Dapper (not including dapper-updates - I wanted to compare quality at release date). Included sections were main for etch, and main, restricted and universe for dapper (I didn’t want to consider non-free packages, since their quality tend to be lower). Results: 4 packages have unsatisfiable Depends on etch, on i386. 49 have unsatisfiable Recommends. In the main section of Dapper, still on i386, only one package has a problem with its Depends (it was psycopg, because its binary package python2.3-psycopg has a dependancy on python2.3-egenix-mxdatetime). 46 packages in main had unsatisfiable Recommends. This is better than Etch, of course, but Ubuntu/main is much smaller than Debian/main. When restricted and universe are included, the results are much worse. 80 packages have unsatisfiable Depends, and 150 packages have unsatisfiable Recommends. It is worth noting that those numbers are worse than those of Debian unstable as of today (67 packages have unsat Depends, 34 have unsat Recommends). Conclusions (sort of):

• Using the debcheck metric (which is actually quite important, since it translates in uninstallable packages for the users), Debian etch is already of better quality than Ubuntu Dapper when it was released (again, I haven’t checked with dapper-updates included).
• It would be great to integrate such tests into the Ubuntu release process. Fixing bug is good, but such tools help to improve the distribution quality as a whole. I’ll try to work on this for Feisty after the Etch release.

Only six days until 23C3 basically starts. I'm looking very much forward to lots of interesting stuff and much more I guess. (The schedule is made with Pentabarf which we're also using for DebConf7, btw.)

Also this year for the first time there will be a chaotic debian presence where we would very much appreciate your help which will be rewarded with a badge like the one below :-)

Please leave your name on the wiki page or tell Mario or me if you intend to help and that we should prepare a badge for you :-)

Hugo Ch vez wins “Person of the Year” poll … Time magazine ignores result. More on Spanish here and here.

Erich Schubert's pastime seems to be accusing others of trolling and FUDing (a politically correct buzzword that actually means lying) while contributing to these trolls and spreading lies himself. I had warned I would reduce my involvement in the project if dunc-tank was started. I reduced it much less than I could, probably much less than I should. I had warned that maintaining libpng required a high profile developer with time and motivation, and I had lost the latter. Basically, the dunc-tank cabal chose to ignore such warnings - as well as similar warnings given by other developers - and thought they could do better without us. Fine. I didn't do anything to prevent libpng from being maintained, and yet you see the result. Trying to put the blame on me for this disaster is simply outrageous. Sure, I have my share in this disaster. Just like you, Erich. You and all others who didn't work on libpng for this time. You let a junior maintainer try to deal with a complicated package, and you let him fail, like every one of us would have failed when we were new in this project. Now, if you really think that:

• warning the release team of this disaster before it hit us,
• giving advice on how to fix it,
• helping them to build their fix,

was being childish, there's nothing I can do to help you, as the kind of help you need has nothing to do with computing. What I have learnt in the meantime, though, is that most people in the project are really able to appreciate any kind of help, which is why now, I won't let myself be hurt by those few who spend time insulting other developers rather than maintaining packages.

For various reasons, Software in the Public Interest (SPI) owned the domains opensource.org and opensource.net, which have been managed by the Open Source Initiative (OSI) for most of their life. This supported various SPI goals and also gave a possibility of community control of opensource.org/net just in case it was ever needed. OSI does not offer much opportunity for community control, as it is a self-appointing board. (Regular readers may remember that the principles of democratic member control, autonomy and concern for community are important to me.) I was watching as the SPI board voted in favour of giving away the opensource domains, proposal 2006-11-18.dbg.mjs.1 on the agenda. The vote happened without any discussion in the meeting. From memory (I guess logs will appear on the SPI site eventually):- David Graham ("SPI must also be involved in the promotion of and education about open source") proposed and voted for this action that stops SPI being involved in this promotion and education about open source; Michael Schultheiss ("I look forward to SPI's future expansion") (amended and?) voted for this action that reduces SPI; Neil McGovern ("achieve a greater degree of involvement [...] from the community in general") voted for this action that lessens SPI's involvement; Jimmy Kaplowitz ("It is important that it continue holding in trust the money and other legal assets belonging to its member projects [...] fulfill some more of its stated corporate purposes, involving education of the general public about free software and about computers in general") voted for this action that drops these assets and reduces involvement in education of the general public; Bdale Garbee ("would like to close this issue one way or another, once and for all") seemed willing to vote for anything which prevented further discussion - of course, only surrendering the domains could close it once and for all, as this is a one-way trapdoor topic - but had apologised for absence from the meeting; Martin "Joey" Schulze had apologised for absence from the meeting; Josh Berkus (nothing obviously relevant in his platform) abstained - consistent but disappointing; I think Branden Robinson was missing. Ian Jackson ("SPI's role is to provide a stable legal entity which can hold assets") voted against this action so that SPI would keep holding these assets. Bravo! Sources: The quotes above are the board's own promises in their election platforms, as listed on the SPI site in 2003 2006 apart from Bdale Garbee's platform which wasn't at the link given in 2004 so that quote is from the minutes of the previous meeting If some board members are willing to give away assets for no good reason, that strikes at one of SPI's core methods: holding assets for the community. What can we trust about this board? Their platforms are full of fine sentiments, but how do their actions reflect their platforms? This may be a mostly-dormant issue until the next election. If you want any of SPI's assets, just ask. If your request is rejected (as SPI rejected the opensource domain give-away before), just keep asking new sets of voters until they agree.