Over the next few weeks I'll be on the road, attending a few Free Software events and giving talks. In particular:

• during the upcoming week-end (18-19 January 2014) there will be a mini-DebConf in Paris. I'll be there to give a talk about Debsources (see schedule), participate in the Debian France plenary meeting, and meet Debian friends from all over Europe.
• two weeks later (1-2 February 2014) I'll be at FOSDEM 2014 to give a retrospective talk about legal issues that Debian has faced over the past few years, participate in a panel about Free Software governance, and meet Free Software friends from all over the world!
• the day after FOSDEM end (3 February 2014) I'll be in Antwerp for the opening keynote of the SQM workshop to discuss some of my research work at IRILL and current challenges in the field

See you "there"?

Coverity is a nice tool to find problems in C, C++ and Java code using static source code analysis. It can detect a lot of different problems, and is very useful to find memory and locking bugs in the error handling part of the source. The company behind it provide check of free software projects as a community service, and many hundred free software projects are already checked. A few days ago I decided to have a closer look at the Coverity system, and discovered that the gnash and ipmitool projects I am involved with was already registered. But these are fairly big, and I would also like to have a small and easy project to check, and decided to request checking of the chrpath project. It was added to the checker and discovered seven potential defects. Six of these were real, mostly resource "leak" when the program detected an error. Nothing serious, as the resources would be released a fraction of a second later when the program exited because of the error, but it is nice to do it right in case the source of the program some time in the future end up in a library. Having fixed all defects and added a mailing list for the chrpath developers, I decided it was time to publish a new release. These are the release notes: New in 0.16 released 2014-01-14:

• Fixed all minor bugs discovered by Coverity.
• Updated config.sub and config.guess from the GNU project.
• Mention new project mailing list in the documentation.

You can download the new version 0.16 from alioth. Please let us know via the Alioth project if something is wrong with the new release. The test suite did not discover any old errors, so if you find a new one, please also include a test suite check.

X bitmaps vs OpenGL Of course, you all know that X started life as a monochrome window system for the VS100. Back then, bitmaps and rasterops were cool; you could do all kinds of things simple bit operations. Things changed, and eventually X bitmaps became useful only off-screen for clip masks, text and stipples. These days, you ll rarely see anyone using a bitmap everything we used to use bitmaps for has gone all alpha-values on us. In OpenGL, there aren t any bitmaps. About the most bitmap-like object you ll find is an A8 texture, holding 8 bits of alpha value for each pixel. There s no way to draw to or texture from anything where each pixel is represented as a single bit. So, as Eric goes about improving Glamor, he got a bit stuck with bitmaps. We could either:

• Support them only on the CPU, uploading copies as A8 textures when used as a source in conjunction with GPU objects.
• Support them as 1bpp on the CPU and A8 on the GPU, doing fancy tracking between the two objects when rendering occurred.
• Fix the CPU code to deal with bitmaps stored 8 bits per pixel.

I thought the latter choice would be the best plan directly share the same object between CPU and GPU rendering, avoiding all reformatting as things move around in the server. Why is this non-trivial? Usually, you can flip formats around with reckless abandon in X, it has separate bits-per-pixel and depth values everywhere. That s how we do things like 32 bits-per-pixel RGB surfaces; we just report them as depth 24 and everyone is happy. Bitmaps are special though. The X protocol has separate (and overly complicated) image formats for single bit images, and those have to be packed 1 bit per pixel. Within the server, bitmaps are used for drawing core text, stippling and creating clip masks. They re the lingua franca of image formats, allowing you to translate between depths by pulling a single plane out of a source image and painting it into a destination of arbitrary depth. As such, the frame buffer rendering code in the server assumes that bitmaps are always 1 bit per pixel. Given that it must deal with 1bpp images on the wire, and given the history of X, it certainly made sense at the time to simplify the code with this assumption. A blast from the past I d actually looked into doing this before. As part of the DECstation line, DEC built the MX monochrome frame buffer board, and to save money, they actually created it by populating a single bit in each byte rather than packed into 8 pixels per byte. I have this vague memory that they were able to use only 4 memory chips this way. The original X driver for this exposed a depth-8 static color format because of the assumptions made by the (then current) CFB code about bitmap formats. Jim Gettys wandered over to MIT while the MX frame buffer was in design and asked how hard it would be to support it as a monochrome device instead of the depth-8 static color format. At the time, fixing CFB would have been a huge effort, and there wasn t any infrastructure for separating the wire image format from the internal pixmap format. So, we gave up and left things looking weird to applications. Hacking FB These days, the amount of frame buffer code in the X server is dramatically less; CFB and MFB have been replaced with the smaller (and more general) FB code. It turns out that the number of places which need to deal with individual bits in a bitmap are now limited to a few stippling and CopyPlane functions. And, in those functions, the number of individual read operations from the bitmap are few in number. Each of those fetches looked like:

bits = READ(src++)

All I needed to do was make this operation return 32 bits by pulling one bit from each of 8 separate 32-bit chunks and merge them together. The first thing to do was to pad the pixmap out to a 32 byte boundary, rather than a 32 bit boundary. This ensured that I would always be able to fetch data from the bitmap in 8 32-bit chunks. Next, I simply replaced the READ macro call with:

    bits = fb_stip_read(src, srcBpp);
    src += srcBpp;

The new fb_stip_read function checks srcBpp and packs things together for 8bpp images:

/*
 * Given a depth 1, 8bpp stipple, pull out
 * a full FbStip worth of packed bits
 */
static inline FbStip
fb_pack_stip_8_1(FbStip *bits)  
    FbStip      r = 0;
    int         i;
    for (i = 0; i < 8; i++)  
        FbStip  b;
        uint8_t p;
        b = FB_READ(bits++);
#if BITMAP_BIT_ORDER == LSBFirst
        p = (b & 1)   ((b >> 7) & 2)   ((b >> 14) & 4)   ((b >> 21) & 8);
        r  = p << (i << 2);
#else
        p = (b & 0x80000000)   ((b << 7) & 0x40000000)  
            ((b << 14) & 0x20000000)   ((b << 21) & 0x10000000);
        r  = p >> (i << 2);
#endif
     
    return r;
 
/*
 * Return packed stipple bits from src
 */
static inline FbStip
fb_stip_read(FbStip *bits, int bpp)
 
    switch (bpp)  
    default:
        return FB_READ(bits);
    case 8:
        return fb_pack_stip_8_1(bits);
     
 

It turns into a fairly hefty amount of code, but the number of places this ends up being used is pretty small, so it shouldn t increase the size of the server by much. Of course, I ve only tested the LSBFirst case, but I think the MSBFirst code is correct. I ve sent the patches to do this to the xorg-devel mailing list, and they re also on the depth1 branch in my repository

git://people.freedesktop.org/~keithp/xserver.git

Testing Eric also hacked up the test suite to be runnable by piglit, and I ve run it in that mode against these changes. I had made a few mistakes, and the test suite caught them nicely. Let s hope this adventure helps Eric out as he continues to improve Glamor.

Liberation vs expectations I feel like I found a key struggle: liberation vs expectations. Many ideas liberate me, like poliamory, atheism, anarchism, nonviolent communication, sexual liberation, discordianism, free software, nonjudgemental environments, E-prime, sillyness, love, pataphysics, dada, constructivism, rolling naked in the mud, fantasy, bdsm exploration, pansexuality, this very idea that i'm trying to describe, crying, laughing, mindfulness, what have you. Sometimes however they become an end rather than a mean, they give me expectations and judgements, and take some other freedom away. I feel like I found where to draw a line: It's the point inbetween freeing myself of my limits and making myself some new ones. It's one of those epiphany moments. Weeeeeee!

Having decided to take a fortnight off, between looking for a new job, I assumed I'd spend a while coding. Happily my wife, who is a (medical) doctor, has been home recently so we've got to spend time together instead. I'm currently pondering projects which will be small enough to be complete in a week, but large enough to be useful. Thus far I've just reimplemented RSS -> chat which I liked a lot at Bytemark. I have my own chat-server setup, which doesn't have any users but myself. Instead it has a bunch of rooms setup, and different rooms get different messages. I've now created a new "RSS" room, and a bunch of RSS feeds get announced there when new posts appear. It's a useful thing if you like following feeds, and happen to have a chat-room setup. I use Prosody as my chat-server, and I use my http2xmpp code to implement a simple HTTP-POST to XMPP broadcast mechanism. The new script is included as examples/rss-announcer and just polls RSS feeds - URLs which haven't been broadcast previously are posted to the HTTP-server, and thus get injected into the chatroom. A little convoluted, but simple to understand. This time round I'm using Redis to keep track of which URLs have been seen already. Beyond that I've been doing a bit of work for friends, and have recently setup an nginx server which will handle 3000+ simultaneous connections. Not too bad, but I'm sure we can make it do better - another server running on BigV which is nice to see :) I'll be handling a few Squeeze -> Wheezy upgrades in the next week too, setting up backups, and doing some other related "consultation". If I thought there was a big enough market locally I might consider doing that full-time, but I suspect that relying upon random work wouldn't work long-term.

Abstract I recently moved our primary nameserver from orff.debian.org, which is an aging blade in Greece, to a VM on one of our ganeti clusters. In the process, I rediscovered a lot about our DNS infrastructure. In this post, I will describe the many sources of information and how they all come together.

Introduction The Domain Name System is the hierarchical database and query protocol that is in use on the Internet today to map hostnames to IP addresses, to map the reverse thereof, to lookup relevant servers for certain services such as mail, and a gazillion other things. Management and authority in the DNS is split into different zones, subtrees of the global tree of domain names. Debian currently has a bit over a score of zones. The two most prominents clearly are debian.org and debian.net. The rest is made up of debian domains in various other top level domains and reverse zones, which are utilized in IP address to hostname mappings.

Types and sources of information The data we put into DNS comes from a wide range of different systems:

• Classical zonefiles maintained in git. This represents the core of our domain data. It maps services like blends.debian.org to static.debian.org or specifies the servers responsible for accepting mail to @debian.org addresses. It also is where all the ftp.CC.debian.org entries are kept and maintained together with the mirror team.
• Information about debian.org hosts, such as master, is maintained in Debian's userdir LDAP, queryable using LDAP¹.
  • This includes first and foremost the host's IP addresses (v4 and v6).
  • Additionally, we store the server responsible for receiving a host's mail in LDAP (mXRecord LDAP attribute, DNS MX record type).
  • LDAP also has some specs on computers, which we put into each host's HINFO record, mainly because we can and we are old-school.
  • Last but not least, LDAP also has each host's public ssh key, which we extract into SSHFP records for DNS.
• LDAP also has per-user information. Users of debian infrastructure can attach limited DNS elements as dnsZoneEntry attributes to their user².
• The auto-dns system (more on that below).
• Our puppet also is a source of DNS information. Currently it generates only the TLSA records that enable clients to securely authenticate certificates used for mail and HTTPS, similar to how SSHFP works for authenticating ssh host keys.

Debian's auto-dns and geo setup We try to provide the best service we can. As such, our goal is that, for instance, user access to www or bugs should always work. These services are, thus, provided by more than one machine on the Internet. However, HTTP did not specify a requirement for clients to re-try a different server if one of those in a set is unavailable. This means for us that when a host goes down, it needs to be removed from the corresponding DNS entry. Ideally, the world wouldn't have to wait for one of us to notice and react before they can have their service in a working manner. Our solution for this is our auto-dns setup. We maintain a list of hosts that are providing a service. We monitor them closely. Whenever a server goes away or comes back we automatically rebuild the zone that contains the element. This setup also lets us reboot servers cleanly since one of the things we monitor is "is there a shutdown running", we can, simply by issuing a shutdown -r 30 kernel-update, de-rotate the machine in question from DNS. Once the host is back it'll automatically get re-added to the round-robin zone entry. The auto-dns system produces two kinds of output:

• In service-mode it generates a file with just the address records for a specific service. This snippet is then included in its zone using a standard bind $INCLUDE directive. Services that work like this include bugs and static (service definition for static).
• In zone-mode, auto-dns produces zonefiles. For each service it produces a set of zonefiles, one for each out of a set of different geographic regions. These individual zonefiles are then transferred using rsync to our GEO-IP enabled nameservers. This enables us to give users a list of security mirrors closer to them and thus hopefully faster for them.

Tying it all together Figure 1: The Debian DNS Rube Goldberg Machine. Once all the individual pieces of source information have been collected, the dns-update and write_zonefile scripts from our dns-helpers repository take over the job of building complete zonefiles and a bind configuration snippet. Bind then loads the zones and notifies its secondaries. For geozones, the zonefiles are already produced by auto-dns' build-zones and those are pulled from the geo nameservers via rsync over ssh, after an ssh trigger.

and also DNSSEC All of our zones are signed using DNSSEC. We have a script in dns-helpers that produces, for all zones, a set of rolling signing keys. For the normal zones, bind 9.9 takes care of signing them in-process before serving the zones to its secondaries. For our geo-zones we sign them in the classical dnssec-signzone way before shipping them. The secure delegation status (DS set in parent matches DNSKEY in child) is monitored by a set of nagios tests, from both [dsa-nagios] and dns-helpers. Of these, manage-dnssec-keys has a dual job: not only will it warn us if an expiring key is still in the DSset, it can also prevent it from getting expired by issuing timly updates of the keys metadata.

Relevant Git repositories

• domains
• auto-dns
• mini-nag
• dns-helpers
• puppet
• nagioschecks

-- Peter Palfrader

---

1. ldapsearch -h db.debian.org -x -ZZ -b dc=debian,dc=org -LLL 'host=master'
2. ldapsearch -h db.debian.org -x -ZZ -b dc=debian,dc=org -LLL 'dnsZoneEntry=*' dnsZoneEntry

Ruby has a reputation for being slow. But there s slow, and then there s three seconds to show the help for a fairly command line program . That s not slow, that s ridiculous. The gem cleanup command is the solution. Rubygems has a nice feature whereby you can have multiple versions of a gem installed at once. That s neat, because it allows programs with different gem version requirements to co-exist on the system. Unfortunately, over time, you can end up with many versions of a gem installed, as upgrades pull in ever-newer versions of all your gems. Couple this accumulation of cruft with a need for Rubygems to look at every one of them on every startup, and you can see how you could very quickly end up with a three second startup time. By running gem cleanup, you ll have the opportunity to nuke all the out-of-date versions of your gems. It takes into account dependencies, so it will at least ask you before nuking a gem that another gem absolutely depends on (I d prefer a command-line switch to say, Don t even think about uninstalling something that another gem depends on! , but you can t have everything). If you ve got non-gem things on your system that rely on out-of-date gems (anything using bundler, for instance), those will assplode the next time you run them, but you can always re-run bundle install to get just the specific versions of gems back you need. The end result of my little spring cleaning? Down from three seconds to three quarters of a second. A 75% improvement. Win!

Today (well, technically yesterday by now), the Media were reporting of an open letter by '5 belgian university professors from the IT field' without calling them by name about how Belgian primary education should introduce programming into the curriculum, starting at age 5. Unsurprisingly, this did not go well with a majority of the Belgian populace. Arguments like "what should the school drop to make place for that, then" and "why would people ever need to learn programming" were rampant on some internet fora that I had a short look at. That being said, though, I think these five unnamed professors are correct. Understanding how a tool works is essential to proficient usage of said tool; and while it is possible to teach particular common and popular use cases of a given tool without providing enough background, doing so will only result in confusion when the computer "is acting up" an oxymoron if there ever was one. After all, a computer can't "act up"; it can only follow instructions. Whenever your seems to be "acting up", what's really happening is that someone (most likely, you) gave it the wrong instructions. Or, perhaps, someone evil on the Internet gave it the right instructions (for their goals, anyway) and infected your computer with a virus. But that's unlikely. Computer education currently mostly consists of "teaching software": rather than explaining how a computer does what it does, people are taught that if you click this button, the text will be bold, or if you click that button, the printer will start buzzing. That's all nice and dandy, until the actual computer people encounter when off the school bench and at work has this other piece of software, where all the buttons are in other places and look all "wrong". Because then they get all confused about the fact that things aren't where they're supposed to be. So, yes, it is my opinion that any computer education should help people understand how a computer does the things it does. And what better way to do that than to actually explain things to a computer, the way computer programmers do such things? Note that programming a computer doesn't have to be hard, and it can be something which kids can understand and will find fun to do. For instance, there's this scratch thing from MIT, which was made for teaching programming in such a context. Yes, adding programming to the primary school curriculum will require that some other things are dropped instead, and I could see that being a problem. However, in our modern world computers have become so pervasively important that we would be doing our kids a disservice not to explain them how to understand computers, as opposed to just learn how to use them...

cjac@foxtrot:/usr/src/deb/strongswan-5.1.0$ ping6 -c 5 google.com tail -3
google.com ping statistics
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 65.235/74.957/103.039/14.122 ms go go gadget ipsec

I have written a number of scripts to create Debian foreign architecture (mostly armel and armhf) rootfs images for SD cards or NAND flashing. I started with putting Debian on my Openmoko gta01 and gta02 and continued with devices like the qi nanonote, a marvel kirkwood based device, the Always Innovating Touchbook (close to the Beagleboard), the Notion Ink Adam and most recently the Golden Delicious gta04. Once it has been manufactured, I will surely also get my hands dirty with the Neo900 whose creators are currently looking for potential donors/customers to increase the size of the first batch and get the price per unit further down. Creating a Debian rootfs disk image for all these devices basically follows the same steps:

1. create an disk image file, partition it, format the partitions and mount the / partition into a directory
2. use debootstrap or multistrap to extract a selection of armel or armhf packages into the directory
3. copy over /usr/bin/qemu-arm-static for qemu user mode emulation
4. chroot into the directory to execute package maintainer scripts with dpkg --configure -a
5. copy the disk image onto the sd card

It was not long until I started wondering why I had to run all of the above steps with superuser privileges even though everything except the final step (which I will not cover here) was in principle nothing else than writing some magic bytes to files I had write access to (the disk image file) in some more or less fancy ways. So I tried using fakeroot+fakechroot and after some initial troubles I managed to build a foreign architecture rootfs without needing root priviliges for steps two, three and four. I wrote about my solution which still included some workarounds in another article here. These workarounds were soon not needed anymore as upstream fixed the outstanding issues. As a result I wrote the polystrap tool which combines multistrap, fakeroot, fakechroot and qemu user mode emulation. Recently I managed to integrate proot support in a separate branch of polystrap. Last year I got the LEGO ev3 robot for christmas and since it runs Linux I also wanted to put Debian on it by following the instructions given by the ev3dev project. Even though ev3dev calls itself a "distribution" it only deviates from pure Debian by its kernel, some configuration options and its initial package selection. Otherwise it's vanilla Debian. The project also supplies some multistrap based scripts which create the rootfs and then partition and populate an SD card. All of this is of course done as the superuser. While the creation of the file/directory structure of the foreign Debian armel rootfs can by now easily be done without superuser priviliges by running multistrap under fakeroot/fakechroot/proot, creating the SD card image still seems to be a bit more tricky. While it is no problem to write a partition table to a regular file, it turned out to be tricky to mount these partition because tools like kpartx and losetup require superuser permissions. Tools like mkfs.ext3 and fuse-ext2 which otherwise would be able to work on a regular file without superuser privileges do not seem to allow to specify the required offsets that the partitions have within the disk image. With fuseloop there exists a tool which allows to "loop-mount" parts of a file in userspace to a new file and thus allows tools like mkfs.ext3 and fuse-ext2 to work as they normally do. But fuseloop is not packaged for Debian yet and thus also not in the current Debian stable. An obvious workaround would be to create and fill each partition in a separate file and concatenate them together. But why do I have to write my data twice just because I do not want to become the superuser? Even worse: because parted refuses to write a partition table to a file which is too small to hold the specified partitions, one spends twice the disk space of the final image: the image with the partition table plus the image with the main partition's content. So lets summarize: a bootable foreign architecture SD card disk image is nothing else than a regular file representing the contents of the SD card as a block device. This disk image is created in my home directory and given enough free disk space there is nothing stopping me from writing any possible permutation of bits to that file. Obviously I'm interested in a permutation representing a valid partition table and file systems with sensible content. Why do I need superuser privileges to generate such a sensible permutation of bits? Gladly it seems that the (at least in my opinion) hardest part of faking chroot and executing foreign architecture package maintainer scripts is already possible without superuser privileges by using fakeroot and fakechroot or proot together with qemu user mode emulation. But then there is still the blocker of creating the disk image itself through some user mode loop mounting of a filesystem occupying a virtual "partition" in the disk image. Why has all this only become available so very recently and still requires a number of workarounds to fully work in userspace? There exists a surprising amount of scripts which wrap debootstrap/multistrap. Most of them require superuser privileges. Does everybody just accept that they have to put a sudo in front of every invocation and hope for the best? While this might be okay for well tested code like debootstrap and multistrap the countless wrapper scripts might accidentally (be it a bug in the code or a typo in the given command line arguments) write to your primary hard disk instead of your SD card. Such behavior can easily be mitigated by not executing any such script with superuser privileges in the first place. Operations like loop mounting affect the whole system. Why do I have to touch anything outside of my home directory (/dev/loop in this case) to populate a file in it with some meaningful bits? Virtualization is no option because every virtualization solution again requires root privileges. One might argue that a number of solutions just require some initial setup by root to then later be used by a regular user (for example /etc/fstab configuration or the schroot approach). But then again: why do I have to write anything outside of my home directory (even if it is only once) to be able to write something meaningful to a file in it? The latter approach also does not work if one cannot become root in the first place or is limited by a virtualized environment. Imagine you are trying to build a Debian rootfs on a machine where you just have a regular user account. Or a situation I was recently in: I had a virtual server which denied me operations like loop mounting. Given all these downsides, why is it still so common to just assume that one is able and willing to use sudo and be done with it in most cases? I really wonder why technologies like fakeroot and fakechroot have only been developed this late. Has this problem not been around since the earliest days of Linux/Unix? Am I missing something and rambling around for nothing? Is this idea a lost cause or something that is worth spending time and energy on to extend and fix the required tools?

Hello, World! Docker s in Debian! Isn t that great! Let s all get happy! It s called docker.io, so go ahead and sudo apt-get install docker.io whenever you want :) The first two uploads have a few errors, which are 100% my fault. The first were a set of FTBFS bugs, which were a stupid error on my part. Thanks to olasd for catching the remaining bug, related to stripping the binaries. I m so sorry this happened, it slipped through as a result of me having a local docker binary in /usr/local, which I tested completely before uploading a totally different binary. I won t let it happen again. It should be fixed now. However, this comes with a warning. It appears as though systemd (which, for the record I adore) is allowing lxc-start unmount /dev/pts and friends, which causes a bunch of damage to the host. I ve filed the bug as bug #734813. Currently the outdated mount(1) is holding back a workaround. Hopefully we get util-linux updated so we can hack around this in the short-term. Hopefully the bigger issues get solved. So, if you re a systemd user, please hold off on using docker.io until we resolve this issue in Debian.

Valve Software s Steam is the number one digital game distribution service, with more than 65 million registered accounts. Steam runs on Windows, Mac OS, and Linux x86/amd64 computers, and provides access to several thousand games, at varying price points an enormous growth from less than a dozen games for Windows only about a decade ago. Valve s latest endeavour has been to bring their storefront into the living room, with a three-pronged attack: a new game controller, a programme of licensed x86 consoles to plug into the family TV, and an OS to run on the Steam Machines to tie it all together. December saw the first public release of their SteamOS which, as it turns out, is basically just a preconfigured desktop Linux. Specifically, it s a Debian Wheezy derivative, comprising a subset of 502 source packages from Wheezy; 8 of Valve s own source packages; and 51 source packages which have been either patched compared to Wheezy, backported from post-Wheezy, or both. For example, the compiler used by default is gcc-4.7 (rather than Wheezy s 4.6) and the libc version postdates Wheezy too. Valve s official instructions and installer release concerned quite a few people who had planned to try SteamOS on an older PC, by mandating a large (500GB) hard disk and a PC with UEFI firmware. Very quickly a number of instructions started appearing from people trying to fix what people felt were real issues specifically provision for BIOS-based computers, and installation from optical media. After being assured that redistribution of derivatives of SteamOS were entirely authorized (and, in fact, encouraged) I decided to produce my own variant, calling upon my own experience with debian-installer modification from past and present jobs, as well as calling upon the skills and experience of the UK Debian community as needed. The end result is Ye Olde SteamOSe. This weekend saw the third release of Ye Olde SteamOSe, a derivative designed to greatly widen the pool of computers capable of running Valve s OS. And unlike the first two releases, the public response this time has been crazy. Like, totally crazy. Combined score across several subreddits totals about 1700. 7 pages of Google search results. Hundreds of tweets. Mentions in dozens of blogs around the world. Coverage on the Linux Action Show. Unilaterally added to Softpedia s list of distributions. Almost 2000 views of a video installation walkthrough I posted on YouTube. Crazy. Sadly the idea to try and track visitors to the page didn t occur to me until long after the initial rush subsided, but 1000 visitors on Tuesday for a news story which landed on Sunday is still pretty hot in my book. It s also interesting to observe the demographics of site visitors the #1 referrer on Tuesday was Dutch PC site Tweakers.net, and StumbleUpon outranks reddit for referrals. About 66% of visitors interested in installing my Debian Wheezy derivative derivative came using Windows (20% using Linux), which suggests there s a lot of potential Linux users out amongst the Windows gamer masses. So what s the purpose of this self-congratulatory blog post? Just dick-waving? Well, there s an element of that (I m only human), but I think it might be nice to alert the audience on Planet Debian/Ubuntu, many of whom are not big gamers, to the next big thing in embedded Linux except this time a real GNU/X.org/sysVinit distribution, not some NIH thing like Android. So now you know!

Please excuse the intrusion to your usual software and co-op news items but vine seems broken and as part of my community and democratic interests, I d like to share this short clip quoting Norfolk s Deputy Police Commissioner Jenny McKibben about why Commissioner Stephen Bett believes it s important to get views from the west of the county about next year s police budget: Personally, with a King s Lynn + West Norfolk Bike Users Group hat on, I d like it if people supported a 2% ( 4/year average) tax increase to reduce the police s funding cut (the grant from gov.uk is being cut by 4%) so that we re less likely to have future cuts to traffic policing. The consultation details and response form are on the PCC website.

It's almost a month since I last blogged something, and one of my new year's resolution is to change that, a bit. Let's see how it goes. I've been listening a lot to this great band from Sweden recently again, put all their songs onto my mobile phone. It might sound weird because they have a rather aggressive style, both soundwise but also lyricswise, but it helps me to get things off my chest and stay relaxed in the rest of my life. The band I want to present to you was already twice mentioned in some other articles of my blog I noticed, but this is the proper post about them: I'm talking about Clawfinger. They came up in the nineties during the crossover phase and did blend in pretty well, but it's mostly their direct and political statements they carry in their lyrics that did let them stand out. One warning though: the direct language they use might be considered blunt and maybe even offensive by some. The message behind it though should rather get you thinking of your own doings if you consider it to be offensive. Here are the songs:

• What Are You Afraid Of: Most people would have probably gone with their first hit for the topic, but I think this song transports the point extremely well too: It's just a color and I'm color blind, the only color I know is the color of my mind. There's only one race and that's the human race, and every human being's got the right to feel save.
• The Faggot In You: Well, it's like Coyote Too twittered or Andy Singer drew it. Get over it and think about what actually stirs these emotions in you. If you're so sure and you feel secure about yourself and your reality, then why do you need reject and refuse where other people stand sexually?
• Life Will Kill You: Let's face the fact, it will. ... and given the choice between your own life and death I suggest that you cherish the time you have left 'cause time waits for noone and we're all growing older. Life for today, not for a future that might never come.

Like always, enjoy! And maybe also think about it a bit. :)

/music permanent link Comments: 4 Flattr this

Review: Honeyed Words, by J.A. Pitts

Series:	Sarah Beauhall #2
Publisher:	Tor
Copyright:	July 2011
ISBN:	0-7653-2907-7
Format:	Trade paperback
Pages:	412

Honeyed Words is a direct sequel to Black Blade Blues and probably doesn't make sense to read out of order. Sarah, Katie, their friends, and Katie's family are still recovering from the climactic events of Black Blade Blues and licking their wounds, but things are slowly looking up. Sarah is getting more comfortable openly expressing her sexuality, although there are still tensions, and her relationships are improving. The city of Vancouver also seems to be recovering. But major political shifts among the nonhuman races have echoes and ramifications, and after a kidnapped singer and a murdered dwarf, Sarah is pulled back into the turmoil. If you liked the world-building in Black Blade Blues, Honeyed Words is more of the same, but with more variety. Pitts adds elves to dwarves and dragons, shows considerably more of the supernatural world beneath the surface of human cities, and introduces Sarah to some new types of danger. There are a few more glimmers of the history of Sarah's sword and the nature of the gods in this universe, but still nothing conclusive. Pitts broadens the world-building rather than deepening it. But I liked the new characters. Teenage elves with obsessions make for great characters, and the demon who shows up about halfway through is delightful. As with the first book, this is mostly a story of things happening to Sarah while she tries to muddle through as best she can. There isn't much in the way of grand strategy or of seizing control of the plot. She just tries to do the right thing and gets lots of help from lots of friends. But the plot moves right along, and it's mixed with a healthy sense of normality that I find refreshing. She needs work as a blacksmith, she's trying to support a friend without having much money of her own, the living arrangements this forces are a bit of a strain for her own relationships, and her broken relationship with her family continues to lurk. Much urban fantasy is built around the premise of a regular person thrust into a fantasy world, but much of it then discards normal life once the supernatural starts. I think Pitts does a particularly good job of keeping his protagonist's life grounded in the ongoing mundane problems of living. It's also more fun to read about Sarah when she isn't quite as angstful. Over the course of Honeyed Words, she seems to be growing into a person who can accept who she is and feel secure about her place in the world. That's nice to see. The downside to this book is that, while it's full of quite a lot of stuff, not all of it coheres that horribly well. It has a certain "middle book" feel. The major plot resolves, but with some significant lingering consequences and something of a cliff-hanger last chapter. Most of the threads left open by the first book are still open here. There's character growth, and setup for some resolution, but not a lot of actual resolution. I still like this series, though. I like urban fantasy that isn't about vampires and werewolves; berserker blacksmiths and Norse legend has much more appeal, and I want to read more of it. Pitts's writing is a bit clunky and probably won't win many rewards, but it's serviceable and I think improving. If you enjoyed the first book, it's worth looking for this one as well. Followed by Forged in Fire. Rating: 7 out of 10

Packt Publishing sent me Krzysztof Niki ski's Instant Haml to do a short blog review... Thing is, and those who read me know, I cannot write short reviews ;-) So lets see how this goes. Packt's Instant series First, as for the format this book follows and the series it fits in: They are very short books. I was the tech reviewer for their Instant Debian Build a Web Server , and when I opened it for the first time, I thought I had received only the first chapter. This series' motto is Short Fast Focused so, yes, the books are ~50 pages long, with ample margins and many big screenshots. I told the editors I was quite unsure about the value this kind of publications add, as they are very similar to online tutorials, but given they have so many books in this series (printed and electronic), there must be a market for them. They surely know their business better than me! There is one other detail regarding the publisher I'll stick in this section, although it is not specific to their Instant series: I do most of my reading in my Kindle. Packt seems to have chosen to specify a very small font for their texts. Besides the two books mentioned, I also have their Object Oriented JavaScript book. For all of the other books I read, I use the smallest font setting. Packt books in mobi format (what they present as Amazon format in their web site) are basically illegible without bumping up the font size through the roof. As I understand it, publishers should use industry-wide default sizes, and let the reader adjust their reading experience. Yes, books of technical nature (such as Packt's) often benefit from having more displayed information than what an ebook reader normally shows... But that's for me to decide! And no, this is not a Kindle-specific glitch: I also get a similar experience when opening it from Calibre. And as for the book... I am a long-time Haml convert/fan; I packaged its Ruby implementation for Debian (and should update it soon :-/ as new versions have appeared), the corresponding Emacs Lisp mode, and I use it for basically all of my static HTML sites and Ruby-based Web systems. Haml is a great templating language, meant to make dynamic HTML generation leaner and easier. It is a clean and elegant technology, and can clearly sell itself. And the project webpage has very good documentation, ranging from a short tutorial and a full API documentation for people to contribute to the project. The first part of this book, of course, covers the "why is Haml so great?" part, presenting the basic equivalences with HTML. In my opinion, the book could be structured a bit differently and would generate a stronger following. Why? Because, even given that Haml is greatly benefited from its Ruby integration and has many hooks to be tightly integrated in a Rails workflow, it can also be used by people who don't want to do Ruby. I have some static websites that are just a bunch of Haml files, compiled by a very simple Makefile and calling the haml command from the shell. I think there would be some value in presenting this invocation before learning how to call it from the Gems environment (i.e. bundle install). Using Haml as a standalone tool is only presented almost as an appendix ("Using HAML outside of Rails" section). Even more so if the author presents four different static-site solutions (probably more non-programmer-friendly than my trusty Makefile). Oh, and this little section uses the (old? obsolete?) uppercase HAML notation for the project's name instead of the now-standard Haml. Dirty screenshots About the screenshots presented in this first section (and I refer mainly to the scaffolding examples), they are meant to show how easy things are, but have an important stylistic mistake: Terminals with transparency might look cool (I hate using them, but then again I'm a very boring person when it comes to my computer habits ;-) ), but transparencies have no place in a book (be it printed or e-book), as the images appear very uncrisp. In the Kindle, they just seemed dirty Now that I'm browsing the PDF from my desktop, I see that the screenshot in "Step 1" has a photo of Earth from space behind the terminal, and even worse, in "Step 2" it is shown over a Web page detailing the installation! These elements are just distracting, and the text would be much cleaerer if it were presented typeset just as a regular code fragment. Opening many of those screenshots in the Kindle was plain useless. Editor integration It is perfectly clear from this text that the author strongly prefers Sublime Text, sometimes uses TextMate, and has just heard reports that Haml has some support in Vim, Rubymine, Emacs and Coda. Of course, devoting a full page (as it is for the first case) for each editor would be out of proportion for this size of book... I just felt the imbalance too big, specially given that most editors will sport approximately the same feature set. Text redundancy If the Instant series is about making short books, I would expect them to be loaded with easy to follow content (as they are), but free of repetition. I felt, however, a large chunk of step 1 of the "Quick start" chapter to be repeated with the the first section of the "Top 6 features" chapter. Yes, the second one adds some depth, but very little. Still, in the later parts of this "Top 6 features" chapter, a more thorough explanation could be used for the Filters, Multiline attributes/code/strings and helpers and extensions sections. It seems the author was on a hurry trying to get it finished, as it is barely explained Explaining a bit more deeply would surely benefit readers. Wrapping up Reading my review, I'm mostly talking about negative issues. IMO, the book is not excellent, but it is clearly not bad. Specially given it fits very well the format for which it was designed. There are many items that could be fixed, and I hope some of them can be fixed (i.e. the screenshots) before the book goes to print If I understand Packt's page correctly, it is currently only available as ebook, contrary to most of the Instant series' titles.

Qt and KDE will be present at FOSDEM, the largest open-source event in Europe. One more year, we will be sharing the Desktops DevRoom with Gnome, Unity, Enlightenment, LXQt and Hawaii (a Qt Quick desktop environment). We recently published the schedule for the devroom, which will be also available in the printed booklet available at the front desk. For the 2014 edition, the FOSDEM organization wants to achieve 100% recording of presentations. That means every presentation, in every room (devroom, lightning talk, main conference, etc) must be recorded. That s hundreds of talks. While the FOSDEM and devrooms organization teams comprise a lot of people, we are far too busy already with the organizative stuff and cannot spend time doing the actual recordings. Good thing is, you can help! Do you want to join the FOSDEM Video Team and receive the t-shirt? We are now looking for volunteer cameramen (and camerawomen, of course ). FOSDEM will provide you with equipment and training, you only need to start recording, focus, make sure nobody gets between the camera and the speaker/stage, etc. You do NOT need to record the whole track, even one talk recording would help. More details on what will be required from you are available in this e-mail from Wouter. Please contact me (pgquiles at elpauer dot org) if you are interested in recording one or more presentations from the Desktops DevRoom.

Ok, so I'm back in Mexico! This year, the best fare I found for travelling to spend the Winter^WSummer season with Regina's family had an oddity: I usually have a layover at either Santiago de Chile or Lima (Per ) of between 45 minutes and 2 hours, clearly less than enough to do anything. But this time, I had a massive 10 hours layover in Santiago. And spending 10 hours in an airport is far from fun. Specially when you have a good group of friends in town! I visited Chile in 2004 for Encuentro Linux (still before the time I had a digital camera: Those photos are all taken by Martin Michlmayr), and I have stayed in touch with a group of systems administrators since then. So, I mailed the list, and we managed to get eight people to have lunch together. In the order we appear in the photo:

• Victor Hugo dos Santos
• Mauricio Troncoso
• lvaro Herrera
• Ricardo Lemus
• Marcelo Riquelme
• Carlos Sep lveda
• Gunnar Wolf
• Pablo Silva

Some of them, even living in the same city, had never met in person before So, of course, we had a table reserved at the restaurant to the name of Dennis Ritchie. And having had nice, fun, sometimes-technical talks... Well, a tiny bit of his spirit was there. Of course, we can only trust he was there, as no Ouija boards were used and no null pointers were dereferenced (just to make sure not to disturb him). Victor Hugo and lvaro took me for a short Santiago city trip before lunch, we had a very nice time. Thanks! :-)