Computing

The Planet 3 services can be accessed on your 3 phone by pressing the button on the home screen, which launches the phone’s default browser.

But what if you want to use Planet 3 using Opera Mini?

The short answer is, you can’t. The author of this post thinks that it’s due to the server restricting access to the built-in browsers, but I don’t think this is the correct reason.

Opera Mini, according to Wikipedia, uses a proxy server hosted by Opera that renders the page in a special compressed format. Now, it should be axiomatic that Planet 3 is not accessible outside the 3 network, and the proxy servers are definitely located outside the network. Q.E.D.

I wouldn’t rate their article as “terriable” but their rating system may very well deserve that honour.

Dead iPod Touch

Another day, another iPod Touch calamity. While updating one of the installed applications, gremlins attacked and icons no longer appear on my home screen.

I’m not an Apple fan-boy, I have never been, and I am unlikely to convert because my first foray into the world of Apple products has been a largely unhappy journey. iTunes, at least on Windows, is slow and often unresponsive. Backing up my iPod Touch literally takes several hours, and the version 2.0.1 update took four attempts. The music interface, while great for the Latin-alphabet world, is a pain to navigate with Chinese songs and artists. Installing and upgrading applications via the iPod Touch interface is a slow and arduous affair. While there have been some outstanding applications, the majority are uninspired and useless. You also often find two or more applications that do very similar things, but each lacking in various regards, which means you end up keeping all of these applications; the closed model of the iTunes Store discourages, and in fact prevents, modifications and extensions a la open source software.

I could keep going on for quite some time, but I’m sure others have documented the failings of the iPod Touch and the iPhone in more detail. I can overlook some bugs, but wholesale destruction of my data is unforgivable.

One of the attractions of Bluehost, my host, is the ability to ssh into your box, which makes administering your site that much easier if you know how to use the *nix command line. (See related post.)

I’ll just write about two things that I’ve worked out recently.

Lesson #1: Read the README file.

Well duh, you say. The story is, I’ve had the bash_completion script for some time (a really useful extension that makes typing on the command line that much easier), but I’ve never quite worked out why it didn’t work. Now I know why. It’s because I naively assumed that the bash_completion.sh script was the meat of it, and simply called it from .bashrc, expecting it to just work. It would, ordinarily, but I don’t have it installed in /etc which is where it expects to be (it’s in my home directory). If you have somewhere else like me, you will need to set the $BASH_COMPLETION variable and modify the bash_completion.sh script to reflect where you’ve actually put it.

Lesson #2: If you didn’t set up the system yourself, things might not be as you expect them to be.

SUITS has a bunch of useful scripts that you can use to improve your command line experience on the undergraduate IT servers, and I copied them over to my account on nointrigue.com because I like them so much. One of these scripts sets nice colours for the command line. It was all working fine until I realised TortoiseSVN could no longer access the Subversion repositories via svn+ssh, failing with the error “connection closed unexpectedly”. I figured something I added recently was injecting garbage into the stream. It turns out it was the colour-adding script! But why? It was protected like this:

if [ -n "$PS1" ]; then
        . ~/.bash/colors
fi

That means that it should only have been run if it was running in an “interactive” terminal, and the colour-adding script should not have been called if I was using svn+ssh. After some more poking around, I found this in /etc/bashrc (which was being called from .bashrc):

# For some unknown reason bash refuses to inherit
# PS1 in some circumstances that I can't figure out.
# Putting PS1 here ensures that it gets loaded every time.

Uhh, ok, nice work, Bluehost. I guess not many of their customers actually use ssh. At least there was a comment.

But even if it was called, why the colour-adding script was failing in the first place? It turns out that tput colors fails if $TERM is not set, which happens to be so when using svn+ssh. (Actually, this would not normally prevent me from accessing my Subversion repositories. The command line svn seems to ignore errors; however, TortoiseSVN dies the moment it sees anything untoward.) My ultimate solution was to simply pipe error to /dev/null.

When Daniel plugged his iPhone into his Mac, I thought he had just picked up a budgerigar and strangled it.

Listen for yourself.

I thought the sky almost fell down just then when I went to my gallery2 installation (/gallery) and saw that it had a database error. “Noooo!!! I’ll have to spend hours reinstalling and uploading again!” The error in question was

An error has occurred while interacting with the database.

If you get this error, don’t panic. For me, it turned out that one of the database tables was corrupted and needed repairing. Log in to phpMyAdmin or to the mysql console and check whether any of the tables are listed as corrupt. In my case, it turned out to be g2_CacheMap.

I snooped around some forums, and in the threads that had responses (a lot of forums have questions left unanswered unfortunately), it seems like the blame lies with your host having a bad mysql setup or bad hard drives that corrupt at random. Shame on you, Bluehost.