Live from Austin!

In mid November, our contract with AT&T (formerly Cingular) expired. We switched to T-Mobile and got BlackBerry Curve phones.

I was a BlackBerry skeptic for a long time. I didn’t think I wanted a phone with a full QWERTY keyboard. This changed when we looked at the phones available. It turned out that the Curve was only marginally wider than the average phone, perhaps a centimeter or so. It’s otherwise comparable to mid-range phones in size. It ends up being pretty much as portable as our Sony Ericsson Z520a phones.

The BlackBerry UI is best described as “retro”. The icons look like 1990s Windows, the text fonts look like 1980s Atari ST, and the general method of navigation most resembles Palm OS. This is both a good thing and a bad thing. Starting with the good, the UI is clearly designed from first principles to work well on a handheld device. The central trackball handles scrolling, pointing and clicking. It sits easily and naturally under the thumb. You can do pretty much everything with one hand, including browsing the web and checking e-mail.

This is in marked contrast to the iPhone, which pretty much requires two-handed operation. Windows Mobile devices suffer from having a desktop UI squeezed into a handheld form factor, and also require two hands, and often a stylus. Symbian is designed for phones, but the UIQ interface for smartphones uses a stylus. Overall, then, the BlackBerry works better than other phones I’ve tried when you’re standing in an airport with a coffee in one hand.

On the downside, it’s hard to find the icon you want in a hurry, because of their visual clutter. Perhaps a replacement UI theme would help; I’m a little tempted to grab the theme designer and start working on one, but it’s Windows only. The fonts were initially problematic too; nowhere near as nice as Apple’s, and they took some getting used to.

But when it comes time to reply to an e-mail, niggling issues with fonts were forgotten as I got to grips with the keyboard. Yes, it requires both hands, or more accurately both thumbs. It’s not as fast as a full size keyboard, but it’s faster than Palm Graffiti or Windows Mobile pen input, and much faster and less frustratingly error-prone than I found the iPhone’s on-screen keyboard to be. Unless Steve relents and allows a Son of Newton to use the Newton’s non-cursive text recognition, I can’t see it being bettered.

Textual messaging is where the BlackBerry really shines. It’s quite possible to thumb out fairly lengthy e-mail responses, or even update your web site. As far as IM, there’s support for Google Talk and AIM built in, as well as Yahoo Messenger, Windows Live Messenger and ICQ if you know anyone who still uses only those. There are third party clients for non-Google Jabber and other protocols, and in addition, there’s BlackBerry’s own BlackBerry Messenger, previously called PIN messaging.

If you have a friend who also has a BlackBerry, PIN messaging is definitely the way to go. The manual doesn’t cover its benefits, so I’ll digress a little here. Unlike other IM systems, PIN messaging is tied to the BlackBerry device by a unique ID. You connect with another person initially by sending them an invite via their BlackBerry-specific e-mail address, or any other address they access via BlackBerry e-mail. When they reply, their device records the device ID you sent, and sends you theirs.

The primary benefit of PIN messaging is that it’s push-based. The recipient doesn’t need to be logged in. If their phone is switched off, the message will be queued until they log on.

The second benefit of PIN messaging is that it’s reliable. Unlike SMS, messages don’t get randomly dropped. In addition, you get delivery confirmation automatically for every message: when you hit enter, the line you typed appears in the transcript with a small icon next to it indicating that the message is going out over the network. When your device receives positive confirmation that the recipient’s device has displayed the line you sent, the icon changes.

If that’s not enough, there’s a third benefit over IM or SMS: there’s a separate “ping” option. So you can set up your regular notification to be something discreet, and know that your spouse can ping you to set off something more noticeable if necessary.

Other than that, PIN messaging has the usual file transfer, allows you to send voice memos, and looks and behaves like regular IM. For us, it has completely replaced SMS, not least because it doesn’t cost 15¢ a message.

One interesting feature of the BlackBerry is that as well as individual icons for each messaging system, there’s also a unified inbox that shows IM, SMS and e-mail in one place. This makes sense, as they all have pretty much the same UI on the Curve; the protocol is almost an irrelevant detail. I believe that if you attempt to send pictures via SMS, the phone automatically uses MMS, but I haven’t tried it.

Web browsing is a mixed bag. The built in BlackBerry browser has two modes, mobile mode and “desktop” mode. Although there are references to WAP, the browser copes with both, the mode just determines how the page is formatted for display. In mobile mode it works like a typical phone browser, in desktop mode it tries to deal with things like tables, CSS and JavaScript. Overall it makes for a pretty good browsing experience, as phones go. (If you haven’t tried browsing from a phone, the main issue isn’t usually layout–it’s latency. Each page request takes a ridiculously long time to send, compared to a desktop system. I assume this is something to do with the mobile network.)

An alternative is Opera Mini, which takes the “thumbnail of page with moveable active area” approach to web browsing. It works surprisingly well with sites that the built-in browser can’t cope with, like zagat.com. (Yeah, good move, make a web site of restaurant reviews that doesn’t work with a phone browser.)

Maps are another strong point. There’s a map application supplied, but I downloaded Google Maps for BlackBerry, which is free and offers pseudo-GPS location by correlating your active cell to its geographical location. Accuracy can be as little as 50m or so in cities, up to 1km in the countryside. The Google Mail application also works well once downloaded.

The BlackBerry OS appears to be Java based, and is pretty solid. It’s more reliable than a Palm; I’ve only managed to crash it once, which is comparable to Linux on the N800 in solidity. Initial bootup (after inserting a battery) is horrendously slow, but once running it seems to use a soft power off which doesn’t require a full boot. The UI is generally responsive at all times, unlike some Sony Ericsson phones. You can put the phone into standby mode by holding down the power switch. In standby the screen and keyboard deactivate, but you can still receive messages and calls. The same hold-down-button action brings the phone out of standby instantly.

The one bug I’ve found so far is in the BlackBerry web browser. After a while the cache gets full and slows browsing down tremendously. The workaround is to empty the cache once a week.

The phone shows a lot of attention to the details of how a mobile device should best operate. For example, an ambient light sensor behind the notification LED turns the screen brightness down in dark areas, and automatically turns on the keyboard backlight. The LED itself has behavior customizable through the notification options; each event (phone call, IM, SMS) can have any or all of a user-chosen sound, vibration, and LED flashes. You can even set different messaging systems to have different notification; for example, I have IM just flash the LED a few times, unless it’s a PIN message from the spouse.

Mac sync is a bit of a sore point. There’s a package called PocketMac that BlackBerry purchased and now give away for free. It worked for me, more or less, but had some annoying bugs. (For example, syncing with a subset of address book records didn’t work, and editing records on the BlackBerry resulted in duplicates.) The solution is simple enough: Mark/Space have a Missing Sync for BlackBerry, which makes everything work, and even syncs user pictures so you can see the face of the person calling you if you’ve given them a picture in OS X.

Overall, it’s the best mobile phone I’ve used. Whether it’s good for you will of course depend on your use cases. If you’re someone who likes to talk to people or use voicemail rather than IM or e-mail, or if you have little patience for customizing software, the iPhone is probably a better bet. It certainly look prettier. But if you prefer text to voice and prefer functionality to prettiness, the Curve beats the iPhone hands down. This may change once they stop crippling the iPhone and open it up to third party applications; we’ll see. For now, I’d pick the Curve again, even if the iPhone wasn’t tied to AT&T.

Update: Oh yeah, the Curve is also a quad band phone. That’s de rigeur, so I didn’t even think it was worth mentioning.

I guess I wasn’t paying attention to the Leopard previews earlier in the year, because OS X just blew my mind.

I was editing an e-mail message, and decided to idly click on Time Machine to see what it was doing. Instead of the Finder going into Time Machine mode, my e-mail went into time machine mode. I clicked the back arrow a couple of times, and there was what my e-mail inbox looked like 2 days ago, complete with since deleted messages.

It’s the same with the Address Book. You can step back through how your address book looked at different moments in the past.

My general impression of Leopard is that it’s good. Proper multi-threading in Finder and Mail makes a big difference. But this Time Machine thing is the most amazing backup tool ever. I got a big hard disk at Costco at the weekend, and backing up is now totally painless, there isn’t even an application to run. You just have to make sure a suitable disk is plugged in for long enough to copy the changes over, once a day or so.

Backing up isn’t sexy and it isn’t fun, which is why most people don’t bother to do it. Now there’s no excuse to skip backing up. Or at least, not if you’re a Mac user.

One of the things I found confusing about bash was its startup scripts: there were so many of them. Eventually I snapped and sat down with a terminal and the man pages, and worked out how it actually behaves. Here’s a summary.

On startup, bash executes any script labeled A in the table above, followed by the first script B it finds. On exit, it executes any script labeled C above.

Let’s look at the column headings in a little more detail.

• An interactive login shell is a shell that you are typing into, that is the first such shell you execute on the machine. Typically you will have had to log in immediately before the shell starts. For example, when you SSH to a remote system and type commands to that system, you are typing into an interactive login shell.

• An interactive non-login shell is a new shell started once you have already logged in; one which doesn’t require that you log in again.For example, if you open a new terminal window in your graphical user interface and get a shell prompt, that’s an interactive non-login shell. Another example of an interactive non-login shell would be a sub-shell started from inside a text editor; for example, typing :sh in vi.
• A non-interactive shell is a shell which doesn’t prompt you; it just runs a program and then exits. The most common example of this is any program written in shell script, such as a configure script, a startup script in /etc/init.d, or any other file marked as executable that has #!/bin/bash on the first line.
• A remote shell is a shell started by a program such as SSH or rsh in order to run a command on a remote machine.For example, the rsync and scp commands use SSH remote shells in order to copy files between machines.

So looking at the second column, an interactive login shell will execute /etc/profile always. It then looks for ~/.bash_profile, ~/.bash_login, and ~/.profile in turn, and executes the first of those it finds. On logout, it executes ~/.bash_logout.

The /etc/bash.bashrc A† item is special; whether bash searches for it is dependent on a compile-time option.

BASH_ENV is an environment variable which allows you to make non-interactive non-login shells (such as shell scripts) execute a startup script. Set BASH_ENV to the filename of a script and then invoke a sub-shell, and the script will be executed when the sub-shell starts up.

Problems with bash’s behavior

Given the above table, the short summary is:

• If you want something executed only when you first log in, put it in ~/.bash_profile
• If you want something executed only for additional shells (such as OS X terminal windows and xterms), put it in ~/.bashrc

But there are a couple of problems with this arrangement, problems which suggest that bash’s startup behavior wasn’t really thought out with users in mind.

Firstly, if you are anything like me, most of the things you want to put in shell startup scripts are things you always want executed. Command aliases, for example; or environment variables that tell pieces of software where to find their bits (JAVA_HOME, ECLIPSE_HOME).

You could put those in both .bashrc and .bash_login, but that represents a maintenance problem: if you change something, you have to remember to change it in both places. So, you might set up a third file for global stuff, and use the shell command source to read it in from both .bashrc and .bash_login. I’ve seen some Linux distributions set this up as the default. I don’t like it, however, because it means you now have 3 different startup files floating around, and when you want to change something you have to remember which file it’s in (or sit and work it out).

The second issue with bash startup scripts is that the distinction between login shell and non-login shell isn’t a very useful one these days. Most of us use graphical user interfaces, so we never see a login shell on the machine we’re using. (For example, any terminal window you open on OS X is a non-login one.) Even when I use SSH to shell into a remote system, I don’t generally want that first login to behave differently to any other shell I start (such as shells inside screen).

What I do care about, on the other hand, is whether the shell is interactive. I don’t want my reminder program printing stuff when rsync is trying to connect and transfer files. I don’t want all my custom commands and aliases getting in the way when running scripts to configure or build software. And I don’t want to slow things down loading cdargs unless I’m actually going to be maneuvering around the directory structure by typing.

So what I want is to have a single customization script, and be able to split it into stuff that is always run, and stuff that is only run when I’m using the shell session interactively. Here’s how to do that.

Simple all-purpose bash initialization script

Start off by moving all your current bash startup scripts into a temporary directory, so you have a clean slate. Then, create a skeleton ~/.bashrc that looks like this:

### Start of universal section ###
# Commands in this section will be executed by both interactive and
# non-interactive shells.
# Commands here must produce no output, or they will break commands
# like scp and rsync.

### End of universal section ###
[ -z "$PS1" ] && return
### Start of interactive section ###
# Commands in this section will be executed only by interactive shells.

### End of interactive section ###

Next, cd ~ if you’re not already in your home directory, then ln -s .bashrc .bash_login

Now you have a single customization file for all your shell sessions, called ~/.bashrc. You can copy in each command from your old customization files, placing them in the appropriate section according to whether you need them all the time, or just in shells that you’re typing in to.

If you really care about login shells

If for some reason you do want to have login shells behave differently from non-login, that’s pretty simple too. Instead of the ln -s command above, create the following ~/.bash_login file:

if [ -f ~/.bashrc ]; then
  source ~/.bashrc
fi
# Commands for login shells only go under here

Now you have two places customization commands may be placed, but you get the option of having login-specific stuff.

Dealing with multiple systems

Another trick I use is to examine the host name of the machine. This lets me use the same .bashrc everywhere; my Mac’s .bashrc is the same as the one I use on my Linux box and the System z mainframe at work. Here’s the code:

if [ "$HOSTNAME" = "T41p" ]; then
  # Customizations specific to the ThinkPad laptop go in here
fi

You can use code like this in either the interactive or non-interactive section of the .bashrc above.

Since I know people find my web pages while searching for information about Nikon scanners and Mac OS X, I’d like to offer the following endorsement:

The Ratoc FR1SX Ultra-SCSI to Firewire adaptor works perfectly with Mac OS X 10.3, and doesn’t need any drivers.

Plug the unit in to the back of your SCSI-based Nikon film scanner, and you suddenly have a Firewire-based Nikon film scanner. This can then be used with Ed Hamrick’s excellent VueScan software to fulfil all your scanning needs.

No adaptor drivers, no Nikon drivers, no Nikon software of any kind—so this solution should work fine with 10.4 / Tiger and other forthcoming OS X versions too.

Unlike USB options, the Firewire interface seems to result in scanning being just as fast and reliable as it was with SCSI.

RedPill 1.4.2 is out. Adds Tiger compatibility. I haven’t upgraded to Tiger myself yet, so let me know if you find any problems…

I was quite amused by the guy who wrote saying he was trying to get the source code to work under Tiger, and confessed that he didn’t know any C and could I help him? Right, yeah, I’ll do that.

Also, yes, I know Tiger doesn’t include StuffIt. I didn’t pack it using StuffIt, I packed it as a bzipped disk image with welcome dialog, but the guys at info-mac apparently have a policy that all such things must be unpacked and repacked with StuffIt.

Source code is at info-mac too.

Spent most of Sunday afternoon hacking on ElectricSheep to try and get it working on OS X again. One of the developers had e-mailed me asking if I could help. It turns out that the OS X version was developed as a ground-up reimplementation, which isn’t exactly ideal from a maintenance point of view. I’m trying to improve that a bit.

Yay! Mozilla now has a native OS X UI. It’s still kinda ugly in places (noteably the buttons top right), but it’s Aqua enough that I can stand to switch from IE at home.

Windows 2000 was better behaved today. It didn’t flake out until around 16:30, when IS helpfully set things up so I could log in to the domain at work. When I logged in, EXPLORER.EXE would crash with some horrible error, and the desktop would fail to appear. The solution turned out to be to blow away all my preferences and files for that account, and let Windows re-create it empty.

Just because Mac OS X has dynamically loadable kernel extension modules, that doesn’t mean you can move them while it’s running.

I just built my first functional Mac OS X Cocoa application, from scratch, without any help. By “functional”, I mean it has a window, menus, an input box and a button, does something notionally useful, and behaves like a proper Mac application. Not bad going considering a week ago I’d never seen a line of Objective-C in my life.

I have the Palm Desktop 4.0 beta for OS X working via my Keyspan USB adaptor, which needs a special driver. I was slightly nervous that the necessary kernel modifications would screw something up, but it seems to have gone OK. I have a usable Palm Desktop once more! Now all I need is PhotoShop for OS X

[I should point out that when I say “kernel modifications”, I don’t mean I went a-hacking. I just double-clicked an installer like for any other Mac application. The only difference is that I had to log in as admin so it could alter the OS kernel.]

I saw the new iMac today. It’s gorgeous, and I want one. The display is much better than on the iBook or even the TiBook.