No, that was not a troll - the A4/A5 chips are based upon ARM chips
What the heck is an "ARM chip"? ARM is fabless, so it's not a "chip that ARM fabbed". If it's a chip whose main processor runs the ARM instruction set architecture, then the A4/A5 are "ARM chip"s.
but have been modified to suit Apple's needs
ARM is in the "intellectual property" business; all sorts of vendors put ARM cores into various systems-on-a-chip - the A4 and A5 are hardly unique in that regard.
The ARM support in Darwin is pretty much common to all ARM cores (although, as the thesis noted, the ARMv5 support had bitrotted a bit). There's also probably core-specific and system-on-a-chip-specific stuff in there, but that stuff is probably different between the various non-A4/A5 chips used in the older iOS machines, so it's not as if A4/A5 are Some Unique New Thing distinct from Boring Old ARM.
What I took from the article was that Apple would be taking a brand new ARM chip
What I took from the thesis (rather than from an article written by somebody who may not have understood what the guy was saying in the thesis) is that Apple would be taking the MV88F6281 ARM chip from Marvell - which is hardly new as it dates back to at least 2008 (in the References section of the thesis it cites Marvell's "8F6281 Hardware Specifications document" and gives a publication date of December 1, 2008) - and doing something on it (not entirely surprisingly, the thesis says nothing whatsoever about what that "something" might be). As the thesis says:
The goal of this project is to get Darwin into a workable state on the MV88F6281 processor so that other teams can continue their work on this platform.
and then using it to drive Mac OS.
The thesis, other than having "ARMing the SnowLeopard" as its subtitle and making the incomplete statement that "Darwin is the lower half of the Mac OSX operating system" (it is, but it's also the lower half of the iOS operating system), doesn't say much about porting "Mac OS". In fact, he repeatedly speaks of "embedded" platforms
You would then have three unique Apple architectures to develop for - iOS, Intel-based Mac OS, and ARM-based Mac OS.
Which has to do with two separate things - instruction-set differences and OS platform differences (iOS vs. Mac OS X).
Yeah, because Apple have been so eager to have their OSes run on other people's hardware....
Apple would probably be delighted to have Other People's ARM Tablets incapable of running iOS (not that those tablets are likely to have the exact hardware necessary to run it anyway).
And considering an intern could port a complete OS port in a mere 12 weeks, shows how portable it is.
Yup, and one of the bits of portability that helped was that it had already been ported to ARM. To quote The Fine Thesis:
When I began this project, development for the MV88F6281 was being done with a train from a different ARM based project. This made sense, because both projects are ARM based, and thus share a lot of code, libraries and low-level platform support.
so he was using the existing ARM support in Darwin. The problem is that the code in question didn't work on the MV88F6281 for a variety of reasons, including bitrot in the ARMv5 support, and that's what he had to deal with.
And indeed I recall rumours that OS-X was running on Intel from before the time the rumours came that Apple was planning to switch to Intel.
Yes, it was. (That's the "secret double life" to which Jobs referred in the MacIntel announcement.)
I suppose portability is simply part of the demands by management. I don't think Microsoft will have such an easy time if they were ever to switch to another architecture.
Yeah, it'll probably be hard to port an OS core that was originally developed on the Intel i860 and moved to MIPS, to make sure x86isms didn't creep in; admittedly, perhaps after the non-x86 versions were killed off, one by one, more such stuff crept in, but perhaps the OS core has been running on ARM for a while "just in case". However, the stuff above it might have more x86isms in it.
Intel? You mean x86? Intel would be more like IA-32 which apple never used.
Yes, they did - the original x86 Macs used the Yonah Core Duo and Core Solo chips, which were 32-bit-only.
Plus it is more like AMD since most macs use x86_64.
All current Macs use x86-64 processors, with an instruction set whose 32-bit version was designed by Intel and extended to 64 bits by AMD and with Intel extensions (the later flavors of SSE), and manufactured by Intel. But "x86" is probably the best term here, as it's width-neutral and doesn't mention a particular vendor.
someone needs to update Wikipedia on this then: http://en.wikipedia.org/wiki/IOS
from that article: "iOS is derived from Mac OS X, with which it shares the Darwin foundation, and is therefore a Unix-like operating system."
That's entirely correct.
Unless I see something otherwise, I would believe that iOS is Darwin based as opposed to the multi-touch tiny screen and GUI is based on the desktop OS X GUI.
Yup. The ObjectiveC OS X GUI code is AppKit; the iOS GUI code is UIKit.
I've heard that they have moved features from iOS GUI to the desktop so iOS apps could run on the desktop but not the other way around.
More like moving some concepts, or implementing concepts with a similar model (e.g., the auto-save stuff; I'm not sure whether that exists in a fashion with similar APIs in iOS, but iOS apps really should try to keep state in stable storage, so that if they're shut down and restarted they pick up from where they left off).
I'll keep looking for evidence of iOS being only based on OS X GUI components.
So what does this mean for all the people who were saying that the iPhone runs a stripped down version of OS X? I've always chalked it down to the fanboys wanting to believe OS X was on every Mac product. But this news is living proof that no flavor of OS X was ever part of iOS, right? iOS and OS X are completely distinct operating systems. The only thing they have in common is they both were invented in Cupertino, CA.
What it means is that everybody should read this person's comment (which was posted anonymously, so it may take a while before it gets moderated up enough for enough people to notice it) before going further.
What he ported was Darwin, not Mac OS X in its entirety; Darwin also underlies iOS. iOS and Mac OS X have some common stuff atop Darwin (for example, Core Foundation and Foundation) and some different stuff atop that and atop Darwin (for example, AppKit vs. UIKit).
Oh, and what he ported it to was a particular ARMv5 development system; the ARMv5 support in Darwin was suffering from bitrot, which he had to fix. (Little of the ARM support in Darwin is in the open-source part of Darwin, but it's there in the iPhone/iPod touch/iPad/second-generation Apple TV.)
Mac OS X programs mostly are 'fat binaries'. If you right-click and 'view contents' of an application you'll see that it's really just a directory filled with files. You'll often see that there are x86, x64, and PPC binaries in the same package, sharing the same 'resource' files (which are now actually files instead of HFS magic).
Actually, as BasilBrush noted, there are app bundles of the sort you describe, but fat binaries involve packing multiple chunks of executable code in the same file; that allows fat versions of code that isn't distributed as application or framework or plugin bundles, such as the UN*X-layer libraries, commands, and daemons.
It would be trivial to add more architectures to Mac OS X. Basically all you need is a compiler (which already exists) and for developers to actually target it.
...and a binary-to-binary translator, along the lines of Rosetta, to deal with all the apps that haven't yet been recompiled (and had any assembler-language or otherwise platform-specific parts rewritten).
tl;dr version of the OS News article - it's just a port of Darwin, using the existing ARM support, to an ARMv5 platform, that included fixing bitrot in the ARMv5 support.
One undergraduate spending 12 weeks porting Darwin (!) to a new CPU architecture
And it's not really very "new" - the architecture in question is ARMv5, and there already exists a port to newer versions of the ARM architecture (it's in these little-known things called "iPhones" and "iPads" and "iPod touches" and "second-generation Apple TVs"), so a lot of what he had to do, as indicated in The Fine Intern Thesis, was deal with bitrot in ARMv5 support (perhaps some early work on what is currently called iOS involved ARMv5 development platforms, but I don't think any of the machines that ship with iOS have ARMv5 processors in them).
TFA says he ported Darwin - the open-source version of the OS X kernel
Kernel and core bits of userland, actually.
What's more, what he ported was the (not-completely-open-source) ARM version of Darwin (little if any of ARM support is open-source), which already exists - it lives, for example, in every one of those mobile phones with the apple-with-a-bite-out-of-it logo on the back, for example - and what he ported it to was an ARMv5 platform, and a lot of difficulties were due to bitrot in the ARMv5 support, as stated in The Fine Intern Thesis
So, as you say, this says little about porting Mac OS X to ARM.
(If I could post in this thread and moderate your posting up by 10^10^100, in the hopes that everybody who thinks this means "OMG APPLE'S BUSY PORTING MAC OS X TO ARM!!!!!111ONE!!!!!!", I would. Most of the discussion that this report has engendered all over the Intarwebs is a real case of "teh stoopid, it burns!")
The Sprint and Verizon (and Au) networks are an evolutionary dead-end, so I wouldn't expect a lot of people to be working on inter-operability with them beyond the minimum necessary to make things work. Note that Au is rolling out LTE, which will put them on the GSM Alliance track. Their CDMA-2000 network will be left for voice only for some years, however. I expect a similar situation will follow in the US.
Verizon is rolling out LTE as well, and Sprint will be doing so as well, so, yes, it appears the US situation is similar to the Australian situation. Telus are "eventually" doing LTE, and Bell Canada are already doing HSPA+ and LTE, so it looks as if Canada are going the same way. I suspect any other markets that still use cdmaONE/CDMA2000 protocol stack are doing similar things, given that Qualcomm killed off UWB, making cdmaONE/CDMA2000 a dead end.
Still, CDMA-2000 and W-CDMA are very different technologies in some ways (aside from both using CDMA), and thus you can't expect one phone to work on both, unless they built both systems into it, which would raise the cost.
CDMA as a multiplexing technology is superior to TDMA.
CDMA is not superior to GSM, which happens to use TDMA.
The second paragraph is probably best stated as "Qualcomm's protocol stack, which happens to use CDMA in its radio interface, is not overall superior to the GSM protocol stack, which happens to use TDMA in its radio interface, or GSM's 3G successor, UMTS, which uses CDMA in its radio interface". If the term "CDMA" could be banned for use when referring to protocol stacks/networks/etc., that would be ideal, as maybe people would stop confusing Code Division Multiplexed Access with cdmaONE/CDMA2000, but people are too used to talking about "CDMA" phones and "CDMA" carriers and so on when they're specifically referring to cdmaONE and CDMA2000 (heck, see the title of the story), so that's not likely to ever happen. Maybe LTE will finally get rid of the confusion (and the "two different incompatible protocol stacks" and "sorry, no SIM card for you!" stuff).
Only in the Americas do CDMA2000 networks still use MEID for authentication, as far as I know.
Only in the USA, as far as I know... here in Canada, Telus/Bell (and their subsidiaries and hangers-on) are using a WCDMA/HSPA network
...which is not a CDMA2000 network.
on 850/1900, and they've switched to SIM cards too. They do still support CDMA devices, as they've sold them, but they don't sell them any more.
So it sounds as if they switched from cdmaONE and/or CDMA2000 to UMTS, so it's not surprising that they switched to SIM cards.
The only other major players in the country were using GSM with SIM cards all along.
At least from what other commenters here have said, I have the impression that the GSM and UMTS standards require that phones have SIM cards.
Actually, I think even in the USA, they've changed their tune... Verizon used to be the only holdout, and a quick search of their website shows that you can get a SIM card for their network now.
A quick search of their website for "SIM" turns up a bunch of pages that say "4G", so I suspect they switched because they're going to LTE, which is the successor to UMTS, and which I suspect continues any SIM card requirements that GSM and UMTS have.
T-Mob was on GSM since the beginning, and you've been able to get a SIM card for ATT for years now.
The latter is because AT&T's network is now a GSM/UMTS/LTE network.
So the North American phones with subscriber identity cards appear to be GSM, UMTS, or LTE phones. I think those cards are optional in the cdmaONE and CDMA2000 specifications, and US carriers, at least, chose not to offer phones that have them, perhaps because that'd make it too easy to switch carriers. Dunno about Canadian cdmaONE/CDMA2000 carriers.
In Japan, they also have W-CDMA (UMTS), but at least the phones there typically use uSIM cards, which just happen to be similar to GSM SIM cards.
Gee, it's almost as if UMTS were developed as a successor to GSM, by a lot of the same people, and had the same requirement for the subscriber's identity being on a removable module... no, that couldn't be.
You're close. GSM won the worldwide competition for a few reasons, but technical superiority was not one of them.You can see that in the fact that UMTS as successor to GSM actually reuses a lot of stuff from CDMA.
Yeah, it uses this thing called "Code Division Multiple Access", which I think comes from CDMA:-). I don't know what stuff UMTS took from cdmaONE/CDMA2000 other than the notion of using Code Division Multiple Access.
"CDMA" as a general technology, or "CDMA" as used in mobile phones? If the latter, are you certain that CDMA mobile phones were broadly deployed before GSM mobile phones?
Actually, there's a lot more to UMTS than just W-CDMA - W-CDMA is just the radio interface; UMTS includes the "higher layers" referred to below.
Never mind that the CDMA in US is CDMA2000.
For "CDMA" in the sense of "CDMA as in the Qualcomm protocol stacks", yes; for "CDMA" in the sense of "Code Division Multiple Access", there might still be cdmaONE networks and phones (2G) and there are definitely UMTS networks and phones (3G W-CDMA, but not CDMA2000).
So while UMTS and CDMA2k shares the base layer encoding, the higher layers are very different.
I'm not sure they even share the base layer encoding beyond "both using Code Division Multiple Access"; the CDMA2000 and W-CDMA radio interfaces are, I think, different.
Are you saying that CDMA2000, which I think is generally considered "3G", is W-CDMA - not just CDMA, as in "Code Division Multiple Access", but "W-CDMA", as in "the Wideband Code Division Multiple Access mechanism as specified by 3GPP specifications"? Or by "3G" do you just mean "the 3G successor to GSM"?
No, it's actually far far far more fragmented than that. It's not anywhere near the GSM market crying and picking up CDMA.
Read up, it'll help you. Here's a good start, and you can extend your knowledge into more technical realms once you get the basics down: http://gizmodo.com/5637136/giz-explains-gsm-vs-cdma
Actually, a large part of the problem is that "CDMA" is used as a term to describe two different things:
the Code Division Multiple Access multiplexing technology, which is used in a number of places including GPS, Qualcomm's cdmaONE and CDMA2000, and the 3GPP's UMTS;
the Qualcomm cdmaONE and CDMA2000 mobile phone standards.
When people talk about "CDMA" phones, they usually mean it in the second sense, so they don't consider UMTS phones "CDMA" phones, the fact that, when running on a UMTS network, they use Code Division Multiple Access, in the form of W-CDMA, nonwithstanding.
The article you point to uses it in both senses; for example, it says
GSM and CDMA both serve as shorthand for different mobile phone technologies. GSM stands for Global System for Mobile Communications; it's the world's most prolific mobile standard (a standard being a set of rules and suggestions about how a mobile network should work). CDMA stands for Code Division Multiple Access—in the context of cellphones and mobile networks, people tend to use it interchangeably to refer to two different mobile standards: CDMAOne or CDMA 2000.
where the last sentence uses it in the latter sense, and also says
What's the core difference? It all has to do with the way your data is converted into the radio waves that your cellphone broadcasts and receives. To keep from lulling you to sleep with the deep dive, I'll just scratch the surface and say that GSM divides the frequency bands into multiple channels so that more than one user can place a call through a tower at the same time; CDMA networks layer digitized calls over one another, and unpack them on the back end with sequence codes.
which uses it in the former sense. They barely mention UMTS, and don't bother mentioning that UMTS also "[layers] digitized calls over one another, and unpack them on the back end with sequence codes".
So, no, the GSM market didn't "pick up CDMA" in the sense of dumping all the GSM protocols in favor of the cdmaONE/CDMA2000 protocols. It did, however, "pick up CDMA" in the sense that the UMTS follow-on to GSM uses Code Division Multiple Access.
Come on, seriously, research what you say before you say it!
Come on, seriously, look for the sarcasm in a posting before you respond to it!
everyone knows that GSM is being run on the AT&T network
Not true, given that the person to whom I responded didn't know that, or he wouldn't have said "Come on, America, at least move onto GSM. Now that it's all being ripped out and replaced with 3G there's a lot of GSM hardware on the second-hand market. It's not even expensive." - yeah, maybe they could use some of the GSM hardware that AT&T threw out as part of their upgrades to UMTS/HSDPA/etc., except that Verizon is too busy buying LTE equipment to bother (another thing he apparently wasn't aware of).
Or, as I said, "The early noughts called, they want their snark about the US mobile phone network back...."
Yeah, AT&T's pages don't mention GSM very much - they keep going on about some "LTE" thing. Hopefully they'll be upgrading from that weird technology to standard GSM some day....
(Yes, I know. The early noughts called, they want their snark about the US mobile phone network back....)
Slashdot Mirror
No, that was not a troll - the A4/A5 chips are based upon ARM chips
What the heck is an "ARM chip"? ARM is fabless, so it's not a "chip that ARM fabbed". If it's a chip whose main processor runs the ARM instruction set architecture, then the A4/A5 are "ARM chip"s.
but have been modified to suit Apple's needs
ARM is in the "intellectual property" business; all sorts of vendors put ARM cores into various systems-on-a-chip - the A4 and A5 are hardly unique in that regard.
The ARM support in Darwin is pretty much common to all ARM cores (although, as the thesis noted, the ARMv5 support had bitrotted a bit). There's also probably core-specific and system-on-a-chip-specific stuff in there, but that stuff is probably different between the various non-A4/A5 chips used in the older iOS machines, so it's not as if A4/A5 are Some Unique New Thing distinct from Boring Old ARM.
What I took from the article was that Apple would be taking a brand new ARM chip
What I took from the thesis (rather than from an article written by somebody who may not have understood what the guy was saying in the thesis) is that Apple would be taking the MV88F6281 ARM chip from Marvell - which is hardly new as it dates back to at least 2008 (in the References section of the thesis it cites Marvell's "8F6281 Hardware Specifications document" and gives a publication date of December 1, 2008) - and doing something on it (not entirely surprisingly, the thesis says nothing whatsoever about what that "something" might be). As the thesis says:
and then using it to drive Mac OS.
The thesis, other than having "ARMing the SnowLeopard" as its subtitle and making the incomplete statement that "Darwin is the lower half of the Mac OSX operating system" (it is, but it's also the lower half of the iOS operating system), doesn't say much about porting "Mac OS". In fact, he repeatedly speaks of "embedded" platforms
You would then have three unique Apple architectures to develop for - iOS, Intel-based Mac OS, and ARM-based Mac OS.
Which has to do with two separate things - instruction-set differences and OS platform differences (iOS vs. Mac OS X).
This could make MIcrosoft's demand that OEM's make ARM based hardware Microsoft exclusive a bit more interesting...
http://linux.slashdot.org/story/12/01/14/0236244/microsoft-taking-aggressive-steps-against-linux-on-arm
Yeah, because Apple have been so eager to have their OSes run on other people's hardware....
Apple would probably be delighted to have Other People's ARM Tablets incapable of running iOS (not that those tablets are likely to have the exact hardware necessary to run it anyway).
Any PPCisms were stripped out during the transition to x86-64 so the code is 32/64bit clean.
Perhaps you meant "32-bitisms"? 10.4.11 had PPC32/PPC64 and x86/x86-64 builds; the first 64-bit platform for Mac OS X was PPC64, not x86-64.
And considering an intern could port a complete OS port in a mere 12 weeks, shows how portable it is.
Yup, and one of the bits of portability that helped was that it had already been ported to ARM. To quote The Fine Thesis:
so he was using the existing ARM support in Darwin. The problem is that the code in question didn't work on the MV88F6281 for a variety of reasons, including bitrot in the ARMv5 support, and that's what he had to deal with.
And indeed I recall rumours that OS-X was running on Intel from before the time the rumours came that Apple was planning to switch to Intel.
Yes, it was. (That's the "secret double life" to which Jobs referred in the MacIntel announcement.)
I suppose portability is simply part of the demands by management. I don't think Microsoft will have such an easy time if they were ever to switch to another architecture.
Yeah, it'll probably be hard to port an OS core that was originally developed on the Intel i860 and moved to MIPS, to make sure x86isms didn't creep in; admittedly, perhaps after the non-x86 versions were killed off, one by one, more such stuff crept in, but perhaps the OS core has been running on ARM for a while "just in case". However, the stuff above it might have more x86isms in it.
Intel? You mean x86? Intel would be more like IA-32 which apple never used.
Yes, they did - the original x86 Macs used the Yonah Core Duo and Core Solo chips, which were 32-bit-only.
Plus it is more like AMD since most macs use x86_64.
All current Macs use x86-64 processors, with an instruction set whose 32-bit version was designed by Intel and extended to 64 bits by AMD and with Intel extensions (the later flavors of SSE), and manufactured by Intel. But "x86" is probably the best term here, as it's width-neutral and doesn't mention a particular vendor.
Sounds like standard intern hazing.
"Hey, Tim, take this source code (*drops huge book of source on desk*) and port it to... uh... ARM."
Try "Hey, Tim, take this source code and get the ARMv5 support working on this development system; watch out for the bitrot...."
So he spent 12 weeks porting a kernel that had already been ported 3 years ago?
Porting it to a development system that had a processor with an older version of the ARM architecture support for which had bit-rotted.
iOS and Mac OS X are already the same kernel.
And much of the same lower-level userland.
Of is the real story that he was back porting lion advancements to the iOS version.
Where was that mentioned in his thesis?
someone needs to update Wikipedia on this then: http://en.wikipedia.org/wiki/IOS from that article: "iOS is derived from Mac OS X, with which it shares the Darwin foundation, and is therefore a Unix-like operating system."
That's entirely correct.
Unless I see something otherwise, I would believe that iOS is Darwin based as opposed to the multi-touch tiny screen and GUI is based on the desktop OS X GUI.
Yup. The ObjectiveC OS X GUI code is AppKit; the iOS GUI code is UIKit.
I've heard that they have moved features from iOS GUI to the desktop so iOS apps could run on the desktop but not the other way around.
More like moving some concepts, or implementing concepts with a similar model (e.g., the auto-save stuff; I'm not sure whether that exists in a fashion with similar APIs in iOS, but iOS apps really should try to keep state in stable storage, so that if they're shut down and restarted they pick up from where they left off).
I'll keep looking for evidence of iOS being only based on OS X GUI components.
No need - you won't find any.
So what does this mean for all the people who were saying that the iPhone runs a stripped down version of OS X? I've always chalked it down to the fanboys wanting to believe OS X was on every Mac product. But this news is living proof that no flavor of OS X was ever part of iOS, right? iOS and OS X are completely distinct operating systems. The only thing they have in common is they both were invented in Cupertino, CA.
What it means is that everybody should read this person's comment (which was posted anonymously, so it may take a while before it gets moderated up enough for enough people to notice it) before going further.
What he ported was Darwin, not Mac OS X in its entirety; Darwin also underlies iOS. iOS and Mac OS X have some common stuff atop Darwin (for example, Core Foundation and Foundation) and some different stuff atop that and atop Darwin (for example, AppKit vs. UIKit).
Oh, and what he ported it to was a particular ARMv5 development system; the ARMv5 support in Darwin was suffering from bitrot, which he had to fix. (Little of the ARM support in Darwin is in the open-source part of Darwin, but it's there in the iPhone/iPod touch/iPad/second-generation Apple TV.)
Mac OS X programs mostly are 'fat binaries'. If you right-click and 'view contents' of an application you'll see that it's really just a directory filled with files. You'll often see that there are x86, x64, and PPC binaries in the same package, sharing the same 'resource' files (which are now actually files instead of HFS magic).
Actually, as BasilBrush noted, there are app bundles of the sort you describe, but fat binaries involve packing multiple chunks of executable code in the same file; that allows fat versions of code that isn't distributed as application or framework or plugin bundles, such as the UN*X-layer libraries, commands, and daemons.
It would be trivial to add more architectures to Mac OS X. Basically all you need is a compiler (which already exists) and for developers to actually target it.
...and a binary-to-binary translator, along the lines of Rosetta, to deal with all the apps that haven't yet been recompiled (and had any assembler-language or otherwise platform-specific parts rewritten).
Please read this OS News article, which explains why this does not mean "Mac OS X was ported to ARM", and the actual thesis before commenting.
tl;dr version of the OS News article - it's just a port of Darwin, using the existing ARM support, to an ARMv5 platform, that included fixing bitrot in the ARMv5 support.
One undergraduate spending 12 weeks porting Darwin (!) to a new CPU architecture
And it's not really very "new" - the architecture in question is ARMv5, and there already exists a port to newer versions of the ARM architecture (it's in these little-known things called "iPhones" and "iPads" and "iPod touches" and "second-generation Apple TVs"), so a lot of what he had to do, as indicated in The Fine Intern Thesis, was deal with bitrot in ARMv5 support (perhaps some early work on what is currently called iOS involved ARMv5 development platforms, but I don't think any of the machines that ship with iOS have ARMv5 processors in them).
TFA says he ported Darwin - the open-source version of the OS X kernel
Kernel and core bits of userland, actually.
What's more, what he ported was the (not-completely-open-source) ARM version of Darwin (little if any of ARM support is open-source), which already exists - it lives, for example, in every one of those mobile phones with the apple-with-a-bite-out-of-it logo on the back, for example - and what he ported it to was an ARMv5 platform, and a lot of difficulties were due to bitrot in the ARMv5 support, as stated in The Fine Intern Thesis
So, as you say, this says little about porting Mac OS X to ARM.
(If I could post in this thread and moderate your posting up by 10^10^100, in the hopes that everybody who thinks this means "OMG APPLE'S BUSY PORTING MAC OS X TO ARM!!!!!111ONE!!!!!!", I would. Most of the discussion that this report has engendered all over the Intarwebs is a real case of "teh stoopid, it burns!")
The Sprint and Verizon (and Au) networks are an evolutionary dead-end, so I wouldn't expect a lot of people to be working on inter-operability with them beyond the minimum necessary to make things work. Note that Au is rolling out LTE, which will put them on the GSM Alliance track. Their CDMA-2000 network will be left for voice only for some years, however. I expect a similar situation will follow in the US.
Verizon is rolling out LTE as well, and Sprint will be doing so as well, so, yes, it appears the US situation is similar to the Australian situation. Telus are "eventually" doing LTE, and Bell Canada are already doing HSPA+ and LTE, so it looks as if Canada are going the same way. I suspect any other markets that still use cdmaONE/CDMA2000 protocol stack are doing similar things, given that Qualcomm killed off UWB, making cdmaONE/CDMA2000 a dead end.
Still, CDMA-2000 and W-CDMA are very different technologies in some ways (aside from both using CDMA), and thus you can't expect one phone to work on both, unless they built both systems into it, which would raise the cost.
Well, yes, one such phone costs USD 199 and above; dunno what other phones use chips capable of handling both CDMA2000's air interface and W-CDMA.
CDMA as a multiplexing technology is superior to TDMA.
CDMA is not superior to GSM, which happens to use TDMA.
The second paragraph is probably best stated as "Qualcomm's protocol stack, which happens to use CDMA in its radio interface, is not overall superior to the GSM protocol stack, which happens to use TDMA in its radio interface, or GSM's 3G successor, UMTS, which uses CDMA in its radio interface". If the term "CDMA" could be banned for use when referring to protocol stacks/networks/etc., that would be ideal, as maybe people would stop confusing Code Division Multiplexed Access with cdmaONE/CDMA2000, but people are too used to talking about "CDMA" phones and "CDMA" carriers and so on when they're specifically referring to cdmaONE and CDMA2000 (heck, see the title of the story), so that's not likely to ever happen. Maybe LTE will finally get rid of the confusion (and the "two different incompatible protocol stacks" and "sorry, no SIM card for you!" stuff).
Protocolwise CDMA only please.
So you're fine with UMTS (which uses CDMA) but not with LTE (which uses OFDMA)?
Only in the Americas do CDMA2000 networks still use MEID for authentication, as far as I know.
Only in the USA, as far as I know... here in Canada, Telus/Bell (and their subsidiaries and hangers-on) are using a WCDMA/HSPA network
...which is not a CDMA2000 network.
on 850/1900, and they've switched to SIM cards too. They do still support CDMA devices, as they've sold them, but they don't sell them any more.
So it sounds as if they switched from cdmaONE and/or CDMA2000 to UMTS, so it's not surprising that they switched to SIM cards.
The only other major players in the country were using GSM with SIM cards all along.
At least from what other commenters here have said, I have the impression that the GSM and UMTS standards require that phones have SIM cards.
Actually, I think even in the USA, they've changed their tune... Verizon used to be the only holdout, and a quick search of their website shows that you can get a SIM card for their network now.
A quick search of their website for "SIM" turns up a bunch of pages that say "4G", so I suspect they switched because they're going to LTE, which is the successor to UMTS, and which I suspect continues any SIM card requirements that GSM and UMTS have.
T-Mob was on GSM since the beginning, and you've been able to get a SIM card for ATT for years now.
The latter is because AT&T's network is now a GSM/UMTS/LTE network.
So the North American phones with subscriber identity cards appear to be GSM, UMTS, or LTE phones. I think those cards are optional in the cdmaONE and CDMA2000 specifications, and US carriers, at least, chose not to offer phones that have them, perhaps because that'd make it too easy to switch carriers. Dunno about Canadian cdmaONE/CDMA2000 carriers.
In Japan, they also have W-CDMA (UMTS), but at least the phones there typically use uSIM cards, which just happen to be similar to GSM SIM cards.
Gee, it's almost as if UMTS were developed as a successor to GSM, by a lot of the same people, and had the same requirement for the subscriber's identity being on a removable module... no, that couldn't be.
You're close. GSM won the worldwide competition for a few reasons, but technical superiority was not one of them.You can see that in the fact that UMTS as successor to GSM actually reuses a lot of stuff from CDMA.
Yeah, it uses this thing called "Code Division Multiple Access", which I think comes from CDMA :-). I don't know what stuff UMTS took from cdmaONE/CDMA2000 other than the notion of using Code Division Multiple Access.
I know that CDMA is an older standard
"CDMA" as a general technology, or "CDMA" as used in mobile phones? If the latter, are you certain that CDMA mobile phones were broadly deployed before GSM mobile phones?
Better known as UMTS.
Actually, there's a lot more to UMTS than just W-CDMA - W-CDMA is just the radio interface; UMTS includes the "higher layers" referred to below.
Never mind that the CDMA in US is CDMA2000.
For "CDMA" in the sense of "CDMA as in the Qualcomm protocol stacks", yes; for "CDMA" in the sense of "Code Division Multiple Access", there might still be cdmaONE networks and phones (2G) and there are definitely UMTS networks and phones (3G W-CDMA, but not CDMA2000).
So while UMTS and CDMA2k shares the base layer encoding, the higher layers are very different.
I'm not sure they even share the base layer encoding beyond "both using Code Division Multiple Access"; the CDMA2000 and W-CDMA radio interfaces are, I think, different.
Yes it does. GSM is 2G. 3G and beyond is W-CDMA.
Are you saying that CDMA2000, which I think is generally considered "3G", is W-CDMA - not just CDMA, as in "Code Division Multiple Access", but "W-CDMA", as in "the Wideband Code Division Multiple Access mechanism as specified by 3GPP specifications"? Or by "3G" do you just mean "the 3G successor to GSM"?
No, it's actually far far far more fragmented than that. It's not anywhere near the GSM market crying and picking up CDMA. Read up, it'll help you. Here's a good start, and you can extend your knowledge into more technical realms once you get the basics down: http://gizmodo.com/5637136/giz-explains-gsm-vs-cdma
Actually, a large part of the problem is that "CDMA" is used as a term to describe two different things:
When people talk about "CDMA" phones, they usually mean it in the second sense, so they don't consider UMTS phones "CDMA" phones, the fact that, when running on a UMTS network, they use Code Division Multiple Access, in the form of W-CDMA, nonwithstanding.
The article you point to uses it in both senses; for example, it says
where the last sentence uses it in the latter sense, and also says
which uses it in the former sense. They barely mention UMTS, and don't bother mentioning that UMTS also "[layers] digitized calls over one another, and unpack them on the back end with sequence codes".
So, no, the GSM market didn't "pick up CDMA" in the sense of dumping all the GSM protocols in favor of the cdmaONE/CDMA2000 protocols. It did, however, "pick up CDMA" in the sense that the UMTS follow-on to GSM uses Code Division Multiple Access.
Come on, seriously, research what you say before you say it!
Come on, seriously, look for the sarcasm in a posting before you respond to it!
everyone knows that GSM is being run on the AT&T network
Not true, given that the person to whom I responded didn't know that, or he wouldn't have said "Come on, America, at least move onto GSM. Now that it's all being ripped out and replaced with 3G there's a lot of GSM hardware on the second-hand market. It's not even expensive." - yeah, maybe they could use some of the GSM hardware that AT&T threw out as part of their upgrades to UMTS/HSDPA/etc., except that Verizon is too busy buying LTE equipment to bother (another thing he apparently wasn't aware of).
Or, as I said, "The early noughts called, they want their snark about the US mobile phone network back...."
Come on, America, at least move onto GSM.
Yeah, AT&T's pages don't mention GSM very much - they keep going on about some "LTE" thing. Hopefully they'll be upgrading from that weird technology to standard GSM some day....
(Yes, I know. The early noughts called, they want their snark about the US mobile phone network back....)