bloovis.com

The new Amazon Kindle app for Android stores its books in the “kindle” directory on the phone’s SD card. I naively assumed that I could copy any non-Amazon but Kindle-compatible books into that directory and have the app recognize them. I tried this with a mobipocket Jane Austen collection (a .prc file) that works just fine on the Kindle, but the Android app crashed immediately after display the book’s title and author.

The trick to getting such a book to be recognized on Android is to use Amazon’s free personal documents service to convert the file to a DRM-ified .azw file.

First, I emailed the .prc file as an attachment to my free personal documents email address: EXAMPLE@free.kindle.com (obviously, you must replace EXAMPLE with your configured Kindle email address). Within a few minutes Amazon converted the file to a .azw (DRM-ified version of the original file), and replied with an email that included a download link for the converted file.

I saved the file to a temporary directory on my computer and renamed it by changing the .azw extension back to .prc. This renaming is very important; otherwise, the Android app won’t recognize the file.

Finally, I copied the file to the kindle directory on the phone’s SD card. The Kindle app can see the file and display its contents.

It looks like the upgrade to the latest Ubuntu is going to keep me busy solving problems for a while.

Today’s second problem has to do with the fingerprint reader in the ThinkPad X41. There’s a good source of information here, but there wasn’t a definitive set of instructions for Ubuntu 10.04 that actually worked. Most of the uproar about the fingerprint reader in Ubuntu 10.04 has to do with a bug where the Enter key has to be pressed after swiping your finger. I couldn’t even get to that point; the trouble was getting logins to prompt for a finger swipe.

As per the instructions at ThinkWiki, I installed and configured the required packages from the standard repository (no PPAs):

sudo apt-get install thinkfinger-tools libpam-thinkfinger
sudo /usr/lib/pam-thinkfinger/pam-thinkfinger-enable

Then I was able to use tf-tool --acquire and tf-tool --verify to show that the fingerprint device worked. But I was not able to use tf-tool --add-user USERNAME to create a fingerprint file for use by the authentication system; this build of tf-tool did not support that option. So I had to set things up manually, by acquiring the fingerprint file and placing it in the proper directory, with the proper name, and with the proper permissions:

sudo su    # login as root
cd /etc/pam_thinkfinger
tf-tool --acquire USERNAME.bir
chown USERNAME:root USERNAME.bir
chmod 400 USERNAME.bir

In all of these commands, substitute your ordinary user name for USERNAME. After this is done, authentication prompts, either in a terminal (e.g., with sudo) or in X (e.g., the login screen), should ask for either a password or a finger swipe. Due the known aforementioned bug, it may also be necessary to hit Enter after the swipe.

I have an old Logitech QuickCam for Notebooks that uses the pwc (Philips Web Cam) driver on Linux. This camera has always worked flawlessly on Linux Mint 6 (Ubuntu 8.10). But on Linux Mint 9, the camera only worked the first time it was plugged in; on subsequent plug-ins, no programs could read images from the camera. The fswebcam utility reported a timeout trying to read the frame buffer; other programs like Cheese or Skype simply displayed blank images.

The solution is to unplug the camera (if it is not already unplugged), then forcibly remove the pwc driver:

sudo modprobe -r pwc

Then the next time the camera is plugged in, the pwc driver will be loaded automatically and will work properly. This has to be done every time you unplug the camera. I’m not sure why this is necessary with recent Ubuntu releases.

My employer’s VPN system doesn’t allow more than one login at a time. But there are occasions when I’d like to be able to use the VPN from two different laptops simultaneously. The solution, most of which I found here, is to use iptables on the machine running the VPN to forward packets from the machine not running the VPN.

In my case, the Juniper VPN software (ncsvc) sets up a connection on the net device tun0, and the network address is 10.0.0.0. So after I start the VPN on one machine, I run the following script on that machine:

#!/bin/sh
# Share the VPN connection with other machines on the local net.
# The assumption here is the the VPN network is 10.0.0.0.
if [ `id -u` -ne 0 ] ; then
   echo "You are not root.  Rerunning with sudo..."
   sudo $0
else
   echo "1" > /proc/sys/net/ipv4/ip_forward
   iptables -A FORWARD -i eth0 -d 10.0.0.0/8 -j ACCEPT
   iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
   sysctl net.netfilter.nf_conntrack_acct=1
fi

Be sure to replace the network address (10.0.0.0), VPN net device (tun0) and local net device (eth0) with the correct values for your system.

Then on the machine that is not running the VPN, I run the following script:

#!/bin/sh
sudo route add -net 10.0.0.0 netmask 255.0.0.0 gw VPNHOST
sudo cp /etc/resolv.conf.vpn /etc/resolv.conf

In this script, replace VPNHOST with the hostname of the machine that is running the VPN (i.e., the name of the machine that is running the first script above). I use static IP addresses on all of my machines, and have added entries for these addresses to /etc/hosts on all machines. I’m not sure how this would work with dynamic IP addresses (DHCP).

The last line of this script is the one new thing I’m doing differently from the scripts at the aforementioned link. It makes the non-VPN machine’s name resolution configuration file identical to that of the VPN machine. This allows the non-VPN machine to resolve hostnames residing on the VPN. In order for this to work, I had earlier copied /etc/resolv.conf from the machine running the VPN to the non-VPN machine, and renamed it to /etc/resolv.conf.vpn.

I just spent many hours getting a 4GB USB key into a state where it can be used to boot Linux Mint 9 (based on Ubuntu 10.04). Here are some notes on the problems I had to solve.

In the past, I’ve used unetbootin to create bootable USB keys. When I did this with the Linux Mint 9 ISO image, the resulting USB key booted up just fine, but the installer application hung when trying to run the partition editor. I narrowed this down to an assertion failure in libparted. Apparently it doesn’t like the geometry on some USB keys. This is a known bug.

Fortunately, the ThinkPad R61 has a CD drive, so I created a CD from the ISO image and booted that. Then after installing Mint 9 on the hard disk and booting that, I was able to create a bootable USB key that didn’t crap out in the installer. I did this by using Mint 9’s built-in Startup Disk Creator, which is in the main Menu under Administration. I told it to erase the entire USB key, which apparently reconfigured its partition table into a form that libparted liked. I verified this by rebooting the R61 with the USB key and running gparted.

The next set of problems came when I tried booting an older ThinkPad R50p with the USB key. As in all recent ThinkPads, you can choose the boot device by pressing the blue ThinkVantage or Access IBM button at startup, then pressing F12. But on the R50p, the USB key wasn’t shown as a boot device. I ran Setup (IBM’s term for BIOS configuration), and in the Startup screen I tried to enable the USB HDD device. This didn’t work; the machine just beeped at me. After a long bout of head-scratching, I finally figured out that Setup doesn’t allow more than eight boot devices to be enabled. I disabled a couple of useless boot devices (e.g., HDD1 and USB Floppy), and then I could enable the USB key.

Finally the USB key would start to boot on the R50p. But after the Linux Mint logo came up, the machine hung with the hard disk light on solid. I rebooted from the USB key and selected the recovery mode boot option in Grub (I forget the exact name for it). Then I was able to see the last error message at the hang. It was an I/O error accessing the fd0 device, which is the floppy. More headscratching and Google searching revealed that I needed to disable the floppy device in Setup.

Now I was able to get past the hang on booting from the USB key, but then X refused to run, displaying a dialog box saying that it was going to run in low graphics mode. This turned out to be a problem with the kernel mode setting (KMS) feature of recent Ubuntu releases. Apparently this is a very bleeding-edge method of determining graphics card type, and it doesn’t appear to work on older machines. The fix was to provide the nomodeset kernel parameter when booting. I did this by hitting Enter when the Grub menu came up, then hitting Enter again to edit the kernel command line. I add the nomodeset parameter and pressed Enter a couple of more times to boot. This time the system was able to boot to a good desktop, though the Mint logo didn’t appear during the early boot stages.

I upgraded one of my ThinkPads from Linux Mint 7 to Linux Mint 9 today, and discovered that I was no longer able to use my HP P1006 printer. The HP printer tool (hp-toolbox) detected the printer correctly, downloaded the appropriate plugin, but then couldn’t install the plugin. Running the tool from the command line didn’t give any extra information. This is a known bug in Ubuntu 10.04.

The solution is to download and build the HP printer package (known as hplip) from source. The complete instructions are here. I had to install the following extra packages before the configure and make steps would succeed: libjpeg-dev, libsnmp-dev, libcups2-dev, libusb-dev, python-dev, libsane-dev, and libcupsimage2-dev.

Keyring is a fine little open source application for Palm OS that stores and generates passwords. There is no Android version of this program, so I decided to move to KeePass 1.x, both the Linux version and the Android version.

Then I hunted for way to import my Keyring data into KeePass 1.x. I couldn’t find a tool to do this, so I had to invent my own method, which included writing a conversion script in Ruby.

The first step is to generate an XML version of the Keyring data file, using this Java program. I fed it the Keyring data, a file called Keys-Gtkr.pdb that I had previously backed up onto my Linux machine using pilot-xfer. It produced the XML equivalent, which I redirected to a file.

Then I wrote a Ruby script called kr2kp, which reads the Keyring XML file and outputs KeePass-compatible XML. I saved the output of this script to another file.

The Android version of KeyPass doesn’t import XML, so I turned to the Linux version, and used it to import the XML file I had created in the previous step. Then I saved the resulting database into a file called keyring.kdb.

Next, I copied keyring.kdb to the keepass directory on the Android device’s SD card. (The exact path of the SD card will depend on the directory where your computer mounts the SD card when you connect the Android device via USB.)

Finally, I ran the Android KeePass app and opened the keyring.kdb file. The Android app is somewhat limited, and doesn’t let you move entries between groups or rename groups. So that kind of manipulation has to be done on the Linux side, and then the .kdb file has to be copied to the Android SD card, as described above.

One of the reasons why I decided to buy an Android device was to investigate the possibility of writing applications for that platform. After spending a couple of days with Android, it’s pretty clear there are huge voids in the app space waiting to be filled. The transition from Palm OS is going to be painful because the following apps have no equivalent on Android:

• Adarian Money. This is lovely little financial app that I’ve used for several years to track every penny I spend. The Android checkbook apps do not come close; the best-selling one doesn’t even track expense accounts, let alone support double-entry accounting. Clearly, a lightweight version of GnuCash is needed here.
• DateBk. I’ve used this program for nearly ten years in its various incarnations, from DateBk+ on a Handspring Visor, to DateBk5 on a Centro. It’s the king of calendar apps and nothing on the iPhone or Android comes close. The Google Calendar app does sync with the web version, but is otherwise very minimal. It also has a serious bug: its ringtone reminders do not work when the screen is turned off, so you’ll miss appointments and meetings constantly. Pimlico has hinted that they might be porting DateBk to other platforms, but who knows when or if Android will ever be supported.
• ListPro. This is a checklist app on steroids, almost a mini-database. I use this for packing lists, lists of items lent out to other people, notes on things to look up when I get home, to-do lists, etc. The Android apps are the usual mix: either seriously broken or only supporting a tiny subset of ListPro’s features.

If I didn’t have a full-time job, I’d start working on filling these gaps myself. I may do that anyway as a rainy-day weekend hobby. The prospect of writing in Java is not pleasant, so I may start working on the algorithms and data structures (or Models and Controllers, in newspeak) in Ruby, and hope that Duby is usable on Android by the time I need to start thinking about the UI (or View in newspeak).

After nearly ten years of using Palm OS PDAs and cell phones, I’m moving to an Android phone. I didn’t want to enter over 100 contacts manually on the new device. Some Google searching turned up ways to migrate the contact list, but most of them involved running Palm Desktop software on Windows. It turns out there is a non-obvious, Windows-free method, described here. In case that forum posting goes away, here’s a repeat of this method (slightly modified):

1. On the Palm device, run the Phone app, then select Contacts.
2. Choose the category to display; I chose All.
3. Press MENU button and choose Send Category.
4. Choose Email; this will send your contacts as an attachment file called All.vcf, and will bring up the email app to send it.
5. In a web browser on your desktop computer, open your Gmail account.
6. Find the message containing the attachment All.vcf. Click on the download link for the attachment and save it somewhere on your computer.
7. In Gmail, select Contacts, then Import, and locate the file you saved in the previous step. Gmail will merge the contacts contained in that file into your existing Gmail contacts. Your Android device will find those contacts when it syncs.

I use pilot-xfer (part of the pilot-link package) to back up the data on my Palm Centro, and occasionally to install files on the Centro. It’s always worked fine on Linux Mint 6. The only thing I needed to do before running pilot-xfer was load the visor kernel module using this command:

sudo modprobe visor

But when I switched to a different laptop running Linux Mint 7, pilot-xfer never seemed to be able to connect with the Centro for the second and subsequent attempts after a reboot. Some poking around revealed that the problem is apparently due to the visor module setting up an incorrect symbolic link for the device /dev/pilot. Normally, after you connect the Centro to the computer with a USB cable and press the hotsync button, /dev/pilot should become a symlink that points to ttyUSB1. But I was seeing it point to ttyUSB0, which is the wrong device file for the Centro.

I couldn’t find an elegant way to fix the problem, so I was forced to come up with a brute force method: before connecting the Centro with the USB cable, remove the visor module and the device symlink:

sudo rmmod visor
sudo rm /dev/pilot

Then after connecting the Centro, load the visor module again:

sudo modprobe visor

Note 1: Immediately after you load the visor module, /dev/pilot will point to ttyUSB0. That’s OK. After you press the hotsync button, the visor module should change the symlink to point to ttyUSB1. If it doesn’t, you’ll have to use the brute force “unplug and unload” method I described above.

Note 2: You should always press the hotsync button on the Centro before running pilot-xfer.

Note 3: You can eliminate the need to use the -p option with pilot-xfer by setting the environment variable PILOTPORT to /dev/pilot. Putting this line in your ~/.bashrc (if your shell is bash) will do the trick:

export PILOTPORT=/dev/pilot