Update: Daniel follows through
Rather than wait for the next installment of RoughlyDrafted, I'm going to proceed with tackling a point that Daniel suggests he'll be addressing, that Apple is simply out of ideas.
I'll be making one crucial assumption, which is that if I can think up something useful someone at Apple has probably already thought of it.
Apple has put a lot of effort into their implementation of OpenGL, hardware acceleration included, but OpenGL is all about surfaces. It won't help you with the flexing of hair or skin, for instance, much less with the fluid dynamics of smoke rising through air or water flowing over rocks in a stream. Of course, dealing with solids, fluids, and factors like gravity and momentum is hugely complicated, and there's a wide selection of expensive software that's used by professionals in gaming, animation, architecture, and mechanical design. Apple certainly couldn't replace all of that, but by laying a little groundwork they could simplify the creation of such software and help to make versions suitable for hobbyists available. For lack of a better name, let's refer to it as Core Physics.
Core Data has already done a lot to simplify the handling and preservation of data. But giving meaning to that data is still left to the developer. One way in which the system could support this task is by making a wider range of statistical operations available as methods on basic classes, like NSNumber or NSArray. Even better would be to provide a library that starts with statistics but goes on to provide support for building object networks based on patterns in the data and putting data in context. Let's call this Core Heuristics.
Picking meaningful information out of data streams, such as those provided by a microphone or a camera, is both difficult and very useful if you can manage it. Support for doing so might be called Core Hearing and Core Vision, respectively.
Given the above, the idea of providing support for environmental/machine control practically suggests itself. For Macs, this would likely be mostly about interfacing with the several home automation standards in use, and maybe about developer tools for other types of hardware, but the possibilities don't end there. Response to touch is a big deal in the physical world, and having touch awareness built into UIKit positions OS X advantageously for use in responsive toys, for example. Granted there's a lot of work to be done to get from an iPhone to an 'iBear', but I wouldn't be too surprised to learn that Apple was already on it. Again, for lack of a better name, let's call this Core Automation.
Note that the above is all about plumbing. I haven't yet suggested anything that would be apparent to the average Mac user, and that's where I'm going to leave it for now. Maybe Daniel has some ideas along those lines.
Wednesday, June 25, 2008
Tuesday, June 24, 2008
whence Carbon?
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.
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.
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.
Sunday, June 08, 2008
good whistlers make better kissers
I mean, is this obvious or what? If you can't wrap your lips around a tune what chance do you stand with another pair of lips?
But I've never seen or heard it said before, so there it is.
But I've never seen or heard it said before, so there it is.
Sunday, June 01, 2008
using Stacks to keep many apps on Leopard's Dock without crowding
For as long as I've been using Mac OS X, which is since the non-beta version of 10.0 was released, I've wished for a way of grouping applications on the Dock, and, as I acquired more apps, I've also begun to wish for a way of shoehorning more icons onto the Dock than it could comfortably accommodate.
Those in the know may immediately point to you to third-party software like QuickSilver or DragThing, or to scripting solutions. Not having tried any of these, I can't comment on them.
My approach is utterly simple, involving nothing more complicated than setting up a group of folders, creating aliases to applications or other folders (Command-L), moving them to the appropriate folder, and dragging the folder icons from a Finder window to the Dock, where they become stacks. The way I've set it up, these folders all live within a folder named Stacks, which is just inside my home folder. They are each named for a category, like "Media" or "Programming" which describes their contents.
Here's the list of stack folders I currently have, in the order they appear on the Dock left to right, and the contents of each (note that the actual filenames of the contents all end in ".alias" or ".app.alias").
The last two items under Programming are folders. In some cases I have altered the names in order to control the alphabetical sort order, and thereby control which icons appear on top of the stacks on the Dock. Doing this has no effect on the application or folder to which an alias points.
Note that a few items appear in more than one stack. Pages, for instance, is both a writing tool and part of iWork, and Bento is both a database program and an application that's useful in getting things done.
Those in the know may immediately point to you to third-party software like QuickSilver or DragThing, or to scripting solutions. Not having tried any of these, I can't comment on them.
My approach is utterly simple, involving nothing more complicated than setting up a group of folders, creating aliases to applications or other folders (Command-L), moving them to the appropriate folder, and dragging the folder icons from a Finder window to the Dock, where they become stacks. The way I've set it up, these folders all live within a folder named Stacks, which is just inside my home folder. They are each named for a category, like "Media" or "Programming" which describes their contents.
Here's the list of stack folders I currently have, in the order they appear on the Dock left to right, and the contents of each (note that the actual filenames of the contents all end in ".alias" or ".app.alias").
- Browsers
- Camino
- Safari
- Network Apps
- Adium
- iChat
- Transmit
- Databases
- AddressBook
- Bento
- Data Guardian
- iCal
- Getting Things Done
- Bento
- iCal
- OmniFocus
- Writing Tools
- MarsEdit
- OmniOutliner Professional
- Pages
- Scrivener
- TextEdit
- iWork & Pro Apps
- Keynote
- Numbers
- OmniGraffle Professional
- Pages
- Web & Widget Design
- BBEdit
- Dashcode
- iWeb
- Media
- GarageBand
- GraphicConverter
- iDVD
- Image Capture
- iMovie
- iPhoto
- iTunes
- Photo Booth
- Preview
- QuickTime Player
- Programming
- Automator
- Xcode
- /Developer
- /Developer/Applications
The last two items under Programming are folders. In some cases I have altered the names in order to control the alphabetical sort order, and thereby control which icons appear on top of the stacks on the Dock. Doing this has no effect on the application or folder to which an alias points.
Note that a few items appear in more than one stack. Pages, for instance, is both a writing tool and part of iWork, and Bento is both a database program and an application that's useful in getting things done.
Subscribe to:
Posts (Atom)