Welcome to revis.org, a small and dull website which will probably be of no interest. The tedious items below may help you fill the seconds of you life in which you can think of nothing better to do.

Fiction Index
Linux on Apple Laptops
Links to web resources
Random Comments

Most of the things you will find here are notes I have made while fixing problems because the single most irritating thing in the world is trawling through bad documentation and old mailing list posts in order to find the exact configuration tweak needed to get everything to Just Work (TM)... again.

I wanted to recreate my xplanet setup for Gnome.

I discovered a few new things, including the fact that the way xplanet deals with paths has now changed. As a result here are updated instructions.

Grab the moon map file first with:

sudo apt-get install xplanet xplanet-images
wget http://astrogeology.usgs.gov/Projects/Clementine/images/albedo.simp750.jpeg
sudo mv albedo.simp750.jpeg /usr/share/xplanet/images/moon.jpg

Then get my modified scripts (based on cueSim/Matthew Gates work and the xplanet FAQ):

cd ~
# get the new scripts and extract them into ~/.xplanet (overwriting old versions)
wget http://revis.co.uk/site/files/xplanet-config.tar.gz
tar zxvf xplanet-config.tar.gz
cd .xplanet
# run the cloud download script for the first time
images/download_xplanet_cloudmap
# optional - add the cloud upload script to a timer
crontab crontab

Then, for Gnome:

Go to System>Preferences>Sessions and add a new entry for the command ~/.xplanet/gnomescript. You can change the wallpaper mode by right clicking on the background.

Or, for KDE:

Right click on the desktop and select configure. On the background tab select no picture and click on advanced options.

Select Use the following program for drawing the background and then the xplanet option. Click on modify. Both the command and preview lines should read:

xplanet -background=~/.xplanet/images/Star_Field_Small.jpg -lat 39.75788 -long -41.066895 --radius 35 --geometry %xx%y --num_times 1 --output %f.jpg && mv %f.jpg %f

The location (lat/long) are set over the North Sea to show Europe and the US. A quick way to get a new position is to navigate to it in Google Maps and copy the "Link to this page" hyperlink.

http://maps.google.com/?ie=UTF8&ll=37.0625,-95.677068&spn=
0.087668,0.22316&t=p&z=12&om=1

The bold section in the link above is the location of the point shown in Google maps.

It is possible to create on Android an application that is just a front end to a web page – a single purpose web browser that provides a single view.

There are several reasons why you might want to do this, for example providing a proper icon rather than a link in the browser favourites is fairly helpful. It also allows for customisation of menu items (e.g. forward/back).

The biggest advantage is access to local functions. You can provide the JavaScript running in the browser with methods that execute in Java directly, allowing access to local resources.

First a WebView element has to be added to your application to hold the browser view. This is added in your layout xml file in the same way as any other view.

<WebView
android:id="@+id/wv1"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>

This is then populated with a WebKit instance, and JavaScript enabled. A Java object (ProxyBridge) is exposed using addJavaScriptInterface().

package com.test.localstore;

import android.app.Activity;
import android.os.Bundle;
import android.webkit.WebSettings;
import android.webkit.WebView;

public class Localstore extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle icicle) {
        super.onCreate(icicle);
        setContentView(R.layout.main);
        
        WebView wView = (WebView)findViewById(R.id.wv1);
        
        ProxyBridge pBridge = new ProxyBridge();
        wView.addJavascriptInterface(pBridge, "pBridge");
        
        WebSettings wSet = wView.getSettings();
        wSet.setJavaScriptEnabled(true);
        
        wView.loadUrl("file:///android_asset/index.html");
    }

	public class ProxyBridge {
		public int one () {
			return 1;
		}
	}
}

The file:///android_asset/index.html URI refers to a file index.html held in the package /assets folder.

It is possible to make this load a remote file, but holding the interface locally and pulling content from the outside world via JavaScript means you can present sensible error messages (or use locally cached data) when there is no internet connection available.

The exposed function can be accessed as object.method(), for example:

<html><body>
<div id="output">Test page.</div>
<input type="submit" value="change to 1" onclick="document.getElementById('output').innerHTML = pBridge.one()" />
</body></html>

Because Android has a local SQLite implementation, building a Gears-like interface should be possible to allow the device to run off-line web applications in a similar way to desktop machines.

Before we start I should point out that this install process made me dislike eclipse rather a lot. The only thing I dislike more is the person who wrote the Android install FAQ and didn't add any information on how to install the chain of dependencies. Recursively searching install FAQs is not fun.

First, get and unzip the Android SDK somewhere sensible (from here).

wget http://dl.google.com/android/android-sdk_m5-rc15_linux-x86.zip
unzip android-sdk_m5-rc15_linux-x86.zip

Add the tools directory to your path:

export PATH=${PATH}:~/path/to/android/tools

Install eclipse:

sudo apt-get install eclipse

Then install the Android plugin and dependencies by going to Help > Software Updates > Find and Install > Search for New Features and adding both the Android and WTP plugin repositories.

• http://download.eclipse.org/webtools/updates/
• https://dl-ssl.google.com/android/eclipse/

Select Android, WTP and Callisto from the list, then let it search for new features. Select everything in the Android list then let Eclipse install and restart. It might or might not bother, if not kill it yourself with some excessive -9 then try again.

The rest of the steps to a working project are here.

I picked up a Black Linux Eee 1000 today, and so far I really like it.

This is the first time I have bought a laptop with Linux pre-installed, and I'm enjoying the experience of actually having everything work out of the box. This does mean that there will be considerably fewer articles posted here... so everyone wins.

There have been only two places so far where anything other than point and click has been required to get it to do what I want.

• Enabling 'advanced desktop mode' (KDE 3.5)
• Setting up my Nokia 6120c to work as a 3G modem

To fix the first issue I just downloaded this package and this package and installed them from the right click menu. This adds an icon to the shut down menu that drops you to a full KDE desktop.

Connecting to the internet via my cell phone (T-mobile UK) was a little bit more complicated.

• Turn on Bluetooth with Fn-F2
• Disable PPP auth (you may not need to do this for your mobile network, test it first!) by changing 'auth' to 'noauth' in the ppp options config file (ctl-alt-t for a terminal, then run sudo nano -w /etc/ppp/options)
• Open the Bluetooth manager (from settings or with sudo /opt/AzureBT/AzureBT)
• Turn on Bluetooth on your mobile and set the device to be discoverable
• Press F5 on your laptop to search for devices
• Your mobile should now be listed, right click on it and select Pair Devices and follow the instructions
• Select Dial Up Network>Connect then enter
  

  Username:

  web

  Password:

  web

  Number:

  *99***1#

  APN:

  general.t-mobile.uk (NOT .co.uk)

• Click on Dial

This should work for both 3G and GPRS on all Nokia S60 handsets (N95, E65 etc) and may work on non-Nokia handsets as well.

Someone asked me recently if I had started watching TV or developed a drinking habit, prompted by the fact that I haven't been updating my site. Heck, I haven't even installed the new Ubuntu release and it's been out for over a month.

Well, today I can finally prove that I haven't been spending my evenings at home drinking in front of old episodes of Frasier. Things are much, much worse than that.

[Edit]
Over the last few months I have been putting together in my spare time an online planning application in JavaScript.

...which is currently down for upgrades. Should be live again with a new pretty version later this year.
[/Edit]

Before you can give a vertical size in Firefox the parent needs to have a size set. By default the body and html elements have a size of zero, so using only percentages to control a fixed vertical layout doesn't work.

However adding the following CSS restores logical behavior.

body {
height: 100%;
}
html {
height: 100%;
}

Ah, another cliché. Sit in a meeting for long enough and a few will come along to mug your faint hope for the human race.

One of the most common clichés at engineering meetings, along with 'oh no not another inflatable dartboard', is 'as useless as a fish with a bicycle'. One key point always remains unanswered; just how useless is a fish with a bicycle? I have never seen anyone attempt to quantify it.

If we do not wish to take the easy option of just giving the fish a normal human bicycle (which seems like cheating) we must first invent a suitable sort of bicycle-like conveyance for a fish. How about this one?

Ok so it's not really a bicycle, really more of a tricycle, but I feel that nitpicking has been left rather late at this point in the proceedings. There is directional control, bicycle type wheels and a chain drive. This is a lot closer to spec than most things that come out of a design office.

Can the fish move the device? Well, a quick scan of the internet reveals a power output estimate for a 1kg cruising Euthynnus of 0.009W or roughly 0% of the output of a household light bulb.

Real engineers are encouraged to skip this paragraph: Temporarily ignoring efficiency (and sanity) we will assume that as every action has an equal and opposite reaction the circular motion of the fish will induce a circular motion of the water of a similar magnitude but in the opposite direction. This will drag the turbine around, transferring all 0.009W to the drive chain.

This website has a calculator for working out speed at a given power. It will be horribly inaccurate for this particular device but frankly at this point I'm hoping that the errors sort of cancel out. Assuming that our fish conveyance is a 'Streamlined Trike' with a weight of 3kg (1 for the fish, 1.5kg for water and 0.5kg for the rest) we can expect a speed of 0.037m/sec or 27.8 miles per fortnight.

Hold on! Not so fast! As the unsophisticated steering mechanism supplied to the fish can only direct him at +/- 5 degrees his path will not be straight but rather a meandering path more commonly displayed by those who are as drunk as a, um, fish.

Rather than actually do some real maths we will just approximate this as a zig zag path with instantaneous direction changes of 90 degrees. This would give a forward motion of 1m/sec for each 1.41m/sec of actual speed, or in the case of our intrepid aquatic cyclist a blazing 0.026m/sec. This is far superior to your common or garden racing snail who can only manage 0.013m/sec.

So what use is this? Well, frankly, not much. A fish in a trike is unable to pull even fairly trivial loads at any great pace. It is also likley to be defeated by even the smallest of hills. But at least now we know.

As it turns out with enough ingenuity you can pretty much design a solution to any problem. Just be sure it isn't a fish bicycle kind of problem.

Drawing CSS layouts using the 'em' unit of measure is a very good idea, as it allows the browser to flexibly resize the whole page when the user zooms in or out. There is a lot more information about flexible layouts here including an example.

However for a complicated application you may need to compute new locations based on the position of existing page elements. You can get the location of an existing element like this:

var el = document.getElementById('elementname');
var left = el.offsetLeft;
var top = el.offsetTop;

However this returns the position in pixels instead of em. In order to convert this to em you need to know how big an em actually is. The most common technique I have seen recommended for this is to make an empty div 1em high and get it's rendered height like so:

HTML
<div id="fontsizecheck" style="height: 1em; position: absolute;"></div>

JavaScript
var el = document.getElementById('emptydiv');
var elinpx = el.offsetHeight;

This works up to a point, but has a serious limitation. Let's say your users font size is really 9.5 pixels in size. Because pixels are always integers your 'eminpx' variable will now hold 10. This means that if you are trying to position something at 'left: 10em;' your code will put it at 100px rather than 95px. This is a pretty big error if you are trying to get things perfect.

Worse than this, as you zoom in and out, the magnitude and sign of this error will change. This causes some interesting visual bugs.

Fortunately there is a pretty easy way to make the errors so small that you can cheerfully ignore them as they will be less than 0.499 pixels. Simply sample an attribute from a much bigger interval with a known size in em.

HTML
<div id="fontsizecheck" style="left: 50em; position: absolute;"></div>

JavaScript
var el = document.getElementById('emptydiv');
var eminpx = el.offsetLeft/50;

The result from this method is good enough to accurately position across a 1650*1080 screen, but may need to be expanded if you are doing something for huge displays with very small font sizes.

I moved from an unlimited data plan to a limited plan from the start of January this year. Being a fairly cautious person, in the month before I made the jump I kept track of how much data I used to make sure that I wouldn't go over the limit.

My new monthly limit is 3GB (1), December's usage was 2800MB. Fantastic, time to switch. Just to be sure I was keeping on track throughout January I set up a automatically populated spreadsheet with an output like this (the scale is in MB):

The yellow line shows, assuming remaining data is evenly used, how much I can use on any particular day without going over budget and getting a slap on the wrist from my ISP.

Daily usage as you can see is generally all over the place, but if we add a simple linear regression (2) a pattern shows up:

Generally it trends upwards towards the end of the month. This should be fairly unsurprising:

• I was low at the start trying to keep under my daily usage limit.

• This reserve built up pretty fast, especially when I wasn't online for some reason.
• With excess available at the end of the month I started burning it on discretionary things like video.

Compare this to December, which has a similar total usage, but spread out roughly evenly over the month.

So, why does it matter when I decide to use my bandwidth? Individually it makes no real difference, but it probably gives some insight into why ISPs often don't offer a status page to show how close you are to the fair usage limit.

If everyone knew how much they had left over at the end of the month the resulting download frenzy would put a major strain on their infrastructure, plus there would be another hit at the start of the month when people who were low at month end suddenly gained a new lease of life. Meanwhile, in the middle of the month expensive hardware would sit idle, when everyone was either already running low or hoarding.

(1) By which they probably mean 3000MB.
(2) General warnings about lies, statistics and devious analysts apply.