As promised yesterday in my report about the Munich BSP, I'd like to talk some more about LiMux, the project being run within the City of Munich to replace all of their desktop Windows systems with Linux. The team kindly offered us the use of their offices in central Munich as a base for the BSP last weekend, and on Sunday afternoon they gave us a demonstration and answered lots of our questions. The following is from my (known-faulty) memory...

Jan-Marek and Florian talked us through their setup. They're using FAI to automate installation of systems, along with LDAP to store lots of configuration information and GOsa as a user-friendly front-end to that configuration. They've integrated these to enable some very clever management features so that all aspects of the city-wide system can be maintained from one central point. As new machines are introduced onto the network, they can be configured into one class or another: simple desktop clients up to so-called "depot" servers, used as seeds for further clients. Individual user profiles can be tweaked, giving users access to new applications as they are needed. Shared resources like network storage and printers are set up automatically from the LDAP database. Access to USB storage devices can be controlled on a per-device, per-user basis for security. That's quite an impressive feature list. Most of the work has been in configuration and systems work rather than custom packages on the clients themselves - the vast majority of the packages installed come straight from the standard Debian archive, with some backports (like a newer version of KDE). Building on top of standard packages means that they have access to a huge amount of Free Software without having to do all of the work themselves. A small team (10-ish at the moment, growing to 100 or so in the future) can effectively deploy and manage desktops and associated servers for a huge number of users - they're expecting to be supporting on the order of 30,000 systems 2 years from now. The team have just recently made their first stable release and are starting to roll it out across the city, one department at a time. There are the familiar issues involved in the deployment, of course. For example, users don't want to help test pre-release versions to help nail bugs, but then complain loudly when they find bugs in the first release. And in such a large project to migrate from predominantly Windows (NT4!) desktops to KDE on Linux, a major part of the effort needed is in user training. There is quite a bit of support and custom work needed to convert people's MS Office macros over to working on top of OpenOffice. And there are still quite a number of users who will remain using Windows for specific applications that still don't have Linux equivalents yet. Apparently the "Wine Cellar" group will help on that front. *grin* In terms of collaborating with Debian, the LiMux team are expecting to help in a few ways. As bug reports are filed against their applications (apparently very few so far), they'll be pushed upstream along with (hopefully) fixes for them. They will also be devoting some full-time developer effort to security work; it would be good for both sides if this effort can be shared.

It was quite striking to see Tux, the Linux penguin, as a visible logo in local government offices! The team have clearly made some excellent progress on this exciting project, and I'm sure that I can speak for all of Debian in wishing them the best of luck in the future. I'll be watching with interest...

I am constantly amazed at the apparent lack of interest in car-pooling when travelling between LUV meetings and the restaurant where we have dinner. After the last meeting I was one of the first five people to arrive at the restaurant and we had arrived in three separate cars. For the most luxurious travel you can have four people to a car and a standard sedan class vehicle can legally and safely carry five people. So an extra seven people could have been comfortably driven to the restaurant and an extra ten people could have been safely and legally driven to the restaurant. But instead most people were waiting in the cold at the tram stop.

Things are quite different in Europe. There was one occasion when after an LSM (Libre Software Meeting) conference in Bordeaux we got 8 people in a Mazda 323, now that's what I call car-pooling! NB This is dangerous and illegal, so I can't recommend doing it.

At the start of the year I suffered a minor injury to my left eye. This brought my vision down to slightly below average for my age. A doctor and an ophthalmologist both thought that my vision was good enough at this level and that I don't need glasses. But the ability to use a small font means that I can have more text on screen and thus do my work more effectively. Since about March I have worn glasses all the time. Regardless of what the experts say I want to have good vision all the time and there is a significant difference between my vision while wearing glasses and that without.

It's often recommended that people get their eyes tested about every 2 years from when they are in their late 20's and also get a test done a few months after any eye injury. I strongly support such recommendations for anyone who works in the computer industry. Even if your vision is slightly less than it could be it will make a difference to your work. I have not found glasses to cause me any inconvenience, I'm sure that it would be bad for children to wear glasses but for adults the only potential issue is when playing sport (which is less demanding on your vision than reading an 8 point font on a typical monitor). I am constantly amazed by TV and radio adverts which say "do you wear glasses, if so then you must have considered LASER eye surgery". Glasses are fine (IMHO) and I will not consider having a LASER or other dangerous object pointed at my eyes unless I am in danger of death or blindness!

The testing apparatus that an optometrist uses is interesting to inspect if you like machines. It is a device with a huge selection of levers for inserting different lenses in front of your eyes until they discover the combination that gives you the best vision. If you get your eyes tested make sure you get the optometrist to explain everything, you can learn many interesting things.

Recently, I have had a further eye problem. Recently my central vision went blurry with a shimmering affect for about 40 minutes, but the peripheral vision was OK. An ophthalmologist diagnosed this as a migraine, apparently I got a very mild one with only a minor visual affect but no headache etc. One thing that is apparently possible when experiencing migraine related vision impairments is the ability to act on visual information without consciously knowing it (EG catch a ball without seeing it).

A migraine is a better diagnosis than I had feared. The movie Super Size Me (the topic of tomorrow's blog entry) contains an interview with a main who describes a diabetic vision problem that sounded similar to mine. Migraines don't cause permanent problems while diabetes can, and diabetes requires lots of unpleasant blood tests and injections.

Apparently migraines are often triggered by physical events or food items. If you suffer one then it's recommended that you write down as much information as possible about the previous 24 hours to help track down the cause. If you experience something similar to what I describe then do not take this blog entry as medical advice, instead rely on a doctor and whichever specialist they refer you to. But do write down everything that happened prior to the medical problem (keeping an accurate diary can't do any harm).

The Wikipedia entry on Migraines has a lot more interesting information, but don't take it as medical advice either. One particularly interesting thing in the Wikipedia article is the note that migraines may be caused by not having suitable glasses, or prevented by wearing special glasses.

In response to my previous post someone pointed out that MX records have an obvious benefit of offering multiple servers at different priority levels.

I don't believe that this is a benefit for many machines on the modern Internet. Most systems that have secondary MX records implement them poorly, they have less SPAM checks on the secondary MX server, and it often doesn't even have a canonical user-list! This is a really serious problem, spammers apparently often target the secondary MX server (I don't have evidence for this but many people assert it to be true and it would obviously work so is likely to be true) and it's well known that spammers often guess account names (a quick scan of the logs of any mail server will prove this). These factors combine to make a secondary MX server without a canonical list of user-names a serious spam problem, it will receive mail and then bounce it to innocent third parties (the vast majority of spam has a forged sender nowadays).

If you have the ability to run a well configured secondary MX server with a canonical list of valid account names (which must be maintained independently of the master mail server for obvious reasons) then there is the issue of why you would want to do so. What problem does it solve? In the early days of the Internet mail storage machines were often end-nodes on the network, many hops away from the central well-connected machines. This meant that sometimes connections would time-out or the hop count (which was smaller then than it is now) would be exceeded. Having a well connected server being a secondary MX server was a significant advantage for a small mail server in those times (by todays servers almost all the mail servers of 1993 are small and the biggest servers of 1993 were medium sized by today's standards).

I just did a quick search for machines with secondary MX records (IE multiple MX records at different priorities). The only significant mail service with such configuration that I could find was gmail. Hotmail.com, ibm.com, microsoft.com, aol.com, and zonnet.nl all have multiple MX records at the same priority - this is a cluster of primary mail servers not a primary/secondary configuration. The evidence suggests that mail servers such as hotmail.com do not benefit from a secondary MX record, so I doubt that any other domain needs it either.

In response to a comment on my previous post, I have previously mentioned in mailing lists the issue of spammers attacking secondary MX servers, but I couldn't see it when reviewing my blog archives.

Above is day 10 of the beard.

The weekend of the 14th-15th October saw my third BSP in as many weekends, this time in Munich. Andreas Barth was in charge of the organisation, and the LiMux development team were kind enough to host us for the weekend at their offices in the centre of the city. Andi, Zobel and I headed into the office early on Saturday morning, ready to start hitting RC bugs. Others joined us during the morning, and we got to a total of 10 people working on fixing bugs. Personally I looked through many of the bugs listed on Andreas' page. It was heartening to see that a very large number of the RC bugs were already well in hand, with patches available and in lots of cases uploads already made. I spent some time looking into #389287, #392398, #389375 and #262440. I also helped out several other developers with their own bug fixes, giving out accounts on my wide range of machines at home so that they could debug on different architectures.

We worked late into the evening, ordering in pizza and then later cooking in the offices. I moved onto some more debian-cd hacking later on, making real progress and getting almost to the point of having my multi-arch CDs working. As always, there was a lot of discussion about the general issues in Debian, especially the 4 GRs that were due to finish that evening. On Sunday morning, things started slightly later as we took breakfast at the office. There was more discussion of the GRs, and the results were generally well received by the group. We continued looking into the RC list; I investigated #389434, but struggled to make much progress. At lunchtime, we quickly(!) headed into the city to see the famous Glockenspiel at the city hall, and went for a quick tour of the historic city centre so that us non-locals could see something of the city outside of the office. We returned and picked up on the bug-killing for a couple of hours. Then the LiMux guys showed us some of their work, and gave us a demo of the project. More on that later... Unfortunately, I had to head back for my flight comparatively early this weekend so I couldn't stay around for very long after the demo. Despite the last-minute attempt by an S-Bahn ticket machine to delay my trip to the airport, I got back without incident and even landed early at Stansted. The Germans I met this weekend were very serious about getting work done, and their efforts are much appreciated. With more people helping to reduce the RC bug counts, we should have no problem releasing Etch in December. Let's keep up the good work...! As always, my meagre attempts at photography are online now.

Dear Benjamin Seidenberg!
Your account ‘benjamin’ has just been created in the central LDAP
database of the Debian project.  Please note that it needs a bit of time
until this information is synced with all developer-accessible machines.
You should be able to login or upload packages after about 30-60 minutes.
The password for this account can be found appended to this message,
encrypted with your GPG key.
Email sent to benjamin@debian.org will be forwarded to astronut@dlgeek.net,
to change this visit http://db.debian.org/forward.html.

This has definately made my day. I would like to thank my sponsor and advocate, Anibal Monsalve Salazar, the Debian Cyrus Team (especially Sven and Henrique) and especially my AM, Cl ment Stenac (Zorglub). I couldn’t have asked for a better AM; he answered every mail within a day as far as I remember, was extremely supportive and helpful. I remember when I sent him the last T&S response he appologized on IRC that he couldn’t write the recommendation until that evening, whereas some AMs have taken months to do it.
For those interested in the NM queue’s proccessing time, here is an approximate summery of my progress through NM:
Waiting for advocate: 2.5 weeks (This should have been shorter, I had my advocate lined up, but then there was a question about me signing the key of the guy who signed mine, but I hadn t checked his ID).
Waiting for AM: 6 months
Going through the checks: 2.5 months. (This would have been shorter had it not been right around the end of my senior year of high school, with the mad rush to cram everything in before exams)
Waiting for FD: 1.5 Months
Waiting for DAM: 1.5 Months
Waiting for account creation after DAM approval: 2 months.

I think the important thing this weekend is that I saw Katelyn truely drunk. Other than that the night ride organized by the SFBC was fun. I've yet to find a group in the city to do longer weekend rides with yet though.

There have been quite some comments on the Iceweasel case all over the planets, and I saw several assertions, especially from the Mozilla camp, that I, as the Firefox co-maintainer, the xulrunner maintainer, and (soon) Seamonkey iceape co-maintainer, have to rectify. They broke the –enable-official-branding flag
Half-true. We just replaced Bon Echo/Deer Park with Firefox at the appropriate places in the build tree so that we could have Firefox with the “unbranded” logo instead of the official logo, as Gervase Markham gave us authorization for. You’re still free to enable the official branding, except that since the logos and stuff are non-free, we removed the other-licenses/branding/ directory from the original tarball, thus yes, the flag is half broken. Firefox logos being subject to trademarks, Debian thinks they are not free.
Trademark and copyright are different things. Mozilla has unnecessarily given a non-free license to “clarify” the trademark situation, but that is not required. To make it clear: Debian thinks the logos are not free because they are not free. Period. Debian isn t properly collaborating with Mozilla , sending unusable 100000-lines patches for validation just before releases (as seen on Lucas Nussbaum’s blog)
Let me take the firefox_2.0~rc1+dfsg-1.diff.gz file, strip the debian directory from it (it only contains maintainer scripts, our set of icons and some debian specific searchplugins), and strip the configure diff that is generated by autoconf due to some changes in configure.in… that’s exactly 2654 lines of diff. Very far from the 100000-lines patches they are claiming. The Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions (from Lucas’s blog again).
So, let’s dig into our firefox_2.0~rc1+dfsg-1.diff.gz:

• Changes to disable application upgrade (we want that to happen through apt-get) and change some other default preferences,
• Changes to fix “make distclean” so that it really cleans the build directory,
• Change not to build the “mangle” utility,
• Change not to call netstat to generate entropy, which is useless on linux,
• Changes to make Firefox build and work on architectures such as hppa, mips, mips64, m68k, ia64, sparc64, alpha, and arm, which the Mozilla guys don’t seem to care much for,
• Change to add a preference directory so that users can put their set of customized preferences in /etc/firefox/pref,
• Change to allow to build flat chrome without the zip utility,
• Change to allow to use system library for myspell, instead of statically linking the bundled one,
• Changes to allow to build s390 binaries on s390x host with s390 toolchain (same applies with x86 binaries on amd64 host with x86 toolchain),
• Changes to work around bugs with the hidden visibility pragma on gcc,
• Changes to make the pango backend actually build correctly,
• Changes to avoid some error messages while trying to create Makefiles from inexistant Makefile.in’s,
• Change to install in /usr/lib/firefox instead of /usr/lib/firefox-x.y,
• Change not to build useless chromelist.txt files,
• Changes to make helper applications with parameters work,
• Changes to allow builds against GTK 2.8,
• Changes to work around an Xrender bug,
• Changes to make the Gecko/yymmdddd string taken from preferences instead of being half-hard-coded (you could change it with preferences, but it would still be set to the hard-coded value at start time ; and you could change it again with preferences…),
• Change to allow mice extra buttons to act as something else than a left button,
• Change to allow to build with -Wl,–as-needed to avoid linking against a whole lot of useless libraries, without losing the link on libxpcom.so which is required by some extensions’ components,
• Changes not to shlibsign the NSS modules at build time, since we’re stripping the binaries afterwards, thus breaking the signature. We do build the signatures later, within the maintainer scripts.

That’s not that many changes, and most of them were taken from either some Mozilla CVS trunk or the Mozilla Bugzilla . And most of those that were not taken from there have been sent, except those that really don’t make much sense outside Debian. So, where are these frozen API changes ? And we’re not properly collaborating, huh ? The Mozilla project started by coming to a (admittedly uneasy) agreement with Debian for use of the name, but the Debian version diverged even further from the official version, so the permission was revoked. (from comments on Matthew Garrett’s blog) That one is really interesting, because between the time we got this understanding with Gervase and now, we are actually less diverging from the official version than by then. The main difference by that time was the extensions manager, which, in Debian, needed a lot of changes to actually act as it should, especially with globally installed extensions. I’m not saying the Debian one was perfect, it also had its own problems, but that was a whole lot less than the blatant crap that was the official one, obviously written for Windows without any thoughts for unix, and especially linux distributions. The only main difference now, between the official Firefox and ours, is that our build has the pango backend enabled, which we chose over the Xft backend for several reasons I won’t explain here. The others differences are that we use system libraries where possible, instead of the bundled libpng, libjpeg, libtiff, libmyspell and libcairo. We also build a flat chrome, instead of having everything in .jar files. Now, a little bit about differences the Mozilla guys don’t seem to care about while they really should: distributions build the Mozilla products with gcc 4.x, while the official binaries are built with gcc 3.4, as well as the extensions distributed on addons.mozilla.org. Fortunately, not a lot of extensions make use of binary components, and not a lot are linked against the standard C++ library, but when that happens (like with colorzilla), you get a component linked against libstdc++5 to load on a Firefox that is linked against libstdc++6. You are lucky if that setup doesn’t crash. Little extra from comments in Lucas’s blog:
Is it possible for the Debian Firefox maintainers to create an installer package for contrib which will install the vanilla FireFox from Mozilla s site.
How great would it be to have a package for one architecture instead of 12, and with a dependency on libstdc++5, that almost no other package uses any more. Update:
Debian is going to replace Firefox with a GNU fork called Iceweasel
Half-true. For the etch release, Iceweasel will only be Firefox with a different branding. We are taking the Iceweasel name because it was already know as a possible alternative name for Firefox when the trademark concerns have been raised more than 2 years ago (thanks Nathanael Nerode for this nice name, by the way). It appears that the GNU guys decided to start a fork with this name… that’s quite unfortunate, actually. Anyways, the plan is to get in touch with them to see what we can do together, but with the etch release approaching, we can’t and won’t do more than a rename for the moment. Update 2:
We (Mozilla ) presently have working relationships with most of the major Linux distributions, including Red Hat, Novell, and Ubuntu (As seen in several posts from people of the Mozilla Corporation or Foundation)
Very interesting. Ubuntu uses the same set of patches as Debian, with some more of their own, and even releases beta software in their official releases. But when it’s Ubuntu, it’s fine. Sorry, I forgot Debian is lame, and DDs are frustrated fanatic integrists, on top of being bloody fanatic assholes. Update 3: Added some precisions about other differences with the official binaries, and a small patch I somehow forgot.

Dear Bubulle, I am afraid that you do not know what you are talking about. Because you aren’t the only one in this case, here’s a short explanation of what happened. The existence of the IceWeasel fork is a reality that the Mozilla people need to accept and, optionally, understand (they also need to remember what Free Software is and how it all works). Unfortunately, some of the Mozilla people at the JDLL yesterday obviously couldn’t bear a little reminder about IceWeasel, but they were the minority. We hung the two posters in the morning, and they did not even notice them for something like 45 minutes. After what, somebody came and asked, in what can be described as an angry manner, if we knew why the IceWeasel fork got started. The answer was a plain and simple “I don’t care why the fork started. We’re going to rename Firefox in Debian so you people stop annoying us with your fucking trademark.” (which was obviously as rude an answer as their original question). At which point they just went away and never came back. They proceeded to fix the Firefox poster by adding a “TM” on it and, I think, fixing the capital “F” in the middle of the “FireFox” name, then stroke the “IceWeasel” line on the other poster. At this point, photos were taken and posted to one, then two blogs. Sam, for the sake of completeness, added the missing and markings to the Firefox poster, which the Mozilla people forgot to add. The whole thing could have stopped at that point, but Daniel Glazman, the famous Daniel Glazman, thought it’d be wise to link the first two blog posts on his blog, vomitting on Debian while he was at it. This was an extremely bad idea. His blog being syndicated on Planet Mozilla, he and the other Mozilla people are just helping spread the IceWeasel name and publicising the whole Mozilla trademarks debacle. I’m just not going to comment on the behaviour of the most vocal Mozilla supporters (no, dear Daniel Glazman, I’m not going to use the term “fanatics”, I leave that up to you), it’s just not worth bothering. Josselin linked the first blog post on his blog, so the thing made it to Planet Debian, too. This is no big news for Planet Debian readers, as the IceWeasel situation has been discussed at length on various blogs already. Now, what you Christian do not know, is that we have had several discussions about the Mozilla trademarks problems at the JDLL. Many people here were not aware of this problem and asked both the Mozilla people and us about it. We explained at length, several times, what happened, what their position was, what our position was, what had been proposed by both parties, why their proposals weren’t acceptable to us. Most of the people were quite astonished to learn that Mozilla Corporation refused the “Community Edition” idea, and most of them got our point. At the end of the day, one of the Mozilla people came and apologized for the blog posts and comments (although he isn’t the author of any post or comment, I believe), telling us that it wasn’t nice from them. Thanks for that, really. Overall, all of this is very positive for the Debian Project. We are doing the Good Thing. To everybody in Debian involved in the renaming of the Mozilla products: thanks, and good luck. Mozilla Corporation now has to face the Free Software community. It’s up to them to either come up with something that is acceptable for the community or stop whining about people complying with their trademark policy. Internet Explorer still has something like 82% of the market. You aren’t done yet, and you’re not going to progress without community support. So you’d better not lose this support now. Up to you.

After writing previous post I have realized that I haven't written any entry in my blog since 24th July. Heh! I hadn't even had holidays then! I have been quite busy enyoing a nice summer, going to Lanzarote some days and resting after the hard last months of work. Now I am working a bit far from home, which means that I don't have a very decent Internet access during the week, so I am not able to blog enough, and I am only trying to keep reading email and having my packages ready, as well as reading different interesting stuff I found out there. Anyway, I hope to keep my blog more updated than these months. For now I am going to update the read books list. I have been reading action novels and so... with summer hot those are the best readings!

After writing previous post I have realized that I haven't written any entry in my blog since 24th July. Heh! I hadn't even had holidays then! I have been quite busy enyoing a nice summer, going to Lanzarote some days and resting after the hard last months of work. Now I am working a bit far from home, which means that I don't have a very decent Internet access during the week, so I am not able to blog enough, and I am only trying to keep reading email and having my packages ready, as well as reading different interesting stuff I found out there. Anyway, I hope to keep my blog more updated than these months. For now I am going to update the read books list.

Hey, the actual version 0.06 of my Perl written WAP browser wApua now is in Debian Sid! It’s the first software written by me which has entered the Debian repository as its own package (since pum is included in the package pisg which is in testing now for a while) as well as the first software debianized by me which reached Debian Unstable. Things are always exiting for the first time. ;-) Thanks to Myon for sponsoring the package.

Many moons ago I thought it might be nifty for my work on Debian QA to have an easy way to see what has changes in each version of a Debian package. I wrote a little script that built a bzr branch for each package, and imported each new version in my mirror. Unfortunately, there were some problems, and I didn't have the patience then to fix them. Last weekend I finished the script (despite not doing any Debian QA work anymore), and set it running. Today it finished. There were still some problems: 88 packages failed, due to problems in bzr. I've reported them to the bzr mailing list. The run took about three full days, on an machine with a 2 GHz AMD64 cpu (in 64-bit mode), 1 GB of RAM, and two 80 gigabyte hard disks in striping mode. It would've gone faster, but I ran out of disk space a couple of times, and it took me hours to wake up and notice. Disk space usage is now about 90 gigabytes, but that's with most branches' working files removed, to save disk space (i.e., only the .bzr directory and contents in most branches). Note that the size shouldn't grow very quickly. Most new versions only change some files, and only parts of each file. Version control systems are good at keeping only the changes. I'm pretty sure 200 gigabytes would last for a long time. Bandwidth and disk I/O might be more limiting, if we wanted to have this as a service open to everyone. I don't know if bzr is the best vehicle for this; perhaps a huge Subversion repository would work better. My instinct says that a distributed version control system would work better, but I'm sure a centralized one would work, too. Whatever the system, it might be helpful for QA work, and for making changes in many packages at once, to have something like this. For QA work, it would make it easy to see what has changed in each version, or to find the version in which a certain change in a package was made. For sweeping changes, this kind of a system should, I think, make it easier to automate the build and upload of packages that are changed. I'm not, by the way, suggesting that this kind of a system would be used to do normal maintainer development. It would work by importing new uploads, not by having people commit to it directly. Or perhaps such a system wouldn't have any use for Debian, I don't know. But at least the script was useful for stress testing bzr a bit, and finding a couple of bugs in it. So it wasn't a waste of time to finish it.

Dear Lazyweb, I’m looking for a small, (easily fits on my lap on the cramped seat of a bus,) inexpensive, (around $100 CAD,) mobile text-editing device with a 90%-sized keyboard and decent battery life that runs an open source OS and Vim, and that I can sync to my desktop system. My first mobile device was a NEC PC-8201A, circa 1984. It ran on 4 AA NiCad batteries which I hardly needed to change more than once a week. At the time, it was my ideal mobile notetaking device. Its near-full-sized keyboard, Wordstar-compatible text editor, terminal program and serial interface allowed me to take notes which I would sync to my father’s Mac at home or to the VAX at the university. Today, my mobile computing needs have hardly changed: text editing is almost all I do. I don’t ask for much of a display, but as an 80 to 90 wpm touch-typist, I won’t settle for anything less than a near-full-sized keyboard. I’d prefer a system that runs Debian, and Vim is a must. Some means of easily synchronizing the device with my home system is necessary: PCMCIA wireless-B would be ideal, but is not a must-have. At the moment, I’m using an old Zaurus (not Linux-compatible) ZR-5000 which has good battery life but a very cramped keyboard, poor software, and no functional means of synchronizing the device to my PC. OK for jotting down quick notes, but frankly, I’d rather have my PC-8201A back again. I could at least type on it and sync it across the serial cable. I took a brief look at various Psion models, but they appear to be near-impossible to find. The HP Jornada 720 looks intriguing. And the NEC Mobilepro 780 appears to be another possibility. Have I overlooked anything? So, suggestions please.

Last weekend, I went to Zurich for the second leg of my own personal BSP marathon. Martin Krafft organised the BSP at the AI Lab in Zurich, arranging sponsorship and encouraging local DDs and users to turn up. Martin and I started early on Saturday morning, opening up the lab shortly before 9am and making a start on the RC bug list. Over the course of the next few hours, more people turned up and started work too - local DDs and a couple of Debian users from ETH. We worked our way through a fair number of bugs that day; personally I closed #389318 (a grotty FTBFS bug caused by IMHO a design mistake upstream - parsing header files using a simple awk script to create an m4 script to then generate C source) and spent quite some time digging into some other bugs. For our late dinner on Saturday, we headed to a local American-style bar/restaurant in Oerlikon called Cheyenne. Their speciality, it seems, is the "Big Mama", the largest burger I've ever seen! It comes on a huge serving plate, and is enough to feed up to 4 people...

I took the chance over dinner to chat with the small group of locals, especially Axel Beckert who had some interesting stories about Fedora, Opera and other groups. On Sunday, we started slightly later but probably had a more productive day in terms of the number of bugs closed. I fixed some silly FTBFS issues in ser: #384772 and #390008 were both caused by the build system assuming i386/amd64 compiler options. I adapted patches suggested by Julien Blache from his own work on openser (thanks!) and tested on my sparc and hppa systems at home. Job done... For the rest of the day, I used the time to work on remaining bugs in my own packages. Both CVS and debian-cd needed new uploads to be ready for the Etch freeze. CVS had a bucket-load of new translations following Christian Perrier's call, and debian-cd had a large number of bugs that had already been fixed in svn for a long time. Between those 2 uploads (and some other old bugs in debian-cd that needed reviewing) that made another 17 bugs fixed, although none of them were RC. Once those uploads were done, I continued on with my debian-cd multi-arch development work. On Sunday evening, we went into the middle of the old city centre in Zurich to a more traditional Swiss restaurant. Several of Martin's colleagues from the lab joined us, and we had some widely varying conversation, ranging from Debian (of course! *grin*) to gossip in the lab via lots of other topics. Due to my ridiculously early flight home on Monday morning we couldn't stay out too late nattering, but nonetheless all the people seemed to enjoy themselves. The Swiss group were a fair bit quieter then the Dutch the previous weekend, but seemed just as committed to getting work done and getting Etch out on time. It was lovely to meet and spend time with them, and I've promised to go back and visit again soon. Until then, I've put my small selection of photos online.

I somehow thought I usually was nice and helpful, however upon reading Marc's e-mail about trying to make exim4 a little bit more foolproof, I realized I was not. My gut reaction to the problem (people failing to check the docs at all) was a simple "So what? Either they'll learn the minimal basics. (Docs on Debian are in /usr/share/doc and reading them can be helpful.) or Debian is not for them. I sure won't be jumping through hoops for them." Lesson learned: I am just an elitist <insert favorite 4-letter word>.

I’m visiting my parents’ house in Vermont, where they finally got cable after the provider agreed to dig up the ground and run a mile or so of cable to their house in return for a two year subscription agreement. (I think after two years the cable company will almost have broken even on the cost of the installation). Having been absent myself from the cable world for some time, I am impressed by the variety of interactive and “on demand” options. My parents’ low-end package includes dozens of free on-demand movies and music videos, as well as built-in easy-to-use tivo-like functionality. The on-demand music videos show one brief ad before the video — it seems the tradeoff is that if you are really going to watch the ad, they can get more money and show you fewer ads. (Or, maybe I’m wrong — if it’s one ad per video, I suppose that would be more ads, but it feels like fewer because of the “on demand” nature. I guess it’s a perceptual trick.) Anyway, getting to the title of this entry. Anybody in the field of intellectual property these days has got to find Weird Al Yankovic’s music video for Don’t Download This Song (warning, myspace page, authorized by Weird Al!) (or, here) (warning, YouTube page, also authorized by Weird Al!) at least a little amusing. If you haven’t watched it, see it now. The opening verse goes like this:

Once in a while maybe you will feel the urge
To break international copyright law
By downloading MP3s from file sharing sites
Like Morpheus or Grokster, or Limeware or Kazaa
But deep in your heart you know the guilt would drive you mad
And the shame would leave a perminant scar
Cuz you’d start out stealing songs, then you’re robbing liquor stores
And selling crack and running over school kids with your car

On the cable video-on-demand channel, however, the names of all the filesharing services (Morpheus, Grokster, Limewire, and Kazaa), are all replaced with beeps, as if they were vulgarities unfit for broadcast. Or cable. If you had never seen the video online, you’d actually be likely to think this was another Weird Al joke — that he can’t even sing the names of (the mostly now defunct) filesharing services publicly. But I’m pretty sure the video was censored by the cable provider or distributor and the irony is wholly unintended. There are a couple of possibilities here. One is that the distributor was trying to avoid inducement liability under the Supreme Court’s decision in MGM v. Grokster. Could a funny song about filesharing actually meet the inducement standard? I sure hope not. The other possibility is that the distributor just found the references too abhorrent to leave in — basically the equivalent of the seven dirty words banned from broadcast TV and radio. Either way, if Weird Al were dead, I’m sure he’d be spinning in his grave. We’re lucky he’s still kicking. (“case” is kind of a misnomer for the title here, but is included for consistency).

Google Reader relaunched a few weeks ago, and for the first time since my initial foray into blogging with Radio Userland in 2003, I’m actually enjoying using an RSS reader. Why? River of news. Most feed readers inexplicably model the email workflow, presenting feeds like folders and feed items like messages. Given the state of most peoples’ inboxes, why on earth would you model email when you’re writing one of these things? Google Reader does river of news right. Simply click on “All items” and scroll through the items with the mouse wheel, clicking on the interesting stories (or reading them inline when the feed is full text). Google Reader takes care of marking the items read as they scroll past. Automatically. The praise doesn’t stop there. There are handy keyboard shortcuts (”n” for next item, “r” to refresh, etc.). Performance is excellent, as feed items are loaded on demand using AJAXy techniques. The look and feel is clean and simple, reminiscent of Gmail, down to easy to read timestamps like “9:53 AM (7 minutes ago)”; and, also like Gmail, there’s a mobile version. Intriguingly, you can sort by “auto” in addition to by newest, which presumably applies some sort of relevance algorithm to the feed items. However, it isn’t clear how it determines relevance (does it track my clicks as I scroll through the feeds, examine my broader search history, what?). Google Reader is a good platform citizen too. There’s a gadget you can add to your personalized Google home page, and gadgets, in case you missed it, are becoming full fledged web components as of last week. Oh, there’s an API too. Finally, in concert with Mozilla Firefox 2, subscribing to feeds finally no longer involves configuring a bookmarklet or, worse, the complex gymnastics of right click/copy link location/go to the appropriate URL/paste/subscribe. With Firefox 2, you can configure the feed subscriber to use Google Reader. As a result, you can now click on the feed icon in the address bar to subscribe to the site’s feed. In most cases, you can even click on a link to an RSS/Atom feed, for those sites that don’t have autodiscovery configured properly. My only complaint here is that it doesn’t remember that I want to subscribe in Google Reader; rather, it asks whether I want to “Add to Google Homepage” or “Add to Google Reader” every time. Ideally, it would show me a preview of the feed instead. I’ve seen Google Reader do that before, so perhaps it’s just a matter of configuring it to go to a different URL, though I’m not sure how to do that. So, what’s not to like here? As with most Google products, it’s not particularly well integrated with the Google platform. Indeed, in that particular post, I complained that there were three different ways of creating a bookmark in the Google platform. Well, there now appear to be four. If all of these mechanisms were integrated, that would be enormously powerful. See something interesting in the Google Reader? Click on the star and, optionally, add tags. See something interesting on the search results page? Ditto. See something interesting on a random webpage? Pull down a menu on the Google Toolbar and do the same thing that way. Want to add free form notes to any of the above bookmarks? Pop into Google Notebook. Naturally, all of these actions should result in the bookmarks/tags/notes/etc. being added to a single stream that can be shared with other users, with all of the resulting social network functionality. Etc. etc. etc. Sigh. I guess I have to be patient a little bit longer. Fortunately, Google sees the problem and is finally doing something about it.

Ian: I have to agree with you - Google Reader rocks. So far, I've been quite reluctant on putting more personal information in other entities hands than what is necessary - specially when those entities are, as Google, expert in exploiting whatever they learn about you. Call me a paranoid, a privacy freak, or whatnot, but after fooling around a bit on Orkut, I decided to withdraw all of my participation there (and never engaged on explicit social network sites ever again - Of course, my participation in several mailing lists is tracked by many Web searchers, and I'm sure I'm well categorized in non-explicit social networks - To say the least, my GPG key is in the Debian keyring ;-) ). I never got a Gmail account and hope I'll never have to - After all, gwolf.org gives me way more than 1Gb of space, is easily accessible and searchable (by me and only by me)... Why should I worry with that?
But, yes, Google Reader gave me something I didn't ever before have: The ability to read my RSS feeds from wherever, from whatever computer, without worrying about synchronizing. For the first time ever, I found my cell phone's uncomfortable, tiny but usable Web browser good for something - whenever I cross the city, I can do it reading news or my friends' life updates. That's quite cool, and that's the only reason I'm ditching Liferea.
But unlike you, I would prefer a more mailbox-like system on Reader. And having to use non-free software sucks, as there is no way for me to change this but to bitch around :) Why do I like to treat my feeds as mail folders? Because there is certain coherence between them. If I just "read all", I get a strange mixing of unrelated items. However, in Liferea, I went through each of my feeds, in order, unless (of course) I decided to jump to another one. And I can do the same in Reader, by clicking on each individual feed with pending items... But it's a manual operation, and those should be avoided. Liferea does support acting as Google Reader, when you click on the "all unread items" virtual folder, but the default style is just the other one.
Anyway... I know that overloading Reader with everybody's preferences is not an option. I know I am not like most Google Reader's users, and it sucks. I'll have to get used to the more regular style (or write an aggregator for myself and host it at gwolf.org or such), but I'm too tied with other stuff to give it a go. :-/
Besides, I like to complain.