Apple's Mac OS X 10.6 code named "Snow Leopard" - report - Page 3

Below MacBook Air? Define below here?


Couldn't agree more.

OK--how about some really wild speculation? (Not as wild as an Apple Tablet, IMHO, but wild, anyway?)

Everybody expects the next generation of laptops to be like fat MBAs, and probably the very next ones will be, but consider: wrapping the MacBook at least in aluminum takes away the color-coding Apple is so fond of. You know: MacBooks come in "Look-at-me-I'm-a-cheapskate" white or "Look-at-me-I've-got-more-money-than-sense" black. What if these pictures we're seeing of the new iPhone are not disinformation, but this is the future: rounded, white or black, plastic or ceramic cases. Anybody but me remember the "Snow" iMac? That's probably what this new design reminds the Apple people of, too, so they code-named the new upgrade "Snow Leopard" because it's designed to run on these new (next back-to-school season?) laptops with a lot of touch features built into the screens? I think touch screens on desktop computers would be ludicrous, but on a laptop, where the screen is no farther away than the keyboard, they make a lot of sense. I think we can expect future laptops to make very heavy use of Cocoa Touch, and maybe they'll get their own touch-centric OS to take advantage of it.

Meanwhile, Microsoft has everybody sitting at their desk, stretching their arms straight out, working their vertical Surface screens.

A Microsoft spokesperson recently said about Surface:
So they are slipping away from the surface it looks like. And they are slipping away from the camera tracking your fingers for touch thing too it looks like, they are going more down the Apple route.

I don't think adding a touch screen to a regular notebook is a good idea. When they are ready to do that they'll likely make a notebook like this with a screen that twists around and can be put flat (but with a hardware keyboard):



Though I still think they'll make a tablet computer first with no twist screen and no hardware keyboard.

Just a 10" slab with some sort of flip-out rest on the back for placing the device on a table at a comfortable angle.

I'm thinking smaller screen and touch keyboard, and maybe sacrificing some features due to its size. Like a larger iPhone with a more complete OS.

They might leave a phone in there though...

"Leopard previewed 2 years ago. Snow leopard will show this year and release winter 2009. When MS releases Windows 7 to laughs and tears, Apple will release Lion for the kill."

Yeah, it is way too soon for an update at MacWorld 2009. They should take all that optimization and wrap it in one of the minor releases of Leopard and call that Snow Leopard. I'd bet that's what they are doing. This won't be a major upgrade nor cost anything.

I'm surprised so many people are thinking this way.

Who will pay for it? Professionals. And they'll think it is the greatest damn OS upgrade Apple has ever released (if Apple puts the same energy into optimizing the OS they would have put into new features). I am, personally, thrilled to hear this news. I depend on my computer to get things done quickly and reliably, and anything that aids in this task is more than welcome and easily worth a full OS upgrade fee (it wouldn't take long for it to pay for itself). I think the $69 mini-upgrade idea is the best way to go about this.

But if Photoshop isn't available, among others, I can't upgrade.

There is no reason to expect 10.6 in January 09.

OS X 10.0 = March 2001
OS X 10.1 = September 2001 - 6 months
OS X 10.2 = August 2002 - 11 months
OS X 10.3 = October 2003 - 14 months
OS X 10.4 = April 2005 - 18 months
OS X 10.5 = October 2007 - 30 months

If you look at the trend you'll see that each release takes longer. Based on this history it is there will be no 10.6 at MacWorld SF January 2009.(thought i think this is a possibility for jan 2010). I'm betting on WWDC June 2010 being the ship time for 10.6. This would put it at 32 months of development time.

So far as the end of the PowerPC, i agree with this given a June 2010 estimated ship date for 10.6. However, I doubt they'll kill 32 bit intel support until 10.7. They were still shipping some 32 bit systems as of mid 07 at least. (Mac Mini) Then again they are Apple so they may bone the 32 bit users but I'm gonna put my money on 64 bit only at 10.7.

Bottom-line, 10.6 at WWDC June 2010 with Intel only support, 32 bit, 64 bit.

10.7 with 64 bit only support.

This is a reasonable guess.

But those aren't the only things to consider. There was an interview with Steve Jobs a few months ago where he said he wants to shorten the development cycle. If that's true, then don't count on a longer wait.

That would be reasonable if 10.6 offered major new features. From what we rumour right now, its mostly a re-adjustment of the OS focusing on performance, improving the core, and so on. We're looking at Leopard SP1 so to speak - that's why its "Snow Leopard". So Jan 2009 is very reasonable. 14-15 months to get that done - definitely.

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.

Maybe it won't be $129, if there are no new features and No PPC and it's called Snow Leopard after Leopard, it may just be an add on for intel users. Say $50 to enhance intel Macs by using only hardware found in new Macs. Kind of like Microsoft did back in the Windows 98 days, you can get 98 and then windows plus (or whatever they called it)

Don't forget that the 30 months between Tiger and Leopard also included a transition to Intel which should be included. And I believe Jobs said he wanted to shorten the release times so 14 months wouldn't be outrageous, even with new features.

I will say this. Apple SOLD quite a few PPC computers to people right before they came out with Intel systems. If you think people who bought computers just over two years ago are going to take this lying down, you are mistaken. If Apple discontinued the PPc support 5 years after Intel was intro'd, so be it. It's not time yet. Leopard isn't even fully cooked yet. Apple SOLD me a $3200 Powerbook days before the Intel announcement. I should expect that they will not give their customers the shaft.

Also, "Snow Leopard (if that's the real name)" has no business being a paid for OS release if all it does is optimize and secure the system better. That is a service pack, point release, bug fix, etc. Surely Apple does not think its customers are total idiots, because that is what they are saying if they try to SELL it to you. It should be a free download. AND it should support PPC. No doubt about it.

If this rumour is true in any way, I'd expect it to be a build that is mainly for new Intel Macs. They come with install discs that only work their models anyway. But Apple would still support older machines on about a 5 year cycle so the next major release wold have to have two flavours, one with code for multiple types of machines and the one with code only for 64-bit Intel Macs.

You're missing the main point though. Leopard has a certain amount of features and a baselline level of support. APIs can be tweaked during the evolutionary process but Apple really can't "take" anything away. The rumors for 10.6 are that Apple is going to make some definitive moves towards removing support in some areas and optimizing the remaining supported hardware. If they were to drop PPC support they certainly couldn't market Leopard as the 50% PPC supported OS. Tech support nightmare.


You're neglecting to mention some salient data that explains the delay.

10.4 was the first OS that enabled support for Intel based Macintosh. Clearly that would increase the amount of work involved in developing Tiger as Apple is now developing and testing two distinct hardware platforms.

10.5 Leopard marks Apple's push into different platforms with the Apple TV and iPhone and potentiall yet another platform due this year.

One cannot take the data you've presented and extrapolate it anything meaningful without having a better historical context of the platform(s) involved.

I think your numbers are way off. Apple is NOT going to support PPC for another 2yrs from this WWDC.

That is a bunch of crap.

I am a professional and I will NOT pay for a bug fix/service pack/ point release, just because it has a code name and pretty packaging.

If apple goes this route, it destroys the good faith its customers have in them. Apple - the company that went out on a limb to try to get rid of DRM and keep a sales model instead of subscription. Apple, the SECURE hardware/ software company who's products "JUST WORK" - yeah right -- if they go this way, they are no better than MS (sure it will work - so long as you keep paying for the same thing - over... and over... and over...) If Apple does this, screw them.

You have a very foolhardy mentality here my freind. to quote you:

I depend on my computer to get things done quickly and reliably, and anything that aids in this task is more than welcome and easily worth a full OS upgrade fee (it wouldn't take long for it to pay for itself).

i think not. If you depend on your Mac to get just work, then Apple needs to make their OS jsut do it. You have already paid for it. You should not need to pay again, just so it does what it was supposed to already do in the first place. think for a second, man.

Apple will ahve the mindless drones who will agree with everything they do and even come up with some psycho rationale for it all (courtesy of the RDF factor). the rest of us will see through it and either hold off on purchases, or simply just become less enthused with the once shining knight of the computing industry. Paying for service packs is a bad trend to start. Don't drink the Kool-Aid so fast my friend.

rumours?

Dude, chill out. You are replying to a rumour as if it's true and seem to be getting worked up over it.


This is what happened to the last guy who got worked up over an Apple Insider rumour...

•

http://www.break.com/index/office-wo...ly-insane.html
• http://www.break.com/index/office-wo...ond-angle.html

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.

I'll never understood why people get worked up over rumours. Seriously, you're only looking at a portion of the information - there's no way to know 10.6 won't have any major features for sure. Why are people getting their knickers in a twist when it might not even be true at all? You truly think Apple would do something as big as stop Carbon apps and not tell the big publishers? If it's true it's a safe bet Adobe and co have known for some time.

Apple is not stupid. They do not randomly go around killing compatibility for some of the biggest professional applications. At the very least it would be a message to some developers to stop clinging to completely Carbon apps.

Mac OS X, version 10.6 will support Cocoa + Java applications.

Great. Can't wait for Leopard Revolutions then .

. . . 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'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:

1. Apple may provide virtualization environment (more transparent than Classic) for old apps.
2. 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!.
3. 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?

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.

Shhhhhhh. We don't discuss that.

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.

Ditto.

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.

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.

Thanks for the link. I'd agree with that as well.

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.

*No, really. Check it out, "MacOS X" it is not: http://flickr.com/photos/gernot/2554181096/