I seem to be getting asked about this more frequently lately so let me put this out where google can find it. If you've upgraded to KDE 4.x and suddenly found skim is not working do this:

# aptitude install scim-bridge-agent scim-bridge-client-qt4

...and make sure you have the following environment variables set in your .bashrc :

XMODIFIERS=@im=SCIM
QT_IM_MODULE=scim-bridge

For GTK+ apps:

# aptitude install scim-bridge-client-gtk

...and in .bashrc:

GTK_IM_MODULE=scim-bridge

Source .bashrc, restart skim and everything should work again.

The serial port is still the way to access network components out of band. It is slow, but reliable, and remarkably well standardized. It does not have technical whiz-bangs that can fail when one needs things to just work. That makes it the natural way to access critical infrastructure and still being sure that this access vector still works when most other things are down. Every communication link has two sides, so there is a market for devices with a network link and a bigger number of serial ports to connect the actual devices to. Commercial vendors have a broad choice of serial console servers. Most of them, especially the small products with five to ten ports, are quite expensive, so I have been investigating how do build a serial console server with el cheapo hardware. USB comes to mind here, of course. The hardware side is actually quite easy: A seven-port USB hub, and seven USB-to-serial adaptors (using the widely-deployed Prolific PL2303) are easily purchased for well below a hundred Euros, and naively connected. In my test setup, connected to the hp compaq nc8000 that my blog readers should know only too well by now, the hub does not even need to have its power supply connected. The notebook can power the hub and the seven adaptors just fine. When the UMTS card is plugged in, the ttyUSBx device nodes appear in the order of plugging in the devices. When the system is booted, the order is not very predictable, so one needs - again - udev to give predictable device node names. udevinfo is an important tool to obtain the data set of an USB device which is available to match a device and to act appropriately when it is connected. udevinfo sorts the devices into a tree and shows the relationship of the devices, which device is “behind” which other device from the system’s point of view. udevinfo’s output starts at the leaf of the device tree and shows the information for each node up the tree until its root is reached. One pitfall is that one can only match against the leaf and _one_ other node more up the tree. So you cannot do matches like “the pl2303-based device connected to port 3 on hub 2-3 will be designated USBserial3”. If you try this, your rule will silently be ignored. This is a major turn-off in udev’s implementation. I didn’t try it on sid, but etch definetely shows this behavior. So one can only match like “the tty on the USB subsystem connected to port 3 on hub 2-3 will be designated USBserial3”, but that’s probably as good as it’ll get. The cause for my hub having only seven ports clearly shows itself when one looks at the udevinfo outputs of the fully equipped USB hub: The adapters are connected to ports 1, 2, 3, 4.1, 4.2, 4.3 and 4.4. The seven-port hub is actually two four-port hubs in a single case, with the second one connected to the first one’s port 4. This reflects itself, of course, in the udev rules necessary to address the adapters by the hub port they’re plugged in:

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.1”, \
   SYMLINK=“USBserial1”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.2”, \
   SYMLINK=“USBserial2”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.3”, \
   SYMLINK=“USBserial3”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.1”, \
   SYMLINK=“USBserial4”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.2”, \
   SYMLINK=“USBserial5”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.3”, \
   SYMLINK=“USBserial6”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.4”, \
   SYMLINK=“USBserial7”

These rules will only work for a similary structured hub that is directly connected to the notebook. If there are more hubs in between the “final” hub and the host, the address matched against in the KERNELS matches are going to have a different structure. In the test setup, the first two parts of the address needed to be wildcarded since these addresses keep changing when the host is booted or the hub plugged out and in. So I guess that these udev rules are probably going to fail miserably when more hubs and/or USB-to-serial adaptors are connected. But if one does not do too many changes, things are just fine, and it is possible to put numbers on the USB hub ports and be sure that the USB-to-serial adaptor connected to port 4 is going to be /dev/USBserial4 in the host system. I tried plugging in and out the adaptors in random order, unplugged and plugged the hub itself, booted the host, and the relationship between the port and the device node was stable. In the test environment, I only tested one adapter at a time, but all these tests were successful as well. I guess that many more of these adaptors will eventually need a powered USB hub, but with seven adaptors on a single hub, the power from the USB host is sufficient to live without extra power on the hub. And, I guess, there is some hard limit for the number of USB adapters being used, and some soft limit when managing the ports and adapters is going to get harder. But, I think that a site in need of more than, say, sixteen serial ports on the console server can afford a “real” console server from one of the major vendors, which can be accessed via ethernet, UMTS, ISDN and whatever you can think of. This concludes the hardware part of my serial console server for the poor. Tomorrow, I’ll blog about the software side needed on the host to allow the serial ports to be accessed from the network while still being reasonably secure. The next article will involve ssh, /etc/passwd shells, /etc/shells, a small perl script, ser2net and telnet. And, shell escape is the cue word for grey hairs sprouting on my head.

I starting trying Twitter. Gotta keep up with the kids these days ;) I'm using the twhirl client based on adobe AIR. I tried spaz but it seemed to push the limits of Linux alpha AIR a bit too much. Twhirl seems quite decent. My twitter URL is here for those who care.


In other news I'll try to get the latest release of the current NVIDIA drivers up tonight.

(How I get TV) The British Broadcasting Corporation, the largest UK public service broadcaster, is seen as a slow lumbering beast and a bit clueless about technology, as you can see from the comment when I wrote about Click: Free=beer and facebook-flaming recently. I think that's a pretty typical view. For example, the BBC has recently helped to launch Freesat which is good in some ways (free-to-air and maybe more standards-based than Sky) but still publishes half-truths like

"Installing a satellite dish is a job for professionals"

(On balance, it's no harder than installing most TV aerials, in my opinion, but remember you get no warranty on DIY.) It's pretty much the same situation online, which is why stories like The BBC and innovation [DavePress] and Good news for websites - BBC told to link out more! continue to be news, nearly 12 years after the BBC's website launched. (Source) One of the few areas where BBC triumphs is probably news-gathering, picking up stories that are unpopular with both business and government, like BBC NEWS: Towns triumph in broadband tests which follows the Experts Say Ofcom Wrong About Rural Broadband storm online. I recently helped The Doon of May team look into internet connectivity and I was surprised how bad it was in their location: a bit of attention from BBC News is most welcome. If you'd like to try receiving the BBC - or some other national broadcasters in Europe - by satellite, I'm currently taking Questions About Cycling on Satellite over on my Cycling Fans blog.

So there are three things people should know about stalking on the internet.
1) Every Canadian is on facebook.
2) Every Brazilian is on Orkut (pronouced or-ku-chi)
3) Whoever is left is probably found through a quick google search. Youtube content does help with this.

Just before the New Year we accepted an offer on our house in Norwich, which had been up for sale since September. It was a bit lower than we'd hoped for, but the buyer was an investor and so we hoped it would be quick and not involve too much hassle.

How wrong we were. We finally completed on Friday, with the money hitting our account today (thanks to the Ulster Bank being a bit shit about telling our solicitor how much was outstanding on the mortgage). I'd become convinced that it was going to fall through, that we wouldn't be able to find a new buyer and that we were going to end up having to rent out a house that it wasn't convenient for us to check up on (due to the radioactive body of water between us and it). So I am somewhat relieved to finally be rid of it.

When I moved in Hungary in 2006, I started a direct marketing company. In fact, it is the local local branch of an Italian marketing company where I worked since 2003. The company is growing very slowly: we faced a lot of issues with the local market (I'll probably talk about this topic in another post) and only in the last months things started going on the right path.

I still remember the old days when I spent the whole working day alone, in the office, struggling to find the good motivation to work on something which almost everybody around me considered a failure even before starting. I always considered my company as a family, where trust and respect are the glue for the team members. I remember the old times when Aron, my first employee and now business partner, started learning the internals of the direct marketing: he trusted me, sharing with me the duties of starting up the company.  Looking back I feel proud of what we did and more conscious about what we can do in the future.

Growing also means enlarging the team. To say the truth, I didn't expect to have so many problems looking for new people to add to our team: I interviewed a lot of people for our "python programmer" position, spending a lot of time and energy. I know that living in Hungary also means dealing with a local, small, atypical environment, but we offer the possibility to learn and develop IT and non-IT skills in a young, international environment.

We finally found an interesting guy, with PHP experiences but willing to learn Python. He told us that he could leave his job by the 16th of June, and he could work with us part-time till that date. Everything worked fine for three weeks then, suddenly, he disappeared. For one week, his mobile phone rang, but nobody picked up the line. No answer to e-mails, IRC, MSN or any other communication channel. I was worried, I hoped he was fine somewhere. This morning he called Aron telling him that he was sick, he had an issue with his eye. He visited a lot of doctors. He was busy. So busy that he couldn't call us to tell us so. For one week. After he started working with us four weeks ago. What is more annoying is that he didn't appear worried about his position, about our project, about our company. If I'd have quit from my job, I'd be very very worried about my new employer who is looking for me for one whole week without being able to reach me.

We are a growing company based on a small team, without a strict organigram and a horizontal structure. I trust my workmates, I trust them so much to put in their hands my investments, my reputation, my customers. The best team members knows that errors in this phase (eg. lost customers) can influence the company future and their job position

In this case, I gave out trust, but I didn't get back respect. I'm starting to think that being friendly and building a collaborative environment, a horizontal structure is not helping but damaging the company. Maybe if I'd be a boss with strong authority, then people wouldn't behave in this way.

And yes, of course, the problem with the eye was just an excuse.

Switching to Perl 5.10 for Debian unstable uncovered a bunch of little problems with the Pod::Man based on Pod::Simple that's included with it. I've unfortunately been slow to fix those problems due to being buried in other work, but this release finally cleans up the ones that have been reported, namely:

• Font problems with two or more C<> blocks in a =head
• Fix subheadings with leading *roff metacharacters
• Fix hyphen escaping to not corrupt eth characters

However, the big change is that pod2man now supports a -u (--utf8) option saying to not munge input characters into ASCII and *roff escapes that only work with troff and instead output literal UTF-8 characters and assume one's man program can cope. This will now be true of Debian as of lenny. I have no good ideas for how to do the transition, since the resulting *roff is not portable and, if copied to another system, can even cause deficient nroff programs to segfault. One of the goals of Pod::Man was always to produce portable *roff output, so this option is not the default. However, it is clearly the Right Thing To Do for systems whose man and/or nroff are sufficiently intelligent; any other option either requires embedding groff-specific character escapes (same portability problem) or corrupting non-ASCII characters badly (the previous approach). Any bright ideas welcome. In the meantime, people who know they're working on systems with modern nroff and man can at least get correct output now. Hopefully podlators 2.1.0 will make it into lenny (as part of the Perl package, since it's a Perl core module), either as 5.10.1 if upstream is fast enough or as a Debian-local modification. (We definitely need a new Perl release before lenny; #480428 would be embarassing and is already driving me nuts by producing spurious output from lots of cron jobs. I'm thinking about asking for an upgrade of the priority.)

It has been some time since my last blog post... The thing is, my university vacations ended this week, and overall left a bad taste. Unfortunately, complications ranging from buying a very big new toy from some reasonably strong illness have made an already tight schedule simple impossible to follow. On the end, I haven't dedicated enough time for anything I wanted to during these vacations: Didn't sleep as much as I would like, didn't dedicate enough time to my gf, didn't advance my Summer of Code project anything near as much as I wanted, didn't help a friend to get a Linux install in his shining new laptop, didn't fix my work's server RAID array, didn't package the newest mergeant... The list goes on...

I guess what I wanted to say is: sorry. I know I'm owing a lot of stuff for a lot of people, and I'm really sorry I haven't been able to deliver what I should. I hope to fix all of these ASAP (maybe excluding the sleeping one, seems like a lost cause :P)

Now if just the Sao Paulo's metro stopped this stupid strike...

Using GNOME Network Manager is a neat way to connect to wireless or virtual private networks from a laptop running Debian Lenny, Sid, Etch with Backports or any of the *buntu distributions. You can control everything from the system tray. But not all window managers have a system tray. And with some window managers it’s not obvious how to make them work with one of those lean third party trays and panels. Especially my favourite window manager for small displays as on the EeePC – ratpoison – insolently puts any panel or tray in the middle of the screen by default. It took me a moment to find out how to make ratpoison work with my favourite third party system tray trayer (which can handle transparency and is only a system tray, no taskbar). First we need to make ratpoison ignore the trayer on the one hand and and reserve space for it on the screen. Fiddling around with preconfigured frames didn’t work well and the following way is also more straight forward:

1. trayer always has “panel” as window title, so adding the following line to your .ratpoisonrc makes ratpoison ignore trayer:

   unmanage panel

2. Now all windows overlap the trayer, so we need to configure the space for it. Trayer in the default configuration shows up at the bottom and has a height of 26 pixels, so we tell ratpoison to add a padding of 26 pixels at the bottom of the screen by adding the following line to the .ratpoisonrc:

   set padding 0 0 0 26

Now we are confronted with the problem that these settings only apply to new windows, not ones which were already running when ratpoison starts. I usually start my X session using an .xinitrc or an .Xsession which calls the window manager using exec at the end. We can start the trayer later though by spawning a subshell in the background with a sleep at the beginning. Also the Network Manager applet (nm-applet) can be started that way. In my case the end of the .Xsession looks like this:

( sleep 1; \
  trayer --align right --edge bottom --distance 0 \
	 --expand true \
	 --transparent true --alpha 128 --tint 0 \
	 --SetDockType true --SetPartialStrut true & 
  nm-applet & ) &
exec ratpoison

The result could look like this: The other programs in the system tray are from right to left: nm-applet (GNOME Network Manager), Twitux (GTK Twitter Client), Audacious, Opera, Pidgin (formerly known as GAIM), Icedove (unbranded Mozilla Thunderbird). The clock on the bottom left is from the package osdclock. Oh, and although I’m fine with trayer: if anybody knows a possibility to control the GNOME Network Manager without the need for a system tray, I would be very happy if you could tell me. :-)

A while ago I wanted to have internet over GPRS (either EDGE or UMTS) via my Nokia E51 working before I leave for the weekend. But whatever I tried, I always got an ERROR if I sent any AT command. Even ATZ and ATH resulted in errors. So started googling for all components: I found AT commands which are said to work with the Nokia E51, I found AT commands which are said to work with Swisscom GPRS and I found many sites describing how to setup a bluetooth modem. But since the even those AT commands which should work with both, Swisscom GPRS and Nokia E51 didn’t work at all, I noticed that all the Nokia E51 howtos were using the USB cable. So I tried that, too, and it worked immediately. It looks very strange to me that the set of AT commands is dependend on which way you connect to the phone. :-/ So here’s my working PPP config:

hide-password
noauth
connect "/usr/sbin/chat -e -f /etc/chatscripts/swisscom-gprs"
/dev/ttyACM0
460800
defaultroute
crtscts
user "guest"
usepeerdns
noccp
bsdcomp 0,0
lcp-echo-failure 10000
lcp-echo-interval 1000
asyncmap 0
novj
nomagic

and the chat script (/etc/chatscripts/swisscom-gprs):

TIMEOUT 5
ABORT BUSY
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO ANSWER'
ABORT DELAYED
ABORT ERROR
'' \nAT
TIMEOUT 12
OK ATH
OK ATE1
OK 'AT+CGDCONT=1,"IP","gprs.swisscom.ch"'
OK ATD*99#
CONNECT ""

So I have now four levels of mobile computing available:

• Nokia E51 with T9 and phone keyboard (for short texts)
• Nokia E51 with Nokia SU-8W bluetooth keyboard (for longer texts and emergencies, see photo on the right)
• ASUS EeePC (7", 630 MHz Celeron, 2GB RAM, 4GB SSD) with Nokia E51 as modem (complete computer, but still small, portable and nearly always with me)
• Lenovo ThinkPad T61 (14" wide screen, 2.2 GHz Core2Duo, 4GB RAM, 160 GB SATA Disk) with Nokia E51 as modem (complete computer with power and disk space)

Should suffice in nearly all situations. ;-)

I ogled with an ASUS EeePC since it was announced, but didn’t want to order one abroad. So I waited until they became available in Switzerland. Digitec is the official EeePC importer for Switzerland and seeems also to be the moving power for yet to come the Swiss localisation of the EeePC. But initially they only offered imported EeePCs with German keyboard layout, but since I really got used to the US layout, I didn’t want to buy ay new laptops or keyboards with German layout. When asking them about US layouts they told me they won’t import from the US and that their competitor Steg Computer is importing US models. But I wasn’t comfortable with Steg and EeePCs also were more expensive there, so I hesitated ordering at Steg. So it was quite unexpected for me when US models showed up on digitec’s website. (Interestingly I never received any mail from their advertised EeePC newsletter, not even when they added 2G models t their repertoire.) So at the end of March (and therefore later as most other geeks ;-) I ordered an ASUS EeePC at digitec. For me, white laptops look like Macs (and Macs are for sissies or masochists ;-) — so I had no problems to decide that I want a black EeePC with US keyboard layout. 2G was to small for my purposes (and also not that much cheaper) and 8G not available. So I went with the 4G, since Debian doesn’t need so much space if you choose the right packages (i.e. neither or at least not that much of GNOME or KDE ;-). I preferred the 4G over the 4G Surf because of the bigger battery capacity (and not because of the webcam which I consider funny but useless:-). Initially the delivery date was set the 28th of March. Then it was subsequently set to “beginning of April”, “mid of April”, “end of April” and “beginning of May”. It finally arrived on 8th of May. In the meanwhile there were reports that even the 4G has been equipped with the smaller battery of the 4G Surf because of some battery shortage after some battery plant burnt down. But fortunately the delivery problems with black 4G US models doesn’t seem to have its reason there and my 4G has a 5200 mAh battery (at least according to its label and ACPI). I also ordered a 2 GB bar of Corsair ValueSelect RAM so that I can pump up the RAM of my EeePC by factor four (for about 10% of the price of the EeePC itself) resulting in having half as much RAM as disk space. Well, I guess, I won’t do suspend to disk in that configuration… ;-) The original Xandros based Linux only noticed 1 GB of the installed 2 GB as already noted on many other places in the web. But that doesn’t really matter, since it only lasted until I found out how to restore it from DVD in case I want to sell the EeePC later (e.g. for getting the successor). It’s fine for novices, but Linuxes feel strange if you can’t even get a console or a terminal with a command line. ;-) The Debian EeePC installer worked fine except that it argued over a checksum error on our mirror which wasn’t reproducable after the installation anymore. I’ve chosen the EeePC to be my first (nearly) pure Lenny installation — compared to the three machines running Sid (i386, amd64 and kfreebsd-i386). It though has a few packages from experimental (mostly xulrunner-1.9) installed. As window managers I have installed ratpoison, FLWM and FVWM. ratpoison — best described as screen for X (although you can’t detach and reattach) since it’s my personal preferences for being productive without big screen resolutions and flwm for a low-resource window manager which can be used intuitivly by both, geeks and non-geeks (and still doesn’t look like Windows at all ;-). And FVWM is installed because it’s my default window manager on all machines with bigger or multiple screens – to be able to compare it with my usual environment. As web browser I’ve got Opera as primary browser (as everywhere else, too) and Conkeror (the EeePC is the test-case for upcoming Debian package of Conkeror) as well as links2 and lynx on the (nearly) text-only side on it, although I need them seldomly. As office programs (as I would ever need some ;-) I’ve got AbiWord and Gnumeric installed since I already use a few GNOME applications (e.g. Network Manager, Twitux, etc.) and OpenOffice.org would take up 170 MB more disk space (then including OOo Draw and OOo Impress) and Siag Office is no more in Debian since years. (Initially I had OpenOffice.org installed instead of AbiWord and Gnumeric until I noticed that I need some of the GNOME libraries anyway.) I also decided that I will need LaTeX then and when so TeX Live also got its chunk of the 4 GB of disk space. I also have a bunch of games on the EeePC. Unfortunately there are a few games which don’t work well on the EeePC due to it’s resolution being smaller than 800x600, so I deinstalled them already again, e.g. I can’t play Cuyo on the EeePC but flobopuyo. Sauerbraten segfaults, but Doom (prboom with freedoom WADs) works fine. Further non-working games unfortunately include Battle of Wesnoth and XFrisk. Still, although quite some parts of GNOME and GNOME Office, TeX Live, ScummVM with Flight of the Amazon Queen and Beneath a Steel Sky, GNU Emacs 22, Iceweasel 3 (aka Mozilla Firefox 3), Icedove (aka Mozilla Thunderbird) and the Iceowl (aka Mozilla Sunbird) are installed, only 2.3 GB of the available hard disk space are used by the installation (i.e. without my home directory). Oh, and btw: Although except the very compact and a little bit wobbly keyboard the EeePC doesn’t feel really small to me (I’ve got quite small hands), but when I sat down in front of my 14” ThinkPad T61 after a day or two with EeePC, the T61, — especially screen and keyboard — felt huge as if it would be some 17” or even bigger notebook. ;-) OTOH I still think that a 1920×1200 (which means nearly four xterms in a row) resolution on a 14” notebook would be a good idea, especially compared to the 1440×900 (which means nearly three xterms in a row) my T61 has. ;-) Personal Resumée after one month Pro EeePC

• It’s geeky. If you show up with it, people want to lift it to see how much it weights and try the tiny keyboard. They’re surprised that 800x480 aren’t that small and that the performance isn’t that bad.
• Very compact and robust. With the T61 I always fear that its edges are too close to the the outside of my backpack and could be damaged that way.
• The price of course: CHF 499 at digitec (plus CHF 54 for the 2 GB RAM)
• Runs Linux ex factory. So yu don’t have to expect that many driver hassles.
• RAM upgrades are very straight forward and do not void the warranty. (BTW: The sticker over one of the screws which probably should prove the integrity can be removed and placed again easily… :-)
• The weight. 0.92 kg can be easily held wit one hand, also because of less leverage effect as with full-size laptops.
• The SSD despite it’s size. Being such lightweight you accelerate the EeePC unmindfully even when it runs. But it doesn’t matter, at least not to the hard disk. And it boots very fast, especially after the usage of insserv.
• Intergrated Ethernet network interface. (Hey, the MacBook Air hasn’t a builtin one, not even an external shipped with it! ;-)
• Three USB sockets (the MacBook Air has only one which is usually taken for the Ethernet network adaptor — Ok, with the EeePC usually one is taken for the Bluetooth dongle, but then are still two sockets left… ;-)
• Great contrast on the builtin screen.
• External VGA output. You have to configure X.org to make the virtual screen big enough (e.g. 2048×2048 instead of the default 800×800).
• Despite its size quite a lot of space for modifications inside the case. Especially a bluetooth case mode should be no big deal.

Contra EeePC

• The keyboard: keys smaller than usually (ok, wouldn’t work otherwise ;-), very wobbly, no precise contact depth (pressing Shift and Fn with one finger often doesn’t press Fn right), not all keys on the same plane, unusual offsets between the key rows (the number row has about half a key width offset to the left) or position of keys (I often hit Ins when I want Home, Del when I want Backspace or Fn when I want Ctrl, the ~ key is between Esc and F1, Up is between Slash and Right Shift, etc.)
• The position of the power button: It’s exactly where I want to put thumb when holding the EeePC solely with the right hand. And yes, I already accidentially switch it off several times because of that. For luck the button doesn’t work at all when the lid is closed, because you still can reach it easily while it’s closed.
• The mouse button(s): It only has two buttons which are one part you can press more to the left and more to the right side. And if you press it in the middle you randomly get either a left or a right click. You have to press it very hard to get both clicks at the same time. (e.g. to emulate a third middle button). Three separated mouse buttons would have been way better.
• It has (only) a touchpad. I definitely prefer thumbsticks as the ThinkPads have, but got used to it, though. I have seen worse touchpads, too.
• The noisy and not very precisely beared fan, which seems to strife its environment when the EeePC is being accelerated. Whih happens quite often because of its size and weight and because the SSD doesn’t mind acceleration. The fan does mind – and you hear it. :-(
• Some programs need minimum 800x600 resolution to work well.

Pro ThinkPad (in direct comparision)

• Thumbstick.
• One of the best laptop keyboards around.
• Three easy to distinguish mouse buttons.
• Even ressource-hungry programs like Liferea work fine.
• Quite big screen resolution (1440×900).
• Bigger battery, space for additional batteries.
• Could be a workstation replacement.

Pro Lenny on the EeePC

• The installer image of the Debian EeePC Project works out of the box. All necessary drivers are available, if you include the non-free repositories and the eeepc.debian.net repositories.
• Stable enough for daily use. (IMHO Debian Testing – and even Debian Unstable – is more stable as many other distribution’s stable releases, e.g. those from SuSE.)

Con Lenny on the EeePC

• My favourite feed reader Liferea has changed its cache format since the version in Debian Etch, so I can’t sync Liferea caches between my Debian Etch running T61 and the Testing running EeePC. Well, fortunately the version of Liferea in Debian Etch still works on Debian Lenny, so I just downgraded the package to the version from Etch and set it on hold. I don’t use it on the EeePC though since it needs way too long to start (about 10 to 15 minutes compared to 1 to 3 minutes on the T61)

Summary I’m very happy with the EeePC and I didn’t expect that it would replace my 14” ThinkPad in so many (but still not all) situations. :-)

Playing with a Holux M-241 Here is how to download tracks from the Holux M-241:

gpsbabel -t -r -w -i m241 -f /dev/ttyUSB0 -o gpx -F  date +'%Y-%m-%d-%H%M%S' .gpx

It might work also via bluetooth, but I have not tried yet. Now, until M-241 support will be released in a stable version of gpsbabel, here is how to compile the version from CVS. Get the sources:

cvs -d:pserver:anonymous@gpsbabel.cvs.sourceforge.net:/cvsroot/gpsbabel login
cvs -z3 -d:pserver:anonymous@gpsbabel.cvs.sourceforge.net:/cvsroot/gpsbabel co -P gpsbabel

Untar this to debianise the sources. If it does to compile because of some errors in lmx.c, apply this patch. Then you can install the resulting package and (hopefully) be happy. Note, after downloading the logs, gpsbabel currently turns on logging. Here is a patch to disable that behaviour. Finally, if you want to hack around a little on the unit, you can play with mtkbabel: the source code is simple, and most of the MTK protocol is implemented, so you can easily feed your own commands to the MTK. Documentation about the commands can be found here:

• http://spreadsheets.google.com/ccc?key=pyCLH-0TdNe-5N-5tBokuOA&t=2046668448833862841
• http://www.rc-cam.com/misc/PMTK_commands.pdf
• http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf
• http://www.sparkfun.com/datasheets/GPS/MTK%20Packet_User%20Manual.pdf

The links are taken from a post in the GPSPasSion forum. For a source of ideas of what commands you can send, you can look into the source code of BT747. For example, to set the M-241 to 2Hz fix, you can add this to mtkbabel:

packet_send('PMTK300,500,0,0,0.0,0.0');
$ret = packet_wait('PMTK001,300,3');

And if you want to set the MTK to an insane 5Hz fix rate, to take really fine grained gpx traces with your laptop, you can use this:

packet_send('PMTK300,200,0,0,0.0,0.0');
$ret = packet_wait('PMTK001,300,3');

Recently I’ve been having some problems with hardware dying. Having one item mysteriously fail is something that happens periodically, but having multiple items fail in a small amount of time is a concern. One problem I’ve had is with CD-ROM drives. I keep a pile of known good CD-ROM drives because as they have moving parts they periodically break and I often buy second-hand PCs with broken drives. On each of the last two occasions when I needed a CD-ROM drive I had to try several drives before I found one that worked. It appears that over the course of about a year of sitting on a shelf I have had four CD-ROM drives spontaneously die. I expect drives to die if they are used a lot from mechanical wear, I also expect them to die over time as the system cooling fans suck air through them and dust gets caught. I don’t expect them to stop working when stored in a nice dry room. I wonder whether I would find more dead drives if I tested all my CD and DVD drives or whether my practice of using the oldest drives for machines that I’m going to give away caused me to select the drives that were most likely to die. Today I had a problem with hard drives. I needed to test a Xen configuration for a client so I took two 20G disks from my pile of spare disks (which were only added to the pile after being tested). Normally I wouldn’t use a RAID-1 configuration for a test machine unless I was actually testing the RAID functionality, it was only the possibility that the client might want to borrow the machine that made me do it. But it was fortunate as one of the disks died a couple of hours later (just long enough to load all the data on the machine). Yay! RAID saved me losing my work! Then I made a mistake that I wouldn’t make on a real server (I only got lazy because it was a test machine and I didn’t have much risk). I had decided to instead make it a RAID-1 of 30G disks and to save some inconvenience I transfered the LVM from the degraded RAID on the old drive to a degraded RAID on a new disk. I was using a desktop machine and it wasn’t designed for three hard disks so it was easier to transfer the data in a way that doesn’t need to have more than two disks in the machine at any time. Then the new disk died as soon as I had finished moving the LVM data. I could have probably recovered that from the LVM backup data and even if that hadn’t worked I had only created a few LVs and they were contiguous so I could have worked out where the data was. Instead however I decided to cut my losses and reinstall it all. The ironic thing is that I had planned to make a backup of the data in question (so I would have copies of it on two disks in the RAID-1 and another separate disk), but I had a disk die before I got a chance to make a backup. Having two disks out of the four I selected die today is quite a bad result. I’m sure that some people would suggest simply buying newer parts. But I’m not convinced that a disk manufactured in 2007 would survive being kept on a shelf for a year any better than a disk manufactured in 2001. In fact there is some evidence that the failure rates are highest when a disk is new. Apart from stiction I wouldn’t expect drives to cease working from not being used, I would expect drives to last longer if not used. But my rate of losing disks in running machines is minute. Does anyone know of any research into disks dying while on the shelf?

Share This

For mobile UMTS/GSM, I have been using an Option 3G Data Card for two and a half years now. I blogged about getting the card to work (in German, sorry) on Linux in July 2005. I never found the time - until now - to automate the card initialization so that I had been using a horrible chat script for card initialization when the PPP connection was built. I recently took the time to automate this, so that the PIN is transmitted to the card automatically when the card is plugged in. This article documents what I did. On a side note: Unfortunately, the vendors’ attitude towards Linux hasn’t changed since 2005. Their Hotlines still deny that their products can be used with Linux at all, and they surely do not publish any documentation that can be of help. Otoh, Vodafone has published a software that supposedly aids usage of their products under Linux. I haven’t tried it yet since it is not packaged yet for Debian. Additionally, Vodafone support media and sales do not seem to know about this effort, they still deny that their products work with Linux. Windows users happily install proprietary software products that do little more than sending a handful of AT commands to the emulated USB modem and hand over the connection to Windows’ PPP Stack. A very unsatisfying situation. Just for the record: Dear Vodafone DE, a week ago you missed the sale of a new USB UMTS interface because you don’t even document it on Linux. This motivated me to look into the drawer that holds the old, non-HSDPA PC cards that have been decommissioned at the customers’ site and use an old, used device. Your fault. But now back on topic: For a data center monitoring system, I want to send out alerts as text message (for German speakers: SMS - we have a rather strange vocabulary for mobile communications), and am reluctant to do so via IP: IP is one of the things that can fail, so it is preferred to directly inject the text messages into the network of the operator that provides service to the recipients of the text messages. Fortunately, most of the recipients are in the same network. After evaluating current hardware solutions that could be plugged directly into the “real” server doing the monitoring and running into the wall of non-support provided by the network operators and hardware vendors, I decided on taking things a little further and to build an Ethernet-Connected text message device. An old hp compaq nc8000 (no, not mine, mine still works fine and is in daily use) and an old, first generation Option Datacard 3G will be mounted near the datacenter’s windows and equipped with Debian and Nagios. That way, the text message device can itself monitor the monitoring system and even send out a warning message when the data center goes out of power: It has a built-in UPS. But now back on topic: For the text messages to go out reliably, it is necessary that the UMTS card is initialized automatically when the system comes up. A great opportunity to finally address this issue for Linux, on customers’ expense **grins**. UMTS card initialization is done in two steps: First, when the card is plugged in, the virtual OHCI host port appears. Initialization of the virtual OHCI happens automatically. Most documentation on the web says that you now need to load an appropriately parametrized usbserial module, and I did it this way for years, but that’s not necessary any more. CONFIG_USB_SERIAL_OPTION is a dedicated kernel module for the Option 3G data card, which gets automatically loaded if it is available. If you don’t have the Option module for some reason, you still need the following udev rule to automatically load the generic USB serial module. I figured that out yesterday before I learned about the Option module in a comment made to the original version of this article.

SUBSYSTEM==“usb”, \
   SYSFS idProduct ==“5000”, SYSFS idVendor ==“0af0”, \
   ACTION==“add”, \
   RUN+=“/sbin/modprobe usbserial vendor=0x$attr idVendor  product=0x$attr idProduct ”
SUBSYSTEM==“usb”, \
   SYSFS idProduct ==“5000”, SYSFS idVendor ==“0af0”, \
   ACTION==“remove”, \
   RUN+=“/sbin/modprobe -r usbserial”

Unfortunately, the usbserial and option modules stay around after the card is pulled. This doesn’t hurt though. Next, we see three virtual serial interfaces, which we can detect via udev, and assign “speaking” device names and transmit the PIN. This goes into /etc/udev/rules.d/50-option3g.rules:

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“option”, \
   ATTRS bInterfaceNumber ==“00”, \
   ATTRS modalias ==“usb:v0AF0p5000d0000dc00dsc00dp00icFFiscFFipFF”, \
   SYMLINK=“UMTS-DATA”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“option”, \
   ATTRS bInterfaceNumber ==“02”, \
   ATTRS modalias ==“usb:v0AF0p5000d0000dc00dsc00dp00icFFiscFFipFF”, \
   SYMLINK=“UMTS-CONTROL”, RUN+=“/usr/local/sbin/umts-pin --device %k”

I am not sure what the modalias attribute identifies, but it looks like it identifies the hardware model: An identical Option Datacard 3G, plugged into the other PC Card Slot gets properly initialized as well. These two udev stanzas do two different things: First, they make sure that the new devices are symlinked to /dev/UMTS-DATA and /dev/UMTS-CONTROL, suggesting the intended use of the interface. The second virtual interface of the 3G Data Card does not seem to be useable at all, and you cannot build an actual data connection over the third. So, we baptize the first interface /dev/UMTS-DATA and ignore the second. The third gets called /dev/UMTS-CONTROL. Now to the real magic: /usr/local/sbin/umts-pin is a perl script that sends the PIN to the Card. %k gets expanded to the device name of the device that has just been detected, so umts-pin gets called with “--device ttyUSB2”. It makes use of Cosimo Streppone’s Device::Modem module (Device::Gsm is not yet packaged for Debian and might be of better use here) to talk to the UMTS device. Unfortunately, I have not yet fully understood the logging and answer processing features of Device::Modem, so the implementation might look a little clumsy. I hope that it can be clearly understood anyway. The actual PIN is read from a configuration file in an apache-like format, which is by default looked for in /etc/umts/pin.conf:

<pin>
        <default>
                pin xyzw
        </default>
</pin>

The reason I settled for this rather complex configuration file format is that the ultimate goal is to automatically detect which of my SIMs is currently inserted in the UMTS card and to automatically send the correct PIN. I haven’t been successful in doing so since I didn’t find an AT command yet to get the UMTS card to divulge the SIM serial number or the IMSI before the PIN is transmitted to the SIM. So currently, the only things that are supported are the “default” stanza and an identically formatted “override” stanza which takes precedence over the default stanza if present. If the first attempt to send the PIN fails, the script tries again ten seconds later. On my test system, this happens about once in twenty times. That must be some weird timing issue. So, if you have the wrong PIN configured, you’ll need the PUK after plugging in the card for the second time, since the first try will eat two of your three attempts. Beware. If you feel uncomfortable with all this scripting and the “quality” of my code, you can also use gammu’s entersecuritycode function. I discovered this after my PIN script was already written, and gammu currently forces you to expose the PIN on the command line (see #484102), and of course my script’s PIN handling is vastly superior **grins**. And one end note: More current hardware, most notably the Huawei series of cards, are reported to show themselves as virtual USB storage first to allow identification and installation of Windows drivers, and need an explicit command to show their virtual USB serial side. I have read web pages where people have managed to do this in Linux, but since I use an older card and do not have a current card available (again, Vodafone, your fault!) I cannot comment about this. But there are reports that this can be done, so don’t panic if you have more recent hardware.

So Avi Bryant finally showed off the work he's been doing with the Gemstone folks at Railsconf, and it's made quite a splash. With performance improvements like that it shouldn't be a surprise. The most interesting thing about it to me though is that it's the first time in a very long while that we've seen a proprietary implementation of a major tool absolutely destroy all the Free implementations. We've had things like Intel's C compiler outperforming gcc before, but nothing on this level, especially because the main ruby implementation is so notoriously slow. Just another feather in the cap of Smalltalk's long legacy.

What's troubled me for some time about the post-Rails Ruby community is that it has a distinct bent away from its Free Software roots. I understand Matz actually used to use (not sure about today) Debian Unstable, and Ruby traditionally displayed its roots quite strongly, with a Perl heritage and a community consisting largely of hardcore *NIX people. With the advent of Rails, the move has been towards things like TextMate and OSX. Software like Gems (no relation to Gemstone) fits in fine with one of these systems, but not so well with modern Free Software systems, and I think it's symptomatic of the change. Given this propensity in the Ruby community, and given the numbers Gemstone is posting, I'd be surprised if lots of Rubyists don't move that way as soon as it's available.

Given all this, I really have to wonder if the modern Ruby fits me any more. I generally think it's important for the Free Software community to support itself first and then try to grow out from there, and the Ruby community isn't really on this path right now. That's fine, there's nothing wrong with it, it's just not something that really interests me. It does make me wonder how something like this could happen, and it really comes down to the fact that a lot of smart people who might otherwise be really passionate about Linux systems are choosing OSX instead. Maybe it's hardware support (I hope the modernization of X will help here) and maybe it's just the whole package being nice and easy to use. Whatever it is, people are choosing it and we're the poorer for it.

One of the downsides of writing my thesis last year was that focusing on a technical subject for approximately 16 hours a day left me almost entirely unable to relate to people. The irony in this is that losing the ability to socially relate tends to result in you assuming that you're fine and everyone else is just behaving bizarrely, which makes rectifying the situation rather difficult. In an attempt to avoid this I have written some software, because dealing with the symptoms of a problem is always better than dealing with the root cause and technology is always the appropriate solution to social issues.

The aim was to send myself an email once a week that I'd actually have to read. This is achieved by running the script with the generate argument. This sends an email with an appropriate reminder message (something along the lines of "Are you sucking? Really? Are you sure? Is everyone around you suddenly getting annoyed at you for no obvious reason?", and so on) and a bunch of embedded characters randomly spread throughout it. Running the script with the check argument will send the email again if a valid response hasn't been received. Those can be stuck in cron. The final part is to add a procmail or whatever rule that passes replies back to the script with the validate argument. These replies should include a line containing all the embedded characters (order doesn't matter, but if there are multiple occurances of a character than the reply must include that number of occurances). If a valid reply is received then no further emails will be sent until the script is run with the generate argument again.

Also: My perl sucks.

In the TechCrunch coverage of Google IO, I was impressed by this:

Not every team has the resources Google does to build for every platform. Google is betting on browser over time for mobile devices; it will be the entry point for many applications. But today, the only browsers capable for supporting mobile apps include iPhone and few others. So Google is developing Android, which includes world class Webkit browser.

Here at the world headquarters of DedaSys LLC (which for the time being happens to be "in front of David's computer, wherever that is"), we too have some suspicions about the browser becoming the platform of choice for mobile phones, although there is a big if: When will the carriers make always on, cheap internet connections widespread? Until that happens, client side apps will still probably dominate for many things. And of course for applications requiring hardware access, some kind of local program will be necessary as well for the foreseeable future. (And of course, Hecl is a good choice "for the time being", too!) Coming back to the phrase cited above, what blows me away about it is the sheer amount of time and money that they're investing in something that "over time", they're not really betting on, in the sense that they just want browsers everywhere? Jumping into a market with a new "OS", toolkit, etc... just to spread a platform with a decent browser? Wow. That is a company with a lot of spare change. Most people and companies in business are doing the best they can to stretch out their dollars or euros as best they can. I guess it really takes a behemoth to pour so much in the way of engineering talent and financial resources into something that's in some ways a bump in the road in terms of their long term vision. Or maybe I'm just reading too much into one phrase?