What's amusing about the Apple timeline is that they've been through this one before*.
PPC RISC => Intel CISC
ARM RISC => Intel CISC
Both times they kept a branch of code base up to date on the other architecture and have plenty of experience in both (I assume they have an X86 compatible iOS).
They have an x86-compatible kernel called XNU and a bunch of x86-compatible kernel-loadable modules and and a bunch of x86-compatible libraries and system daemons. Whether they ensure that, when those are built as part of iOS (e.g., with `CONFIG_EMBEDDED` #defined) rather than as part of OS X, they continue to work on x86, and whether the stuff that's iOS-only is and remains x86-compatible, is another matter.
*In the meanwhile they've secretly been creating their own architecture and instruction set.
...assuming they think they can create one so much better that it's worth the effort of maintaining it and llvm/lldb/etc. for it, and doing the fat-binary dance yet one more time.
A bit of digging says that there 64-bit ARM CPUs out there. I don't know if they're available in quantity, or how they're sold. I looked for applications using them, and there are LAMP stacks,
...i.e., server stuff, so there's probably not much interest in embeddable cores for systems-on-a-chip right now.
What does "it" mean here? Offering a 64-bit core as an embeddable block, or offering a 64-bit ARM core as an embeddable block?
If the former, perhaps most 64-bit processors aren't interesting to people building systems-on-a-chip, especially given that many of them are developed solely for the developers' own systems or maybe a few others (POWERn and z/Architecture processors are developed only for IBM's use or maybe a couple of other vendors if they let them use POWERn; the same applies for SPARCv9 and Sun^WOracle and Fujitsu) and even those that aren't are aimed at stuff a bit bigger (x86 except maybe for Atom, IA-64). MIPS appear to be the only ones offering 64-bit processors that might be available as embeddable blocks, but their Web site seems to mostly talk about the 32-bit cores.
If the latter, perhaps, err, umm, 64-bit ARM processors are just now beginning to arrive.
They're pushing it as a server processor, though, rather than a mobile processor.
The loveliness of the ARM family is that it's easily modified and graftable with other functionalities/features. Will a 64-bit version have the same nearly pluggable ease? We'll get to see, I'm guessing, soon enough.
"The loveliness of the ARM family" as described there is less a function of the instruction set and more a function of the CPU core being offered as an "intellectual property block" to stick onto a system-on-a-chip; I see no reason why it'd be any harder to do that with a 64-bit processor.
Away from what, your pocket? Sure, there is not yet a need for tablets with 4Gbyte of memory. But ARM 64-bit is not some far away dream, it just doesn't make much sense yet.
...in your pocket. ARM 64-bit might also be intended for servers (e.g., "low power means lower heat means you can stuff more processors into the same space in the machine room").
IBM's POWER, DEC/Compaq's Alpha (later bought by Intel... I assume that Intel's internal x86 micro-ops take inspiration from Alpha), MIPS non-low power division, HP's PA-RISC, etc all bet that Itanium would be the next great thing
HP bet that Itanium would be the next great thing because it was originally their idea - they teamed up with Intel to make it. As far as I know, IBM never decided that Itanium was the future, although Compaq and SGI ("MIPS non-low power division") eventually did.
And your assumption is, I suspect, incorrect, given that Compaq sold the Alpha to Intel in 2001, and the first micro-op Intel processor, the Pentium Pro, came out in 1995. There's no reason to assume that Pentium Pro's uops took inspiration from Alpha rather than from some other RISC processor, or even, necessarily, that it took direct inspiration from any of them, given that they're an internal implementation detail rather than a user-available instruction set.
As to Linux: It is already dominant in the server space. The year of "Linux in the pocket" has been a while ago. On the desktop? That will come, as soon as MS customers realize that MS cannot innovate away from what works well. The ribbon, their desktop-unfriendly new window manager, etc., are all attempts to be different, even if it degrades usability.
I've heard that at least some free-software UN*X desktop environments are pretty competitive with Windows in the "different, even if it degrades usability" department, at least from some of the complaints heard here.:-)
You've got a few of the points right, but my experience with a single-core Atom (recent Lenovo) versus a single core G4 (ancient G4 iBook) leads me to think Intel really only caught up with the PPC recently.
Atom isn't aimed at the laptop computer market. What Intel's selling for that market is, at least in the "compute pi with bc with scale=2000" benchmark, about 28 times faster than the G4 (it's quad-core, but, unless bc is multi-threaded, about all the other core might be doing is running Terminal as the digits of pi are being spit out, running Safari as it chews up CPU for already-loaded-but-still-open windows, etc.):
That's a CISC chip, by the way. (Memory-to-register arithmetic instructions, for example, although some of the more exotic instructions are implemented in a fashion similar to DEC Alpha's PALcode, wherein the instructions trap into a special processor mode with special non-architected instructions available, so the decimal fixed-point stuff and MVC/MVCL/TR/TRT/etc. stuff is sort of done in software.)
However, neither of those are aimed at desktop/laptop machines, so IBM arguably did give up on doing processors for those machines. (In fact, after selling off the PC division to Lenovo and killing off the workstation side of RS/6000 and its successors, they arguably gave up on doing those machines, period.)
Also, porting has much more to do with APIs than instruction set.
In the example given by the person to whom you're responding, you're 10000% correct - it's not as if Apple switching to x86 suddenly made it easy to translate Windows applications to OS X applications (well, other than making the apps run "the lazy way" by running them atop Wine).
John Mashey, one of the MIPS architecture designers among many other things, has written a really good essay on RISC architectural choices.
He posted it to the comp.arch USENET group a few times; here's a copy of that post that renders in a monospace font so you can read the ASCII tables easily. [Google Groups' version makes the tables unreadable.]
The best rule of thumb I like to remember from that essay is that RISC architectures try to make exception handling simple; for example, they don't tend to use the MMU for data access more than once per instruction, because then you have multiple ways that the instruction can generate an exception. Other RISC choices can be seen as stemming from this rule, such as:
- no variable-length string comparison/move instructions
Still applies to most if not all RISCs these days; x86 sort-of has that with some looping instructions.
- accesses to multibyte data are aligned so they can't cross page boundaries
Does any RISC architecture other than SPARC have that restriction these days? (I had the impression ARM just ignored the low-order bits with multi-byte loads and stores, but somebody indicated that's not true in recent versions of the architecture.)
- load/store architectures; this keeps MMU exceptions and ALU exceptions from ever being generated by the same instruction.
Still applies to most if not all RISCs these days; does not apply to x86, even in 64-bit mode.
x86_64 is RISC, if you don't count the 32-bit instructions.
And if you don't count the non-register-to-register arithmetic instructions and the CALL instruction (even in its simplest form, it pushes the return address onto the stack rather than just stuffing it in a register).
It has become quite simple in modern times to make a CPU emulating JIT (meaning treating the binary instruction set of one CPU as source code and recompiling it for the host platform.) what is extremely expensive execution-wise is data model conversion on loads and stores. Unless Intel starts making load and store instructions that can function in big endian mode (we can only dream), data loading in an emulator/JIT will always be a huge execution burden.
Was Rosetta, translating PowerPC to x86, really that bad?
Also, in the x64 version of the x86, both AMD and Intel have left out certain instructions that were there in the 32-bit mode - which made it more CISCy.
And left out neither any of the register-memory arithmetic instructions that were there in the 32-bit mode nor the CALL instruction, which also made it more CISCy.
As it is, more & more software is now win64 and same on the Linux side as well. As 8GB becomes the minimum memory density available, both Intel & AMD can drop support for 32-bit instructions completely, @ which point the x86 would be a pure RISC architecture - just like MIPS and POWER
...unless you consider "load/store architecture" to be an inherent characteristics of a "pure RISC architecture".
"There's such a thing as "computing in general" wherein one can have a dominant market position? News to me"
Yep, it's called making the silicon most commonly used by people and software most used by people, which the two companies mentioned have (intel for silicon, Microsoft for Windows OS.)
I.e., desktop/laptop computing. For tablet computing, it's various ARM vendors for silicon, and Apple and Google for the OSes. Unless Windows 8 tablets (as opposed to Windows RT tablets) catch on big, that's not going to go Intel/Microsoft.
"How is phone computing not part of "computing in general"
Ever see a featurephone? Bear in mind a large swath of phones don't really work as computing devices (nor do many run x86 hardware,) don't run Windows, and do not much more than make calls or take pictures. Plenty of flip phones still in use across the globe.
If they "don't really work as computing devices", then they're not part of "phone computing", so "phone computing" means "smartphones", and "phone computing" is like "tablet computing" in that it's ARM and iOS/Android.
So maybe the title should be changed to "Apple USB Power Adapter Scorns Standard Promise To European Commission", as the iPhone 5 does something that TFMoU considers OK.
Then again, if Apple haven't "placed... on the market" any "[EPSes] equipped with a Micro-USB connector", maybe they conform to the letter, if not the spirit, of the MoU.
Plus the EC is fine if they simply include an adapter from USB, IIRC.
Well, no, the EC is not fine with that.
Well, yes, the EC is fine with that, unless they've changed the MoU since June 5, 2009. People who haven't read paragraph 4.2.1:
4.2.1 In order that compatibility of as many Mobile Phones as possible with a Common EPS may be enabled, if a manufacturer makes available an Adaptor from the Micro-USB connector of a Common EPS to a specific non-Micro-USB socket in the Mobile Phone, it shall constitute compliance to this article.
might not be OK with that, but that's another issue. (And "make available", for better or worse, doesn't necessarily imply "bundle with the Mobile Phone at no extra charge".)
They offer a cable for sale, not included in the box, and it still means you can't use an Apple charger to charge any other device,
Why does an Apple USB Power Adapter plus a USB Standard A to Micro-USB B cable not allow you to charge other devices that accept power from a Micro-USB B-Plug?
which is the whole point of the standard.
Well, half the point of the standard - the other half is allowing standard chargers to charge an Apple device.
Someone posted some interesting points in the linked article, I've pasted it here. ( Don't shoot the messenger who is an android fan.) Discuss... *** “Apple has reneged on that commitment to the European Commission to change to micro-USB”. This is simply false. Undertaking 4.2.1 states that “if a manufacturer makes available an Adaptor from the Micro-USB connector of a Common EPS to a specific non-Micro-USB socket in the Mobile Phone, it shall constitute compliance”. —http://ec.europa.eu/enterprise...
Annex II futher states that “An EPS provided with a detachable cable shall be equipped with a USB Standard-A receptacle. Above requirement also applies to detachable cables used as adaptor i.e. where the Micro-B is replaced by a proprietary plug” —http:// ec.europa.eu/enterprise...
Apple’s decision not to use a Micro-USB connector is in keeping with the agreement, as they also offer a Micro-USB to Lightning adaptor. Their charger also appears to be a common EPS,
Section 2 "DC Plug Connector Specification" of Annex II says "Standard detachable cable assembly, supplied for use with the EPS, shall have Standard-A and Micro-B plugs...". Does Apple provide such a cable standard with the Apple USB Power Adapter? If not, maybe they can still squeak past
4.3 Undertake, subject to the satisfactory completion of the work described in article 4.1, to ensure that each EPS equipped with a Micro-USB connector placed by them on the market for use with Mobile Phones is a Common EPS.
For the avoidance of doubt, this MoU does not preclude the supply of an EPS which has a specific non-Micro-USB connector provided the Mobile Phone with which it is intended to be used can also be charged with a Common EPS under Article 4.2.
in the MoU by not placing any external power supplies equipped with a Micro-USB connector on the market and ensuring that the iPhone 5 can be charged with a Common EPS (which it can, with the Lightning-to-Micro-USB adapter).
If you read the linked-to page about the agreement, you'll see that the title is "One charger for all - Frequently asked questions", emphasis mine. The first FAQ, "What's the issue?", says:
Incompatibility of chargers for mobile phones is a major environmental problem and an inconvenience for users across the European Union. Currently, specific chargers are sold together with specific mobile phones. A user who wants to change his/her mobile phone usually acquires a new charger and disposes of the current one, even if it is in perfect condition. This unnecessarily generates considerable amounts of electronic waste.
and the second FAQ, "What is the solution envisaged?", says:
Harmonising mobile phone chargers will bring significant economic and environmental benefits. Following a request from the European Commission and in close co-operation with the Commission services, major producers of mobile phones have agreed in a Memorandum of Understanding (“MoU”) to harmonise chargers for data-enabled mobile phones sold in the EU. The industry commits to the provision of compatible chargers on the basis of the Micro-USB connector. Once the commitment becomes effective, it will be possible to charge compatible data-enabled mobile phones from any common charger.
The astute reader will note that a certain word that begins with "c" and ends with "harger" appears quite frequently in those items. This was not about "mobile phone accessories" in general, it was about a particular accessory, namely the charger, so "they have junked earlier iPhone accessories, forced a new industry in Apple-only accessories to arise" is 100% irrelevant to the MoU.
As for the charging part - the only part relevant to the "promise to the EC" - TFMoU explicitly says that "[making] available an Adaptor from the Micro-USB connector of a Common EPS to a specific non-Micro-USB socket in the Mobile Phone" is sufficient to ensure compliance. Perhaps Apple phones sold within the EU should ship with that adaptor, rather than selling it as an add-on, but that's another matter.
Now, TFMoU also says that the Signatories:
4.3 Undertake, subject to the satisfactory completion of the work described in article 4.1, to ensure that each EPS equipped with a Micro-USB connector placed by them on the market for use with Mobile Phones is a Common EPS.
where an "EPS" is an external power supply and
2.4 A ‘Common EPS’ is an EPS which meets the requirements of the specifications and standards which will be developed under article 4.1 and as may be revised under article 4.5.
The specifications are expected to include:
2.4.1 A Micro-USB B-Plug attached via a cable which delivers power to the device being charged.
so if, for example, the Apple USB Power Adapter sold in one EU country doesn't provide "a Micro-USB B-Plug attached via a cable which delivers power to the device being charged", then they're not conforming to that part of TFMoU. At least from the picture, it offers what appears to be a USB 2.0 Group 7 - Standard “A” Receptacle, rather than a "USB 2.0 Group 7 – Micro-USB B-Plug", so, unless it includes a cable that plugs into the Standard A-Receptacle and has a Micro-USB B-Plug, they aren't complying - and the Apple page says they include an "Apple Dock Connector to USB Cable", which plugs into the Standard A-Receptacle but has an Old Fashioned 30-Pin Apple Dock Connector, so no go.
So maybe the title should be changed to "Apple USB Power Adapter Scorns Standard Promise To European Commission", as the iPhone 5 does something that TFMoU considers OK.
4.2 Undertake, subject to the satisfactory completion of the activities described in article 4.1, including successful standardisation as required, to ensure their Mobile Phones are capable of being charged at the Preferred Charging Rate by any EPS meeting the requirements of a Common EPS.
So "compliance" means "[ensuring] that [your] Mobile Phones are capable of being charged at the Preferred Charging Rate by any EPS meeting the requirements of a Common EPS.", where "EPS" is "external power supply" and
2.4 A ‘Common EPS’ is an EPS which meets the requirements of the specifications and standards which will be developed under article 4.1 and as may be revised under article 4.5.
The specifications are expected to include:
2.4.1 A Micro-USB B-Plug attached via a cable which delivers power to the device being charged.
So this means that if you have a power supply that has a Micro-USB B-Plug, it should be possible to use the B-Plug to charge the phone. It doesn't say that the phone must have a B-Plug receptacle built into it; in fact, it explicitly says, in the section to which you're responding, that one way to accomplish this is to have an adapter that plugs into the phone and accepts a B-Plug.
So, no, this doesn't "[use] two proprietary adapters to emulate a single standard adapter". It uses an adapter to plug into a proprietary connector and offer a standard socket, allowing you to charge an iPhone 5 with any external power supply that has a Micro-USB B-Plug.
I think the EC could argue that Apple should bundle that adapter with all phones sold in the EU, although the MoU just says that Apple has to "make available" the adapter to comply.
And, no, the MoU wasn't so broad as to be "aimed at reducing electronic waste resulting from mobile phone accessories." It was aimed at reducing electronic waste from a particular mobile phone accessory, namely the charger.
Slashdot Mirror
What's amusing about the Apple timeline is that they've been through this one before*.
PPC RISC => Intel CISC
ARM RISC => Intel CISC
Both times they kept a branch of code base up to date on the other architecture and have plenty of experience in both (I assume they have an X86 compatible iOS).
They have an x86-compatible kernel called XNU and a bunch of x86-compatible kernel-loadable modules and and a bunch of x86-compatible libraries and system daemons. Whether they ensure that, when those are built as part of iOS (e.g., with `CONFIG_EMBEDDED` #defined) rather than as part of OS X, they continue to work on x86, and whether the stuff that's iOS-only is and remains x86-compatible, is another matter.
*In the meanwhile they've secretly been creating their own architecture and instruction set.
...assuming they think they can create one so much better that it's worth the effort of maintaining it and llvm/lldb/etc. for it, and doing the fat-binary dance yet one more time.
A bit of digging says that there 64-bit ARM CPUs out there. I don't know if they're available in quantity, or how they're sold. I looked for applications using them, and there are LAMP stacks,
...i.e., server stuff, so there's probably not much interest in embeddable cores for systems-on-a-chip right now.
Hmmmm. Then why hasn't it been done?
What does "it" mean here? Offering a 64-bit core as an embeddable block, or offering a 64-bit ARM core as an embeddable block?
If the former, perhaps most 64-bit processors aren't interesting to people building systems-on-a-chip, especially given that many of them are developed solely for the developers' own systems or maybe a few others (POWERn and z/Architecture processors are developed only for IBM's use or maybe a couple of other vendors if they let them use POWERn; the same applies for SPARCv9 and Sun^WOracle and Fujitsu) and even those that aren't are aimed at stuff a bit bigger (x86 except maybe for Atom, IA-64). MIPS appear to be the only ones offering 64-bit processors that might be available as embeddable blocks, but their Web site seems to mostly talk about the 32-bit cores.
If the latter, perhaps, err, umm, 64-bit ARM processors are just now beginning to arrive.
The details of Clover Trail's power management won't be disclosed to Linux developers.
So sign up as a Windows developer, get the info, and use it to improve Linux.
...and perhaps get sued for violating a non-disclosure agreement you signed in order to get the info.
As otherwise noted, perhaps the chip will emerge when the need is demonstrated.
Well, according to the slide show, silicon will be available for the X-Gene in "2H. 2012", so maybe they're already shipping.
They're pushing it as a server processor, though, rather than a mobile processor.
The loveliness of the ARM family is that it's easily modified and graftable with other functionalities/features. Will a 64-bit version have the same nearly pluggable ease? We'll get to see, I'm guessing, soon enough.
"The loveliness of the ARM family" as described there is less a function of the instruction set and more a function of the CPU core being offered as an "intellectual property block" to stick onto a system-on-a-chip; I see no reason why it'd be any harder to do that with a 64-bit processor.
Away from what, your pocket? Sure, there is not yet a need for tablets with 4Gbyte of memory. But ARM 64-bit is not some far away dream, it just doesn't make much sense yet.
...in your pocket. ARM 64-bit might also be intended for servers (e.g., "low power means lower heat means you can stuff more processors into the same space in the machine room").
IBM's POWER, DEC/Compaq's Alpha (later bought by Intel... I assume that Intel's internal x86 micro-ops take inspiration from Alpha), MIPS non-low power division, HP's PA-RISC, etc all bet that Itanium would be the next great thing
HP bet that Itanium would be the next great thing because it was originally their idea - they teamed up with Intel to make it. As far as I know, IBM never decided that Itanium was the future, although Compaq and SGI ("MIPS non-low power division") eventually did.
And your assumption is, I suspect, incorrect, given that Compaq sold the Alpha to Intel in 2001, and the first micro-op Intel processor, the Pentium Pro, came out in 1995. There's no reason to assume that Pentium Pro's uops took inspiration from Alpha rather than from some other RISC processor, or even, necessarily, that it took direct inspiration from any of them, given that they're an internal implementation detail rather than a user-available instruction set.
As to Linux: It is already dominant in the server space. The year of "Linux in the pocket" has been a while ago. On the desktop? That will come, as soon as MS customers realize that MS cannot innovate away from what works well. The ribbon, their desktop-unfriendly new window manager, etc., are all attempts to be different, even if it degrades usability.
I've heard that at least some free-software UN*X desktop environments are pretty competitive with Windows in the "different, even if it degrades usability" department, at least from some of the complaints heard here. :-)
You've got a few of the points right, but my experience with a single-core Atom (recent Lenovo) versus a single core G4 (ancient G4 iBook) leads me to think Intel really only caught up with the PPC recently.
Atom isn't aimed at the laptop computer market. What Intel's selling for that market is, at least in the "compute pi with bc with scale=2000" benchmark, about 28 times faster than the G4 (it's quad-core, but, unless bc is multi-threaded, about all the other core might be doing is running Terminal as the digits of pi are being spit out, running Safari as it chews up CPU for already-loaded-but-still-open windows, etc.):
Gave it up? http://m.engadget.com/2010/09/06/ibm-claims-worlds-fastest-processor-with-5-2ghz-z196/
That's a CISC chip, by the way. (Memory-to-register arithmetic instructions, for example, although some of the more exotic instructions are implemented in a fashion similar to DEC Alpha's PALcode, wherein the instructions trap into a special processor mode with special non-architected instructions available, so the decimal fixed-point stuff and MVC/MVCL/TR/TRT/etc. stuff is sort of done in software.)
But, no, IBM didn't give up the Power architecture (or whatever you want to call the collection of architectures descended from POWER) either: http://arstechnica.com/gadgets/2009/09/ibms-8-core-power7-twice-the-muscle-half-the-transistors/.
However, neither of those are aimed at desktop/laptop machines, so IBM arguably did give up on doing processors for those machines. (In fact, after selling off the PC division to Lenovo and killing off the workstation side of RS/6000 and its successors, they arguably gave up on doing those machines, period.)
Also, porting has much more to do with APIs than instruction set.
In the example given by the person to whom you're responding, you're 10000% correct - it's not as if Apple switching to x86 suddenly made it easy to translate Windows applications to OS X applications (well, other than making the apps run "the lazy way" by running them atop Wine).
John Mashey, one of the MIPS architecture designers among many other things, has written a really good essay on RISC architectural choices.
He posted it to the comp.arch USENET group a few times; here's a copy of that post that renders in a monospace font so you can read the ASCII tables easily. [Google Groups' version makes the tables unreadable.]
The best rule of thumb I like to remember from that essay is that RISC architectures try to make exception handling simple; for example, they don't tend to use the MMU for data access more than once per instruction, because then you have multiple ways that the instruction can generate an exception. Other RISC choices can be seen as stemming from this rule, such as: - no variable-length string comparison/move instructions
Still applies to most if not all RISCs these days; x86 sort-of has that with some looping instructions.
- accesses to multibyte data are aligned so they can't cross page boundaries
Does any RISC architecture other than SPARC have that restriction these days? (I had the impression ARM just ignored the low-order bits with multi-byte loads and stores, but somebody indicated that's not true in recent versions of the architecture.)
- load/store architectures; this keeps MMU exceptions and ALU exceptions from ever being generated by the same instruction.
Still applies to most if not all RISCs these days; does not apply to x86, even in 64-bit mode.
x86_64 is RISC, if you don't count the 32-bit instructions.
And if you don't count the non-register-to-register arithmetic instructions and the CALL instruction (even in its simplest form, it pushes the return address onto the stack rather than just stuffing it in a register).
It has become quite simple in modern times to make a CPU emulating JIT (meaning treating the binary instruction set of one CPU as source code and recompiling it for the host platform.) what is extremely expensive execution-wise is data model conversion on loads and stores. Unless Intel starts making load and store instructions that can function in big endian mode (we can only dream), data loading in an emulator/JIT will always be a huge execution burden.
Was Rosetta, translating PowerPC to x86, really that bad?
No, the Intel Pentium Pro was the first real "CISC-on-RISC" design.
Didn't the Nx586 come out a little earlier?
Also, in the x64 version of the x86, both AMD and Intel have left out certain instructions that were there in the 32-bit mode - which made it more CISCy.
And left out neither any of the register-memory arithmetic instructions that were there in the 32-bit mode nor the CALL instruction, which also made it more CISCy.
As it is, more & more software is now win64 and same on the Linux side as well. As 8GB becomes the minimum memory density available, both Intel & AMD can drop support for 32-bit instructions completely, @ which point the x86 would be a pure RISC architecture - just like MIPS and POWER
...unless you consider "load/store architecture" to be an inherent characteristics of a "pure RISC architecture".
I expect these tablets will be locked to Windows 8 through a secure boot system. It remains to be seen that users will be able to install other OSes.
I.e., it remains to be seen whether the tablets will not conform to the Windows Hardware Certification Requirements for Windows 8 Client and Server Certified Systems (look for "non-ARM") by not supporting Custom Mode and not allowing Secure Boot to be disabled?
And growing logarithmically still.
Presumably you meant "growing exponentially".
Po-tay-to:Po-tah-to::missionary:marketing
Yup. Both flavors of m-word suck.
"There's such a thing as "computing in general" wherein one can have a dominant market position? News to me"
Yep, it's called making the silicon most commonly used by people and software most used by people, which the two companies mentioned have (intel for silicon, Microsoft for Windows OS.)
I.e., desktop/laptop computing. For tablet computing, it's various ARM vendors for silicon, and Apple and Google for the OSes. Unless Windows 8 tablets (as opposed to Windows RT tablets) catch on big, that's not going to go Intel/Microsoft.
"How is phone computing not part of "computing in general"
Ever see a featurephone? Bear in mind a large swath of phones don't really work as computing devices (nor do many run x86 hardware,) don't run Windows, and do not much more than make calls or take pictures. Plenty of flip phones still in use across the globe.
If they "don't really work as computing devices", then they're not part of "phone computing", so "phone computing" means "smartphones", and "phone computing" is like "tablet computing" in that it's ARM and iOS/Android.
So maybe the title should be changed to "Apple USB Power Adapter Scorns Standard Promise To European Commission", as the iPhone 5 does something that TFMoU considers OK.
Then again, if Apple haven't "placed ... on the market" any "[EPSes] equipped with a Micro-USB connector", maybe they conform to the letter, if not the spirit, of the MoU.
Plus the EC is fine if they simply include an adapter from USB, IIRC.
Well, no, the EC is not fine with that.
Well, yes, the EC is fine with that, unless they've changed the MoU since June 5, 2009. People who haven't read paragraph 4.2.1:
might not be OK with that, but that's another issue. (And "make available", for better or worse, doesn't necessarily imply "bundle with the Mobile Phone at no extra charge".)
They offer a cable for sale, not included in the box, and it still means you can't use an Apple charger to charge any other device,
Why does an Apple USB Power Adapter plus a USB Standard A to Micro-USB B cable not allow you to charge other devices that accept power from a Micro-USB B-Plug?
which is the whole point of the standard.
Well, half the point of the standard - the other half is allowing standard chargers to charge an Apple device.
Someone posted some interesting points in the linked article, I've pasted it here. ( Don't shoot the messenger who is an android fan.) Discuss... *** “Apple has reneged on that commitment to the European Commission to change to micro-USB”. This is simply false. Undertaking 4.2.1 states that “if a manufacturer makes available an Adaptor from the Micro-USB connector of a Common EPS to a specific non-Micro-USB socket in the Mobile Phone, it shall constitute compliance”. —http://ec.europa.eu/enterprise...
Here's a URL for the MoU that replaces "..." with something actually useful, and is an actual link to boot - http://ec.europa.eu/enterprise/newsroom/cf/_getdocument.cfm?doc_id=5274.
Annex II futher states that “An EPS provided with a detachable cable shall be equipped with a USB Standard-A receptacle. Above requirement also applies to detachable cables used as adaptor i.e. where the Micro-B is replaced by a proprietary plug” —http:// ec.europa.eu/enterprise...
Here's a URL for Annex II that replaces "..." with something actually useful, and is an actual link to boot - http://ec.europa.eu/enterprise/newsroom/cf/_getdocument.cfm?doc_id=5272.
Apple’s decision not to use a Micro-USB connector is in keeping with the agreement, as they also offer a Micro-USB to Lightning adaptor. Their charger also appears to be a common EPS,
Section 2 "DC Plug Connector Specification" of Annex II says "Standard detachable cable assembly, supplied for use with the EPS, shall have Standard-A and Micro-B plugs...". Does Apple provide such a cable standard with the Apple USB Power Adapter? If not, maybe they can still squeak past
in the MoU by not placing any external power supplies equipped with a Micro-USB connector on the market and ensuring that the iPhone 5 can be charged with a Common EPS (which it can, with the Lightning-to-Micro-USB adapter).
If you read the linked-to page about the agreement, you'll see that the title is "One charger for all - Frequently asked questions", emphasis mine. The first FAQ, "What's the issue?", says:
and the second FAQ, "What is the solution envisaged?", says:
The astute reader will note that a certain word that begins with "c" and ends with "harger" appears quite frequently in those items. This was not about "mobile phone accessories" in general, it was about a particular accessory, namely the charger, so "they have junked earlier iPhone accessories, forced a new industry in Apple-only accessories to arise" is 100% irrelevant to the MoU.
As for the charging part - the only part relevant to the "promise to the EC" - TFMoU explicitly says that "[making] available an Adaptor from the Micro-USB connector of a Common EPS to a specific non-Micro-USB socket in the Mobile Phone" is sufficient to ensure compliance. Perhaps Apple phones sold within the EU should ship with that adaptor, rather than selling it as an add-on, but that's another matter.
Now, TFMoU also says that the Signatories:
where an "EPS" is an external power supply and
so if, for example, the Apple USB Power Adapter sold in one EU country doesn't provide "a Micro-USB B-Plug attached via a cable which delivers power to the device being charged", then they're not conforming to that part of TFMoU. At least from the picture, it offers what appears to be a USB 2.0 Group 7 - Standard “A” Receptacle, rather than a "USB 2.0 Group 7 – Micro-USB B-Plug", so, unless it includes a cable that plugs into the Standard A-Receptacle and has a Micro-USB B-Plug, they aren't complying - and the Apple page says they include an "Apple Dock Connector to USB Cable", which plugs into the Standard A-Receptacle but has an Old Fashioned 30-Pin Apple Dock Connector, so no go.
So maybe the title should be changed to "Apple USB Power Adapter Scorns Standard Promise To European Commission", as the iPhone 5 does something that TFMoU considers OK.
LOL, am I reading this correctly? Let me paraphrase:
Compliance is using a standard, rather than proprietary, adapter*
*Note: Instead of one standard adapter, using two proprietary adapters to emulate a single standard adapter, shall constitute compliance.
If you read the June 5, 2009 Memorandum of Understanding regarding Harmonisation of a Charging Capability for Mobile Phones, you see that:
So "compliance" means "[ensuring] that [your] Mobile Phones are capable of being charged at the Preferred Charging Rate by any EPS meeting the requirements of a Common EPS.", where "EPS" is "external power supply" and
So this means that if you have a power supply that has a Micro-USB B-Plug, it should be possible to use the B-Plug to charge the phone. It doesn't say that the phone must have a B-Plug receptacle built into it; in fact, it explicitly says, in the section to which you're responding, that one way to accomplish this is to have an adapter that plugs into the phone and accepts a B-Plug.
So, no, this doesn't "[use] two proprietary adapters to emulate a single standard adapter". It uses an adapter to plug into a proprietary connector and offer a standard socket, allowing you to charge an iPhone 5 with any external power supply that has a Micro-USB B-Plug.
I think the EC could argue that Apple should bundle that adapter with all phones sold in the EU, although the MoU just says that Apple has to "make available" the adapter to comply.
And, no, the MoU wasn't so broad as to be "aimed at reducing electronic waste resulting from mobile phone accessories." It was aimed at reducing electronic waste from a particular mobile phone accessory, namely the charger.