My laptop is a little underpowered these days and I’ve been having a bit of trouble with up to date support for the AMD Radeon graphics hardware it packs, so I’ve been thinking about upgrading for a few months. I wanted to get a machine designed for Linux, rather than a buying a Windows machine and installing my distribution du jour on it. There are a couple of reasons for this desire. First, it seems to be getting more difficult to be sure that a machine designed for Windows is going to work well with a Linux distro, thanks to features like NVIDIA Optimus and UEFI secure boot, and second I object to paying for an operating system I have no intention of using. I’d rather my money went to the projects and supporters of the open source communities that provide the operating system I choose to use.

The only viable options I found for a well specified bit of laptop kit designed for Linux are the System76, ZaReason and Dell. There are others providing Linux laptops but mostly as cheap or refurbished options.

I have a couple of specific requirements other than good Linux support. I want a 15.6 inch 1080p flat panel, because my eyesight is pretty good and I value screen real estate because I use software like photo editing suites and development environments that have big complicated user interfaces. Having run short of memory on a couple of projects recently I want at least 8GB memory, and I want decent processor. I’d like a fast hard disk or an SSD, and I also want to avoid NVIDIA and AMD graphics hardware and stick with Intel graphics, as I don’t do anything that needs epic graphics power and I’d rather have graphics hardware with a good reputation for long-term Linux support.

ZaReason, a US-based company, offers the Verix 530 which comes close but packs NVIDIA graphics hardware and needs both the memory and hard drive boosting to meet my spec, bumping up the price. Dell only offers one Linux laptop which is a bit pricey in comparison to the others and doesn’t have many customisation options. In only offering one machine and whacking a “Dell Recommends Windows” banner on the pages for their Linux machine, Dell’s not building my confidence that they really know what they’re doing with Linux.

System76 won my business with their Gazelle Pro. It comes close out of the box and I can customise the couple of other options I need without breaking the bank. The important options I chose are:

• 15.6″ 1080p Full High Definition LED Backlit Display with Glossy Surface (1920 x 1080)
• Intel HD Graphics 4000
• 3rd Generation Intel Core i7-3630QM Processor (2.40GHz 6MB L3 Cache – 4 Cores plus Hyperthreading)
• 8 GB Dual Channel DDR3 SDRAM at 1600MHz – 2 X 4GB
• 500 GB 7200 RPM SATA II HDD
• International UK Keyboard Layout – Including Pound, Euro, and Alt GR keys

It’s a shame they’re based out of the US as it adds shipping time and cost on. I also wasn’t sure exactly what happens about paying UK taxes on the import. I put the order in last week and the machine arrived today. Next up, unboxing and first impressions!

I’ve not been blogging this last few months what with all my spare time going into trying to do some proper computer science and then writing my dissertation. Last night, I had a catastrophe – I noticed something in my results that should be impossible and traced it back to a subtle bug that compromised all my results to date! Pretty nasty at this stage in the project…

The effect was subtle and I didn’t think it would alter my conclusions. That said, to ignore it and continue wouldn’t be right. The alternative of explaining about the bug and its effects in my dissertation is not something I wanted to have to do either.

After a few minutes of sitting with my head in my hands I decided to fix it and start again. After all, it’s just compute time and elbow grease, it’s not like I just threw away a month’s time on the LHC or anything! Turns out, my decision to script everything paid off and I could pretty much throw a few tens of hours of compute time in to reproduce all my data and then a couple of hours with the charting software and I’m good to go. The choice of LaTeX also turned out to be even more of a winner as I was able to rebuild my document with the new figures and any layout modifications required almost trivially.

I was right – the conclusions do not change, however they are now more striking and there are no oddities that I can’t really explain. Tips of the day for those doing work like this:

• script everything you can – just in case you need to redo stuff
• use LaTeX – because you can swap out every figure for a new version easily

There are plenty of other reasons for applying these two tips, but there’s two reasons I hadn’t thought of before yesterday.

 

Java programs run on the Java Virtual Machine, a kind of virtual computer that hides many of the differences between the different kinds of computers it’s running on. Folks have been writing implementations of other languages that run on this virtual machine for a while now – besides JVM-specific languages like Scala and Groovy, you can also get ports of existing languages like JRuby, Jython and JavaScript.

Conveniently, in the Java 6 specification (released way back in September, 2006), official scripting support is required in the javax.script package, and a slightly stripped-down build of Mozilla Rhino, the JavaScript implementation is shipped with the JVM.

I’ve been meaning to take a look at this for a while now, and I decided to use these facilities to solve a problem I was having in my MSc. project.

My project consists of runnable experiments that produce some kind of results over sets of data. I want to have fully set up experiments ready to run so that I can repeat or extend the experiment very easily without having to refer to notes or other documentation, which involves programs that accept configuration information and wire up components.

The Java code to do this kind of thing tends to be very verbose – lots of parsing, type-checking and an inability to declare simple data structures straight into code. It’s tedious to write and then hard to read afterwards. Using JavaScript to describe my experiment setup looked like a good solution.

Example: creating a data structure that provides two named date parameters in Java, as concisely as I can:

package com.crossedstreams.experiment;

import java.text.SimpleDateFormat;
import java.util.HashMap;
import java.util.Map;

public class RunExperiment {
  public static void main(String[] args) throws Exception {
    SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd hh:hh:ss");

    Map config = new HashMap();

    config.put("start", format.parse("2012-02-01 00:00:00"));
    config.put("end", format.parse("2012-02-08 00:00:00"));

    // do stuff with this config object...
  }
}

That’s a lot of code just to name a couple of dates! The amount of code involved hides the important stuff – the dates. Now, achieving the same with JavaScript…

var config = {
  start: new Date("February 1, 2012 00:00:00"),
  end: new Date("February 8, 2012 00:00:00")
}

// do stuff with this config

When there are many parameters and components do deal with, it gets tough to stay on top of. Some of what I’m doing involves defining functions to implement filters and generate new views over data elements and JavaScript helps again here letting me define my implementers inline as part of the configuration:

filter: new com.crossedstreams.Filter({
  accept: function(element) {
    return element == awesome;
  }
})

This approach isn’t without problems, for example there’s some ugliness when it comes to using Java collections in JavaScript and JavaScript objects as collections. To be expected I guess – they are different languages that work in different ways so there’s going to be some ugly at some of the interfaces, maybe even some interpretation questions that don’t have one right answer.

Nothing I’ve come up against so far can’t be fairly easily overcome when you figure it out. I think that using Java to build components to strict interfaces and then configuring and wiring them up using a scripting language like JavaScript without leaving the JVM can be a pretty good solution.