CANBoat Design part III - Choosing the server hardware

The server that CANBoat runs on was always designed to run 24 by 7. This means that it must be reliable and use little power. Power usage adds up over longer periods. Something that uses 3W will use 6 Ah @ 12 V per day. So every Watt counts!

For a long while I thought that I would end up with some form of embedded ARM board running Linux. I bought a number of ARM based systems to run field tests.

However as I started to develop software it soon turned out that the criteria list contained three items, not two:

• Power usage - as low as possible IN REAL LIFE.
• Connectivity - USB 2.0 Host, Ethernet, Wifi.
• Up-to-date Linux kernel with distribution that provides lots of packages.

I was surprised to find that in practice a small x86 server based on the AMD Geode ran with almost as little power as an ARM board. Unlike the ARM boards it had all the I/O that I wanted. Furthermore it was cheap and reliable to procure. You can get cheap ARM boards based on commercial items such as routers but these usually have a very short lifetime as manufacturers continuously drive down prices by bringing out new hardware. Embedded systems are usually a lot more expensive.

The clincher was that most ARM board manufacturers have a hard time keeping up with the Linux distributions, so they usually run out-of-date kernels and weak distributions. Support for FTDI serial converters was not a given, and these are used in many devices such as the Actisense NGT-1. I had to backport many fixes for the FTDI serial converters to the older Linux kernels to get reliable serial USB connections. Not Good.

So in the end I decided on low power x86. The PC Engines ALIX 2d.13 has exactly the interfaces I needed, but is available in a range of different systems. They run about € 100 / $ 140 which is still very reasonable. It runs a very nice mini Debian release named Voyage Linux with a kernel that is new enough to run stuff like the FTDI interfaces reliably. As it is just a pruned Debian release getting an additional package is just an apt-get away. The processor is a 500 MHz AMD LX800 which is plenty fast for Linux server needs.

Programmatically detecting that /bin/sh is actually csh

As my last post shows, if you write something up about a subject people will find your site no matter what the purpose of the site, or in this case blog, is about.

Therefore I'm going off on another tangent with a subject that I don't have any other place to put in, and that involves UNIX shells.

In my 'day job' we encountered a few customers that, 'for convenience' decided that they like csh so much that they want this to be the default shell. And they do this by making /bin/sh a symlink to /bin/csh, or even just copy /bin/csh over /bin/sh. This is probably most likely to happen on Linux, as that doesn't use /bin/sh as heavily as the likes of AIX, HP-UX and Solaris.

In my opinion what these people do is a very bad idea, as software should be able to depend that the syntax for /bin/sh is always the same. It maybe a superset when it's actually KSH or BASH, but it should certainly execute the minimal Posix shell syntax. Still, we have to write software that could function anyway. Sigh.

Here's what my colleague Nils came up with:

#!/bin/sh

[ "$shell" != "" ] && goto csh

echo "This is Bourne Shellish."
exit 0

csh:
echo "This is C Shell. You are a naughty fellow -- please reset /bin/sh to a Bourne type shell!"
exit 1

A plain goto csh is ok but throws an error message in bourne style shells, so we prepend it with a condition that is only true in CSH. We can't use if, as that has different syntax in the two types of shell. The condition is true on CSH because it has a variable $shell whereas Bourne style shells have $SHELL instead.

Hopefully this helps somebody out there.

Next time I'll get back to a nautical subject, I promise.