Was anybody else surprised that Jobs said nothing about 10.2? I was. I really did expect a sneek peak at it. Perhaps they'll just ship it when done and not bother to intro it.
Well we have all been focused on new hardware, iMacs and G5's etc OS X has been out of the lime light. I am not suprised that SJ really just kept his focus on the new consumer machine and the applications that go with it. he knows he is on stage and he just wants to keep hammering the message.
It doesn't matter how fast you machine is it is what you can do with it that counts.
So back to the subject what is the state of play with 10.2, are there any significent speed enhancements? Can OS X and the finder be made to run any faster.
You know MS has made huge profits by introducing biger bloated applications and OS's that cause up to upgrade our machines to improve the speed. I hope that Apple hasn't done the same thing with the finder. OS X is beautiful but on a 450 G3 it is still painfully slow. Is the only soloution a hardware upgrade or will apple allow us to get more use out of our existing machines by makeing the finder faster?
As for MS, I think they actually took a step in the right direction with XP professional. We timed a 1.8GHz P4 system at work. From powering on to machine waiting for you to log in was 30 seconds!! It was less time yet to actually log you on.
On my 266 G3 (Beige tower) I can get to the OSX login prompt in 1:20. The biggest chunk of time is that it sits at the smiley mac face for 40 seconds before going on.
I was wondering what sort of boot time OSX has on newer systems? If it is slow on other systems as well, think Apple will respond by shortenning boot-time in 10.2?
all i really want out of 10.2 is more streamlining...a more responsive UI and more optimized apps. on my 500mhz G3 imac, scrolling is oftentimes slow and booting/dragging/launching aren't up to OS9..not yet, anyway.
running top i was dismayed to find that itunes was taking 75% of my CPU at startup and 20-30% during MP3 playback. this really needs to be addressed as well. when OSX can run faster than 9 and hold a fairly moderate RAM footprint, then it will be an unqualified success. until that milestone is reached, OSX will not be an unqualified success.
I think that 10.2 will be a much quieter update. With 10.1 there were serious UI and speed issues that needed to be addressed in public. While OS X still has its issues, they are not huge enough to require the spotlight when they are fixed unless Apple adds some serious new wizardry to the OS. I think that apple *CAN* make OS X even faster. I find it hard to believe they would even make OS X if they couldn't make it fast. They obviously showed how dramatically they can improve the OS in just 6 months and I hope they choose to do it again, instead of using the slowness to drive new hardware sales.
<strong>I think 10.2 will bring OS X up to once and for all, OS 9's complete feature set.
and add a few cool things.</strong><hr></blockquote>
I think spring-loaded folders and USB print sharing are a lock. Add labels and I think you've got everything people miss from the old system (unless they simply miss the old system itself, naturally).
<strong>What good would the Finder being 64 bit be? I can see no imaginable benefit of this even when run on 64 bit hardware.
And really ponder why you would want Cocoa. A well written Carbon application should outperform a Cocoa app. (keyword well written)</strong><hr></blockquote>
Exactly!!
It baffles me to no end that people spout "geek-speak" and insist these technologies be incorporated when those people really don't understand anything about the tech, how it works, the benefits or the drawbacks.
I think the idiots just make themselves feel better by spreading FUD much like the Windows zealots do about...
Okay, okay, you get my point. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
there is no reason why a "well written" carbon app should perform better than a cocoa app. The only fundamental design difference that would slow a cocoa app over a carbon app is the fact the Objective-C uses dynamic messaging, and c-c++ does not. This adds overhead to messaging of objects, however, the majority of this overhead occurs in UI related code (app kit). Now, slow down a second before you say "the UI needs to be fast - cocoa sucks" because, the decrease in speed due to message passing is insignificant compared to the larger bottlenecks in the system: ie quartz/aqua, and even would be insignificant without all the fancy quartz glitz. so, in general - a "well written" carbon app should not perform better than a cocoa app - the dynamic messaging is inconsequential overhead, and any time critical code that taxed the system would most likely be written in C-C++ in either a cocoa or carbon app (a cocoa app need not be written ONLY in objective-C, just the UI portion), resulting in the same execution time for that section of code.
Would a cocoa finder be better? well, there is no simple answer. It CAN be said that the cocoa application framework provides superior programmer efficiency, resulting in more work getting done in less time. This could have resulted in a more advanced finder than what we have today, given the same amount of effort. There are numerous other reasons why cocoa just plain rocks. In the end, it doesn't REALLY matter what API it is written in. A good example is IE 6 on windows. It is a good app, but somewhere underneath it is Win32 and the infamous WinProc/WinMain code. Win32 SUCKS, but a good app was written in it. Carbon does not suck, and Cocoa is a great deal better yet. bottom line - a good finder could be written in any API, some API's are more efficient...
It baffles me to no end that people spout "geek-speak" and insist these technologies be incorporated when those people really don't understand anything about the tech, how it works, the benefits or the drawbacks.
I think the idiots just make themselves feel better by spreading FUD much like the Windows zealots do about...
Okay, okay, you get my point. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
I think people are referring to Cocoa since the API is more mature and complete. Carbon has not yet inherited all the features built into the OS, so it is still behind. Has the new Carbon Lib altered the event model? If not this means Carbon also is still behind Cocoa in terms of multithreading/multitasking.
Whatever API the next Finder will be using: fix it Apple!
Comments
It doesn't matter how fast you machine is it is what you can do with it that counts.
So back to the subject what is the state of play with 10.2, are there any significent speed enhancements? Can OS X and the finder be made to run any faster.
You know MS has made huge profits by introducing biger bloated applications and OS's that cause up to upgrade our machines to improve the speed. I hope that Apple hasn't done the same thing with the finder. OS X is beautiful but on a 450 G3 it is still painfully slow. Is the only soloution a hardware upgrade or will apple allow us to get more use out of our existing machines by makeing the finder faster?
<img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
As for MS, I think they actually took a step in the right direction with XP professional. We timed a 1.8GHz P4 system at work. From powering on to machine waiting for you to log in was 30 seconds!! It was less time yet to actually log you on.
On my 266 G3 (Beige tower) I can get to the OSX login prompt in 1:20. The biggest chunk of time is that it sits at the smiley mac face for 40 seconds before going on.
I was wondering what sort of boot time OSX has on newer systems? If it is slow on other systems as well, think Apple will respond by shortenning boot-time in 10.2?
<strong>I certainly hope Apple can get OSX faster.
We timed a 1.8GHz P4 system at work. From powering on to machine waiting for you to log in was 30 seconds!
On my 266 G3 (Beige tower) I can get to the OSX login prompt in 1:20.
</strong><hr></blockquote>
So, a brand-new P4 system launches Windows in one-third of the amount of time that a four year-old Mac launches OS X? This is news?
and add a few cool things.
running top i was dismayed to find that itunes was taking 75% of my CPU at startup and 20-30% during MP3 playback. this really needs to be addressed as well. when OSX can run faster than 9 and hold a fairly moderate RAM footprint, then it will be an unqualified success. until that milestone is reached, OSX will not be an unqualified success.
<strong>I think 10.2 will bring OS X up to once and for all, OS 9's complete feature set.
and add a few cool things.</strong><hr></blockquote>
I think spring-loaded folders and USB print sharing are a lock. Add labels and I think you've got everything people miss from the old system (unless they simply miss the old system itself, naturally).
Ah no the point was that XP boots up faster than Win2k on the same hardware.
It most likely will be demoed at Macworld Tokyo in March and shipping in July and Macworld New York.
<strong>I hope to see a 64-bit Cocoa Finder but I don't know if it's too soon for this.</strong><hr></blockquote>
What good would the Finder being 64 bit be? I can see no imaginable benefit of this even when run on 64 bit hardware.
And really ponder why you would want Cocoa. A well written Carbon application should outperform a Cocoa app. (keyword well written)
<strong>What good would the Finder being 64 bit be? I can see no imaginable benefit of this even when run on 64 bit hardware.
And really ponder why you would want Cocoa. A well written Carbon application should outperform a Cocoa app. (keyword well written)</strong><hr></blockquote>
Exactly!!
It baffles me to no end that people spout "geek-speak" and insist these technologies be incorporated when those people really don't understand anything about the tech, how it works, the benefits or the drawbacks.
I think the idiots just make themselves feel better by spreading FUD much like the Windows zealots do about...
Okay, okay, you get my point. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
[ 01-11-2002: Message edited by: starfleet ]</p>
Would a cocoa finder be better? well, there is no simple answer. It CAN be said that the cocoa application framework provides superior programmer efficiency, resulting in more work getting done in less time. This could have resulted in a more advanced finder than what we have today, given the same amount of effort. There are numerous other reasons why cocoa just plain rocks. In the end, it doesn't REALLY matter what API it is written in. A good example is IE 6 on windows. It is a good app, but somewhere underneath it is Win32 and the infamous WinProc/WinMain code. Win32 SUCKS, but a good app was written in it. Carbon does not suck, and Cocoa is a great deal better yet. bottom line - a good finder could be written in any API, some API's are more efficient...
<strong>
Exactly!!
It baffles me to no end that people spout "geek-speak" and insist these technologies be incorporated when those people really don't understand anything about the tech, how it works, the benefits or the drawbacks.
I think the idiots just make themselves feel better by spreading FUD much like the Windows zealots do about...
Okay, okay, you get my point. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
[ 01-11-2002: Message edited by: starfleet ]</strong><hr></blockquote>
Whatever API the next Finder will be using: fix it Apple!