I've been getting a lot of blog spam lately; it appears that Akismet is slipping. Fortunately, there's a new Akismet-compatible alternative at TypePad AntiSpam which I read about from Justin Mason's post. And it being perl, I decided to try it out here on my blog (never mind it being Blosxom, as long as it uses Frank Hecker's feedback plugin that in turn uses Net::Akismet. But alas, the current version of Net::Akismet doesn't support user-supplied REST endpoints, so I added it, and promptly filed a report on the CPAN. Hopefully it gets included in the next release very soon. As for the Blosxom feedback plugin, tweaking it to use the new feature in Net::Akismet was a cinch, so only the real test (of incoming spam filtered by TypePad) remains. Hopefully it does work. [PS: Looks like the first line in blosxom posts don't like package-like names such as Net::Akismet (during editing my blog title disappeared on the render!) Needs to be looked at later...]

(How I get TV) The British Broadcasting Corporation, the largest UK public service broadcaster, is seen as a slow lumbering beast and a bit clueless about technology, as you can see from the comment when I wrote about Click: Free=beer and facebook-flaming recently. I think that's a pretty typical view. For example, the BBC has recently helped to launch Freesat which is good in some ways (free-to-air and maybe more standards-based than Sky) but still publishes half-truths like

"Installing a satellite dish is a job for professionals"

(On balance, it's no harder than installing most TV aerials, in my opinion, but remember you get no warranty on DIY.) It's pretty much the same situation online, which is why stories like The BBC and innovation [DavePress] and Good news for websites - BBC told to link out more! continue to be news, nearly 12 years after the BBC's website launched. (Source) One of the few areas where BBC triumphs is probably news-gathering, picking up stories that are unpopular with both business and government, like BBC NEWS: Towns triumph in broadband tests which follows the Experts Say Ofcom Wrong About Rural Broadband storm online. I recently helped The Doon of May team look into internet connectivity and I was surprised how bad it was in their location: a bit of attention from BBC News is most welcome. If you'd like to try receiving the BBC - or some other national broadcasters in Europe - by satellite, I'm currently taking Questions About Cycling on Satellite over on my Cycling Fans blog.

(Guess I arrived early.) Dear Reader, I'd like to read any opinions on these three:- 1. when I get new information about a story I've already written about, should I make it a new blog post and/or add it to the old post or something else? For example, I've got new links about the Yahoo's good anti-spam actions which is sort-of linked to last week's spammer registrar post. 2. what should I do with links to sites where I've commented? Should I make a new feed like my bookmarks feed, silently ignore them, or something else? Last time I did a link post, mildly irritated comments followed on one of the planets. 3. Tonight is my first full Kewstoke village council meeting. Main (non-routine) topics include Sand Road Lay-by, Crookes Lane Memorial Seat, the newsletter, replacing the gazebo on the village green, coopting more councillors, completing the Crookes Lane Footpath, the 2007-08 accounts and reviewing the Sand Bay Management Plan. Any comments on any of those?

Switching to Perl 5.10 for Debian unstable uncovered a bunch of little problems with the Pod::Man based on Pod::Simple that's included with it. I've unfortunately been slow to fix those problems due to being buried in other work, but this release finally cleans up the ones that have been reported, namely:

• Font problems with two or more C<> blocks in a =head
• Fix subheadings with leading *roff metacharacters
• Fix hyphen escaping to not corrupt eth characters

However, the big change is that pod2man now supports a -u (--utf8) option saying to not munge input characters into ASCII and *roff escapes that only work with troff and instead output literal UTF-8 characters and assume one's man program can cope. This will now be true of Debian as of lenny. I have no good ideas for how to do the transition, since the resulting *roff is not portable and, if copied to another system, can even cause deficient nroff programs to segfault. One of the goals of Pod::Man was always to produce portable *roff output, so this option is not the default. However, it is clearly the Right Thing To Do for systems whose man and/or nroff are sufficiently intelligent; any other option either requires embedding groff-specific character escapes (same portability problem) or corrupting non-ASCII characters badly (the previous approach). Any bright ideas welcome. In the meantime, people who know they're working on systems with modern nroff and man can at least get correct output now. Hopefully podlators 2.1.0 will make it into lenny (as part of the Perl package, since it's a Perl core module), either as 5.10.1 if upstream is fast enough or as a Debian-local modification. (We definitely need a new Perl release before lenny; #480428 would be embarassing and is already driving me nuts by producing spurious output from lots of cron jobs. I'm thinking about asking for an upgrade of the priority.)

I ogled with an ASUS EeePC since it was announced, but didn’t want to order one abroad. So I waited until they became available in Switzerland. Digitec is the official EeePC importer for Switzerland and seeems also to be the moving power for yet to come the Swiss localisation of the EeePC. But initially they only offered imported EeePCs with German keyboard layout, but since I really got used to the US layout, I didn’t want to buy ay new laptops or keyboards with German layout. When asking them about US layouts they told me they won’t import from the US and that their competitor Steg Computer is importing US models. But I wasn’t comfortable with Steg and EeePCs also were more expensive there, so I hesitated ordering at Steg. So it was quite unexpected for me when US models showed up on digitec’s website. (Interestingly I never received any mail from their advertised EeePC newsletter, not even when they added 2G models t their repertoire.) So at the end of March (and therefore later as most other geeks ;-) I ordered an ASUS EeePC at digitec. For me, white laptops look like Macs (and Macs are for sissies or masochists ;-) — so I had no problems to decide that I want a black EeePC with US keyboard layout. 2G was to small for my purposes (and also not that much cheaper) and 8G not available. So I went with the 4G, since Debian doesn’t need so much space if you choose the right packages (i.e. neither or at least not that much of GNOME or KDE ;-). I preferred the 4G over the 4G Surf because of the bigger battery capacity (and not because of the webcam which I consider funny but useless:-). Initially the delivery date was set the 28th of March. Then it was subsequently set to “beginning of April”, “mid of April”, “end of April” and “beginning of May”. It finally arrived on 8th of May. In the meanwhile there were reports that even the 4G has been equipped with the smaller battery of the 4G Surf because of some battery shortage after some battery plant burnt down. But fortunately the delivery problems with black 4G US models doesn’t seem to have its reason there and my 4G has a 5200 mAh battery (at least according to its label and ACPI). I also ordered a 2 GB bar of Corsair ValueSelect RAM so that I can pump up the RAM of my EeePC by factor four (for about 10% of the price of the EeePC itself) resulting in having half as much RAM as disk space. Well, I guess, I won’t do suspend to disk in that configuration… ;-) The original Xandros based Linux only noticed 1 GB of the installed 2 GB as already noted on many other places in the web. But that doesn’t really matter, since it only lasted until I found out how to restore it from DVD in case I want to sell the EeePC later (e.g. for getting the successor). It’s fine for novices, but Linuxes feel strange if you can’t even get a console or a terminal with a command line. ;-) The Debian EeePC installer worked fine except that it argued over a checksum error on our mirror which wasn’t reproducable after the installation anymore. I’ve chosen the EeePC to be my first (nearly) pure Lenny installation — compared to the three machines running Sid (i386, amd64 and kfreebsd-i386). It though has a few packages from experimental (mostly xulrunner-1.9) installed. As window managers I have installed ratpoison, FLWM and FVWM. ratpoison — best described as screen for X (although you can’t detach and reattach) since it’s my personal preferences for being productive without big screen resolutions and flwm for a low-resource window manager which can be used intuitivly by both, geeks and non-geeks (and still doesn’t look like Windows at all ;-). And FVWM is installed because it’s my default window manager on all machines with bigger or multiple screens – to be able to compare it with my usual environment. As web browser I’ve got Opera as primary browser (as everywhere else, too) and Conkeror (the EeePC is the test-case for upcoming Debian package of Conkeror) as well as links2 and lynx on the (nearly) text-only side on it, although I need them seldomly. As office programs (as I would ever need some ;-) I’ve got AbiWord and Gnumeric installed since I already use a few GNOME applications (e.g. Network Manager, Twitux, etc.) and OpenOffice.org would take up 170 MB more disk space (then including OOo Draw and OOo Impress) and Siag Office is no more in Debian since years. (Initially I had OpenOffice.org installed instead of AbiWord and Gnumeric until I noticed that I need some of the GNOME libraries anyway.) I also decided that I will need LaTeX then and when so TeX Live also got its chunk of the 4 GB of disk space. I also have a bunch of games on the EeePC. Unfortunately there are a few games which don’t work well on the EeePC due to it’s resolution being smaller than 800x600, so I deinstalled them already again, e.g. I can’t play Cuyo on the EeePC but flobopuyo. Sauerbraten segfaults, but Doom (prboom with freedoom WADs) works fine. Further non-working games unfortunately include Battle of Wesnoth and XFrisk. Still, although quite some parts of GNOME and GNOME Office, TeX Live, ScummVM with Flight of the Amazon Queen and Beneath a Steel Sky, GNU Emacs 22, Iceweasel 3 (aka Mozilla Firefox 3), Icedove (aka Mozilla Thunderbird) and the Iceowl (aka Mozilla Sunbird) are installed, only 2.3 GB of the available hard disk space are used by the installation (i.e. without my home directory). Oh, and btw: Although except the very compact and a little bit wobbly keyboard the EeePC doesn’t feel really small to me (I’ve got quite small hands), but when I sat down in front of my 14” ThinkPad T61 after a day or two with EeePC, the T61, — especially screen and keyboard — felt huge as if it would be some 17” or even bigger notebook. ;-) OTOH I still think that a 1920×1200 (which means nearly four xterms in a row) resolution on a 14” notebook would be a good idea, especially compared to the 1440×900 (which means nearly three xterms in a row) my T61 has. ;-) Personal Resumée after one month Pro EeePC

• It’s geeky. If you show up with it, people want to lift it to see how much it weights and try the tiny keyboard. They’re surprised that 800x480 aren’t that small and that the performance isn’t that bad.
• Very compact and robust. With the T61 I always fear that its edges are too close to the the outside of my backpack and could be damaged that way.
• The price of course: CHF 499 at digitec (plus CHF 54 for the 2 GB RAM)
• Runs Linux ex factory. So yu don’t have to expect that many driver hassles.
• RAM upgrades are very straight forward and do not void the warranty. (BTW: The sticker over one of the screws which probably should prove the integrity can be removed and placed again easily… :-)
• The weight. 0.92 kg can be easily held wit one hand, also because of less leverage effect as with full-size laptops.
• The SSD despite it’s size. Being such lightweight you accelerate the EeePC unmindfully even when it runs. But it doesn’t matter, at least not to the hard disk. And it boots very fast, especially after the usage of insserv.
• Intergrated Ethernet network interface. (Hey, the MacBook Air hasn’t a builtin one, not even an external shipped with it! ;-)
• Three USB sockets (the MacBook Air has only one which is usually taken for the Ethernet network adaptor — Ok, with the EeePC usually one is taken for the Bluetooth dongle, but then are still two sockets left… ;-)
• Great contrast on the builtin screen.
• External VGA output. You have to configure X.org to make the virtual screen big enough (e.g. 2048×2048 instead of the default 800×800).
• Despite its size quite a lot of space for modifications inside the case. Especially a bluetooth case mode should be no big deal.

Contra EeePC

• The keyboard: keys smaller than usually (ok, wouldn’t work otherwise ;-), very wobbly, no precise contact depth (pressing Shift and Fn with one finger often doesn’t press Fn right), not all keys on the same plane, unusual offsets between the key rows (the number row has about half a key width offset to the left) or position of keys (I often hit Ins when I want Home, Del when I want Backspace or Fn when I want Ctrl, the ~ key is between Esc and F1, Up is between Slash and Right Shift, etc.)
• The position of the power button: It’s exactly where I want to put thumb when holding the EeePC solely with the right hand. And yes, I already accidentially switch it off several times because of that. For luck the button doesn’t work at all when the lid is closed, because you still can reach it easily while it’s closed.
• The mouse button(s): It only has two buttons which are one part you can press more to the left and more to the right side. And if you press it in the middle you randomly get either a left or a right click. You have to press it very hard to get both clicks at the same time. (e.g. to emulate a third middle button). Three separated mouse buttons would have been way better.
• It has (only) a touchpad. I definitely prefer thumbsticks as the ThinkPads have, but got used to it, though. I have seen worse touchpads, too.
• The noisy and not very precisely beared fan, which seems to strife its environment when the EeePC is being accelerated. Whih happens quite often because of its size and weight and because the SSD doesn’t mind acceleration. The fan does mind – and you hear it. :-(
• Some programs need minimum 800x600 resolution to work well.

Pro ThinkPad (in direct comparision)

• Thumbstick.
• One of the best laptop keyboards around.
• Three easy to distinguish mouse buttons.
• Even ressource-hungry programs like Liferea work fine.
• Quite big screen resolution (1440×900).
• Bigger battery, space for additional batteries.
• Could be a workstation replacement.

Pro Lenny on the EeePC

• The installer image of the Debian EeePC Project works out of the box. All necessary drivers are available, if you include the non-free repositories and the eeepc.debian.net repositories.
• Stable enough for daily use. (IMHO Debian Testing – and even Debian Unstable – is more stable as many other distribution’s stable releases, e.g. those from SuSE.)

Con Lenny on the EeePC

• My favourite feed reader Liferea has changed its cache format since the version in Debian Etch, so I can’t sync Liferea caches between my Debian Etch running T61 and the Testing running EeePC. Well, fortunately the version of Liferea in Debian Etch still works on Debian Lenny, so I just downgraded the package to the version from Etch and set it on hold. I don’t use it on the EeePC though since it needs way too long to start (about 10 to 15 minutes compared to 1 to 3 minutes on the T61)

Summary I’m very happy with the EeePC and I didn’t expect that it would replace my 14” ThinkPad in so many (but still not all) situations. :-)

I lent someone my old Palm IIIe as a data entry device for an exhibition this week. I don't use it much since I got a Samsung K608i last year. They weren't comfortable with using their smart phone as a data entry device. I can understand that: I'm still pretty slow at phone-typing and it corrupted data when its memory filled recently. The batteries had been removed from the Palm to avoid them leaking, so it needed reloading with useful Palm free software for data entry. The first problem was that I decommissioned bouncing a while ago and that was the last machine to sync with the Palm. I wasn't keen to pull it out of the store cupboard and connect all the wires, but my current desktop machine nail doesn't have a 9-pin serial port for the cradle and that's the only connector on the Palm. Actually, it's not the only connector: the Palm has an InfraRed emitter and I have a Belkin F5U230 USB-IrDA dongle thing. I don't use it that often, but it worked enough to connect nail to the internet through my old mobile phone. That was a while ago and I forgot the specifics, but eventually I noticed the key phrase in the irattach man page:-

"Note that there is another USB driver for those devices called ir-usb which is NOT compatible with the IrDA stack and conflicts with irda-usb. Because it always loads first, you have to remove ir-usb completely."

Sure enough, I checked the lsmod output and found ir-usb there, screwing stuff up. A few modprobe -r commands, then I simply ran

"irattach irda-usb"

and saw the irda0 network device appear. Still one thing to do: beam the actual applications. This was pretty easy because I remembered reading that obexftp defaulted to IRDA sending when I was getting bluetooth working. All I had to do was enter a command like

"obexftp --irda --put db.prc"

and the Palm asked if I wanted to accept it! Yes! First test with obexftpd for receiving files wasn't encouraging, though and I can't see how to use sobexsrv for this: I'll probably write next week whether we get any data off the Palm! The Palm IIIe is too old to hotsync over infra-red, as far as I can tell. I've got a roundabout route through the K608i but it doesn't seem to be very reliable. Anyone got any expert tips?

England swings like a pendulum do! There's another fuel price protest and the coverage in the London press is pretty biased, with occasional balanced reports and very rare dissenting opinion. One of the favourite whines on news-and-nutters phone-ins is "waah, I live in a village, I need my car". While that's true for some people, most villagers could switch to bicycles for many journeys without problems. At the moment, the biggest problem with cycling to town is the number of cars on the small lanes, followed by the number of potholes. Switching to cycling or walking will have a triple benefit: fewer cars on the road will free up space for cycling, wear the roads out less and reduce fuel demand (so petrol should become cheaper for those who really need it). Over the last few days, I've been happy to read Bike The Drive 2008 [Dirk Eddelbuettel], Mountainbike, By Joerg Jaspert and How to Start Bicycling to Work, by John Goerzen. A couple of tweaks to that last one: in England, I don't think that a cycling helmet is necessary. I've not worn one for the last few months (it went mouldy after a rain storm) - I find I can hear traffic better and many drivers seem to give me more room on the road. I wonder if helmet-wearing "dehumanises" cyclists to drivers? The safety data seems rather confused, but it's a personal choice. If you feel safer with a helmet, wear one. I also wear ordinary business or casual clothes, relying on a good quality commuter saddle rather than cycling shorts. I suspect that drivers here are developing a sort of blindness to the "screaming yellow" hi-vis jackets, so I don't wear those - but sometimes I wear hi-vis reflective armbands if I'm wearing black in the dark. I agree completely with the comments on that page about being predictable, Cateye lights and pannier bags. Finally, Bike Week 2008 starts on 14 June, which would be an ideal time to try a group ride - or just get a free breakfast for cycling into town.

To continue the CECB mini-review series, I picked up an LG/Zenith DTT900 at Circuit City in Southaven this evening with one of my two digital converter box coupons (and $24ish of my hard-earned money at Sam’s Town’s blackjack tables). With essentially the same setup and conditions (same television and el-cheapo VHF/UHF indoor antenna) as the RCA DTA800B tested before, the initial channel scan found the same 17 channels/sub-channels. However, the Zenith’s ability to manually add channels meant that I was able to add WMC-DT/NBC 5 (RF channel 52) and with some fiddling get a reasonably stable signal, something I was unable to accomplish with the RCA—this isn’t that surprising, since the Zenith is based on LG’s ATSC digital tuner chipset, which is known for its superior reception capabilities over most other silicon. In addition, other channels (WHBQ-DT/Fox 13, WPTY-DT/ABC 24, and WLMT-DT/CW 30) that were less-than-stable with the RCA were rock-solid with the Zenith. Bear in mind that WMC is running on a different frequency (and lower on its tower) than it will after the transition is complete in nine months, so indoor antennas in Shelby County at least should cope better with WMC when it is back on VHF channel 5. The built-in guide is a little weaker than that included on the RCA model; the Zenith’s only shows program data for one channel at a time. The Zenith, however, has more functionality accessible from the remote control, including a “favorite channels” feature that would be useful for the compulsive surfer who isn’t interested in switching past the news and weather loops on 3–2 and 5–3 when doing the Letterman/Leno (or Conan/Craig) shuffle, and a sleep button. I also thought the Zenith’s menus were a little more polished and better organized. On the antenna front, the Zenith, unlike the RCA, does not provide an attachment for digitally-steered “SmartAntennas,” which may be a consideration if you already have one of these (they are apparently uncommon at present) or have hard-to-tune channels in multiple directions which might benefit from this high-tech solution. The Zenith’s better signal-handling may reduce the need for a fancy antenna, however; either way, you should probably check out TVFool’s antenna aiming guide or the somewhat less-friendly CEA/NAB-sponsored AntennaWeb website to determine what sort of antenna solution is going to be necessary for you before spending money on one. The only real problem I encountered in testing was that the “zoom” setting seemed to behave oddly; at first, letting it decide on its own seemed to work OK on some channels, but then I ended up with some bizarre “squeezed” pictures on several HD channels. Expect to manually fiddle with the zoom setting when channels switch between showing native 16:9 and pillarboxed 4:3 programs. Those who use closed captioning will also find that it seems to forget the CC setting when you switch channels, although I think there’s a menu option to leave closed captioning on all the time. Finally, caveat emptor: many manufacturing runs of this converter, and its near twin sold by Best Buy under its Insignia house brand, apparently have an audio problem that certain TVs seem to be more susceptible to than others. The converter I purchased had a manufacturing date of April 2008, which has been reported to be the run in which this problem was fixed, and I observed no audio problems during my testing (on an admittedly low-end CRT stereo television/VCR over RCA cables). Overall, I’d assess the LG/Zenith DTT900 as a better option for those who are planning to use the converter on a regular basis; however, if you’re simply buying a converter to serve as a “lifeline” when cable or satellite television is disrupted, or if you would like to take advantage of the SmartAntenna connectivity on that unit, the RCA model is probably adequate for most needs and seems to retail for about $10 less.

We hear a lot these days about the price of gas, energy efficiency, and the like. But, in the United States, outside of a few progressive cities, there aren't a lot of people that are using the ultimate zero-emissions transportation technology: bicycles.

That's really too bad, because bicycles are a lot cheaper to operate than cars even before you consider gas prices. They also are great exercise and are probably faster, safer, and more convenient than you think.

I live about 10 miles (16 km) from work, which includes several miles on sand roads. I haven't bicycled in about 6 years. Last week, I got my bicycle out, touched it up a bit, and started riding. Sunday I rode in to work and back as a test. As soon as I get a bit of gear (hopefully by the middle of next week), I plan to start riding bike to work at least 3 days a week.

I've picked up some tips along the way. Let's talk about a few of them.

Safety

Many people think bicycling is dangerous. In fact, bicycling is about as safe as driving an SUV. Not only that, but only 10% of bicycling accidents occur when you are hit from behind (and 90% of those produce only minor injuries). It turns out that the vast majority of bicycling accidents occur because people are not riding on the road with traffic, or are acting unpredictably. Following some basic safety advice can make you safer in a bicycle than an SUV. Oh, and don't drink and ride; 24% of fatal bicycle accidents involve an intoxicated rider.

Distance

Think it's too far? Think again. It's fairly easy for an untrained, unfit person to ride a bicycle up to 10 miles without working hard at it. That can probably be done in about an hour. As you get more fit and used to the bike, you may be able to go that distance in half that time. Also, get pannier bags for your bicycle. They attach in back and let you carry work clothes, laptops, etc. without having to use a backpack.

Smell

Many people with office jobs are concerned about this. Not everywhere has a convenient shower. Check out these tips from the Tips and Tricks for Biking to Work manual.

I'm excited about it, and will be sure to post more here on how it goes.

Mom and I went to Wal-Mart today to pick up two digital converter boxes (specificlly coupon-eligible converter boxes, “CECBs”) as emergency backup for Comcast’s frequently-incompetent cable service in Memphis. It took about 15 minutes for the assorted checkout staff figured out how to ring up the converters and use the government coupons for them, but eventually we escaped with two RCA DTA800B converters. I found the box relatively easy to use and hook up. The boxes included quick start guides in English and Spanish and full user manuals in both languages, as well as a programmable remote control (with batteries) and a short push-on coax (F-type) cable for attaching the box to a TV over the “antenna” TV input. Both boxes worked moderately well in southeast Memphis with a rather lame RCA unpowered indoor VHF/UHF antenna I picked up a while back, which is no Silver Sensor but a bit more compact to haul around, less likely to attract quizzical stares from airport security, and better than nothing at all. Neither box was able to scan WMC‘s rather weak digital signal (authorized at 394 kW but clearly not transmitting at anything close to that power) and there’s no manual tuning option. I’d imagine if I’d brought a decent directional antenna like the Silver Sensor I’d have gotten WMC and a more stable signal on some of the other channels. So, overall, I have no real complaints about the boxes themselves, except for the lack of a manual tuning feature available on other converters, and the SmartAntenna feature will be nice for folks with hard-to-tune channels in multiple directions when you can actually buy one again. I’ll probably examine some of the other CECB models before settling on one, however, particularly now that it appears that the reported Zenith DTT900 audio problem is fixed in newer boxes.

One of the things I do when I’m at home is translating debconf templates into Galician. I’m not doing bad at all. Although it’s just me working alone (by choice), mine is the 10th most complete translation, and climbing :) I’m going to document my workflow, for two reasons: one is that others may find it useful or may suggest improvements. The other is that, in this way, I won’t depend on my bash history not being erased :) I have a compendium with almost all strings in all debconf templates I translated, and several scripts I use to maintain that compendium, apply it to translations, etc. It is available at http://darcs.tarrio.org/gl-templates/, and can be downloaded with Darcs using this command:

$ darcs get http://darcs.tarrio.org/gl-templates/

In my local machine I keep it in $HOME/pos. (You may use this compendium and scripts freely, if you want, but be sure to change all appearances of “gl.po” into the appropriate file name for your language.) Nowadays I’m mostly driven by bubulle’s NMU announcements. Whenever he announces a NMU for a package I haven’t translated or whose Galician translation is outdated, I work on it. This is what I do to start a new translation for a package called “example":

1. Extract the attached templates.pot file into $HOME/pos/example_templates.pot.
2. Bootstrap the translation with my compendium, using this command:

   $ ./bootstrap-po example_templates.pot > gl.po

   The script is smart enough to know that a file called example_templates.pot is a templates file for a package called example. However, I can specify a different package name as its second argument:

   $ ./bootstrap-po nonsensicalfilename.pot example > gl.po

3. The generated gl.po file is UTF-8 encoded. However, I use xemacs to translate, which cannot read that, so I encode it into iso-8859-1:

   $ msgconv -t iso-8859-1 gl.po -o gll.po

4. Edit the file.
5. Encode the edited file into utf-8:

   $ msgconv -t utf-8 gll.po -o gl.po

6. Add the translations to my compendium:

   $ ./add-total-po

   (My compendium is the total.po.txt file, hence the name.)
7. Optional: edit the compendium to remove obsolete strings or strings which may be ambiguous so I don’t want them in the compendium.
8. Send the translated file to the package maintainer using the BTS:

   $ ./send-po example

9. Record and push the changes to the compendium:

   $ darcs record -a
   $ darcs push -a

This is how I update an existing, outdated translation:

1. Extract the file into $HOME/pos/gl.po.
2. Most likely, it’s UTF-8 encoded. Encode it into iso-8859-1:

   $ msgconv -t iso-8859-1 gl.po -o gll.po

3. Edit the file, fix only the fuzzy translations.
4. Encode it back into UTF-8:

   $ msgconv -t utf-8 gll.po -o gl.po

5. Update the translation using the existing translated strings and the compendium:

   $ ./refresh-po gl.po   msgconv -t iso-8859-1 -o gll.po

6. Open the file. Hopefully you’ll have new fuzzy translations. Edit the translation and complete it, or do some strings then refresh again and edit and refresh again until the file is completed. If the file contains lots of similar sentences you can just translate a couple of them, refresh, and the other ones will then be all fuzzy. Magic!
7. When I’m done, encode into UTF-8, update the compendium, send to maintainer, submit changes to compendium.

(tl;dr: if you have a few minutes, please add information here) Joss, the problem with the new package formats is that there is nothing that actually uses the additional information in a way that adds significant new functionality, so the net result of the change was that we throw away the information at a different layer in our software stack, and one of the interfaces got a lot more complicated in the process. One possible application would be a "poor man's patch tracking" inside the BTS, perhaps with a new state "fixed in patch". I can see two ways of implementing that:

1. by extending the interface of the "new" package formats that Debian,Ubuntu bug numbers are attached to the actual patch files and having the archive maintenance software extract and process that information (reject packages that add a patch for a bug without closing it in the changelog, notify the BTS), or
2. by leaving the package format untouched and simply adding a regex matching "Fixes: #nnnnnn" that is reported to the BTS as "we have added a patch", so the submitter is notified that the bug is gone for him/her; the bug is then closed in the changelog of the upload removing the patch.

The former approach also allows us to link to patches from BTS pages, which the latter doesn't, so there could be actual benefit here if we believe it is worth the additional complexity. (Update: Rapha l thinks it is. I like the idea of a package format with separate patches a lot more in this context than I did without it, but still my fear that it will actually be perceived as sanctioning large patchsets still remains.) About mandatory co-maintenance: the problem isn't "helping". We have plenty of people with commit access to packages they don't even remotely understand who are really helpful (not). The problem is that someone needs to actually read all the commit logs and understand what the changes do in this context. In most cases, that person or group would be upstream, not a DD. My first impression after reading the patch was "adding uninitialized data to the entropy pool is pointless/harmful as it is not random, so this patch makes sense", because the loop around it was not contained in the patch. Obviously I'm not an OpenSSL developer. There is nothing Debian could have done internally to verify the correctness of this patch that would properly scale to the entire archive, even if we put "more emphasis on security". The only solution I see is reporting every patch to upstream immediately and getting affirmation that it is correct. This, however means that we need to produce patches that upstream can accept. For obvious code bugs, that is simple, but for integration patches like paths it is not sufficient to replace one string with another, but rather make it configurable in some place that can be reached from debian/rules. In an ideal world, we end up with very few Debian specific patches, so essentially we are talking about adding functionality to dpkg that we don't want to use. I've started a page in the Debian Wiki, Getting Packaged with an outline of a possible document aimed at upstream developers that should list the typical problems we run into and how to avoid them.

There is an article on TechCrunch on Windows on the OLPC. This article started out as a comment below lots of comments that were missing the point, but eventually grew too large. The entire discussion circles around the question whether it would be beneficial to give the users the same view and behaviour that is on 90% of machines worldwide, so they can start out prospective jobs with a minimum of training. Learning your way around the UI is only a significant part of training if that actual work you will do is trivial — so this argument basically boils down to "I don't expect the African kids to do anything but grunt work during their lifetime anyway, so we better start training them early", which is the wrong approach not only to education. To make a bad car analogy, roads are usually made of several layers, from the foundation providing the stability up to the paint defining lanes. Operating systems are similarly layered, with a core that applications (cars) never touch directly, and several other layers on top of that that are not really required for basic functionality, but that add safety (process separation) or comfort (standard functions). The minimum standard of things is a "platform definition", which all car (or application) makers can expect — all roads have a minimum width and there are no dangerous spikes (if that is not true, you can get a steamroller or respectively format your harddisk). Railways use the same kind of foundation (operating system), but the platform (heh) is quite different. You cannot drive a car on a railway, or a train on a road, just as you cannot run a Windows application on a Linux system or vice versa (there are special wagons you can place your car on, and special trucks with rails on them if you feel like it, but these are heavier and need more energy to pull). Now in this discussion, people have been comparing Windows (the platform) to Linux (the operating system). That doesn't work. On Linux, there are several platforms available, the most prominent being GNOME and KDE for the desktop and POSIX utilities on the command line, but there are lots of others as well. Part of most platform definitions is an user interface, which abstracts what is really happening to something comprehensible to the user, using analogies (a tachometer displays our speed as an angle usually, but other representations are possible). The "desktop" idiom happened to be the first graphical UI some thirty years back, and was perpetuated into today's computers (just like the width of roads hasn't changed from the days of the Roman empire, where it was "two horses and then some"), however this doesn't mean it is the best choice available — it's just what we are used to. If you look at the screen contents on the day traders' computers (lots of that on the TV right now thanks to the market crisis), you will notice the vast majority does not use overlapping windows or standardized "rising-edge" buttons to click on, but rather, they have a tightly-packed grid layout with high-contrast information displays that also color-code certain messages. I think that is the most important point here: to achieve optimal results, the presentation idiom needs to be chosen in a task specific way. With children as the target audience, we lose one of the key requirements behind the adoption of the windowed view: the need for side-by-side presentation of data from multiple unrelated sources (which is also a problem given the lack of screen space). With the introduction of ad-hoc mesh networking and collaborative applications, the "desktop" analogy begins to break down. The project's mission also defines requirements on the platform. If we want to keep the requirement "users should be able to build and share their own stuff", then we want a framework where it is hard to make mistakes, especially those that can be spotted only after an interesting failure, and more importantly impossible to write code that makes unrelated components fail, because these components might be your way back out of the situation. Windows has an excellent event model with fairly good isolation of components (to the point where a problem in an event handler can be handled by the event loop rather than terminating the program, so for example Internet Explorer can shut down broken plugins rather than crashing), but the detail knowledge required to really work with the API (how to build a message loop that also runs queued I/O completion handlers correctly) leads to a fairly steep learning curve, and would teach implementation details rather than concepts. The normal "linuxy" approach of going low level whenever higher-level approaches fail is not the answer either as we want to truly empower people rather than just training them to be a cheap replacement for the tech support Indians (no offence), so it is vital that the "real" applications use the same framework that people implementing new things would use, and thus all the complexity that we want in our "official" applications needs to be taken care of by the platform, with all the safety features in place too. So no existing platform provides what we want. — hence Sugar. And that is the problem for Windows advocates: Sugar replaces those bits that make Windows a platform and not just a kernel, so porting Sugar to Windows doesn't make sense from a technical point of view, since we already replaced the bits that we didn't have free software for before. Other than that, the "Linux vs. Windows" kernel choice is secondary; in fact both kernels are very similar in design and function, the various advantages and disadvantages of either aren't that relevant really. The only technical reason in favour of Linux is the virtual memory management — the Windows VMM behaves erratically in the absence of a swap device, but I believe that is not something that cannot be fixed. The reason why I believe Linux is the better choice here is long-term support. Since these devices will be used in basic education (which hasn't changed that much in the past years as 1 plus 1 still equals 2), there is hardly any need for radical changes after the initial rollout — why add instability when you don't have to? With Microsoft as a for-profit company, there needs to be a business model sustaining that behind it, and I believe it will be very hard to find one. "Subscription" falls down in that it is a long-term recurring expense, which governments tend to be pretty wary of. The alternative is to upgrade several million computers' OS every few years. Lots of companies are skipping entire Windows releases because of the migration cost, and even with the "console bonus" (all hardware is the same) and bootloader support for software upgrades over a mesh network, this is still a massive endeavour. That each machine would have to reserve enough memory for the entire "upgrade pack" so it can transition "in one go" also makes this model unworkable. To summarize, using Windows on the OLPC does not make sense at all. If you use just the kernel, you don't gain anything over Linux, and if you use the entire platform (and by extension, the UI), you add unnecessary complexity that is not only not required for the actual task, but also distracting. If you add restrictions and extensions to make it work, you invent a new platform, which is precisely what Sugar did. The argument that it is important for pupils to use the same thing that the rest of the world is using to ease their entry into the workforce is bogus at best, and racist at worst.

"Here are three examples of rules that I think it's time to abandon. These particular examples are all about email. 1/ Top Posting [...] 2/ HTML Email [...] 3/ Reply-To On Mailing Lists [...] So, yes, the barbarians are at the gate. The lunatics have taken over the asylum. Good ideas have been crushed by the number of people who don't understand them. But there's no point in complaining about it. You just have to accept it and move on."

-- Pointless Battles For Geeks, By Dave Cross Unsurprisingly, given the above links to my site, I disagree with Dave Cross's conclusion, but I do agree with two aspects: battling is generally pointless and using hard rules about these things is unnecessary. I have those pages on my website so that I can point to them when their broken emails aren't handled as expected. I use some aspects of them as scoring inputs in my mail filters. I don't use them as rules and I try not to complain about them too often. Nevertheless, I still believe sending properly-trimmed plain text emails from a list-friendly email client is clearly best practice, to be recommended when someone asks why their email bad habits are causing them problems.

For a project I was looking for a way to use GNU Mailman for mailinglist management (especially its powerful web based moderation, bounce handling and attachment scrubbing features) but storing the mailinglist member information in a SQL database. That's useful when you want to relate mailinglist members to extra information already in a database and functionality on an interactive website, and it's possible on a per-mailinglist basis. This turned out to be not very difficult but just not that clearly documented. What I used:

• Mailman. I used the 2.1.x version packaged in Debian etch: an "open" system is just one apt-get away!
• The MySQL Member Adaptor available from rezo.net. There are several versions of MySQLMemberAdaptor around the web, but this one seems the most recent.

This explanation assumes you know how to work with Mailman in a regular setup, and things like creating databases and users under MySQL. Take the following steps:

1. Install and set up mailman as you would otherwise.
2. Put the MysqlMemberships.py file into the dir that is Mailman's base, this normally already has files like MemberAdaptor.py in it. For Debian this is /usr/lib/mailman/Mailman. You only need to add MysqlMemberships.py, the other files from rezo.net are not needed.
3. The create table query in MysqlMemberships.py does not work with MySQL 5, I had to apply this patch which I've sent to MySQLMembership's author in the meantime. This patch has been applied by Fil.
4. Create a database and a MySQL user, and add that information into your mm_cfg.py, like this:

   MYSQL_MEMBER_DB_NAME = "mailman"
   MYSQL_MEMBER_DB_USER = "mailman"
   MYSQL_MEMBER_DB_PASS = "somethingrandom"
   MYSQL_MEMBER_DB_HOST = "localhost"
   MYSQL_MEMBER_TABLE_TYPE = "wide"        # wide means one table per list, flat = one large table

5. Create a mailinglist like your normally would (e.g. via newlist). To enable the MySQL backend for just that list, create a file extend.py under /var/lib/mailman/lists/listname with the following content:

   from Mailman.MysqlMemberships import MysqlMemberships
   def extend(list):
           list._memberadaptor = MysqlMemberships(list)
   

   (whitespace is significant in Python).
6. It should work now! Upon receiving the first request for your list, the database table will be created automatically, which you can then populate. You may need to restart the mailman qrunner after you make further changes to your setup.

Anyone seen this before? Today, I went to an event about the Sub-National Review Consultation (as a substitute for someone else AIUI). I'd not heard about this before, but if you're in England and you've any interest in our regional planning system (which I think you should, if you have your main home here or run a business here), you have six weeks left to comment on the UK Government's suggested changes. As I understand it, it will move the second-highest tier of planning control from democratically-accountable regional bodies to the business-led Regional Development Agencies, with some oversight by MPs and the very- indirectly-accountable council leaders. I've posted more detail on Co-opNet. When I asked about local involvement and cooperatives, I was directed towards Local Strategic Partnerships, but I'm pessimistic about how easy it will be to influence regional planning through those: a few weeks ago, I was at the launch of the North Somerset Partnership Sustainable Community Strategy for 2008-2026. It's a 72-page A4 glossy book which I've still not found time to read properly. I think the size says something about its sustainability. I've posted a little more detail on WsMForum. I'll try to answer questions about either of them on this blog or those forums...

Last weekend, Sarah and I went to the Maker Faire again. I love how I don't even have to negotiate with Sarah to go, she loves it just for watching the Combot Cup, where the combat robots destroy each other spectacularly. Ever since Jon Oxer gave his Hardware/Software Hacking: Joining the Real and the Virtualtalk at Google about, I got vaguely interested in electronics again. The Arduino board seemed like a pretty cool thing to hack on, and since it seemed like I'd need to get vaguely electronically savvy to do a thing or two for the dream home we want to build one day (which coincidentally seems to quite similar to what Jon's currently building), I figured I'd have to get my act together and learn the difference between an Ohm and an Amp. The last time I dabbled in electronics was as a kit, with the ubiquitous Dick Smith Funway 1 kit. So the Maker Store at the Faire had copies of Making Things Talk, bundled with an Arduino starter kit, so I lashed out on one of them, a BoArduino, and a little breadboard-based electronics kit. I've been flicking through the Making Things Talk book, and reading the projects. The Arduino board seems really cool. The Processing/Wiring language seems fairly straightforward. I'd decided that my "project" would be a water monitor for the cat water bowl. We have a dish with a little tank on it, not unlike the office water cooler, and it usually lasts about 7 days. We typically refill it on a Saturday as part of the weekend chores. Sometimes our schedule gets a bit disrupted (we go away, we have visitors) and we forget. Or worse, we're away, have a house sitter, and they completely forget to check it. It's only happened a couple of times, but we really don't want to neglect the cats. So I thought a water sensor would be a perfect project. One of the projects in the book involves a Bluetooth modem, so I figured that as the MythTV box has a Bluetooth adapter, and would be within range of the water bowl, I could use it to monitor the water sensor (as well as stick a blinking light on it). The end goal is to have the house call us (via Asterisk and eSpeak) if the water bowl gets empty. So I ordered a Bluetooth modem, the exact part number in the book, and it arrived on the weekend, and I got around to playing with it today. To cut a long story short, I was messing around with it attached to a USB to TTL serial cable, and I was trying to get it to talk to my laptop, and instead of swapping the TX and RX lines, I swapped the V_CC and ground lines, and well, I let the magic blue smoke out. What I discovered, after the fact, was that the Bluetooth chipset had been changed since the book had been written, and so the commands for the chipset were different. So most of my second-guessing whether I had the TX and RX round right way was because of that. So I'm miffed with myself for frying the thing within hours of getting my hands on it, and I'm miffed with the supplier for maintaining the same product ID for a product that has changed componentry. Chalk that one up to experience... To add insult to injury, Spark Fun is out of stock of the (cheaper) item that it turns out I want instead. I doubt I'll get my hands on it until after we get back from Zurich, so it'll be another three weeks before I can begin to make any progress. I guess I can try to prototype the water-sensing part with the board connected to my laptop with the USB cable in the meantime...

Following Martin's post on the subject, since I created my prompt, I've updated quite a lot. It only showed the branch before, now it does so even when I'm on a detached head or something, and also shows when I'm in the middle of a rebase or a merge. You can see the zsh-fu for this. For example, when I'm in the middle of a rebase on my paid work repository, it looks like:

 (10:34) <~/dev/mmsx master <rebase -i>> 
 [artemis]                                                 (~/dev/mmsx/Build/)

With nice colors I cannot really show without a screenshot that I'm too lazy to do :) This is a recent addition that I shamelessly took from the contrib bash prompt in git-core package. And to be frank it's really needed, because it's cheap tests (basically looking for magic file names) and that it can tell you if you forgot to end a rebase or a merge, which can happen if you have been disturbed in the middle of it by a colleague for example. I liked the '*' idea from Martin to show if the tree is dirty. Sadly it's not an option. Martin, to do that, you can do:

 unclean=
 git diff-files --quiet && git diff-index --cached --quiet HEAD --   unclean='*'

But this is a very expensive operation. On the glibc git repository, it takes seconds with cold cache (and it's not very surprising because it basically has to stat(3) a lot of stuff). And not having a shell for seconds is a bit extreme. PS: I know my prompt only supports git, but:

1. I barely care about other VCSes as I only use git and sometimes svn for packaging ;
2. when I have to use svn it's for cheap stuff where I don't really need the prompt help.

When you're 5, you're living with your parents. If not, you're probably in an orphanage, waiting for adoptive parents. When you're 10, you're living with your parents. If you're not, something is very wrong. When you're 15, you're living with your parents—although you'd probably rather live elsewhere. When you're 20, you're most likely still living with your parents; but if you don't, that's nothing to be ashamed of. When you're 25, you've either moved out, are doing so, or are thinking about it. When you're 30 and you still live with your parents, you're pathetic. At least that's the way I look at it. As of today, I'm officially pathetic. Won't be for long, though—it's just taking slightly longer than initially expected to make the appartment habitable. Stuff left to do:

• Attach some plaster to one wall, closing the holes in it
• Paint that wall, and one other which had to be treated for water damage first
• Finish up the kitchen: attach doors, connect electricity, glue everything together, attach baseboards
• Close water pipe shafts again
• Actually move in

Except for the "connect electricity" bit and the final step, that should all be doable in about a day, if I hurry. It's about time.

After a fair amount of clean-up, a lot of waiting for review, and some ruthless pruning, I and my colleagues at Solarflare finally got our net driver accepted for Linux 2.6.26. Meanwhile a larger version of the driver made it into Xen's Linux tree, along with dependent drivers to provide a secure fast path to the hardware from domU. Somewhere down the road we're going to have to resolve these two versions, but now I'm just pleased to have a working driver in-tree. There are some other changes I've worked on over the past few months:

• I maintain diagnostic scripts for our NICs and drivers. Among other things they include Vital Product Data (VPD). There's a standard way to read VPD in PCI (actually there are two, in different versions of the spec) but in Linux this is only accessible to root, and even then there are race conditions. We provide an MTD driver for flash and/or EEPROM attached to the NIC, and I know where the VPD appears in there, but most users won't be loading that driver. So I wrote this: Expose PCI VPD through sysfs
• Along the way I found a bug in sysfs, which I fixed: Disallow truncation of files in sysfs
• One day I accidentally bridged one of our network interfaces, which has Large Receive Offload (LRO) enabled by default, with one of the motherboard's network interfaces, and the results were not pretty. LRO isn't really compatible with packet forwarding, and currently causes the GSO code to crash or warn. I wanted to solve this by disabling forwarding of LRO skbs, but it turns out to be trickier than I thought.
• We wanted to use topology information to allocate one IRQ per CPU package, not per core (or per thread, with HT enabled) for Receive-Side Scaling. Unfortunately this information is only available in some kernel configurations and not for all architectures. I had a go at providing reasonable defaults, but it didn't work too well!

However, this is still only part of my work. My main task at the moment is to write more unit tests for our next NIC.