Faster, better, cheaper: what is the true value of a computer?

One thing I've had a lot of time to think about over the last 15 years is what exactly does faster & more powerful mean? After a decade of clockspeed wars, we've moved on to more cores, more RAM, longer battery life, less weight, backlit keyboards, etc. A new computer still costs about the same as it did 15 years ago... is it any better?

The more time I spend with the machines, the more I think about usability. A machine is only as powerful as the tasks it can accomplish. I have a $200 netbook (w/linux, of course) that excels at being light. It works great for travel but not netflix. I could not write a paper on it, but I can check email, upload photos/files, etc.

In our computer cluster here, we upgrade as we hit limits. Ran out of RAM? Buy more... it's cheap (for a desktop, at least). Chronic, awful wrist pain? Get an ergonomic keyboard. I find a 2-screen setup a very cost-effective productivity boost, whereas the idea of paying 20% more for a 10% bump in speed strikes me as silly.

The whole state of affairs reminds me a little of mean and variance. We always hear about the expected values of things, the mean, but rarely is variance ever reported, and variance is often the most important part. Things like weather, lifespan, salary, time-to-completion? The variance may be more important than the mean. Speed/power tells something about the "maximum potential" of a machine, but not how much use one might get out of it.

I see two different directions --

First, unexpected developments. Examples include multiple cores and SSD. No one really expected these to change the aesthetics of computers. Nonetheless, the reduced latency of SSD is pleasantly surprising, as is the increased responsiveness under load of a multi-core machine. I don't hit enter and wait. My machine flows more at the speed of thought than it used to, even if I have a browser with 50+ tabs open, music playing, etc.

Second, human interface. My new phone is just a little too tall, which makes it just a little more difficult to use, since I can't reach across the screen with one hand. Again, I never expected this to matter, but it's a human-machine interface question rather than a pure machine capabilities question. Backlit keyboards, ergonomic keyboards, featherweight laptops, and long battery lives are all about the human-machine interface. Which is more important than speed, since the human is the whole point....

The aesthetics of interface is how Apple came to rule the world. Their hardware is beautiful, intuitively responsive to human touch. Hell, even their stores are clean & informative and intuitive and full of fun toys. Personally, I can't stand their walled-garden approach to hardware, and I have the time and energy to coax my machines into greatness through a commandline interface (which remains one of the most powerful human-machine interface ever developed), but I *like* Apple hardware. They've dragged the PC industry kicking and screaming into the 21st century of "Humans matter more than machines".

Which they rather presciently highlighted in their 1984 Superbowl commercial:
http://www.youtube.com/watch?v=2zfqw8nhUwA

Finally, a mind-blowing historical view on the subject, including a 1983 Bill Gates pimping Apple hardware, and Steve Jobs describing how machines should help people rather than the other way around:
http://www.youtube.com/watch?v=xItV5U-V2W4

Everyday revision control

This post has been a long time coming. Over the past year or so, I've gradually become familiar, even comfortable, with git. I've mainly used it for my own work, rather than as a collaborative tool. Most of the folks that I work with don't need to share code on a day-to-day basis, and there's a learning curve that few of my current colleagues seem interested in climbing at this point. This hasn't stopped me from *talking* to my colleagues about git as an important tool in reproducible research (henceforth referred to as RR).

I find the process of committing files and writing commit messages at the end of the day forces me to tidy up. It also allows me to more easily put a project on hold for weeks or months and to then return to it with a clear understanding of what I'd been working on, and what work remained. In short, I use my git commit messages very much like a lab notebook (a countervailing view on git and reproducible research is here, an interesting discussion of GNU make and RR here, and a nice post on RR from knitr author Yihui Xie here ).


Sidenote: I've hosted several projects at https://code.google.com/, and used their git archives, particularly for classes (I prefer the interface to github, though the two platforms are similar). I've also increasingly used Dropbox for collaborations, and I've struggled to integrate Dropbox and Git. Placing the same file under the control of two very different synchronization tools strikes me as a Bad Idea (TM), and Dropbox's handling of symlinks isn't very sophisticated. On the other hand, maintaining 2 different file-trees for one project is frustrating. I haven't found a good solution for this yet...

As far as tools go, most of the time I simply edit files with vim and commit from the commandline. In this sense, git has barely changed my work flow, other than demanding a bit of much-needed attention to organization on my part. Lately, I've started using GUI tools to easily visualize repositories, e.g. to simultaneously see a commit's date, message, files, and diff. Both gitk and giggle have similar functionality -- giggle is prettier, gitk is cleaner. Another interesting development is that Rstudio now includes git tools (as well as native latex and knitr support in the native Rstudio editor). This means that a default Rstudio install has all the tools necessary for a collaborator to quickly and easily check out an repository and start playing with it.

Adventures with Android

After months of dealing with an increasingly sluggish and downright buggy Verizon HTC Rhyme, I finally took the leap and got a used Galaxy Nexus. First off, I think it's beautiful. The rhyme isn't exactly a high-end phone, so the small, unexciting screen isn't particularly surprising. By comparison, the circa 2011 Nexus is a work of art. My first impression of the AMOLED screen is great. Dark blacks and luscious color saturation (though I have found it to be annoyingly shiny -- screens shouldn't be mirrors!). It even has a barometer!

One big motivation for a phone upgrade (asides from the cracked screen and aforementioned lag) was being stuck at Android 2.3.4 (Gingerbread). As a technologist, I don't consider myself an early-adopted. I prefer to let others sort out the confusion of initial releases, and pick out the gems that emerge. But Gingerbread is well over 2 years old, and a lot has happened since then. The Galaxy Nexus (I have the Verizon CDMA model, codename Toro) is a skin-free, pure Android device. Which means that I am now in control of my phone's Android destiny!

How to go about this? I hit the web and cobbled together a cursory understanding of the Android/google-phone developer ecosystem as it currently stands. First off, there's xda-developers, a very active community of devs and users. There's an organizational page for information on the Galaxy Nexus here that helped me get oriented. This post made installing adb and fastboot a snap on ubuntu 12.04 (precise). There's also some udev magic from google under the "Configuring USB Access" section here that I followed, perhaps blindly (though http://source.android.com is a good primary reference...).

Next, I downloaded ClockworkMod for my device, rebooted my phone into the bootloader, and installed and booted into ClockworkMod:

## these commands are from computer connected to phone (via usb cable)
## check that phone is connected.  this should return "device"
adb get-state
## reboot the phone into the bootloader
adb reboot-bootloader

## in recovery, the phone should have funny pictures of the adroid bot opened up... reminds me of Bender.
## the actual file (the last argument) will vary by device
fastboot flash recovery recovery-clockwork-touch-6.0.3.5-toro.img
## boot into ClockworkMod 
fastboot boot recovery-clockwork-touch-6.0.3.5-toro.img

This brought me to the touchscreen interface of ClockworkMod. First, I did a factory reset/clear cache as per others' instructions. Then I flashed the files listed here (with the exception of root) via sideloading. There's an option in ClockworkMod that says something like "install from sideload". Selecting this gives instructions -- basically, use adb to send the files, and then ClockworkMod takes care of the rest:

## do this on computer after selecting "install from sideload" on phone
## the ROM, "pure_toro-v3-eng-4.3_r1.zip", varies by device
adb sideload pure_toro-v3-eng-4.3_r1.zip
## repeat for all files that need to be flashed

I rebooted into a shiny new install of Jelly Bean (4.3). It's so much cleaner and more pleasant than my old phone. I was also pleasantly surprised to see that Android Backup service auto-installed all my apps from the Rhyme.

In the process of researching this, I got a much better idea of what CyanogenMod does. I'm tempted to try it out now, but I reckon I'll wait for the 4.3 release, whenever that happens.


I also found http://www.htcdev.com/bootloader, which offers the prospect of unlocking and upgrading the HTC Rhyme, though I haven't found any ROMs that work for the CDMA version...