unethical blogger - Linux

Catch me at SCALE!

R. Tyler Croy — Mon, 24 Jan 2011 19:00:00 +0000

This is a cross-post from another silly blog I run calledOMG! SUSE!

Let's all pretend I have a Geeko-related pun for "SCALE." Anyhoo, SCALE, otherwise known as the Southern California Linux Expo, is coming up in February (25th - 27th) and yours truly will be present and accounted for.

Yes, those are bus tickets you see there. I will be heading down from Oakland to Los Angeles by bus instead of flying for ideological reasons, so I'll try to be in a good mood when I arrive!

At this year's SCALE, the openSUSE project is making a big splash. Contributors and ambassadors will be showing up from all over the globe to show off openSUSE, talk nerdy, socialize and eat tasty snacks supplied by Cruise Director, GNOME Accessibility contributor and openSUSE Board Member Bryen Yunashko, who just got his annual haircut in preparation for the momentous occasion! ;) If you're in the area, check out this amazing speakers listing and be sure to register as soon as possible!

I'll be covering the specifics of SCALE more in the coming weeks on OMG! SUSE!, so stay tuned and I hope to see you there!

GNU/Parallel changed my life

R. Tyler Croy — Thu, 11 Nov 2010 17:48:32 +0000

Over the past month or so I've fallen in love with an incredibly simple command line tool: GNU/Parallel. Parallel has more or less replaced my use of xargs when piping data around on the many machines that I use. Unlike xargs however, Parallel lets me make use of the many cores that I have access to, either on my laptop or the many quad and octocore machines we have lying around the Apture office.

Using Parallel is incredibly easy, in fact the docs enumerate just about every possible incantation of Parallel you might want to use, but starting simple you can just pipe stuff to it:

cat listofthings.txt | parallel --max-procs=8 --group 'echo "Thing: {}"'

The command above will run at most eight concurrent processes and group the output of each of the processes when the entire thing completes, simple and in this case not too much different than running with xargs

With some simple Python scripting, Parallel becomes infinitely more useful:

python generatelist.py | parallel --max-procs=8 --group 'wget "{}" -O - | python processpage.py'

There's not really a whole lot say about GNU/Parallel other than you should use it. I find myself increasingly impatient when a single process takes longer than a couple minutes to complete, so I've been using GNU/Parallel in more and more different ways across almost all the machines that I work on to make things faster and faster. So much so that I've started to pine for a quad-core notebook instead of this weak dual core Thinkpad of mine :)

GNU/Parallel Demo

Keyboard Synergy

R. Tyler Croy — Mon, 14 Jun 2010 16:45:00 +0000

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.

Virtual Hosting with HAProxy and WSGI

R. Tyler Croy — Sun, 17 Jan 2010 00:29:38 +0000

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. While my "virtual hosting" with haproxy is using the ability to inspect the HTTP headers of inbound requests, you can use a number of different criterion to determine the right backend for serving a request: url matching, request method matching (GET/POST), protocol matching (haproxy can load balance any kind of TCP connection) and so on.

WSGI (pronounced: whiskey) comes into play on the backend side of haproxy, using the eventlet.wsgi module which provides a WSGI interface I can build web applications very quickly, test them and deploy them. When deployed, I can run them as "nobody" in userspace on the server, binding to some higher numbered port (i.e. 8080) and haproxy will do the work routing to the appropriate WSGI process.

Below is a simple haproxy configuration that I'm using to run Urlenco.de and a site for my wedding and many more as soon as I finish them. The section to note is frontend http-in in which the ACLs are defined for the different virtually hosted domains and the conditionals for selecting a backend based on those ACLs.

global
    maxconn         20000
    ulimit-n        16384
    log             127.0.0.1 local0
    uid             200
    gid             200
    chroot          /var/empty
    nbproc          4
    daemon

defaults
    log global
    mode http
    option httplog
    option dontlognull
    retries 3
    option redispatch
    maxconn 2000
    contimeout 5000
    clitimeout 50000
    srvtimeout 50000

frontend http-in
    bind *:80
    acl is_urlencode hdr_end(host) -i urlenco.de
    acl is_wedding hdr_end(host) -i erinandtylerswedding.com

    use_backend urlencode if is_urlencode
    use_backend wedding if is_wedding
    default_backend urlencode

backend urlencode
    balance roundrobin
    cookie SERVERID insert nocache indirect
    option httpchk HEAD /check.txt HTTP/1.0
    option httpclose
    option forwardfor
    server Local 127.0.0.1:8181 cookie Local

backend wedding
    balance roundrobin
    cookie SERVERID insert nocache indirect
    option httpchk HEAD /check.txt HTTP/1.0
    option httpclose
    option forwardfor
    server Local 127.0.0.1:8081 cookie Local

5 tips for traveling with Tux

R. Tyler Croy — Sun, 27 Dec 2009 11:19:41 +0000

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.

Use a basic window manager

Personally, I prefer XMonad, but I believe any simplistic window manager will save a noticable number of cycles compared to the Gnome and KDE "desktop environments." Unlike Gnome, for example, XMonad does not run a number of background daemons to help provide a "nice" experience in the way of applets, widgets, panels and menus.

Disable unneeded services and hardware

Reducing power consumption is a pretty important goal for me while traveling with a Linux laptop, I love it when I have sufficient juice to keep myself entertained for an entire cross-country flight. Two of the first things I disable before boarding a plane are Wireless and Bluetooth via the NetworkManager applet that I run. If I'm on a redeye, I'll also set my display as dark as possible which not only saves power but also eye strain. It's also important to make sure your laptop is running its CPU in "power-save" mode, which means the clockspeed of the chip is reduced, allowing you to save even more power. Finally I typically take a look at htop(1) to see if there are any unneeded processes taking up cycles/memory that I either don't need or don't intend to use for the flight. The flight I'm currently on (Miami to San Francisco) I discovered that Chrome was churning some unnecessary cycles and killed it (no web browsing on American Airlines).

Use an external device for music/video

If you're like me, you travel with a good pair of headphones and a desire to not listen to babies crying on the plane. I find a dedicated device purely for music can help avoid wasting power on music since most devices can play for 12-40 hours depending on the device. It's generally better (in my opinion) to use your $100 iPod for music and your $2000 computer for computing, that might just be personal bias though.

Load applications you'll need ahead of time

I generally have an idea of what I want to do before I board a plane, I have a project that I'd like to spend some time hacking on or something I want to write out or experiment with. Having a "game plan" before I get onto the plane means I can load up any and all applications while plugged in at the airport. This might be a minor power saver but after I've lowered the CPU clockspeed and disabled some services, I certainly don't want to wait around for applications to load up while I sit idly in coach.

Update: As Etni3s from reddit points out, powertop(1) is a pretty handy utility for watching power consumption.

As I write this article, I'm probably an hour into my five and half hour flight and the battery monitor for my X200 is telling me I have an estimated eight hours of juice left.

I'm proud to say, Tux is my copilot.

Awesomely Bad

R. Tyler Croy — Sun, 26 Jul 2009 03:52:18 +0000

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? xcb-util, xcb-proto, libxcb-xlib, xcb-kitchensink, etc.
Well, I need xproto as well, which isn't in the repositories either.
CMake? Really guys? Fine.
ImLib2, I've never even heard of that!
libstartup-notification huh? Fine, i'll build this too.

After compiling what felt like an eternity of subpackages, I discovered a number of interesting things about the varying versions of Awesome v3. The configuration file format has changed a few times, even between one release candidate to another. I ran across issues that other people had that effectively require recompilling X11's libraries to link against the newly built xcb libraries in order to work (/usr/lib/libxcb-xlib.so.0: undefined reference to _xcb_unlock_io). Nothing I seemed to try worked as I might expect, if I couldn't recompile the majority of my system to be "bleeding edge" I was screwed. The entire affair was absolutely infuriating.

There were a few major things that I think the team behind Awesome failed miserably at accomplishing, that every open source developer should consider when releasing software:

If you depend on a hodge-podge of libraries, don't make your dependency on the bleeding edge of each package
Maintain an open dialogue with those that package your software, don't try to make their job hell.
When a user cannot build your packages with the latest stable versions of their distribution without almost rebuilding their entire system, perhaps you're "doin' it wrong"
Changing file formats, or anything major between two release candidates is idiocy.
If you don't actually care about your users, be sure to state it clearly, so then we don't bother using or trying to improve your poor quality software

In the end, I decided that Haskell isn't scary enough not to install XMonad, so I've started replacing machines that run Awesome, with XMonad, and I'm not looking back. Ever.

Using Glib's gtester Results in Hudson

R. Tyler Croy — Thu, 18 Jun 2009 08:02:02 +0000

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.

Extremely brief review of the Nokia n810

R. Tyler Croy — Mon, 05 Jan 2009 09:22:14 +0000

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.

The battery life was nothing to write home about, closer to a laptop battery life, instead of a phone's battery life.

The Software
Despite being Linux-based, the device doesn't feel like Linux at all, which I think is a good thing for the mass-market. The "Home" screen was pretty slick, with the ability to add applets to the "desktop" to report things like weather, time, VPN status, etc. A cross-between systray and Dashboard, the Home screen was where I felt most comfortable in the device (the "home" screen in my Smartphone is set up with similar informational panels). Once leaving "Home" I was soon frustrated again, I still haven't figured out whether or not the "Accounts" preference in the Control Panel (for IM accounts) and the installation of Pidgin are the same thing or not. Email and IM, the two other foundations of what I would expect from an "internet tablet" were weak. Neither of them cooperated with any of the IMAP/SSL or Jabber/SSL servers I use, and they both seemed to be targeted at webmail and chat services like GMail and GTalk.

Maemo does use .deb packages for installation, so I could pretty easily find some of my favorite open source applications in the Maemo repositories, unfortunately the GUI frontend for apt-get on Maemo allows for only one operation at a time (no checking multiple boxes and then clicking "Install") so adding new software was literally a 30 minute operation.

Conclusion
I don't think I'm being too negative in saying that I'm disappointed in Nokia for releasing what I think is such a substandard product. With the ubiquity of wireless in San Francisco, having a nice solid ultra-portable machine that I can actually fit into my pocket is exciting, The Nokia n810 is certainly not that machine.

This week I'm shipping my ASUS Eee PC off for my little sister, so I'm starting to look more and more for something even more portable to fill the void, right now the leader is the OQO model 02 which is about 2 times the price of the n810, and ships with Vista by default, but with Ubuntu and close to 6 hours of battery life I think it could be the ultra-portable that I've been looking for.

I'm using Git because it makes me feel cool

R. Tyler Croy — Sun, 04 Jan 2009 14:42:02 +0000

Let's be honest for a second, anybody who knows me knows that I'm clearly an insecure person; I spend the majority of my time trying my best to appear cool. I've owned a lot of Macs in my life, not because they're solid machines with a fantastic operating system, but because I felt so damn smug and cool whenever I was doing anything on my Macs. I also developed Mac software for a while, not because it was my passion or Objective-C and Cocoa are practically God's gift to software, but because Mac developers are so cool, what with the black-rimmed glasses and fancy coffees. Hell, I remember when I finally traded my MacBook Pro for a Thinkpad running Linux; it had nothing to do with an ideological stance against Apple's treatment of developers or frustrations with Leopard, it was all about the new geek-chic that was Linux. Thus far, my life has basically been one big quest for more leet-points.

Then came Git.

When I started out in the software world, I was using CVS, which was a notch less cool than a slim IBM salesman's tie. The constant moaning and groaning of fellow developers using CVS, combined with the shame that I felt when I finally told my parents about my use of CVS was too much to bear. I had to switch.

I remember the first time I tried Subversion, I remember talking to Dave and saying "Meh, I'll stick with CVS!" Soon enough, just like the Macarena, Subversion swept the nation up. Subversion was the newest, coolest thing ever, developers rushed into the streets exclaiming "it sucks less than CVS! It sucks less than CVS!" I switched over to Subversion and all of a sudden I was cool again. One by one, open source projects I knew about switched over to Subversion, then Source Forge switched over to Subversion and in an instant, Subversion replaced CVS and became the mainstream version control system. Subversion had grown up, gotten married, a 401k and health insurance, how uncool.

After joining Slide, which used Subversion, I found myself burning up inside. Here I was at this hip start-up, really feeling cool, but still using the same version control system that uncool companies like, Yahoo! and Sun use. I would not stand for this. As 2007 became 2008 the writing was on the wall, Git was our new bicycle. It had been blessed by Saint Torvalds and clearly we needed to get in on the ground floor of the new cool before it became mainstream.

We needed to switch to Git immediately. Who cares if Git is extremely fast, it's not like time is money or something ridiculous like that. What do I care if Git handles branches and merge histories unlike CVS or Subversion? With its immense coolness-factor, I didn't even consider that Git will allow us to work in a decentralized workflow or a centralized workflow, nope, didn't even cross my mind. If one were to make a list of Pros and Cons of Git versus whichever other version control system, you could just put "Pro: Cool" at the top of the list, underlined, in bold, and the rest would be moot as far as I'm concerned.

Unlike Subversion or Perforce, Git doesn't have corporate backing, Git is distributed, like a guerilla-force sweeping through the jungle ready to pownce on an unsuspecting platoon; that's freakin' cool. Git rides a motorcycle, wears a leather jacket, makes women swoon and kicks ass and/or jukeboxes.

Git is the Fonz. Cool.

Don't make any false assumptions about my feelings towards Git, it's not like it's a clearly superior version control system or anything, I'm using it only because I want to be cool too.

Hudson notifications with libnotify

R. Tyler Croy — Fri, 19 Sep 2008 06:40:20 +0000

I've been using a Gnome-based desktop for about the past 8-9 months and one of the things I've come to really appreciate is that most Gnome applications integrate with "libnotify". Libnotify is a simple Windows taskbar-like notification system that presents status messages at the bottom of your screen. Like all great pieces of software, it has a solid Python interface which allows for incorporating it in those little 10-minutes scripts I find myself writing every now and again.

One of the things I wanted to script was the notification of the build status of the numerous jobs that we're running in our Hudson instance here at Slide. Using the Universal Feed Parser and pynotify (listed under "notify-python"), I had a good little Gnome Hudson Notifier running in less than 10 minutes.

Source code after the jump.

import feedparser
import pynotify
import time
 
BASE_TITLE = 'Hudson Update!'
 
def success(job):
        n = pynotify.Notification(BASE_TITLE, 
                                        '"%s" successfully built :)' % job,
                                        'file:///usr/share/pixmaps/gnome-suse.png')
        n.set_urgency(pynotify.URGENCY_LOW)
        return n
 
def unstable(job):
        return pynotify.Notification(BASE_TITLE, 
                                        '"%s" is unstable :-/' % job,
                                        'file:///usr/share/pixmaps/gnome-suse.png')
 
def failure(job):
        n = pynotify.Notification(BASE_TITLE, 
                                        '"%s" failed!' % job,
                                        'file:///usr/share/pixmaps/gnome-suse.png')
        n.set_urgency(pynotify.URGENCY_CRITICAL)
        return n
 
def main():
        pynotify.init('Hudson Notify')
        old_items = []
        while True:
                feed = feedparser.parse('http://hudson/rssLatest')
                items = [t['title'] for t in feed['entries']]
                new_items = list(set(old_items).difference(items))
 
                for i in new_items:
                        i = i.split(' ')
                        job, build, status = (i[0], i[1], i[2])
                        status = status.replace('(', '').replace(')','')
                        if status == 'SUCCESS':
                                success(job).show()
                        elif status == 'UNSTABLE':
                                unstable(job).show()
                        elif status == 'FAILURE':
                                failure(job).show()
 
                old_items = items
                time.sleep(60)
 
if __name__ == '__main__':
        main()

It's pretty basic right now, but does everything I really wanted it to do. I may add it into a public Git repository in the near future if I spend any more time on the project. Hope you like it :)

Dashboard for Linux users

R. Tyler Croy — Wed, 26 Mar 2008 07:55:35 +0000

With the release of Mac OS 10.5 (Leopard) I found myself in a tough spot, I liked certain features added into Leopard, but I couldn't stand some of the stability issues I was having and the other bugs that would interrupt my normal workflow during the day. In an effort to alleviate some of my frustrations with Leopard, I experimented for a week with running Gnome (with Compiz) on my openSUSE workstation. In general all the important bits were there, By this point, I had already switched from using any sort of GUI editor to work, but instead had switched over to using vim on a shared development server here at the office. Given that Drosera still wasn't fast enough for my normal day-to-day web development debugging, I was also using Firefox and Opera for most of my web browsing as well. Chat was covered by Adium, so using it's Linux/Windows counter-part, Pidgin was no trouble at all.

After switching for a week and falling in love with Compiz and some of the features it offers, I feel like I can accomplish far more now on Linux than I was on Mac OS X. For me Mac OS X became the new Windows, I was fighting the system to work almost as much as I was do actual work (between the IMAP code in Mail.app crashing and Safari leaking, I was not a happy camper). The one missing feature however was Dashboard. I'm not a religious user of Dashboard, but I always used it to keep little chunks of information stored away either in post-it notes, via clocks, or tickers, etc. I'd not found a good solution until recently, by way of Opera and a combination of widgets and one of the default Compiz Fusion plugins.

(click to enlarge)

The concept behind Opera Widgets is the exact same as behind Dashboard widgets, tiny little web applications running on your desktop, by default however they run on your desktop. This wasn't going to work for me, I like to stash widgets away, and access them through the trusty F12 button as per usual with Dashboard.

In enters the "Widget Layer" plugin for Compiz Fusion , which allows you to assign rules for placing regular windows sitting in the window manager, into this special widget layer that appears just like Dashboard does on Mac OS X (with the actual desktop faded out in the background). In order to group all Opera Widgets in the Widget Layer, you can set the "Widget Windows" field to:

role=opera-widget
Which will cause all enabled Opera Widgets to be availabe at a keypress of F12, if you're on Linux, I highly suggest you try it out, it's extremely useful, especially if you grab some of the more developer focused widgets from the widget directory

Of course, there's plenty of reasons to use Compiz. One of my favorite plugins is the "Annotate" plugin that allows you to draw on your screen, which comes in handy for going over interfaces with coworkers.

In general the addition of Compiz to the Linux desktop I feel is an important one, it drastically improves the rendering of windows since it's essentially doing what Quartz Extreme is doing on Mac OS X in terms of offloading some rendering on the graphics card's GPU. Having really bitching eye-candy certainly doesn't hurt either, So far with Compiz I have what equates to "Spaces", "Expose", and "Dashboard" from Leopard, along with a myriad of other goodies like "Wobbly Windows", true transparency and reflections on arbitrary UI elements and of course, a fish tank inside my desktop. (If you're using openSUSE, the one-click packages for Compiz Fusion can be found here on the wiki).

Video: Hello Moko

R. Tyler Croy — Sun, 12 Aug 2007 12:55:00 +0000

I thought I'd dork around a little bit with recording videos featuring the Neo1973, running OpenMoko. This video is running an older version of OpenMoko (2007.1) so it isn't current. It's also worth noting, to use the phone, you don't have to do a full shutdown and bootup, you should really only ever need to do either if you're a developer, or when you first receive the phone.
Hello Moko.

OpenMoko 2007.2 Preview

R. Tyler Croy — Sun, 12 Aug 2007 06:58:53 +0000

I bit the bullet last thursday and started playing with some of the 2007.2 OpenMoko snapshot images, 2007.2 denoting the next iteration of the software. Whereas my previous photos were from 2007.1, the interface was a bit weak, and wasn't much to be proud of. The direction that the interface is now heading in is not only sleek, but much more usable. One of the most important changes, in my opinion, is the addition of acceleration-incluenced scrolling throughout the interface. The new scrolling allows you to do a quick swipe with your finger and have the interface scroll quickly and then slow to a stop, as if your scroll had momentum behind it.

OpenMoko Boot screen

2007.1	2007.2

OpenMoko Desktop

2007.1	2007.2

OpenMoko Applications

2007.1	2007.2

OpenMoko Dialer

2007.1	2007.2

Overall things are progressing quite nicely, but as a developer I feel that I'm teetering between bricking my OpenMoko phone, and making beautiful music with it, either way, I'm along for the ride. The last picture I'll leave you with is one from when my friend whurley and I met up this past week since he was in town representing BMC at Linux World. whurley was one of the organizers of the first iPhoneDevCamp and is a proud owner of an iPhone, regardless, he thought the OpenMoko phone was pretty cool :)

You can find all my OpenMoko photos on Flickr

Meet OpenMoko

R. Tyler Croy — Thu, 09 Aug 2007 04:24:27 +0000

I'm not going to try to explain too much here, but I received my Neo 1973, the OpenMoko-based Smart phone today. While it's a developer preview, it's incredibly exciting. So far I've been able to use my Cingular SIM card, if you use AT&T/Cingular, you can check if yours is supported on the wiki. I can run the general built in suite of applications without too much trouble, I also made a phone call, which worked! Unfortunately however the latest build that I have on my Neo doesn't have sound properly working, which sagacis from the #openmoko channel on Freenode is helping me with currently. I'm a bit over-excited so I'll let the images do the rest of the talking for me.

Meet OpenMoko

Some Assembly Required

Welcome to OpenMoko

Yes, It Does

Browsing around OpenMoko

Dialing with OpenMoko

Sizing up OpenMoko

Running applications "on" your desktop

In general, it's a bit slow, but the developer preview is probably about half as powerful as the planned public-released version. so I'm not exceedingly worried about that. This phone is just all around cool, and will hopefully be a fun device to carry around with me. You can check up on the OpenMoko community by adding Planet OpenMoko to the feed reader of your choice. This is just the beginning.

Hacking with IronPython

R. Tyler Croy — Mon, 30 Jul 2007 13:24:08 +0000

I've been wanting to play with IronPython for a very long time, but never really got around to it since most of my days are either consumed with Python or Mono to some capacity, but never both.

Despite my initial instinct to flee in terror after looking over some of the IronPython examples I found on various blogs, I decided it would at the very least be worth an install just to check out the interpreter, and to see how well it performs on top of Mono.

ccnet% ipy
IronPython 1.0.2467 on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>>

Scary! But familiar, so I forged ahead undaunted, wanting to start hashing some strings, I figured I'd import the md5 module and get to work.

ccnet% ipy
IronPython 1.0.2467 on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import md5
Traceback (most recent call last):
  File md5, line unknown, in Initialize
  File hashlib, line unknown, in Initialize
  File hashlib, line unknown, in __get_builtin_constructor
ImportError: No module named _md5
>>>

Alright, so there are still some holes in the IronPython bridge into Python, but this is fine by me, I can call into .NET code! One other thing that seemed to be missing was the 'select' built-in module, which in turn made my little 'telnetlib' based project fall on it's head.

I run an icecast2 server on my workstation, so I can just tune in with my MacBook Pro, and get whatever stream is being served up by the server. The source for the icecast2 server is a script using Liquidsoap which allows for shuffling, bumps, and a couple of other things to make my music-listening experience better. One of the nice things about Liquidsoap is that it has a telnet interface, so I can glean meta-data about what's playing, or control the playlist through the telnet interface. With this telnet interface in tow, I set out to hack up a Windows Forms and IronPython-based controller for already scripted radio station. And thus, my little IronRadio Controller was born:

Unfortunately, I couldn't use Python's native "telnetlib" so I rolled my own IronTelnet class that would permit basic reads and writes to the telnet server, but other than that, the IronRadio Controller is mostly WIndows Forms code and some events cobbled together. The interface is unfortunately poor, as I don't have an Interface Builder for WIndows Forms, let alone IronPython-based Forms (not to mention I could care less about spit-and-polish for anything in X11.app).

The source for the script can be found here, and will require IronPython and Mono to run (or .NET if you're on a Windows machine).

I'm still trying to figure out if I can use IronPython with mod_mono to replace fighting with mod_python, but there are no guarantees as to whether that will work or be worth the trouble.

Starting with OpenMoko.

R. Tyler Croy — Sat, 21 Jul 2007 09:45:39 +0000

I've already ordered my OpenMoko-based phone already and anxiously await its arrival to the U.S. from FIC. The first order of business will of course to see if I can use it as a real phone, which I'm not holding out for since it's very obviously both beta hardware and software. More importantly however, I'm very excited at the idea of getting Mono running on the mobile, Linux/arm-based device.

In the meantime, I've been playing around with the OpenMoko platform inside of the QEMU-arm emulator. Enjoy :)

Meet OpenMoko

Booting Linux

The OpenMoko Interface

Running a Terminal

OpenMoko Mail

Ordering Take-out

All in all the interface definitely needs some work, but as my iPhone toting coworker David Young said "how cute!"

The platform in general has a lot of potential in my opinion, it's still up for grabs whether FIC will completely miscarry on producing decent hardware to run the phone, but you never know. The biggest key will be whether open source developers, notable for producing some of the most horrid user-interfaces since Windows 95, can cope with the new design paradigm that a smaller touch screen interface creates. I'm going to be doing my part, and for that much I'm very excited.

Is that a penguin in your pocket or are you just happy to see me?