Thanks to all that donated to the MS society in my name. Thanks to the generous donations and a match from Google I surpassed my goal and I may even get a cool bike jersey from the event. The actual ride was a lot of fun. The ride was very well supported. It felt more like 8 12 mile rides the first day instead of one 100 mile ride. The second day was even better. I managed to tag along with a group of cyclists from Deloitte who I could draft off of, for the second half of the ride, which made it very fast and a good learning experience. I have not had many opportunities to draft on rolling hills before.

The first day route had 7400ft of climbing over the 100 miles. The second day route had only 3500 over the 75 miles. However, by looking at the routes it is obvious that neither day was exactly the most direct route to the destination. Which is ok, I had all day to do the ride on each day and didn't have to turn around and ride home afterwards.

Speaking of afterwards, when I got back to AT&T park to pick up my stuff, I tried to ride back to my house. That was the slowest riding I have done for a very long time. The bright spot was I passed a couple of people starting on the wiggle, who did comment that everyone seems to be passing them :)

When the Debian installer starts, it will normally ask you what language you want to install in and gives you a really long list of languages to choose from. Unfortunately, that's not how it works when you install on a headless NAS device. The reason for this is that installations on NAS devices are done via SSH and the installer normally brings the network up after asking the user for their language. So we'd simply skip the language question and go with English. When Timo Jyrinki recently mentioned that he couldn't install in Finnish, Frans Pop pointed out that localechooser has changed a lot since etch and that it should now be possible to have the language question after setting up the network. This turned out to be correct and I managed to choose a different language but the installer still showed everything in English. Frans reminded me that the installer drops all translations that are not necessary but unfortunately this happens too early in our case. He pointed me to a variable that determines whether translations will be dropped. So in lenny translations will not be dropped on NAS devices that have enough RAM and users will be asked when they connect to the installer via SSH what language they'd like to install in.

Lennart Pottering’s post about the sound APIs available for Linux appears to have caused some consternation from people working with the modern out of tree OSS drivers who feel that the current, out of tree, OSS drivers are being unfairly maligned. This rather misses the point of his post. The fact that there are improved versions of the OSS code doesn’t really help developers who are trying to target current Linux distributions which only ship the old OSS drivers. From this point of view the new OSS drivers are probably best looked at as a completely different product. Joss is right, though - most applications should be working with a higher level user space API than either ALSA or OSS. One of the most obvious examples of this is in the embedded space where there are often vast numbers of controls that need to be exported in order to support the complex audio routing that devices like phones can have. Most of these should only be touched very occasionally when changing use case and should therefore be hidden from normal applications where they’re at best irrelevant and at worst confuse end users. They do, however, need to be exposed by the kernel in order to allow user space the flexibility to manage the audio configuration of the system at run time.

After Lennart posted his summary of Linux sound APIs, the debate heated up again between ALSA and OSS zealots. Both ALSA and OSS developers think their API is the definitive interface for sound support in Unix and like to bash each other, and tell how the other API sucks and how the others are spreading FUD. This is not only a sterile debate, but it is completely irrelevant. Do you know why? Because neither of them is a suitable sound API. Technical constraints, functional requirements and history make the ideal sound stack on Linux look like the following:

• a sound driver, consisting of a kernel module and if necessary a low-level library
• if configured so, a sound daemon which brings software mixing and network support PulseAudio finally kicking out all crappy alternatives
• a high-level programming API for use by developers.

Only the last bit should be of interest to application developers. Everything else is plumbing. When you develop a multimedia application or a mixer controller, why would you care of the insanely complex ALSA library or to make ioctls somewhere in /dev when GStreamer and Phonon provide you with high-level functions that can do it in a snap? When you want to insert sounds in your game or application, why would you care of those bits when, with SDL_Mixer or libcanberra, a single line of code is enough to decode and play the sound? If we want to see sound working properly under Linux, we need to keep the stack simple and to clearly separate the roles. In the end, this boils down to very simple things:

• Application developers must stop using ALSA and OSS. Both of them are completely unsuitable for the task, and it only serves the purpose of letting ALSA and OSS developers troll. Whichever application you are writing, there is one of the high-level frameworks SDL, GStreamer, Phonon, libcanberra, KNotify, JACK that is better.
• OSS and ALSA should stop trying to be application-level APIs. Instead of trolling about which API is better, they need to write drivers so that sound fucking works instead of asking users to use Windows to see their brand new computer output some sound.
• The plumbing layers (backends for the high-level APIs and PulseAudio) need excellent support for both ALSA and OSS. In the end, what matters is to have a driver for your sound card and to have it usable by all applications. Keeping the driver layer independent from the sound API is the only reliable way to keep things working over time. If someone else starts writing yet another driver framework, we will be able to make applications use it, instead of adding yet another ton of compatibility stacks.
• In the end, compatibility layers that cross layers in the stack must disappear. ALSA emulation for PulseAudio? OSS emulation with a LD_PRELOAD hack? Seriously, WTF? Applications should not have used them as a sound API, and we need to trash this crap eventually.

Please, guys, hold off a minute. You are developing drivers and you must be praised for that. Keep doing that well, and stop trying to invade applications. There are people who may not know how to develop a driver, but who obviously know better what a sound API should look like.

Dear Adrian, I can only but complain about the "Guide Through The Linux Sound API Jungle" that you mention in your last post. All that is said there about OSS is pure FUD and only reflects a deep ignorance of the current project. It is a pitty to spread misinformations that deprecate the work of others without even trying to understand it. Here is what is said about OSS in this document:

The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.

And here is what one of the devs from OSS answered to this [1]:

It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's author, right? I'd have expected him to know better). He's basically judging OSS per the old OSS/Free drivers, which is like 5 years ago, and even that he does wrong. First, *all* current implementations/emulations of OSSv3 do sample conversion. It's not even a property defined by the API but by the underlying drivers. Second, even OSSv3 supported surround, USB cards, etc. Third, arguing that "it cannot be virtualized" is disproven by the amount of emulations and alternative implementations existing out there and working in practice. (The main difficulty is mmap() API, which is very rarely used anyway, and even that can be done with, say, oss2pulse). Fourth, complaining about OSS API being awkward, is... well, awkward when you compare it to ALSA API, if you could compare it, since most ALSA API isn't documented. It's kinda funny he advocates using ALSA API (not in the quoted part above, but last time I read his blog he suggested it). Actual ALSA devs advocate against it, but using a sound library with multiple backends [2].

If you read some documentation, you can understand that OSS has been the target of some kernel developpers that didn't like it to be reused in a commercial product, back in the 90s. Hence, ALSA was launched, and OSS was progressively discarded, while constantly being the target of FUD like this. OSS has then lived for almost 10 years in the dark side of the force, but eventually did the way back in July 2007. Ironically, now most of the developpement in the linux kernel is driven by commercial interests. Most of the original complains about OSS are now fixed, including all the FUD written in this guide. In particular, software mixing is now supported. Being also part of a project that writes code to handle sound input and output, I can only but complain about the mess in the area of sound APIs in linux. However, OSS should really be reconsidered. In particular, its API is designed in order to abstract as much as possible access to the sound card, so that application writers have as less as possible to do with sound conversion and the like Those who have tried to use ALSA may for instance compare that to the "set rate near" call in its API: this call will set the rate to what the hardware support and let you handle the conversion... For each application... Also, OSS API is available across all unices, except OSX, and there is even a BeOS port going on. Finally, OSS API is POSIX oriented, reading and writing on the sound card, being a matter of calling few ioctls and then reading from the device file. In the future, OSS developpement will most probably be done as a community project, and I believe it is now time to stop spreading false ideas about the project, and give it as much attention as the other projects. For the debian users who want to try OSS4, a package is available in the packaging team's svn repository. It has been sitting in NEW for some time, I hope it gets accepted at some point.

DISCLAIMER: Paranoid rant ahead. You ve been warned. Every two years, around this time of the year, I feel concerned: it s voting time in Brazil. For quite some time now, Brazil has had electronic voting, but that doesn t make me more confortable with it. Yes, having the results within the same day is an enormous advantage, but I am not sure about the security of the whole process. You can call me paranoid (and surely I am a bit), but there are some things that give me the creeps about it. For a start, let s look at the operational process. The voting machines are certified and sealed by Electoral Justice officers the week before the voting. They are opened in the electoral section by those officers in the presence of common citizens. Those citizens are called to work in the Electoral process usually for four or five elections in a row, being replaced after that by newcomers . The voting machines are not connected to any network. During the day, voters come with the voting document (voting is mandatory in Brazil), one of those citizens enable the voting machine by typing the document unique number in it, the voter give his vote and go home. Then the voting machine is unable to receive votes if not enabled by entering another document number, and it goes on and on the whole day long (pretty boring work ). At the end of the day, the president of the section (usually the most experienced of those citizens) close the voting machine, prints a tally sheet , hand a colored 3 -inch floppy disk to the Electoral Justice officer with the votes and go home. Other officers will pick up the voting machines later on. The first officer then goes to the voting processing central of the Electoral Justice and within hours we will know the result of the election. As you can see, there are lots of points of failure in the whole process! All this sealing of voting machines are just a matter of trust. First point: there s no way we can know for sure if the machine does what it s suppose to do. Even if officers say that they randomly choose machines to be tested, there s no way to know how random is that. There s a report [pt-BR] made by a prestigious university (English summary here), stating that 1/3 of the voting machines in a particular studied state had corrupted log-files (among other important security problems!). This study also showed differences in the countings (sometimes as large as 20-thousand votes!)... Hey! This is supposed to be a deterministic system: if nothing in the conditions changed, counts should always match! Until recently, closed-source software were used in the voting machines, but that has changed recently. I doubt that it makes any difference, since we ll never really know what is actually running in the machine. Surely, Electoral Justice officers know (or should know), so we d have to trust them So second point: we don t know how the voting is processed within the machine. (Also, we don t know for sure the machine doesn t have a network connection. It may have a wireless connection we don t know about and can be passing all the votes to someone else, or even receiving instructions But since that can be spotted with a scanner, I ll trust other paranoids have already done that.) Surely the machine must be enabled before every vote with the voters document number. If it were not, how could we know that no one voted twice, or that a non-voter have voted? But we don t know how the machine records that! Third point: we cannot know if the voting machine database doesn t link the voter to the vote. That is a nasty one it opens up the possibility of voting by intimidation . Also, the tally sheet that is printed at the end of the day only brings the total of votes, the total of absent-voters, and the votes each candidate (or party) have received. So, on to the fourth point: there s no way of knowing for sure that your vote was counted right (or was counted at all!). At least a copy of this tally sheet is glued at the entrance of the voting section, so an independent audit only on the numbers is do-able (although hard to do!). What happens to the colored disk between the voting section and the voting processing central is not known. It goes with the officer and what he does with it is just a matter of trust. Now for the most insteresting point: the security is based on the color of the disk!. The Electoral Justice checks if the officer handed the right colored disk and puts the data in the system. Surely (?) they might have some way to check data integrity other than that On the same issue, maybe even worse: even if the disk is not tampered, but just read (or copied) by the officer before being handed, and if the database links the voter to the vote, this information is valuable, and may be sold. Finally, since we don t know (and have no way to know for sure) what the machine does, we don t know if the machine keeps a copy of the voting database in it. So when it is taken back by other officers, we cannot know whether the same thing that may happen to the disk also could happen with the machine. I am missing a lot of things about the whole Brazilian E-Voting process, and also I surely have missed other points of failure. I heard of fraud in the past, with paper ballots, and those were pretty nasty frauds. But this whole tale of impossible fraud in e-voting is nothing but a tale (as fraud is more than possible!). I think we have to begin investigating other systems, surely with cryptography involved. A system like Debian s, far from perfect (we all have to trust secretary s word on the secrecy of the voting system key), is much better, for instance. I understand that it s not simple enough for non-geeks, but there might be a way! It doesn t need to be a whole new system! I would be happy if, as an example, the tally sheet printed a hash of my vote that I could verify later on or if the security of the disk is not just color-based or if the tally sheets had a way of being validated and be available on-line for auditing (and not just glued at the entrance of every voting section). Look! I am not distrusting any officer a priori... I think the message is auditing should be made easy... then I could trust a version of Linus s Law adapted to E-Voting: Given enough eyeballs, all frauds can be discovered .

I wrote before about datapacker, but I didn't really describe what it is or how it's different from other similar programs.

So, here's the basic problem the other day. I have a bunch of photos spanning nearly 20 years stored on my disk. I wanted to burn almost all of them to DVDs. I can craft rules with find(1) to select the photos I want, and then I need to split them up into individual DVDs. There are a number of tools that did that, but not quite powerful enough for what I want.

When you think about splitting things up like this, there are a lot of ways you can split things. Do you want to absolutely minimize the number of DVDs? Or do you keep things in a sorted order, and just start a new DVD when the first one fills up? Maybe you are adding an index to the first DVD, and need a different size for it.

Well, datapacker 1.0.1 can solve all of these problems. As its manpage states, "datapacker is a tool in the traditional Unix style; it can be used in pipes and call other tools." datapacker accepts lists of files to work on as command-line parameters, piped in from find, piped in from find -print0. It can also output its results in various parser-friendly formats, call other programs directly in a manner similar to find -exec, or create hardlink or symlink forests for ease of burning to DVD (or whatever you'll be doing with it).

So, what I did was this:


find Pictures -type f -and -not -iwholename "Pictures/2001/*.tif" -and \
-not -wholename "Pictures/Tabor/*" -print0 \
datapacker -0Dp -s 4g --sort -a hardlink -b ~/bins/%03d -


So I generate a list of photos to process with find. Then datapacker is told to read the list of files to process in a null-separated way (-0), generate bins that mimic the source directory structure (-D), organize into bins preserving order (-p), use a 4GB size per bin (-s 4g), sort the input prior to processing (--sort), create hardlinks for the files (-a hardlink), and then name the bins with a 3-digit number under ~/bins, and finally, read the list of files from stdin (-). By using --sort and -p, the output will be sorted by year (Pictures/2000, Pictures/2001, etc), so that photos from all years aren't all mixed in on the discs.

This generates 13 DVD-sized bins in a couple of seconds. A simple for loop then can use mkisofs or growisofs to burn them.

The datapacker manpage also contains an example for calling mkisofs directly for each bin, generating ISOs without even an intermediate hardlink forest.

So, when I wrote about datapacker last time, people asked how it differed from other tools. Many of them had different purposes in mind. So I'm not trying to say one tool or the other is better, just highlighting differences. Most of these appear to not have anything like datapacker --deep-links.

gaffiter: No xargs-convenient output, no option to pass results directly to shell commands. Far more complex source (1671 lines vs. 228 lines)

dirsplit: Park of mkisofs package. Uses a random iterative approach, few options.

packcd: Similar packing algorithm options, but few input/input options. No ability to read a large file list from stdin. Could have issues with command line length.

Write your own launcher I am at OpenExpo and while chatting about KDE 4.1 with the nice people at the KDE booth, I realised that some of the Debtags Technology could be used to make a really good application launcher. After a bit of prototyping, I present you the Application Launcher Startup Kit:

git clone http://people.debian.org/~enrico/2008-09/launcher

There are two python scripts in it: index that indexes your existing .desktop files in a Xapian database, and query that contains a function to query the index, and when run with the query keywords as parameters, it shows the results. You give it a list of terms (and possibly of currently selected categories), and it gives you:

• Spell checking suggestions
• Tag cloud generation
• Completion support
• Search results

It's more than fast enough to do all of this in real time, as the user types. For example, on my system:

$ ./query imag
Found: 55 /usr/share/applications/gqview.desktop
Found: 51 /usr/share/applications/gimp.desktop
Found: 48 /usr/share/applications/gpicview.desktop
Found: 46 /usr/share/applications/camorama.desktop
Found: 44 /usr/share/applications/inkscape.desktop
Found: 42 /usr/share/applications/geeqie.desktop
Completion: image
Completion: imagemagick
Completion: images
Tagcloud: 2DGraphics 0.661410884419
Tagcloud: Application 0.489939013302
Tagcloud: Core 0.331070153265
Tagcloud: GTK 0.158799073563
Tagcloud: Graphics 1.0
Tagcloud: Photography 0.426417355406
Tagcloud: RasterGraphics 0.661410884419
Tagcloud: Utility -0.3383614892
Tagcloud: VectorGraphics 0.213729717371
Tagcloud: Video 0.364913248472
Tagcloud: Viewer 0.806009703748
Spellchecked: image
$ ./query word proc
Found: 100 /usr/share/applications/ooo-writer.desktop
Found: 69 /usr/share/applications/efax-gtk.desktop
Completion: word processor
Completion: word processors
Tagcloud: GTK -0.255400677833
Tagcloud: Office 1.0
Spellchecked: 
Spellchecked: doc

Now, it's just a matter of putting a GUI on top of it. I am not going to do it: that is up to you.

Russell writes about the iphone. I think he's missing a few things.

The open nature of the PC wasn't inherently what brought it greater success. The open nature of the PC meant that it could spawn an ecosystem of third party hardware vendors, sure. It also meant that it could be cheaply cloned by other manufacturers, ensuring competition that drove down the price of hardware. The net result? x86 is ubiquitous, sufficiently so that even Apple use a basically standard[1] x86 platform these days. Low prices and the wide availability of software that people wanted to run bought the PC the marketplace, with Microsoft being the real winners. Apple hardware remained more expensive for years, and the compelling MacOS software was mostly limited to areas like DTP. Nobody else had any incentive to buy a Mac.

Now, let's look at the phone market. Third party hardware vendors? No real distinction between the iphone and anything else. Sure, anything remotely clever has to plug into the dock port, but developing something to work with that also gets you into the ludicrously huge ipod market. Other phone accessories are either batteries, chargers or headphones. That's really not going to be what determines market success.

Competitive cheapness? When you have a multivendor OS like Android or Windows Mobile, you might expect there to be more opportunity to compete to undercut each other, offering equivalent platforms for less cost. But that's missing something. In the same way that the home computer market has basically consolidated towards PCs, the phone market has already consolidated. Your smartphone has an ARM in, probably along with an off the shelf GSM chip and some 3D core (generally something from Imagination, though in Android's case Qualcomm seem to have come up with their own core - I haven't been able to find out if it's derived from something else). There's no realistic way to make a phone with equivalent hardware functionality and quality to the iphone and sell it for significantly less money. And if you figure out how to, Apple get to take advantage of the same price reductions in their next generation hardware. And, being Apple, they'll probably find some compelling wonderful design feature that costs them nothing extra but makes you want it more anyway. So hardware competition probably isn't going to be what determines market success.

Which leaves two things - advertising and applications. Apple are good at marketing. This is unfortunate, because I'd really rather live in a world where everyone running MacOS was running Linux instead, but we seem to suck in comparison. The good news is that Microsoft also seem to, so maybe we'll have our act together some time between now and Apple crushing us to death. So, assuming current trends continue, Apple's marketing probably isn't going to kill the iphone. Which leaves one thing: applications.

The obvious argument against the iphone's success is that, as a closed software distribution platform, it's less attractive to developers. I don't think that's true. If we look at the console market, the gp2x was hardly a PSP killer. Or a DS killer. You could possibly argue it was a Gizmondo killer, but only if you ignore the Finnish mafia. Being an open platform doesn't immediately result in you killing closed platforms. You need developers, and you need applications. Otherwise nobody's going to buy your hardware, even if it costs $10 less than an iphone and has a few extra bits of plastic. What attracts developers? An attractive development environment and a revenue stream. Android has one real thing going for it here - it's not tied to Objective C, and so there's probably a larger number of potential developers. But let's be realistic. If you're a competent developer, you can move from C++ or Java to Objective C without too much effort. And if you're an incompetent developer, you're not going to be deciding the future of a platform.

Apple have made it easy for people to write applications that share the iphone's delightful[2] UI. There's almost active encouragement to write beautiful programs that integrate well. Sure, the platform limitations bite you in weird ways (like the no background running thing), but Apple have come up with hacks to smooth most of those over. The iphone is a wonderful device to develop for. Sufficiently delightful that there was a huge developer base even before Apple had released the SDK. What does that tell you? Developers actively want to write for the iphone. In fact, they wanted to even before there was a real revenue model. Mindshare means a lot.

What are we going to see in response from Android? To begin with, uglier applications. I'm sure that'll get better over time, but right now the Android UI just isn't as well put together[3]. It's functional, even attractive. But it's not beautiful. And lowering the bar to developer involvement means the potential for more My First Phone Application. Windows Mobile and Symbian have huge numbers of applications. They're mostly dreadful lashups of functionality you'd never want and a UI that's ugly enough to make you want to stab out your eyes, coupled with a nag screen asking for a $10 donation to carry on using it assuming it hasn't crashed before it got that far. To be fair, a lot of iphone stuff isn't much better. But proportionately? Right now the Apple stuff has it. I never want to see another listing of Symbian freeware.

At the moment, Apple wins at providing compelling applications. They may be a gatekeeper between the developer and the user, but right now that's not causing too many problems. Well. It wasn't. The recent fuss about Apple dropping applications because of perceived competition with their own software is an issue. If a developer is going to spend a significant amount of time and money on an application, they want a reasonable reassurance that they're going to be able to ship it. And, right now, Apple's not giving that. It remains to be seen whether this has long term consequences, but there's some danger of Apple alienating their developer base. If those developers move to another platform, and if they create compelling software, Apple might stand some real competition. At the moment? Apple has the hardware, the OS and the applications. They have the potential to take over broad swathes of the market. But they also have the opportunity to throw it away. And that's what's going to decide the success of the iphone - a closed platform is not inherently a problem, but it gives the vendor the option of removing one of their key advantages. If Apple get through this with their developer popularity intact, I don't see the open/closed distinction as having any real-world importance at all.

The relevance to Linux? We're not going to succeed by being philosophically better. We have to be better in the real world as well. Ignoring that in favour of our social benefits doesn't result in us winning.

[1] It's slightly more legacy free than a "genuine" PC - there's no i8042, and things like the gate A20 hack aren't implemented. But it'll boot DOS (given enough effort), so hell, it's a PC

[2] And yes, I genuinely do think that the iphone's UI is better than anything else on the market. There's no reason someone else, including us, couldn't have got there first. But we didn't, and now everyone gets to play catch up. Shit happens

[3] I have no idea where Apple gets its UI engineers from, but someone needs to find the source and start waving huge piles of money to pick them up first.

I was invited to participate at Festival Internacional de Software Libre (FISOL), in Tapchula, Chiapas. The other invited speakers were Sandino Flores (tigrux), Alexandro Colorado (jza), Eric Herrera (crac), John Hall (maddog) and Fernando Romo (pop), all well-known due to very different contributions to the Free Software movement in Mexico and abroad. Several other people also presented tutorials, but I was not involved in that part, and mentioning one while not the rest would be unfair.
The conference was quite massive - Tapachula is a medium-sized city (~200,000 people) in Mexico's Southernmost point - Sadly, due to its geographical location, it is mainly famous for being the region where illegal immigrants from Central America enter Mexico towards the USA, and it is a known spot for all kind of abuses, both from the authorities and from gangs of thieves.
This is the third time I come to this conference. The first two years (2005, 2006) it was organized by the local CUCS university and it was reasonably large, but this year it counted also with many other universities in the region. Attendance was... HUGE. We were told around 1600 students were registered to participate, and I expect at least 1000 to have actually been there. Very amazing and encouraging!
It is, by far, a base-level conference - Most attendees had had no previous contact with Free Software at all, or had at most toyed around with a distro for some hours. Some people, of course, _are_ already working and involved, on various different degrees. All in all, quite encouraging.
But not only I had fun (and got extremely tired!) at the conference, or at the beer sessions afterwards. I also got to push some more publicity (and work, of course!) towards my new favorite pet project: OpenStreetMap.
As many other Debianers, I joined the fever last August, during Debconf. So far, I have been quite busy tracing and mapping; I am quite fortunate to get the OSM addiction while living on the edge of the well-mapped area of Mexico City. So far, I have mostly worked on the Ciudad Universitaria and Coyoac n areas, where some sensible improvement can be felt. Lots yet to do, for sure, but I'm making progress.
Still, mapping Coyoac n sometimes feels a bit futile. Why? Because all of my cycling/tracing/mapping sessions look almost like a little blip on the overall state of my city, which is way better than what I expected - Most of the central city is done (although lots of work is still pending on the very large outskirts - but getting there can be a trip just by itself!)...
But this time, I had the opportunity to do something new, something better and sensible. And, yes, it feels very good. How does the map of Tapachula look for just a weekend of mapping activity? And, yes, I only went out once (morning running) expressely to get some new traces, the rest of it was while being transported by car to the conference-related activities. And I didn't even have to say once "lets go by a different route"! ;-)
Just for comparison: Last week, Tapachula's state was quite similar to what they have today on Google Maps - Just the major highways in the area. Besides, if you look at the satellite map for Tapachula, I estimate I managed to map around between a fifth and a tenth of the city's surface.
So, have you got a GPS? Do you enjoy going out on the street, be it walking, running, cycling on driving? Or even if you don't enjoy it, are you sometimes forced into it? Start contributing to OpenStreetMap now!

As I wrote in blog item 29 there are many ways to break your debian/rules file. As I grew of seeing those and many more, I decided to write a lintian test for this. Getting that finished will still need several days, as the general Makefile syntax is quite intresting in detail, and lintian is written in perl thus so have to be tests. It's quite intresting that the different cases when variables are resolved and when not seem to quite firmly force an specific way to parse it. (And relearning perl when I so successfully unlearned all parts of that language in the past make it not much faster). Anyway, the reason I'm blogging is to give you already the results of one particular test a preliminary version gave when running over the lintian lab: It's checking for targets with -stamp in them that are phony, as that makes no sense. It will either cause configure or make run multiple times via build, wasting buildd cycles or even make the build more unstable, or just indicates needlessly complex Makefiles (having an install target that invokes an install-stamp target that does not actually produce a stamp file just makes the Makefile longer without doing anything at all but confusing readers). You can find the preliminary results for that test at http://people.debian.org/~brlink/debian-rules-phony-stamp-file.log. I looked at some randomly choosen results and did not find a false positive. As that list was produced by the last runable version which did not yet look at variables, I guess the list will only increase.

Thanks to Wolfger for pointing out an HTTP 500 while trying to greet me by comment. :D I totally forgot about upgrading Net::Akismet to the new version that comes with my patch, as described previously. All the while I was thinking Net::Akismet was doing too good of a job keeping out comment spam, when it may as well have kept out all comments :( But its my fault, really. Among other things, Jerome has finally started a new grassroots group for the OLPC effort here in the Philippines, fresh from the success at the recently-concluded SFD. There's now an IRC channel up too, with logs available locally (text-only, until I can set up a web and fileserver frontend.) I'm personally interested on running a port of Inferno and perhaps help out on the TODOs for it.

I don’t have the expertise to intelligently explain the entire global financial meltdown myself, but here are a few resources that merit wide dissemination, especially if you are a podcast-listener:

• The Planet Money Podcast. NPR’s Adam Davidson hosted one of the most memorable episodes of This American Life on the Giant Pool of Money (complete PDF transcript). He has springboarded that show into a frequent short podcast in these times of peril. He finds a near-perfect balance between accessibility and complexity for a non-specialist but educated audience. It’s also entertaining. Of all major media outfits, NPR is miles ahead on the podcast front.
• Paul Krugman’s blog. Admittedly on the partisan side (”Conscience of a Liberal”), Krugman’s analysis is deep both on politics and economics. Steve drew my attention to this excellent illustration of the flaws with the current approach to bailout:

Tomorrow, a long bus ride to the capital of the Czech Republic will set off the last trip together with my high school classmates before the final exams in spring. We are to leave half an hour past 6am local time; I m surprised to find that my alarm watch can be configured to get on my nerves at five o clock in the morning. Until Friday, instead of connectivity I will have medieval buildings and woozy-for-some-reason teenagers all around me, so please don t expect me to reply to mails before Saturday. I ve been really looking forward to these holidays for weeks (hint: the school year started a fortnight ago). So glad they re finally here! PS: I m going to miss the party, so allow me to pre-congratulate 500000-submitter and the prospective winner of the contest. Cheers!

Just stumbled over this meme at Adrian (the meme seems to be started by madduck involuntarily), and since I’m fascinated by how people choose hostnames since my early years at university, I can’t resist to add my two cents to this meme. To be exact, I have two schemes, one for servers out there somewhere (Hetzner, xencon, etc.) and they’re all wordplays on their domain name noone.org, e.g. symlink.to.noone.org (short name “sym” :-), gateway.to.noone.org (usually an alias for one of the machines below), virtually.noone.org (always a virtual machine, initially UML, soon a Xen DomU), etc. So nothing for a quiz here. My other scheme is for all my machines at home and my mobile machines. I’ll start this list with the not so obvious hostnames, so the earlier you guess the scheme, the better you are (or the better you know me ;-). One more hint in advance: “(*)” means this attribute or fact made me choose the name for the machine and therefore can be used as hint for the scheme. :-)

azam

My first PC at all, a 386 with 25 MHz and MS-DOS. (Got named retroactively(*). Hadn’t hostnames at that time.)

ak (pronounced as letters)

Got it from my brother after he didn’t need it anymore. It initially was identical to azam, but once was upgraded to a 486. Still have the 386 board, though.

azka

My first self-bought computer, a pure SCSI system with a AMD K5-PR133 and 32 MB RAM. Initially had SuSE 4.4 and Windows 95 on. Still my last machine which had a Windows installed! :-)

m35

Same case and same speed as azka. Used it for experimenting(*) with Sid years ago.

azu

Initially also an AMD K5-PR133, later replaced by a Pentium 90 and used as DSL router.

azl

An HP Vectra 386/25N book size mini desktop I saved from the scrapyard at Y_Plentyn before his (first) move to Munich. The cutest(*) 386 I ever saw.

ayce

A 386 with 387 co-processor(*) and solded 8 MB of RAM.

ayca

A 1992 Toshiba T6400C 486 laptop bought at VCFe 5.0.

bijou

My 1996 ThinkPad 760ED, which is still working and running Debian GNU/Linux 5.0 Lenny (I started with Debian 3.0 Woody on it and always dist-upgraded it! :-)

gsa (pronounced as letters)

My long-time desktop after azka. A Pentium II with 400 MHz and 578 MB of RAM at the end. Bought used at LinuxTag 2003, it worked until end of last year when it started to suddenly switch off more and more often and now refuses to boot at all. Hasn’t been replaced yet though. I mostly use my laptops at home since then.

gsx (pronounced as letters)

An AMD K6 with 500 MHz I got from maol and which was used as Symlink test server more than once. (It was the machine initially named symlink.to.noone.org because of that.)

hy

My 32 bit Sparc, a Hamilton Hamstation.

hz (pronounced as letters)

My 64 bit Sparc, an UltraSparc 5.

tub

An HP Apollo 9000 Series 400, model 400t from 1990.

tpv (pronounced as letters, too ;-)

My Zaurus SL-5500G.

tryane

A Unisys Acquanta CP mini desktop with a passively cooled(*) 200 MHz Pemtium MMX. Used as DSL router for while, but the power supply fan was too noisy.

lna (pronounced as letters)

A 233 MHz Alpha

loadrunner

An IBM ThinkPad A31 running Sid. I use it as beside terminal.

pony

A Compaq LTE5100 laptop with a Pentium 90 running Sid.

dagonet

A Sony Vaio laptop which ran Debian GNU/kFreeBSD until it broke.

Those who know me quite good should already have guessed the scheme, even if they can’t assign all the names. For all others, here’s one name which doesn’t exactly fit into the scheme, but still is related in someway, but you need to knowledge of the theme’s subject to know the relation:

colani

A big tower from the early 90s designed by Colani.

Ok, and now the more obvious hostnames:

rosalie

A very compact Toshiba T1000LE 8086 laptop running ELKS and FreeDOS.

amisuper

Also an old Symlink test server from maol. He named it “dual”. 2x(*) Pentium I with 166 MHz. Unfortunately doesn’t boot anymore.

visa

An IBM NetVista workstation running Debian GNU/kFreeBSD. My current IRC host.

nemo

My ASUS EeePC running Debian 5.0 Lenny.

pluriel

My current WLAN router running FreeWRT.

c1

My MicroClient JrSX, an embedded 486SX compatible machine with 300 Mhz for VESA mountings.

c2

My MicroClient Jr, an embedded Pentium MMX compatible machine with 200 Mhz for VESA mountings.

c-crosser

My Lenovo ThinkPad T61 running Debian 5.0 Lenny.

c-cactus and c-metisse

The KVM based virtual(*) machines on c-crosser running Sid and Debian GNU/kFreeBSD.

jumper

My NAS(*) at home, currently a TheCus N4100. Soon to be replaced by some Mini-ITX box.

Any one who hasn’t guessed the scheme yet? For those understanding German it’s explained at the end of my old hardware page. For all others I suggest either to look at the domain name in my e-mail address (no, it’s usually not noone.org). Still not clear? Well, feel free to ask me for all the gory details or mark the following white box to see the scheme as well as the explanations for nearly all hostnames hidden in there:

All the machines are named after Citroëns. Old machines after old Citroëns, current hardware after current Citroën models or prototypes. Those names starting with “A” are 2CV derivatives since the 2CV was Citroëns “A” model. “AZ” was the 2CV, AZU and AK were 2CV vans and everything starting with AY (e.g. AYA, AYA2, AYB – but those don’t sound that nice ;-) is Dyane based, but I currently only use Méhara names (AYCA is the normal Méhari, AYCE the 4x4 version). Interestingly not everything starting with AYC is a Méhari: AYCD was the Acadiane, the Dyane van. HY and HZ are variants of Citroëns “H van” (HX, HW and H1600 as well, but they don’t sound that nice), TUB was the pre-WWII “H van” prototype and later the nickname of the “H van” in France. TPV was the name of the pre-WWII 2CV prototype and an abbreviation for Toute Petite Voiture (French for “Very Small Car”), hence the Zaurus, my smallest Linux box, got that name. Rosalie was the nickname of a rear-wheel drive pre-WWII Citroën. M35 was a Wankel engine prototype of the Ami 8 and the Ami Super was the 4 cylinder version of the Ami 8. Bijou was a 2CV based coupé build by Citroën UK in the late 50s and early 60s. Visa and LNA were 2CV predecessors which were available with 2CV engines, but were stopped before the 2CV. GSA and GSX are GS late derivatives. C1, C2, (C3) Pluriel, C-Crosser, Jumper and Nemo are current Citroën models and C-Cactus and C-Métisse are recent Citroën prototypes and show cars. The 2CV Dagonet was an aerodynamically optimised 2CVs by Jean Dagonet in the 50s. The Tryane is an aerodynamic and fuel efficient, three wheeled car by Friend Wood based on the 2CV and with a body of wood. And Colani once dressed a 2CV so that it broke several efficiency world records. The Namco Pony was a 2CV based light utility truck (similar to the Méhari, but with steel body) built in Greece under license in many variants. And Loadrunner is the name of some CX six-wheeler conversions.

Some links about the naming items:

• Tryane II
• An original Loadrunner and a just recently built Loadrunner. I even saw the base of exactly that one in RL shortly before it was converted into a Loadrunner.
• Luigi Colani
• Dagonet
• Namco Pony
• C1, C2, C-Crosser, C-Cactus, C-Métisse, Pluriel, Nemo, Visa, LNA, GSA, Ami Super, Rosalie
• AZAM, AZL, AZKA, AZU, AK, AYCD, Bijou, TPV
• HY, HZ, TUB.

Hope you had fun. I had. ;-)

Now playing: Willi Astor — Gwand Anham Ära

I went to this event a few weeks ago. The immediate outcome is the call for expressions of interest in RISE-SW’s projects. The deadline is next Monday (29th September) at 12 noon, so get emailing if you’re interested in them. After that, shortlisted EoIs will get two weeks to write a full bid. I’ve asked for a non-Microsoft copy to be posted. Microsoft is a social problem, not a social enterprise. The consultation event was a pretty straightforward introduction and discussion in small groups, followed by feedback to the whole group, with lunch to finish. The host was Gareth Hart of Perfect Moment (yet another non-SE hired by RISE instead of SE providers?). First, the introduction covered the CapacityBuilders Social Enterprise Programme, the context of the programme and RISE’s suggested themes for support: accessibility of SE support, better opportunity for the Voluntary and Community Sectors to be more enterprising, improving SE quality standards and organisations, making SE infrastructure sustainable, and developing more peer-to-peer SE support and mentoring. In the discussion that followed, I think the standards and sustainability themes were largely kicked into touch as unachievable with the available budget, while we felt peer-to-peer support was better as part of the more general accessibility and opportunities themes. My personal pet points were that if the Social Enterprise Mark is funded, it should benefit small SEs rather than RISE, and that if another database or directory is funded, it should be Open in licence and maintenance, like ODP and unlike previous directories which have wasted government money. I’ll be interested to see how that’s reflected in the Call for Expressions when I get to reading it this week.

After a short discussion time, my proposals have been ACK'ed and we will have 63 languages supported, including English, in Debian Installer for Lenny. Etch had 58 supported languages. The final winners are (alphabetical order of ISO code): Amharic, Arabic, Belarusian, Bulgarian, Bengali, Bosnian, Catalan, Czech, Welsh, Danish, German, Dzongkha, Greek, English, Esperanto, Spanish, Basque, Finnish, French, Irish, Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian, Italian, Japanese, Georgian, Khmer, Korean, Kurdish, Lithuanian, Latvian, Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch, Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese, Romanian, Russian, Northern Sami, Slovak, Slovenian, Albabian, Serbian, Swedish, Tamil, Thai, Tagalog, Turkish, Ukrainian, Vietnamese, Wolof, Simplified Chinese, Traditional Chinese Newcomers for Lenny are: Amharic, Welsh (back), Irish, Marathi, Northern Sami, Serbian We lost Estonian which was in Etch. Those that missed the deadline are of course all other languages of the world. We will put focus on languages where an effort started at some moment but could not be complete enough: Afrikaans, Estonian, Persian, Armenian, Icelandic, Kazakh, Kannada, Kashmiri, Lao, Malagasy, Malay, Sanskrit, Secwepemctsin, Telugu, Urdu, Xhosa Many thanks to all translators for this final effort. Thanks also to all people who urgently popped up last week to complete the translations for languages that were "orphaned". I hope this will bring us more translators...:-) I keep special thanks to Frans Pop here. He is, along with me, the author of the code that allows us to split D-I translations in "sublevels", allowing translators to focus on the most "important" messages. He also implemented prior warnings when users pick up a language where some less important screens aren't translated. This also allows us to more easily keep partly complete translations, or activate languages earlier. Without this, 11 languages should have been dropped.

Lately following the US elections (and lately the finance collapse) is an interesting thing, I have been watching the following (in the order of importance):

1. NBC Nightly News
2. NBC Meet the Press
3. NBC Countdown
4. The Daily Show/The Colbert Report

Additionally, if you watch it in this order, the fear and maybe even panic that sets in watching the news is slightly relived by the common sense and a bit of humor. And to the people that say that that the above is very anti-Republican leaning - I admit, it is a bit, but when Democrats fail, they cover it as well. It just does not happen as much lately. I mean, Republicans manage to contradict themselves inside one sentence, entertainment TV loves that and Democrats actually have hard time competing for air time. A Democrat gets an oral relief from his secretary? A bunch Republicans are selling government oil-rich lands for sex! Beat that! Poor Democrats