An ARM On Four Cylinders

I’ve been trying out a Ferrari.

Well, sort of. Let’s put it this way: If the is today’s ARM computing equivalent of the Volkswagen, then the is probably its Ferrari, at least under the hood.


Physically, the thing looks like the result of an unlikely marriage between an oversized postage stamp and a heat sink.

The PCB’s somewhat smaller than a , but even considering this is a development board, the end result is a lot tidier – the heat sink actually makes it somewhat reminiscent of a shrunken down NeXTCube, and tacking on a couple of pieces of matte black cardboard on the open sides completes the effect.

But the most important hardware characteristic of the is its quad-core Exynos 4412 CPU, which is very snappy indeed. In fact, this is the fastest device I’ve used yet by all accounts, although the 8GB EMMC I ordered along with it has to take part of the credit (running the OS from an SD card works fine, but is somewhat slower).

I hooked mine up to a full HD (1920x1080) monitor via an HDMI-DVI adapter1, plugged in a Bondi Blue iMac USB keyboard I had lying around as well as a bog-standard USB webcam and mouse, and stuck to Ethernet for connectivity.


So what do you run on it? Well, I chose – in fact, part of the reason I got one was that Ricardo Cerqueira ported CyanogenMod 10.1 to it with nearly complete hardware support (more on that in a moment), so I pretty much ignored the stock AOSP version and the (then incipient) port and just went ahead and flashed that.

Most people would probably look at using this as a media centre (for which it is eminently suitable), to run arcade emulators (which I did, but mostly to be amazed at the speed of the thing), and, of course, for testing apps.

Me, I set up , Facebook Messenger and Flipboard on it (besides a number of Google Apps and a couple of terminal emulators), and soon had a couple of apps of my own running on it – one of them compiled locally using AIDE.

Given my in for , using as a “desktop” is hardly a problem – aside from somewhat oversized fonts and lack of multitouch (or even a working secondary mouse button), switching between apps with Alt+Tab works smoothly and intuitively enough, and most well-written apps support a minimal amount of keyboard navigation – so (rather ironically) moving about with a keyboard alone is a more viable proposition than on an .

Zooming (which can only really be handled via pinching) remains the only hassle, but there are a few nice touches – for instance, and rather unexpectedly, I can switch it “on” and “off” (i.e., switch off the display via DPMS) using the power button on the USB keyboard, and most “normal” key combinations for caret movement and text handling just work.

Remote Access

One of the reasons I bought an was that it’s a perfect, zero-hassle smart terminal – I just sit, tap the power button on the keyboard and get instant access to a decent default desktop with a few different browsers3, a perfectly usable terminal emulator2 and working builds of tmux and , so the basics were covered right off the bat.

Running is just the icing on the cake, really. But full HD is sort of wasted on terminal windows, so I also looked for ways to replicate .

After some experimentation, I settled on Jump Desktop as my and client – it not only handles tunnelling without any issues and is very speedy, it also works well in uncommon configurations (such as using VNC with Mac authentication or RDP-over-SSH to a Linux machine).

And, of course, it blows out of the water in terms of speed and flexibility.

Interestingly enough, despite not supporting more than one mouse button and handling the scroll wheel inconsistently, Jump Desktop handles right-clicking and scrolling without any issues, and (much to my delight) had no trouble whatsoever with Portuguese keyboard layouts at any end.

So this VPS (where I keep a container with Chrome and development tools to use on the go) and a number of other servers are just a couple of clicks away, and it’s awesome.


There are a few minor niggles with the whole setup, though.

The first is that applications are (naturally) unprepared for being used in a desktop environment and/or with a physical keyboard – even Jump Desktop persists in displaying an on-screen toolbar and keeps trying to “help out” by adding a black margin around the remote display (likely to allow your finger to touch the very edges of the screen), something I worked around by setting my remote desktops to be 1920x1016 (i.e., exactly the right size).

Also, Bluetooth is, alas, not supported yet, for changes in the 4.2 Bluetooth stack mean that USB dongles (the only practical way to add a transceiver) require a substantial bit of internal re-plumbing at the kernel and driver levels to get working.

But overall, and considering that I’m running CyanogenMod nightly builds, the whole thing’s a lot more stable than you’d expect.

Penguin Inside

Using the as an desktop and thin client was all fine and good for a few weeks, but this weekend I decided I’d have a go at running on it locally – partly because I like to pull weird stunts like that, and partly because I’ve been porting stuff from threading to the multiprocessing module and it was a good opportunity to get a better feel for the Exynos quad-core.

Python for Android worked fine (after some tweaking), but I then realised I was going to need to install some packages locally.

So I started thinking about setting up a chroot environment of some sort, gradually drifted onto the notion of using standard Linux ARM binaries and after a few (mercifully short) tries eventually came across Linux on Android, which is nothing more than a chroot environment mounted from a filesystem image4.

As it turns out, running a userland alongside processes works very well indeed (since it’s all running atop the same kernel, there’s zero overhead). So much so that even though I’m not interested in running X applications locally, setting up a server and running Firefox just worked – and at impressively snappy speeds, too.

The only serious drawback with this is the amount of extra storage required for the extra luggage a system brings along with it, but it’s perfectly doable and, at least for my purposes, much better than trying to install natively.

So I can see myself getting quite some mileage from this as soon as I get my hands on a largeish SD card and move the filesystem over to it.

Who knows, I might even go crazy and try to run Unity on it, just for kicks5.

  1. Something that requires some trial and error, since not all adapters are created alike. The adapters work fine, but I eventually settled on a smaller one. ↩︎

  2. CyanogenMod’s built-in terminal app is, incidentally, the only one able to handle a physical keyboard with a non-US layout without any issues whatsoever. ↩︎

  3. Besides the stock browser, I installed both flavours of Opera (Mini and Mobile), Firefox and the Chrome Beta. ↩︎

  4. But the most interesting solution (in terms of actual geek-fu) is still Sven-Ola’s Debian Kit. Reading about it should give you a pretty good idea of what it takes to get the chroot environment to work seamlessly. ↩︎

  5. Not really, no. ↩︎

This page is referenced in: