Much has already been written, both about Leopard’s features and about the fact that we developers didn’t get to see the final build before it was released. Actually, even if we had been able to grab a copy of the final build before release, it wouldn’t have made that much difference really; if problems show up (as happened to my company this time around) in the final seed, or even in the GM if they provide it before the release, there really isn’t that much time to correct them before either Mac OS X or your apps need to ship.

In this case, the problem we’re seeing seems to be with the Leopard kernel, though it’s possible that it’s actually a disk firmware bug that’s being triggered more readily by Leopard than Tiger.

Anyway, as a result, we’ve had to join the rather humiliating position that Filemaker are in, by declaring our applications not fully compatible with Leopard. I say “not fully” because, unlike Filemaker, at least our customers can run our applications from a bootable CD, and since that bootable CD will contain Tiger, not Leopard, it’s really not as bad as it sounds.

Having griped a little, let me just say: I’ve installed Leopard on a few of my machines now, and it’s looking very nice indeed. Superficial first impressions are that, in spite of all the new UI glitz, Leopard is actually faster than Tiger. Which would make it the third update in a row where Mac OS X seemed to get faster, not slower (contrast that with Microsoft’s recent efforts).

As for the UI changes… well, broadly speaking I quite like them. I’m still not entirely sold on the squarer corners on the windows, though I’m already finding the ones on Tiger too rounded after only a few hours of using Leopard full-time. And I’m glad they toned down the extra shadows on the Dock a bit, though I’d have liked to have seen what it was like without them. As for folder icons… well, they are nice, but I understand the complaints from others that the badges for the system folders are too subtle.

Like it or loathe it, I’m sure we’ll all get used to the new UI, and in a couple of weeks’ time, Tiger will look dated.

Posted by alastair at 4:32 PM Digg It | Permalink | Comments (0) | TrackBacks (0)

We’ve just released iPartition 3. This version’s development, testing and even release seems to have dragged on and on; originally I’d hoped that we’d get it out much sooner, but in retrospect it isn’t surprising given the amount of work involved in some of the new features.

I should say that much of the credit for the new filesystem support (we now resize NTFS and FAT, as well as HFS+), not to mention the excellent work on supporting Boot Camp, belongs to my friend and colleague, Chris Suter (Chris, where’s your blog? You’ve been talking about starting one for ages), who some people might recognise from his sporadic presence on various Apple developer mailing lists. My work for this release has been mainly on the interface, though some of the FAT code is mine.

I shouldn’t minimise, though; a lot of work went into the interface, not least all the time I spent re-drawing various icons as vector graphics (I think I’m right in saying that all the icons visible in iPartition’s windows are now scalable vectors, and they continue to look pleasing to the eye even at high UI scale factors). We even flirted with using a scalable backdrop for the distribution disk image, but that doesn’t work on 10.3 so we decided to leave that for now.

The new UI should be more accessible than the old one was for people using screen readers and the like too; it certainly seems to work better in Voice Over. Plus I’m very proud of the new look pie chart; it uses space much more effectively in the window and is simply gorgeous to look at:

Somehow a static image doesn’t quite do it justice. But you can always download the demo and make yourself a disk image so you can play with it.

Of course, we’ve already had an e-mail to complain that the new features are such a small upgrade that it isn’t worth the time we’ve spent on them, never mind the upgrade price. You’d think it was just a case of five minutes work writing code to shell out to diskutil or something, as opposed to the reality, which is that writing filesystem related code is a hard, unforgiving slog. You can’t afford to make mistakes, but it’s complicated so you inevitably will anyway; testing is difficult at best, not to mention slow; and just to make life better, there are usually all sorts of idiosyncrasies that (a) users don’t appreciate, and (b) you have to deal with.

To give some idea, according to our version control system, I started the FAT code nearly two years ago now, and the NTFS code is nearly a year old itself. So this release is the culmination of all of that effort, from both me and Chris. We hope our customers like it. Time will tell.

Posted by alastair at 12:55 PM Digg It | Permalink | Comments (0) | TrackBacks (0)

The BBC continues to report on the wildfires in California. I’d just like to say that I hope all of the people I’ve met, not to mention those I’ve interacted with on-line (whether Coriolis Systems customers or otherwise) are OK, and that I hope the fires are brought under control soon.

Next to that, acquiring a dent in my car this morning seems positively inconsequential.

Posted by alastair at 4:56 PM Digg It | Permalink | Comments (0) | TrackBacks (0)

This morning, just as I was coming off the market roundabout at the junction of the A32 and A27 in Fareham, some idiot in a lorry drove into the side of my car. The roundabout there has three lanes, once of which goes off, so at the eastern exit there are two lanes, both of which go onto the A27. I was in the left-hand lane, in my MG. The lorry driver, on the roundabout, was in the right-most lane (for the benefit of those reading this outside the U.K., we drive on the left). As we came off the roundabout, he drove into the left hand lane, apparently ignorant of the fact that my car was alongside his vehicle.

The annoying thing is that I could see it happening, and all I could do about it was try to put my foot down hard to get out of the way. Braking wouldn’t have helped (instead of hitting my car towards the rear, he'd have hit the front of it), and doing nothing wasn’t really an option either given where we were (there are railings to the left of the left-hand lane… and I didn’t particular want to end up squashed between them and his lorry; on reflection, I may actually have had a lucky escape, though we weren’t travelling very fast at the time).

Anyway, my car got off quite lightly under the circumstances; the damage seems to be limited to a (rather awkward looking) dent in the driver’s side rear wheel-arch, plus some scraped paintwork. There didn’t seem to be any visible damage to the lorry; maybe some scraped paint on the front-left corner of the cab, but then that could easily have been there already. Particularly as the lorry in question seemed to have a couple of bits of broken indicator tied on with what looked like washing line.

Plus, I have a feeling from the looks of my inbox, that I have other problems to deal with today as well.

AAARGH!

Posted by alastair at 11:03 AM Digg It | Permalink | Comments (2) | TrackBacks (0)

Apparently there’s an SDK on the way.

I’m sure some commentators will now drone on about how Apple’s hand was forced, but I bet they were going to do this anyway.

Posted by alastair at 5:07 PM Digg It | Permalink | Comments (0) | TrackBacks (0)

From Daring Fireball:

Piracy

This is why it’s a mistake, a huge mistake, to call copyright infringement and bootlegging “piracy”.

Er, what?

Software pirates have long played up to the skull-and-crossbones image. I remember way back in the ’80s, there were groups with the word “Pirate” in their names (on the Atari ST, for instance, the Pompey Pirates). They were proud to be called “pirates”.

The whole phenomenon of people pretending to be offended at the use of words like “pirate” or “theft” in relation to copyright infringement is a recent development, and quite frankly it’s ridiculous. Nobody is actually offended by these terms; it’s just that one or two pro-piracy people have realised that “copyright infringement” sounds like the kind of law-breaking that nice people might engage in, whereas “piracy” and “theft” don’t.

The same people also realise that they have to make sure that a substantial proportion of the population is engaged in copyright theft, otherwise it might be practical to start prosecuting people for it. Currently you can only really do that for show, and you’ll never recover your costs.

Posted by alastair at 3:42 PM Digg It | Permalink | Comments (0) | TrackBacks (0)

MacWorld’s Christopher Breen has written an article pondering whether Apple is now on the wrong track.

I have to say, I agree with many of the points he raises, though I think it’s unfair to blame Apple for the ringtones problem (which I’m fairly certain has been imposed on them by the record companies—the same companies, incidentally, who continue to claim that “ripping” your own CDs is illegal).

And as for the iPhone “bricking” thing, I’m sorry Christopher, but you’re plain wrong about the legalities of it. Sure, in the U.S. the Copyright Office has blocked people from trying to use DMCA to protect against phone unlocking. But that does not mean that you, as an iPhone user, are within your rights to do it. It just means that Apple and AT&T cannot use that particular piece of legislation to sue you. They can still write into your contract terms that you may not unlock your phone, and if they’ve done that then the only way around it would be for you to demonstrate that those terms were illegal somehow. You might conceivably try to bring an anti-trust case, but to be honest I’d expect it to be knocked down on the basis that you were free to buy any other smartphone. Without doing that, you’ve breached the terms of your contract.

I also don’t think that Apple should be forced to spend time ensuring that unsupportable hacks will function correctly with their software updates. Plainly they did do some testing, but when it went wrong, what did you expect them to do? Actively support something that they are almost certainly contractually obliged not to? All they could do is warn customers that it might break their phones.

And yes, they could have displayed a warning up front, but they would probably have had to display it to all iPhone users (consider: how do you tell if an iPhone has been hacked, when you don’t know about or have copies of all available hacks, or the time to analyse them?). Warning everyone would have needlessly frightened lots of customers, and that’s a bad thing to do.

As for whether there is a provision for “undoing the damage”, there is. If you pay Apple, they will provide you with another iPhone. Put another way, the cost of rectifying the damage is the same as the cost of a new iPhone, so buy a new iPhone.

This doesn’t even seem unreasonable. In general, to fix an arbitrary problem on a UNIX-based system (or a Windows-based system, for that matter), you need an expert. Experts cost hundreds of dollars an hour. Buying a new iPhone is cheaper.

On the flip-side, should Apple allow people to write iPhone apps? Yes, but only once they are certain that the iPhone can run third-party apps securely (e.g. by running them in a sandbox). Otherwise there’s a risk of iPhone viruses, and we don’t want those.

Posted by alastair at 2:41 PM Digg It | Permalink | Comments (0) | TrackBacks (0)

MacWorld UK are running a quote from F-Secure’s Jarno Neimela, who says:

“The amount of technical information [available about the iPhone] makes it likely that sooner or later someone will create a worm or some other malware… This will create an interesting problem for the security field as the iPhone is currently a closed system and it’s not feasible to provide anti-virus or other third-party security solutions for it.”

Excuse me for pointing this out, but there is absolutely nothing to stop Apple from dealing with such a problem themselves, if they so desire, including—if necessary—providing their own anti-virus technology. There is simply no need for “third-party security solutions”.

My guess is that in such a circumstance Apple would simply push out updates via iTunes that removed the virus from phones and patched the vulnerability that it used to install itself. Even if an update has to wipe the phone completely to get rid of a virus, since users’ data is stored on their Macs or PCs, it only has to synchronise to return things to the way they were before.¹

Moreover, the same reasoning (about the amount of technical information) could be used about the Mac. Where are the hordes of Mac viruses? Oh, that’s right, there aren’t any.

Sure, some jerk will probably write one sooner or later, but the status quo is that there are none². Zip. Zilch. Nada. And there’s much more technical information available about the Mac than there is about the iPhone.

Posted by alastair at 3:14 PM Digg It | Permalink | Comments (4) | TrackBacks (0)