unethical blogger

Over the past year or two I've become quite fond of tiled window managers, the jump to Awesome (which I've since dropped) to XMonad was a logical one. My gratuitous use of GNU/screen and Vim's tabs and split window support, already provided a de-facto tiled window manager within each one of my many terminals. The tiled window manager on top of all those terminals has served to improve my heavily-terminal biased workflow.

One computer has never been enough for me, at the office my work spans three screens and two computers, I've not yet discovered a Thinkpad that can drive three screens alone; at home I typically span three screens and two laptops (let's conveniently ignore the question of why I feel I need so much screen real estate). Tying these setups together I use synergy to provide my "software KVM" switch. As long as I've used synergy, I've had to switch from one screen to the other with a mouse, which is one of the few reasons I still keep one on the desk.

Until I discovered a way around that, thanks to Jean Richard (a.k.a geemoo) who posted this little configuration change to synergy.conf:

section: options
     keystroke(control+alt+l) = switchInDirection(right)
     keystroke(control+alt+h) = switchInDirection(left)
end

With this minor configuration change, combined with XMonad, Vimium (Vim-bindings for Chromium) and my usual bunch of terminal-based applications, I can go nearly mouse-less for almost everything I need to do during the day.

Lately I've fallen in love with a couple of fairly simple but powerful technologies: haproxy and WSGI (web server gateway interface). While the latter is more of a specification (PEP 333) the concepts it puts forth have made my life significantly easier. In combination, the two of them make for a powerful combination for serving web applications of all kinds and colors.

HAProxy is a robust, reliable piece of load balancing software that's very easy to get started with, For the uninitiated, load balancing is a common means of distributing the load of a number of inbound requests across a pool of processes, machines, clusters and so on. Whenever you hit any web site of non-trivial size, your HTTP requests are invariably transparently proxied through a load balancer to a pool of web machines.

I started looking into haproxy when I began to move Urlenco.de away from my franken-setup of Lighttpd/FastCGI/Mono/ASP.NET to a pure Python stack. After poking around some articles about haproxy I discovered it can be used for virtual hosts as well as simple load balancing. Using a haproxy's ACLs feature (see Section 7 in the configuration.txt), you can redirect requests to one backend or another.

After running a Linux laptop for a number of years and having mostly negative travel experiences from messing something up along the way, this holiday season I think I've finally figured out how to optimally travel with a Linux notebook. The following tips are some of the lessons I've had to learn the hard way through trial and error over the course of countless flights spanning a few years.

Purchase a small laptop or netbook

Far and away the best thing I've done for my travel experience thus far has been the purchase of my new Thinkpad X200 (12.1"). My previous laptops include a MacBook Pro (15"), a Thinkpad T43 (14") and a Thinkpad T64 (14"). Invariably I have the same problems with all larger laptops, their size is unwieldy in economy class and their power consumption usually allows me very little time to get anything done while up in the air. Being 6'4" and consistently cheap, I'm always in coach, quite often on redeye flights where the passenger in front of me invariably leans their seat back drastically reducing my ability to open a larger laptop and see the screen. With a 12" laptop or a netbook (I've traveled with an Eee PC in the past as well) I'm able to open the screen enough to see it clearly and actually type comfortbaly on it. Additionally, the smaller screen and size of the laptop means less power consumption, allowing me to use it for extended periods of time.

A coworker of mine, @teepark and I recently fell in love with tiling window managers, Awesome in particular. The project has been interesting to follow, to say the least. When I first installed Awesome, from the openSUSE package directory, I had version 2, it was fairly basic, relatively easy to configure and enough to hook me on the idea of a tiling window manager. After conferring with @teepark, I discovered that he had version 3 which was much better, had some new fancy features, and an incremented version number, therefore I required it.

In general, I'm a fairly competent open-source contributor and user. Autoconf and Automake, while I despise them, aren't mean and scary to me and I'm able to work with them to fit my needs. I run Linux on two laptops, and a few workstations, not to mention the myriad of servers I'm either directly or peripherally responsible for. I grok open sources. Thusly, I was not put off by the idea of grabbing the latest "stable" tarball of Awesome to build and install it. That began my slow and painful journey to get this software built, and installed.

• Oh, it needs Lua, I'll install that from the repositories.
• Hm, what's this xcb I need, and isn't in the repositories. I guess I'll have to build that myself, oh but wait, there's different subsets of xcb?

For one of the projects I've been working on lately, I've been making use of Glib's Testing functionality to write unit tests for a C-based project. I'm a fairly big fan of the Hudson Continuous Integration Server and I wanted to run tests for my C-based project.

Unfortunately, the gtester application generates XML in a custom format that Hudson cannot understand (i.e. JUnit formatted XML). In order to come up with some JUnit XML, I spent about an hour and a half toying with XSLT for transforming the XML gtester generates (see the snippet below).

I added a shell script build step to the end of the build process that runs:

gtester test_app --keep-going -o=Tests.xml
xsltproc -o tests.junit.xml gtester.xsl Tests.xml

Then I just specified "tests.junit.xml" in the Publish JUnit test result report section of the Post-build Actions and then Hudson would properly process and post the test results when the job was finished.

A coworker of mine was kind enough to let me borrow his Nokia n810 for a couple days to try it out as he know I was considering purchasing one for myself. I'm very glad I tried it before buying it, since I'm not going to buy it now (sorry Nokia! The princess is in another castle!)

The thought of a handheld, wireless capable, Linux device is very intriguing for me. That said, I'm not sure what I would even do with it! As I mentioned in my previous post, I like to feel cool, and the prospect of answering the question "is that Linux in your pocket or are you just happy to see me" is far to enticing to pass up. Regardless, I think the n810 suffers from some critical hardware, and software, deficiencies.

Hardware
The n810 is powered by a 400Mhz ARM processor, and comes equipped with either 128MB or 256MB or RAM (from what I can tell), I'm not entirely certain which is to blame for the sluggishness of the experience, but my guess is on the RAM. Particularly when running the browser (Gecko-based) I would experience "hiccups" where the device spent a few seconds registering input, before actually following a clicked link. This may be more at fault of the software, but for an internet tablet, the sluggishness of the browser in both user interaction and rendering time was absolutely infuritating.

The built-in keyboard is smooth, a little too smooth for my taste; I found myself constantly struggling to hit the right keys with my fingers (my thumb is the width of 2.5 columns of keys). Unlike most US keyboard layouts, the n810 keyboard has a lot of keys in "weird" places that I could not get a hang of over the course of a weekend. I eventually gave up on trying to chat or use SSH on the device because I found it so painful to try to type on the device.