I think I must be looking forward to Daniel's vacation nearly as much as he is himself, so I can get off this bus, but that time isn't here yet.
In the 5th installment in his series on myths about Snow Leopard Mr. Dilger addresses the notion that Snow Leopard abandons Carbon.
Carbon is the component of Mac OS X which derives from what the Mac OS was before it was combined with NEXTSTEP cum OpenStep. Loosely speaking, it was what was left after the 10% of Mac OS APIs that were incompatible with protected memory and preemptive multitasking were combed out, the remaining 90% were tuned up, and some of them were woven into lower level components that also served Cocoa, which derived from OpenStep. Carbon first appeared in Mac OS 8.6, allowing developers to get an early start on converting their applications so they would run on Mac OS X, when it was eventually released, and conversely apps written for Mac OS X using Carbon would also run on the final version of the classic Mac OS (9.2.2).
It was a good plan for a smooth transition, but it left Mac OS X with what were initially two distinct native GUIs, Carbon, derived from Mac OS, and Cocoa, derived from OpenStep, which complicated further development.
This state of affairs continued until Apple's WWDC 2007, during which it became evident that the Carbon GUI would not be making the jump from 32-bit to 64-bit computing, despite that some developers had already received advanced distributions of the developer tools including 64-bit Carbon, meaning it was a strategic decision rather than one driven by technical difficulties. Once the smoke cleared, it was also plain that 32-bit Carbon wasn't going away, certainly not in Leopard, and probably not for years to come.
(What follows is technically supposition or second-hand summation, since I'm not personally familiar with the APIs in question.)
By this time much of what had originally been Carbon had already been moved into or replaced by lower level components of Mac OS X, and were as much part of Cocoa as part of Carbon. Cocoa had also collected references to many or most of the remaining pieces of Carbon, so it had become relatively simple to use them from within a Cocoa application. What was left that was still identifiably Carbon, the part that wouldn't be making the 64-bit transition, was mainly GUI objects and drawing routines. These remain for compatibility with older software, as Cocoa's GUI support is considerably more sophisticated.
The future is Cocoa, but that doesn't mean your Carbon apps won't run on Snow Leopard, or even on Mac OS X 10.7, whenever it comes along.
Tuesday, June 24, 2008
Monday, June 23, 2008
under-the-hood enhancements in Snow Leopard
Once again Daniel Dilger provides those of us who weren't at WWDC '08 with more information than we already had, this time regarding new features in Mac OS X 10.6, a.k.a. Snow Leopard, most of which won't be evident to the end user, except in terms of peppier performance and more efficient disk usage.
He even manages to give Microsoft credit where credit is due, for pioneering Fast User Switching, XMLHttpRequest, and innovative text processing features in Word.
Based on what he adds to what was already generally known, I'd characterize Snow Leopard not just as a code refactoring, but as a build-out of features that already existed in some form, sometimes accomplished by moving feature support developed for a particular context into the system where it will be generally available, much as was done with Cover Flow in Leopard, and sometimes by fleshing out support that already existed in skeletal form. Whatever feels half-finished in Leopard should be ready for prime time in Snow Leopard.
He even manages to give Microsoft credit where credit is due, for pioneering Fast User Switching, XMLHttpRequest, and innovative text processing features in Word.
Based on what he adds to what was already generally known, I'd characterize Snow Leopard not just as a code refactoring, but as a build-out of features that already existed in some form, sometimes accomplished by moving feature support developed for a particular context into the system where it will be generally available, much as was done with Cover Flow in Leopard, and sometimes by fleshing out support that already existed in skeletal form. Whatever feels half-finished in Leopard should be ready for prime time in Snow Leopard.
Saturday, June 21, 2008
Daniel and the Liars Den
Original title: "Daniel and the sycophants"
If you read RoughlyDrafted without keeping an eye peeled for irony, you might think Daniel Eran Dilger believes Microsoft is helplessly incompetent and incapable of surviving in the face of real competition.
While I suspect he thoroughly enjoys projecting that impression, I doubt he'd swear under oath to really believing it, at least not without caveats.
What I think is going on with him is that he just can't abide Microsoft's cheerleaders - the bloggers and columnists who persist in portraying Microsoft as being far more competent than it really is and who treat Apple's best efforts as being of no ultimate significance, except as they may eventually find their way into Windows - and that he's driven to respond in kind, with equal and opposite distortion.
Take this article, for example, in which he tasks The Street's Jim Cramer for attempting to weave FUD around Apple's prospects using trumped up concern over Steve Jobs' health, and the presumption that Apple would be lost without him. I particularly like this: "Apple desperately needs Jobs like a blazing forest fire needs a match."
There's also Dilger's series of articles addressing myths about Leopard, and now about Snow Leopard. He goes after this stuff with the ferocity of a wolverine and the tenacity of a badger.
If you read Dilger carefully, it becomes clear that sucking up to the hegemon is a hot-button issue for him (as in it's something you DON'T DO if you have a gram of integrity), and he's responding creatively.
Maybe he'll be a little mellower after he comes back from vacation.
If you read RoughlyDrafted without keeping an eye peeled for irony, you might think Daniel Eran Dilger believes Microsoft is helplessly incompetent and incapable of surviving in the face of real competition.
While I suspect he thoroughly enjoys projecting that impression, I doubt he'd swear under oath to really believing it, at least not without caveats.
What I think is going on with him is that he just can't abide Microsoft's cheerleaders - the bloggers and columnists who persist in portraying Microsoft as being far more competent than it really is and who treat Apple's best efforts as being of no ultimate significance, except as they may eventually find their way into Windows - and that he's driven to respond in kind, with equal and opposite distortion.
Take this article, for example, in which he tasks The Street's Jim Cramer for attempting to weave FUD around Apple's prospects using trumped up concern over Steve Jobs' health, and the presumption that Apple would be lost without him. I particularly like this: "Apple desperately needs Jobs like a blazing forest fire needs a match."
There's also Dilger's series of articles addressing myths about Leopard, and now about Snow Leopard. He goes after this stuff with the ferocity of a wolverine and the tenacity of a badger.
If you read Dilger carefully, it becomes clear that sucking up to the hegemon is a hot-button issue for him (as in it's something you DON'T DO if you have a gram of integrity), and he's responding creatively.
Maybe he'll be a little mellower after he comes back from vacation.
Friday, June 20, 2008
yet another OS (open secret): LLVM
While not exactly lying face-up on the table, neither is the fact that Apple has plans for LLVM very secret.
AppleInsider goes into some detail, explaining what LLVM is and where it fits into Apple's current development tools and products, and providing a hint of how that role might expand in the future.
AppleInsider goes into some detail, explaining what LLVM is and where it fits into Apple's current development tools and products, and providing a hint of how that role might expand in the future.
Thursday, June 19, 2008
the cards are (mostly) on the table
If Apple's direction seemed uncertain before WWDC '08, it no longer does. They may still (probably do) have some surprises in store, but the overall shape of their plans is coming into focus.
There are three businesses to which Apple is unshakably committed: Mac OS X and the full-blown Macintosh environment, the iPhone and the version of OS X shared by it and the iPod Touch, and iTunes media sales and distribution.
Each of these is an inclusive category, not just a specific set of current products. For instance, the Mac business includes Mac OS X Server and the Xserve, while the iTunes business includes the Apple TV. The iPhone business is likely to grow to include new Touch products which may or may not be phones, as well as becoming the conceptual home for the new MobileMe online service.
There's a lot of crossover and synergy between them, and new ideas are more likely to take root if they apply to at least two, or better yet to all three, but each has integrity in itself and could stand alone as an independent business.
That's a very strong position for Apple, and a very clear statement of who they perceive themselves to be at this point in time and what they intend to do over the near-to-mid term.
What they might do in the long term is a more open question, and is likely to be driven as much by match-ups between market opportunities and the company's core competencies as by any description of what businesses they're in.
There are three businesses to which Apple is unshakably committed: Mac OS X and the full-blown Macintosh environment, the iPhone and the version of OS X shared by it and the iPod Touch, and iTunes media sales and distribution.
Each of these is an inclusive category, not just a specific set of current products. For instance, the Mac business includes Mac OS X Server and the Xserve, while the iTunes business includes the Apple TV. The iPhone business is likely to grow to include new Touch products which may or may not be phones, as well as becoming the conceptual home for the new MobileMe online service.
There's a lot of crossover and synergy between them, and new ideas are more likely to take root if they apply to at least two, or better yet to all three, but each has integrity in itself and could stand alone as an independent business.
That's a very strong position for Apple, and a very clear statement of who they perceive themselves to be at this point in time and what they intend to do over the near-to-mid term.
What they might do in the long term is a more open question, and is likely to be driven as much by match-ups between market opportunities and the company's core competencies as by any description of what businesses they're in.
Tuesday, June 17, 2008
LP64 plus Universal Binaries = smooth transition to 64-bit computing
In today's installment, Daniel Eran Dilger explains why Apple doesn't share most of the problems encountered by Microsoft in making the 64-bit transition.
Monday, June 16, 2008
Snow Leopard Intel only, PPC-Mac users yawn
Continuing his hot streak, Daniel Eran Dilger explains why PPC-Mac users have no real reason to be upset over Snow Leopard being Intel-only, with a few caveats.
Saturday, June 14, 2008
"stop waiting and start coding"
Daniel is on a roll. In his very next article, about SproutCore, he says "If you were waiting for the resurrection of Yellow Box or Cocoa for Windows, stop waiting and start coding. SproutCore brings the values of Leopard’s Cocoa to the web, domesticating JavaScript into a functional application platform with lots of free built-in support for desktop features."
Mr. Dilger asserts, and he's not alone in doing so, that Apple has already made use of SproutCore in its .Mac galleries, and that the client-side web apps which will be an important part of MobileMe are built using it.
Even better, it's open source, under the MIT license.
Update: here's links to two more articles about SproutCore...
Mr. Dilger asserts, and he's not alone in doing so, that Apple has already made use of SproutCore in its .Mac galleries, and that the client-side web apps which will be an important part of MobileMe are built using it.
Even better, it's open source, under the MIT license.
Update: here's links to two more articles about SproutCore...
a bit more about Grand Central
Had Daniel Eran Dilger of RoughlyDrafted Magazine been in attendance at Apple's WWDC, he would now be in violation of the NDA covering all aspects of the conference aside from the keynote address. As he wasn't, that blood is on someone else's hands, whoever passed the information he presents here along to him.
Much of that article is simply placing news that was already public in context, but there are a few tidbits that hadn't appeared elsewhere.
With regard to Grand Central, after describing how packet-switched networks are more robust than circuit-switched networks, Dilger writes:
"Snow Leopard’s Grand Central Dispatch does the same thing for processes, packetizing tasks into Blocks and routing them to available processing cores as efficiently as possible. It can also manage the big picture for the whole system, adjusting how it balances its tasks as the performance load increases. This would be close to impossible for Individual developers to do themselves."
That's not much, but it's more than those of use who weren't at WWDC already knew.
Much of that article is simply placing news that was already public in context, but there are a few tidbits that hadn't appeared elsewhere.
With regard to Grand Central, after describing how packet-switched networks are more robust than circuit-switched networks, Dilger writes:
"Snow Leopard’s Grand Central Dispatch does the same thing for processes, packetizing tasks into Blocks and routing them to available processing cores as efficiently as possible. It can also manage the big picture for the whole system, adjusting how it balances its tasks as the performance load increases. This would be close to impossible for Individual developers to do themselves."
That's not much, but it's more than those of use who weren't at WWDC already knew.
Thursday, June 12, 2008
parsing the enigma of "Grand Central"
What's the first thing that pops into your mind when you hear the phrase Grand Central? If you're from New York City, chances are it's either Grand Central Terminal, or the subway station that adjoins it. Wikipedia has a disambiguation page for "Grand Central" that's been updated this week to include a reference to a new usage, but so far the article pointed to is just a stub, containing a one sentence description: "Grand Central is a technology developed by Apple to optimize multicore application support in Mac OS X 10.6."
In a press release, Apple says this: "Snow Leopard delivers unrivaled support for multi-core processors with a new technology code-named “Grand Central,” making it easy for developers to create programs that take full advantage of the power of multi-core Macs."
But why name it Grand Central, unless there's metaphoric value in stirring up an association with big, busy transportation hubs? (I'd rather not get more specific than that, as I suspect it would be easy to attribute too much significance to the detailed design and operation of one particular hub, looking for clues that aren't there.)
In a transportation hub, conveyances of one sort or another enter, let off and board passengers, and exit, and people enter and board a conveyance, transfer between conveyances, or get off and exit. A computer runs processes, which may themselves be divided into threads, and which are commonly separated between system space and user space. It has various resources which processes/threads make use of. Managing these processes/threads and resources is a much more complicated task than managing the trains and other conveyances passing through a transportation hub (busy airports possibly excepted), although it seems likely that a system software component vaguely analogous to such a hub might help to simplify the problem, and to judge by the sparse information already publicly available that would seem to be a major part of what Apple has created.
Just as conveyances interact with the infrastructure they depend on (sensors, traffic signals, drivers who obey them, ...), processes/thread which are designed to cooperate with the management system can play a role in making things run smoothly, and it seems Apple has also created tools to facilitate writing software that plays nicely with the system.
Whether this interpretation is on the right track, and what the details might be, remain to be seen. We should know in about a year, if not sooner.
In a press release, Apple says this: "Snow Leopard delivers unrivaled support for multi-core processors with a new technology code-named “Grand Central,” making it easy for developers to create programs that take full advantage of the power of multi-core Macs."
But why name it Grand Central, unless there's metaphoric value in stirring up an association with big, busy transportation hubs? (I'd rather not get more specific than that, as I suspect it would be easy to attribute too much significance to the detailed design and operation of one particular hub, looking for clues that aren't there.)
In a transportation hub, conveyances of one sort or another enter, let off and board passengers, and exit, and people enter and board a conveyance, transfer between conveyances, or get off and exit. A computer runs processes, which may themselves be divided into threads, and which are commonly separated between system space and user space. It has various resources which processes/threads make use of. Managing these processes/threads and resources is a much more complicated task than managing the trains and other conveyances passing through a transportation hub (busy airports possibly excepted), although it seems likely that a system software component vaguely analogous to such a hub might help to simplify the problem, and to judge by the sparse information already publicly available that would seem to be a major part of what Apple has created.
Just as conveyances interact with the infrastructure they depend on (sensors, traffic signals, drivers who obey them, ...), processes/thread which are designed to cooperate with the management system can play a role in making things run smoothly, and it seems Apple has also created tools to facilitate writing software that plays nicely with the system.
Whether this interpretation is on the right track, and what the details might be, remain to be seen. We should know in about a year, if not sooner.
Subscribe to:
Posts (Atom)