X61s (1)

I’ve been the lucky owner of a Thinkpad X61s for a bit more than a week now. It’s a light and small 12.1 inch notebook. It’s structurally very solid and has got almost the same full size keyboard as my 14.1inch T60. (The enter, tab, shift and alike keys are shortened in width).

The installation of Gentoo went quite smooth. For those interested the xorg.conf, make.conf and kernel .config I use.

Internal mic/speaker and external jacks; video; DRI and AIGLX; USB; PCMCIA; wireless; fingerprint reader and ethernet all seem to work just fine. I haven’t tested the firewire, ssd slot, bluetooth and n-capabilities of the wireless yet.

In comparison with my T60 the volume and the backlight buttons aren’t hardware controlled. Gnome recognizes the volume buttons, but not the backlight ones. I’m still working on those.

Fosdem (2)

I have just returned from Fosdem 2008. The trip by car to Bruxelles was by Dutch standards quite long, 3 hours. Volker, who did the hotel bookings for the FSFE, was kind enough to also book a room for me and my brother. For the 3-star hotel, which normally would cost you 200,– per night, we only had to pay about 70,– p/n. I did expect group discount, but that it would be so enormous was a surpise. I’m not complaining though :).

After the check-in we went for a quick diner and straight of to the Delirium Café for the “Beer Event”. The café, even though it’s the largest one I’ve ever visited, was barely big enough for the masses of geeks. One could buy a ‘red dot’ from one of the organizers for 20,– euros. With it you can order any beer (one of the 25 on the tap) at the bar without paying until you spend the 20,– euros. This wasn’t checked though. I feel it hard to imagine, and my head felt even harder the next morning, that one would consume more. On that next morning the real magnitude of the conference became apparent. The first talk, at a large (really, large) college room at the Free University of Bruxelles, was attended by at least a thousand if it weren’t two-thousand people.

The talk about Perl 6 was the most interesting for me. I didn’t really like Perl <5 primarily because of having too many ways to do the same in exactly the same way but with a different syntax. I knew that Perl 6 was a total and backwards incompatible redesign of the language, build on top of a generic and good virtual machine called Parrot. Parrot, which I hadn’t given a proper look yet, turned out to be a lot greater than expected. You write support for a new language in Parrot by writing in a subset of Perl 6, which with it’s new Regular Expressions and specializations (tokens: regex without backtracking, etc), was looking very suited for it.
Except for all the new syntactic very very sweet sugar (on which I won’t (yet) elaborate) they added in Perl 6, the greatest one (which is actually more of a Parrot thing) is being able to extend Perl during runtime: writing new parser rules. One application is being able to define ‘!’ as a faculty operator. I’m itching to play with it.

Another very interesting talk was the one about Gallium3D, which is an effort to rework the 3D API on Linux and Xorg for 3D accelerator drivers. It primarily abstracts most of the operations of the video card to being a very specialized language processor and not entirely surprising makes heavy use of the llvm. The abstraction was effective enough to being able to take a driver originally written for Linux, rework it for Gallium3D and actually being able to be run on a Windows version of Gallium. That it runs on Windows really can’t bother that much people. That it also now runs on Cell’s SMP’s, can. The speaker joked that one finally can play 3D games on your PS3 [ on Linux ].

Most of the talks I attended were pretty interesting. Most of the speakers, though, weren’t that great speakers. The thing I missed most with FOSDEM was that there was no easy way to get in touch with people of a certain project. There were booths of a lot of projects, but there the people behind the booth were just standing there to show you stuff in the hallway that was too narrow. There were separate rooms for projects where there were talks given about the project, but there was no real time in between. A few hours nothing but people of the project meeting in a project room would have been great.

Miscellaneously, the OLPC is a great toy; the EEE is even uglier than it looks on the web; the MacBook Air is even thinner than you think and the FSFE people with whom we stayed at the hotel were great. I could tell a lot more, but quite frankly I’m very tired and sleep calls.

Codeyard 2008

Codeyard is a project of the RU to stimulate high school students for Free and Opensource Software in the Netherlands. Primarily they offer hosting and guidance for setting up projects. They also organize (great!) monthly meetings at the university where participants meet.

To motivate people to join, they organize a yearly award sponsored by Capgemini for the best project. With a friend, Noud, and my brother Bram we participated in their first year (2006) and won the award. This year, I have the honor to join as a member of the jury.

If you’re interested, you can visit one of the “community days”. The next one is this Saterday. There will also be a presentation by the people who cracked the “OV-kaart”, which should be quite interesting.

Bye bye Reiser4

A few days ago my root partition (formatted Reiser4) corrupted on my notebook. [ the usual IO hangups and nasty output in dmesg ]. Probably due to the usual wear and tear a notebook has to suffer or a faulty suspend cycle causing bogus IO. Something I suffered a few times before and didn’t think it would be a great deal. This time, though, fsck.reiser4 said it was all ok. That meant I was pretty screwed, for I knew it didn’t work correctly.

I lended a USB hdd, booted up to a fallback installation on a separate ext2 partition and tried to copy over everything to the USB hdd. It was quite tricky to copy over as much as I could and remembering the point where it started to crash when reading it. Luckily, I salvaged my whole /home. /var, /bin, /usr/share and a lot of other trees weren’t that lucky.

Formatted to XFS, copied everything I got back to the HDD and copied a Gentoo stage 3 tarball over it. A stage 3 tarball contains a minimal installation to which can be chrooted and then booted and from which the rest of the system can be build: the usual method to install Gentoo. I didn’t lost my world nor /etc/make.conf file. A small script later I got portage re-emerging every package I had installed on the system. Still 200 to go at the moment, but at least I’m now in a partially functioning gnome desktop, which is a lot more usable than TWM (ugly default WM of Xorg).

XFS performs quite well. It’s latency under load is a lot smaller than Reiser4’s. (It’s a pity I haven’t yet come to try the new patches in mm to help Reiser4 a bit with that problem. And also becasuse Reiser4 seems so close to inclusion, reading Andrew’s merge plans). In contrast, XFS sucks at handling a lot of small files compared to Reiser4. This is all just a feeling though. I haven’t tested anything. The most important characteristic of a FS, though, is only apparent after long use: the influence of fragmentation. Having looked around a bit, btrfs seems interesting.

On a sidenote on latency: my mom runs Ubuntu with EXT3 and even though EXT3 sucks in practically every single performance benchmark it has seem to got a superb responsiveness. Ah, 150 packages to go.

Linux 2.6.24-bw-r34

Again an update for my bw-tree. There isn’t a tree that includes reiser4 and TuxOnIce without a lot of other bloat, so I created one myself.

Download the big diff or the seperate patches broken out.

Note I pulled in new patches for reiser4 from the -mm tree against -rc8 which should fix the Reiser4 flush problem a bit.

Update Patched against 2.6.24 stable. New TuxOnIce patched added and the genpatches. Please note that I haven’t tested Reiser4 thoroughly enough on this version.


Tickle is a small Python serializer like Pickle. It however aims at generating smaller output:

>>> len(tickle('hello'))
>>> s = StringIO.StringIO()
>>> pickle.dump('hello', s)
>>> len(s.getvalue())

Though the difference is and remains quite small, this alone is useful for serialization of small things in the case of for instance RPC. However, usually you already know what kind of data to expect and you don’t really bother about the type information. This can be done by specifying a template:

>>> obj = []
>>> for i in xrange(100):
       obj.append((i, str(i)))
>>> len(tickle(obj))
>>> len(tickle(obj, template=(tuple, \
   ((tuple,((int,), (str,))),)*100)))

(Instead the *100 an iterator could be constructed, but that would clutter the example even more than it already is.) In comparison:

>>> s = StringIO.StringIO(); pickle.dump(obj, s)
>>> len(s.getvalue())

One big disadvantage of Tickle is speed. Pickle has got a nice C implementation, which is quite fast. Psyco helps a bit but not really enough for really big things. Even more so pickle is a bit smarter: it builds a LUT for instances to avoid duplicate data. However, in the situations where Tickle will be used (by me at least) that isn’t too big of an issue.

You can download tickle.py via gitweb.


CaCert is a Certification Authority that works with a web of trust: people meet and assure (similar to keysigning) eachother. If you’ve been assured by enough people you’ll be able to let your ssl server key be certified by cacert. It’s a lot more secure than other CA’s who just give anyone a certificate who pays enough.

Still a hierarchical system with a CA is flawed. When the CA is compromised, the whole system fails. PGP’s web of trust hasn’t got this weakness.

(Got a nice shiny cacert certified ssl certificate on my webserver now)

Virtual packages in python

When writing an application in python, it can be very convenient to be able to import a module from the top of your module tree. Eg. import myapp.config instead of (python 2.5 only) relative imports: import ....config. To do this one would have to make myapp a package. The normal way to do this is to put your application directory (which now has to be named myapp) somewhere in python’s package search path. This isn’t all to convenient.

The solution: manually set up your package module:

import os
import sys
import imp
def setup_virtual_package(name, path=os.curdir):
    """ Sets up a package at the given path with a given
     name """
    modulePath = os.path.abspath(path)
    f, fn, suffix = imp.find_module('__init__',
    imp.load_module(name, f, fn, suffix)
    sys.modules[name].__path__ = [modulePath]

Now import myapp.something works like a charm.

Stupid PHP (1) (Strings are faster than Arrays)

When I slowly build a big string out of little bits, the worst thing to do in most languages is to just use string concatenation:

for(something) {
 str .= little_bit;

Why? Everytime a little bit is added to str, there must be a new string allocated big enough to contain str and the new little bit. Then the actual str must be copied in. In most languages there are constructs to efficiently build strings like this instead of concatenating. StringBuffer in C#. StringIO in Python.

But no, PHP has to be stupid. There is no nice construct and you’ll end up using concatenation. So, I thought to be smart and make use of PHP array’s and implode. Arrays are here for having elements added and removed all the time so they are properly buffered and should be great at having lots of small elements added. And when I want to pack it all into one big string, I can use PHP’s builtin implode function.

I wanted to try it out and created two scripts: a.php concats a little (10byte) string one million times and b.php appends it to an array and then implodes it. And because I’m also interested in the performance of implode I got a script c.php that’s identical to b.php but doesn’t implode afterwards. These are the results:

a.php (concat) 0.320s
b.php (array append and implode) 0.814s
c.php (array append) 0.732s

Indeed, string concatenation with all its allocation and copying is actually faster than plain simple array appending. PHP is stupid.