Recently, I’ve tried to download a torrent containing several individual files using bittornado and the download stalled at something like 99%, so I needed to check, which of the individual files were downloaded completely. An apt-get search lead to cfv, a versatile file checksum creator and verifier.

$ sudo apt-get install cfv
$ btshowmetainfo foo.torrent

You now get the torrent’s contents listed, cd into the directory containing the listed files.

$ cfv -f foo.torrent

The files are now checked, and the incomplete files will be listed.

Accorring to Greenspun’s Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp.

That guy’s damn right! I think that I’ve just implemented one.

Because I needed USB speakers for my Alix board, I’ve made a quick search on geizhals.at and ordered what seemed the most reasonable to me: a pair of Techsolo TL-2020 USB speakers. They were USB powered (+), the price was some 10 Eur (+) and the power 10W (+). (If you stop reading here: don’t order them, read the conclusion!)

After plugging them into my Linux laptop they seemed to work. When I used them with my Alix board, the first strange thing that appeared was that they went into an undefined state (power led permanently off) when I turned on the desk lamp (wtf?).

The next and bigger trouble was, that I was able to bring them into an undefined state (garbage sound and/or power led off) by permanently starting and stopping playback in 1 second intervals during some hour. This worked reproducibly. The playback was done using my own player coded against the OSS API and talking to the snd-pcm-oss, snd-usb-audio kernel drivers.

First I’ve suspected the USB sound driver and tried to do some debugging, but without much luck.

Because this misbehavior was unacceptable for me, I decided to order some other USB speakers, but this time I was more carefully choosing the brand and model. The NSLU2-linux guys were recommending some USB sound chips as being known to work and the page at least mentions Logitech V10 speakers. Using another google search I’ve found a howto on making those speakers work with gentoo, so apparently someone has made them work under Linux. And using yet another google search, I’ve discovered that at least some revision of the V10 speakers used one of the chips the NSLU2-linux guys recommended as known to work.

Although they were more expensive (30 Eur), I’ve decided to order them because of their apparent good reputation. They work flawlessly. The test that brought the techsolo speakers down in one hour was unable to bring the logitech speakers down during 2 days.

Conclusion

• Logitech v10 USB speakers work flawlessly for me with Linux.
• I don’t recommend Techsolo TL-2020 USB speakers to be used with Linux.

Recently, I was traveling in the train with a friend and we were talking about programming languages. So I’ve told him why C++ is among my favorite languages and what I think are its killer features. One of them were templates, and I mentioned that while java generics are implemented only by inserting cast byte code instructions at the right places, C++ templates are a turing-complete functional programming language.

He looked very surprised about that, so I have written a small example for demonstration, the compile-time factorial algorithm

#include <iostream>

// general formula for all N
template<int N>
struct factorial {
    static const int value = N * factorial<N - 1>::value;
};

// specialization for 0
template<>
struct factorial<0> {
    static const int value = 1;
};

int main() {
    typedef factorial<7> fac;
    std::cout << fac::value << std::endl;
}

The nice thing about this compile-time algorithm is, that its run-time complexity is O(1), as the generated machine code only prints the result (5040), which is computed at compile-time:

105                            .loc 1 18 0
106 0083 C745F8B0              movl    $5040, -8(%ebp)
106      130000
107                            .loc 1 19 0
108 008a 8B45F8                movl    -8(%ebp), %eax
109 008d 89442404              movl    %eax, 4(%esp)
110 0091 C7042400              movl    $_ZSt4cout, (%esp)
^^ std::cout
110      000000
111 0098 E8FCFFFF              call    _ZNSolsEi
^^ std::basic_ostream<char, std::char_traits<char> >::operator<<(int)

The next step after having acquired my Alix 2C3 was to install Debian. Here’s the installation procedure in case you want to setup your own one:

Partition your CF card

Get yourself a CF card reader, plug in the CF card and determine what the device special file for the CF card is, for me it was /dev/sdb and create a partition for Linux. I’ve put Linux into the second partition, /dev/sdb2, so the rest of the installation procedure assumes this.

$ fdisk /dev/sdb
fdisk> p
... remove factory-default partition
fdisk> d 1
... create partition for Linux
fdisk> c 2
... don't forget to mark it as bootable
fdkis> a 2
fdisk> w

Install MBR on CF card.

$ install-mbr /dev/sdb

Create filesystem

$ mkfs.ext2 /dev/sdb2

Bootstrap debian

I’ve used debootstrap to set up a debian base system on the CF card:

$ apt-get install debootstrap
$ mount /dev/sdb2 /mnt
$ debootstrap --arch i386 sid /mnt http://ftp.sk.debian.org/debian

To install additional packages, just chroot into the fresh Debian system and run apt-get.

$ mount /dev/sdb2 /mnt
$ chroot /mnt /bin/bash
chroot> apt-get install sl

For the base system to work, it needs to be configured a bit. Most notably, it has to be told to run a console on the serial line. Edit /etc/inittab on the CF card. Remove (or comment-out) all lines of the form:

... /sbin/getty ... ttyN

Those lines tell init to spawn consoles and display a login prompt on virtual terminals 1 - 6. Add the following line instead:

T0:23:respawn:/sbin/getty -L ttyS0 38400

Install kernel

You could just chroot into the Linux partirion and run apt-get install linux-image-2.6-486 but this procedure tries to install a lot of unnecessary dependencies. Another option is to download the Debian kernel package on the development machine, unpack it, an setup it manually on the CF card:

# Download kernel package on devel machine
$ apt-get -d install linux-image-2.6.24-1-486
$ mkdir /tmp/kern
$ dpkg --extract \
    /var/cache/apt/archives/linux-image-2.6.24-1-486_*.deb \
    /tmp/kern
# Mount CF partion into /mnt
$ cp /tmp/kern/boot/* /mnt/boot
$ cp -R /tmp/kern/lib/modules/2.6.24-1-486 /mnt/lib/modules
$ chroot /mnt /bin/bash
chroot> depmod -a 2.6.24-1-486
chroot> exit

Next, you need an initramfs image for the installed kernel. You can create one using mkinitramfs:

$ cp -R /etc/initramfs-tools /tmp
# Now, you can tune the settings in /tmp/initramfs-tools
# Mount Linux partition on CF card into /mnt
$ ln -s /mnt/lib/modules/2.6.24-1-486 /lib/modules/2.6.24-1-486
$ mkinitramfs -d /tmp/initramfs-tools -o /mnt/boot/initramfs-2.6.24-1-486 \
    2.6.24-1-486
$ rm /lib/modules/2.6.24-1-486

Install grub

To make the CF card bootable, grub is needed. Start by installing the grub package on the fresh Linux system:

# Mount linux partioon on CF card int /mnt
$ chroot /mnt /bin/bash
chroot> apt-get install grub
chroot> mkdir /boot/grub
chroot> cp /usr/lib/grub/i386-pc/* /boot/grub
chroot> exit

Then, setup grub on the CF card. Assume your CF card corresponds to device /dev/sdb. Create a file, /tmp/device-map with the following content, that tells grub that (hd0) should be mapped to /dev/sdb:

(hd0) /dev/sdb

Then, start grub from the command line and continue the installation:

$ grub --device-map /tmp/device-map
grub> root (hd0,1)
grub> setup (hd0,1)

And finally you have to create a boot menu for grub on the CF card, /boot/grub/menu.lst:

serial --speed=38400
terminal serial

timeout 5
default 0

title 2.6.24-1-486
root (hd0,1)
kernel /boot/vmlinuz-2.6.24-1-486 root=/dev/hda2 console=ttyS0,38400n8
initrd /boot/initramfs-2.6.24-1-486

Edit: Someone has pointed out, that the above procedure of installing grub did not work for him. Instead, he did the following on his development machine:

$ echo '(hd0)  /dev/sdb' > /mnt/boot/grub/device.map
$ grub-install --root-directory=/mnt /dev/sdb

Boot the board

At this point you should be able to boot the Alix board from the CF card. Network and USB worked for me out of the box.

Edit: An user reported the following problem during booting:

resume: libgcrypt version: 1.2.3
resume: Could not stat the resume device file.
        Please type in the file name to try again
        or press ENTER to boot

The fix was to remove the initramfs-tools config file /tmp/initramfs-tools/conf.d/resume and to add the option noresume to the kernel commandline.

Goodie: install LED driver

Debian includes a source package for the led driver, alix-leds-source. You can build the driver on your development machine:

# Need headers for kernel on alix
devel> apt-get install linux-headers-2.6.24-1-486
# Get driver source
devel> module-assistant get leds-alix-source
# Build package for target kernel
devel> module-assistant -l 2.6.24-1-486 leds-alix

Voila! There is now a deb leds-alix-modules… in /usr/src. Just install it on the CF card. And don’t forget to put leds-alix into your /etc/modules on the alix board.

Recently, I had the need for a small and cheap board, to run a Linux system with my custom application. My requirements for the board were:

• Portable and quiet.
• For my development cycle to be the shortest possible: it should run the distro I’m the most familiar with: Debian GNU/Linux.
• I needed to attach several devices via Ethernet. So at least one Ethernet adapter. More than one would be good, they would obsolete the need for a switch.
• USB port.
• Audio out or additional USB port for USB speakers.

In the short time I had for choosing the board, I’ve considered the following candidates:

Mass market Linux devices

The NSLU2 would be a good candidate, but the small amount of flash was unsuitable for my app and I felt like an additional USB stick to hold the app was just uncool. Linux powered NAS devices would be an option too, but they were not cheap.

Further, one needs to run custom distros like OpenWRT on those devices. Although they are feature rich and support a lot of packages, I’m not so familiar with them, so getting all packages I need for my application would take me more time than a simple apt-get.

Intel D201GLY2

My first candidate was an mini-ITX motherboard with an Intel Celeron on board for around 40 Eur. Equipped with everything you would expect from a PC platform:

• Intel Celeron 1.2 GhZ CPU on board
• 1 x Ethernet
• IDE
• SATA (obsolete for me)
• USB
• audio
• VGA (obsolete for me, reported to not work well with Linux)

Although the CPU is passively cooled, some guys wrote they would recommend a CPU fan or at least a fan in the case, because their CPU got quite hot. RAM for the board was very cheap and I’ve planned to equip it with a 2GB IDE flash drive.

The main problem with the board for me was, that the smallest case I’ve found, the Morex T-3310 was too big for me (230 mm x 205 mm x 90 mm) and more expensive (89 Eur) than all components of the system in sum. The power supply was an external one that looks like a notebook power supply, so not small at all (portability–).

eBOX-2300-H

The next candidate, was a small x86 compatible box, the eBOX-2300-H for around 150 Eur. The size 115 x 115 x 35 mm can’t be beated! It featured:

• 200MhZ vortex86 x86 compatible CPU (300MhZ available, but some problems with the missing FPU unit were reported when running Linux)
• 128MB RAM on board
• 2 x USB
• 1 x Audio (very good)
• 1 x Ethernet
• 1 x VGA (obsolete)
• 1 X IDE for laptop drive (obsolete, but maybe practical for installation)
• CF card slot
• Comes already in case (very cool!)

Although 128 MB RAM was enough for me (I’ve tested my app in a XEN instance with 128MB RAM without swap), if there was the possibility to get more RAM cheaply, I would take if for just the case, you never know.

The main problem with that hardware was that shipping time was 3-4 weeks (too much for me) and the customer service discouraged me to use the 200MhZ variant, because it was discontinued already. And because I’ve read about some problems with the 300MhZ variant with Linux, the ebox was not an option any more.

Alix

Then, I’ve stumbled around a family of x86 compatible boards, the Alices. The board is 152.4 x 152.4 mm (quite good) and features:

• AMD Geode 500 MhZ CPU on board.
• 256 MB RAM on board.
• CF Card slot.
• One of the following set of peripherals.
  • 1C1: 1 X VGA (obsolete), 1 x Audio, 1 x Ethernet, 2 x USB, 1 x RS232, GPIO pins (Wow! but currently obsolete for me)
  • 2C2: 2 x Ethernet, 2 x USB, 1 x RS232
  • 2C3: 3 x Ethernet, 2 x USB, 1 x RS232

The price is 111 Eur for the 2c3 variant and 7.5 Eur for the power supply.

These boards really rock: they fill the gap between the consumer Linux devices like the NSLU2 and mini-ITX PC systems. Imagine all the things one could built using such a device!

There are really cheap cases for those devices available for less than 10E! The 18V power supply is quite small and I really welcome the 3 network interfaces, because they obsolete the need for a small switch for my application (i need to connect exactly 3 devices to the system).

So finally I’ve ordered the Alix 2C3 at a reseller here in Slovakia: SKfree. The order was confirmed at Friday and the next Wednesday, the board arrived. Let’s see how stable it will run!

My work on the s390 port of CACAO was finished around the beginning of summer 2007. Our criteria for the port to be finished were:

• Passing all benchmarks of the dacapo benchmark suite.
• Passing the mauve test suite. This turned out to be useful as some tests have still located bugs.

As the work was part of an internship, i had to document it. This took some time in the summer 2007. The documentation was finished around the beginning of fall 2007 and checked as part of the CACAO Handbook into the mercurial repository in docs/s390.tex.

The internship finished, time has come to start working on a master’s thesis. I’ve got 2 subjects to choose from: implement escape analysis for the optimizing compiler or rework the framework of the optimizing compiler. After taking one month to have a look at both subjects, I have chosen to work on escape analysis.

After having followed twisti’s build instructions on how to build cacao with OpenJDK as runtime, I’ve got an OpenJDK based JRE with Cacao as VM in JIT mode on s390. Here’s the usual first real life app run:

$ ~/j2re-image/bin$ ./java -cp /usr/share/java/jython-2.1.jar org.python.util.jython
LOG: [0x77e626b0] JVM_GetStackAccessControlContext: IMPLEMENT ME!
LOG: [0x77e626b0] JVM_DesiredAssertionStatus: cls=0x475d20, IMPLEMENT ME!
LOG: [0x77e626b0] JVM_DesiredAssertionStatus: cls=0x474d20, IMPLEMENT ME!
LOG: [0x77e626b0] JVM_DesiredAssertionStatus: cls=0x475a80, IMPLEMENT ME!
...
LOG: [0x77e626b0] JVM_GetSystemPackage: IMPLEMENT ME!
Jython 2.1 on java1.7.0-fastdebug (JIT: null)
...
>>> import java.lang.System as s
LOG: [0x77e626b0] JVM_GetProtectionDomain: cls=0x5fed20
LOG: [0x77e626b0] JVM_ResolveClass: IMPLEMENT ME!
>>> [s.getProperty(p) for p in
    ['java.vm.name', 'java.runtime.name', 'os.arch', 'java.vm.info', 'java.version']]
LOG: [0x77e626b0] JVM_GetProtectionDomain: cls=0x5fed20
LOG: [0x77e626b0] JVM_ResolveClass: IMPLEMENT ME!
['CACAO', 'OpenJDK Runtime Environment', 's390', 'JIT mode', '1.7.0-fastdebug']

I’ve run the dacapo benchmark against cacao/s390 and compared the results with IBM’s java 1.4 and 5.0 for s390. A prerelease of Java 6.0 is also available from IBM, but benchmarking is prohibited.

The benchmarks were run on a virtual machine with 256 MB RAM and a lot of swap on the Community Development System for Linux.

Every benchmark was run 5 times with default data size, the table below shows the worst and best run on each VM.

The results are available as histogram too.

Finally, eclipse is running on cacao/s390: