A few months ago I did an interesting discovery about using my cellphone to go on the internet via bluetooth. I had this strange situation before where it just stopped working, and after revisiting all configs it worked again. What really happens is that my cellphone somehow crashes, after which I power cycle it by removing the batteries. The phone then boots again, but here is the twist: the service channels in the phone are re-allocated and apparently in a random order! This implies that the RFCOMM channel configured in the /etc/bluetooth/rfcomm.conf file is possible wrong now! Solution: just browse the services again with sdptool browse, adapt the file and it should work again!

Linux serial ports only work at standard speeds by default. MIDI runs at 31250 baud, which is not a standard speed. However there are tricks to get custom speeds, but documentation is quite fuzzy. This is a simple recipe that worked for me with an FT232 USB-Serial board.

Check the baud base of the device:

$ setserial -g -a /dev/ttyUSB0
/dev/ttyUSB0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 24000000, close_delay: 0, divisor: 0
closing_wait: infinite
Flags: spd_normal low_latency

As you can see the baud base is 24000000 here.
Next calculate the divisor by dividing the baud_base you see here by the speed you want.
In my case 24000000/31250=768.

Apply the new setting:

$ setserial -v /dev/ttyUSB0 spd_cust divisor 768

Next start your serial application, you might want to make sure it is already set to the correct speed before you do the above changes else it might destroy your settings. The correct speed is 38400 baud, which is now aliased to 31250.

With minicom just use the menu (CTRL-A Z) to change the settings.

Screen can be used like this:

screen /dev/ttyUSB0 38400

Exit screen by pressing CTRL-A CTRL-\

Sweet.

Update:

I received an email from Ethan Bisset with a much nicer solution: just use the debian provided serial library instead of the one provided with the arduino software.

This is his recipe:

1. Get arduino software
2. apt-get install sun-java6-bin binutils-avr avr-libc gcc-avr librxtx-java
3. Untar arduino software
4. Delete <arduino>/lib/librxtxSerial.so
5. Done!

(below is the old entry:)

Download the linux 32-bit arduino toolkit from the arduino toolkit download page and untar in a directory.

Install the avr tools: apt-get install avr-libc binutils-avr gcc-avr

Install "ia32-sun-java5-bin". ( apt-get install ia32-sun-java5-bin )

Adapt the "arduino" startup script script and replace java in it by

/usr/lib/jvm/ia32-java-1.5.0-sun/bin/java

Execute the "arduino" startup script. It works just fine now.

Thats all.

Many thanks to the Debian java packagers for providing this 32-bit compatibity jvm!

As Debian has been released my "unstable" box recently upgraded to glibc 2.9.
This caused DNS resolving to mysteriously fail in some applications.

Turns out that only IPv6 enabled applications suffer.

Apparently libc now fires both an IPv4 and IPv6 DNS resolving request in parallel. It looks like some DNS servers don't handle that correctly and answer an error on the IPv6 request before the IPv4 request even has time to resolve further in the internet.

In my case it was my local NSLU2 running Debian lenny causing the trouble, more specific the maradns local DNS server and DNS proxy running on it.

I manually upgraded maradns to the latest version (> 1.3.10) and things are "back" to normal.

Another solution is to disable IPv6 systemwide but I prefer not to do that as I use IPv6 occationally for testing.

I fear that this will cause more trouble for alot of people with routers doing DNS proxying.

A new version of openMSX has been released!

Important new feature is save-states. This gave me the means to finally finish the very first game I bought as a kid: Konami's Nemesis 2 for the MSX computer.

In these times games were usually hard. Nemesis 2 is even harder. The only way to play it without save-states is not dying all 15 levels. Given that Nemesis 2 is a shooter this is VERY hard :)


Each one of those red bullets and grey stones is fatal :)

But save-states wasn't enough. I also enabled "old-people" mode, meaning running the emulator at 75% speed of the original MSX computer.

After more then an hour of hard labour playing using alot of save-states I finally managed to finish the game.

Only 22 years late ;-)

P.S.: I checked with my MSX friends and no-one was able to finish this game without some form of cheating....

I'm really happy with my new Dell precision M6400.
The only thing most people complain about is the size of the power brick, and I can't agree more. It's a huge 200 Watt thing and it's really as large and heavy as a stone brick.

Luckily I still have a spare power brick of my old Dell precision M65: a 90 Watt PA-10 family power brick. It has exactly the same voltage (19.5 Volt) so I decided to try it.
I've been using it now for a few days when at customer sites and it works fine.

(Try at your own risk!)

Last year I even did it for longer then a month, but this year I want at least to redo a minimal effort, thus I'm going for a month of sobriety, as a kind of cleansing :) (and no, I'm not religious).

These are my 5 daily checkpoints:

1. smoothie for breakfast
   
   This is something which we (me and my wife) do already anyway, have a fresh fruit smoothie for breakfast. Currently our favorite mix is 4 blood oranges, freshly pealed and parted, a seep of Sea-buckthorn elixir, and a couple of frozen strawberries (or cranberries). Mix all in the blender, long enough to don't have any parts left. It is extremely tasty, and gives a serious vitamin boost for the winter. The idea is to have it for breakfast and then don't drink or eat anything else for at least 1.5 hours, to make sure it's (almost) fully digested.
   
   
2. < 4 coffee
   
   This is a hard one; people who know me will know I'm a serious coffee lover. I have a special espresso machine, and typically serve single origin or special blend coffees. It's hard to resist :)
   
   
3. exercise
   
   Just a walk with the dogs already counts.
   
   
4. no sugar
   
   This is usually not so hard for me, as I'm not into sweets anyway.
   
   
5. no alcohol
   
   This is tougher. I'll have to stick to coffee, tea and fruit juices.
   

This is all as much a physical as a mental exercice :)

I was getting sick of all the wires on my desk, and I needed a new keyboard anyway,
so I bought a logitech bluetooth key and mouse (mx 5000). It's supposed to work just fine.

The keyboard comes with a bluetooth dongle, but it's rather silly not to use the bluetooth build in my laptop, so i never tried the dongle.

I was running linux-image-2.6.26-1-amd64 on my laptop and it had serieus issues with bluetooth. It was very hard to get the device to pair, it imvolved alot of manual probing/forcing.

This morning I upgraded kernel to 2.6.27.7 from kernel.org and it all started working flawlessly...

P.S.: might be fun to see if I can find a way to have it's LCD display work in Linux ;-)

Since everybody is posting pictures of the first snow of the year, I can't stay behind. Quickly popped out this morning to make this snap of my favorite habitat, the valley of the "Grote Nete":


(click on the image to enlarge)

nikon d300 tamron 17-50 f/2.8 2008 Joost Yervante Damad

It's still unclear to me if this is software raid or not.
It might depend on the chipset. My chipset is "Intel ICH9M-E SATA AHCI/RAID controller hub" which seems to hint that it is hardware RAID.

Dear lazyweb, anyone know how to find if this is software or hardware raid?

The Debian Lenny release has still quite a big list of Release Critical bugs, and as Debian developer I feel that I should do my share, and at least look at the list of bugs and see if there's any I could do something for.

Almost always though, I find that I won't touch the remaining bugs in the list.because of one or more of these reasons:

1. a package I really don't care about
2. hugely complex package or might also use something obscure like cddb
3. it seems like people are already looking into it
4. it requires a political solution, not a technical one
   

As part of the effort to get Lenny released, Joss Mouette started the Debian Bug Sprint.
This is really a cool concept, and it is a shame not more people participated.

The reason for me it is cool is that it forced me to break the rules I mentioned above, because I got a bug which fitted 1 and 4 of my list above!

Turned out this bug is really a border case in interpretation of Debian policy.

The package is perfectly usable without any extern dependencies, hence it is currently in the main section of Debian. However it doesn't end there. The package also has a download script that can fetch firmware images for certain printers. It appears for people with these printers the package is NOT usable without external files.

Aparantly though, the current, as one person involved in the bug calls it, "spirit" of Debian is to tolerate this, as it is good enough that it is usable without external dependencies for SOME persons.

However the bug submitter doesn't agree, and thinks this is a case that needs addressing withing the Debian project.

I suggested splitting up the package and moving the download script to contrib, but this was mostly dismissed as idea.

The end result is that the maintainer decided to escalate the problem to the Debian CTTE.
This means it probable won't be solved by today, soo I will have to bake cookies for someone :)