I received the usual amount of paypal scam mails yesterday and, for some unknown reason, decided to read one. Looked like the ordinary scam, with an attached html file imitating some paypal login site. Apart from two lines near the end, which obviously are supposed to look like a live chat with -- Frank Abagnale.

In case you don't recognize the name, Frank Abagnale Jr. is an american security consultant, who earned his living as a conman, forging checks, before he got caught at the age of 21.

From: "PayPal Accounts" <accounts@int.paypal.com>
Subject: Notification of Limited Account Access
To: <bwachter-spam@lart.info>
Date: Thu, 22 Jul 2010 22:42:09 +0100

Dear Member,

As part of our efforts to provide a safe and secure environment for the
online community, we regularly screen account activity.
Our review of your account has identified an issue regarding its safe use.
We have placed a restriction on your account as a precaution.

To lift the restriction we will require some further information from you.

If, once we review your further information and we're confident that the
use of your account does not present a safety risk to our service and
customers, we'll be happy to reinstate your account.

We have sent you an attachment which contains all the necessary steps in order to restore your account access.
Download and open it in your browser.

Frank Abagnale JR is typing...
Frank Abagnale JR: After we have gathered the necessary information, you will regain full access to your account.

We thank you for your prompt attention to this matter.

Very sincerely,
PayPal Review

I'll publish all the annoying quirks of using Openembedded under the tag Openembedded -- mainly as reference for my own purpose. Since many of the issues can't be resolved by a simple google search this article series might prove useful for other developers, too.

If during a build ipkg-make-index throws something like the following errors

Traceback (most recent call last):
  File "/media/software/OE/aard-build/tmp/staging/i686-linux/usr/bin/ipkg-make-index", line 114, in 
    pkg = ipkg.Package(filename)
  File "/media/software/OE/aard-build/tmp/staging/i686-linux/usr/bin/ipkg.py", line 161, in __init__
    tarStream = ar.open("control.tar.gz")
  File "/media/software/OE/aard-build/tmp/staging/i686-linux/usr/bin/arfile.py", line 61, in open
    raise IOError, (2, "AR member not found: " + fname)
IOError: [Errno 2] AR member not found: control.tar.gz

go and find out which package was last touched (strace helps). Most likely it's an empty ar archive. To get on with your build quickly just remove it, for a more permanent solution try to find out why the recipe in question results in empty archives.

I've just completed Aardview 0.1.1, which fixes a few minor quirks the 0.1 version had. Changes include:

• initial window size can be configured; last window size can be restored on startup
• rescale the displayed image if the window size changes
• pasting into Aardview now works for file names, too. Version 0.1 only allowed pasting directory names to change the current directory
• give images loaded on application startup the correct size
• new shortcuts for toggling display of the directory/file listings

The Touch Book comes without a battery backed RTC, which means that the device will lose the correct time every power down. While this won't be much of a problem once power management works and the Touch Book stays mostly on it's quite annoying right now.

There are several easy to use RTC chips with different interfaces available. Since the Touch Book uses I2C, and the I2C buses are easily accessible chosing a RTC chip with I2C interface appears to be the best option. This article demonstrates how to hook up a DS1307 to one of the Touch Books I2C buses.

You need: One DS1307, one 3V Lithium Cell with at least 48mAh, one 32.768kHz quartz crystal, some wires. You should be able to get these components for about 3 Euros.

First you bend the pins of the crystal so you can put it on top of the DS1307 and solder it to X1/X2 (pins 1 and 2), and solder GND (pin4) to the batteries negative terminal:

Now mark pin 1 on your cable, and make a note which wire you'd like to use for which signal. In my setup the lines from right (1) to left (4) are:

Connect the cable to the DS1307: GND to the batteries negative terminal, SDA to pin 5, SCL to pin 6 and VCC to pin 8

Use a small piece of cable to connect the batteries positive terminal with VBAT (pin 3), and mark the soldering points we want to use on the mainboard. The interesting pins from right (1) to left (8) are: USB 5V (1), used as power supply for the chip during normal operations, GND (4), SCL (5) and SDA (6).

Update: Since USB 5V is only available when the USB subsystem is loaded using it is not the best option. When using USB as power source you need a 1 second wait in the kernel modules initalization routine. A better option is soldering VCC to L21:

Disconnect your Touch Book from the power supply, unplug the internal battery, and carefully (preferably without accidentally swapping some lines) solder the wires to the mainboard (Update: The following pictures are for the version using USB for VCC. Better use 3 wires to the interpart connector, and a seperate wire from VCC to L21). After that you can turn on your Touch Book to test if everything works.

You need to get the i2c commandline utility from Gumstix to initialize and test the chip. You can use this version compiled for AI OS if you don't want to compile it yourself. Save the i2c program somewhere in the search path. My binary tries to open /dev/i2c-3, while the gumstick sources use i2c-0 by default. You'll need to adjust this if you use the sources.

To initialize the RTC and set the time to February 19th 2010, 00:51 do the following:

i2c --count=8 0x68 wb 0x0 0x0051000719021000

0x68 is the address of the chip, for the date format description please read the DS1307 datasheet (Table 2, Timekeeper Registers). If everything worked well you can now use watch to see the RTC counting seconds:

watch -n 1 i2c --count=8 0x68 readbyte 0

Once you're satisfied with the results you can stick the battery to the displays backside using some double sided adhesive tape. The attached chip fits nicely into one of the notches around the border:

To use the chip as a RTC you can either apply my patch to the AI-OS tree and build your own kernel image, or download a patched uImage. Just copy the uImage over the one on the first partition of the SD card, and reboot.

The new DS1307 should show up as first RTC, the old TWL4030 as second:

$ dmesg|grep rtc
[   19.007293] rtc-ds1307 3-0068: rtc core: registered ds1307 as rtc0
[   19.007324] rtc-ds1307 3-0068: 56 bytes nvram
[   19.007659] twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc1
[   19.007781] twl4030_rtc twl4030_rtc: Power up reset detected.
[   19.008148] twl4030_rtc twl4030_rtc: Enabling TWL4030-RTC.
[   19.273559] rtc-ds1307 3-0068: setting system clock to 2010-02-21 13:52:16 UTC (1266760336)

You can control both RTCs using hwclock, though the TWL4030 is mostly useless after the mod:

$ hwclock -f /dev/rtc
Sun Feb 21 14:09:47 2010  0.000000 seconds
$ hwclock -f /dev/rtc1
Sat Jan  1 00:17:32 2000  0.000000 seconds

For more information you can poke around in sysfs, interesting locations include /sys/bus/i2c/devices/ (3-0068 is the DS1307), /sys/bus/i2c/drivers/ and /sys/class/rtc/.

My build system for nightly builds is finally back online. For now it's just used for The Mana Client, but other builds will be added soon.

The current version can produce Windows builds using MingW and NSIS as well as static Linux builds using dietlibc. I'm currently adding support for Win32 Qt builds.

git made implementing a nightly build system a lot easier. As it provides wrappers around the most common VCS dealing with several VCS requires next to no additional code. Clean builds can easily be ensured with almost no overhead by keeping a clean repository to pull in upstream changes, and creating fresh clones from it for the builds.

The recently released Linux kernel 2.6.32 finally includes support for some device filesystem again. It's called devtmpfs, and simply creates device nodes for all devices known to the kernel in a tmpfs. I've been using a similar approach on some boxes for the last years, and I'm quite glad that I don't have to keep an out-of-upstream filesystem up to date any longer.

The main reason for including it into the kernel apparently was `bootup speed', udev needs too much time parsing sysfs for devices on complex systems. With devtmpfs, udev finds a populated /dev directory and just needs to adjust some permissions. While this hopefully will solve some of the current udev problems like using NIS/LDAP groups, I think in the long run it's more important that it's possible again to have a udev-less system with a dynamically generated /dev.

There are several cases where this can be important. Sometimes it's nice to run a system where no hardware gets plugged in after bootup without a static /dev. udev is more prone to errors and way to complex for that scenario, it's enough to have the kernel generate the device nodes, and adjust a few device permissions on startup. I've been running my router that way for several years with a custom linux, and was quite glad not wasting inodes on the 4MB memory card I used.

More importantly, it allows for small initramfs images on systems with limited hardware resources again. I've proved about three years ago that it's possible to include a minimalistic package system in an initramfs while keeping its size under 60K. This allowed me to bootstrap a custom distribution with a 2.6 kernel from CD on a system with only 4MB of RAM - the initramfs contains code to check device nodes for a cd drive, mount the cd, search for packages, and extract it to hard disk. Shipping a static dev for such a setup either is prone to errors due to missing device nodes, or takes up too much space. Same goes for the udev userland tools.

You don't need much additional code around your package system to get an installer (given you don't need a shiny UI): You need to do some basic hardware setup, like formatting a drive, mounting the future rootfs. After that it's just ordinary package system functionality. You could even do parts of the hardware setup in the first package to be installed as pre-install scripts, and let this package pull in all other required packages as post-install dependencies.

For embedded systems this approach will give you completely new install or recovery scenarios: You just need to flash a kernel with a 20K overhead (compressed), and you'll be able to do the initial installation or a recovery installation during an ordinary bootup (given the kernel can get the network running). Going for a two-kernel-approach, one non-erasable rescue kernel, and one for the final system your device is virtually unbrickable, even for users unfamiliar with serial interfaces or JTAG. (Some systems, like the WRT routers, listen for incoming TFTP transfers on startup to reflash bricked devices. While this gives you an equally unbrickable device it's harder to implement than the above in-kernel approach, and depends on the actual hardware/bootloader combination)

I've stopped development on my package system implementing the above ideas after finishing a working prototype a few years ago, partly because devfs was vanishing, making the device handling to complex, partly due to the lack of time. The first reason has been eliminated with devtmpfs, now I hope I'll be able to find the time to complete the package system.

A few interesting gadgets which have been announced for a long time are now finally becoming available. All feature an ARM CPU and are running a custom Linux version. Two of the devices rely on an active community for further development, though it's possible to replace the operating system easily on all of them.

Touch Book

The Touch Book is by far the most interesting piece of hardware shown here. It's a netbook with a detachable top, giving you a tablet when needed. AlwaysInnovating has been shipping a limited amount of beta hardware devices since about August, but reached a stable design by now and announced to ship everything in the order backlog pretty soon.

The device is designed to give you easy access to the mainboard, which features 4 internal USB slots. Two of them are already used for WLan and bluetooth dongles, the other two are for your own enhancements. All the hardware sits in the tablet part of the device, the keyboard only contains an additional battery pack. You put the display on the keyboard backwards, giving you a slightly thicker tablet with the additional battery runtime. Or just take of the tablet, and use it seperately. Like, stick it to your fridge using the included magnets.

The software is still in beta, but is expected to become release quality by end of December. The preinstalled Touch Book OS is based on Angstrom, other distributions working on the device include Android, Ubuntu and Gentoo. Anybody getting this device now should be aware of his status of a paying beta tester, though it looks like it'll give you a lot of fun.

SmartQ 7

The SmartQ7 is an Internet tablet with a 7" touchscreen. It's the most mature of the devices presented here, and most likely the one you want to get if you'd like to spend more time using it than making it work. The hardware has been finalized several months ago, though the operating system still seems to have some problems.

It's manufactured the `classic way', by an old fashioned company who sells devices with beta grade software as final product, trying to keep the customers happy by supplying regular updates. While that's fine as an ordinary user it leads to a cluttered community of people hacking the device, resulting in lots of searching if you want to change something by yourself without duplicating efforts.

You can order the SmartQ from DealExtreme if you want to give it a try.

txtr Reader

The txtr Reader is an ebook reader with an epaper display. The operating system is based on Fedora - not a decision I would have made, but at least it's a well known base which can be customized, if needed. It's booting from an SD card, which makes it easy to try out custom operating system images, without bricking the device.

The final hardware specifications have been announced only a few days ago. Unfortunately they decided to kick out WLAN support last-minute to keep the retail price of the device under EUR 300. Which means that - unless you want to fiddle with bluetooth NAP - you need to pay a monthly EUR 12 subscription fee for 3G to get wireless access to the Internet.

I've been looking forward to the txtr reader launch for a long time now, but decided I won't get one. WLAN was the connection I most likely would have used most of the time, and I'm not willing to spend 300 bucks on a gadget with one of the main features I'm interested in gone. I guess it should be possible to hook up a USB WLAN card, and patch the operating system to recognize it, but I won't spend money to try it. At least that saves me the time I would have needed to put in to write a BBeB reader to be able to read my Librie ebooks...

Conclusion

I'd get the touch book. Preferably with keyboard, as the software is still in beta stadium and may get you into situations where you need to have a keyboard plugged in. Since you can just plug in any USB keyboard it would be my first choice for a tablet without keyboard, too. With its well documented hardware design and several operating systems to run on it clearly offers the most hack value.

The SmartQ 7 is nice if you can't afford the touch book, or don't want to play that much with the operating system or hardware.

The txtr reader is basically a disappointment, I'd wait for the next release, hoping for it to contain WLAN again. They clearly decided to aim the first revision hardware to end users instead of hackers improving it, despite trying to emphasize the openness of their platform for the last months. To be honest, the developer documentation they've released so far is mostly worthless. I've hoped for them to release an early batch of readers to developers (like AlwaysInnovating did with the touch book), but as an end user it's just too expensive.

Notes GUI programming, introduction

The C/C++-API toolkit for Notes provides the developer a lot of interesting new options. You can write addin programs or dlls for both the Domino server or the Notes client. You can perform operations neither Java, nor Lotus Script, nor the formula language will allow you to, and you'll get better control over error handling in some cases. Last, but not least, you can write stand alone applications to perform tasks without blocking the client or requiring the client to be running, unlike any solution using Java/Lotus Script/Formula language.

For the latter case it's sometimes desirable to provide a GUI to the user. The classic win32-MFC-approach is a pain in the ass, takes long, and is prone to errors. Fortunately, it's possible to combine a Notes API program with the Qt toolkit, which will enable you to rapidly develop a GUI for your program, assist you in providing translations, while keeping translations, GUI and code separated.

Even if you're writing a server plugin you might benefit from Qt hiding some of the usual cross platform annoyances, provide translation functions, and a few nice-to-have little helpers.

This article is the first in a series of posts about writing GUI applications using Qt and the Lotus C++ toolkit. I'll cover setting up a build environment under Windows first, to continue with topics like a simple sample application, a multithreading example, a custom model to tie to Qt's model/view-enabled widgets, using Notes API datatypes in signals/slots, and porting your applications to UNIX.

Required software

To start you'll need to install three software packages:

Visual C++

The Notes C++ toolkit documentation lists Visual C++ 6.0 as supported compiler, but works with any Visual C++ compiler newer than that. Qt/Windows is mainly developed using Visual Studio 2005 and 2008, so you should at least use VS 2005. You only need the command line tools, which means you can get away by only installing freely available components. I suggest using VS 2008 (Note: Even though I'm talking about VisualStudio just Visual C++ should be enough to follow my articles. Installing VS is just the easiest way, given you have access to it)

Notes C++ Toolkit

Unless you need features only available in Notes 7 or Notes 8 I suggest downloading the latest version of the 3.0 toolkit (3.0i at the time of writing). It's a free download you can get from the Lotus download page, though you'll have to register an IBM account. Unpack the toolkit wherever you like -- I'll assume it's located in c:\notescpp for the rest of the series.

Qt

Unless you have a commercial Qt license you'll need to build Qt for VS by yourself (Update: Since the 4.6 release Nokia provides VS2008 binary packages). Get the Windows source package from Nokias Qt download page, extract the package and follow the included instructions. If you don't want to go through all the configure options you can save build-qt.bat to your Qt source directory (we'll assume it's c:\qt\4.5.2), add c:\qt\4.5.2\bin to your PATH variable, and execute the batch file from a Visual Studio command prompt. This will take some time, and requires about 5GB of disk space.

Final steps

With Qt compiled, VS installed, and the Notes toolkit unpacked there's not much left for this article.

Header pitfalls

The Notes API redefines a few identifiers found in the Windows API headers, so you need to make sure your compiler parses the Notes headers first. Since the VS init scripts prepend their include directories to the %INCLUDE% variable you can't just add the Notes include directories to the system wide variable, like you'd usually do. You can either modify the VS init scripts (which are rather messy), or put a batch file with the following contents somewhere in your path:

set INCLUDE=c:\notescpp\include;%INCLUDE%

If you forget to execute this batch file before trying to build a notes application the build will fail.

Compiling a sample notes application

As a last step you should now try building some of the sample notes applications you can find in c:\notescpp\samples, like the mailscan example. Open a VS command prompt, navigate to the sample directory, execute the notes-dev batch script, and build the example:

Setting environment for using Microsoft Visual Studio 2008 x86 tools.
c:\Program Files\Microsoft Visual Studio 9.0\VC>cd \notescpp\samples\mailscan
C:\notescpp\samples\mailscan>notesdev
C:\notescpp\samples\mailscan>set INCLUDE=c:\notescpp\include;c:\Program Files\Microsoft Visual Studio[...]
C:\notescpp\samples\mailscan>nmake /f mswin32.mak

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl -Zi -Od -DDEBUG -c -W3 -nologo -GX -MT -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -DW32 -DNODLL  
-D_X86_=1 -Zp1  -D_MT -MTd MAILSCAN.cpp
MAILSCAN.cpp(20) : fatal error C1083: Cannot open include file: 'iostream.h': No such file or directory
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.EXE"' : return code '0x2'
Stop.

Oops. You just made your first contact with the prehistoric C++ used in the Notes C++ API. The errors here are easy to fix, however. You need to replace

#include <iostream.h>
#include <fstream.h>

by

#include <iostream>
#include <fstream>
using namespace std;

and remove libcimt.lib from the makefile.

Coming soon...

In the next article I'll show a simple example application combining Qt and the Notes C++ API, and tell you about error handling. Starting with the 3rd article I'll present an actually useful application, which gets more and more features as we cover more advanced topics.

The swedish domain registry used yesterdays evening to test one of the classic BIND shoot yourself in the foot scenarios -- with great success. You need to substitute DNS for BIND on most occurences to make the article factually accurate. Apparently they didn't train their people to be extra careful about BINDs many pitfalls -- and didn't have a testing step involved in their zone updates. I hope they learn from their grossly negligent workflow and make sure this never happens again -- and remind the many working the same way that it might be wise to have safer procedures in place. There's absolutely no excuse for not having safeguards against software behaviour known for over 10 years to be potentially harmful.

I've got a Bilora Box some time ago. Since I'm shooting medium format with my Pentax 645n anyway both films and tools to develop them are at hand.

Box cameras are pretty much pin hole cameras on steroids -- one cheap fix-focus lens, if you're lucky more than one aperture, shutter speeds of about 1/30s and bulb. On the back of the case is a small red window for the picture counter -- numbers printed on the backing paper of the film.

My box takes 6x9cm pictures, big enough for contact prints. Given the blurriness of the pictures you don't want to enlarge them much anyway. As an alternative to making prints and scanning them I tried scanning the negatives directly today -- with impressing results, when ignoring that the scanner became quite dusty and I'm unable to locate it. Fortunately the dust and reams add to the antique look.

To scan the negatives I placed two sheets of paper on top of the negative and added light from two 500W halogen spotlights to replace the lack of a transparency unit.

(Click to enlarge)