I was giving a skills exchange session about Zsh at DebConf 11. I wasn t expected to prepare the session, but since there was no video projector available in the meeting room I started to work on some notes. Looks like I suffer from presentation driven development, so the notes turned out to become bigger than expected. If you re interested in my Zsh pony then head over to grml.org/zsh-pony. PS: I plan to provide the zsh pony at github, but my org-mode file still causes an error 500 at github. Github support is already aware of it. In the meantime I m happy to receive feedback, patches and contributions via mail.

After some troubles I finally managed to write first usable application for MeeGo. The first thing I have choosen was intentionally simple as I more or less wanted to get used to Qt Quick. However I still think it can be useful (after some polishing), at least I used similar application on my older phone :-). The application is meant for photographers who don't remember hyperfocal distance for all their lenses and apertures or want to calculate depth of field: Code is released under GNU GPL on Gitorious: https://gitorious.org/dofcalc

Filed under: English Meego 2 comments Flattr this!

Many people still install Linux from CDs. But a growing number install from USB. In an ideal world you'd be able to download one image that would let you do either, but it turns out that that's quite difficult. Shockingly enough, it's another situation where the system firmware exists to make your life difficult.

Booting a hard drive is pretty easy. The BIOS reads the first 512 bytes off the drive, copies them to RAM and executes them. That code is then responsible for either starting your bootloader or identifying the currently active partition and jumping to its boot sector, but before too long you're in a happy place where you're executing whatever you want to. Life is good. So you'd think that CDs would work in a similar way. The ISO 9660 format even leaves a whole 32KB at the start of a filesystem, which is enough space for a pretty awesome bootloader. But no. This is not how CDs work. That would be far too easy.

Let's imagine we're back in the 90s. People want to be able to boot off CD without needing a boot floppy to do so. And you're a PC vendor with a BIOS that's been lovingly[1] forced into a tiny piece of flash and which has to execute out of an almost as tiny piece of RAM if you want your users to be able to play any games. Letting boot code read arbitrary content off the CD would mean adding a new set of interrupt hooks, and that's going to be even more complicated because CDs have a sector size of 2K while hard drives are 512 bytes[2] and who's going to pay to implement this and for the extra flash and RAM and look surely there has to be another way?

So, of course, another way was found. The El Torito specification defines a way for shoving a reference to some linear blocks into the ISO 9660 header. The BIOS reads those blocks into memory and then redirects either the floppy or hard drive access interrupts (depending on the El Torito type) to that region. The boot code can then proceed as if it had been read off a floppy without all the trouble of actually putting a floppy in the machine, and the extra code required in the system BIOS is minimal.

USB sticks, however, are treated as hard drives. The BIOS won't look for El Torito images on them. Instead, it'll try to execute a boot sector. That isn't there on a CD image. Sigh.

A few years ago a piece of software called isohybrid popped up and solved this problem nicely. isohybrid is a companion to isolinux, which itself is a bootloader that fits into an El Torito image and can then load your kernel and installer from CD. isohybrid takes an ISO image, adds an x86 boot sector and partition table and does some more fiddling to turn a valid ISO image into one that can be copied directly onto a USB stick and booted. The world suddenly becomes a better place.

But that's BIOS. EFI makes this easier, right? Right?

No. EFI does not make this easier.

Despite EFI being a modern firmware for the modern world[3], EFI implementations are not required to be able to understand ISO 9660. In fact, I've never seen one that does. FAT is all the spec requires, and FAT is typically all you get. Nor will EFI just execute some arbitrary boot code from the start of the CD. So, how does EFI boot off CD?

El Torito. Obviously.

It's not quite as bad as it sounds, merely almost as bad as it sounds. While the typical way of using El Torito for a long time was to use floppy or hard drive emulation, it also supports a "No emulation" mode. It also supports setting a type flag for your media, which means you can distinguish between images intended for BIOS booting and EFI booting. But the fact remains that your CD has to include an embedded FAT partition that then contains a bootloader that's able to read ISO 9660 because your firmware is too inept to handle that itself[4].

How about USB sticks? Thankfully, booting these on EFI doesn't require any boot sectors at all. Instead you just have to have a partition table, a FAT partition and a bootloader in a well known location in that FAT partition. The required partition is, in fact, identical to the one you need in an El Torito image. And so this is where we start introducing some extra hacks.

Like I said earlier, isohybrid fakes up an MBR and adds some boot code that points at the actual bootloader. It needs to do a little more on EFI. The first problem is that the isohybrid MBR partition has to cover the entire ISO 9660 filesystem on the USB stick so that the operating system can access it later, but the El Torito FAT image is inside that partition. A lot of MBR-based code becomes very unhappy if you try to set up a partition that's a subset of another partition. So we can't really use MBR. On to GPT.

GPT, or the GUID Partition Table, is the EFI era's replacement for MBR partitions. It has two main advantages over MBR - firstly it can cover partitions larger than 2TB without having to increase sector size, and secondly it doesn't have the primary/logical partition horror that still makes MBR more difficult than it has any right to be. The format is pretty simple - you have a header block 1 logical block into the media (so 512 bytes on a typical USB stick), and then a pointer to a list of partitions. There's then a secondary table one block from the end of the disk, which points at another list of partitions. Both blocks have multiple CRCs that guarantee that neither the header nor the partition list have been corrupted. It turns out to be a relatively straightforward modification of isohybrid to get it to look for a secondary EFI image and construct a GPT entry pointing at it. This works surprisingly well, and media prepared this way will boot EFI machines if burned to a CD or written to a USB stick.

There's a few quirks. Macs will show two boot icons for these CDs[6], one marked "EFI Boot" and one helpfully marked "Windows"[7], with the latter booting the BIOS El Torito image. That's a little irritating, but not insurmountable. The other issue is that older Macs won't look for boot loaders in the legacy locations. This is where things start getting horrible.

Back in the old days, Apple boot media used to have a special "blessed" folder. Attempting to boot would involve the firmware looking for such a folder and then using that to start itself up. Any folder in the filesystem could be blessed. Modern hardware doesn't use boot folders, but does use boot files. For an HFS+ filesystem, the inode of the bootloader is written to a specific offset in the filesystem superblock and the firmware simply finds that inode and executes it. And this appears to be all that older Macs support.

So, having written a small tool to bless an HFS+ partition, I tried the obvious first step of burning a CD with three El Torito images (one BIOS, one FAT, one HFS+). It failed. While Refit could see the bootloader in the HFS+ image, the firmware appeared to have no interest at all in booting off it. Yet Apple install media would boot. What was the difference?

The difference, obviously, was that these earlier Macs don't appear to support El Torito booting. The Apple install media contained an Apple partition map.

The Apple partition map (APM) is Apple's legacy partition table format. Apple mostly dropped it when they went to x86, where it's retained for two purposes. The first is for drives that need to be shared between Intel Macs and PPC ones. The second seems to be for their install DVDs. Some further playing revealed that burning a CD with an APM entry pointing at the HFS+ filesystem on the CD gave me a boot icon. Problem solved?

Not really. Remember how I earlier mentioned that ISO 9660 leaves 32KB at the start of the image, and that an isohybrid image then writes an MBR and boot sector in the first 512 bytes of that, and the GPT header starts 512 bytes into a drive? That means that it's easy to produce an ISO that has both a boot sector, MBR partition table and GPT. None of them overlap. APM, on the other hand, has a header that's located at byte 0 of the media, overlapping with the boot sector. And it has a partition listing that's located at sector 1, overlapping with the GPT. Is all lost?

No. Merely sanity.

The first thing to remember is that the boot sector is just raw assembler. It's a byte stream that's executed by the CPU. And there's a lot of things you can tell a CPU to do that result in nothing happening. Peter Jones pointed out that the only bits of the AFP header you actually need are the letters "ER", followed by the sector size as a two byte big endian integer. These disassemble to harmless instructions, so we can simply move the boot code down a little and stick these at the beginning. A PC that executes it will read straight through the bizarre (but harmless) Apple bytes and then execute the real boot code.

The second thing that's important here is that we were just given the opportunity to specify the sector size. The GPT is only relevant when the image is written to a USB stick, so assumes a sector size of 512 bytes. So when the GPT starts one sector into the drive, it's actually starting 512 bytes into the drive. APM also starts one sector into the drive, but we can simply put a different sector size into the header and suddenly we're able to choose where that's going to be. 2K seems like a good choice, and so the firmware will now look for the header at byte 2048.

That's still in them middle of the GPT partition listing, though. Except we can avoid that as well. GPT lets you specify where the partition listing starts and doesn't require it to be immediately after the header. So we can offset the partition listing to, say, byte 8192 and leave a hole for the Apple partition map.

And, shockingly, this works. Setting up a CD this way gives a boot icon on old Macs. On new Macs, it gives three - one for legacy boot, one for EFI boot via FAT and one for EFI boot via HFS. Less than ideal, but eh. The one remaining problem is that this doesn't work for USB sticks (the firmware sees the GPT and ignores the APM), so we also need to add a GPT entry for the HFS+ partition. Job done.

So, it is possible to produce install media that will work if burned to CD or written to a USB stick. It's even possible to produce a version that will work on Macs, as long as you're willing to put up with three partition tables and an x86 boot sector that doubles as an APM header. And patches to isohybrid to do all of this will be turning up as soon as I tidy the code to the point where it works without having to hack in offsets by hand.

[1] Insert some other adverb here if you feel like it
[2] Why yes, 15 years later BIOSes still tend to assume 512 bytes. Which is why your 4K sector disk is much harder to work with than you'd like it to be.
[3] Ever noticed how the modern world involves a great deal of suffering, misery and death? EFI fits into that world perfectly.
[4] Obviously if you want your media to be bootable via both BIOS and EFI you need to produce a CD with two El Torito images. BIOS systems should ignore the image that says it's for EFI, and EFI systems should ignore the BIOS one. Some especially creative BIOS authors[5] have decided that users shouldn't have their choices limited in such a way, and so pop up a screen that says:

1.
2.
Select CD-ROM boot type:

and wait for the user to press a key. The lack of labels after the numbers is not a typographical error on my part.
[5] Older (pre-2009, and some 2009 models) Apple hardware has this bug if a dual-El Torito CD is booted via the BIOS compatibility layer. This is especially unfortunate because said machines often fail to provide a working keyboard emulation at this stage, resulting in you being stuck forever at an impressively unhelpful screen. This isn't a Linux bug, since it's happening before we've run any of our code at all. It's not even limited to Linux. 64-bit install media for Vista SP1, Windows 7 and Server 2008 all have similar El Torito layout and all trigger the same bug on Apple hardware. Apple's aware of this, and has resolved the issue by declaring that these machines don't support 64 bit Windows.
[6] Even further investigation reveals that Apple will show you as many icons as there are El Torito images, which is a rare example of Apple giving the user the freedom to brutally butcher their extremities if they so desire
[7] "Windows" is Apple code for "Booting via BIOS compatibility". The Apple boot menu will call any filesystem with a BIOS boot sector Windows.

It is half-time for me at DebCamp/DebConf11 in Banja Luka, Bosnia-Herzegovina, and that is a good time to write about my work so far. I started with some finger exercises, such as the HTML copying for gnome-terminal (as blogged previously) and cosmetic changes to the buildd.debian.org/status website. After that, I began my main project: A SAT-based solver for the testing transition problem. In Debian, new software first enters a repository called unstable, where it is tested. Once some requirements are fulfilled (package has been in unstable for usually at least 10 days and has no new release critical bugs), it is entitled to enter the repository called testing, which will eventually form a new stable Debian release. But some packages need to migrate together, usually because either requires the new version of the other. Also, no packages in testing ought to become uninstallable by some seemingly unrelated change. The software that decides these things is called britney. It is sufficiently good in making sure nothing bad happens, but not smart enough to figure out what to do in case more than two packages need to migrate simultaneously. My goal is to improve this. Now, the the various requirements can all be expressed as predicative formulas, and a lot of research has been going into writing good solvers for such problems, called SAT-solvers. Hence my plan was to only specify what we expect from a testing migration, but leave the search for a solution to such a general purpose and highly optimized program. My initial progress was good and I had some result after two days of hacking, and the approach is promising. Because the data sets are pretty large (1.5GB of input data, the final SAT problem has 1.8 million clauses with 250.000 variables), so I learned quite a bit about profiling and optimizing Haskell programs, and that parsec is slower than working with BS.lines and BS.split to parse simple input. I also used the FFI to use dpkg code directly to compare Debian version numbers. At some point I noticed that I actually want to solve PMAX-SAT problems: Given two set of clauses, hard clauses and soft clauses, find a variable assignment that fulfills the hard clauses and as many of the soft clauses as possible. Unfortunately, there are no fast Free PMAX-SAT solvers around. The ones that I found and that were fast enough that I could use them, msuncore by Joao Marques-Silva at the University College Dublin and MiniMaxSat by Federico Heras at the Universitat Polit cnica de Catalunya, are only available as statically linked binaries. It is a shame that this is acceptable by the academic community; imagine mathematicians would stop including the proofs in their papers, and only share their theorems. So if you happen to have written a PMAX-SAT solver and can solve this instance (in weighted DIMACS format) in less than five minutes, and want to brag that the Debian project is using your code, then please release it under a Free license (e.g. GPL or BSD) and tell me about it! The code of my SAT-based solver is, of course, available, though slightly unpolished. Parts of it (notably the interface to picosat and the PMAX-SAT solvers) might be of general interest and I plan to put them on Hackage as a separate license. Update: I have contacted the authors of the SAT solvers mentioned above, and they have reconfirmed that they have no intention of releasing the source. Now I put my hope in maxsatz2009 by Chumin LI, which is GPL but was not able to cope with my large instance directly; I think I need to change the memory management.

Flattr this post

As the main reason why I got Nokia N950 is that I promised to write some applications for that, I started to look deeply at available options how to write them. Unfortunately there are too many options and all documentation I've found is pretty confusing. The short story is that you should use Qt for user interface. However it is not that easy as it looks, you can use regular Qt, which can be run on the phone, but looks ugly in the end (maybe I did something wrong, but it did look completely different to anything else running in the phone). You can use Qt Quick, which is easy to write (simple UI definition and JavaScript variant for code), but it does not seem to support much of the widgets. And then there is Meego Touch library, which seems like a best option, however not mentioned at all on Nokia developer website. Looks like I need to learn few more things before actually starting to code.

Filed under: English Meego 7 comments Flattr this!

why proprietary relicensing is unacceptable for a Free Software enthusiast The past few months have witnessed a large debate about copyright assignment, which seems to has neared its peak around the time Project Harmony has released version 1.0 of its agreement templates. (Note: I use the expression "copyright assignment" in this post, but I'd happily include into it both actual Copyright Assignment Agreements CCAs and Contributor License Agreements CLAs, as both could be used to permit various forms of proprietary relicensing.) Mark Shuttleworth has been one of the most prominent voices campaigning in favor of copyright assignments (to for-profit companies). A couple of interesting blog posts of his where this is evident are "On balancing economic power in the FLOSS ecosystem" and "The responsibilities of ownership". Voices against the opportunity of increasing the popularity of copyright assignments are aplenty and it is pointless to repeat good arguments which I find fully convincing. If you are interested in the subject, here are a few good reads I recommend:

• "Some thougts on copyright assignment", seminal essay (circa end of 2009) by Michael Meeks that provides a good coverage of copyright assignment basics and effects on the surrounding ecosystem
• Richard Fontana's "The trouble with Harmony"; in particular, I recommend taking a close look at "The illusion of constraint" part

What I would like to add to the debate is the point of view of a Free Software enthusiast, not unlike yours truly. I contribute to Free Software not because it is superior to proprietary software in either its software products or in its development methodology. (It actually is superior in many cases, but that's just not my primary motivation.) I do contribute to Free Software to build a world in which users are in complete control of the software they run. Let's assume we have a broken toaster at home. We are all free to (1) open it up and try to repair it by ourselves. If we don't have the needed knowledge, we are free to (2) hand it over to a person that we trust and who does have the needed knowledge to repair it. That failing, we can (3) ask the toaster producer to repair it for us. Many people like me simply don't accept to live in a world where, once all the toasters will be software-driven, the only repair option will be (3), just because the toaster software is proprietary. (Given various kind of [broken] metaphors have been used to explain copyright assignments, it seemed sensible to propose my broken toaster metaphor in exchange.) When I contribute to some Free Software project, I not only care about being able myself to get a Free Software licensed copy of the whole product (i.e. the original software product + my own contribution). I care that all recipients of the product, present and future, will be able to get that contribution with enough freedoms attached to put them in control of the software that includes it. This desire can be fulfilled with a varying degree of success, depending on the license of the code base I contribute to. For instance, I find more pleasant to contribute to a copyleft licensed code base than to a weak-/non-copyleft licensed one, and more pleasant to contribute to an AGPL-ed web app than to a copyleft web app. It also means that, given the option, I will not allow the code base maintainer to re-license my contribution under terms that allow distributing it without suitable freedoms attached. Different contributors will be ready to accept different re-licensing promises, but the mere fact we are debating all this and that companies like Canonical feel the need of campaigning for copyright assignments is evidence that many contributors like me exists and actually have a problem with allowing downstream relicensing of their contributions. What is feared the most is of course proprietary relicensing. According to my moral horizon this is the case not because the company might end up gaining money out of my code: I wouldn't have a problem with that. The reason is rather that the company will be able to distribute my own code in a way that grants less freedoms to users than those that were implicitly "agreed upon" when the contribution has been written. In that respect, I can't help thinking at harmony agreements as a large scale smoke screen experiment meant to convince volunteers that copyright assignments are something Free Software needs. By exploiting the creative-commons-like "it's easy, just choose one" scheme, Harmony takes the chance of offering misleading options such as the one labeled "any OSI approved license". Via that option, which is seemingly fine, the copyright recipient will be allowed to relicense the contribution under some non-copyleft license (e.g. BSD) and from there do essentially what they want. All in all, companies campaigning for copyright assignments seem to have failed to understand two main points. The first one is that contributors motivated by Free Software ideals want the code to remain free not only for themselves, but for all recipients of the code. I'm not claiming that all contributors to FOSS projects belong to this category, but the fact that there is a considerable amount of such people is undeniable. Hoping that they will be fooled by tricks like the "any OSI approved license" agreement is foolish. The second is that while volunteer Free Software communities do respect companies that provide huge amounts of code contributions, they also expect companies to figure out by themselves which business models make their businesses sustainable. Telling volunteers that current business models are not sustainable without proprietary relicensing is worthless. Volunteers just don't care. They want software freedom guarantees and are not willing to renounce to them in exchange of the wealth of companies, not even under the (implicit) threat that otherwise those companies will be forced to reduce the amount of their code contributions.

---

Update: explain in the initial note why my reasoning here encompasses both CCAs and CLAs. Thanks Tollef for noticing that it wasn't clear.

average sprint speed: 1 sprint/month I've proposed a DebConf11 BoF on Debian sprints and, more generally, on how we have been using Debian money in the past 1.3 years. As part of the BoF preparation, I've taken the time to review the last 16 months of sprints and check how the Debian Sprint Program which we've recently streamlined and "marketed" quite a bit is going. In particular, I've finally done the homework of preparing the big table of sprints and their costs, in order to evaluate how sustainable the sprint program is. Without further ado, here is the table:

Debian sprints held from April 2010 to June 2011

No	Sprint	When (month)	Where	Attendees	Debian cost (EUR)
1	groupware (report)	04/2010	de	4	240
2	FAI (report)	06/2010	de	7	570
	(DebConf10)	08/2010	us
3	ftpmaster (report)	09/2010	de	3	350
4	DSA (report)	09/2010	de	3	400
5	release team (report)	10/2010	fr	6	0
6	kernel team (report)	10/2010	fr	3	120
7	www team	12/2010	at	5	1430
8	debian med	01/2011	de	25	460
9	security team	01/2011	de	7	1000
10	emdebian	02/2011	uk	17	0
11	ftpmaster	03/2011	de	5	2000
12	groupware	04/2011	de	6	300
13	alioth	05/2011	uk	4	500
14	debian edu	06/2011	de	9	760
15	release team	06/2011	be	5	1640
	(DebConf11)	07/2010	ba
Total	15 sprints	16 months			9770

To better understand the table, several comments are in order:

• numbers are approximate in various ways. In particular, 2010 costs predate a protocol I've agreed upon with the Debian auditors to do proper accounting, hence it is possible that some costs are slightly overestimated
• costs are Debian's costs and do not include reimbursements for non-Debian people that might have attended the sprint. This also explains why some sprints have been at 0 cost: they have been entirely sponsored by other entities interested in supporting Debian, such as companies or institutions.
• where needed, costs have been normalized to Euro
• we have streamlined the sprint process around October 2010 (you can find the underlying rationales in an old RFC). Sprints happened before that data had a different way of being announced and of reporting back to the project.
• the above data are not detailed enough to properly estimate per-person costs, as we lack a breakdown of Debian vs non-Debian attendees
• no costs for DebConf-s are included, as they have their own budgets which aims to be amortized 0 cost in the long run

Please note that the purpose of the table is not to be precise and transparent about Debian finances and how we use them. That is a (very!) worthwhile goal and I do think Debian should do much better in informing its community about how donated money are used to further Debian goals. But that is a broader topic on which the auditors are working; it is not up to me to discuss it here. If you are interested in that topic though, you might want to follow tbm's BoF at DebConf11. The purpose of the table is rather to find out some general figures about Debian sprints held in the recent past:

• we have had a total of 15 sprints in 16 months (about 1 sprint/month)
• we have spent about 10'000 EUR for sprints, for an average per-sprint cost of about 650 EUR
• all sprints have been held in Europe
  (given DD geographical distribution, I find quite surprising that no group of US-based Debian hackers have asked for sprint sponsoring)
• about half of the sprints have been held in Germany
  (probably thanks to DD-density there and also to the welcoming attitude of friendly venues such as the Linux Hotel)
• the variance of per-person costs is high: there are very cheap sprints (e.g. when people travel within Europe by train and stay at friends') and quite expensive sprints (e.g. when one or more of the participant needs to be flown oversea which has happened only once, up to now)

I'm personally quite happy about those figures. Enabling volunteer developers to meet and hack together in person is possibly the most valuable way of using donated money. Having 1 sprint/month is not bad, but in a project the size of Debian is quite possibly a minimum. Doing more than that is highly desirable. It is also financially sustainable, especially if we will be able to show by actually having more sprints and being transparent about them that we can put into good use donated money. Another, more subtle, aspect of sustainability is that related to sprint management. Processing sprint requests and ensuring that transparency guidelines are actually followed by the organizers is still quite some work. I've been mostly doing that myself up to now, which is all fine and well, but does not necessarily scale. Other organizations (such as KDE e.V.) have realized that to the point of having hired people specifically to manage sprints in an otherwise volunteer community. In Debian we are quite keen of maintaining the project running on a volunteer basis. At the same time I feel we should have more room for scalability in the number of sprints we could run. So if you are looking for a management task to help Debian with, think about becoming, err, "sprint master", and contact me. If otherwise you want to focus on Debian hacking, what are you waiting for? Check the guidelines and propose your sprint! To know more about sprints, Debian money, and how you could help with all that, be sure not to miss the Sprint and money BoF.

... or TDDD and DEP8 context As a nice byproduct of the huge "rolling" discussion we had back in April/May, various people have brainstormed about applying Test-Driven Development (TDD) techniques to Debian development. Here is a brief summary of some opinions on the matter:

• a seminal conversation on identi.ca
• a couple of blog posts by Lars, discussing the general problem of how to use TDD in distribution development and to a lesser extent its instantiation to Debian
• a separate post by Daniel stressing the specific TDD advantage of increasing the confidence of maintainers in making far reaching changes

... and hey, they've also coined the cool TDDD acronym, which I hereby took the freedom to re-target to Test-Driven Development in Debian. Having a cool acronym, we are already half-way to actually having the process up and running *g*. more testing I believe Debian needs more testing and I've been advocating for that since quite a while e.g. at DebConf10, as one of the main goals we should pursue in the near future. Of course advocating alone is not enough in Debian to make things happen and that is probably why this goal has been (thus far) less successful that others we have put forward, such as welcoming non-packaging contributors as Debian Project members. There are important reasons for increasing testing in Debian. quality assurance Quality Assurance has always been, and still is, one of the distinctive traits of Debian. I often say that Debian has a widespread culture of technical excellence and that is visible in several places: the Debian Policy process, lintian, piuparts, periodic full archive rebuilds, the EDOS/Mancoosi QA tools, the cultural fact that maintainers tend to know a lot about the software they're packaging rather than only about packaging, the we release when it's ready mantra, etc. But caring about quality is not a boolean, it's rather something that should be continuously cherished, refining quality requirements over time. By simply maintaining the status quo in its QA tools and processes, Debian won't remain for long a distribution who could claim to care about package quality. Others will catch up and are in fact already doing that. In particular, we surely have room for improvements in our quality tools and processes for:

• Build time package testing. Several packages run their build-time test suites during package build. This aspect is somewhat supported by the Debian policy; we also do a best effort attempt to run build-time test suites via debhelper (starting from version 7). At the same time we could probably campaign more to encourage maintainers to look for build-time test suites which do not follow common Makefile target naming or, fwiw, which don't rely on make at all. TodoList.add("investigate and possibly file bug report against policy to encourage maintainers to run build-time test suites")
TodoList.add("investigate and possibly file bug report against lintian to spot the presence of [non-invoked] build-time test suites")
• Runtime package testing (AKA "as-installed package testing"). Some kinds of test-suites are difficult to run at build-time (e.g. complex applications that don't offer easy way to re-configure on the fly their filesystem paths) and some others are plainly impossible to run without having the packages to be tested properly setup (e.g. running services that are accessible only through the network) or an isolated, throw-away testbed (e.g. bootloaders, kernels, etc.). TTBOMK this kind of testing is not currently in use neither in Debian nor, indirectly, in any of its derivatives. autopkgtest (AKA DEP8) is a step in this direction; I will get back to it later on in this post.
• Integration testing. When applied in the context of distributions, integration testing is about testing package combinations, task (as in tasksel) combinations, basic system functionalities, automated installations, etc. This is the aspect that Lars has discussed the most (and in which he seems to be interested the most) so I don't feel like adding much. Still, it's interesting to note that on this front Debian has an important potential to exploit. The large base of its developers and the fact that the average Debian user is technical savvy mean that we can potentially collect a lot of test cases. It's "just" (with well-deserved double quotes) a matter of deciding a standard interface for test case submissions and developing a most likely virtualized test runner. At that point a continuous integration service that periodically run and publishes results can be setup independently from the rest of the Debian infrastructure and offered to interested eyes, such as Release Team's. Any taker?
• Automated code analysis and in particular automated bug finding is something which is becoming more and more common and finally, after decades of research viable. Successful proprietary tools and businesses are aplenty (a nice and very fun read on the subject is the story of Coverity), as well as FOSS solutions. For instance, the Linux kernel is routinely using Coccinelle to automatically find bugs and even produce the corresponding patches. Add to the above the fact that Debian is one of the largest software collection in existence (and quite probably the largest collection of Free software in existence) and is upstream of the packaging of that software for the most part. That turns Debian into a very peculiar platform for large scale automated code analyses. Not that we can aim at fixing all the bugs we are going to find, or even hope to tame all the false positives we are going to find. But we can offer an important service to the whole ecosystem of Free software and use it to pinpoint important class of bugs from a distribution point of view, such as nasty security bugs (as long as they can be automatically found ). DACA is a very good step in the right direction, even though it is still in its infancy.

reducing inertia Inertia is a recurring topic among Debian lovers (and haters). It is often argued how difficult it is to make changes in Debian, both small and large, due to several (alleged) hindrances such as the size of the archive, the number of ports, the number of maintainers that should agree before proceeding with a cross-package change, etc. It's undeniable that the more code/ports/diversity you have, the more difficult is to apply "global" changes. But at least for what concerns the archive size, I believe that for the most part it's just FUD: simply debunking the self-inflicted culture about how "dangerous" doing NMUs is might go and has already gone, imho a long way to fight inertia. Adding per-package and integration tests will make us go another long way in reducing inertia when it comes to performing archive-wide changes. Indeed if a package you are not entirely familiar with has extensive test suites, and if they still pass after your changes, you can be more confident in your changes. The barrier to contribution, possibly via NMU, gets reduced as a result. And if your change will turn out to be bad but still not spot by the test suites, then you can NMU (or otherwise contribute) again to extend the test suite and make the life easier for future contributors to that package. It smells a lot like an useful virtuous cycle to me. autopkgtest / DEP8 how you can help Of all the above, the topic that intrigues me the most is as-installed package testing. Work on that front has been started a few years ago by Ian Jackson when he was working for Canonical. The status quo is embodied by the autopkgtest package. At present, the package contains of various tools and the following two specs:

1. README.package-tests provides a standard format to declare per-package tests using the new debian/tests/control file. Tests come as executable files which will be run by the adt-run tool in a testbed where the package(s) to be tested is already installed. This part of the specs has been reified as DEP8 which I'm (supposedly) co-driving with Iustin Pop and Ian (for well-deserved credits).
2. README.virtualisation-sever describes the interface among the test runner and the testbed. A nice separation is provided among the runner and the testbed, enabling different testbed environments with a varying degree of isolation: you can have a "null" testbed which runs tests on your real machines (needless to say, this is highly discouraged, but is provided by the adt-virt-null tool), a chroot testbed (adt-chroot), or a XEN/LVM based testbed (adt-virt-xenlvm).

The specs allow for several runtime testing scenarios and look quite flexible. The tools on the other hand suffer a bit of bitrot, which is unsurprisingly given they haven't been used much for several years. At the very minimum the following Python development tasks are in need of some love:

• The usage of python-apt needs to be ported to recent API, as several used methods and attributes are now gone.
• Porting from dchroot to schroot is needed for the adt-virt-chroot backend.
• A kvm backend for the test runner would be nice.

If you are both interested in TDDD and grok Python, the above and many others tasks might whet your appetite. If this is the case don't hesitate to contact me, I'll be happy to provide some guidance.

---

Note: this post is the basis for the TDDD BoF that I will co-host with Tom Marble at DebConf11. If you plan to come, we will appreciate your thoughts on this matter as well as your help in getting the autopkgtest toolchain up and running again.

One of the first things that I worked on here at DebConf11 is supporting the HTML target in gnome-terminal. This means that if you copy a part of the screen and paste it into some application that handles HTML (such as evolution or my blog s edit field), attributes such as color and boldness are preserved. Here are some examples: A man page

MAN(1)                           Manual pager utils                           MAN(1)
NAME
       man - an interface to the on-line reference manuals
SYNOPSIS
       man [-C file] [-d] [-D] [--warnings[=warnings]] [-R encoding] [-L locale] [-m
       system[,...]] [-M path] [-S list] [-e extension] [-i -I] [--regex --wildcard]
       [--names-only]  [-a]  [-u]  [--no-subpages]  [-P  pager] [-r prompt] [-7] [-E
       encoding]   [--no-hyphenation]   [--no-justification]   [-p   string]    [-t]
       [-T[device]] [-H[browser]] [-X[dpi]] [-Z] [[section] page ...] ...
       man -k [apropos options] regexp ...
       man -K [-w -W] [-S list] [-i -I] [--regex] [section] term ...
       man -f [whatis options] page ...
       man  -l [-C file] [-d] [-D] [--warnings[=warnings]] [-R encoding] [-L locale]
       [-P pager] [-r prompt] [-7]  [-E  encoding]  [-p  string]  [-t]  [-T[device]]
       [-H[browser]] [-X[dpi]] [-Z] file ...
       man -w -W [-C file] [-d] [-D] page ...
       man -c [-C file] [-d] [-D] page ...
       man [-hV]
DESCRIPTION
       man is the system's manual pager. Each page argument given to man is normally
       the name of a program, utility or function.  The manual page associated  with
       each  of these arguments is then found and displayed. A section, if provided,
 Manual page man(1) line 1 (press h for help or q to quit)

A coloured diff from git

commit 55c514ae6a714abcfa818c33f00a2c051412c3d9
Author: Joachim Breitner <mail@joachim-breitner.de>
Date:   Thu Jul 21 12:08:56 2011 +0200
    Refactor vte_terminal_determine_colors_internal
    
    to work on VteCellAttr instead of VteCell, and use it in
    vte_terminal_cellattr_to_html.
diff --git a/src/vte.c b/src/vte.c
index 8bcc95d..7d4a6f1 100644
--- a/src/vte.c
+++ b/src/vte.c
@@ -6532,19 +6532,18 @@ swap (guint *a, guint *b)
 
 static void
 vte_terminal_determine_colors_internal(VteTerminal *terminal,
-                                      const VteCell *cell,
+                                      const VteCellAttr *attr,
                                       gboolean selected,
                                       gboolean cursor,
                                       guint *pfore, guint *pback)
  
        guint fore, back;

Midnight commander

  Links     Datei     Befehl     Optionen     Rechts
 <  ~/build/gnome-terminal/vte  .[^]> <  ~/build/gnome-terminal/vte  .[^]> 
 'n        Name            Gr e  Modifikations 'n         Name            Gr e  Modifikations 
 /..                      BERVZ. 20. Jul 18:23 /..                       BERVZ. 20. Jul 18:23 
 /.git                       4096 22. Jul 12:42 /.git                        4096 22. Jul 12:42 
 /autom4te.cache             4096 22. Jul 11:20 /autom4te.cache              4096 22. Jul 11:20 
 /doc                        4096 22. Jul 11:20 /doc                         4096 22. Jul 11:20 
 /glade                      4096 22. Jul 11:20 /glade                       4096 22. Jul 11:20 
 /gnome-pty-helper           4096 22. Jul 09:47 /gnome-pty-helper            4096 22. Jul 09:47 
 /perf                       4096 22. Jul 11:20 /perf                        4096 22. Jul 11:20 
 /po                         4096 22. Jul 11:20 /po                          4096 22. Jul 11:20 
 /src                       12288 22. Jul 12:41 /src                        12288 22. Jul 12:41 
 /termcaps                   4096 22. Jul 11:20 /termcaps                    4096 22. Jul 11:20 
  .gitignore                  935 22. Jul 11:20  .gitignore                   935 22. Jul 11:20 
  AUTHORS                      41 20. Jul 18:25  AUTHORS                       41 20. Jul 18:25 
  COPYING                   35068 22. Jul 11:11  COPYING                    35068 22. Jul 11:11 
  ChangeLog.pre-git        433051 20. Jul 18:25  ChangeLog.pre-git         433051 20. Jul 18:25 
  HACKING                     905 20. Jul 18:25  HACKING                      905 20. Jul 18:25 
  MAINTAINERS                 118 20. Jul 18:25  MAINTAINERS                  118 20. Jul 18:25 
  Makefile                  30512 22. Jul 11:20  Makefile                   30512 22. Jul 11:20 
  Makefile.am                1247 22. Jul 11:11  Makefile.am                 1247 22. Jul 11:11 
  Makefile.in               28812 22. Jul 11:20  Makefile.in                28812 22. Jul 11:20 
  NEWS                      43910 20. Jul 18:25  NEWS                       43910 20. Jul 18:25 
  README                      496 20. Jul 18:25  README                       496 20. Jul 18:25 
  aclocal.m4               377874 22. Jul 11:20  aclocal.m4                377874 22. Jul 11:20 
 *autogen.sh                  610 20. Jul 18:25 *autogen.sh                   610 20. Jul 18:25 
 
 BERVZ.                                        BERVZ.                                         
  10G/104G (9%)   10G/104G (9%)  
Hint: To look at the output of a command in the viewer, use M-!
~/build/gnome-terminal/vte $
 1Hilfe   2Men     3Ansicht  4Bear~ten 5Kopieren 6Ver~ben 7Mkdir    8L schen  9Men s   10Beenden

These changes are discussed in GNOME Bugzilla bug #365121 and can be downloaded in my git repository. Unfortunately, I later found out that I was not basing my work on the current development version, which has changed considerably, so we will see how and when my changes will actually make it into GNOME. Also note that my blog s HTML editor actually modifies the HTML code, so looking at the source of this page does not give you the code that I generate. Update: I ported my changes onto the vte-next branch, so they could be merged now. Please follow the bug report if you want to know more.

Flattr this post

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004. He s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details. Raphael: Who are you? Martin: I m Martin Michlmayr. I m 32, originally from Austria, and currently living in the UK. I ve contributed to various free software projects over the years but Debian is without doubt the one I m most passionate about. I joined Debian in 2000 when I was a student. I worked on Debian more or less full time for a few years while I was pretending to study. Later I started a PhD to do research about quality and management aspects of volunteer free software projects. I investigated the release process in several free software projects, in particular looking at time-based releases. After finishing my PhD in 2007, I joined Hewlett-Packard. I m part of HP s Open Source Program Office and work on various free software and open source activities, both internally and within the community. Raphael: How did you start contributing to Debian? Martin: I first used Debian in the days of 0.93R6, some time around the end of 1995. The 0.93R6 release was still based on a.out but I needed an ELF-based system for some application, so I moved to Slackware. I then quickly moved to Red Hat Linux where I stayed for several years. I rediscovered Debian in 2000 and quickly decided to join the project. I cannot recall how I rediscovered Debian but when I did, it was clear to me that Debian was the ideal project for me: I could identify with its philosophy, I liked the volunteer nature of the project, and I found the size and diversity of Debian interesting since a large project offers a lot of different challenges and opportunities. I remember how many new things there were to learn and back then the documentation and other resources for new contributors were nowhere as good as they are today. My application manager, Julian Gilbey, was a great help he was incredibly friendly and passionate about Debian. I also remember meeting up with Peter Palfrader (weasel) for key signing when we were both in the New Maintainer queue. I was incredibly lucky with my New Maintainer process and soon became an official Debian Developer. Because there was a shortage of application managers, my first major contribution in Debian was to become an application manager myself and help other people join the project. Debian is a large project with a long history and a rich culture, so new contributors should expect that it will take some time to become familiar with everything. Fortunately, there are many resources, such as documentation and the debian-mentors list, for new contributors. Another great way to become familiar with the way things are done in Debian is to subscribe to various Debian mailing lists and ideally to read some mailing list archives. It s also a great idea to attend the Debian Conference or other conferences since meeting people in real life is a great way to integrate. I remember attending Debian Conference 1 in Bordeaux where I gave my first public talk. Finally, new contributors should find an area where they can make a unique contribution. Most people in Debian maintain packages but there are so many other ways to contribute. For example, most of my contributions were not technical but were about coordination and other organizational activities. Raphael: What s your biggest achievement within Debian? Martin: I m particularly proud of a number of achievements:

• New Maintainer: I helped a lot of people join Debian. It s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
• Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It s hard because you don t know the circumstance of someone they may be inactive because of an illness or for other good reasons so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn t complain when I took their packages away.
• DPL: I acted as the Debian Project Leader for two years. I m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It s very motivating to meet users and to hear how they use Debian and how we can further improve it.
• Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.

Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help? Martin: There are plenty of instructions on the Internet to install Linux distributions on NAS or various embedded devices by connecting a serial console and then typing in hundreds of commands. What I found is that such instructions significantly limit the user base because they are way too complicated for most users. There are just too many steps that can go wrong. So instead, in Debian, we provide a solution that just works: usually, you download a firmware image for your NAS device from Debian and when you upgrade you get the Debian installer. You connect to the installer via SSH and perform a normal installation. The installer knows about the device and will prepare everything for you automatically for example, it knows if the device has requirements for the partition layout and it will install the kernel where the device expects to find it; unfortunately, NAS devices are not like PCs, so the requirements are different for almost every device and therefore you need special code to support a new device. Finally, there are detailed installation guides and we provide help on our mailing lists. There are a number of technical areas for improvement. The installation could be made even easier, and it would be nice to support new platforms and devices. A bigger problem is that while we ve implemented a great solution for NAS devices, we haven t really extended this work to support other classes of devices. For example, tablets and mobile phones are getting incredibly popular and we don t have a compelling solution for such devices, mostly because of the lack of an appropriate GUI. Raphael: What are your plans for Debian Wheezy? Martin: I ve recently been asked by Stefano Zacchiroli, our current Debian Project Leader, to coordinate the care-taking of Debian finances. Debian, as a volunteer project, relies on donations and in-kind gifts (e.g. hardware) to maintain its infrastructure and to support various development efforts, such as funding sprints and other developer gatherings. Debian s money and other assets are held by affiliate organizations around the world. My responsibility will be to keep track of money and other assets (e.g. hardware and trademarks), work with the DPL to establish procedures related to the use of Debian s assets, and make sure that the procedures are followed. Finally, we want to publish public statements so our donors know how we use their donations to further improve Debian. I just started working on this and this will be my main activity in Debian in the coming months. Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. http://debian-handbook.info). Is this something Debian should support? Martin: First of all, I should make it clear that I don t decide how Debian spends its money. This is up to the DPL to decide together with the project at a whole. I ll just make sure that procedures are followed and expenses tracked and reported properly. Having said that, in my opinion, it s unlikely that Debian as a project will fund this effort. It would be inconsistent with the position of the project not to fund work directly (only some related expenses, such as travel costs to allow Debian teams to organize face-to-face meetings). Whether Debian should support the fundraising effort by helping to promote it is another question and that s probably not as clear cut. It looks like a worthwhile effort, but on the other hand it would be unfair for authors of other Debian books for Debian to put its weight behind one and there are many other efforts that are worth promoting if you promote one, where do you stop? So while it sounds worthwhile, it s probably better for Debian to stay out of it. But somehow related to this, I sometimes worry about the fact that there are so few paid opportunities around Debian. If you contribute to the Linux kernel for a while, you have an excellent chance to get hired by someone and to work on the kernel full time. The kernel may be an extreme example but there are a lot of projects that have more paid opportunities than Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE. Obviously, there are some Debian Developers who can spend some time on Debian as part of their job. I know that some Canonical employees contribute to Debian, that support companies like credativ improve Debian as part of their work, and that system administrators fix bugs or package new software as they deploy Debian. But I think this is a minority of contributors and even they don t work full time on Debian. Instead what I see is that a lot of people leave university, get a job and then no longer have time for Debian or people start a family and no longer have time. I can take myself as an example since I don t have nearly as much time as I did in the past when I was a student. I guess there are different ways to deal with this problem one would be to create more paid opportunities around Debian outside the project, another one might be to make it easier for new volunteers to join the project. I don t have the answers to these questions but it s something I wonder about, and I also wonder whether pure volunteer projects can still keep up with projects with a lot of full time contributors. Raphael: What motivates you to continue to contribute year after year? Martin: Debian is a great project with a great mission, goals and people. I contribute to make Debian a better solution and to promote the free software philosophy. Finally, the community around Debian provides a lot of motivation. It s amazing how much I ve learned about other cultures because of my involvement in Debian and how many friends I ve made over the years all around the world. Raphael: Do you have wishes for Debian Wheezy? Martin: Not really. I m pretty happy with the way things are going at the moment. We have made a lot of organizational changes in the last few years from which the project has greatly benefited. I m particularly pleased about the plans to adopt a time-based freeze. Raphael: Is there someone in Debian that you admire for their contributions? Martin: There are many people I admire greatly. I d like to mention Joey Hess because he s a great example to follow. He doesn t get involved in politics, is easy to work with and does great technical work. In fact, he has made not one but several contributions that have completely changed Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has a lot of contributors who have done great work over the years but who are not very vocal about it. People like Colin Watson or Peter Palfrader. Debian has many unique contributors and the list of people I admire is much longer than the few people I just mentioned.

---

Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Our adventurous friends Eric and Katie had invited us to join them on a hike in the Grand Canyon over the 4th of July weekend. As this struck us as something we'd never have considered doing otherwise, we thought we'd accept their kind offer. We're so glad we did. It was quite a bit of traveling just to get there. We flew out of San Jose on Thursday night, got into Las Vegas, rented a car, and then drove to Peach Springs, Arizona, where we stayed the night. We didn't get in at the Grand Canyon Caverns Inn until around midnight, and we had to get up again for a 5:00am departure (I think we actually got away by more like 5:30am), to drive to the Hualapai Hilltop, where the trail head was. Zoe handled all of this very well. She didn't end up falling asleep in the car until about 10:30pm I think, and dealt with the transfer out of the car at midnight very well and went back to sleep. The drive to the Hualapai Hilltop, along Indian Road 18, took about an hour. We had to dodge a bit of livestock on the road. The road itself was sealed and of good quality. We remarked on the way back out that as soon as you left the Havasupai Reservation and entered the Hualapai Reservation that there was a distinct degradation in the quality of the road. We parked at the Hilltop, and got ourselves organised, and commenced our descent by about 7:10am. The first 1.5 miles was very steep. There were a bunch of switchbacks and there was a fair few people coming up the other way already. There were also a few mule trains coming in the opposite direction that we had to dodge. The mule trains have right of way, so we had to stop and get out of the way to let them pass. Zoe thought they were pretty cool because they invariably had a few dogs with them as well, and she thinks dogs are awesome. The remaining 6.5 miles (it was an 8 mile/13 kilometre hike in total) were fairly easy. There was a lot of variety in terrain. Rocks, sand, dirt. It wasn't all in the sun, which was made it more comfortable. Heat wise, I think it was in the high 30's Celsius, with pretty much no humidity, so it didn't feel too uncomfortable. Towards the end, as we got near the water, there was a distinct change in the canyon. There was more greenery, and we started hearing insects and seeing bird life. When we first saw the water, it was hard not to just jump in, it looked so inviting. The total hiking time was about 4 hours 45 minutes, which included a reasonable stop to give Zoe some breakfast. We arrived in the village at around midday. Unfortunately the lodge wasn't ready for check ins until 1pm, so we had to twiddle our thumbs for a little bit. Zoe handled the hike incredibly well. We used a Macpac Possum child carrier that Nigel had passed down to us, and she didn't complain the whole time. She even took a nap in it. We were very relieved that it wasn't a problem for her. Sarah carried her, and I carried everything else. (I'm so glad I didn't see the photo of how I looked until well afterwards). In hindsight we probably brought too much stuff, but we didn't really know what to expect down there, so we'd rather have too much than too little. The village completely exceeded my expectations. I had this (silly) mental picture of it being just the lodge and not much else, but somewhere between 450 and 700 people live in the village. It had two general-type stores, a cafe that was pretty much like a fast food/takeaway place, an elementary school, and some sort of basic medical clinic. There was also a small general purpose community centre of some sort. The main store had pretty much everything you'd need in the food department. The cafe frequently ran out of various different things, but you weren't going to go hungry. For the remainder of Friday, we just stayed put in the village and let Zoe stretch her legs. Eric and Katie and their kids explored the first set of falls down from the village, unofficially named Rock Falls. On Saturday, we all hiked down to Havasu Falls. We met a couple of other families (amusingly both from the Bay Area) along the way, so we had some interesting conversations. I have no idea how long the hike was. Havasu Falls was impressive. Quite tall and narrow at the top, and quite loud. Zoe was impressed. We took her for a bit of a swim in the pools in the bottom. We had lunch there, and then Zoe and Sarah stayed there (Zoe took a nap in the KinderKot (also courtesy of Nigel) in the shade by the falls, and I took the Macpac with a water bladder in it to refill it at the spring in the campground, which was further down stream, and to check out Mooney Falls with Eric and Katie (and their kids), which was further downstream again from the campground. Mooney Falls was pretty insane. A lot taller than Havasu Falls, and a lot more treacherous to get to the bottom of. Parts of it were vertical. Chains and rickety ladders were involved. Caves were involved. I'm so glad I didn't have Zoe in the Macpac, because on multiple occasions, the top of it got bashed into rocks, so without having Sarah with me also to act as a guide, there's no way I could have safely descended with Zoe in the backpack. My favourite photo illustrating how crazy this was is this one that I took of Eric and Katie. This photo highlights some of the craziness involved to get down. I pretty much got to the bottom, had a quick look around and left Eric and Katie to it, because I figured Zoe would have woken up by now, and was probably bored. Turned out I had all of the sunscreen with me as well. So I climbed back up, and trekked back to the campground, refilled at the spring, and headed back up to Havasu Falls. After we reunited, we then hiked back up to the village, which to be honest, was the hardest bit of hiking we did. I was carrying Zoe in the Macpac, and it was hot, and it was mostly loose sand all the way. We were very glad to get back to the village. Zoe started showing signs of coming down with a cold and a cough, so we decided to cut short our stay in the village and leave on Sunday instead of Monday. We'd been tossing up between getting a helicopter or horses out. We ended up opting for the helicopter after learning that the horses still took about 3.5 hours, and you basically had no control over the animal. We were dubious as to how Zoe would go being bounced around on the back of a horse for that long. The helicopter ride also took all of about 5 minutes. The tribal members get first dibs on the helicopter, and there had been a death in the village, and I think a lot of people had come to the village for the viewing (the casket itself was flown out earlier on Sunday morning for a burial out of the village), so I suspect there was a higher number of tribal passengers than usual. We didn't get out until 2pm. Again, Zoe was incredibly good. She just hung out with us while we waiting for a flight out. There were plenty of dogs for her to be entertained by, and some other kids. She also took a pretty decent nap. So we finally got out, and got back to our car, and then the heavens opened. It absolutely poured down with rain. Sarah was keen to check out Hoover Dam, so we decided to stay near Boulder City in Nevada, and got a suite in the Hacienda Hotel and Casino for cheap. The next day was the Monday public holiday for Independence Day, and we were tossing up whether or not to take Zoe to a doctor to get her checked to see if she had bronchitis (we've been a bit gun-shy about bronchitis since the time she came down with it when we were in Australia). She ended up falling asleep in the car while we were hunting around for an Urgent Care facility that was open, so we decided to let her sleep and drove to Las Vegas. After she woke up, we took her to see the flamingos at Flamingo and the lions at MGM Grand. Zoe absolutely loved all the lights, sights and sounds of Las Vegas. In the afternoon, we took her to a doctor, and got the "first child, huh?" from the doctor (she didn't have bronchitis). After that, we went and briefly checked out Hoover Dam (just walked half way across the bridge in front of it and walked across the dam itself). The following day, we packed up and spent the morning on the Las Vegas strip again. This time we went to the Venetian (Zoe thought the gondolas were pretty cool) and then we flew out in the afternoon. So it was a lovely little family vacation. We ended up spending about as much time in Las Vegas as we did in the Grand Canyon, but that was okay. I'd really like to go back to Supai again, but I'm not sure if the stars will align themselves appropriately. If we did, knowing what I know now, I'd take a lot less food and put all of the luggage on a horse, and just hike in with the minimum of stuff. I'd probably be game to hike out as well if the bulk of the luggage was on a horse. Photos from the trip are here.

Short version arrival was quite easy, the arrival wiki page is now up-to-date and my photos are uploaded every day to this Flickr set. I had a small problem departing from CDG to Zagreb after scanning my suit twice and complaining that it had too many electronic devices, they had me remove my Nexus S, Nokia N950 and Kindle 3 from the suit pockets and then scanned that all lot again. After that another security guy asked me to open my suitcase and started squishing my Ligo cheese and declaring in a grave voice that it was too soft to be legal . As I kept calm and explained the DebConf cheese party to him, he looked around, put the cheese back in the bag and said ok, ok, off you go . So I still have that softness for the party. I heard an even better anecdote from our next years hosts when they were travelling trough Germany, a border official asked a typical so, what are you here for? question. They answered that they were in transit for an IT conference and gave him the invitation letter. He read the letter, nodded and then said: DebConf, huh? So, who was the author of the Linux kernel? and when after the initial shock they gave the right answer, they were immediately waved trough. Now that s what I call good border security. I met up with the guys in the Zagreb airport caf , which was immediately after exiting the secure zone. We waited for dkg to arrive and get his baggage. The passport check too a couple of minutes, but the baggage claim looked to be taking almost a half an hour. After that was sorted out, we took out some local money in one of the 5 ATMs around and went to the bus. We were waived to just put our bags into the bus luggage space and get on, the driver went around to sell us tickets just before we drove off. It was one of the most comfortable and well air-conditioned buses I have been on in a long time. We were in the Zagreb bus station in less than half an hour. Then a funny part started an old man came up to dkg and immediately asked Are you going to Banja Luka? , and when he said yes, the man started dragging us along to the bus station saying that there is a bus to there that will leave in a couple minutes, but we were in luck, so we should follow him right to the bus. Driven by curiosity, we went on. The man dragged us to the far side of the bus terminal bus stops where there was a minibus with Bosnian number plates, but no official designation as a passenger transit bus and no other passengers. They asked a reasonable 120 kuna for the trip, but they looked very shady to me, so we refused. I think that if we agreed and we were lucky enough that they actually did get us to Banja Luka, the price would have risen along the way, for example using the highway tolls as an excuse. After getting cursed at by the old man and being demanded to buy him a beer for his efforts, we went upstairs to the real bus station where we were told that there were two buses to Banja Luka: one at 15:00 and another at 16:30, but that those two buses arrive in Banja Luka almost at the same time, so we got us tickets for the latter bus and went to a local bar to get some food and drinks. I somehow managed to get sausages in deepfried bread that for some reason cost almost triple of a hamburger and fries that others got, but it sure helped to pass the time and after all those 9 was not a bad price for a good meal. We were a bit surprised by the bus drivers asking us to pay 1 (or 8 kuna) for bags to be put into bus bag storage, especially as we for several minutes could not quite understand what they want of us as neither of them spoke either English, Russian or German. I don t remember when was the last time I crossed a real (i.e. non-Shengen) border in a bus, so getting out of the bus and walking one-by-one to the border official was a new experience. On the other border of two bus drivers collected the passports an then brought them back later, so that was less painful. And by then we were in Bosnia! And of the things that greeted us was a billboard for the casino in Banja Luka Hotel Bosna. By the time we got to Banja Luka, dkg had already made friends with an official from Croatian ministry of regional development that sat behind us on the bus and knew English very well (after living in Canada for some time). The bus station in Banja Luka looked almost abandoned like the bus stopped in the field with only a few taxi drivers and a bunch of buildings some distance away showing that this was indeed part of civilization. The taxi drivers would take you to the venue for 8-10 KM 5 or 50-100 kuna (if their meter is broken and you look to be really ignorant of the exchange rates). If you walk on a bit, there is a bus station with an ATM taking Visa cards and a bit further on a bus stop that will take you to the centre of the city for 1.5 KM. The train station looked fully abandoned when we went there, only a news kiosk was working there. The bus driver reacted well to the name Hotel Bosna and wave toward it when we passed by it. It is hard to miss, especially the blinking Casino sign or the white pillars with black letters Hotel Bosna on top. You just get off at the bus station Central and walk back a couple hundred meters. Then see all you Debian friends drinking in the cool bar and walk around the corner to the main entrance of the hotel to check in. The rooms are looking really great this is the best DebConf location that I have been to (I was not in Argentina). Soft beds with linens changed daily, nice air conditioning, towels (changed daily, if used), good shower, It is lacking in the speed and power of its free WiFi and in some place there is a clear impression that the hotel was built as a top of the line hotel a couple decades ago, but somehow has fallen into a disrepair since. Or it is simply used much more than expected. So far I would say that the DebCamp is running full steam two hacklabs have desks, chairs, power and network connection, one of them even has sufficient air conditioning. The network works great for me so far, at least in the venue. The hotel wireless is barely usable to read a blog post, preferably without photos. The food is being served well and on time. So far for lunch and dinner you walk up to the reception and get a food ticket based on your room number and go to the M level for the food (the M level is between the ground floor, labelled as PR , and first floor) where for breakfast and dinner there is a buffet, but for lunch you sit at a table and they bring you food. Vegetarians should clearly say vegetarian while pointing at themselves to get the special vegetarian option. So far food has been very good, except that that they often run out of popular items, such as fries, in the buffet. You can also ask for beer and other extra drinks with your food, but know that they cost extra up to 2.5KM for a beer, for example.

I'm someone who sometimes has a beard, and sometimes doesn't. Today, I'm someone with a fairly long beard, although it's not (yet?) one of the likes of andrew or maddog. I don't think it looks very well on me, but you can blame the government (or lack thereof) in Belgium. How?! What?! Yes, the government. A while back, a movie critic working for the RTL (a Francophone Belgian TV station) decided to keep his beard until the Belgian government took the oath of office. He was quickly joined by an actor, and then by a Flemish radio presenter (dutch, with pictures). And then by a whole bunch of people. I didn't join them, initially. But after a while, when my beard was starting to get long again, people started asking me, 'is that for the government?' And initially I said no. But people kept asking. Since it seemed like a good excuse for not having shaven that long, after a while I just decided to say 'yes' for the heck of it. And now, after having said so for quite a while, I've kindof grown to the idea. Which, I guess, means that if the impossible happens, and someone back home manages to form a government that will take the oath while I'm still in Bosnia and Herzegovina, I'll have to go out and buy some razor equipment. But I don't expect that to happen. Today, exactly 400 days after the previous election (yes, it's really been that long), it still doesn't look as if there's going to be an agreement on anything. I wish there was something positive or funny that I could report on in this whole thing, but it doesn't look like it. Sigh.

Some weeks ago I noticed that one of my backup servers was not removing the old backup generations it was making. It had over 18 months worth of daily backups, done with rsync and "cp -al". This is not the world's greatest backup system, but that's entirely irrelevant for this rant. The cron job that would do that did not exist: I had forgotten to enable it. So I ran it by hand. Then fixed it, when I noticed it was buggy, and didn't remove any old generations prior to 2010. After that I removed years-old backups of machines that haven't existed for years. Disk usage:

       Size  Used Avail Use% 
before 5.4T  2.6T  2.6T  51% 
after  5.4T  892G  4.3T  18% 

Inodes:

          Inodes    IUsed     IFree IUse%
before 732577792 77645915 654931877   11%
after  732577792 16871789 715706003    3%

That's about 61 million files removed, over the course of three weeks, of which the machine was down due to crashes for about one week. It should not take two weeks to copy a couple of terabytes (it's less than two megabytes per second). It should definitely not take two weeks to delete it. Almost all the time it was up, it was removing files. There were a couple of times when it finished one run and was idle until I woke up and started the next run. Say a day in total. Why is "sudo rm -rf" on a large directory tree, or set of large directory trees, so slow? I suspect part of the problem is that the system call API is beautiful, but simplistic: you need to call unlink or rmdir on every file separately, and that means doing an inode lookup separately for each file. Having a system call to delete everything in a directory would have a chance of removing things more efficiently, I suspect. However, since I've not done any profiling, nor even analyzed the relevant source code in the kernel, I might be entirely wrong. I wonder if anyone else needs to remove large directory trees frequently? I do that a lot, because of my backup software development hobby. But I may be in a unique position, and nobody else would benefit from fast removal. (I'll note that my backup server is using ext3, and that ext4 is much faster at removing files, particularly large files, but it's still not fast enough.)

Right now I am sitting in the train to the airport for going to DebCamp/DebConf 11 in Banja Luka, Bosnia and Herzegovina. During DebCamp amongst other things I am going to work on finishing up the last bits on getting daily/weekly Debian Live autobuilds back for wheezy. This spring Jimmy Kaplowitz offered to help with the task of overseeing the debian-live autobuilder and to coordinate necessary bits with cdimage.debian.org. Having them on cdimage.d.o became recently possible as Steve McIntyre offered to make a VM available for us (live-build requires root privileges, and naturally, you would not want to let that run on the host system itself, that is why in the past it was not possible to build them on cdimage.d.o). The remaining issues are, and this is why the autobuilds are not yet back since spring, that live-build still needs two things: a couple of tweeks for wheezy, and the autobuild stuff need to be properly integrated into live-build itself. That will happen as an additional binary package live-build-cron with a bunch of debconf questions, so that everyone and his dog can setup a debian-live autobuild server on his own machine. The initial upload (which will not yet work, do not bother to try) was uploaded to experimental this week and cleared the new queue, now looking forward to get this all finished up and resulting in a live-build uploaded to unstable by the end of the week. In the second week, Jimmy arrives, I will be introducing him to live-build and the various little things to watch for and hopefully manage to persuade him to take over the autobuilds maintenance. Having all images that are based on packages solely from the stable/testing/unstable archives moved to cdimage.d.o is freeing up ressources on live.debian.net which did the job in the past since etch. Ben Armstrong volunteered to help with overseeing the live.d.n instance of live-build-cron that will build more then once per day images for si, with the only difference that they will not use live-* from the archive but the latest snapshots from our git snapshots repository. This will be a big help for the development as eventually we will be autotesting these images for various things. Last but not least, thanks to both Jimmy and Ben for all your kindness, patience and help with this during the last couple of months. We have interesting times ahead.

Nearly three years ago, I wrote an article comparing Linode and Slicehost having been first a Slicehost customer and then switched to Linode. I would have been happy to stay with Slicehost, because they seemed like good people, but the 64bit vs 32bit issue, especially, tilted things very far in Linode's favor. I thought the results were damning, and many people agreed with me, judging by the number of people clicking through the affiliate link I added later. Based on some comments I read from this guy, who did a similar comparison, at http://journal.uggedal.com/vps-performance-comparison/ I think that between the two of us we drove a lot of customers towards Linode.
Those articles have been out there for years, and are very easy to find with Google. Curious to monitor the situation, a while ago, I set up a Twitter search feed for "Slicehost vs Linode" to see if people were talking about my article, and what other people were suggesting. Overwhelmingly, those suggestions have been for Linode too. Recently, Rackspace, who acquired Slicehost several years ago, announced they would be shutting down Slicehost and transitioning their customers to Rackspace: http://www.readwriteweb.com/cloud/2011/05/rackspace-shutting-down-sliceh.php And yet - people are still asking about Slicehost vs Linode on Twitter! This is a useful reminder to me of how much, in our profession (and likely others, but I'm going with what I know) there is a core of the very clued in, who follow all the latest trends (and, negatively, fads too, at times), and are highly informed about everything that's going on. Outside that, though, there is a pretty long tail of people who are much less informed. That's not a criticism of those people, either; perhaps they follow the latest developments in gold mining technology or something else that's much more relevant to their lives than "computer stuff". It's something to keep in mind when marketing things - you think that everyone must have got the message, that no one could possibly not know what's going on, but it's actually quite difficult to really, reliably communicate something to a broad range of people.

On Friday, June 24, the last day of Open Source Bridge, I won a scarf! It says, "Open Source Citizen." I wasn't the only one. The attendees nominated people who "made an extra effort to help others and share their knowledge," and the conference committee chose the three people they felt exemplified this. The winners were Sumana Harihareswara, Igal Koshevoy, and me. In case you don't know Sumana, she's the new Wikimedia Volunteer Development Coordinator, a friend, and a commenter here at Asheeshworld. In the photo of her and her new scarf, you can also see Ward Cunningham. I suggest reading her wrap-up about the conference, and checking out the notes from her talk. I haven't met Igal, but I've learned he's a fixture of the Portland tech scene. He's user number one on opensourcebridge.org and one of the original contributors to calagator, the most important event calendar in the Portland tech world. That's just a brief summary; follow him on Twitter to keep in touch. I started the conference a little shy, not wanting to introduce myself to people, so I hung out with Sumana. She talked to everyone she could find, and there I was standing next to her. On the first day, it was only because of Sumana's outgoingness that people knew who I was. On the second and third days, I was involved in two sessions: a panel on open source communities and a talk about the OpenHatch training missions. I was extremely honored to be chosen. There were so many other spectacular people I met for the first time, like Valerie Aurora, Jacinta Richardson, Brian Aker, and Alex Linsker. These are all people with three crucial traits: they're extremely knowledgeable, friendly, and opinionated. I'm glad I had a chance to attend and meet them! Photo credits: Thanks to Noah Swartz for the photo of me. Sumana's photo comes from her post to wikitech-l. Igal's comes from his Open Source Bridge user profile.

I got tired of my previous website theme, so I created a new one. And thanks to the miracles of CSS, I didn't have to throw out the old there's still a 'choose your layout' option in the menu. Playing with CSS is fun, and this was an ideal opportunity to learn the new features of CSS3. I've used some of those, and did so in such a way that the theme should still be usable under a browser that doesn't speak CSS3 yet (I hope, though I didn't test). I'm calling it the 'grass' theme if you go check it out, you'll see why and it's now the default. While I was at it, I found out about this little features of CSS that I didn't know about earlier, but could be useful none the less: Using background: inherit is not the same as background: transparent. The latter will render all elements on the site (including floating elements) on top of eachother, while the former will inherit the background of parent elements, but will 'hide' elements that have a lower z-index value on the same location. This is useful if you have position:fixed or position: absolute elements that might overlap with floating elements on small screens. I'm sure this is old hat to anyone who's done some serious web development (me, serious web development? hah!), but it's news to me. One thing I haven't found is whether it's possible to use an alpha layer using CSS3. I looked for quite a while and didn't find it, so I suppose the answer is that it can't be done, and you'll have to use a PNG file with alpha values, or some such. Oh well. In other news, . But I guess that's not a surprise to anyone. Leaving by car, in three days. That might be a surprise. Still have to pack a shitload of things, and also find some things. No surprise there nothing better for me to do something than an uncomfortably close deadline. Oh well.

You might have noticed the release of mksh R40 recently, after more than a year of development. Well, stay tuned for both R40b (with accumulated fixes) and R41 (intent to speed up array handling a lot and prepare for what we postponed to mksh R42 now associative, multi-dimensional arrays). You should also upgrade, if you have not yet done so, to kwalletcli 2.11. Finally, jupp 3.1.15 was left out to the world, including Minix 3 users this time, by special request of one of these on our mailing list. In addition to the MidnightBSD mport which has been there in like forever and the MirPort and the FreeWRT package, in December 2011 a user submitted it to FreeBSD ports, and Benny is going to add it to NetBSD pkgsrc soon, he said. (He also updated their mksh source package. Thanks!) I ve been asked by two people, independent from each other, when I ll upload it to Debian proper, instead of the private-repo packaging. Maybe I should indeed do that, comments?