In recent years Apple has started doing something that I regard as pretty dumb - tying versions of XCode to a particular system, and/or not supporting older XCode versions on newer systems. XCode 3.0 required Leopard, and I suspect that the next big XCode update will go the same way.

What’s even more annoying is that the distributed build system is tied to your system, architecture and xcode version. I can see why the version of the tool chain used by each node in a distributed build needs to match, but Apple should really spend some time making this stuff work a lot better.

The IDE should really be far more de-coupled from the tool chain, and I really ought to be able to participate in a shared build system running on a number of system versions (for that matter the IDE is a horrible monolithic lump which should really be broken down into smaller components and updated in a far more agile way, but that’s another topic).

The main reason why the Xcode thing is such an issue for me, is that it’s a really big barrier stopping me doing early testing of system updates. One way or another I’ve been getting pre-release systems from Apple for the last 20 years or so. Until fairly recently, I was very happy (keen, even) to live on the edge. Maybe not for alphas, but certainly by the time the system got to beta I’d typically install it and live on it for my main development machine. Crashes and glitches notwithstanding, I wanted to know what was coming, try it out, and give feedback on it whilst there was still time to change stuff.

Now, however, access to pre-release builds is next to useless for me. I simply can’t live on pre-release systems, since I immediately lose access to the other 5-10 macs that are normally happy to help out with my builds (and believe me, I need them to help compile Football Manager, which contains a lot of code!). For the amount of time & effort it takes to install a new system, it’s barely worth it just to click around for half an hour to see what’s changed, before switching back to my “real” system.

I can’t believe I’m the only person who has this problem, and it seems to me that the quality of the feedback that Apple receives must suffer as a consequence.

First day of the conference proper - and an eclectic mix of excellent sessions.

A lot of stuff wasn’t directly relevant to the day job, but as always with these events it’s fantastic to just get the time & space to think about the issues, and to be pointed in some new directions. What wasn’t relevant today may well become the future.

Plus, of course, the ability to simply meet and hang out with a bunch of like-minded geeks is priceless.

I’m at the NSConference this week, which is a UK-based get together of Mac and iPhone developers.

Today was workshop day, and I attended an excellent iPhone session given by Bill Dudney - great work Bill.

Hopefully this conference will become an annual event, so if you didn’t make it along this year but are interested in attending in the future, make sure that you let Scotty and Tim (the organisers) know!

Come home. Drink two generous vodka & cokes whilst washing up & chatting to Caroline. Decide to “fix” one or two minor issues with the hackintosh.

Use Kext Helper to attempt to re-install some kernel extensions that I suspected hadn’t been installed properly. Reboot said hackintosh.

Experience the “no smoking” / grey boot screen. Experience extreme fear/rage/wish-that-one-had-got-time-machine-working-on-the-eee.

Spend rest of night figuring out what went wrong and how to fix it.

In the end I had to bootstrap off the install cd I used for the original install, then boot into an iDebeb install image I had on a DVD, then use the terminal to copy back an original Extensions folder taken from my MacBookPro. Arse!

On the plus side, I think I now have a better understanding of what’s going on under the hood. On the minus side, it’s 3.38 in the morning, and I’m now back to where I started.

I’m using the original WiFi card in my eee, which does not have native out-of-the-box support from OS X.

Luckily, some third-party “drivers” are available from RALink, makers of the card.

The word drivers was in quotes in that last sentence because although this software allows use of the WiFi card, it doesn’t really supply a Mac OS X driver in the strictest sense of the word. A real driver would just invisibly do its job, allowing you to connect to wireless networks with the normal user interface - you wouldn’t really know that it was there.

The RALink software, in contrast, is rather painful, and a real eyesore. It consists of a custom application which you have to launch when you log in, and which opens a single window which you can’t resize or close.

This window has a tabbed interface with a great deal of random clutter on it that almost nobody will ever care about. The layout is a real dog’s dinner, and looks like it was probably created by a programmer who isn’t used to design visual UI of any kind, let alone for a Mac.

In amongst this is a list of the visible networks in range, and a (confusing) interface allowing you to join one. By default the software does not remember the password for a network, forcing you to re-enter it each time. However, there is a mechanism on a different tab which allows you to save “profiles”, which do save your password to a particular network. You can have multiple profiles, but only one is active at a given time, and you have to choose manually.

All in all, this software is a bit of a mess, but I suppose we should be grateful that it exists and that it has been made freely available. Personally I’d like to see RALink release it as open source - at the very least that would allow someone who knows what they are doing to clean up the UI.

In the meantime, I may upgrade my wireless card, just to get rid of this software. Which is a bit of a shame, since the built in card seems to actually work perfectly well.