Bluish Coder

Visiting the Pitcairn Island Petroglyphs

The night before my last day on Pitcairn Island I was asked what areas of the island I hadn't seen that I'd like to before I left. I mentioned "Down Rope" where the petroglyphs can be seen. The petroglyphs are markings at the base of a rockface at an enclosed beach. The markings are thought to be made by pre-european polynesians. To get to there you have to go down a steep path cut into the side of the rock. Parts of it are only about a foot wide and it's a long way down. The yacht taking me back to Mangareva was scheduled to leave at 9am the next day so I didn't think they'd be much chance of seeing it. Shawn, one of the Islanders, offered to take me down at 7am if I was keen and I agreed.

The sun was rising giving a nice morning sky as we were on our way to the Down Rope track via quad bike. In the pictures below you can see the steps leading down at the top of the path. Further down shows the view looking down onto the beach where Down Rope leads. That's Shawn, the Pitcairn guide, who led me down. Without him I'd never have found the path. The beach you can see from that view is the one in this image.

This area of Pitcairn had the only sandy beach that I saw on the island. The other areas were pretty rocky. There were the usual Pitcairn crabs that I'd seen down Tedside while fishing, but also a type of crab that lives in a shell which I hadn't seen before.

An idea of the scale of the cliffs at the bottom can be seen in this photo with Shawn walking ahead of me. They towered above. At the base are the petroglyphs. They are carved into the rock and indented, which you can see when looking up close. To make them easier to find the outlines have been painted which is why they are white and clear in the photo.

The way back up was a bit easier on the nerves, probably because I didn't need to look down, but harder on the legs. In that photo you can see the steps in the rocks on the right - not for the faint of heart! Further up you're clinging to the rockface, then onto slippery banana leaves, and finally back up the top. It was a great experience and I'm glad I was able to fit it in before I left.

This is a republish of one my [pitcairn news](http://www.pitcairnnews.co.nz/120620.html#downrope_and_petroglyphs) articles about my trip. Re-posted as I've been writing about my Pitcairn trip here also.

Building Inferno OS for Android Phones

Updated 2014-12-29 - I've moved the patch files to github and provided updated build instructions there. Other than those build instruction updates most of this post is still valid.

Inferno is a small operating system that can be built to run on Host operating systems as a user process or natively on bare hardware. Inferno uses ideas from the Plan 9 operating system and has some interesting features. These include the Plan 9 system of representing resources as files using the 9P protocol.

Last year source and binaries were released to run the hosted version of Inferno on an Android phone. A YouTube video of it running is here. The binaries and installation are quite tightly tied to a specific android revision. It involves replacing the init.rc file on the phone to enable dual booting of Android or Inferno. Replacing this file in versions of Android different to that which the replacement was based on won't work. For example the version used is from a Gingerbread device and won't work on an Ice Cream Sandwich device. I set about building from source so I could run Inferno on my Nexus S alongside Boot To Gecko. I used B2G as the base instead of Android as B2G is easier to build and it's interesting to compare the two operating system approaches on the phone.

Warning: These steps flash data to your phone and may result in having to re-flash the original OS. Make backups first! B2G and Inferno are experimental operating systems running on the phone. They may not make for a great Phone experience at this early stage in their development.

This first step is to build the B2G system. This is pretty well covered on the Mozilla Developer Network. Basic steps to build for the Nexus S (with the phone connected to the PC):

$ git clone git://github.com/mozilla-b2g/B2G
$ cd B2G
$ ./config.sh nexus-s
$ ./build.sh
$ export B2G_ROOT=`pwd`
$ cd ..

If you want to flash B2G to your phone you can run the following command with the phone connected (this will delete everything on your phone and is not needed if you want to just try Inferno on your rooted Android phone):

$ cd B2G
$ ./flash.sh && ./flash.sh gaia
$ cd ..

We'll use the B2G tools to build Inferno and 'adb' to copy it to the device and start it.

The most recent port of Inferno that runs on Android is available in a mercurial repository hosted on bitbucket. This should be cloned and the PATH modified to use the Linux version of the Inferno build tools which we also need to build. Unfortunately the repository modifications to get Android builds working has broken Linux builds slightly so the first build attempt will fail and then we manually build the features we need. The location of the build needs to be in /data/inferno to match the directory it will be in on the device.

To build the Linux tools after cloning, edit the mkconfig file to have the following settings (change the existing ones set to Android/ARM):

SYSHOST=Linux
OBJTYPE=386

Now we build:

$ cd /data
$ hg clone https://bitbucket.org/floren/inferno
$ cd inferno
$ vim mkconfig    # Change SYSHOST and OBJTYPE as above
$ ./makemk.sh
$ export PATH=$PATH:/data/inferno/Linux/386/bin
$ mk nuke
$ mk install      # This will error out, ignore the error and continue
$ cd lib9 && mk install && cd ..
$ cd libmath && mk install && cd ..
$ cd utils/iyacc && mk install && cd ../..
$ cd limbo && mk install && cd ..

Now that the Linux tools are built we can build the Android version. This requires an ARM C compiler compatible with Android. I use the one built during the B2G build process which is accessed via a wrapper shell script called agcc. This agcc script is based on using the Android SDK. A patch to have this work with the B2G toolset is available here. This assumes B2G's gcc is in your PATH. The example below sets this and you'll need to change it to where you cloned B2G. You should also adjust the instructions to put agcc somewhere in your path. I use a bin subdirectory off my home directory.

I was unable to get the prebuilt audio binaries working that are provided with the Inferno for Android port. There were also some changes I needed to do to get it working on ICS. Patches to disable the audio, compile on ICS, and get events working are in inferno.patch which is applied in the commands below.

Edit the mkconfig file to have the following settings (change the existing ones from Linux/386 that we set earlier):

SYSHOST=Android
OBJTYPE=arm

Install agc modified to use B2G:

$ cd ~/bin
$ curl http://plausible.org/andy/agcc >agcc
$ chmod +x agcc
$ curl http://www.bluishcoder.co.nz/inferno/agcc.patch | patch -p0
$ export PATH=$PATH:$B2G_ROOT/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin

There is an issue with building using the B2G toolchain regarding stdlib.h. To prevent a compile error around the use of wchar_t I modified $B2G_ROOT/bionic/libc/include/stdlib.h line 167 to change #if 1 to #ifndef INFERNO to prevent the wchar_t usage of mblen and friends from being used.

Build Android Inferno:

$ cd /data/inferno
$ vim mkconfig     # Make SYSHOST/OBJTYPE changes for Android
$ curl http://www.bluishcoder.co.nz/inferno/inferno.patch | patch -p1
$ vim $B2G_ROOT/bionic/libc/include/stdlib.h   # Change to line 167 described above
$ mk nuke
$ mk install

Inferno for the device is now built. I use a B2G device to test but it will run on a rooted Android phone as well. To install run the parallel-push.sh script with the device connected. This copies everything to /data/inferno on the phone:

$ ./parallel-push.sh

Booting the phone will still boot into the main OS (B2G or Android). Inferno can be manually run using adb:

$ adb shell
# stop b2g     # 'stop zygote' on Android
# cd /data/inferno/Android/arm/bin
# ./emu-g
;; wm/wm &

From the running emu-g shell you can run any Inferno commands. The device interface to access phone functions is documented in README.android. For example, to turn the phone on and enable GSM data on New Zealand's Vodafone network:

;; echo on > /phone/ctl
;; echo net on gsm www.vodafone.net.nz '' '' > /phone/ctl

Photos of the main phone screen and tetris running on the phone are below:

To switch from Inferno back to the main OS, kill the running emu-g process and start b2g or zygote:

# kill 1234    # where 1234 = process id of emu-g
# start b2g    # 'start zygote' for Android

There are a bunch of issues with the existing port unfortunately. The 'hardware' capacitive keys don't work. I work around this by tweaking /etc/buttonserver.cfg to use the down volume key to bring up the keyboard so I can at least type. The touch screen seems to be out by a few pixels. Sound doesn't work due to disabling it in my patch applied above to get things compiling. I did test receiving and making a call though using direct device access and that worked.

Inferno is an interesting operating system and with its distributed features and Limbo programming language there might be some different approaches that could be taken to integrate phones with desktop devices to share computing resources. The existing port has some bitrot and the steps to build, as can be seen above, are quite manual but it can be streamlined. Dual booting B2G (or Android) with Inferno shouldn't be too difficult. It'd be nice to see continued work on Inferno for Android to experiment with distributed applications on mobile devices.

ATS library reference

While I had some downtime travelling during my Pitcairn Island trip I made a start at writing some reference documentation for some of the ATS standard libraries. I used AsciiDoc to write the documentation because I was familiar with it from doing a reference for Wasp Lisp.

I've only documented a few of the standard modules and welcome contributions for any others. I've included examples for most of the functions. The examples and AsciiDoc source are available in my ats-reference github repository.

A generated PDF from this source is available in ats-reference.pdf.

H.264/AAC/MP3 decoding support for Boot To Gecko

Bug 714408 landed on mozilla-central today. This adds the ability to decode video and audio that uses the H.264, AAC and MP3 codecs on B2G. This support is exposed through the standard HTML video and audio elements. If you're running B2G built from the latest mozilla-central then the following video MP4 video should work:

Sorry, your browser doesn't support HTML video

Of course, WebM works on B2G too using our builtin decoders:

Sorry, your browser doesn't support HTML video

Support for the H.264, AAC and MP3 codecs is provided by using the android 'libstagefright' library which allows hardware accelerated decoding of some video formats. The current implementation is still a work in progress and there are some bugs and performance issues that need to be addressed but playback is at least working.

The Firefox decoding engine was modified to enable decoders to be loaded from a shared library. This 'PluginDecoder' is enabled using the compile time configure switch "--enable-media-plugins". One specific plugin is implemented, omx-plugin. Building this is enabled using the configure switch "--enable-omx-plugin". The combination of these two switches gives support on B2G and those switches are turned on by default in the mozilla-b2g git repository.

What about support for Firefox on Android? The same basic approach can work on some devices running stock Android. There is work ongoing to get H.264/AAC/MP3 decoding working reliably on Android. There are differences between Android versions in the stagefright API and this needs to be handled. Possibly by having different plugins for each android version, or having the plugin dynamically determine what functions to use at run time. B2G was easier (and one reason why it was done first) since we control the specific libstagefright version used.

What about support for desktop? This is trickier since some desktop operating systems don't include H.264, AAC or MP3 decoders. Exactly what the desktop story is is under discussion (I believe - I'm not aware of any specific decision being made about support yet). A GStreamer decoder was recently landed but is not built by default. Using the configure switch "--enable-gstreamer" results in it being built and provides support for H.264. This works on Linux. It may work on GStreamer for Windows/Mac but I haven't tried.

If you're testing B2G please try out the new decoding support and raise bugs for things that don't work. This will help us have better Android support too if we can squash as many implementation issues as possible at this early stage while Android support is being worked on.

Pitcairn Island and Slow Internet

While I was visiting Pitcairn Island I got to experience what the internet is like for areas where fast broadband speeds aren't available.

I wrote about the internet setup on the island in my post about leaving for the island. I found while I was there that many modern websites just failed to work. I was unable to use Gmail's standard interface. It would almost never complete loading. When it did successfully load it wouldn't work. Requests would time out, and the page would just hang waiting for the results of background HTTP requests. I had to use the fallback 'Basic' HTML interface. This actually worked quite well and was usable.

Facebook was mostly usable but again background HTTP requests would often time out and fail. This would results in parts of the interface becoming unusable. The initial load of the page took minutes. I was rarely able to upload images greater than 80Kb in size - they'd never complete. Facebook's major win was that everything is integrated on the site so I wouldn't have to attempt loading any other major website to do chatting, photo sharing, etc. It'd take all day if I had to visit a dozen sites to do things.

Twitter was painful. Visiting pages with individual tweets took an age to load due to the size of the data being transferred. Sending a tweet out would take a long time with no obvious indication to the user that anything was happening - was it taking a long time or had it just failed?

I found using text based tools running through an SSH connection to a remote server to be more usable than the web browser in some cases.

Most issues I had with sites seemed to be the result of:

• XMLHttpRequest's failing and the site not gracefully handling the failure. The user never gets informed of it and they're left waiting for a long time wondering if things are working.
• Making dozens of HTTP requests on page load due to individual JavaScript files, CSS resources, third party widgets being loaded, etc. The latency of the satellite connection on the island makes this much worse than just the slow speed of the connection.
• Large images on pages. I remember reading a Hacker News thread about WebP where someone commented that an extra 10-20% on image compression doesn't matter in the modern world of high bandwidth availability. Pitcairn has taught me that this isn't true everywhere - every byte counts.

These things can be hard to test for. Simulating low bandwidth/high latency connections is a chore and I doubt many website developers do it. Simulating failure of resources loading is also tricky - it probably never occurs during development so the failure path never gets tested.

I'm curious if a combination of the newer web standards could help in some of these areas. Could the offline application cache be used by sites like Facebook and Twitter to more aggressively cache the non-changing scripts and user interface portions of the site for example.

On the positive side, less time on the internet meant more time enjoying the island.