Solipsism Gradient

There’s been so many comments about Leopard over the weekend that I stopped reading – and there are too many of them that just repeat each other, too.

I’ve been running Leopard since the first seeds came out, and the last few have been really stable, especially the last one; I didn’t have to reboot it once in about a month.

The final release – 9A581 – was built on Oct. 12 but released to developers on Oct.26, the same day that it (theoretically) was released to users; some journalists got it earlier under embargo. In past major releases, the final build’s release date for developers was uneven – sometimes just a few days before, sometimes as much as a week after.

Buzz Andersen, a former Apple employee, wrote a very good post pointing out the difficulty of interpreting Apple’s actions from the outside. While I personally think Apple’s two-week delay in posting the final release for developers was unfortunate, I must point out that past releases leaked on the torrent sites in less than a day. If some developers won’t honor their NDAs, everybody will suffer for it.

Similarly there’s much controversy about stuff that got suddenly (or not-really-so-suddenly) taken out of the final release; 64-bit Carbon apps, ZFS support, Java 1.6, backing up over wireless are the ones that immediately come to mind. As usual, people are reading into that all sort of background motivations – Apple is following some Machiavellian scheme, or is completely stupid/clueless. I prefer to believe that they’re doing the best they can with their limited resources while trying to follow a multitude of small individual agendas. Ants carrying a large item into their nests come to mind…

For now, I’d just like to point out that, as in previous years, 10.5.1 will be out within 15 days, probably fixing at least one of those omissions. I think Apple made a good decision in, for the last month, concentrating on polishing existing features. Leopard is unusually smooth and “finished” for a .0 version.

On a personal note, and as I posted to the XRay Support Forum a few days ago, XRay 1.1 suffers from some problems in the final Leopard release. The most annoying is that the file browser doesn’t allow you XRay an item – it will crash.

I’m fully resolved to step up efforts to release XRay II, at least in public beta, as soon as other commitments allow. It will be Leopard-only and everybody who paid for XRay 1.x will get a free upgrade to the “standard” edition (there may be a “pro” edition, but I’m not sure yet).

One commitment which, unfortunately, is a great deal more pressing (literally!) is that I’ve contracted to write a book about “Programming Objective-C 2.0”. This also is specific for Leopard, and as you can imagine, deadlines are very short; ideally, of course, the book should be out today! But, the laws of physics and physiology permitting, it will be out as soon as possible. Watch this space for details.

While I haven’t had time to really look at, or comment on, Leopard yet, this article by Matt Legend Gemmell is must reading for Cocoa developers. Nice job.

Overnight, Apple’s changed the Leopard Developer Tools page to confirm officially that the tool formerly known as Xray is now called Instruments.

Well, while both names are certainly better than the prototype name (which, supposedly, was “PowerTrace”), I’m both relieved and worried by the change. When the name first came to my attention over a year ago, some Apple folks told me privately that I shouldn’t worry about any conflict with my own XRay utility (now being reincarnated as XRay II). Still, I hoped that the similarity might drive some clients my way, and I even linked from my own page to Apple’s, to avoid any confusion.

Now, this last-minute change is a also little worrying, since it’s probably a symptom of a cease-and-desist letter. This came up so suddenly that even the icon on the Apple site still uses an “x-ray machine” theme. I can’t find any larger Mac software company using any variation of “X-ray”, but who understands how lawyer’s minds work? It might even be a non-software company. Hopefully my new second-generation name will be non-conflicting enough to avoid any trouble.

Very interesting post over at the online photographer:

…Canon introduced three coupled tilt-shift lenses for the EOS system, a 24mm, a 45mm, and a 90mm.

…I was told that Canon expected to lose money at least on the 90mm, and that probably all three lenses would never earn back their development cost.

What? So why make them at all?

Because, I was told, the availability of the three tilt-shifts would serve as an enticement for pros thinking of switching systems from Canon’s main competitor. The company would never make any money on those specific products, but it would make money from all the other products those “switchers” would buy after they switched.

OK so far, but now read this:

Once, I ran into an even more fascinating phenomenon: a photographer who had switched to Canon because of the tilt-shift lenses, but who hadn’t actually bought any of the tilt-shift lenses!

What was that about? “I just like to know they’re there,” he told me, “so I can buy them if I want to.”

Does this sound familiar…?

Steve Jobs just said (I guess I should say, Real Steve Jobs, hehe) on his blog:

…We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February.

…Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. …we believe it is a step in the right direction.

This seems to indicate that the application installer – which will in all probability be iTunes – will check if the application is properly signed. Whether they’ll allow developer-signed apps is anybody’s guess, but I wouldn’t rely on it. (Signed apps is one of the 300 Leopard features, by the way. I’ll comment on the Leopard day announcement in a few days.)

I wrote two weeks ago:
Rainer Brockerhoff wrote:

Conclusions:

– the current generation of iPhone/iPod touch will remain closed forever, just like the first generations of iPods; (I was wrong there, and a good thing too!)

– an SDK is likely to come out only after everything (especially the hardware) has stabilized;

So the February OS X version will be the first one with stable, public APIs… meaning current apps, written to reverse-engineered specs, will probably have to be seriously rewritten.

Rainer Brockerhoff wrote:

– Apple is unlikely to invest efforts into implementing TrustZone in the current generation, unless Moorestown (or whatever else they might adopt in the future) has a similar security feature – and maybe not even then

Now I wonder how they’ll handle such a hypothetical future hardware migration… probably fat binaries, with the “other” executables being stripped out by iTunes when installing an app; this would be the most flexible without upping memory footprint on the phone side.

Update: Seems that Intel and ARM are collaborating on new TrustZone implementations… might that foreshadow TrustZone on Moorestown…?

Now, some people say this proves that Apple is listening to complaints and that they’re changing their original plans; on the contrary, I think this had been the plan all the time, but the Leopard delay also delayed the SDK. Regarding the timing of this announcement, this might be a trial balloon to see if they can minimize the inevitable profit-taking after next week’s earnings announcement. Hopefully that will happen.

Just saw this over at Amazon:

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.

…

Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use.

…Start, terminate, and monitor as many instances of your AMI as needed, using the web service APIs.

Pay for the instance-hours and bandwidth that you actually consume.

…Amazon EC2 passes on to you the financial benefits of Amazon’s scale. You pay a very low rate for the compute capacity you actually consume.

…etc.

History repeats itself… this is very close to what we used to operate with in my mainframe days. You punched out a job control deck and ran a job that used a virtualized instance of the OS. Later on you’d get billed by so many seconds of actual CPU time, I/O bandwidth, and storage. In fact, my M.Sc.-thesis-to-be (1975, I vaguely remember) was about implementing just such a billing system.

Been some time without a test, so here’s a brief one: What kind of blogger are you? My result:

Update: the test seems to be no longer there, sorry.

Drew Thaler on ZFS: a must read.

Update: response from MacJournals News. I regret not having time right now to look into ZFS pros and cons myself…

Update#2: Drew explains more.