Wednesday, June 24, 2009

Eclipse Galileo released!

References

Today marks the arrival of the Eclipse 3.5 (Galileo) release train, bringing in with it a year's worth of accumulated goodness. Ian Bull has already provided his top ten list, but as a Mac developer one of the most important things to me is the Cocoa support.

For those that don't know, the underlying APIs on Macs have been based on two different concepts; the object-oriented framework that once was Nextstep (called Cocoa in Mac OS X) and the older legacy C-based API from Mac OS 9 days (called Carbon). Although both can be used to write applications, interact with the same (visual) widgets, and have much the same access, ever since Mac OS X was released the future has always been Cocoa. (The iPhone has a predominantly Cocoa based runtime as well.)

When the Eclipse Mac port kicked off (which was by and large when I became involved with the Eclipse community, having only seen/used Eclipse in an IBM-related position prior to that), the decision was made to go down the Carbon route. In part, this was due to the familiarity of the APIs with respect to other UI toolkits available, and also lack of exposure to Objective-C in general. Apple has kept updating Carbon in subsequent Mac OS X refreshes, but the pace of development has mainly been in the Cocoa space. And given that the Carbon libraries were predominantly 32-bit, the cost of upgrading/maintaining those in a 64-bit world were too high; Apple has explicitly said that Cocoa is the 64-bit way of the future.

Other high-profile apps have been based on Carbon for some time - QuickTime and Finder are two such examples. But although Mac OS X has been able to use more than 4G of memory (by creating multiple 4G slices where necessary), it isn't until Snow Leopard that the Cocoa applications have had native 64-bit access across the board. Snow Leopard might be the last Apple OS that will run on 32-bit machines; if it weren't for the fact that some of the initial Mac Minis were 32-bit, Snow Leopard probably would have had a 64-bit only moniker as well.

Apple has also made sure Java developers move forwards with 64-bit support, though arguably there's not much for Java developers to do/care, since the JVM handles all the abstractions for non-native code. The latest Java 6 is only available on 64-bit Intel Macs, which may have performance improvements over its Java 5 counterpart (which has 64-bit and 32-bit mode).

This brings us back to Eclipse on the Mac. There are now three downloads you can get:

  • carbon.tgz - the older, Carbon-based UI which should run on PPC and Intel machines but only be capable of Java 5 32-bit access
  • cocoa.tgz - the newer API, able to run on PPC and Intel machines, also only capable of 32-bit access
  • cocoa_x86-64.tgz - only available for Intel 64 bit platforms and 64-bit JVMs (Java 5 or Java 6)

To configure which JVM you use by default, you need to run /Applications/Utilities/Java Preferences.app which specifies the order in which it tries to launch a JVM. If you download the x86_64 package, you need to make sure that Java 6 (64-bit) or Java 6 (64-bit) is at the top of the list. Otherwise you'll need to ensure that Java 5 (32-bit) is at the top of the list.

Tuesday, June 23, 2009

iPhone now fails to login to T-Mobile hotspot

References

Since upgrading my iPhone firmware to 3.0, I find that I'm no longer able to log into my local T-Mobile hotspot (from Virgin Trains, no less). Unfortunately, getting authorised requires you to click on a button (which presumably runs some JavaScript) to take you to another page, where you have to click a button (more JavaScript) before finally letting you access the internet without any further ado.

Whilst Apple's approach (of trying to access http://www.apple.com) is a neat one, they presuppose that the page you're taken to is some kind of form entry page which has a single login button. Neither of these assumptions hold for the T-Mobile hotspot, and so the only thing you can do is press Cancel. However, if you do that - you're booted off the hotspot and WiFi connection is dropped.

Whilst the approach is a good one, it's clear this hasn't had much testing. For example, what happens if the password is wrong? Or what happens if there's a two-page process that you need to fill in? Due to the secrecy behind the development of the firmware, it's clear that none of these edge cases has been considered.

Which is a shame, really, because the idea is a good one. Now, if only it worked ...

Safari, Acid and the iPhone

References

Safari has had a successful run at winning the Acid 2 race as well as winning Acid 3, so it comes as a bit of a surprise to note that the iPhone, which is also based on WebKit, passes neither of them.

Whilst the Acid 3 compliance has gone up from OS 2.2 (with a 73% pass rate) to OS 3.0 (with a 97% pass rate), it's a little unclear why the same isn't also true of the desktop-based WebKit, which easily gets 100% in the recent 4.0 builds, upon which the iPhone WebKit is based.

Acide2 failure Acid3 failure

Monday, June 22, 2009

Seeya! Yahoo!

References

Leaving Yahoo! behind is a sad day in a way, like leaving a girlfriend with whom it's just not working out. Let's still be friends, you say, in the knowledge that the chances of a reconciliation are slim to non existent.

Having been using the free web since the early days, and starting out with hotmail.com (and even bigfoot.com) mail addresses, some of which may still work, Yahoo! became the default mail address (and web account) I used for several reasons:

  • Yahoo! Games allowed me to play bridge, when I should have been working on my MSc
  • Yahoo! Messenger was the first (decent) replacement for a talk (and follow ons ntalk and ytalk) chat client across the internet at large
  • Yahoo! Mail wasn't owned by Microsoft (which was a good reason for giving up on Hotmail in itself). Oh, the spam filtering was pretty good in comparison to the junk that came through in Hotmail's inbox.

Sadly, though, as with much of life, things tended to go flat. Yahoo! messenger managed to go from a market leader to an also-ran just by being gratuitously closed (even to the extent of intentionally breaking third-party applications like Adium). At the same time, I found less and less time to play bridge (both in the virtual and real world) and whilst I've never really had a problem with Yahoo! Mail, it has remained pretty stubborn in terms of interfacing with the outside world.

The game changer, as with much else in the internet, was the arrival of the Google services. Google Mail was the starting point, and Google Talk's use of XMPP became instantly available in products like iChat. I never ran Yahoo! Messenger again. Oh, there's been some Mac-based clients for Yahoo!, and open apps like Adium have fought the cat-and-mouse battle between the protocol and the application, but ultimately it was Yahoo!'s closed-ness that pushed me away. In fact, for a long time, the only advantage of Yahoo! mail over Google mail was that the former could open multiple windows(or tabs) which made for much easier reading of the Eclipse-related bugs that came my way.

Ultimately, it was Yahoo!'s change of mail to their 'new-and-improved' beta, which initially one could opt out for but recently became the default default to which there was no return. So my one reason for using Yahoo! mail over Google mail was finally vanquished, and I changed my Eclipse bugzilla account to use my Google mail instead of my Yahoo mail.

Frustratingly, my iPhone has had perfect ability to interact with my Yahoo! mail. For whatever reason, Yahoo! decided to partner with Apple for the launch of the iPhone (push) mail services, which meant one-click setup of Yahoo! mail was available from my iPhone. Read messages could be used to sync what had been already read/processed, forwarded to others, and so on.

Except I can't access it from my Mail.app desktop. Why not? Because Yahoo! doesn't include an IMAP connection. Or rather, they do, as long as you want to pay for it. Why I can access my mail from one device, but not use it from another device, completely eludes me. I can access my Gmail fine from both my Mail.app, my iPhone, and when I'm not able to use either of them, a web-based interface as well. I've got triple-play access to mail. The same is also true of iChat/web-chat, and even (to a lesser extent) on the iPhone via Google's gTalk for iPhone page (and if you unlock it, via background apps as well).

Now, don't get me wrong. There's nothing wrong with Yahoo! mail itself, and it might suit a certain kind of person still. But it wove its own seeds of destruction a long time ago (longer ago, even, than the ill-fated decision to go/no-go/maybe-go Microsoft) by providing a one-size-fits-nobody approach to their services. After all, keeping customers hemmed in never really succeeded; instead, make it an open, transparent place and you get the customers. In this case, customers are eyeballs to the Google advertising universe, and even though I use my Mail.app client (and iPhone app client) a lot, I still do visit the Gmail website probably several times a week; a lot more than I now go to Yahoo! mail.

So, farewell, Yahoo! mail. It's not me, it's you. I hope you grow gracefully older, and I'll always remember the time we had together, and I wish you all the best.

Saved by ZFS (twice)

References

Saddened as I am with zfs' departure from Snow Leopard, I still use it for my day-to-day fileserving needs (and if ZFS isn't available in the future, then I'm quite happy in not upgrading my server just yet). It's come to my aid in a couple of ways recently which are worth mentioning in praise.

A few weeks ago, owing to an NFS networking problem, my login.keychain suddenly disappeared. I have no idea particularly why, only that when I logged in one day I discovered that all my passwords and personal secure data had disappeared. Now, had I not had the luxury of backups or something like Time Machine to be able to reacquire the data, I'd have been stumped. Fortunately, I have an automated ZFS snapshot job running which allows me to generate a list of snapshots on an hourly, daily, and weekly basis. Unfortunately, the .zfs support isn't available in ZFS-119, but I can still mount one of my previous snapshots (using zfs clone) and then peruse the contents of my filesystem hours or days into the past. All I needed to do was copy the contents of the previous file from last night's daily backup, and I'm good to go again.

The second time was over the weekend, when I came down to hear my file server performing the click of death. I bought a Iomega Ultramax almost exactly a year ago (14 months, in fact) and the Segate Barracuda 7200.10 inside was making some strange noises. The disk wouldn't mount, and therefore the pool was off-line. Now, I've had some issues with the Iomega before (like not powering on after a power failure and being noisier than a leaf blower in a library) but I've given it the benefit of the doubt. And in any case, I had mirrored the drives, so that if one failed, then the other would still be available.

Unfortunately, the single point of failure was the Iomega unit itself. For whatever reason, it wasn't happy with the Seagate and was executing the clicks (possibly after a self-contained timer has said "the warranty has run out"). I bought an external SATA adapter from Maplin (actually, good quality) and hooked up the internal drives; both checked out OK although I think one was on the way out. Fortunately, either drive was mountable by ZFS although ZFS was helpfully indicating that one of them was starting to suffer from checksum errors (go ZFS!).

Long story short; I had to buy some more hard drives. This time, instead of going for a fan-assisted needs-a-separate-power-unit job, I plumped for a couple of bus-powered 2.5" devices. These work on either USB or Firewire (with my preferred way being Firewire) and have the advantage that they come on with the machine and off with it. So if there's a power failure in the future, my pool will come back up with the system.

Moving data across was a doddle; having mounted one drive in the pool, ZFS noted that the pool was still operational but with degraded capability. All I needed to do was execute zpool replace Pool oldDisk newDisk and it set about reslivering the disks. A few hours later, and it was time to execute zpool replace Pool workingDisk newOtherDisk and my pool is now running on 2009 disks, which hopefully have a longer shelf life than the other ones. Oh, and did I mention? ZFS doesn't care that they're the same size. It just cares that it has enough space to be able to punt the data from one to another. In fact, if I'd wanted to make my pool bigger at this point, I would have been able to replace them with larger disks, and it would work (actually, I replaced them with the same size owing to what I could get my hands on late on a Sunday afternoon). Alternatively, I could add more spindles to the pool which would make up for the slower rotational speed of the 2.5" disks.

So, ZFS has come to my rescue twice this month. It's a real shame that we won't see it by default in Snow Leopard, but hopefully it's been moved sideways rather than ejected completely, and we'll see new binaries coming out after Snow Leopard has hit the shelves.

Wednesday, June 17, 2009

iPhone software now available!

References

Fleetingly for a minute, the iPhone software now appears to be available:

The iPod firmware images are also available, but with a protected:: URL, whatever that means. I assume it's a HTTP behind the covers too ...

Monday, June 15, 2009

Java Security update for Mac OS X released

References

From the “about frigging time” department, Apple have just released their security fixes for Java (as reported previously). All users should upgrade.

Sunday, June 14, 2009

Russian Roulette - App Store Rejection policy

References

Is it me, or is getting an application into the App Store nothing more than a random Russian roulette? There's certainly a back-end auto-rejection mechanism which is applied through point-n-click rather than any specific policy. And once you're on the rejection train, then there's nothing that seems to get you back on track. Indeed, there's no appeal - any mails that you send back attempting to get clarification are met with a stony silence. All you can do is resubmit, wait a week, and then get a cloned mail rejection a week later.

Application screenshot

Here's the app I'm working on. It allows you to discover hosts on your local network through a GUI, then add them to your favourites so that you can wake them up when they go to sleep. OK, it's not the first wake-on-lan app in the store, but it does auto-detect what the machines are and give you nice little images showing you whether they're awake or not. However, Apple don't like this because of use of "Apple logo or Apple copyright images". Which is largely bunk, because they're images I took myself; ergo, I own the copyright to them. The first version we submitted did have a top-view of the Mac Mini, which includes a blobbed version of the Apple logo, so we scrubbed it and re-sent it to have it rejected for exactly the same reason.

Construction of images (copyright 2009 Alex Blewitt)

So Apple is essentially claiming that we're using the logo (we're not, we removed it from the images, although the screenshot at the top does show an older version with it on the mini) or Apple graphics (we're not, we used our own photos). It's really unclear as to what they think is still wrong - but the auto-rejection notice contains no level of detail that can be used to substantiate what the problem is, nor how to fix it. I feel the submission policy is a bit like the blind man solving a rubik's cube (from the great Weird Al film UHF):

So, back to the drawing board. Try again, submit again, wait for rejection letter, rinse and repeat.

Oh noes! The Twitpocalypse is upon us!

References

OK, so it's not very exciting. The Twitpocalypse has been and gone, the world hasn't ended, and life goes on.

The Twitpocalypse is caused by the fact that Twitter identifies its tweets by a numeric identifier, and recently the number of tweets posted exceeded the bound of SInt32, or 2^31-1 (2147483647). Programs written with the assumption of a SInt32 range (including my preferred iPhone client, Twitterific) started to fail on Saturday afternoon. This highlights a couple of interesting points:

  • Plan Ahead. Like the Y2K bug, this was predicted relatively well in advance, and was going to happen sooner (or later). Filesystems like ZFS use a 128-bit identifier to avoid out-of-range identifiers as storage grows in the future. 64-bit systems allow access of a massive 17MTb capacity of memory (though in practice, that's not likely to be met soon). But at the lower end, 4G is a relatively near target, and even some laptops can use more than this limit.
  • Getting apps into the AppStore is harder than a camel through the eye of a needle. The bug was fixed pretty quickly, but it's sitting in the Apple Random Rejection Queue waiting for someone to hit the button. It's not great for an app to exist in this state - and what happens if a more serious bug (like a security bug) exists in an application? How long might Apple iPhone customers be vulnerable before Apple accepts a security patch?

Whilst I doubt this is universal (or that there are other iPhone Twitter clients that exist that may suffer similar afflictions) this highlights an important point that the App Store process is a roadblock in the event of external factors impacting one (or more) programs that have no control about when the update gets issued.

Tuesday, June 09, 2009

Farewell, ZFS, we hardly knew ye ...

Readers of my blog may know that I'm interested in ZFS, Sun's “next generation file system” including its Mac port (including making binaries available for the Mac port from zfs.macosforge.org). I currently run my home file server off of an Iomega Ultramax, and it's served me well (including the ability to recover files that accidentally got corrupted recently).

I'd been looking forward to ZFS on Snow Leopard, mainly because the supply of bits to the aforementioned ZFS project had dried up. It even had a mention on the Tech Specs page, as the screenshots show.

Sadly, these have since disappeared from the main server specs site; though if you look quickly, you might be able to see them at a regional mirror (such as www.apple.com/de) – you'll need to look quick, as, like an ex-girlfriend, they'll be updated to erase any mention of ZFS ever having existed.

Now you see it ... Now you don't ...

Does this mean the future is HFS? Well, I doubt it – even with the Oracle acquisition towering over Sun's future, like the sword of Damocles, ZFS is still a true next-generation file system and I expect will make an appearance at some future point. However, I suspect confidence in the Mac port (or the kernel adaptations required) weren't up to scratch, and so rather than advertise something and then pull it, they're canning the marketing material in advance. It's worth noting that even at this stage, the feature list is possibly still subject to amendments – but the chances of ZFS making it into the gold release are pretty unlikely. And given Apple's past support for updates to ZFS in the kernel (i.e. nothing) the chances that it'll make it in to a subsequent point release of Snow Leopard are pretty slim.

Wednesday, June 03, 2009

What is the point of Apple's binary plist format?

When Apple created the plist format, it was as a drop-in replacement of the Next-style property lists (as emitted from the NetInfo tools) which were a kind of JSON-like format. Much ado was made at the time that they weren't “proper” XML formats, since the data encoded was an ordered set of typed information rather than information. On the plus side, the schema for plists has remained unchanged for pretty much ever, and all applications use it (for storing their name and version, if nothing else).

Then, in not so early days, Apple released plutil whose only purpose in life was to convert between an XML representation of the file (good, human readable) into an opaque binary format (aka 'binary1'). The suggested rationale behind this was to reduce disk space; though it's quite possible that by storing a set of data-type limited forms in a transparent manner that the deserialisation process might be faster (no entities to worry about, etc).

The problem is that there are better ways of solving the problem, at least from a space-saving perspective. XML files tend to GZip quite well, especially when they're repetitive (as property lists often are), and the resulting space is often much less than the equivalent binary XML form. As a test, I looked at /System/Library/CoreServices/backupd.bundle/Contents/Resources/System.plist, which takes up a whopping 1.1Mb of space on disk as an unadulterated XML file, and piped it through the plutil as above. The resulting file came down to 919K; a saving, but not a noticable one. In fact, the reason for this poor ratio is that the majority of the entries in this file are Strings, and these aren't compressed at all by the plutil binary format. In fact, quite a lot of those Strings are repetitive as well, being as this file lists all the locations that backupd is (or isn't) supposed to back up.

As a test, I piped the original, uncompressed file, through gzip -9, and it resulted in a 105K file. That's almost the size of the saving that the binary1 format came up with. Now, load-time of the plist might be a valid factor to take into consideration (and it is quite possible that the binary format helps here) but consider that the slowest part in a computer system - particularly one with more than one core - is the disk. Loading a 105K file off disk is almost certainly faster than a 919K file, to the extent that you could do whatever you wanted in that time with compression or decompression (and still not have to do any work at the other end). For smaller files (those measured in single or tens of K) the difference might not be noticeable, but it's certainly a candidate for testing out to see what is faster/slower for loading.

The interesting thing is then the performance on more constrained devices, like the iPhone. Being able to shrink an installed file size down certainly helps reduce the delivery; but what about the runtime characteristics, not to mention, ease of loading? Stay tuned to find out.

Tuesday, June 02, 2009

Review of MacBook Pro (Late 2008)

Although no new MacBook hardware is likely to be announced at WWDC, I've also had a Write review of MacBook Pro TODO item on my list for a while, so time to get it out of the way ...

I waved goodbye to my final G4 Mac laptop when (believe it or not) the end of the (non-magnetic) power cable broke off and got trapped in the power charging port of my PowerBook. The computer, disk, screen, keyboard etc. was all fine; but I couldn't get charge into the laptop, so it was a brick. All for the cost of a 10¢ computer part. That's not the first time it had happened, either – an older power adapter had done the same thing (but I'd managed to fish it out and replace the adaptor the previous time). So, I ended up with a MacBook Pro with a 128Gb SSD and 4Gb of RAM. Here's what I think.

This is probably the worst Apple laptop I've owned, and I've owned them since the early Mac OS X 10.0 days (the original TiBook was my first foray into Apple hardware, having been on NeXT systems beforehand), and I've been through the TiBook, PowerBook 1.5, PowerBook 1.67 and now MacBook Pro (Fall 2008) models. The fact that it's an Intel machine isn't really an advantage/disadvantage to me (other than 10.6 will be able to run on it) but it is the worst of the lot so far.

Firstly, I've always bought Matte screens; and for a very good reason. Glossy screens may look sexy in the adverts where you see the reflection as it rotates around the centre, but the reality is that they also reflect in real life as well. I'm sitting here with the Sun streaming in through the window, and the reflections are obvious and intrusive. Unless Apple are planning to come out with an iMirror app, I can't really see why Glossy screens are the only way – unless the cynic in me is right, and it's just a cost-saving measure to prevent having two types of screens manufactured. His Steveness probably works in a office with no Windows, after all ...

Secondly, the keyboard is crap. The all-in-one aluminium body means that instead of the keyboard being a self-sealed unit that sits atop the macbook, the keyboard in the MacBook Pro ‘pokes through’ the cut-out aluminium holes. What this means is each key is basically a mini window to the hardware underneath (and why there's so much space between the keys) but where it really shines is the under-keyboard lighting. On the old PowerBook, the keyboard lighting was a graceful affair, with each letter lighting up as light demanded. With the new MacBook Pro, the keys light up, but there's an insane amount of light spillage from under the keys, and unless you're working directly overhead the keyboard each key has a halo of light to distract you.

Thirdly, whilst the machine feels solid, it also feels heavy. I think that it's technically lighter than the old PowerBook was, but the screen is a lot heavier (all that glass) which means the screen isn't structurally as sound as the previous one, especially when carried one-handed. It's very easy to pick it up one-handed and have the screen bend over backwards; so far, it's not been damaged but it's only a matter of time.

Fourthly, the design of the ports on one side leads a lot to be desired. For the previous PowerBook, the external monitor cable (usually the thickest of the lot) was right at the back. Now, the display cable (small socket) lies about half-way down one side. And typically, the monitor cable goes backwards whilst USB cables go forwards (to mice etc.). Aesthetics have a lot to blame here; to get the ever-decreasing-size of ports, the monitor is now in a completely different place. Perhaps we'd be in a better position if the laptop used a decent DVI adapter like before, and so the connector is at the back.

Fifthly, the hinge of the MacBook Pro is black. Notionally, that's to fit in with the black border of the screen. However, when the laptop is closed, there's an obnoxious black edge to the hinge. None of the previous Apple laptops look ugly when closed; the MacBook Pro is the first example of its kind.

Sixthly, the trackpad is annoyingly loud. I used to use tap-to-select for mouse clicks, but it's pretty tricky to use the tap-to-select without generating a loud click. Not good for late night coding sessions.

Seventhly (and lastly), the screen release indentation on the front of the lid has really sharp edges. Try one in an Apple store sometime - you can practically cut yourself on it.

So all in all, I wish I'd been able to stay with my old PowerBook. However, Intel is the way forward (as is 10.6) so the new laptop will allow me to achieve both. But I can't help but feel that the current unibody MacBook Pro is a lesser rival to all of its previous generation devices.

Review of iPhone 3G

With WWDC 2009 just around the corner, and write a review of iPhone 3G on my TODO list, if I don't write something this week then it'll be outdated before I even write this. So without further ado, the highly belated iPhone 3G review ...

Having first purchased an original iPhone (for use unlocked on Orange), the changes between the iPhone and iPhone 3G are both noticeable and gave me an opportunity to test them side-by-side. The differences are both cosmetic, functional and not always an upgrade.

In what looks like a continuing trend, the iPhone 3G's shape is subtly different from the former. Whilst the former version had a flat back, the newer has a rounded back. This results in thinner edges but a fatter middle. Opinion is divided on what 'feels' better, but undoubtably the feel of the full-metal back versus tacky plastic back is noticeable either way around. The iPhone 3G thus ends up feeling cheaper, if not slightly more comfortable, to hold. A cycnic might observe that it is also an excuse for Apple to sell more docks, since the newer model doesn't fit the older docks without the use of some kind of Dremmel tool to file it down.

The speaker/microphone is also different – not necessarily in a good way – between the models. The original has a set of tightly drilled spaces into the casing (which mated up into equivalently positioned spaces in the dock) whereas the latter has a bigger case incision and a wire mesh internally. The end result is that you can end up with more fluff buildup into the new iPhone 3G speaker/microphone holes than the original generation. Aesthetically, they don't look as good either. Perhaps the reason was to support better speakerphone operation (which the first didn't have at first; though a software upgrade might have added later).

The rounded back also has its problems with working flat on a desk. The old model was sturdy and you could type on it flat; the new model really doesn't work when flat on a desk if you want to press buttons. About the only good thing you can say about the back is that the bluetooth signal, when horizontal, was absolutely pants with the old iPhone model (due to interference with the metal casing). It works fine if held in portrait mode, but clipped to a belt in landscape mode made the bluetooth headset drop out much of the time. The newer iPhone 3G, due to its lack of metal back, doesn't have this problem. So it's good that the newer model (allegedly) will have a matt or rubberised back; not metal, but not cheap plastic either. We shall see.

The screen of the newer model is decidedly jaundiced, with a yellow tint obvious when holding up the two models next to each other. Although not obvious if you've only ever held one, the colour reproduction on the first model was much closer to reality than what's shown on the iPhone 3G. I suspect an original manufacturing fault turned into a marketing ploy, and it wouldn't surprise me if the new iPhone will have a slightly cooler tint with some kind of marketing gumph like "Now more accurate colours!" thrown into the StevePhilnote.

What about the other new features of the iPhone 3G? Well, the GPS is really handy. You wouldn't leave it on all the time (at least, you wouldn't unless you had a charger with you at all times) but for the periods in which you want to use it, it works great. Rambling off the beaten track, it'll tell you where you are in the world, and even if you're off the (Milton Keynes) grid, you can still use satellite maps to find out where you are and where to go. Clearly this is useful as long as you have a mobile signal, but apps exist which can track your path even in the absence of an internet connection to download maps. In addition, the iPhone's GPS combined with (lackluster) camera brought geotagged photos to a wider audience than previously, and indirectly ensured that iPhoto support for geotagged photos wasn't far behind. Whether the new iPhone will get a magnetometer for using as a compass direction is an interesting idea; it's got much less use than the GPS has, but perhaps could be used in conjunction with the location services to extend the accuracy of the GPS, but you could also imagine treasure-hunt applications that take your location into advantage with your direction “take five steps North ...”

Lastly, the all-new 3G part of the iPhone 3G. Maybe other experiences from elsewhere in the world differ, but in the UK with O2, the 3G is a complete waste of time and battery power. Yes, the 3G is faster than 2G when you're outside or standing next to a transmitting tower. However, inside buildings, paper bags, or even pockets, the 3G signal is patchy. There have even been instances where telephone operators have installed in-building repeaters in order to maintain 3G signalling in key locations (read: important customers). For me, if I used 3G, the signal was so weak that it ping-ponged back and forth between 3G and 2G. Worse, if I had an incoming call but 3G was one bar, then the network just routed it straight through to voicemail even though I allegedly had a 3G connection and it was on in front of me. Lastly, and this is probably a benefit to me due to the location that I work, the WiFi connectivity around here is pretty comprehensive - I can walk into a Pret, Starbucks or even the cloud and get a WiFi signal which is faster and lower battery consumption than a 3G network is. Even the train I'm typing on has a WiFi network on it. When I'm outside WiFi range, the 2G signal is acceptable; and it has the added advantage of being able to receive/make phone calls. Given that my iPhone is, well, a phone first (and a PDA second/web browser third) being able to use it as a phone is a higher priority than the 3G network utilisation. Partially, this is a problem with the O2 3G network (combined with working in a densely populated city where the signals block 3G and living in a more sparsely populated city where the 3G towers are way off in the distance) but given the inherent problems, I turned off 3G almost as soon as I got the phone and didn't look back. (Settings > General > Network > Enable 3G if you want to do the same.) So, even if the new version of the iPhone has HSPDA downlinks, I think the network support is likely to be as good (bad?) as it currently is, and therefore on its own, not a big leap.

Niggles aside, the iPhone and iPhone 3G are still the best phones I've used, and the ability to run applications (whether a twatter client, games or even my own creations) means that even at home, my iPhone probably gets more use as a sofa-browser than any other device I've owned before. The new iPhone can't really go wrong, and whilst minor updates (memory, processor, HSPDA) are pretty much guaranteed, the phone will still be much the same phone as before. iPhone OS 3.0, likely to be released at the same time the new iPhone will be later in the year, will add some missing features like cut'n'paste. But even without c'n'p, the iPhone is still a great platform and telecommunications device.