These are my ten wishes for 2007. Since Santa didn’t arrive in this part of the world, I think I’m asking this to the Three Wise Men (in spite of they were brought here by the Spanish catolicism, but hey):

1. Dignity, land and respect to the Mexican indigenous groups.
2. Return and good health for Commander in Chief, Fidel Castro.
3. Strongest antineoliberalism in the Latin American region.
4. Right wing oppression brought down in Bolivia.
5. Good year socially, economically and politically to Nicaragua with its new hope.
6. An even better year in Cuban trades; they were the best growing economy in Latin America by exporting to South America and China.
7. Stop to the free trade agreement and military bases with the US in Ecuador.
8. Peaceful solution to the Colombia-Ecuador border conflict.
9. Democracy established in some of those countries where it’s more needed, like Central America.
10. More social successful programs in Venezuela.

And my bonus one:

• Peace from R o Grande all the way down to Tierra del Fuego.

I have discovered a treasure reading a movies blog: first Pixar animation video The adventures of Andre and Wally B. from the astonishing year of 1984. It was filmed when Pixar was still a division in Lucasfilm Ltd., and was directed by John Lasseter and Ed Catmull. As they credit in the film itself, a Cray X-MP/48 was used from Cray Research, and also ten VAX 11/750s from DEC, which were part of MIT's Project Athena. A piece of cake Update: Wikipedia has also a reference to this movie.

We had a tough time getting out of Encinitas yesterday. It seems like everything was going wrong. I'd forgotten to order food for a sick aunt and her family in New Jersey the night before, so I was scrambling with apologies and new orders all morning. Then, when we finally got out of town, we hit traffic for about an hour near Santa Ana. Blech! Fortunately, it's a nice stretch of California highway, and we could see Catalina Island off on the horizon to the west. Our Christmas-eve-eve (or Festivus, if you will) was spent at Maj's parents' house in Long Beach, with about 30+ Jenkinses plus various offshoots and friendly relations. They have a huge house near Long Beach/Belmont Shore, with a giant tiled patio area that goes right into the house. It was a good place for a party. Amita June got some nice gifts from family, including a screaming monkey doll dressed as Superman. Yeah, we already have one screaming monkey doll with an "I LA" t-shirt, so this new one will join our growing collection of screaming monkeys with poor sartorial taste. tags: christmas belmont shore festivus long beach amita june

Typewriters are broken Yesterday Amita June and I were playing with pyKeys, from the awesome pyToddler suite of tools, and I realized that typewriter keyboards are broken. I was showing her that when she pushed on the key marked "Q", a "Q" would appear on the screen. But that's not what happened: instead, a "q" appeared on the screen. That's not a bug in pyToddler, of course: that's just the way typewriters work. If you click on the button marked with a capital letter, it prints the lowercase letter on the paper or screen. To get the capital letter itself, you have to put the keyboard in another mode, or use a modifying chord key. I'm not sure why this is the case. It's clear why we use modifier keys to make capitals, since we type lowercase keys much more often. But why do keyboards show the capitals printed on the keys, then? tags: typewriter keyboard pytoddler pykeys

Free Culture Christmas If there's anything that gives a bracing jolt of Christmas cheer, it's 235 Creative Commons Christmas songs. Thanks to Uwe Hermann for compiling this fine list. tags: cc christmas open content music christmas song

Character list for the Paiwan language We mapped the available glyphs and accents for the Paiwan language. The letters in alphabetical order:

a b c d e f h i j k l m n p q r s t u v w y z   n       

No uppercase. All the characters are in Unicode except n , which already needs to be requested for the Amis script. We need to design an input method to enter the underlined letters and the n .

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.

Which Website Markup Language? Dear Lazyweb, now that I've finished my Ph.D. thesis (i.e. now that I'm officially unemployed ) it's time to renew my vetust homepage. That page is written with WML, I used to be quite happy with it, but this is no longer the case (lots of reasons for that snippet). I'm now looking for an XML based markup language for re-writing my new homepage, the features I would like to see in a tools based on it are:

• content-oriented XML-based markup for describing the content of the website (if not XML-based at least processable via an API implemented in some programming language I like: python, ruby, ML, ...)
• legacy XSLT (or whatever if not XML-based) transformations for generating XHTML 1.1 pages which can be statically served by a web server requiring no particular extensions
• ability to extend both the input format of the transformation tool (e.g. adding support for new XML dialects) and the corresponding transformations, and to integrate the results in the resulting website. Relegating the results of the ad-hoc transformations in a subdirectory of the resulting website which is not integrated elsewhere is not ok
• ability to integrate verbatim snippets of XHTML/Javascript/... in the input document where needed (hopefully not so often)
• clean final XHTML pages which rely only on CSS for presentational purposes would be nice
• support for predefined common website layouts would be nice (e.g. 2/3-column layouts supported by Google Page Creator)

Of course I can design my own XML format and all the needed XSLT transformations, but I would like to avoid re-inventing the wheel if possible. Actually a while ago I think I read about a couple of tools like the one I'm looking for here on planet, but right now I'm unable to find the relevant posts. Similarly I'm apparently unable to find the right set of Google keywords for finding anything useful.

Character list for the Amis language We mapped the available glyphs and accents for the Amis language. The letters in alphabetical order:

    a c d f n  h i k l m n o p r s t u w y

Everyone of them can get an acute, grave or circumflex accent on top. Literally on top: i would get the dot PLUS the accent on top. The only exception is for the letter n , which gets the dot on top of the g replaced by the accents. Some accent combinations are missing in Unicode, like accented d, f, h and k, and i with dot and accents. So we need an extension of Unicode. Then we need an input method that would insert n instead of g and allow to type all the accent combinations. Here is the full character set:

    a              
    c       ?      
    d       ?  ?  ?
    f       ?  ?  ?
    n       ? n  n  [1]
    h       ?  ?   
    i       ?  ?  ? [2]
    k       ?     ?
    l       ?     ?
    m       ?     ?
    n             ?
    o              
    p       ?     ?
    r       ?     ?
    s       ?      
    t       ?  ?  ?
    u              
    w              
    y              

[1] the gliph for 'n ' is actually missing, because it needs to be a single character: since it is a letter, backspace and delete need to erase all of it in a single shot. [2] missing because of the accent on top of the dot. Question marks mark where a character is currently missing in Unicode. We have a problem because Unicode would not want anymore latin accent combinations, so we will need to use character combinations and hope that fonts and applications display them well. This raises the issue that hitting delete or backspace on a character built using combining accents would delete only half of it. For consistency of interaction, it can make sense to use combining accents for all the combinations, even if an accented letter does exist in Unicode. This would avoid backspace and delete to have different behaviors, for example, on s-grave and s-acute. The accents are not taken into account when sorting. Uppercase letters are not used.

Looking at my webserver logs, there seems to be a highly increased demand for my 10 + 100 Creative Commons Christmas Songs blog post from last Christmas... I wonder why... ;-) So I decided to update the list this year, adding a bunch of additional songs; in total there are now more than 230 songs listed. Of course the list is incomplete, so any further links to Creative Commons licensed Christmas music are very welcome. Just leave a comment here or directly on the old blog post and I'll update the list. I'll probably also put up some more Christmas-related songs on my Creative Commons music podcast over the next few days... Image credit: Photo taken from Wikipedia. Author: Kelvin Kay. License: GNU Free Documentation License (GFDL), version 1.2.

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.

For those who have missed the previous blog entries: Debian Package of the Day (aka Deb-a-day) is now alive again ! There has already been several entries (published 2 times a week, on wednesdays and sundays, until we make sure that we can sustain an higher rate):

• scribus-ng: next generation of the desktop publishing program
• python-scipy: get the math done
• htop: powerful top replacement
• qalculate: the ultimate desktop calculator

Deb-a-day is not syndicated on Planet Debian (because of the “only personal blogs” rule), but it’s syndicated on Planet Ubuntu, and it might be syndicated on Debian Times (negociations are still ongoing :-). Don’t forget to subscribe to the feed ! We (the nice team of editors) have 2 entries ready in the queue, but that’s not enough. If you discovered an interesting package through Deb-a-day, and didn’t submit an entry yet, you should really feel guilty now ! (we are especially looking for cool graphical apps, so Deb-a-day becomes less nerdy, but apps for nerds are welcomed as well, of course.)

Hardware sucks. It just totally and utterly sucks. I purchased a 300 GB hard drive (plus a 3.5" USB disk drive enclosure) roughly 8 months ago which I encrypted using dm-crypt and then used it as a backup medium. And now the disk has died. No, this is not a software problem (that would be easy to deal with), the hardware is simply dead (it's making funny "klck" noises all the time). Mounting it via USB (using the USB enclosure) doesn't work at all anymore. I connected the disk via IDE in a PC and was able to mount it just fine (with cryptsetup luksOpen and all). A simple ls works, too (at least in the top-level directory). So I tried to copy the data over to another medium, but when accessing certain directories or files the system simply hangs and I get tons of funny kernel errors (and the disk makes even more and louder funny noises). Great. Stupid as I am, I also put data on the drive which I did not have backups of on other media (mostly because the data is huge, e.g. conference video recordings, large amounts of Creative Commons MP3s etc). OK, so I managed to get at least some small parts of my data, but now the disk is completely dead, I fear. I'll try to convice the vendor to give me a new drive, but I won't let them get their fingers on my data, i.e., I will not send the disk to them (yes, even though it is encrypted; crypto can be broken). Any ideas what else I could do? A professional "data recovery" service is not an option either, they usually cost 1000-2000 Euros (in the best case). What do you do for storing huge amounts of data nowadays? The only viable option I can think of is a RAID-5 (mdadm) with 3 or more disks in a silent PC which I can leave turned on 24/7. Unfortunately that costs non-trivial amounts of money. CDs are too small and they don't last too long either; the same is true for DVDs. Sigh...

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.

I've been sitting on this for a while, gradually adding more bits as I think of them. So it's a bit long and rambly, but if I don't post it now I'll never get round to it. First, the details, for anyone who cares. I got married to my partner of 11 years, Katherine, on 1st December. This was actually our 11 year anniversary. We had a civil ceremony in The Assembly House, Norwich with a wine reception afterwards, then moved on to Wolterton Hall for the main reception, with a magnificant feast provided by Brasteds. Afterwards there was a chocolate fountain courtesy of Digby's and Nero thanks to Milton. The wedding cars were provided by American Dream (we had the Excalibur Sedan and the Lincoln Town Car). The bus to/from the reception was from Dolphin Autos. Robin Phillips brought the band. Wonderful purple jacket + the other suits were from John Field Formal Hire. Next, some photos. Burly Dave Ganesh Paddy Steve Tim (Ceremony) Tim (Reception) Finally, some things I've learned. For guests (I wish someone had told me these - Katherine says I sound stroppy but I don't mean to):

• As soon as you know if you're going or not, let the couple know. Especially if you're not going. They will probably be constrained on numbers and there are very few people who can be invited at short notice if you only let them know you're not coming by the RSVP deadline.

• Don't leave buying your present until the last minute. The couple will have lots more important things on their minds in the final week or two than trying to make sure there's enough left on the gift list.

• People really do mean that they'd rather you turned up than gave a gift. I never fully appreciated this; I'd feel bad going to a wedding without having given a gift. However I know that it's not cheap to get to Norwich and (in most cases) have to spend at least one night in a hotel. I'd much rather people did that and I got to see them on the day than they sent a present.

For couples getting married:

• It costs more than you think. Really. I'd always assumed hotels dug their arm in for weddings and upped all the prices, but actually the hotels we looked at were the cheap options, both in terms of the actual cost and also the fact they'd throw extras like a honeymoon suite in for free.

• Make sure everyone in the wedding party knows the way to the ceremony venue. Really. Don't rely on them to ask you, or assume that they'll have looked at the directions you've prepared.

• People are far too generous. We received many completely unexpected gifts from relatives or friends who we hadn't invited to the wedding, or those who couldn't make it. (As well as many of the people who came to the wedding buying us far too much.) If you gave us a gift, you will get a thank you card - these are already in progress but it probably won't be until after the New Year before they're all sorted and sent.

• Don't leave booking a honeymoon until after the wedding. We had issues regarding not being sure about Katherine's holidays and we ended up not sorting anything until a couple of weeks later. This reduced our options somewhat.

• So far it doesn't seem to have changed anything much. Katherine and I have already been living together for some time which we consider a bigger step. And we haven't seen a whole lot of each other since the wedding, though we have spent the past week together. But really, we don't feel a lot different yet.

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.

ls2rss AFAIK amule is missing notification of completed downloads. In addition to that, me and Godog are sharing the same amule instance and it's cool to be notified of what the other downloaded, it's a bit like the for:someone tag on del.icio.us. As an issue of my hack of the day series I hence implemented ls2rss.py. The name is telling: given a directory it generates a corresponding RSS feed. It's written in python, it's meant to be run as a cron job, and takes care of minor details like remembering files that have been deleted since the last invocation and enforcing a threshold to the feed size. I was unable to find anything like that already available on the net (the one available here is not available for download any longer). In case of need, try mine. Download

• ls2rss.py (python script) Requirements are: python-syck, python-pyrss2gen or equivalent non-Debian packages
• [sample YAML configuration file incoming.yaml] used by me to monitor my ~/Incoming/ directory

Big week for me in and around the media. Huzzah for fame and fortune!

Web 2.0 APIs I'm really happy that an article I wrote for Linux World on Web APIs for software development was published. Called Ten Web 2.0 APIs you can really use, it covers the APIs available today that are really useful for more than just gee-whiz mashups. I'd covered a few of the services when I did a story for LW on the Web 2.0 Summit, so Don Marti asked me to follow up with a full rundown on the world of Web APIs right now. tags: web2.0 api web api linuxworld article

Wikitravel on the AP wire On the other side of the media lens, Wikitravel is one of the sites featured in an article on the API wire by Anick Jesdanun called Travelers contribute to online guides. Although the article covers a lot of other travel sites, and even has some sour grumpiness by proprietary travel guide publishers, I think it's very favorable to Wikitravel. tags: wikitravel ap anick jesdanun travel guides

Thanks, Tom Also, it was nice of Tom Brown from Stuffopolis in talking about his OpenID Podcast to say that the OpenID extension for MediaWiki is "excellent". Gawrsh! tags: openid stuffopolis tom brown mediawiki excellence

Many people have recently posted in Planet Debian regarding the use, usability and usefulness of having comments enabled in blogs, of using comments as the right way for following discussions, of dealing with spam, and so on.
I'm sorry I'm not linking to more of them, but I'm too lazy to look them up. This is one of the down-sides of not using comments - Ideally, if I were interested on commenting on a topic, I would just leave the comment on the blog that started it. It goes somewhat against Joey's logic of posting both the comment and the posting itself - Of course, we all want everybody and their dogs to read our comments, don't we? And, given we know that (most of) our target readers regularly follow Planet Debian, we continue ranting on our personal blogs (as I'm doing now). Besides, that will rank our page higher. We all want Google to love us, right? Of course, following discussions on a bunch of blogs is not optimal, as it's easier to miss parts of it (hey, would somebody volunteer on writing threading support for Planet? It'd have to be multidimensional, as postings often refer to different threads... Bah :) ). Besides, many of us are syndicated on different planets (and many people read our blogs as individuals as well), so many of my postings start with a stupid amount of background information so the martians understand the terrans. But still, here I am, writing a post that provides nothing but a braindump, serves no purpose, and links to your posting. So there, the world is not ideal. QED.
As always, MJR rants against captchas (and yes, thank you, you have commented on my blog that most captchas are trivially crackable by automated means). They do reduce spam, but they are REALLY not a strong barrier against it. I have thought of some ideas, or thought about implementations for other ideas I've read here and there, but I'm too lazy to implement them on my blogging software. I could switch, but I happen to like Jaws. I would like to contribute to making it better, but have had a permanent lack of time for a long time already :-/ I do get swamped by spam comments, and every now and then mass-delete whatever looks like spam (hundreds to thousands of comments, for crap's sake!), but anyway... It's not too important for me. I like having comments on my entries, but sometimes a long time must pass until I even read them (I read my own blog syndicated via the Planets, on a RSS reader).
BTW, Lucas: I used to have trackbacks enabled. The amount of spam, and the control I have over spam in my blog, makes me favor comments against trackbacks. My trackbacks used to be so wildly abused that it almost made me cry. I hope it is not your case :)

In part 1, I described the problem of software installation on Linux; in part 2, I’ll describe the solution we came up with at the recent LSB Packaging Summit. After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux—you know, like the one Microsoft has built around Windows. No, it’s not about imitating Microsoft. It’s about being competitive. A platform is only as good as the applications that run on it. Bottom line: Many third parties have built their businesses around proprietary software, and we can’t just ignore them. And “ecosystem” implies decentralized, which I argued in part 1 was a key tenet of open source development anyway, i.e., this should be playing to one of our core strengths. So, if your “solution” is to tell ISVs (independent software vendors) to give us their source code so the distributions can include it because that’s just how we do things, you can safely skip the rest of the post below. You’re simply not going to agree that any of this is a problem. Ok. Assuming our goal is to create a vibrant third party software ecosystem (and everyone still reading agrees that’s a good goal, right?), we have the following challenges. First of all, the distribution vendors are hugely invested in their existing package systems, and for the most part, those package systems work extremely well. As I said in part 1, “if [an application] is in your distro of choice, you re only an apt-get or a yum install away from running it.” (I’m saying it again here because some of the commenters apparently didn’t see that. The tricky bit is “in your distro of choice”, which by definition is not the case with third party software.) Furthermore, a variety of highly sophisticated systems management solutions are built above those package systems, such as Red Hat Network and Novell ZENworks. This is a pretty important consideration, because these days, the “software management problem” largely involves managing software across the entire infrastructure, not just a single system. What problem then? This: ISVs have thus far been reluctant to use the native package systems. Why? THEY’RE hugely invested in “package systems” for other platforms, and every Linux specific thing they have to support costs money. In a world where decisions are ruled by cost vs. benefit, this is a pretty important consideration too. How do ISVs handle this today? For the most part, they ignore the package systems on Linux and do their own thing. Trouble is, while doing their own thing gives ISVs the flexibility to work cross platform, it ultimately makes their products integrate poorly in the broader systems management context because the package systems know nothing about them. What is needed is a way to bridge the gap between what the distros provide and what the ISVs want. But how? First off, we have to understand what ISVs want. The answer is simple: ISVs want to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows. So, if one commenter is right that “[t]he problem is that people (including software distributors) believe there s such [a] thing as ‘Linux’ as a target platform” and that “[i]f you re distributing software for ‘Linux’ then it won t be simple to install it, ever”, well, then Linux is destined to suffer the fate of UNIX. I’m not ready to give up so easily. Several commenters suggested that what we need is a brand new package system. That’s a non-starter—for one thing, the distros aren’t going to be too keen on replacing something they’re hugely invested in, and if ISVs aren’t going for RPM today, why would they go for something different tomorrow? No, to find a way forward, we need an evolutionary step from where we are today. From there, perhaps we can do more, but even the first steps can be quite valuable in their own right. To help find those first steps, we put some of the leading minds in Linux packaging in the same room (including the maintainers of RPM at Red Hat and Novell and the authors/maintainers of APT, yum, alien, and klik) along with ISVs large and small, server and desktop. The discussion pretty quickly converged on constructing a single API that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences. Question is, what do ISVs need in such an API? Limiting the scope is key here, because providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable, not to mention more work to implement, which in turn makes it less likely to get into the distros so that ISVs can count on it being there, the whole point of this exercise in the first place. Fortunately, the ISVs don’t really need much. At the most basic level, an installer just needs to be able to query the system to see if it’s LSB compliant, and if it is, what version of the LSB it’s compliant with; and it needs to be able to “register” with the package system, so the package system knows about it, including what files it has installed. And that’s really about it. Importantly, because we assume an environment that’s LSB compliant, we don’t have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support—components can extend the LSB, and applications can depend on those other components being installed—but we’re talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with. We only had a day, so we obviously don’t have a complete solution yet. For one thing, we barely touched on the issue of uninstallation (should we allow applications to register GUI uninstallers?), and the issue of how applications go about changing the system configuration still needs discussion (in a lot of cases, the assumption of LSB compliance means the installer is going to be well behaved, but there’s undoubtedly corner cases to be explored). And it’s going to take time for the API to be implemented and put into widespread enough use that ISVs can depend on it. However, everyone in the room did come to consensus pretty quickly that this was an important problem, and that providing a simple API that provides the minimum necessary functionality was the way to go. Perhaps most exciting, the very people whose support are needed to put the API into widespread use were in that room, and active participants in the discussion too. Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets. Because this is just a start, the FSG is launching a Packaging workgroup to continue the discussion we started at the Packaging Summit. If you’re interested in this topic, I’d encourage you to join the mailing list and get involved. There’s still plenty to be done. Update: One more thing: In addition to making it easier for ISVs to better support Linux by simply extending their existing installation scripts, the API approach really comes into its own when you imagine it implemented in things like Autopackage and InstallAnywhere. Let the market decide!