Over the last few months I've been hacking on (yet another) image viewer for GTK+, using the hot new GVFS library (go Alex!) for asynchronous file handling and GtkImageView because I'm lazy. It's got a pretty lean interface at the moment and is fairly fast in use. My goal is to use it on my Zaurus for reviewing images from a CF card in the field, so performance is quite important to me. As the primary users are photographers, filenames are not shown in the interface (just thumbnails). There is a lot of work left to do, but I've used 0.1 for some time now. The source is being developed in a Bazaar branch at http://burtonini.com/bzr/katachi. I've just tagged a 0.1 release, a tarball of which is here. You'll need to build GVFS from git, and GtkImageView from svn, sorry. :) NP: Closes Volume 1, Boards of Canada

It's our second wedding anniversary on Monday, and because Sarah's not been to Napa Valley yet, and because this is probably the last opportunity to spend a bit of quality time away together before the pitter-patter of little feet, we've lashed out for a nice weekend away. We're staying two nights at the Gaia Napa Valley "hotel". It's really nice, but a lot more like a motel in most respects. I really like the environmentally-conscious initiatives they've taken though. I can highly recommend it, and the day spa attached is also excellent. Oh, and they have free wireless, which whilst surprising given how much they charge for things like in-house movies, is also a bonus. It was good enough to make laptop-based VoIP calls with. Today, we drove around aimlessly after our massages, in search of wine tastings (it was handy having a a ready-made designated driver). It seems the wineries here are all into charging for tastings, which in my opinion is a bit of a deterrent (in some cases) to purchasing. The charge varies between $5 and $15. Some wineries seem to refund the cost of the tasting if you make a purchase (which seems like the way to go in my opinion). We stopped for a late lunch at the Rutherford Grill, where I think I've had the most awesomely delicious rack of barbecue pork ribs I've ever had in this country. I cannot recommend that place enough. Apparently their rotisserie chicken is also to die for. We picked up thirteen bottles of wine in our travels this afternoon, so for the first time in ages, we'll actually have something in the wine rack at home. Tomorrow we're going on the Napa Valley Wine Train, which looks like it'll be fun. So now Sarah can say she's seen Napa.

I'm working at the Palo Alto Coworking Space today for a few hours, since I'm in Palo Alto and since I'm interested in coworking. It's a great, open, airy space with a good WiFi connection and a lot of couches, windows, air and light. Good spot to work. It's also attached to the Socialtext office. Ross Mayfield just announced that they are seeking a new CEO, so I thought it'd be a good idea to throw my hat in the ring while I'm in the neighborhood anyways. Liz Henry caught me on virtual film. tags: socialtext wiki ceo2.0 sign coworking

Daniel Martin commented:

"Often, dustups like these are the result of upstream not caring about one or more of the following: 1) Licenses. Many people will release code with no license attached to it at all, which means (Thanks to the wonders of the Berne convention) that no one else can distribute it. 2) Patent restrictions (the gif patent issue is now dead, but there's still patents on some other graphic formats) 3) Restrictions against selling the software for commercial gain, using the software in the military, in biotech, etc. The netpbm copyright file seems to include instances of each of these. I don't know how it escalated into being unable to build based on upstream."

Thanks for the info. I'm still surprised debian doesn't keep a (maybe big) patchset rather than a fork on this one. I don't remember what put me off it, but maybe imagemagick isn't so bad...

Being a good Debian user

Notes: the bulk of this article was written on the 17th; updates were added in later; this article is really long, you might want to read it in more sessions

Debian's arm port uses hardfloat. This means that apps like rrdtool (graph function) take ages to run because there is no floating point unit. In order to make this faster you'll want to use soft-float emulation. But this support needs to be present in all depended upon libs, including libc, which is an ABI incompatible change which would break all binaries. I can't use the yet-in-development-and-unofficial armel port since the machine has to be up and running almost 24/7 and I can't afford downtime.

So what to do?

Well, obviously use another soft-float enable libc, like uclibc, in parallel withe the hrad-float enabled libc. Debian Sid contains uclibc development libs, but building the whole toolchain is a pain. There is no real support in the distro itself and building on the arm machine is kind of out of the question. I tried a little in a debootstrapped chroot on the native machine, but this was a pain and I was stuck tring to figure out how to disable whitles and bells for rrdtool since I didn't needed any of the perl, tcl or python support. So I stopped, went to bed and decided I'll continue the next day (the day I wrote the biggest part of this article). The future looked dark, trying to build a softfloat uclibc rrdtool on a system that wasn't prepared for that and from which softfloat was pulled away somewhere during etch's development stage....

Deciding to go with the competition - native building

From link to link I found out that gentoo has arm-softfloat-linux-uclibc port, among others, so I decided to use that on the target machine (a NSLU2) in a chroot. Well I stumbled on the low computing power, when I tryed to emerge sync the tree. I gave up un that and tried to use emerge-websync. It looked better, but I didn't got too far with this either since the machine ended up being overloaded, with figures varying from 3 to 8 for the load average (all of them).

Deciding to go with the competition - cross building

It was time to bring in the big guns and I decided I was going to crossbuild those binaries, probably statically since it meant lower risk for things to break on the target machine.


Since I observed that gentoo has a nice tool called crossdev which actually uses emerge (the equivalent of dpkg+apt in Debian world) to make the cross chain tool and saw that they have some really good documentation and a development version of an arm-softfloat-linux-uclibc, I decided I could .

So I went on and downloaded the latest stage3 tarball for x86 (so I can have a gentoo system to start with), made all the necessary things and created a gentoo chroot. I emerge sync-ed, updated portage, installed crossdev (following the nice instructions on the gentoo embedded site about the subject). This took a while, but it went like a breeze. I made the necessary arangements to be able to cross build packages (setting SYSROOT, making that nice xmerge script).

As my goal was to make an arm-softfloat-linux-uclibc binary for rrdtool I tried directly to xmerge rrdtool (of course, first just pretended -p).

Finding bugs in the packages

First bug

All went fine until I found freetype which for some weird reason detected the i486-pc-linux-gnu-gcc compiler as i486-pc-linux-gnu (observe the missing trailing -gcc). I looked over the logs and determined that the CC_BUILD environment variable was not set. So exported CC_BUILD=i486-pc-linux-gnu-gcc and xmerged the library.

(While trying to fix this issue I entered #gentoo-embedded on freenode and actually met Yuri Vasilev, whom I had met in Edinburgh, at DebConf. Look for the video about Ligusk if you are interested about his project to make a Debian like distribution based on Gentoo. It was nice to meet a friendly "face" - as much you can say that online.)


I reported the bug (already there is a patch, I haven't tested, but looks ok) and the workaround in the gentoo bugzilla... after creating an account, since I never used that BTS before.

Second bug

Next pain was libart_lgpl whose upstream, for some comfortability reason chose to detect the target type sizes (and basically ignoring inttypes.h) with a small program which was built with the cross compiler which later was supposed to be ran on the host. I don't think is necessary to say that i failed, of course, since the binary was an ARM binary, while the host was an x86 machine. Yupee! not.

Ok, two bugs, no softfloat rrdtool yet. I reported this second bug and tried to work around the issue. Since I didn't really used too much a gentoo system, I wanted to know details and what possibilities I had. I got some really nice tips from "solar" (aka Ned Ludd) on #gentoo-embedded. He pointed out that while building a package one can press CTRL+z, do some stuff, like altering the Makefile.in file in the build directory and then fg back. Ok, cool.

All I need now is somebody with direct access to an arm machine that can compile and run for me the program in question. seanius on #debian-devel was kind enough to do this for me and, to my surprize, I got the same output header file as I got in the host x86 chroot. But that detail is not important, let's just compile that rrdtool. Well, first libart_lgpl...

Ok, I CTRL+Z-ed the build process just after the configure stage ended, cd-ed into the build directory, I tampered with the Makefile.in file and changed that line from

./gen_art_config > gen_art_config.h

into

cp /gen_art_config.h.arm gen_art_config.h

Haha! In your face! Ok, nasty did was done so I fg-ed and went on confident that I will get my hands on that rrdtool very soon. The package build ended succesfully, without any other suprizes, so I went for the graal!


xmerging rrdtool, the bugs don't stop

xmerge -v rrdtool

Bla, bla, bla.... bla, bla, bla, what do you know, there are a few IEEE math function tests in the configuration script of rrdtool. They failed. I don't know why, but I have a feeling that this should be happening on softfloat or even maybe the rrdtool source is not that cross compile aware. I didn't care that much, so I did what I knew best, tampering with an ongoing build.

This time is was a little bit harder to catch since I had to wait for the source to unpack (well, there is a larger frame, but that is the rough timing) and at that moment CTRL+Z the build.

I didn't had much time to waste, so after looking shortly over the tests I realized I should just ignore the error and look for the "failing command" that was interrupting my beloved build. Muhahah!

Thank God for verbose error messages, I could find the place fast and chaged the two "exit 1" statements into two harmless 'echo "Ignoring IEEE math errors"', sic. I had to do this a few times since I got the timping wrong, at some point I got the syntax wrong (at which point I remembered the cp trick I did earlier and saved the modified file in /configure.rrdtool )...

xmerging rrdtool and the 4th bug

After passing past this stage, I got a compilation error which, judging from the command, meant that the linker tried to link the target (arm) binary against the host (x86) libraries.

Oooook, this is not going to stop me! I look at the Makefile.in to try understand why this happened and then realized it wasn't worth it for me to try to fix it the right way. So I cheated once again! Muhaha, I just ran some useful commands which I'll let you feast your eyes to:

ln -sf /usr/arm-softfloat-linux-uclibc/usr/lib/libart_lgpl_2.so /usr/lib/
ln -sf /usr/arm-softfloat-linux-uclibc/usr/lib/libpng12.a /usr/lib/
ln -sf /usr/arm-softfloat-linux-uclibc/usr/lib/libfreetype.so /usr/lib/

Ok, good to go. Of course, I had to stop again the build to copy the "fixed" configure script that ignored IEEE math errors, but that is already history.

And, believe it or not, actually the build succeded. I had a cross built rrdtool using shared libraries built against softfloat ucllibc. No guarantees about its correctness, but it built!

This is when I decided to start writing this article.

Still there are things to do

I will have to do a few things before being happy about the victory:

• check that all the resulted binaries are indeed ARM ELF files, and not Intel x86. It appears the shared libs are already.
• done, they are (checked the next day)
• figure out qpkg (is a utility from portage-utils which seems to be a way to make binary packages) to package somehow the result of this work or maybe just ignore it and use plain cp
• see how I can fit together both the softfloat uclibc binaries and the native debian binaries on the same filesystem, including ld.so configuration...
• but I fear this will be a nightmare, so I might decide to go with static compilation of rrdtool, which I don't think it will be quite straight forward given the experiences describe above; there could be also the size issue to take into account, and since the NSLU2 has only 32MB of RAM, this could be problematic
• I think I'll have to use a statically linked binary after all (note added late, the second day)
  
• see if the rrdtool binary really works and if all the work payed off, performance wise - it should, taking into account what I have heard from wookey during the debconf7 talk about the armel (warning, 73MB ogg file) port
• be happy with the solution I got or wait for the Debian armel port to catch up and switch to that asap
• if I'll have to do the switch I'll probably think of ways of migrating the whole system from arm to armel, and not to reinstall everything; this might prove useful for the whole debian armel port, when people are working on migration plans, since arm will be deprecated in favour of armel

due to the constant high volume of incoming spam containing attachments
which are not easy parseable for our filters, the listmasters decided
now to block the following types of attachments: Content-Type: image/(gif jpeg)
Content-Type: application/pdf This is only a temporary solution, until we have better methods to
filter out spam mails containing these types of attachments. If you know better solutions, let us know! listmaster

Daniel Jacobowitz asked:

"Do these banks actually send billing information via email? The US banks I've dealt with (and other things, like most utility companies) only send you notifications to go to their encrypted web site to get your bill."

Good question. Actually, I don't know. I already have web access to my bank statements, so it would be strange to describe that as email billing. My emailed phonecoop bill is the actual bill as a PDF file attached to an email, along with a zipped CSV file containing fuller call data. I don't mind that being unencrypted too much because I download it from their mailserver with TLS, which doesn't seem too risky. Another phone company sends me an emailed bill as plain text, also unencrypted - I should go stop that one. Looking at the other utilities, it seems like two of them send email notices telling you to use their (horribly broken) web sites to get the bill, while the water company try to screw you if you sign up to their web services, and don't seem say how their system works. So, I'll not be signing up for any more of these just yet. What idiots are describing "email notices that ask you to download from the web" as email billing, which UK companies actually offer proper email billing and do any encrypt email yet?

A hot topic this past DebConf7 was git. I've bought into the hype, so I decided to take the plunge and move my Subversion repositories to it. A lot of people seem to be willing to part with their history when making the move, but I'm some what irrationally attached to it.

Most of my Debian packages are in one big SVN repo, which used to be one big CVS repo (I used cvs2svn to move). So I decided to pull apart each source package into its own git repository. I started with git svn clone like so:

$ git svn clone -A authors --trunk=trunk/libclass-makemethods-perl \
  --branches=branches/libclass-makemethods-perl/upstream \
  --tags=tags/libclass-makemethods-perl --no-metadata \
  file:///home/svn/debian libclass-makemethods-perl

And this gives a git repo that can track an SVN repo. But I want to go all the way, no turning back. So I made a little script to clean up this repo called clean-git-svn:

#!/bin/sh -e
tags= git branch -r   egrep 'tags/[^@]+$' 
echo "$tags"   perl -ne \
  'chomp($_); my $head = $_; s,\s+tags,debian,g; print "git tag $_ $head^\n"'
for i in $tags ; do echo "git branch -r -d $i"; done
upstream_tags= git branch -r   egrep ' +[0-9][^@]+$' 
echo "$upstream_tags"   perl -ne \
  'chomp($_); s,\s+,,g; print "git tag upstream/$_ $_^\n"'
for i in $upstream_tags ; do echo "git branch -r -d $i"; done
echo "git branch upstream current"
echo "git branch -r -d current"
echo "git branch -r -d trunk"

This will output a bunch of git commands that will make this a more "gitified" repo. I make no guarantees this will work, you should probably hand check your history with gitk to make sure this won't screw anything up. If your the part you're converting also came up from CVS, you'll probably have a bit of a mess on your hands that will need more manual cleanup. gitk is really an amazing visualization tool and can help a lot here. Once you're satisfied just pipe it into /bin/sh. Since git svn mostly can't track where you merged in your SVN repo, make sure you merge the upstream branch into master as soon as you can. It will save you a lot of conflicts later, trust me.

One thing I miss from svn is svn export. Does an equivalent command exist in git? You would think there would be an option you could pass to git clone to do this but I can't seem to find anything.

I moved back to using the ion window manager today (ion2 to be precise). Having tabs in my window manager, I no longer needed them in my web browser, which at the moment is epiphany. I couldn't find a way of disabling them or an extension to do it so I wrote my own. It's at /code/epiphany/, works for the epiphany in Etch but not in sid: it seems the GNOME people have disabled the "Detach Tab" functionality I was relying on. I think I can get it working in the later epiphany versions with a bit more work.

Five years ago, I started work on OfflineIMAP. I couldn't find any mail reader that offered good IMAP support and a good feature set. Rather than write my own mail reader, I simply wrote OfflineIMAP and used it with mutt. OfflineIMAP does a bi-directional sync between an IMAP server and local mailboxes. This lets you work offline, and also speeds up reading since each new message doesn't have to be downloaded from the network on the spot.

I kept hoping that OfflineIMAP would become obsolete soon, as mail readers got better. Back in 2004, two years after writing OfflineIMAP, I looked at mail readers. In 2005, after some more frustrations with mail readers, I wrote a comparison. I wound up sticking with mutt and OfflineIMAP each time.

I've gone out looking at mail readers again. Here's what I've found.

KMail
Overall a nice reader, KMail has almost every feature and setting I want. It has "disconnected IMAP" folders, which download every new message in folders to the local disk as part of the routine mail checking. It then caches local changes and syncs them to the remote on the next mail check. This boosts interactive performance and permits offline operation -- very similar to OfflineIMAP. KMail has keyboard shortcuts for most things, and keyboard shortcuts can be added or changed for most other things as well.

KMail also integrates with the KDE calendar and addressbook, which I already use. That's nice, too.

I have two big gripes about it though.

Back in 2004, I noticed that KMail crashes a lot. By 2005, it was worse. Sadly, KMail still has a tendency to crash. I've seen an average of 1-2 crashes per day, due to SIGFPE, SIGSEGV, and I think also SIGILL. This doesn't make me happy at all. Especially to see that it's no better on that in three years. Just don't try emptying trash while your mailbox is being synced, for one thing....

Gripe #2 is that there is absolutely no way to select a different alternative in a multipart message without using the mouse. Simply no way using the keyboard. It's also cumbersome, though possible, to view attachments using the keyboard -- you have to press Enter to open the message in its own window, then tab to the attachment.

KMail also sometimes works a bit sluggishly -- for instance, when you delete a message, you first see strikethrough through it, then it disappears. It doesn't feel very "snappy".

Evolution
Evolution has a decent core. It is easy to get set up and has an extensive set of keyboard shortcuts. It does IMAP downloading and syncing like Kmail, and it does it by default. It doesn't offer all that much flexibility in configuration, but probably enough.

Here's my gripe. There is no way for it to show a total message count next to each folder in the folder list. It will show an unread message count, but not a total message count. You have to click on each folder individually to see a total message count. I can't figure out why this is missing from Evolution. It's one of the main benefits to switching from mutt, and so I didn't bother looking at Evolution any more past there.

Thunderbird / Icedove
By default, it isn't all that capable of a mail reader. There aren't that many configuration options, and the keyboard shortcuts -- while existing for most things -- are cumbersome.

The Nostalgy extension helps with the keyboard shortcuts significantly. You still can't change some of them (Ctrl-L for forward, anyone) -- at least not without an extremely cumbersome process involving editing text files.

Thunderbird can do automatic IMAP downloading and syncing like KMail and Evolution, but for some inexplicible reason, only for your INBOX. In fact, Thunderbird won't even check for mail in folders other than INBOX unless you set an undocumented configuration option. It seems to assume that nobody does server-side mail filtering.

If you want IMAP downloading for offline use or performance, you have to manually invoke a download operation. There is a Sync on Arrival extension, but it isn't compatible with Thunderbird 2.0. From reading comments online, there are a lot of people frustrated about that.

So Thunderbird strikes out as well.

mutt + OfflineIMAP
The good thing about this combination is performace. mutt is extremely fast, and OfflineIMAP works faster than anything else for IMAP downloading. mutt is also far more configurable than anything else.

There are some annoyances about mutt.

#1 on that list is the lack of a folder list. There is just no way to see a list of folders along with new or total message counts. You can press c, Enter to go to the next folder with unread mail, which is something, but not enough. There have been numerous abortive projects over the years to address this, but for whatever reason, mutt itself doesn't have this yet. Probably the most promising current project is this one.

#2 is HTML mail. I don't mind the lack of default support for HTML mail. That's to be expected. There are some things that do bug me involving viewing HTML mail. First off, sometimes people attach graphics to messages that also have an HTML component. Viewing these graphics doesn't represent a security risk, but mutt doesn't make them available to a browser for viewing -- you have to manually save them if you want to view them. Also, you normally don't want to load graphics from the Internet for HTML mail. The only way to accomplish that with mutt is to set your browser to lynx or something; just using Firefox to view a HTML component will load all of that.

#3 is handling of embedded URLs. xterms can pass mouse clicks, and it would be nice if mutt made URLs clickable like other mail readers do.

#4 is the IMAP support. No support for caching, fragile, etc. That's why I use OfflineIMAP. That works, but it's a hassle.

#5 is printing. Printouts from mutt just spew the text of the message at the printer. No page numbers, formatting, nothing. muttprint makes that situation a bit better, but the integration is flaky and weird.

Conclusions
I'm not sure what I'll do. None of these are really where I want them to be, though mutt and KMail are probably the closest.

Bought a NSLU2 from Ebuyer. Was about ~50GBP hence qualifying for free delivery with 5 working days. I don’t know why, but according to the packaging it was sent “next day” on the 4th day(!?). The device came direct from the usual suspects Computer2000, one of the oldest and biggest computer part distributors in the UK. Sidenote: I wonder if Ebuyer can claim to have stock, when it’s actually their distributors stock? tbm’s slug install page aided my Debian etch install. This slug has a 80G external USB hard drive attached with 10G ext3 for Debian and the rest for my legacy pr0n collection on fat32. I’ve already configured nfs and it seems to work well. 539M Debian install for that… bloat. I am worried I might have not have given it enough swap, so now I am thinking of how to ramp up the memory. I’ve reassuringly discovered my slug is already operating at full 266 speeds. It would be good if this device can handle btdownloadcurses. Other ideas is to setup a logging server on it. Also I’d like to familiarise myself better with the architecture. I think I’ve seen these Xscale’s in at least one mobile phone. :) Other hardware purchases I am thinking of:

• a USB wireless device – Anyone knows what chipset a Linksys WUSB54GR sports and if it is compatible with aircrack?
• Another USB stick
• Another huge USB external drive for the slug
• USB serial for connecting up my etrex primarily

I wish this slug had a USB-style power supply. As for backups, I want to switch everything I have over to LVM2 eventually and use its snapshot features. Any tips or suggestions, let me know. I am not a fan of RAID solutions btw.

If you’ve received email from an attorney in the last five years, you’ve probably seen some version of a boilerplate warning/disclaimer in the message footer, indicating that the message may be privileged (or in some cases, asserting that the message is privileged!) and telling the receiver to destroy and/or return all copies if they are not the proper recipient. In the last couple of years, almost everyone has also added a statement to the effect that this email does not contain illegal tax advice (or if it does contain such advice, you shouldn’t use it!) Cumulatively, I’m sure we’ve used gigabytes if not terabytes of bandwidth attaching this text to every email sent. My question to the world: is anyone aware of such an email disclaimer ever being enforced or held enforceable?

Share This

A month ago I asked for help to localize reportbug-ng. To my surprise translations came in pretty quick. Junichi Uekawa was the first one, he sent his Japanese translation only a few hours after my request for help. Currently we have rng translated into the following languages: Catalan, Czech, English, German, Japanese, Spanish and Swedish. Thanks David Planella, Miroslav Kure, Junichi Uekawa, Javier Fern ndez-Sanguino Pe a and Daniel Nylander for your translations! But that’s not enough. If your language is missing, please consider translating rng to your language. Just take the source of the current version in unstable, grab the .pot and translate it. There isn’t really that much text to translate. The .pot contains only 42 messages and most of them are very short. When you’re done, please file a l10n+patch bug against rng with the translation attached. I’ll include your translation as soon as possible, thank you in the changelog and will probably name my first pony after you Thanks!

Some time ago, I needed a small but helpful tool which could start some shell command with bounded time and kill spawned process if it was timed out. There is timeout package in Debian but it has very serious bug #187092. In fact, this tool can't intercept the proper status of called command and can't kill processes spawned by called command. I've tried to fix the Debian's timeout package but the bug is still opened over 4 years. So I decided to code the own Perl implementation. The result was attached to bug report. I've noticed that my script is currently used by Exim packagers. It's nice to see that my work is still useful. I think more people can find this script helpful so I set the Google Code project: timeout-pl. You can download the newest version of this script from Google or CPAN. Have a fun.

Just stopped off in Derby on the way to Edinburgh. It was a good move in one way, because my inbound train was running over 30 minutes late (diverted due to the floods in the Midlands) and my outbound one is only 10 minutes late... but the manager just announced flooding in West Yorkshire, so I guess we'll see. The inbound train was called Vyjaer Kernewek (or something like that), which was nice to see. Derby was useful in another way (besides a good wifi-enabled light meal at the big blue coffee shop). I bought a laptop case. I didn't plan that when I set off, but by Bristol it was already obvious that I couldn't carry all my widgets in one bag. I also couldn't get the laptop out on the train, for fear of a packing explosion. So, Derby has shops. It also seems to have a market-free market place as the focus of the city centre. There's a view up to the cathedral, a small waterfall... and the Derby Mountain Rescue. I suppose the peaks are near, but mountains? The market wasn't in the marketplace. It seemed to be under cover in two parts. One is in the guildhall and the other is in a shopping centre that seems to have an identity crisis - is it the Eagle Centre, or is it Westfield? - and also has a building site attached that greets you as you approach from the railway. Not good tourist promotion. Until the building site, the City-Rail Trail is signposted well, about 5 minutes walk, but the signposts are a bit odd. I noticed the funny ridges first and dismissed them as an anti-spin thing, but then I noticed some bronze floppy disks (I'll post a photo once I find the right USB lead). Other attachments included spark plugs and glasses. There's no sign explaining it that I saw. What the heck is that all about? Coda: No, it wasn't a good move. Apparently there's more flooding in South Yorkshire, so I arrived about midnight and this is posted the next day. At least I'm having a better time of it than damog, who's stuck in New York and I wonder whether other tales of woe will appear on Planet Debian as people find net access. Now for breakfast and planning the day.

My second problem with people who use the Franklin Redways papers to claim all cycle tracks are dangerous is that I don't trust the user number and preference estimates in the papers. I noticed cycle counters (sensor loops cut into in the path, attached to a grey cabinet with solar panel) scattered around King's Lynn, but I don't remember any in Milton Keynes. Milton Keynes Redways and Leisure Routes: An Information Sheet includes phrases like 'It is evident from casual observation...' while noting the combination of this with other data suggests a 'paradox' - maybe there's no paradox and some of the casual observations are simply improbable? The main source of cycle use data seems to be surveys rather than counters. A survey with 120 responses has quite some potential for error when used to estimate a city catchment area of 200,000 people. An "accident rate" equals "accidents per use", so an incorrect use estimate can make a very big difference, especially if use is still sadly small. As the author says, he has no accurate usage figures for the Redways. Another survey is included in the references, so I find it surprising that no usage information is quoted from that survey. Perhaps it would help to explain the figures in some way unwelcoming to the general tone of the piece? Cyclist preferences seem to be taken from one cycle user group screenline count, rather than a cordon census or survey, which I also found surprising. I often rode parts of a trip on the 'least-bad' option for connecting the best route overall, not on the type of route I would have chosen if I had a choice. After all, when in my car, I'd probably choose to drive along a dual-carriageway from the edge of my village if I had the choice, but I don't, so I use a winding lane for the first mile or two. I don't prefer the winding lane to the alternative quarry road or the toll road: it's just a connection in a better route overall.

... is NaughtySVN.

I have joined this project which was started by Alexander Thomas a few weeks ago and I have convinced him that is better to have a release sooner rather than later. The project is still in its early alpha stage[*] but I thought is better to have a rather minimalist and functional client first.
So, I talked to Alexander and we came up with a roadmap; for the 0.0.1 release I am working on the update feature which is about 40% done[1][2] (update dialog screenshot).

Of course, after the release I will probably make a debian package, too, unless someone else beats me to it :-) .

So, the future is bright.


Update: as a response to a comment, NaughtySVN is designed to be not only a Subversion client, but also a framework for other VCS-es and other clients. It just happens that we are working on the Subversion backend and client at the moment.

P.S.: as curiosity of mine, I have written in python a small nautilus plugin that does the svn update (is a svn frontend) and I must say I really miss the development speed of python when writing in C (or maybe I am out of practice).

[*] only a few features are implemented and can't be used yet as a SVN client without being forced to use another client.
[1] according to my estimations
[2] update related code is not committed yet

The day after Memorial Day, when I got into my car, it reeked. A strong, foul odor greeted me that morning. It had rained a lot during the long weekend, and I hadn't driven the car. I figured it was just some water sitting somewhere. It ought to evaporate soon enough. The smell seemed to be coming from the vents, so I figured I could help it evaporate by running the fan as much as possible.

I've been dealing with the smell ever since then: windows open, fan on full blast, as often as possible.

This morning I noticed a chewed Kleenex with rodent droppings attached to it in the glove box. I also noticed Kleenex bits and more rodent droppings on the floor mat below the glove box.

So I have a more sinister enemy here.

I dropped by the mechanic over lunch to make an appointment. I explained the symptoms. He looked as me suspiciously.

"But how would a rodent get in there? Hmm... I forget -- do you live in the country?"

"Yes, I do."

"Oh, well that would explain it then."

It reminded him of other rodents he's done battle with -- pack rats that have chewed up wires and hoses, including one that was still alive and in the vehicle when he started working on it.

So I asked him how expensive this was going to be.

"Well, I don't know. It could be easy, or it could be interesting. You just never know when you're dealing with rodents."

He promised to call me if it looked like it might be interesting.

I'm a bit late to this party, but the NSLU2—affectionately known as the 'slug'—is a piece of kit you can't afford to be without on your home or small office network. Not much bigger than the palm of my hand, and cheaper than a ticket for a Test at Lord's, the NSLU2 is a small fileserver that serves files from attached USB disks. What makes it particularly special is the large amount of alternative firmwares built by Linux open source developers, which allow you to extend the functionality of the NSLU2 beyond merely serving out files via SMB (the Windows file serving protocol.) Cheap NFS serving  So what's the big deal for me? Well, like most laptop-slinging folks whose home network is predominantly wireless, I want my backup disks to sit on the network, available when needed. It turns out it's very difficult to find a standalone network disk that properly supports Unix file system semantics such as symbolic links. Most just support SMB file sharing, with attendant limits such as no links and no files over 2GB. (I found this out the hard way with Apple's Airport Extreme.) With the NSLU2 I was able to install the "Unslung" alternative firmware, and install good old NFS, making my backup disks available in a normal way to Linux and OS X machines alike. (How we used to complain about NFS back in the early 90s, but Windows file sharing still makes it look good!) In the great tradition of open source there are multiple choices of Linux distributions you can install. As it was my first time round, I went for Unslung, which preserves as much as possible of the official Linksys interface, but lets you extend it. Next time, with a better idea of what I'd use the box for, I'd probably plump for Debian.  Constraints breed creativity Inside the case, the NSLU2 is in fact a tiny Linux machine with 32MB of RAM and an Intel XScale CPU. This turns out to be plenty enough resources to serve files on a small network. Aside from my prosaic needs, the NSLU2 has been put to several more innovative uses, such as a music server for Apple ITunes and a 4-line home telephone exchange. I've been astounded at the applications people have devised for this little box. Being fairly cheap makes it a great candidate for home automation projects. It's a great example of how limiting resources fosters innovation. Remember how games on 8-bit microcomputers were so much more ingenious than those on their more well-resourced successors?
So, I may be a little slow in finding this little hardware gem, but I wholeheartedly recommend it.