NEW YORK, Jul 29, 2011 The crowd of thousands gathered here to attend PreventaConf 2011 were abuzz over the unveiling of the culmination of 3 years of aimless arsing about^ww^w concentrated development which has led to the porting of dpkg to the MINIX 3 operating system. Women fainted, men wept openly, medical personnel were kept busy dealing with the many instances of heart seizure, multisensory hallucination and spontaneous combustion which accompanied this momentous event. Much remains to be done.

• start-stop-daemon needs to be ported. It is not built for now.
• A basic set of essential packages needs to be created. Currently all that stuff lives in /usr/local or /usr/pkg. This has already caused problems when e.g. dpkg-architecture assumed perl was in /usr/bin.
• fakeroot needs to be ported so you don't have to build .debs as root which is currently the case.
• Other support programs such as update-rc.d and ldconfig etc. are needed. Currently .debs have to be installed with --force-all to get around their lack. (ldconfig atleast could just be a noop as Minix doesn't actually support shared libraries yet.)
• There are still some API deficiencies. lchown(2) doesn't exist, getpwent(3) doesn't seem to work reliably. etc. Could this cause problems? We will have to investigate and provide workarounds if necessary. No doubt other problems will crop up as work progresses.

Still this is a major milestone of which the Debian Minix developers are justifiably proud.

As I was debugging something recently, an instruction popped up that seemed a little incongruous: Now this is an interesting instruction on a few levels. Firstly, %eiz is a psuedo-register that simply equates to zero somewhat like MIPS r0; I don't think it is really in common usage. But when you look closer, this instruction is a fancy way of doing nothing. It's a little clearer in Intel syntax mode: So we can see that this is using scaled indexed addressing mode to load into %edi the value in %edi plus 0 * 1 with an offset of 0x0; i.e. put the value of %edi into %edi, i.e. do nothing. So why would this appear? What we can see from the disassembley is that this single instruction takes up an impressive 7 bytes: Now, compare that to a standard nop which requires just a single byte to encode. Thus to pad out 7 bytes of space would require 7 nop instructions to be issued, which is a significantly slower way of doing nothing! Let's investigate just how much... Below is a simple program that does nothing in a tight-loop; firstly using nops and then the lea do-nothing method. Firstly, you'll notice that rather than the 7-bytes mentioned before, we're comparing 3-byte sequences. That's because the lea instruction ends up encoded as: When you hand-code this instruction, you can't actually convince the assembler to pad out those extra zeros for the zero displacement because it realises it doesn't need them, so why would it waste the space! So, how did they get in there in the original disassembley? If gas is trying to align something by padding, it has built-in sequences for the most efficient way of doing that for different sizes (you can see it in i386_align_code of gas/config/tc-i386.c which adds the extra 4 bytes in directly). Anyway, we can build and test this out (note you need the special -mindex-reg flag passed to gas to use the %eiz syntax): So, if you need 3-bytes of padding in your code for some reason, it's ~160% slower to pad out 3-bytes with no-ops rather than a single larger instruction (at least on my aging Pentium M laptop). So now you can rest easy knowing that even though your code is doing nothing, it is doing it in the most efficient manner possible!

It's been a while since my last blog post, and also quite a while since my last item in the "Testing stuff with QEMU" series, so here goes. I'm using this QEMU image to do compile-tests on the PowerPC architecture for various software projects, especially flashrom (open-source flash ROM programming software). So here's how to install Debian GNU/Linux on PowerPC (in QEMU):

1. Install QEMU:
   $ apt-get install qemu
2. Create a (resizable) image which will hold the installed OS. Use the relatively new "qcow2" QEMU image format, which will only take up as much space as is really needed and has some other nice features (compression, encryption).
   $ qemu-img create -f qcow2 debian_powerpc.qcow2 2G
3. Download a Debian installer ISO for PowerPC:
   $ wget http://cdimage.debian.org/cdimage/archive/5.0.8/powerpc/iso-cd/debian-508-powerpc-netinst.iso
   Note: For some reason, the current Debian stable 6.0.2.1 ISO didn't work for me (red screen with undefined error during the install; didn't look into the issue, yet). Using an older 5.0.8 image worked fine.
4. Install Debian in the QEMU image:
   $ qemu-system-ppc -hda debian_powerpc.qcow2 -boot d -cdrom debian-508-powerpc-netinst.iso
   The installation is nothing really special, you'll know almost everything from your usual x86 installation procedure. Note that you have to use "qemu-system-ppc" (not your usual "qemu"), of course.
5. After the install has finished, shut down QEMU; from now on you can boot it with:
   $ qemu-system-ppc -hda debian_powerpc.qcow2

See the screenshots for some system info. By default an OpenBIOS firmware and the quik bootloader is used, the emulated "machine" is g3beige (Heathrow based PowerMAC). You can use QEMU's -M and -cpu options to select different machines or CPUs. Hope this helps.

So there are two things I stumbled upon with caff:

• If you have two keys, you want to set $CONFIG 'local-user' to the content of $CONFIG 'keyid' . For some reason unbeknownst to me this option is not even listed in the configuration file template. keyid does something different that you'd expect
• More importantly it uses its own gpg.conf for whatever reason (probably because it sets its own GnuPG homedir and does not override the configuration file location). So if you, like me, put the right settings for strong signatures into ~/.gnupg/gpg.conf, you need to replicate them into ~/.caff/gnupghome/gpg.conf.

Thanks to Tom Marble for the hint. I'm still sad that I'd basically need to re-do yesterday's keysigning (which was about 100 e-mails), just to switch from the default SHA1 to SHA256

A new maintenance release version 0.9.6 of Rcpp went onto CRAN and into Debian earlier today. This release contains a fix which helps the RppEigen package (mentioned previously on this blog), as well as an addition which permits user-defined finalizers for external pointer objects (following a suggestion on the mailing list). Two new examples where added: a Gibbs sampler illustration (blogged about as well) and a Rcpp-based Fibonacci implementation following a question on StackOverflow. And while that last example is clearly degenerate, the 700+ fold net speedup (as shown in my answer) is still pretty neat. The complete NEWS entry is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

0.9.6   2011-07-26
    o   Added helper traits to facilitate implementation of the RcppEigen
        package: The is_eigen_base traits identifies if a class derives from
        EigenBase using SFINAE; and new dispatch layer was added to wrap() to
        help RcppEigen
    o   XPtr now accepts a second template parameter, which is a function
        taking a pointer to the target class. This allows the developper to
        supply his/her own finalizer. The template parameter has a default
        value which retains the original behaviour (calling delete on the
        pointer)
    o   New example RcppGibbs, extending Sanjog Misra's Rcpp illustration of
        Darren Wilkinson's comparison of MCMC Gibbs Sampler implementations;
        also added short timing on Normal and Gaussian RNG draws between Rcpp
        and GSL as R's rgamma() is seen to significantly slower
    o   New example on recursively computing a Fibonacci number using Rcpp and
        comparing this to R and byte-compiled R for a significant speed gain

Thanks to CRANberries, you can also look at a diff to the previous release 0.9.5. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

Due to high demand I have prepared official Redis packages for Debian "squeeze":

1. Add the following line to /etc/apt/sources.list:

   deb http://backports.debian.org/debian-backports squeeze-backports main
   

2. Update your local package lists:

   sudo apt-get update
   

3. Install redis-server with:

   sudo apt-get -t squeeze-backports install redis-server
   

The current version number in this repository may be found here. Bugs should be reported in the usual way. For the sections of the web community who insist on hitting problems solved years ago, here is why you should use these packages over installing Redis manually:

• Zero-effort installation: Starts Redis immediately, no compilation or configuration required.
• Improved security: Runs as a dedicated user/group and data files are accessible only to this user.
• Production-ready initscript: All these versions can cause data loss. Server can also be restarted with a standard "/etc/init.d/redis-server restart" instead of manual dance with pidfiles.
• Sensible default locations for data files (/var/lib/redis), logs (/var/log/redis) and utilities (/usr/bin/redis-cli, etc.). Logs are automatically rotated and compressed using logrotate. The log verbosity is additionally reduced from verbose to notice - it is unlikely you care about every new connection.
• Sensible upgrade path: Upgrades to newer versions result in less downtime, handle conflicting changes in configuration options, and can be quickly rolled back in case of incompatibility. The package can also be purged entirely from the system in seconds.
• You don't make your sysadmin cry. If you are the sysadmin and are installing software with a variant of git pull && make && make install you deserve every problem you run into.

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.

Jacob has been eagerly awaiting this day for at least, well, 2 days now. This morning he started asking questions. All day long he has been wondering how long until the big event. And that event is the arrival of the UPS truck carrying a special $8 package for him. And in that $8 package is not a DVD, or a book, or a toy, but rather 12 rolls of adding machine tape (totaling 1/3 of a mile). Oh yes, our four-year-old can hardly contain his excitement over office supplies. Let me back up a bit to explain. I am always on the lookout for a certain kind of toy. The sort of thing that you don t find in the toy section of a store. The sort of thing that is interesting and engages the curiosity of our boys, that most people would consider would toss, and that usually costs less than $5. Along those lines, Jacob has an old manual typewriter he can use, he and I built a switchbox full of switches and light bulbs that the boys love to play with, we built him a command-line-only PC out of spare parts, the boys have some radios they can use, and one day I salvaged a decades-old adding machine that was going to be thrown out. Jacob liked it he enjoys number and letter games and had some fun, but didn t zealously engage with it until just a few days ago. He sat down at his table and started making cards . He will print out a bunch of numbers, making a strip a couple of feet long, and then say, Dad, I made another card for you! We will then happily accept the card and he will continue making more. Here he is, holding up one of his cards: Jacob had a ton of fun making them, and Oliver wanted in on the action too. Oliver was somewhat interested in the adding machine, but not as much as Jacob, and Jacob didn t want to share. So somehow they decided that Oliver would run and get cards from Jacob and then take them to whatever parent Jacob said. Today Jacob said, Dad, the Oliver delivery service will bring you a card! Saturday morning we had some time to hang around and play, so we played some adding machine tape games. I tucked some long cards under my waistband, and the boys happily chased me all over the house trying to get them back. We also decorated: And here is what the room looked like after some cleanup: That orange bucket on the desk is my card bucket where I can put all the cards he gives me. He even helpfully empties it out into the recycle bin when there are too many old cards in it! But then tragedy struck it was out of paper! I ordered a 12-roll pack off Amazon, and boy was it a long couple of days until it arrived. Today before the UPS truck got here, I showed him how we could feed old paper through and print on the back side an incredible innovation, it seemed! Terah had a conversation with him earlier that went like this: Terah: Jacob, we need to clean up the house. Jacob: Why? Terah: Because some people are coming over. Jacob: Who is OH YES! The UPS delivery man! Yes, let s clean! Terah: Ah, well yes he will be here too, but your great uncle and aunt are coming. Jacob: Oh yay! And the UPS man! It is hard to describe Jacob s excitement when the package arrived. I quickly opened it up, and at his great uncle s prompting, he counted to see if he really did get 12 rolls of paper. IT IS TWELVE ROLLS! YAY! And then we quickly installed it in the machine and off he went. At his great uncle s prompting, he started writing a J on each card . This meant Jacob , or maybe he d put two J s, meaning To John From Jacob , or perhaps the two J s meant To Terah From Jacob he d always have to clue us in. Anyhow, for an $8 investment in paper this has brought hours of joy to our boys. Even though Jacob isn t yet really using it to perform arithmetic, it is setting him up to enjoy that sort of thing and encouraging his curiosity. Both good things.

Last night, Tim O'Reilly posted about O'Reilly's desire to ensure that conferences they run are free of harassment and as welcoming to as much of the community as possible. This comes on the back of a brief campaign by various people concerned that the absence of such a policy at one of the largest open source conferences was a problem. O'Reilly turned out to be highly responsive, and it's a credit to everyone involved that this got worked out in such a short space of time.

OSCON's an interesting conference. First, it's huge. There's upwards of 15 simultaneous tracks in the main conference. It covers a huge range of topics, from Linux to pretty much any piece of open source middleware you can think of, to web technologies to hardware hacking to free culture. It's a cross section of pretty much everything that can plausibly be described as open source. As such, the demographics are very different to a typical Linux conference, or even a typical single-field technical conference such as PyCon. We may have discussed these issues at length in the Linux community, but that's such a small part of the OSCON audience that it's not surprising that awareness is lower.

Which means this is a pretty big deal. Sexual harassment isn't something that's limited to Linux conferences. It's prevalent throughout the entire open source world. Having a conference that represents a broader part of that world than any other accept that this is a genuine problem is a massive step towards raising awareness of it in the wider community.

Remembering not so far away history, I'm always a bit afraid when I'm about to use new hardware with Linux. It used to be troublesome to make some devices work. After getting Linux based phone last week, I've also received new notebook, where I want to run Debian as well. I expected various troubles, but surprisingly everything works like a charm without single line of configuration. Wireless networking, docking station, card reader, webcam, fingerprint reader and so on. All I had to do is to pull SSD out of old X60 notebook and put it into new X220. The only (though unnecessary) change was installation of 64-bit kernel (I currently see no big benefit in migrating to 64-bit userspace) and everything is working. Can your operating system do this? Thanks to all people who have helped in this.

Filed under: Debian English Linux 2 comments Flattr this!

Sitting in , , (Banja Luka, Republika Srpska, Bosna i Hercegovina) let s just say the country is pretty nice. People are okay, the beer is not called Nektar by accident, and the Mark (subunit Fennig, funnily enough) is worth 1 DM. Price niveau is below Germany (even when we had the DM) in some things, below or at modern European in others. In short, very affordable. They don t accept paper money though, it s really hard to get coins in most places, and they only want those. The food is okay, and my hotel is very luxurious. It s also got LAN. The weather is not so nice at the moment though: raining a lot, and expecting 30 C too-hot sun in two days. And there are still no Geocaches in the area. Anyway, DebConf is going on, I m acclimating and trying to get people, faces, nicknames and realnames connected. And accents. (And pronunciation of names for example, Ian differs totally from what I d use.) We even have working wire network (LAN) most of the time ;-) We re indeed still working on resurrecting m68k, but that s no news. More on that later, I d say.

Miss apachetop under nginx or lighttpd? You can use pv to get a quick-and-dirty readout for almost any daemon: grep can naturally be used to filter the results.

If a single man can display so much hatred
think only of how much love we all can display together.

Stine Renate H heim

I wrote a Norwegian post explaining my experience at Ut ya. I had taken this blog for dead, and had entirely forgotten that it was syndicated on Planet Debian. I don t want to let Google Translate make this disaster any worse than it is the translation of bullets into balls being particularly bad so the international attention the massacre has garnered in consideration, I am writing an English translation of my experiences. I feel somehow duty-bound to make people aware of what happened, but I don t want to get into anything else but a sober description of the events and some very brief reflections. There are many details I have chosen to omit. Others have written their experiences of the events at Ut ya. I wanted to write mine down as well, and get it out there . Partly, I want to write this down because I m unsure if I will remember all the details at a later point in time, although I think I d prefer it if I couldn t. I m also writing this because people are asking about my experiences and it s much better to have an URL to give them, lest I have to keep going through the same spiel over and over again. Our former Prime Minister and current labour movement demigod Gro Harlem Brundtland had recently left the island. I had been the cameraman for a video interview of her talking about Ut ya, and I was in the media group room encoding the video into a file suitable for YouTube, when someone else in the room startled and said that Twitter was full of messages about a loud explosion in Oslo. As the newspapers brought us information about the extent of the damages, a consensus arose that an informational meeting was in order. As soon as the current round of talks finished, we were gathered into the main hall. The meeting was duly held, and after the statement was made that a TV feed would be made available, I took it upon myself as the local alpha geek to make it happen. Of course, the situation caused both the wireless network and the GPRS networks to become totally unusable. As I was waiting for someone to set up a password, I took the opportunity to face the consequences of having eaten two bits of a microwavable dish called Hold-It the local equivalent of a Hot Pocket and went to the toilet. As I was in there, I first heard agitated shouting, then screams, then gunshots coming from just outside the toilets. More than anything else, it sounded like a toy gun. I was convinced that someone was making a joke in incredibly bad taste and I stormed out of the booth with the intent of halting it. As I tore the door open, I saw two of my comrades hiding in a recessed corner. Their facial expressions left absolutely no doubt that this was no toy. They signalled for me to get back in the booth. I closed the door, did a mental double-take in utter, complete confusion, and opened it again. They were still signalling. Had they not stood there, I would have run straight into the gunman; they saved my life. I looked out into the hallway, and I made eye contact with a young boy lying in a pool of blood. He was motioning for me to help him. I heard more gunshots from inside the building and retreated back inside. As I was trying to think through my next move, I realized that the decidedly insubstantial wood-fiber door would not resist any kind of bullets. I made my way out into the hallway, with the intent of escaping outside. At that point, I was of course not aware that there was an intention to kill as many as possible, so I thought that the open spaces outside would be a place of relative safety. Of course, this proved to be wrong and my life was probably saved a second time by one of the caf volunteers taking me into a hard-to-spot employee s bathroom. We sat there for ninety minutes. Always ready to make a run for it, ready for just about anything. A peculiar group dynamic arose with these two people with whom I had barely previously spoken. We came to share a strange sense of common destiny and gallows humour. One of them had seen the shooter and described the police uniform. I perceived it to be realistic that we were the only ones aware of the wounded outside the toilet. I tried to reach the emergency services, but all their lines were busy; the terror attack in Oslo had probably clogged their lines. I finally got through to the fire services, who could inform me that the police did know about the situation and were on their way. This was to take 90 minutes and by the time we evacuated, the young boy outside my door had perished. The despair I first saw in his eyes as I passed him, fleeing from one room to the other and the empty, blank stare as we left, are burned into me and they are images I will never in my life forget. Finally, the real police arrived. We walked out. I chose the path through the minor conference hall something I now regret. The sight was simply beyond my capacity to describe fully, and so terrifying that I barely remember the sight only the terror it struck in me. There were several people bunched up in a corner, a big amorphous heap of bodies. Some were conscious and yelled at me not to do anything that could startle the police, others lay still. Their bodies were all covered in blood, and a thick pool of blood extended at least a half-metre in all directions around them. The policeman across the hall was screaming orders at me, but he was screaming so loudly that I couldn t make out his words at first. We were first moved into the camp newspaper s offices. There were about eight of us there, I think, in addition to one girl who lay wounded. Towards the end she was drifting in and out of consciousness. We covered her with sweaters to keep her warm and one of us tried to at least temper her bleeding. The bullet had missed her heart, but by the entry wound it was clear that it was not by far. I do not know who this girl was or how she is now. I sat behind and never saw her face. The wounded were evacuated first. I don t remember how long we remained; I had lost all concept of time. In spite of protests from the group who knew him, one kid was put in handcuffs. At the time I didn t understand why, and the policeman seemed to say something almost to the effect that there was no reason for it at all. I didn t see when they undid his cuffs, but I remember thinking that this treatment made a terrible experience even worse for him. I tried my best to comfort him but knew it would be little help. Later, when things stabilised a little, we were told that he was handcuffed because he had come from an unsecured area. The police was extremely good at carefully explaining what was happening and why; this was a big help and I am grateful for it. Eventually we were moved out into the main corridor of the building, where we joined up into a group of about fifty. Only when I saw the two people who saved my life did any emotion other than mild confusion arise. I broke down shivering in tears in one of their arms. After a few seconds, I came back to my senses and realised that this was not the time. I quickly gathered myself, got the shaking under control, and sat down. We were given some chocolate and soda from the kiosk. I remember making an offhand remark that an inability to find joy in free candy was a sure sign of a bad situation. We all laughed out loud. Gallows humour is a coping mechanism, but in retrospect one almost feels guilty for it. We were shown out in a single file with hands above our heads. I remember an intense concern that someone would slip in the steep, muddy slope and create a misunderstanding. Outside, there were more bodies. Some under improvised covers a tarpaulin from the waffle stand, the deflated bouncy castle but some simply lay there. Everyone I met displayed a courage, a mental discipline and unity of purpose far beyond anything one would ever wish to expect from people this young. Everyone conducted themselves with an attitude that could almost be described as stiff upper lip . Safely across the fjord we were offered blankets. I was asked if I was aware of any injuries, and asked to lift my shirt and show my abdominal region. We were shown into the bus which took us to the hotel used by the survivors and their family. I simply cannot describe in any words the relief I felt when I was able to embrace my living comrades. It was completely unlike anything I had ever felt before in my life. The euphoric feeling was tempered only by the realisation that there would be many I could never see again, comrades whom I had taken great pride in calling my friends, with futures in the service of all mankind, futures I had previously found such great joy in pondering and guessing about. The feeling which continues to upset me the most, is the feeling that so many of my comrades left behind grieving families and friends. Torn away senselessly. I do not know how much more than this relatively sober account of the events on Ut ya I can muster. I would, however, like to offer some reflections. First of all, from the bottom of my heart, I want to thank the police who saved the lives of so many still on the island, the holidaymakers who took aboard swimmers into their boats and the rescue services staffed primarily by volunteers who have spared no effort in trying to soften the blow as much as they can. The opportunity to spend time with those comrades who underwent the same experience as myself has also been an immeasurable aid. I was also so relieved to find my very closest friend among the survivors, which has also been an indescribable help. If I can name a single positive in this tragedy: Had he arrived with his automatic weapon fifteen or twenty minutes prior, he would have arrived during the informational meeting, at a time when the major hall was absolutely jam-packed the death toll would be many times what it ended up being. I am agonisingly aware of the meager comfort this provides to those who have been bereft of their closest, but I do find some solace in this. We cannot sweep under a rug that this was without question! a political attack on the labour movement. But it is thankfully also an attack which has been perceived by everyone as an attack on the Norwegian society, and on a symbol of the wide recruitment to the participatory democracy which lies at our very national soul. I cannot thank the Norwegian people, and indeed the people in other nations who have offered their condolences, enough for their shows of support and shared grief. It really has been a tremendous help to me knowing that so many people feel with us. I also want to thank from the bottom of my heart the rock-steadiness of everyone in both the national and local wings of the Labour Party and Labour Youth in supporting us, and the political milieu in general for their resolute steadfastness saving me from losing yet more that I cherish; our freedoms in a participatory democracy. Our Party has lost many of its very brightest youngsters. Personally I feel an angry spite, a deep restless urge to get the wheels of society going again. I want to show his kind that we will not be broken. We re stronger than that. I will not be frightened into silence and passivity. I want to remember the dead, and honor them by carrying on our common work. I want to end this with a request to everyone who reads this, echoing a statement I read by one of my good friends and comrades: Please, don t let me see any messages of hatred, wishes for the death penalty, anything like that. If anyone should be of the belief that anything will improve by murdering this sad little person, they would be profoundly wrong. All attention now should be plowed into caring for those victims and their relatives who did not share my luck, and not giving an audience to a perpetrator who wants one. Tore Sinding Bekkedal

I m here at DebConf11 and it started in the worst possible way. First my wife and me had the pleasure of being guests of the Bosnien border police for 11 hours. Overnight stay in a small room in a small building far away from whatever we know. And unknown status when it goes on. Oh fun. And then, after finally arriving here, my Laptop breaks. Stupid machine, why break at the beginning and not at the end of the conf? It heated up, all to 120 C (which I don t believe is good, nono) and then turned off. Came back on some time later, but the graphics card got a kick. The left part of the screen now shows a big white strip all over it. Which doesn t help it at all. Additionally the thing does not want to operate below 70 C anymore. At least it only takes seconds for it to heat up that far. The fans stay off. There is a way to turn them on by software. If i use that way - the temperate quickly climbs over 100 C. WTF? Well. Guess that means I am looking for a replacement. I don t have too many requirements. Basically I want a BIG screen (and I mean big, my current has 17 ) and that it works well with Debian. Reasonable battery life (1.5hours is reasonable for such a thing, anything more is fine. Its NOT a mobile thing to use on trips, for that I have other devices. It is a workstation you can easily take with you) and the usual rest of a good CPU, at least 4GB RAM and >60GB Harddiskspace. Any suggestions?

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.

I have turned off comments on my blog - there was too much spam, and I'm not planning to invest the time to fix that properly. On the one hand, this is a shame - it removes an opportunity for other people to respond to what I might write. On the other hand, the idea that this was any kind of two-way conversation was always a badly-maintained illusion. I didn't have any kind of notifications set up to tell me when comments arrived; so I rarely read them, and almost never replied. I don't want to build a commercial enterprise or a "community". So for the moment, if you want to get in touch, email me. If you want to respond publically, write your own damn blog post. :)

Currently Debian/Unstable is going through a transition to using /run instead of /var/run. Naturally any significant change to the filesystem layout requires matching changes to SE Linux policy. We currently have Debian bug #626720 open about this. Currently the initscripts package breaks selinux-policy-default in Debian/Unstable so that you can t have initscripts using /run if the SE Linux policy doesn t support it. A patch has been suggested to the policy which uses a subst file, basically that causes the SE Linux labeling programs to treat one directory tree the same way as another. The problem with this is that it depends on a libselinux patch that is not in any yet released version of libselinux (and certainly won t be in a Squeeze update). The upside of such a fix is that it would work for policy that I package as well as custom policy, so if someone wrote custom policy referring to /var/run it would automatically work with /run without any extra effort. I think that the only way to do this is to just have regular expressions that deal with this in the file contexts. It s a bit ugly and slows the relabel process down a little (probably no more than about 10%) but it will work and work on Squeeze as well. One thing I really like to do is to have the SE Linux policy for version X of Debian work with version X+1. This makes upgrades a lot easier for the users. Ideally upgrading a server could be a process that involves separate upgrades of the kernel, the SE Linux policy, and user-space in any particular order because upgrading everything at once almost guarantees that something will break and it may be difficult to determine the cause. At this time I m not sure whether I ll add a new policy using the subs file before the release of Wheezy (the next stable release of Debian) or just keep using regular expressions. I can have the Wheezy policy depend on a new enough libselinux so it won t be a problem in that regard (a new upstream version of libselinux with the subst feature should be released soon). In any case I need a back-port to Squeeze to use regular expressions to make an upgrade to Wheezy easier. for n in $(find . -name "*.fc" xargs grep var/run cut -f1 -d: uniq) ; do
sed -e "s/\/var\/run/\/(var\/)?run/" < $n > $n.new
mv $n.new $n
done
for n in $(find . -name "*.fc" xargs grep var/lock cut -f1 -d: uniq) ; do
sed -e "s/\/var\/lock/\/((var\/run) (run) (var))\/lock/" < $n > $n.new
mv $n.new $n
done
for n in $(find . -name "*.fc" xargs grep dev/shm cut -f1 -d: uniq) ; do
sed -e "s/\/dev\/shm/\/((var\/run) (run) (dev))\/shm/" < $n > $n.new
mv $n.new $n
done I used the above fragment of shell code to change /var/run to /(var/)?run , /var/lock to /((var/run) (run) (var))/lock , and change /dev/shm to /(var/run) (run) (dev))/shm . It involves a reasonable number of changes to policy (mostly for /var/run), but hopefully this will be acceptable to the release team for inclusion in the next Squeeze update as the changes are relatively simple and obvious and the size of the patch is due to it being generated code. There is one final complication, Squeeze currently has selinux-policy-default version 2:0.2.20100524-7+squeeze1, but initscripts in Unstable breaks versions <= 2:0.2.20100524-9. So I guess I could submit a proposed version 2:0.2.20100524-9+squeeze1 to the release team to fix this. I would really like to have the Squeeze policy work with initscripts from Unstable or Wheezy. Any suggestions for how to deal with this? Update: I wrote the above before testing the code, and it turned out to not work. I ve written another post describing a better solution that I have now uploaded to Unstable. I still have to sort something out with an update for Squeeze.

I use rss2maildir.py to read rss feeds, it has a nifty feature whereby if a post is changed, it just gets tacked on to a thread for that post. There are 2 things that really annoy me with rss feeds, though - 1 is the people that don't include the full post in the rss feed, and the other is people that include a comment count in the rss feed. I don't care how many comments are on the post, dammit. I'd deliberately go follow the post if I did, but having that comment count means that I get another one in the thread for NO REASON, the content of the post hasn't changed, dammit. This means that until that post drops out of the feed, every 30 minutes if the comment count has changed (and so the "content" of the feed changes) I get that post yet again and marked as new in my mailbox. Why does anyone put the comment count in the feed, does anyone really care?! If you want to link to comments from the feed, that's fine, just drop the count from it, and the content of the post wouldn't change, and I'd be happy. Erm, comments are currently turned off here, until I manage to get round to turning on all the little spam prevention fun... just thought I'd have a whinge, really!

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

just how many Space Shuttle Programs can you fund with the insane amounts of money Europe is about to spend to pull Greece out of the hole they ve dug for themselves? Same for the countries that will undoubtedly follow the same path in the coming weeks. Yeah, fuck that. Point is: there are so many better ways to spend that money (that we don t have anyway).