Evidently, you know nothing about how OS X development works and have never read single word from developers who do. Cocoa is a great framework for application development, but it's at a higher level of abstraction than base system APIs and thus unsuitable for certain types of software that requires a lower level approach. It's easier to maintain a cross platform code base using Carbon than Cocoa because Carbon as a set of APIs is more similar to the Win32 APIs than Cocoa. All of Blizzard's excellent cross platform games are Carbon based. There are also holes in Cocoa that are only filled by Carbon technologies. (There actually are developers who detest Cocoa as being feature incomplete and highly constraining to work with.) Your claim that Carbon slows down your computer because it's "legacy" is particularly dumb because Carbon apps can be more simply coded (additionally, C++ code is faster than ObjC); many end-users perceive Carbon apps as being faster than Cocoa apps, while Cocoa apps are usually regarded as more feature complete than their Carbon counterparts. Finally, notable developers have stated that one can make just as poor or just as excellent an application in either environment.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Mac OS X 10.6 Snow Leopard: Cocoa Finder and 64-Bit Changes
- Thread starter MacRumors
- Start date
- Sort by reaction score
First off, Steve Jobs has been quoted many times (Co-Interview with Bill Gates included) that Apple sees itself as a Software company.
Secondly, Were are you getting your numbers ?
Steve jobs may have said that, however from an analytical point of view Apple is a hardware company.
When you buy a Mac you buy the hardware, it just so happens that it ships with the Mac OS. Mac OS X is just an incentive for buying the hardware.
iPods, Macs, iPhones, Apple TV's, is where Apple makes its profits. Profits from software are the few million buying OS X for their older Mac, and of course Final Cut, Shake etc.
Apples software prices are extremely cheap because to use the software you must buy a Mac. Apple reduced the price of Shake from $6000 to $500. Apple bought Motion for millions and included it within Final Cut for free.
Now if Apple were to release OS X for PC's, you can see the price for Final Cut increasing 10 fold (except for actual Macs perhaps).
Yes, but why do you/we buy Apple products? why do you buy a Macbook or an iMac? It's because Mac OS X..it's because their software.
why iPhone is so great? it's because its software.
ipod? because software...
they have the hardware part, but the reason Apple have so much success is because the software in their products, not the hardware.
nowadays the hardware of a Mac is equal to a PC's..but the SOFTWARE is the key. That's what Steve Jobs meant.
If you bought a new system with Vista x64 installed, you might not be aware. At least 20% of new Vista systems are 64-bit.
Out of the 11 HP laptops listed as "new arrivals" at Best Buy, 9 come with 4GB of memory and 64-bit Vista.
http://news.cnet.com/8301-13924_3-10076795-64.html?tag=mncol
http://news.cnet.com/8301-13924_3-10076795-64.html?tag=mncol
As long as you make sure that any hardware or software you buy has the "Vista Logo", you could be unaware of the bitness. (Microsoft requires both x86 and x64 support in order to get the logo.)
ROTFLOL. I don't know whether to compare this to the amount of 64-bit software for OSX, or whether to ask if you realize that 32-bit software also runs on Vista x64.
And at least one important 64-bit program only runs on Windows x64 - Adobe Photoshop CS4
I'm sorry, but I disagree. HP (and others) wouldn't be putting Vista 64-bit on the majority of their new laptops and desktops if x64 was "a bag of hurt".
To the end user, it's mostly irrelevant whether any application is 32-bit or 64-bit. Very few apps need 64-bit, but today many (most?) new systems need at least 33-bits for memory addressing. (Nobody needs a 64-bit computer, but lots of people need a 33-bit or 34-bit one
)To the end user, it's mostly irrelevant whether an application package contains fat binaries that run on both 32-bit and 64-bit, or whether it contains a set of 32-bit binaries and a set of 64-bit binaries and installs the appropriate set.
When the end user runs software update, it's mostly irrelevant whether the system downloads 32-bit or 64-bit software.
Well, that is just broken. Its a link to an article which outlines that the 64bit version is currently only available *NOW* but nothing is actually said about 64bit in the final release. I wish people would actually read the notes instead of assuming that notes for *THAT* build mean that it is going to be bought through till the final product.
Getting back to 64bit - the majority of people won't be affected - even with OpenSolaris, for example, is 64bit, but the majority of user land applications are 32bit because 64bit makes non-sense what so ever. Also, given that one can compile in 32bit 'long mode', one can get the benefits of the 64bit environment without needing to be 64bit.
I am running windows 64bit and their are tons of programs for it. Windows 64bit can run 32bit apps so the "bitness" doesn't matter. Do you run windows 64bit?
Creative development with Adobe software in windows 64 is going to be orders of magnitude faster then osx.
As per the last sentence: whats the major improvement here then? Is Final Cut going to render HDV faster? Is Motion going to stop being one of the buggiest programs I've ever seen? BLU-RAY support goddammit?
Who was talking about Windows? We know you love Windows, but why did you bring it up here in this thread?
An by the way, fat binary isn't a problem. It works just fine.
Call me a stubborn old horse, but I do not agree. I don't always agree with what Steve says, but he makes a great point in clarifying that in the video.
People don't buy the iPhone (or iPod Touch) because of the hardware. They buy it for the OS, Multi-Touch user interface, iPod (or mini iTunes) music playback, and the applications you can load. That is all entirely software.
On the Macintosh systems, it is similar to the iPhone, lots of competition with more features (often better features on competition's computers), but it is OS-X, iLife, and pro apps that pull people in (and were Apple makes most of it's money).
Apple is a Software company that sells hardware. They make bright shiny products, but it is the software inside that makes them what they are, not the hardware that they now share with most every computer / phone manufacturer. And just because it isn't on the invoice when we buy our new systems, doesn't mean that iLife and OS X are Free! They do charge us for that software, and that is the only way they can get away with such high prices in comparison to comparable hardware on the market.
Dell, Gateway, Acer = Hardware companies
Apple = Software company that also makes their own hardware.
Just put one of those game machines with Blue-Ray on your network. Economically solved.
Rocketman
I agree that people use Macs for the software, but let's be realistic - it's the hardware sales that pays the bills.
I was replying to a post that was claiming that a universal installer was an advantage for Mac - just pointing out that Windows has the same.
Of course they do. Programs like TrimTheFat don't exist.
I doubt it. Creative development is also dependent on the interaction between the user and the computer.
People would often tell me their PC was faster than my Mac. I replied, "that may be true, but I'm faster using my Mac than a PC."
It's the entire chicken or the egg scenario here. In reality they both pay the bills in their current business model.
Computers existed before the Macintosh, the OS is what got it going. Touch screen phones existed before the iPhone, it was the OS and Multi-Touch that made that device popular.
If you like, I will agree that Apple is a software company that makes good money selling hardware. But in the end, Software is their focus, and hardware is made by them, to ensure their software experience is the best they can make it.
In my experience Fat Binaries (or Universal in Apple language) simply take up more space than single processor dedicated code. They don't take longer to load, and are just as stable as single processor coded versions. That software exists for those looking to save a few (to hundreds) megabytes of disk space.
will run well on the new netbooks
can't wait til january...it's using apple's new scaleable manufacturing process so the same design and materials can be scaled to different sizes...including 9 inches...
can't wait til january...it's using apple's new scaleable manufacturing process so the same design and materials can be scaled to different sizes...including 9 inches...
Too true. Adium got burnt in a huge way (probably a person-year of development time or more lost) by buying into Apple's statements about Java being a fully supported way to use Cocoa.
You're going to like some Snow Leopard changes.
Can't elaborate due to NDA, but they've definitely been listening when people complained about various issues in Cocoa.
not really because most books don't have alot of ram. 64bit apps can be slower than 32bit apps on small amounts of ram.
from the position of sombeody without a hefty commercial carbon baggage, i say move on, apple! no need to update obsolete api's with each new system iteration. carbon can remain in a (32bit) stasis, and that'd be ok as its app base will continue to function, but interested developers can migrate their apps to the api's that move on. heck, there's a constantly growing wave among mac developers who do not give a dime about carbon - the iphone wave.
As AidenShaw points out, Mac is playing catchup up some regards to Vista 64 bit machine numbers, the paucity of 64 bit software for OS X currently, and also that CS4 ain't going 64 bit for Mac (can it be done under Bootcamp/virtualisation?). Though Adobe's opening itself up for rivals to use this as an opportunity in the time it takes between June next year and CS5.
"To the end user, it's mostly irrelevant whether any application is 32-bit or 64-bit. Very few apps need 64-bit, but today most systems need at least 33-bits for memory addressing."
Currently. Hopefully Snow Leopard will actually show applications and uses that can use a Mac that goes beyond the previous 32 bit limitations. Maybe the RAM limitation will be the first to show up, as users can incrementally add more RAM, as their machine gets older, to give it more of a chance to keep up. Cheaper RAM prices at the moment are helping currently too. Whether that will remain for DDR3 at higher speeds and sizes remains to be seen.
Just to take another section from one of the articles used article too, for balance:
Regarding the Cell processor, wouldn't it make more sense to have it as an add on e.g. a PCI Express board, if it was at all feasible to incorporate it, or follow something like the IBM System z9 mainframe use (or Roadrunner use, if it would crossover). However, wouldn't it be competing against GPUs? You'd imagine Apple would want them to be talking the same language at least. Anyhow, not like Apple and Cell rumors are new - http://www.macsimumnews.com/index.php/archive/the_next_wave_apples_connection_to_the_cell_processor/
http://www.eweek.com/c/a/Apple/Is-There-a-Cell-Processor-in-Apples-Future/
http://lowendmac.com/musings/05/0309.html But then there are lots of rumors of all sorts of things: http://www.theinquirer.net/gb/inquirer/news/2008/09/03/potential-console-deal-intel
"To the end user, it's mostly irrelevant whether any application is 32-bit or 64-bit. Very few apps need 64-bit, but today most systems need at least 33-bits for memory addressing."
Currently. Hopefully Snow Leopard will actually show applications and uses that can use a Mac that goes beyond the previous 32 bit limitations. Maybe the RAM limitation will be the first to show up, as users can incrementally add more RAM, as their machine gets older, to give it more of a chance to keep up. Cheaper RAM prices at the moment are helping currently too. Whether that will remain for DDR3 at higher speeds and sizes remains to be seen.
Just to take another section from one of the articles used article too, for balance:
Regarding the Cell processor, wouldn't it make more sense to have it as an add on e.g. a PCI Express board, if it was at all feasible to incorporate it, or follow something like the IBM System z9 mainframe use (or Roadrunner use, if it would crossover). However, wouldn't it be competing against GPUs? You'd imagine Apple would want them to be talking the same language at least. Anyhow, not like Apple and Cell rumors are new - http://www.macsimumnews.com/index.php/archive/the_next_wave_apples_connection_to_the_cell_processor/
http://www.eweek.com/c/a/Apple/Is-There-a-Cell-Processor-in-Apples-Future/
http://lowendmac.com/musings/05/0309.html But then there are lots of rumors of all sorts of things: http://www.theinquirer.net/gb/inquirer/news/2008/09/03/potential-console-deal-intel
Well, in all fairness, it's still in the OS three years after being deprecated, so it wasn't as though Apple completely pulled the rug out from under them. I still use a Cocoa-Java application nearly every day (Cyberduck). That said, it did have a fairly short run (only 4 years IIRC), so I kinda see where they're coming from.
You're going to like some Snow Leopard changes.
I see I'm not the only one who's glad to see the dev love coming from Apple. I'm still thrilled about GC in Obj-C 2.0 (although I do think it encourages poor coding, that's a "these damn kids" rant for another time.)
I had a look at the Wikipedia entry for intel future processors - there is a section that states intel will be incorporating a co-processor, I'm wondering whether it is that monster Larrabee will be used as the co-processor. With that being said, given that Quickpath will be made available - nothing stopping them from using it in their Mac Pro range and optimise CODEC's to really push down the compression times.
Don't have the link on me, but I saw a recent Intel video showing how the GPU could put work onto the CPU, rather than the other way round (making it very useful for integrated graphics systems with decent CPU that aren't being taxed) - made a decent game performance change (10fps extra in some of the demos).
So the GPGPU will also perhaps be complemented with GPCPU