the 10.5.X are mini SP so calling it SP1 will not fit in may call in Leopard SE / Leopard reloaded M$ was going to have a XP reloaded but that turned into SP2.
. . . and maybe the code-name amounts to a tacit admission of that? In any case, if it is a freebie, if it improves quality, and if they continue refining and supporting 10.5 for legacy systems for a decent period of time, I'm all in favor of it. But I'm not confident that all those things will hapen.
I think Apple will have Final Cut Studio in Cocoa for next year and iTunes 8 will likely be Cocoa as well.
I'd love to see that, but based on what I've seen from apple I'm not getting my hopes up. I just read that the head of Logic development has said that updating the app to 64 bit would make things worse more than better, and that they plan to NEVER do a 64 bit build. I wonder if a mandate from Apple would change things.
So the OS thing came up again? Cool. So here is what the fellow at Harvard says.
Okay... the UI biggie for 10.6 is Pockets (name not locked in yet). It's the successor to the Stacks crowd (so it may take 2 OS releases to see daylight). Pretty simple idea really. An app developer can enable an app to be 'pocketed'. What this does is gives you a single keystroke (similar to expose) which will save the Application and Application Prefs, and any open documents into a 'packet' of info which it then puts into your pocket.
The pocket is complimentary to the idea of expose and spaces. Expose and Spaces lets you manage windows and the like while on your computer... Pocket lets you do the same with applications. It's a new idea that compliments something you already do today.
If you buy photoshop... and you have two macs.. you probably only buy ONE copy and install it on both. (feeling that you 'own' it now). Apple's historical stance is to find you a quick, easy, and legal way to do what you already do in a more sensible way.
So here is how pockets works. The encrypted pocket includes your computer stamped info and enables you to launch an application on another computer where it isn't installed. These pockets can be put on Apple's iPod line-up (and iPhone of course) or transfered via the freshly re-vamped .Mac (to be announced prior).
Developers can decide if they want the app to be portable or not... This extends 'loaner' functionality for freeware titles etc. (so you can upload a pocket of your latest build of fill_in_the_blank_freeware_you_make) and quickly distribute it (via a RSS page, or similar 'podcast' type subscription).
The tech sits between the ipod application store, the OS, the .Mac, and Apple's existing .pkg technology. It's 1.0 version will give a lot of functionality (and expand to include a wide variety of features) but the big news is the long term vision (or 2.0 version) which will be part of the following OS release (which won't be an OS X successor).
PS: I disagree with the Harvard guy on the freeware etc aspect. I personally thing this is just a tech to allow you to snapshot an application, prefs, and associated docs into a 'pocket' universe which you can easily swap to up to 5 Macs (just like iTunes) and you can do it via .Mac or iPod. That being said.. Harvard guy usually is right... and I'm usually wrong.
EDIT: Oh, and this will be sold as Application license flexibility. (for when you want to show your co-worker a photoshop doc and he doesn't have Photoshop installed. But pockets are a 'read only' type of framework and not built for you to be able to author new content.. but to be able to work on it and have it sync back on the far side. (especially useful for .Mac and MacBook Air etc.) It will integrate seamlessly with Time-Machine for versioning too.
Hopefully the folks at Apple realize that its time to start focusing on performance.... This has certainly been a weak spot for CERTAIN TYPES of programs only (look at all of the literature on Linux vs OS X performance wrt transaction-heavy systems). Believe me -- I'm an OS X fan all the way, because there's a lot more to an OS than pure performance. But this is an area that needs some attention now if they want to keep growing their market-share.
The miraculous engineering feat of melding the XNU kernel (a Mach hybrid) with the BSD user-land, along with System V interfaces and POSIX compliance, has undoubtably created some compromises inside the kernel and system code. In my opinion, Apple have done a wonderful job putting a truly object-oriented API (Cocoa) on top of the rest of the OS, and that will pay of in spades in the years to come, as will the inspired choice of using IOKit. It's the core of the OS that needs a little tweaking now. This clean-up will make the OS faster, more secure, and more stable (even though I think it's pretty darn stable right now).
And no, I do not think they will be putting the Linux kernel in there. It has to do with licensing issues, not technical issues.
If anything, Apple are probably acting in anticipation of MinWin (Windows 7.0) and they realize that the foundations need to be shored up a little in order to not have any performance embarrassments. I am confident that Apple will deliver. Their OS strategy is already vastly superior to Redmond's (have many sku's of Windows are there? And how many of OS X?) so again I am confidents that Apple are doing the Right Thing here.
I don't see Apple breaking PPC and Carbon support starting next year. It was mentioned several times in this forum: Apple had to keep Classic for several years. There is no sense killing all major apps now.
But there might be something in this rumor:
Apple may provide virtualization environment (more transparent than Classic) for old apps.
Apple may keep Rosetta and Carbon altogether but offer improvements for the 64bit Intel AND OTHER NEW PROCESSOR ARCHITECTURES ONLY. They don't need to be 64 bit!.
Apple may introduce a new file system (ZFS?) which may break important functionality of the old apps.
I will try to clarify the second point. Currently, Apple has a nice "Universal binary" architecture in place. Since the first 10.5 betas It was highly recommended to provide 64 bit support in all new Frameworks and drivers. Also, Apple introduced Objective-C 2.0 with garbage collection and improved runtime architecture for 64-bit processors (not sure Intel only). One of the changes was the internal object (or an instance of an object, in Apples terminology) representation. It is possible that these were steps towards more significant modernization of the Objective-C runtime environment. The reason this can not be applied to old processors is that the old applications expect the old runtime, old memory representation and may use some runtime hacks. In order to use the new runtime a recompile is needed. Applications compiled for 64bit Leopard may have all necessary changes in place, but the old apps don't.
Cocoa-only might mean that all OS features will be available from Cocoa APIs. Since 10.0 release there was a permanent move in this direction. Initially, most file system operations required Carbon APIs. Untill recently, QT had very limited support in Cocoa etc.
Cocoa provides much better abstraction than the procedural API. This will allow Apple to use hardware acceleration (SSE4, GPU, P. A. Semi?) or other improvements more aggressively. They may may be supported on new/recent hardware only. Think CoreImage - when introduced, only few configurations could support it.
1) Carbon is, if not already dead, on extreme ICU life support. Go look at the Sessions on the WWDC site, and look for Carbon. You won't find it. Last year there was just one: Transitioning Carbon apps to Cocoa. I'm not sure how much larger a clue anyone needs. (Well, unless you're Adobe...)
2) You can kill Carbon for the developer without killing it for the user. When developing, you need these things called 'header files'. They are the files that define and describe the API that the developer uses. They are not used at run-time, only during compile-time for the developer creating the app. I expect to see the Carbon headers removed. This means that developers *cannot* compile a Carbon app for the new OS. They *must* move to Cocoa if they want to support the new OS.
3) The user could still run Carbon apps on that OS, by Apple simply retaining the Carbon libraries for a while. No development, but still run the apps. This gives users the ability to continue using their apps, but *forces* developers (finally) to move off of Carbon. After another major OS iteration or two, they can pull the libraries, as they did Classic, and then, and only then, in a few years, would the Carbon apps no longer run.
4) Most of the Carbon functionality has been moved out of the Carbon libraries and into Core*. Carbon has become, more or less, a shell over Core*. Cocoa has been using pieces of Core* behind the scenes for a while - I expect that the announcement will be that Cocoa now has all (and I mean all) the functionality that Carbon had, plus all the Cocoa goodness that Carbon has always lacked. ie, there's no need for Carbon APIs.
So - Carbon dead, some greybeard developers will continue to whine unhappily despite being bonked over the head for a decade that this was going to happen, Cocoa developers happier, users not screwed. Better?
I'm not sure how much larger a clue anyone needs. (Well, unless you're Adobe...)
People seem to like ragging on Adobe, but side with Apple. The question I have is, why did Apple let their pro apps linger in Carbon for so long? They too had nearly a decade to change, but have not.
Before Carbon was announced, most of the big devs (and the small devs) threatened to simply not develop for MacOS X if they couldn't move their old code over. Can't really blame them... so they got Carbon, and the message that this was temporary.
That last bit freaked them out, again, and Apple had to go through a rather long period of placation, demonstrating that the devs could have more time to feel like they were using a peer API. Internally, there was also a lot of resistance to ditching the old MacOS Toolbox code completely, so Carbon did have some internal support.
Now, if you're going to ship the bloody API, and you're really not sure about it, and you want to show some very large (and very stubborn) large development houses that you do support their API of choice, what do you do? You write your own apps in it. It's that whole 'eating our own dog food' idea - by using the APIs to write your apps, you find the problems faster. By writing your apps in it, you tell others that you're not going to just drop it suddenly.
It hasn't been suddenly. It's been a decade. I would not at all be surprised to hear that Apple has Carbon-sanitized their apps. Remember the MacOS Toolbox -> Carbon helper app Carbonizer? It would be pretty damned simple to write an analog that helps you find the Carbon calls in your app, and map them to Cocoa equivalents. Actually *doing* the recoding isn't trivial, but a helper assistant isn't out of the question.
Think of it this way: When Carbon and Cocoa were announced, they shared basically no code between them. A developer used one, or the other, more or less. Carbon had certain Mac technologies that you couldn't access from Cocoa, so pretty quickly, many Cocoa apps also had some Carbon calls in them. Over time, this has changed - the functionality that was exclusively in Carbon has been pulled out and placed in the Core* APIs (CoreFoundation, CoreImage, CoreAnimation, etc). Carbon has been slowly but methodically gutted and has been becoming more of a legacy API shell over the Core* libraries. What previously required a Carbon call in a Cocoa app has been replaced with a Core* call. Also, to make them easier to use, much of the Core* stuff has a Cocoa wrapper as well, so a Cocoa dev can stick with a more 'pure' approach if they want.
When Carbon becomes an empty shell, but the assumptions about the runtime environment are holding back what can be done on the rest of the system... it's time to start shoving it off to the old code's home.
As to how this relates to Apple's apps: I'd wager that they are again eating their dog food by migrating the apps away from the Carbon API so it can be retired. If you look at how Apple rolls out dev technologies, they tend to hammer on them in house, privately, and only unveiling them when they have a) a solid implementation that's been tested, b) examples of how best to use the technology, c) anecdotes for marketing. I'd expect that, with an announcement of official Carbon deprecation, will come a set of tools to help migrate code away from Carbon, and an announcement that they've been using it in house on their own apps.
Kickaha -- I don't know anything about this stuff. I don't want to know anything about this stuff. I could care less about any of this stuff (as long as the elves make my computer magically work)... but your last two posts were so clear and well-explained, that I found myself enjoying and learning from them. I don't know if you're right or wrong, but they sure read well. Thanks much.
Kickaha -- I don't know anything about this stuff. I don't want to know anything about this stuff. I could care less about any of this stuff (as long as the elves make my computer magically work)... but your last two posts were so clear and well-explained, that I found myself enjoying and learning from them. I don't know if you're right or wrong, but they sure read well. Thanks much.
I just read that the head of Logic development has said that updating the app to 64 bit would make things worse more than better, and that they plan to NEVER do a 64 bit build.
May I ask where you read this please? I'm not doubting you but I'd like to check it out. Apple don't usually break from not discussing future products.
May I ask where you read this please? I'm not doubting you but I'd like to check it out. Apple don't usually break from not discussing future products.
Yes indeed. I'm sure the Cakewalk developers would love to discuss this seeing as how Sonar has been 64-bit for a while without any issues.
May I ask where you read this please? I'm not doubting you but I'd like to check it out. Apple don't usually break from not discussing future products.
It is being reported on apple's Logic user board. Apparently their lead programmer told various people that in person, I assume at a trade show.
Anyway, the idea that 10.6 would drop carbon support is being disputed, supposedly it just means that Apple is *adding* cocoa functionality so that devs won't have to use any carbon at all:
Yes indeed. I'm sure the Cakewalk developers would love to discuss this seeing as how Sonar has been 64-bit for a while without any issues.
For the record, I'm just passing along what I heard. I doubt that a 64 bit update would hurt performance overall (or not by much) and my guess is that the Logic guys just don't want to update because it would be too much work, and because they have found other ways to get some of the 64 bit benefits without rewriting the app (splitting out some functionality into separate threads/processes).
It is being reported on apple's Logic user board. Apparently their lead programmer told various people that in person, I assume at a trade show.
Anyway, the idea that 10.6 would drop carbon support is being disputed, supposedly it just means that Apple is *adding* cocoa functionality so that devs won't have to use any carbon at all:
For the record, I'm just passing along what I heard. I doubt that a 64 bit update would hurt performance overall (or not by much) and my guess is that the Logic guys just don't want to update because it would be too much work, and because they have found other ways to get some of the 64 bit benefits without rewriting the app (splitting out some functionality into separate threads/processes).
I agree with this guy. For track count and plugin processing more RAM isn't going to help but if you're an EXS24 user you're looking at this with incredulity. Loading loops and sampling is a mainstay of the modern DAW. I think you're right the engineers probably want to keep Logic 32-bit and optimize the hell out of it rather than comb through and move it to 64-bit.
I agree with this guy. For track count and plugin processing more RAM isn't going to help but if you're an EXS24 user you're looking at this with incredulity. Loading loops and sampling is a mainstay of the modern DAW. I think you're right the engineers probably want to keep Logic 32-bit and optimize the hell out of it rather than comb through and move it to 64-bit.
I wonder if Snow Leopard won't be a lightweight version of OSX that will run nicely on Netbooks and Nettops that Intel are touting at Computex. IIRC, Atom is a 64 bit cpu. Perhaps this would go into a revised mini with Snow Leopard as the OS. However, these Nettop and Netbook systems are generally priced at the very low end of the market. An area that Apple hasn't historically shown a lot of interest in.
But this is the hottest area of the market right now and Windows really isn't well positioned here. Vista and Windows 7 are never going to compete in this space. MS is using xp to work on these machines.
My thoughts all along too. Snow Leopard is destined for Apple's devices, not their mainstream laptops/desktops. It's too early to kill Carbon for Adobe and Microsoft. A nice 64bit Cocoa OS may sound cool but without the big apps it's not destined for mainstream use.
So essentially OS X morphs into an Intel-only 64-bit nimble beast, and OS X Leopard* includes Carbon as a legacy technology for the time being. Interesting.
Comments
the 10.5.X are mini SP so calling it SP1 will not fit in may call in Leopard SE / Leopard reloaded M$ was going to have a XP reloaded but that turned into SP2.
Great. Can't wait for Leopard Revolutions then
I think Apple will have Final Cut Studio in Cocoa for next year and iTunes 8 will likely be Cocoa as well.
I'd love to see that, but based on what I've seen from apple I'm not getting my hopes up. I just read that the head of Logic development has said that updating the app to 64 bit would make things worse more than better, and that they plan to NEVER do a 64 bit build. I wonder if a mandate from Apple would change things.
Okay... the UI biggie for 10.6 is Pockets (name not locked in yet). It's the successor to the Stacks crowd (so it may take 2 OS releases to see daylight). Pretty simple idea really. An app developer can enable an app to be 'pocketed'. What this does is gives you a single keystroke (similar to expose) which will save the Application and Application Prefs, and any open documents into a 'packet' of info which it then puts into your pocket.
The pocket is complimentary to the idea of expose and spaces. Expose and Spaces lets you manage windows and the like while on your computer... Pocket lets you do the same with applications. It's a new idea that compliments something you already do today.
If you buy photoshop... and you have two macs.. you probably only buy ONE copy and install it on both. (feeling that you 'own' it now). Apple's historical stance is to find you a quick, easy, and legal way to do what you already do in a more sensible way.
So here is how pockets works. The encrypted pocket includes your computer stamped info and enables you to launch an application on another computer where it isn't installed. These pockets can be put on Apple's iPod line-up (and iPhone of course) or transfered via the freshly re-vamped .Mac (to be announced prior).
Developers can decide if they want the app to be portable or not... This extends 'loaner' functionality for freeware titles etc. (so you can upload a pocket of your latest build of fill_in_the_blank_freeware_you_make) and quickly distribute it (via a RSS page, or similar 'podcast' type subscription).
The tech sits between the ipod application store, the OS, the .Mac, and Apple's existing .pkg technology. It's 1.0 version will give a lot of functionality (and expand to include a wide variety of features) but the big news is the long term vision (or 2.0 version) which will be part of the following OS release (which won't be an OS X successor).
PS: I disagree with the Harvard guy on the freeware etc aspect. I personally thing this is just a tech to allow you to snapshot an application, prefs, and associated docs into a 'pocket' universe which you can easily swap to up to 5 Macs (just like iTunes) and you can do it via .Mac or iPod. That being said.. Harvard guy usually is right... and I'm usually wrong.
EDIT: Oh, and this will be sold as Application license flexibility. (for when you want to show your co-worker a photoshop doc and he doesn't have Photoshop installed. But pockets are a 'read only' type of framework and not built for you to be able to author new content.. but to be able to work on it and have it sync back on the far side. (especially useful for .Mac and MacBook Air etc.) It will integrate seamlessly with Time-Machine for versioning too.
The miraculous engineering feat of melding the XNU kernel (a Mach hybrid) with the BSD user-land, along with System V interfaces and POSIX compliance, has undoubtably created some compromises inside the kernel and system code. In my opinion, Apple have done a wonderful job putting a truly object-oriented API (Cocoa) on top of the rest of the OS, and that will pay of in spades in the years to come, as will the inspired choice of using IOKit. It's the core of the OS that needs a little tweaking now. This clean-up will make the OS faster, more secure, and more stable (even though I think it's pretty darn stable right now).
And no, I do not think they will be putting the Linux kernel in there. It has to do with licensing issues, not technical issues.
If anything, Apple are probably acting in anticipation of MinWin (Windows 7.0) and they realize that the foundations need to be shored up a little in order to not have any performance embarrassments. I am confident that Apple will deliver. Their OS strategy is already vastly superior to Redmond's (have many sku's of Windows are there? And how many of OS X?) so again I am confidents that Apple are doing the Right Thing here.
But there might be something in this rumor:
- Apple may provide virtualization environment (more transparent than Classic) for old apps.
- Apple may keep Rosetta and Carbon altogether but offer improvements for the 64bit Intel AND OTHER NEW PROCESSOR ARCHITECTURES ONLY. They don't need to be 64 bit!.
- Apple may introduce a new file system (ZFS?) which may break important functionality of the old apps.
I will try to clarify the second point. Currently, Apple has a nice "Universal binary" architecture in place. Since the first 10.5 betas It was highly recommended to provide 64 bit support in all new Frameworks and drivers. Also, Apple introduced Objective-C 2.0 with garbage collection and improved runtime architecture for 64-bit processors (not sure Intel only). One of the changes was the internal object (or an instance of an object, in Apples terminology) representation. It is possible that these were steps towards more significant modernization of the Objective-C runtime environment. The reason this can not be applied to old processors is that the old applications expect the old runtime, old memory representation and may use some runtime hacks. In order to use the new runtime a recompile is needed. Applications compiled for 64bit Leopard may have all necessary changes in place, but the old apps don't.Cocoa-only might mean that all OS features will be available from Cocoa APIs. Since 10.0 release there was a permanent move in this direction. Initially, most file system operations required Carbon APIs. Untill recently, QT had very limited support in Cocoa etc.
Cocoa provides much better abstraction than the procedural API. This will allow Apple to use hardware acceleration (SSE4, GPU, P. A. Semi?) or other improvements more aggressively. They may may be supported on new/recent hardware only. Think CoreImage - when introduced, only few configurations could support it.
2) You can kill Carbon for the developer without killing it for the user. When developing, you need these things called 'header files'. They are the files that define and describe the API that the developer uses. They are not used at run-time, only during compile-time for the developer creating the app. I expect to see the Carbon headers removed. This means that developers *cannot* compile a Carbon app for the new OS. They *must* move to Cocoa if they want to support the new OS.
3) The user could still run Carbon apps on that OS, by Apple simply retaining the Carbon libraries for a while. No development, but still run the apps. This gives users the ability to continue using their apps, but *forces* developers (finally) to move off of Carbon. After another major OS iteration or two, they can pull the libraries, as they did Classic, and then, and only then, in a few years, would the Carbon apps no longer run.
4) Most of the Carbon functionality has been moved out of the Carbon libraries and into Core*. Carbon has become, more or less, a shell over Core*. Cocoa has been using pieces of Core* behind the scenes for a while - I expect that the announcement will be that Cocoa now has all (and I mean all) the functionality that Carbon had, plus all the Cocoa goodness that Carbon has always lacked. ie, there's no need for Carbon APIs.
So - Carbon dead, some greybeard developers will continue to whine unhappily despite being bonked over the head for a decade that this was going to happen, Cocoa developers happier, users not screwed. Better?
I'm not sure how much larger a clue anyone needs. (Well, unless you're Adobe...)
People seem to like ragging on Adobe, but side with Apple. The question I have is, why did Apple let their pro apps linger in Carbon for so long? They too had nearly a decade to change, but have not.
Before Carbon was announced, most of the big devs (and the small devs) threatened to simply not develop for MacOS X if they couldn't move their old code over. Can't really blame them... so they got Carbon, and the message that this was temporary.
That last bit freaked them out, again, and Apple had to go through a rather long period of placation, demonstrating that the devs could have more time to feel like they were using a peer API. Internally, there was also a lot of resistance to ditching the old MacOS Toolbox code completely, so Carbon did have some internal support.
Now, if you're going to ship the bloody API, and you're really not sure about it, and you want to show some very large (and very stubborn) large development houses that you do support their API of choice, what do you do? You write your own apps in it. It's that whole 'eating our own dog food' idea - by using the APIs to write your apps, you find the problems faster. By writing your apps in it, you tell others that you're not going to just drop it suddenly.
It hasn't been suddenly. It's been a decade. I would not at all be surprised to hear that Apple has Carbon-sanitized their apps. Remember the MacOS Toolbox -> Carbon helper app Carbonizer? It would be pretty damned simple to write an analog that helps you find the Carbon calls in your app, and map them to Cocoa equivalents. Actually *doing* the recoding isn't trivial, but a helper assistant isn't out of the question.
Think of it this way: When Carbon and Cocoa were announced, they shared basically no code between them. A developer used one, or the other, more or less. Carbon had certain Mac technologies that you couldn't access from Cocoa, so pretty quickly, many Cocoa apps also had some Carbon calls in them. Over time, this has changed - the functionality that was exclusively in Carbon has been pulled out and placed in the Core* APIs (CoreFoundation, CoreImage, CoreAnimation, etc). Carbon has been slowly but methodically gutted and has been becoming more of a legacy API shell over the Core* libraries. What previously required a Carbon call in a Cocoa app has been replaced with a Core* call. Also, to make them easier to use, much of the Core* stuff has a Cocoa wrapper as well, so a Cocoa dev can stick with a more 'pure' approach if they want.
When Carbon becomes an empty shell, but the assumptions about the runtime environment are holding back what can be done on the rest of the system... it's time to start shoving it off to the old code's home.
As to how this relates to Apple's apps: I'd wager that they are again eating their dog food by migrating the apps away from the Carbon API so it can be retired. If you look at how Apple rolls out dev technologies, they tend to hammer on them in house, privately, and only unveiling them when they have a) a solid implementation that's been tested, b) examples of how best to use the technology, c) anecdotes for marketing. I'd expect that, with an announcement of official Carbon deprecation, will come a set of tools to help migrate code away from Carbon, and an announcement that they've been using it in house on their own apps.
Shhhhhhh. We don't discuss that.
Before Carbon was announced... etc., etc. etc.
Kickaha -- I don't know anything about this stuff. I don't want to know anything about this stuff. I could care less about any of this stuff (as long as the elves make my computer magically work)... but your last two posts were so clear and well-explained, that I found myself enjoying and learning from them. I don't know if you're right or wrong, but they sure read well. Thanks much.
Kickaha -- I don't know anything about this stuff. I don't want to know anything about this stuff. I could care less about any of this stuff (as long as the elves make my computer magically work)... but your last two posts were so clear and well-explained, that I found myself enjoying and learning from them. I don't know if you're right or wrong, but they sure read well. Thanks much.
Ditto.
I just read that the head of Logic development has said that updating the app to 64 bit would make things worse more than better, and that they plan to NEVER do a 64 bit build.
May I ask where you read this please? I'm not doubting you but I'd like to check it out. Apple don't usually break from not discussing future products.
May I ask where you read this please? I'm not doubting you but I'd like to check it out. Apple don't usually break from not discussing future products.
Yes indeed. I'm sure the Cakewalk developers would love to discuss this seeing as how Sonar has been 64-bit for a while without any issues.
May I ask where you read this please? I'm not doubting you but I'd like to check it out. Apple don't usually break from not discussing future products.
It is being reported on apple's Logic user board. Apparently their lead programmer told various people that in person, I assume at a trade show.
Anyway, the idea that 10.6 would drop carbon support is being disputed, supposedly it just means that Apple is *adding* cocoa functionality so that devs won't have to use any carbon at all:
http://daringfireball.net/linked/200...-04-pure_cocoa
Yes indeed. I'm sure the Cakewalk developers would love to discuss this seeing as how Sonar has been 64-bit for a while without any issues.
For the record, I'm just passing along what I heard. I doubt that a 64 bit update would hurt performance overall (or not by much) and my guess is that the Logic guys just don't want to update because it would be too much work, and because they have found other ways to get some of the 64 bit benefits without rewriting the app (splitting out some functionality into separate threads/processes).
It is being reported on apple's Logic user board. Apparently their lead programmer told various people that in person, I assume at a trade show.
Anyway, the idea that 10.6 would drop carbon support is being disputed, supposedly it just means that Apple is *adding* cocoa functionality so that devs won't have to use any carbon at all:
http://daringfireball.net/linked/200...-04-pure_cocoa
For the record, I'm just passing along what I heard. I doubt that a 64 bit update would hurt performance overall (or not by much) and my guess is that the Logic guys just don't want to update because it would be too much work, and because they have found other ways to get some of the 64 bit benefits without rewriting the app (splitting out some functionality into separate threads/processes).
http://digitalproducer.digitalmedian...e.jsp?id=30309
I agree with this guy. For track count and plugin processing more RAM isn't going to help but if you're an EXS24 user you're looking at this with incredulity. Loading loops and sampling is a mainstay of the modern DAW. I think you're right the engineers probably want to keep Logic 32-bit and optimize the hell out of it rather than comb through and move it to 64-bit.
http://digitalproducer.digitalmedian...e.jsp?id=30309
I agree with this guy. For track count and plugin processing more RAM isn't going to help but if you're an EXS24 user you're looking at this with incredulity. Loading loops and sampling is a mainstay of the modern DAW. I think you're right the engineers probably want to keep Logic 32-bit and optimize the hell out of it rather than comb through and move it to 64-bit.
Thanks for the link. I'd agree with that as well.
I posted a similar thought at Ars.
I wonder if Snow Leopard won't be a lightweight version of OSX that will run nicely on Netbooks and Nettops that Intel are touting at Computex. IIRC, Atom is a 64 bit cpu. Perhaps this would go into a revised mini with Snow Leopard as the OS. However, these Nettop and Netbook systems are generally priced at the very low end of the market. An area that Apple hasn't historically shown a lot of interest in.
But this is the hottest area of the market right now and Windows really isn't well positioned here. Vista and Windows 7 are never going to compete in this space. MS is using xp to work on these machines.
My thoughts all along too. Snow Leopard is destined for Apple's devices, not their mainstream laptops/desktops. It's too early to kill Carbon for Adobe and Microsoft. A nice 64bit Cocoa OS may sound cool but without the big apps it's not destined for mainstream use.
*No, really. Check it out, "MacOS X" it is not: http://flickr.com/photos/gernot/2554181096/
No, really. Check it out, "MacOS X" it is not: http://flickr.com/photos/gernot/2554181096/
I guess we have an answer to the two GG bridges.