• Wifi: it ships an Atheros AR9285 wireless card. From the Official Linux Wireless wiki we can see that it is supported on kernels >= 2.6.29. Jaunty comes with 2.6.28, but it is not a problem:

sudo apt-get install linux-backports-modules-jaunty

• Sound: Update ALSA. This is for the latest snapshot:

sudo apt-get install build-essential
wget http://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/\
alsa-driver-unstable-snapshot.tar.bz2 -O -| tar xvj
cd alsa-driver-unstable
./configure --enable-dynamic-minors
make
sudo make install-modules
echo "options snd_hda_intel model=hp-dv5" | \
sudo tee -a /etc/modprobe.d/alsa-base

Problem solved. Reboot and enjoy.

I mention this because the time to buy is getting closer and closer, and yet I’m astonished that so little people out there are making a big fuss over the next big thing: ARM netbooks and Linux. Sure, we already have some of these out there from Skytone and Elonex -and probably others-, but those are fairly limited machines performance-wise.

I’m talking about cheap mini-laptops that can be used to surf the web, write reports and even play 720p video, all with an extremely low power consumption, 10+ hour battery life and very little heat generation. These machines are already on their way, will use newer and more powerful ARM processors and will hit the market in the following months.

I believe this is, in fact, a silent revolution that doesn’t even ripple the surface. This will change everything. And why is that? Well… for starters there is a huge market for something like this, like the sells of anything Netbook-related have been steadily showing lately. An it seems hardly possible that Microsoft will release an ARM enabled Windows XP. This means Linux will get yet another boost in market share when these machines become mainstream, although I’m pretty sure Microsoft will still claim a 90%+ share in the netbook segment. Despite this alleged 90%, the rules of the game have changed, and netbooks are not playing by Microsoft’s rules any more.

Things are changing. And with this, cheap, ubiquitous, multimedia network-enabled machines will become a reality. And those will be powered by free software, at last. Debian has been supporting ARM chips for a long time, Ubuntu does since release 9.04 and other mobile and embedded devices have a long history with Linux. And lets not forget about Android! Oh man, I can hardly wait to get my hands on one of these jewels!

It’s a revolution.  It’s quiet, but it’s happening.

The easiest thing to do would be installing the system normally through PXE (look for the link at the end of this post if you’re interested), but there is a problem. Flash devices have a limited number of write-cycles, and wear levelling is not used on consumer grade cards. There are file systems optimized for flash devices -such as JFFS2- but the benefits are not obvious here. As I understand it, these are designed for industrial devices with direct access to the memory cells. Consumer devices have an abstraction layer that make them transparent and enable us to use them as any other normal storage. It should provide everything we need, such as wear levelling. But as I said before, it normally doesn’t for consumer-type devices.

Alternatives

Having discarded the optimal solution for both technological and budget limitations, we are left with three alternatives.

1. Use the CF as an ordinary device, with total disregard for the premature death of the drive. This is the simplest, and provided you have a lifetime warranty for your media it might not be such a bad idea.
2. Use the CF as if it were a LiveCD, maybe even adding persistence for our changes. This option should prove perfect if we want to use the Thin Client as a desktop system. Temporary changes are written to RAM, permanent changes will be stored on disk and even software updates will remain between reboots. It is a bit more complicated, so I’ll leave this in my TO DO list for now.
3. Install everything by hand on a local copy, configure the system to be able to run with as little disk access as possible (ideally, from a read-only root file-system), and dump it to the CF. Since space is not a problem for me (I have both a 1GB and 8GB CF cards), I’ll prefer this approach. In case everything was set as read-only, we would only  have to remount the file systems as writable during the process. As for SquashFS, though it seems an ideal choice for an embedded system that needs no upgrades, I’ll discuss this in other posts. It is simpler to deal with a “standard” system, not having to recreate binary boot images every time you update the box.

My home server is used to share media and printers on my local network, manage downloads, and above all, provide a permanent access to my home network from wherever I might be. This is, by far, the handiest thing ever. At least it is for me. You never know when you are going to need to bypass Internet filters when you are roaming, for example. The wonders of SSH truly never cease to amaze me :)

I’ve opted for letting some writing be done to the CF, albeit the write-intensive tasks have been dealt with, because it is easier for the system to be updated, and because some of the services I’ll be using refuse to work on read-only mode. However, my next entry will be about using aufs/unionfs, and replicating this setup on totally read-only and compressed system that will run from the 256MB standard CF that comes with the computer.

Things to install

• Basic system: since Jaunty is still in Alpha stage, downloading the whole ISO is not worth it. Just grab the NetBoot mini ISO and download the rest as you go. You’ll have to update frequently until it is released anyhow.
• linux-image-server: A scheduler less suited for multimedia but with some advantages for a server.
• ssh: Access point to/from your server.
• cups: printer support. Note that CUPS alone will add around 100 MB to your installation.
• portmap, nfs-kernel-server: NFS file server.
• samba: sharing files and printers for Windows boxes.
• nmap, mc, wget, curl, unrar, p7zip-full, arj, unzip, unp, unace, qemacs-nox: some handy tools I can’t live without. Mostly Swiss-army knives, decompressors and a tiny Emacs-like editor. It’s bigger than mg, but it has UTF8 support. I love Emacs but it is huge for a system like this.
• usbmount, ntfs-3g: to automatically mount USB devices. Nice if you plan to plug and unplug your external drives to share them on your LAN.
• mldonkey-server: for our every day download-needs.

These were the steps I followed. Keep in mind these are mainly notes to myself. They should work for you, but they might not. At the very least these steps will give you some useful hints. Please note that there might be some rough edges in the tutorial, since I actually wrote this after having everything installed. I tooks some notes during the process, and this setup is working flawlessly for me. I don’t think any important (read non-trivial) steps were left out, but if that’s the case and it is giving you any kind of problem, just ask in the comments!

The CF shouldn’t suffer much IO, so the idea is to install and customize everything on a virtual machine, and then dump the resulting image to the CF after making every needed adjustment.

I originally intended to make the system completely read-only, but then decided that preventing /tmp and /var/log from massacring the CF would be more than enough. You can skip completely some of these steps, since the root-fs will not be totally read-only. For that, check the next post.

Installing the base system

I’ll be using VirtualBox because I find it easier to work with than plain QEMU, particularly since I’m going to be needing the network from within the virtual machine. Just create a new one with a disk size that can fit in you CF. I’ll use a 1GB card that I have laying around. Also configure the CDROM drive to use the NetBoot mini ISO that you have downloaded.

Before booting the machine, add PAE/NX support to the virtual CPU. The generic kernel doesn’t need it, but once you try to boot with the linux-image-server branch you will need this to proceed. That is done from the virtual machine definition section following the path: Details -> General -> Advanced.

Boot the machine and type ‘cli’ if you want to minimize the installations. Then manually partition the hard drive if you want to use the new EXT4 file-system type, and go through the process as you normally would. Of course, disregard the swap partition. You can’t have that on a CF or it will die soon for sure.

I use the French repositories because those are the fastest for me. I always start by modifying the list of repositories on the recently installed system, in case I want to install things not present in universe. Edit it manually or just append the needed info.

echo "deb http://fr.archive.ubuntu.com/ubuntu jaunty \
main restricted universe multiverse" >> /etc/apt/sources.list

And install the packages.

sudo su -
apt-get clean
apt-get update
apt-get install linux-image-server openssh-server samba cups \
 wget p7zip-full portmap nfs-kernel-server nmap mc \
 qemacs-nox unp arj unrar unzip usbmount mldonkey-server
apt-get clean

No real need to mention it, but don’t forget to delete the generic kernel and associated files if you want to save another 100MB or so.

Now to handle issues related to readable-writable paths, as well as config files. Some steps are only useful if you will mount the rootfs as read-only. I’ll mark them as “Optional”:

• Optional: /etc/mtab: We will link it to a file that can describe the mounted file-systems without requiring write access.

rm /etc/mtab
ln -s /proc/mounts /etc/mtab

• /etc/network/interfaces: static IP for the server. Bare in mind you’ll need writable /etc/resolv.conf and /var/lib/dhcp3 if you intend to use dynamic IPs. You’ll probably have to edit /sbin/dhclient-script to account for this if you are going for a full-ro filesystem. This is how my /etc/network/interfaces looks like.

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.0.0.100
gateway 10.0.0.1
broadcast 10.0.0.255
netmask 255.255.255.0

• /etc/etc/fstab: define the mountpoints. Ensure that directories that need to be writable ar mounted as tmpfs rather than letting the system write them to flash. Alternatively you can mount them on external media. You need this to run the rootfs mounted as read-only. Even if you are not going to do so, you *MUST* set the ‘noatime’ flag when mounting, or at least ‘relatime’. If you don’t, every single access to the files will require a read operation to modify the access time, and this is pure overhead for the CF that will significantly shorten its life span. Using journaling is probably another bad idea, since many commits will also affect the CF. Either use EXT2, or use this as a temporary solution and go for the SquashFS-Live system of approach #2.

/dev/sda1 / ext4 noatime,errors=remount-ro 0 0
proc /proc proc defaults 0 0
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/lib/urandom tmpfs defaults 0 0
# Define the following ones if you use NFS or dynamic IPs.
# Writable paths should be tmpfs or be on external media.
# Both settings are OPTIONAL for our current setup.
tmpfs /var/lib/nfs tmpfs 0 0
tmpfs /var/lib/dhcp3 tmpfs defaults 0 0

• Logging: either log to a tmpfs as shown above, to an external media, remotely or remove logging capabilities. This step is not optional at all. If you choose any option other than the first one, you’ll probably want to take a look at /etc/syslog.conf, /etc/default/syslogd and your /etc/rc?.d for links to /etc/init.d/sysklogd. Don’t forget the syslog.conf man entry. Note that logging to a tmpfs will give you some warnings at boot-time since some files are expected to exist. It’s probably not such a good idea, since you’ll loose the logs between reboots, troubleshooting vulnerabilities becomes more difficult, and so on. If you do proceed with the idea, you should keep this in mind: some logfiles are expected to be present at boot-time, so you’ll get some errors if you boot with an empty /var/log. Mldonkey also doesn’t boot if it can’t access the logs, so populate the directory with a  trivial script such as the following. It  must be run at boot-time before /etc/init.d/bootlogs.sh and /etc/init.d/sysklogd are invoked:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          madoka
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      1
# X-Start-Before:    bootlogs sysklogd
# Short-Description: recreate /var/log structure for Madoka
# Description:       recreate /var/log structure for Madoka
### END INIT INFO

do_start () {
 mkdir -p /var/log/mldonkey
 mkdir -p /var/log/news
 cd /var/log

 touch \
 dmesg          \
 mail.warn      \
 user.log       \
 daemon.log     \
 messages       \
 debug          \
 auth.log       \
 mail.err       \
 syslog         \
 mail.log       \
 kern.log       \
 lpr.log        \
 mail.info      \
 news/news.crit \
 news/news.err  \
 news/news.notice

 chgrp adm dmesg
 chown syslog:adm \
 mail.warn       \
 user.log        \
 daemon.log      \
 messages        \
 debug           \
 auth.log        \
 mail.err        \
 syslog          \
 mail.log        \
 kern.log        \
 lpr.log         \
 mail.info

 chown news:news news
 chown root:news news/*
}

case "$1" in
 start)
 do_start
 ;;
 restart|reload|force-reload)
 echo "Error: argument '$1' not supported" >&2
 exit 3
 ;;
 stop)
 # No-op
 ;;
 *)
 echo "Usage: $0 start|stop" >&2
 exit 3
 ;;
esac

I saved it in /etc/init.d/madoka, and added it to my default runlevel to execute before init.d/bootlogs.sh and /etc/init.d/sysklogd

update-rc.d madoka start 05 2 .

Adding some more goodies

• mldonkey: I just made symbolic links to an external drive. /var/lib/mldonkey/incoming, /var/lib/mldonkey/temp and /var/lib/mldonkey/torrents are the most frequently written directories by far. It also rewrites the configuration files whenever changes are made. Those are also stored under /var/lib/mldonkey/.
  

• /etc/usbmount/usbmount.conf: this is great if you are going to have lots of external drives. It automatically mounts the devices wherever you choose to (in my case, under my shared samba directory). It just works after rebooting. I only edited the file to specify the mount point and to add more file-systems that I wish automatically mounted:

FILESYSTEMS="ntfs vfat ext2 ext3"

• /etc/samba/smb.conf: to share files and printers, edit yours to resemble these pointers.

# add to [global] section, and edit the rest to your heart's contempt
workgroup = WARPCORE
printcap name = cups
printing = cups
security = share
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
# make sure [printers] section looks like this
[printers]
browseable = yes
printable = yes
public = yes
create mode = 0700
guest only = yes
use client driver = yes
path = /tmp

#define at least one share point
[shared]
comment = Shared media
path = /media
guest ok = Yes

To have the printers actually work you’ll need to configure them with cups. After having everything tuned, remember to mount the root file-system read-only. Adding the printer is trivial thanks to the administration web interface. Just forward the needed port or make cups accept connections from interfaces other than localhost, and launch your web browser.

ssh -L 2000:localhost:631 10.0.0.100

Then, access the configuration wizard visiting http://localhost:2000. On Windows systems you can add this by simply add ing a new printer with the wizard and browse your samba shares. You should see the printer there, hanging from your samba server. User your disks with the drivers and it should be a done deal.

• /etc/exports: remember to set up this if you are using NFS shares. I export the same things as with Samba.

/media 10.0.0.0/24(rw,sync,no_subtree_check)

Copying the image to the CF

Ok, so now you have a perfectly working system in your virtual machine. That’s great. Time to copy it to the CF. Convert your VDI file to a raw image as shown below, and dump it to the CF.

If you are using the OSE edition of VirtualBox:

vditool DD machine.vdi raw_image.img

If it is the closed-source release, vditool is not available. You’ll have to do it like this:

VBoxManage internalcommands converttoraw machine.vdi raw_image.img

Once you have that, simply dump it to your CF with dd and you are good to go! Mine is detected on /dev/sdc

dd if=raw_image.img of=/dev/sdc bs=1024

Other installation tips

Going for a completely read-only system, even running something as mldonkey, is not that complicated either. Just trace the paths that need to be written frequently with “lsof /” and if you find something that has to modify many files, either replicate the file-structure on tmpfs/ramfs (preferably the former), or better yet, use aufs/unionfs on a temporary file system.  Thats the great thing about the live-system approach that I”ll be using next. I’m still working on some rough edges, but I’ll blog about it as soon as the results are perfect :)

Another, simpler approach if you don’t mind the hassle and some extra wear on your CF, simply make a PXE install and customize afterwards following my steps. Here is a nice and easy tutorial to make an Ubuntu  net installation in case you want to try that.

Anyway I hope you find this useful. It certainly was for me. Let me know if you find a cheap thin client on Ebay and follow this tutorial. A noiseless server does really make a difference!

A while ago I was looking for a similar noiseless solution for my brother in law and a friend, and the itch started all over again. I decided it was a good moment to upgrade my system. The low power consumption and being fanless were a must, but I also wanted it to have integrated gigabit ethernet. So I though using a Thin Client would be a good solution. These are normally fanless and have very little power needs, and some even have decent processors and Gigabit Ethernet. After looking for a while, I settled for a Fujitsu-Siemens Futro S400 that I found dirt cheap in Ebay.

It has GbE, and an AMD Geode NX 1500 processor that is actually an embedded Athlon clocked at 1GHz that runs on 6W: not bad, given it was introduced on 2004. The S400 boots from a 256MB CF and even has a spare IDE connector on-board. It lacks an internal power connector though, so I had to resort to using external media. One could get the 5V/12V from the motherboard, especially since the PCI port is not being used at the moment, but the system already gets hot enough as it is. I don’t want to add another heat source for now. However, unlike last time, I wanted to keep the OS on the compact flash. Sometimes the external media might not be available to boot, and besides… CF are fast for these things. I just swapped it for an 8GB/x133 I had laying around, and that’s much more than I need.

Installing on flash memory, however, requires certain considerations to prevent the installed OS from degrading due to a CF failure. These devices usually have  a limited number of write cycles, so the set up must minimize the write-operations as much as possible. Once it is done, you can use most thin clients exactly as any other computer.

Basically:

1. Create a minimal installation on local machine
2. Customize it to your needs and add any other required packages
3. Make it possible for the root FS to run being mounted read-only
4. Dump the installation to the CF and make it bootable
5. Profit!

It’s not rocket science, but I’ll be writing something about it  for those who could find it useful. Check out the home server tag if you are interested, and good luck!

UPDATE: Here is a photo of the AC adapter, in case you want to Google it.

Since the project has advanced so much over the last months, we have decided to boost the release closer to the 1.0 milestone. Many things have been improved, in stability, features  and performance. The Windows build has received some attention, and though it still has a lot of issues, Stefan de Konik has built a beta Windows package for people to try it out and help us sort out the rest of the problems. Great job as always, Stefan! The admin part is still not running under Windows, but you can always create the necessary config files on another environment and try out the Windows binaries.

In this release the caching mechanisms have been fixed, the web server can now be bound to multiple IPs and ports at the same time, a new balancing strategy has been added (so sticky sessions can now be implemented, for instance) …

To find out more about it, read the official release note for 0.98

Try it out. Cherokee is the fastest web server there is right now.

Her you have some links:

• The mailing lists
• Download link
• Online documentation

Yep. It is! Octality‘s first and very own Sun Fire 12000. Yes, I know it was recently retired by Sun, but still 52 processors and 288GB of RAM make a hell of machine to test things on. The photograph was taken this morning at the storage room.

Being dedicated to High Performance does have its benefits, don’t you think? It’s deffinitely getting interesting around here. I bet not many start ups get this kind of hardware after just a few months of existence.

By the way, this fella isn’t precisely small. It is 191x85x166 cm and weights 987kg.

Anyway, I’ll post again once  I have the things properly tested and I’ve spoken to the people of IEArobotics. For now, here is the link to download Wiilson if you want to try it out.

As mentioned earlier, it is just a PWM Wiimote implementation to control a Skybot. The Wiimote is interfaced thanks to the excellent pywii library, Orienting the Wiimote makes the bot move and it goes faster or slower depending on the inclination of the controller. Changing from mode ‘A’ to ‘B’ (or ’1′ to ’2′) overrides this behavior and controls the bot with the direction keys of the Wiimote, being able to alter speeds with the ‘Plus’ and ‘Minus’ buttons. It’s not pretty, but it is a quick hack and works fine. If you want something better you’ll have to wait for the release of pybot, a Python module to control (extended) libStargate managed robots with PWM support. The only class present right now is to control the Skybot as it is out of the box, so PWM support is software based -you’d have to rewire it if you wanted a hardware version of this, much better but totally out of the scope-.

Coming up soon, at least as soon as our bot gets de-cannibalized if that is even a word!

By the way… I think I’m getting to love this stuff. I’ll have to buy a Skypic or Arduino for myself. You can’t ever play around enough with these things. And to think it was always there and I never knew!

Hacking these things has been fairly easy thanks to some pretty handy pieces of software we stumbled upon at IeaRobotics and a bit of Python magic. The tools of the trade were Pydownloader to program the Skypic, libStargate to interface the PC and the bot, and finally Pywii, a wonderful Wiimote library.

We ended up implementing a new server for the Skypic that should enable a smooth control of the acceleration applied to the Skybot in response to the Wiimote’s movements. To handle it we had to extend libStargate. Our job wasn’t particularly hard to do, but up until now you only had the chance of applying an all-or-nothing type of movement. Now the acceleration is proportional to the pitch and roll values of the controller. Since the controlling code is in the PIC instead of the computer, the effect is really smooth.

The bot has dual power. 6V for the Skypic and 9V for the servos. If only we had used 12V for these the effect would be nicer yet, but overall its fine.

I’ll clean the code a bit before submitting the patches to the project’s author, and I hope to have it ready and submitted this week along with a new wrapper class around libStargate to control specifically the SkyBots with PWM capabilities. It is called pySkybot, by the way.

That was until last week. And yes, it finally arrived on Monday.

I know it wasn’t long ago when I said that I wouldn’t probably have an eReader for a long time. But what can I say. I read a lot. And as noted, I’m a geek. So it was pretty much something bound to happen.

This eBook-reader isn’t as nice as the iRex Illiad but is way less expensive and still has some pretty decent specs. And it looks cooler too. It supports some formats, including PDF which is a must-have given the amount of PDFs in my collection. It also has a good battery life of around 7500 page turns if audio reproduction is not enabled. These things use e-Ink, so energy is used only when the page has to be rewritten, not while you are actually reading the page. And the display is very readable even under direct Sunlight. Good luck trying to do that on a PDA.

I have a fairly nice collection of eBooks, both technical and non-technical, in a variety of languages. I was actually worried with PDFs not displaying non-Latin alphabets, but I tried it with some texts in Arabic and, apart from not showing the titles at all in the general book-listing menu,once a selection was done it displayed with no problems. Some English PDF also show an incorrect title, so I’m not really sure if it is related to the language or to a problem with the files.

Anyway, I’m quite happy with my new toy. I’ll probably do a lot less bookbinding from now on, but I’ll be reading much more to compensate.

By the way, there are thousands of eBooks freely available on the net, so I’m quite sure I won’t be using the proprietary BBEB Book format supported by the PRS-505. Some useful links are GNU Press, Wikibooks and Project Gutenberg.

And here is a quick tip. You can use Google to look for tons of eBooks. For example, if you were interested in Unix books a search string like this one would do the trick:

-inurl:(htm|html) intitle:(“index of”|”last modified”|”parent of”) + (“ebook”|”ebooks”|”book”|”books”) + (pdf|chm|doc|txt|zip|rar|djvu) + unix

Happy hunting! I’m going to bed to read now ;)

You can see the whole story at Hackaday. Although I’m not really used to hacking with circuits, I do check some of these sites on a regular basis. And I must say every now and then they come up with things that make me wish I were Ajo ;-)