For those of you who haven’t heard about this: the comedians that lost a bet (not shown, but aired before) have to reside for 24 hours in a setting where they are confronted with strange situations designed to make them laugh. Each time they laugh, “punishers” come out to hit them on the buttocks with an object.

The situations are often funny, sometimes not so, sometimes hilarious, but the thing I like the most is when the comedians make each other laugh (and often themselves too), resulting in even more punishment.

The “No laughing spy” broadcast is almost 5 hours long. It is split up in “episodes” of 30 minutes, so you do not have to watch it all in one run (I did). Hope you enjoy!

1. 5.1 audio source
2. 5.1 audio capable cable (e.g. optic fibre)
3. iTunes (or something else that can output to AirTunes/AirPlay)

I used http://www.diatonis.com/surround_sound_music.html or http://www.kellyindustries.com/sounds.html for the 5.1 audio sources (WAV files, iTunes wouldn’t play the .ac3 files). I borrowed an optic cable (thanks Michele!) with a TOSLINK plug on one side (goes into the receiver) and a Mini-TOSLINK plug on the other side (goes into the Airport Express). The important thing is to put the volume of iTunes to 100%.

If the volume of iTunes is not set to a 100%, the receiver will not detect that your source is DTS or DD5.1 (whatever your source is), and will output noise. I guess this is because DTS and DD5.1 should be passed through the receiver unchanged (volume control is done at the very last). I think iTunes doesn’t handle this gracefully (in my opinion it should output it unchanged no matter what the volume control is set to).

Anyway it does work, so enjoy!

The hardware
I swapped out a Pentium D 930 (yes, I know, old hardware, but it served its purpose) with a Core2Duo T5500. Impressive! The motherboards are nothing impressive (read: I forgot the brand and model), and the only thing noting was the difference in memory: from 2 GB to 4 GB. Other than that, they are pretty similar in performance (I measured with 3DMark2006: 6500-ish vs 7100-ish, respectively).

Interesting!
The interesting thing wasn’t the power usage difference between them (well, I expected a drop in power usage and got it), but the difference in power usage when I used a 400 W PSU with the new setup compared to a 500 W PSU. For the record, the only thing I changed was the PSU. No settings changed, no other hardware changed. I didn’t even run windows updates in between them. Unfortunately, I don’t have the numbers for the D930 with the 500W PSU, because I already swapped it for the other motherboard when I thought about trying that.

The details
In the table below you can see power usage that I measured (it was oscillating a bit sometimes (a few percentage of the total), I took a number that looked average). The activities are: Busy (Battlefield: Bad Company 2, ingame), Idle (Windows desktop, no programs running), Windows Standby (as the name implies), Off (shutdown, cable plugged in).

Anyway, the measurements:

As expected, there is some difference between the Pentium D930 and the C2D T5500 (max 115 W, min 3 W), even forget that the D930 is terrible at being Standby (I mean: 121 W? really?) but look at the difference between the same C2D with a 400 W and 500 W PSU (max 25 W, min 2 W). I guess the 400 W PSU I have is more power efficient. By the way, I rechecked 3DMark2006 for both the 400 W and 500 W PSU, both are around 7100-ish, so no big change there.

Update: 400 W PSU is FSP Group Inc, 500 W PSU is Coolermaster

If you want to debug postinst scripts, you can easily do this on the machine where you (half) installed the package. Normally you can execute /var/lib/dpkg/info/foo.postinst like this:

sh -x /var/lib/dpkg/info/foo.postinst configure


However, if you use debconf, the output will be like this:
+ . /usr/share/debconf/confmodule
+ [ ! ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [ ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/foo.postinst


Which is not helpful either. However, you can add “set -x” in /var/lib/dpkg/info/foo.postinst and then just execute it, it will give you the full output.


sh /var/lib/dpkg/info/foo.postinst configure


Now the debugging process can begin!

When only one package is made, this is easy: just install the files in debian/tmp as you would when installing on the system. For multiple packages, each package has its own directory: debian/<package-name>. How does dh_builddeb figure out which directory to use?

Apparently, the default behaviour is to let the first package use the debian/tmp dir, and the other packages use the debian/<package-name> directory.

I would rather have them all using the debian/<package-name> directory, but I could not find an option to do this.

Update:
It seems that setting the compatibility level to 7 fixes this behaviour (echo “7″ > debian/compat), see man debhelper (section “Compatibility levels” for more info.

client 192.168.1.1#37242: view internal: query: www.apple.com IN A +

I changed the regexp and I archive it here in case anyone else (or future-me) wants to use this:

--- bind9.orig	2009-11-01 15:06:16.000000000 +0100
+++ bind9.new	2009-11-01 15:06:07.000000000 +0100
@@ -73,9 +73,9 @@
     open(Q,"< $QUERYLOG") or die "$!";
     while (<Q>) {
 	chomp;
-	if (/client \d+\.\d+.\d+.\d+\#\d+: query\: \S+ (\w+) (\w+)/) {
-	    if ($1 eq 'IN' and $2 !~ /^TYPE/) {
-		$IN{$2}++;
+	if (/client \d+\.\d+.\d+.\d+\#\d+: (view \w+: )?query\: \S+ (\w+) (\w+)/) {
+	    if ($2 eq 'IN' and $3 !~ /^TYPE/) {
+		$IN{$3}++;
 	    } else {
 		$OTHER++;
 	    }

By the way, I also found out that there is a program called 'munin-run' which can be used to run the plugin as munin would, this saves a lot of hassle with sudo and environment settings!

Oct  8 03:32:08 hoshi kernel: [145430.434977]kjoradsatn. omtitra  eod

edit: Oct 9
Today, I got this one, this is getting scary:

Oct  9 03:32:08 hoshi kernel: >99873]koradsatn. omtitra  eod

The only link I could find was this one: http://forums.gentoo.org/viewtopic-t-245137-start-0.html But it does not help me a lot.

When comparing the output of dmesg to the one in /var/log/kern.log (which is the source of the garbled messages), the only thing that is missing in the kern.log is this:

[236989.877537] kjournald starting.  Commit interval 5 seconds

It looks like this is the source from the garbled message: If you start from ‘k’ and take only every other character, you’ll see. So apparently, this is not a kernel problem (because the message appears ungarbled in dmesg) but rather a problem with syslogd.

Now things get really strange, as I have an rsyslogd daemon running, but I could not find the binary on the disk. It seems that I accidentally started a syslog daemon in a chroot (I did play around with that certain chroot, because I was fixing a computer that was booting via nfs-root from this machine).

The funny thing is that the rsyslogd that was running, was actually a 32-bit executable (the nfsroot is a 32-bits install), while the host is a 64-bit system. So I’ve been running a 32-bit syslogd on a 64-bit for two days :)

I’ll see if I get another garbled message tomorrow, but I think the problem is solved now :)

Scrambled character set

A friend of mine had a problem with his terminal today. Most people will encounter this one day or another. He asked me how to fix it. I told him to do ‘cat /bin/bash’ and press ^C at one point and repeat this until it worked. He was surprised that worked and asked me why. I told him I didn’t know exactly, but that it had to do with control characters that are often found in binary files but I was curious myself to so I did some research.

Apparently there is an ANSI escape sequence to select character sets. To select one of these character sets, the ANSI code ‘ESC(0′ is used. Because terminals will catch the escape character, we have to do some extra to get a literal ESC: type ^V ESC. The character will be displayed as: ‘^[‘. Typing this will result in a terminal that looks like the image above:


bash$ echo '^[(0'


You can get the correct character set back by typing ‘ESC(B’, but maybe a better idea is to reset the terminal (the program ‘reset’ will not always reset the character set) with the following ANSI code: ‘ESCc’. For this command we don’t have to use single quotes to avoid the parenthesis from being interpreted, so this easier to remember:


bash$ echo ^[c


So whenever you get this problem, remember to press these 4 keys (ok, I count a control character as one key): ^V ESC c ENTER