Hardware's hard facts

We just bought some toys to do a Tamias test deployment. We started small with just 15 nodes made of :

• A Barebone chassis that has motherboard, CPU, chipset and loads of integrated stuff we won't use : the Shuttle XS36V
• A 1TB 2.5" hard disk from Samsung
• A 2GB RAM stick from Elixir (unrelated to the card game, for you french readers)

Now, the law of large numbers predicts that for millions of hardware pieces, a few of them will be faulty. I was really interested to see how lucky we would be with the Tamias hardware, and here is the result for the case of not so large numbers :

Part	Qty bought	Qty faulty	Remark
Shuttle XS36V	15	2	Won't boot from USB key, but installs from USB CD
Samsung 1TB HDD	15	0	so far so good
Elixir 2GB RAM	15	2	1 won't P.O.S.T., 1 fails during Debian install

So that's it, 13% failure for RAM. I was expecting 1 failure and hoping for zero... The motherboard could be rated at 0% failure because it actually works, but we had to boot from a USB CD. I would have to check if the BIOS release is the same as the other 13 pieces, but since we got it to work, we decided not to RMA them. Memory was RMAd and replaced swiftly, Memtest86 (using debian memtest86+ packages) has passed so we expect no problems here either...

FTDI USB driver woes on Debian LiveCD

Just a quick info that might be useful for some of you Xbee users. I wrote this little software to visualize and plot Xbee accelerometer data a while back.

Now, my brother tried to use it, and since he is not into Linux at the moment, I prepared a LiveCD for him using the Debian Live project. The reason why I did that is because the python program needs wxpython which is not included in the default Debian LiveCD.

The problem is that the kernel currently used (at the time of build: started Mon, 05 Mar 2012 20:21:01 -0600 and ended Mon, 05 Mar 2012 20:52:50 -0600) includes a buggy driver for the FTDI USB kernel driver. Details about the bug can be found here :
http://comments.gmane.org/gmane.linux.usb.general/44150

and changes needed to any python software (including my own xviz) that wants to work around this bug, so that you don't need to replace the kernel or rebuild the liveCD, are to look for a line like this:

 self._port = serial.Serial(self._comport, 9600)

and add a rtscts= parameter like this:

 self._port = serial.Serial(self._comport, 9600, rtscts=1)

This tells the driver to open the serial port using RTS/CTS flow control, which actually disables it, because the driver inverts both states, duh.

Debian, IPv6 and ... Java ?

Today is the first time for me to talk about Debian. It has been my favorite Linux flavor for quite some time now. I would say at least ten years, when compiling stuff became less fun and more painful, or my spare time ran out. I don't know exactly.

But whatever the cause, I ditched compiling everything in favor of the flexibility (and frustrating nature at times) of a packaging system. At that time, RPM did not prove better than Slackware's plain .tar.gz packaging and although dselect could be stubborn at times, it soon got better with apt-get and friends.

Let's add IPv6 to this landscape.