Wow. Of course Apple and IBM are pretty tight (again) these days so that bodes well for us Apple folks. Talking of Apple and IBM I wonder if they have discussed letting Siri crib off Watson's results yet? For non British English speaking folks.to crib: (transitive) (informal) to steal (another's writings or thoughts)
I suspect that is already happening -- just DockDuck "Siri Watson"
In more generic terms (emphasis mine):
Introducing the (beta) IBM Watson iOS SDK! ANDREW_TRICE/ DECEMBER 18, 2015 / 0 COMMENTS Mobile app designers have a lot of decisions to make when designing and building their apps. Adding cognitive capabilities is quickly becoming table-stakes. Cognitive computing is changing the way that entire industries process, understand, and respond to information. It is transformative both in how people engage with computing systems, and how information can be analyzed to optimize processes and advance business goals and capabilities. Introducing the new IBM Watson iOS SDK (beta) Of course, it’s written entirely in Swift. The IBM Watson iOS SDK (beta) makes interacting with IBM Watson services quick and painless. The IBM Watson iOS SDK gives developers a Swift application programming interface (API) to simplify integration with many of the Watson Developer Cloud services, including the Watson Dialog, Language Translation, Natural Language Classifier, Personality Insights, Speech To Text, Text to Speech, Alchemy Language, or Alchemy Vision services – all of which are available today, and can now be integrated with just a few lines of code. https://developer.ibm.com/swift/2015/12/18/introducing-the-new-watson-sdk-for-ios-beta/
Also, below is another link from 8 months ago that shows iOS apps using Watson:
This example uses Node.js for the intermediary http server. But, recently IBM released a web server written entirely in Swift -- Kitura beta. One (of many) advantages being that a developer can use the same development language (Swift) to write both ends of client-server apps.
Voice-Driven Native Mobile Apps with IBM Watson & IBM MobileFirst Bluemix Services Used This app uses three services available through IBM Bluemix:
IBM Watson Speech QA for iOS App Architecture The app communicates to the Speech to Text and Question & Answer services through the Node.js middelware tier, and connects directly to the Advanced Mobile Access service to provide operational analytics (usage, devices, network utilization) and remote log collection from the client app on the mobile devices.
No, no no! For the hundredth time, Apple will not replace Intel with ARM, AMD, or its own Ax chips in MacBooks anytime in the foreseeable future. The proof is in the pudding and the pudding is the iPad Pro! Intel chips is Apple's way of differentiating it from Macbooks. Period, end of story!
Re: the discussion about switching CPU... Yeah... Like we need another transition period to lose tons of apps and drivers. It's hard enough to deal with support between OS X versions, let alone the architecture changeovers. Companies like when users are forced to re-buy stuff (which is why drivers stop being written for hardware that still works, screw you M-Audio/Avid), but developers hate change and resist it as much as possible. Apple's computer dominance isn't yet assured (especially on content creating workstations) and being able to port between Mac and Windows would be much more difficult for developers with a different CPU architecture put back into the mix. It would also kill the Mac-runs-Windows angle.
as for the primary topic of the article: the only way this Intel revelation should matter is if things like thunderbolt and usb chipsets (and whatever else) were hindered by the tick-uhhhh-tock three-step (like we are already waiting for Intel to make viable chipsets for thunderbolt 3 / display port with external Retina display capability).
I agree, When Apple switched to Intel from PPC it was out of necessity. It became a net positive in many ways but they were pretty much at the end of the road with IBM and the PowerPC. Had they stayed on PPC there likely would be no mac today. Intel as of right now is at the top of the game in performance when it comes to CPUs. If they aren't advancing, nobody is advancing. Arm is advancing but it's in (for now) in an entirely different race and a mac architecture switch at this point would be settling for less and an unnecessary burden on the entire mac ecosystem with no gain. It is possible for Apple to make an Arm based MacBook, but judging by the problems Microsoft suffered with the arm based Surface RT in the market place, I don't see why Apple would want to do that to themselves. It wouldn't be iOS and would require arm based versions of software written for a special arm based MacOS X. Not exactly attractive to anyone.
Apple can succeed where Surface RT failed because they won't need to "shrink" OS X to fit ARM like MS tried to shrink Windows to fit...
Apple is already "growing" iOS to be a "MacBook" of sorts--look at the iPad Pro line. I would not be surprised to see a near-future MacBook* line being based on iOS, where the MacBook Pro line stays with OS X/Intel.
(*Maybe they will call it something other than MacBook, but there is already a functional distinction between MB and MBP, so the model names could be preserved).
No, no no! For the hundredth time, Apple will not replace Intel with ARM, AMD, or its own Ax chips in MacBooks anytime in the foreseeable future. The proof is in the pudding and the pudding is the iPad Pro! Intel chips is Apple's way of differentiating it from Macbooks. Period, end of story!
Wow. Of course Apple and IBM are pretty tight (again) these days so that bodes well for us Apple folks. Talking of Apple and IBM I wonder if they have discussed letting Siri crib off Watson's results yet? For non British English speaking folks.to crib: (transitive) (informal) to steal (another's writings or thoughts)
I suspect that is already happening -- just DockDuck "Siri Watson"
In more generic terms (emphasis mine):
Also, below is another link from 8 months ago that shows iOS apps using Watson:
This example uses Node.js for the intermediary http server. But, recently IBM released a web server written entirely in Swift -- Kitura beta. One (of many) advantages being that a developer can use the same development language (Swift) to write both ends of client-server apps.
Awesome post. It's all very exciting for the future of Apple/IMB.
Apple can succeed where Surface RT failed because they won't need to "shrink" OS X to fit ARM like MS tried to shrink Windows to fit...
What did Microsoft "shrink" for RT?
I know the major removed features - bitlocker (replaced with device encryption), media player, Domain support, Software RAID management and it had limited RDC functionality. However, Apple will have exactly the same issues migrating to ARM; they've got to recode the OS for a different architecture, and just about all software written for MacOS will be completely incompatible without some kind of emulation.
ARM CPUs (Like the A9X, and Probably the A10X in the future) certainly give Intel's entry-level mobile CPUs a run for their money and for the notebook/low end series computers, I'd see them being a good fit. But would Apple want to segregate their market in doing this? An A9X and I'm guessing most future Apple SoC device won't be able to keep up with Intel's workhorse CPUs or even desktop class ones. Geekbench is the only real cross platform benchmark we have to go by, and on that the A9X scores in the 5500 range whilst current-gen Skylake CPUs, as seen in the most recent iMac sporting an i7-6700K, can score upwards of 22000. Apple's not about to replace an iMac with an ARM CPU, especially seeing as Apple's inevitable A10(X) which yes, will be a performance, boost, but will probably be battling alongside Intel's 7000-series i5 and i7 (Kaby Lake, expected before the end of 2016) which will also see a performance boost.
My point is - would Apple really create a split in their Desktop/Laptop OS market? There's alternatives - abandon the desktop segment (I don't see them doing this), or run with some kind of Rosetta-like binary translator, but it slows things down, and they're hardly infallible. Rosetta, as I recall, couldn't run programs that required a G5 as the Intel hardware of the era couldn't both run something that CPU demanding and the translator at the same time.
Apple's solution for their 68k to PPC transition was a far better solution, giving the 68k emulator direct access to the MacOS nanokernal, thus allowing PPC interrupts to be handled as 68k interupts, allowing mixed switching and importantly allowing developers to mix their 68k and PPC code without much issue. It would be possible to tie extremely low-level binary translation into XNU and if Apple does ever go down the ARM route I'm guessing they'd do this, but in a security conscious age it might not be very wise and Apple might be trying to plug holes before moving in this direction.
I think this all the more reason that Apple will at some point move away from intel x86 to Apple ARM Ax chips.
Ah, that's a who,e different matter. Apple's ARM chips would need to become several times faster.
What nonsense, A processors are more than fast enough.
You can't be serious, we are a very long way from iPhines that can effectively take care of the computing needs of most people. The end game here is a cell phone that can function as a desktop replacement when docked with a video monitor.
What nonsense, A processors are more than fast enough.
You can't be serious, we are a very long way from iPhines that can effectively take care of the computing needs of most people. The end game here is a cell phone that can function as a desktop replacement when docked with a video monitor.
I say the end game is cluster. So we can call on as much power as needed in a given situation but know it's not sitting redundant while someone else has need.
Most of Adobe's software is close to retro garbage, don't even know how they could become or stay a "standard".
Most of what they do can be done in other software, it is pure inertia (same as the one using Words or whatever software that everyone uses and no one knows quite why) keeping this sloth behemoth in place.
I'm a heavy user of Adobe CC. It has a lot of faults but even with that, there is simply no 100% replacement for apps like Photoshop and Lightroom. Period. I'm a huge fan of Pixelmator - a photoshop competitor - and in many ways it blows Photoshop out of the water but I revert right back to Photoshop because it has better features, is more scalable, and has a gazillion plugins along with a tried-and-true support structure. It is a standard whether you like it or not.
Name one other package you feel is a worthy 100% replacement for Photoshop. Just know, if you say "Gimp", then you lose all credibility and this conversation will be over with.
Serif's Affinity Photo. For one, its close sibling, Affinity Designer, won an Apple Design Award at WWDC’15, and Photo itself was elected, also by Apple, best Mac App of 2015. And since its lean and modern engine was written in platform-agnostic C++ (though it does use a lot of OS X-specific technologies and, as such, is heavily optimized, which sets it apart from Adobe apps in the performance department) it will soon be ported to Windows, along with Affinity Designer, the as yet unreleased but announced Affinity Publisher and a confirmed but not yet announced (with fanfare and product name to go with it, that is) DAM component which will take the spot left void by Aperture and run with it (as there's no technical reason stopping its developers from porting it as well and going head-to-head with Lightroom). Oh, did I mention that Affinity Photo already supports a lot of Photoshop plugins and that it will soon feature a Macros persona (Serif's jargon for “mode”) which will enable further automation?
Sure, you may argue that it's not a 100% replacement… yet. Remember InDesign 1.0? Was it a full QuarkXPress replacement? As for some weird, kludgy tools like 3D support in Photoshop and Illustrator, well… those are niche tools, to say the least. I'd venture to say that the vast majority of Photoshop *and* Lightroom users (which are, by and large, mostly photographers) will rarely, if ever, touch those. Designers and other creatives will surely have some use for them but, even then, it will be a rare occurrence. Besides, Affinity Photo already offers a few perspective tools of its own, so it's not like they couldn't come up with a technically comparable but better solution UX-wise for that case scenario one day.
By the way, Serif also offered animation tools in the soon-to-be-discontinued (yes, those guys are really betting their company on Affinity) DrawPlus (which could serve as a basis to compete with Animate CC as a separate app – yes, I am aware that I am reposting a link, but that post is relevant to both apps), WebPlus (so they may very well compete with other web and UX authoring tools soon) and the iMovie-esque MoviePlus (yes, I am aware that it looks like an extremely basic piece of software compared to Premiere Pro or Final Cut X, but those guys stealthily developed two full-blown Illustrator and Photoshop-calibre pieces of software in a little over four years… Gotta hand it to them).
IMHO, Adobe is looking a lot like Intel (nay, like Quark) here. They are at a serious risk of being overtaken and will no longer be the one and only standard, much like during the Macromedia days.
Oh, if I also may add this tidbit to get more on topic, Serif also confirmed they are indeed working on an iOS port as well, with feature parity or near-parity, which means their engine is already ported to ARM as we speak. Should Apple transition the Mac to A-series processors, Serif would have an even bigger headstart over Adobe than Adobe had over Quark during the Mac OS Classic to [Mac] OS X transition…
What nonsense, A processors are more than fast enough.
You can't be serious, we are a very long way from iPhines that can effectively take care of the computing needs of most people. The end game here is a cell phone that can function as a desktop replacement when docked with a video monitor.
It's not a matter of opinion or even discussion, it's a matter of fact, look at the benchmarks (and weep if you are Intel because performance per watt is even more devastating).
Apple can succeed where Surface RT failed because they won't need to "shrink" OS X to fit ARM like MS tried to shrink Windows to fit...
What did Microsoft "shrink" for RT?
I know the major removed features - bitlocker (replaced with device encryption), media player, Domain support, Software RAID management and it had limited RDC functionality. However, Apple will have exactly the same issues migrating to ARM; they've got to recode the OS for a different architecture, and just about all software written for MacOS will be completely incompatible without some kind of emulation.
ARM CPUs (Like the A9X, and Probably the A10X in the future) certainly give Intel's entry-level mobile CPUs a run for their money and for the notebook/low end series computers, I'd see them being a good fit. But would Apple want to segregate their market in doing this? An A9X and I'm guessing most future Apple SoC device won't be able to keep up with Intel's workhorse CPUs or even desktop class ones. Geekbench is the only real cross platform benchmark we have to go by, and on that the A9X scores in the 5500 range whilst current-gen Skylake CPUs, as seen in the most recent iMac sporting an i7-6700K, can score upwards of 22000. Apple's not about to replace an iMac with an ARM CPU, especially seeing as Apple's inevitable A10(X) which yes, will be a performance, boost, but will probably be battling alongside Intel's 7000-series i5 and i7 (Kaby Lake, expected before the end of 2016) which will also see a performance boost.
My point is - would Apple really create a split in their Desktop/Laptop OS market? There's alternatives - abandon the desktop segment (I don't see them doing this), or run with some kind of Rosetta-like binary translator, but it slows things down, and they're hardly infallible. Rosetta, as I recall, couldn't run programs that required a G5 as the Intel hardware of the era couldn't both run something that CPU demanding and the translator at the same time.
Apple's solution for their 68k to PPC transition was a far better solution, giving the 68k emulator direct access to the MacOS nanokernal, thus allowing PPC interrupts to be handled as 68k interupts, allowing mixed switching and importantly allowing developers to mix their 68k and PPC code without much issue. It would be possible to tie extremely low-level binary translation into XNU and if Apple does ever go down the ARM route I'm guessing they'd do this, but in a security conscious age it might not be very wise and Apple might be trying to plug holes before moving in this direction.
No, all software written for Mac OS X is compatible when it runs on ARM. It is just a recompile away. Mac OS X itself is also a recompile away for it to run on ARM. But read my previous post about possible 'difficulties'. That leaves us compatibility for MS x86 applications. Read my previous post on that. I might add that 'wine' itself is not entirely enough, most of the time dlls from the application (in x86 code) are used that must also be translated to ARM code, this can be done in a static way (only once). It would be nice if Apple made an app for that (not that I need it). Note that people already have this kind of setup running, it seems: https://wiki.winehq.org/ARM#Status (look at 'I got Wine 1.5.11 and Qemu to work with Ubuntu 12.10 on ARM' https://forum.winehq.org/viewtopic.php?f=8&t=17701).
By the way, if you look at benchmarks, compare single core results, multicore is useless.
You can't be serious, we are a very long way from iPhines that can effectively take care of the computing needs of most people. The end game here is a cell phone that can function as a desktop replacement when docked with a video monitor.
I say the end game is cluster. So we can call on as much power as needed in a given situation but know it's not sitting redundant while someone else has need.
In fact it's the other way around. A cluster (any cluster) can be swamped in an instant, and is a single point of failure (and attack) and depends on bandwidth which is itself a single point of failure. Cloud clusters are hype, and almost always totally unnecessary and a waste of energy and space, especially when you have pocket supercomputers that dissipate zero when not used.
No, all software written for Mac OS X is compatible when it runs on ARM. It is just a recompile away.
I'm going to need to see proof of that. I doubt every developer that's ever written software for OSX has recoded it to also work on ARM. Apple has made steps towards this with Swift, but it's not just as simple as hitting the 'compile for iOS' button and it's certainly not "all software written for OSX"
That leaves us compatibility for MS x86 applications. Read my previous post on that. I might add that 'wine' itself is not entirely enough, most of the time dlls from the application (in x86 code) are used that must also be translated to ARM code, this can be done in a static way (only once).
I read your previous post, I figured it was bait considering it contains a sentence basically copy+pasted from Wikipedia and you're combining terminology with a complete misunderstanding of what those words mean. Wine isn't a binary translator, it's (explicitly) not even an emulator. Also I love how you think a "company" that made it exists. Cute.
People are running an OS coded and compiled for ARM on ARM-based architecture? Well I'll be, that's something isn't it? And did you even read the first sentence of the linked article? It even states x86-compiled programs won't work on Wine alone. QEmu is yet again a different piece of software altogether, being a hypervisor. Yes, you can do architecture emulation in a similar capacity to Apple's old PPC/68k emulation, but it's got exactly the same drawbacks.
No, all software written for Mac OS X is compatible when it runs on ARM. It is just a recompile away.
I'm going to need to see proof of that. I doubt every developer that's ever written software for OSX has recoded it to also work on ARM. Apple has made steps towards this with Swift, but it's not just as simple as hitting the 'compile for iOS' button and it's certainly not "all software written for OSX"
I read your previous post, I figured it was bait considering it contains a sentence basically copy+pasted from Wikipedia and you're combining terminology with a complete misunderstanding of what those words mean. Wine isn't a binary translator, it's (explicitly) not even an emulator. Also I love how you think a "company" that made it exists. Cute.
If an architectural split was to exist on the platform, why on earth would there be an application/software level translator for it?
People are running an OS coded and compiled for ARM on ARM-based architecture? Well I'll be, that's something isn't it? And did you even read the first sentence of the linked article? It even states x86-compiled programs won't work on Wine alone. QEmu is yet again a different piece of software altogether, being a hypervisor. Yes, you can do architecture emulation in a similar capacity to Apple's old PPC/68k emulation, but it's got exactly the same drawbacks.
Why?
You seem to have problems understanding basic computer science principles and lack some reading skills. Maybe your a kid. But anyway: - yes it's a recompile away because all code uses APIs and is implemented in C, Objective C or C++, there is no need to write assembly code for Mac OS X. - no copy and past from Wikipedia, I know it all you know, and no I didn't say that it was a company that created wine, and no the misunderstanding is yours alone: I just combine some existing technology to make it work. - you misunderstand again, basically a joke (but also a request that Apple makes a nice package of the combination of technology I proposed (a la Rosetta)). - you misunderstand again, read a bit further, I combine two technologies, Qemu can also be used as an assembly translator, the part I need to make it all work. - why? because it makes it easy to compare CPUs (essentially, the number of cores isn't fundamental to its design and implementation, it's a true technological comparison).
No, all software written for Mac OS X is compatible when it runs on ARM. It is just a recompile away.
I'm going to need to see proof of that. I doubt every developer that's ever written software for OSX has recoded it to also work on ARM. Apple has made steps towards this with Swift, but it's not just as simple as hitting the 'compile for iOS' button and it's certainly not "all software written for OS X"
- yes it's a recompile away because all code uses APIs and is implemented in C, Objective C or C++, there is no need to write assembly code for Mac OS X.
This is not accurate! Mac OS X software is not necessarily a compile away to run on ARM.
This would only be true if the OS X app were written to:
use only APIs with equivalent ARM iOS APIs
compensate for lack of mouse pointer
compensate for lack of machine resident file access
use platform independent Display Interaction
A simple example is OS X has NSTableView where a table has multiple columns and each column can be edited,resized, sorted, hidden, rearranged (moved in relation to other columns). iTunes is an example of a multi-column table.
Further, an OS X app can implement a multi-column table without writing a single line of code -- using a OS X capability called Bindings in Interface Builder.
Neither multi-column tables nor Bindings and available in iOS!
- yes it's a recompile away because all code uses APIs and is implemented in C, Objective C or C++, there is no need to write assembly code for Mac OS X.
This is not accurate! Mac OS X software is not necessarily a compile away to run on ARM.
This would only be true if the OS X app were written to:
use only APIs with equivalent ARM iOS APIs
compensate for lack of mouse pointer
compensate for lack of machine resident file access
use platform independent Display Interaction
A simple example is OS X has NSTableView where a table has multiple columns and each column can be edited,resized, sorted, hidden, rearranged (moved in relation to other columns). iTunes is an example of a multi-column table.
Further, an OS X app can implement a multi-column table without writing a single line of code -- using a OS X capability called Bindings in Interface Builder.
Neither multi-column tables nor Bindings and available in iOS!
Dick, I was talking about Mac OS X on ARM (read my earlier posts).
You seem to have problems understanding basic computer science principles and lack some reading skills. Maybe your a kid. But anyway: - yes it's a recompile away because all code uses APIs and is implemented in C, Objective C or C++, there is no need to write assembly code for Mac OS X. - no copy and past from Wikipedia, I know it all you know, and no I didn't say that it was a company that created wine, and no the misunderstanding is yours alone: I just combine some existing technology to make it work. - you misunderstand again, basically a joke (but also a request that Apple makes a nice package of the combination of technology I proposed (a la Rosetta)). - you misunderstand again, read a bit further, I combine two technologies, Qemu can also be used as an assembly translator, the part I need to make it all work. - why? because it makes it easy to compare CPUs (essentially, the number of cores isn't fundamental to its design and implementation, it's a true technological comparison).
Just because Xcode has the ability to compile stuff for iOS or MacOS doesn't automatically mean, as you stated, "all OSX software will run on ARM". Far from it. There's a reason companies don't often make architecture shifts.
Rosetta and Wine are not similar. No part of Wine is at all similar to what Rosetta is, or what it does. Rosetta was a software-layer translator that let older PPC applications run on Intel hardware but had a lot of limitations that would not be acceptable if they were to run side-by-side architectures, and different again from the 68k emulator which was an incredibly well implemented solution I can see them using again. It served a different purpose from Rosetta, and did it well.
It's not impossible that Apple will switch to ARM, and I do think it's going to happen, but it probably won't happen for a while without Apple alienating sections of their market. ARM cannot keep up with Intel's desktop class CPUs, and they are lighyears behind the workstation CPUS. An A9X's 2,000 flops of performance is a fraction of the 500gflops a single CPU in a high-end Mac Pro can do, and that's a 4-generation old CPU. Read this, specifically the evaluation section which details limitations.
There's nothing wrong with multicore performance comparisons, unless you're specifically comparing single-core performance or you're dealing with multiple platforms and want a gadge of CPU perfromance without the multicore variable. OSX multithreads very well, and thus multicore is a very relevant benchmark. If you're wanting to use single-threaded performance, it's still not even appearing on the top 40 pages on Geekbench and there's a lot of several year old laptops in there.
- yes it's a recompile away because all code uses APIs and is implemented in C, Objective C or C++, there is no need to write assembly code for Mac OS X.
This is not accurate! Mac OS X software is not necessarily a compile away to run on ARM.
This would only be true if the OS X app were written to:
use only APIs with equivalent ARM iOS APIs
compensate for lack of mouse pointer
compensate for lack of machine resident file access
use platform independent Display Interaction
A simple example is OS X has NSTableView where a table has multiple columns and each column can be edited,resized, sorted, hidden, rearranged (moved in relation to other columns). iTunes is an example of a multi-column table.
Further, an OS X app can implement a multi-column table without writing a single line of code -- using a OS X capability called Bindings in Interface Builder.
Neither multi-column tables nor Bindings and available in iOS!
Dick, I was talking about Mac OS X on ARM (read my earlier posts).
Ah ... That's different!
But, observing Apple, I don't think Apple will port OS X to ARM. Rather, I suspect that they will extend iOS to incorporate most OS X functions, where appropriate.
There are many examples of capabilities developed for iOS then ported back to the OS X mothership -- Metal is one of the latest examples.
At some point iOS could subsume the major capabilities ...
What If Apple offered a iPad Pro keyboard with a trackpad, trackpad gestures, screen cursor and yes, more robust resident file access - FTFF Finally, The Fine Finder.
There is no reason that Apple couldn't re-implement (doing it right, this time) on iOS -- things like multi-column tables and bindings.
There is no reason that Apple couldn't offer a desktop or laptop with both an Intel CPU and Ax APU.
I believe we'll see more of this platform cross-pollination at WWDC 2016!
Apple can succeed where Surface RT failed because they won't need to "shrink" OS X to fit ARM like MS tried to shrink Windows to fit...
What did Microsoft "shrink" for RT?
I know the major removed features - bitlocker (replaced with device encryption), media player, Domain support, Software RAID management and it had limited RDC functionality. However, Apple will have exactly the same issues migrating to ARM; they've got to recode the OS for a different architecture, and just about all software written for MacOS will be completely incompatible without some kind of emulation.
ARM CPUs (Like the A9X, and Probably the A10X in the future) certainly give Intel's entry-level mobile CPUs a run for their money and for the notebook/low end series computers, I'd see them being a good fit. But would Apple want to segregate their market in doing this? An A9X and I'm guessing most future Apple SoC device won't be able to keep up with Intel's workhorse CPUs or even desktop class ones. Geekbench is the only real cross platform benchmark we have to go by, and on that the A9X scores in the 5500 range whilst current-gen Skylake CPUs, as seen in the most recent iMac sporting an i7-6700K, can score upwards of 22000. Apple's not about to replace an iMac with an ARM CPU, especially seeing as Apple's inevitable A10(X) which yes, will be a performance, boost, but will probably be battling alongside Intel's 7000-series i5 and i7 (Kaby Lake, expected before the end of 2016) which will also see a performance boost.
My point is - would Apple really create a split in their Desktop/Laptop OS market? There's alternatives - abandon the desktop segment (I don't see them doing this), or run with some kind of Rosetta-like binary translator, but it slows things down, and they're hardly infallible. Rosetta, as I recall, couldn't run programs that required a G5 as the Intel hardware of the era couldn't both run something that CPU demanding and the translator at the same time.
Apple's solution for their 68k to PPC transition was a far better solution, giving the 68k emulator direct access to the MacOS nanokernal, thus allowing PPC interrupts to be handled as 68k interupts, allowing mixed switching and importantly allowing developers to mix their 68k and PPC code without much issue. It would be possible to tie extremely low-level binary translation into XNU and if Apple does ever go down the ARM route I'm guessing they'd do this, but in a security conscious age it might not be very wise and Apple might be trying to plug holes before moving in this direction.
You pretty much made my point by describing the "major removed features" of RT.
You missed my point by suggesting that Apple will have the same problem with ARM, because I was suggesting that Apple could "grow" iOS to fit an ARM based laptop form factor, not "shrink" OS X to fit ARM. Also, while not specifically ARM related, by building on iOS, Apple would avoid trying to create a touch-friendly version of OS X, a challenge that MS and most all Windows app developers must consider.
I do understand your concern about what may appear to be a "split" in Desktop/Laptop, but who's to say that it would be so confusing to have iOS based "laptops" with a permanently attached keyboard, and regular workhorse laptops with full OS X? In my mind (which is to say just my opinion), a spectrum of product offerings could be offered with a slight amount of feature overlap and would make perfect sense.
You pretty much made my point by describing the "major removed features" of RT.
You missed my point by suggesting that Apple will have the same problem with ARM, because I was suggesting that Apple could "grow" iOS to fit an ARM based laptop form factor, not "shrink" OS X to fit ARM. Also, while not specifically ARM related, by building on iOS, Apple would avoid trying to create a touch-friendly version of OS X, a challenge that MS and most all Windows app developers must consider.
I do understand your concern about what may appear to be a "split" in Desktop/Laptop, but who's to say that it would be so confusing to have iOS based "laptops" with a permanently attached keyboard, and regular workhorse laptops with full OS X? In my mind (which is to say just my opinion), a spectrum of product offerings could be offered with a slight amount of feature overlap and would make perfect sense.
I know it's a list of removed features, but they're all more enterprise-oriented and really don't have much place in a tablet. Bitlocker was made redundant by device encryption, RAIDs don't exist on tablets. Media player's removal was a bit of a hit considering the few RT alternatives, though, and as for RDC and Domain - I'd love to see this on tablets, it would make my job so much easier.
Yea, sorry I did misinterperate. Creating a fully-grown ARM-based iOS(ish) laptop as an alternative to a MacBook (Reintroduction of the iBook?) would be a fantastic alternative to shrinking OSX, and it would be fantastic if it'd allow mouse support.
Comments
I suspect that is already happening -- just DockDuck "Siri Watson"
In more generic terms (emphasis mine):
Also, below is another link from 8 months ago that shows iOS apps using Watson:
This example uses Node.js for the intermediary http server. But, recently IBM released a web server written entirely in Swift -- Kitura beta. One (of many) advantages being that a developer can use the same development language (Swift) to write both ends of client-server apps.
Apple can succeed where Surface RT failed because they won't need to "shrink" OS X to fit ARM like MS tried to shrink Windows to fit...
Apple is already "growing" iOS to be a "MacBook" of sorts--look at the iPad Pro line. I would not be surprised to see a near-future MacBook* line being based on iOS, where the MacBook Pro line stays with OS X/Intel.
(*Maybe they will call it something other than MacBook, but there is already a functional distinction between MB and MBP, so the model names could be preserved).
Awesome post. It's all very exciting for the future of Apple/IMB.
I know the major removed features - bitlocker (replaced with device encryption), media player, Domain support, Software RAID management and it had limited RDC functionality. However, Apple will have exactly the same issues migrating to ARM; they've got to recode the OS for a different architecture, and just about all software written for MacOS will be completely incompatible without some kind of emulation.
ARM CPUs (Like the A9X, and Probably the A10X in the future) certainly give Intel's entry-level mobile CPUs a run for their money and for the notebook/low end series computers, I'd see them being a good fit. But would Apple want to segregate their market in doing this? An A9X and I'm guessing most future Apple SoC device won't be able to keep up with Intel's workhorse CPUs or even desktop class ones. Geekbench is the only real cross platform benchmark we have to go by, and on that the A9X scores in the 5500 range whilst current-gen Skylake CPUs, as seen in the most recent iMac sporting an i7-6700K, can score upwards of 22000. Apple's not about to replace an iMac with an ARM CPU, especially seeing as Apple's inevitable A10(X) which yes, will be a performance, boost, but will probably be battling alongside Intel's 7000-series i5 and i7 (Kaby Lake, expected before the end of 2016) which will also see a performance boost.
My point is - would Apple really create a split in their Desktop/Laptop OS market? There's alternatives - abandon the desktop segment (I don't see them doing this), or run with some kind of Rosetta-like binary translator, but it slows things down, and they're hardly infallible. Rosetta, as I recall, couldn't run programs that required a G5 as the Intel hardware of the era couldn't both run something that CPU demanding and the translator at the same time.
Apple's solution for their 68k to PPC transition was a far better solution, giving the 68k emulator direct access to the MacOS nanokernal, thus allowing PPC interrupts to be handled as 68k interupts, allowing mixed switching and importantly allowing developers to mix their 68k and PPC code without much issue. It would be possible to tie extremely low-level binary translation into XNU and if Apple does ever go down the ARM route I'm guessing they'd do this, but in a security conscious age it might not be very wise and Apple might be trying to plug holes before moving in this direction.
Sure, you may argue that it's not a 100% replacement… yet. Remember InDesign 1.0? Was it a full QuarkXPress replacement? As for some weird, kludgy tools like 3D support in Photoshop and Illustrator, well… those are niche tools, to say the least. I'd venture to say that the vast majority of Photoshop *and* Lightroom users (which are, by and large, mostly photographers) will rarely, if ever, touch those. Designers and other creatives will surely have some use for them but, even then, it will be a rare occurrence. Besides, Affinity Photo already offers a few perspective tools of its own, so it's not like they couldn't come up with a technically comparable but better solution UX-wise for that case scenario one day.
By the way, Serif also offered animation tools in the soon-to-be-discontinued (yes, those guys are really betting their company on Affinity) DrawPlus (which could serve as a basis to compete with Animate CC as a separate app – yes, I am aware that I am reposting a link, but that post is relevant to both apps), WebPlus (so they may very well compete with other web and UX authoring tools soon) and the iMovie-esque MoviePlus (yes, I am aware that it looks like an extremely basic piece of software compared to Premiere Pro or Final Cut X, but those guys stealthily developed two full-blown Illustrator and Photoshop-calibre pieces of software in a little over four years… Gotta hand it to them).
IMHO, Adobe is looking a lot like Intel (nay, like Quark) here. They are at a serious risk of being overtaken and will no longer be the one and only standard, much like during the Macromedia days.
Oh, if I also may add this tidbit to get more on topic, Serif also confirmed they are indeed working on an iOS port as well, with feature parity or near-parity, which means their engine is already ported to ARM as we speak. Should Apple transition the Mac to A-series processors, Serif would have an even bigger headstart over Adobe than Adobe had over Quark during the Mac OS Classic to [Mac] OS X transition…
No, all software written for Mac OS X is compatible when it runs on ARM. It is just a recompile away.
Mac OS X itself is also a recompile away for it to run on ARM. But read my previous post about possible 'difficulties'.
That leaves us compatibility for MS x86 applications. Read my previous post on that.
I might add that 'wine' itself is not entirely enough, most of the time dlls from the application (in x86 code) are used that must also be translated to ARM code, this can be done in a static way (only once).
It would be nice if Apple made an app for that (not that I need it).
Note that people already have this kind of setup running, it seems: https://wiki.winehq.org/ARM#Status (look at 'I got Wine 1.5.11 and Qemu to work with Ubuntu 12.10 on ARM' https://forum.winehq.org/viewtopic.php?f=8&t=17701).
By the way, if you look at benchmarks, compare single core results, multicore is useless.
Cloud clusters are hype, and almost always totally unnecessary and a waste of energy and space, especially when you have pocket supercomputers that dissipate zero when not used.
I read your previous post, I figured it was bait considering it contains a sentence basically copy+pasted from Wikipedia and you're combining terminology with a complete misunderstanding of what those words mean. Wine isn't a binary translator, it's (explicitly) not even an emulator. Also I love how you think a "company" that made it exists. Cute.
If an architectural split was to exist on the platform, why on earth would there be an application/software level translator for it?
People are running an OS coded and compiled for ARM on ARM-based architecture? Well I'll be, that's something isn't it? And did you even read the first sentence of the linked article? It even states x86-compiled programs won't work on Wine alone. QEmu is yet again a different piece of software altogether, being a hypervisor. Yes, you can do architecture emulation in a similar capacity to Apple's old PPC/68k emulation, but it's got exactly the same drawbacks.
Why?
Maybe your a kid.
But anyway:
- yes it's a recompile away because all code uses APIs and is implemented in C, Objective C or C++, there is no need to write assembly code for Mac OS X.
- no copy and past from Wikipedia, I know it all you know, and no I didn't say that it was a company that created wine, and no the misunderstanding is yours alone: I just combine some existing technology to make it work.
- you misunderstand again, basically a joke (but also a request that Apple makes a nice package of the combination of technology I proposed (a la Rosetta)).
- you misunderstand again, read a bit further, I combine two technologies, Qemu can also be used as an assembly translator, the part I need to make it all work.
- why? because it makes it easy to compare CPUs (essentially, the number of cores isn't fundamental to its design and implementation, it's a true technological comparison).
This is not accurate! Mac OS X software is not necessarily a compile away to run on ARM.
This would only be true if the OS X app were written to:
- use only APIs with equivalent ARM iOS APIs
- compensate for lack of mouse pointer
- compensate for lack of machine resident file access
- use platform independent Display Interaction
A simple example is OS X has NSTableView where a table has multiple columns and each column can be edited, resized, sorted, hidden, rearranged (moved in relation to other columns). iTunes is an example of a multi-column table.Further, an OS X app can implement a multi-column table without writing a single line of code -- using a OS X capability called Bindings in Interface Builder.
Neither multi-column tables nor Bindings and available in iOS!
Rosetta and Wine are not similar. No part of Wine is at all similar to what Rosetta is, or what it does. Rosetta was a software-layer translator that let older PPC applications run on Intel hardware but had a lot of limitations that would not be acceptable if they were to run side-by-side architectures, and different again from the 68k emulator which was an incredibly well implemented solution I can see them using again. It served a different purpose from Rosetta, and did it well.
It's not impossible that Apple will switch to ARM, and I do think it's going to happen, but it probably won't happen for a while without Apple alienating sections of their market. ARM cannot keep up with Intel's desktop class CPUs, and they are lighyears behind the workstation CPUS. An A9X's 2,000 flops of performance is a fraction of the 500gflops a single CPU in a high-end Mac Pro can do, and that's a 4-generation old CPU. Read this, specifically the evaluation section which details limitations.
There's nothing wrong with multicore performance comparisons, unless you're specifically comparing single-core performance or you're dealing with multiple platforms and want a gadge of CPU perfromance without the multicore variable. OSX multithreads very well, and thus multicore is a very relevant benchmark. If you're wanting to use single-threaded performance, it's still not even appearing on the top 40 pages on Geekbench and there's a lot of several year old laptops in there.
Ah ... That's different!
But, observing Apple, I don't think Apple will port OS X to ARM. Rather, I suspect that they will extend iOS to incorporate most OS X functions, where appropriate.
There are many examples of capabilities developed for iOS then ported back to the OS X mothership -- Metal is one of the latest examples.
At some point iOS could subsume the major capabilities ...
What If Apple offered a iPad Pro keyboard with a trackpad, trackpad gestures, screen cursor and yes, more robust resident file access - FTFF Finally, The Fine Finder.
There is no reason that Apple couldn't re-implement (doing it right, this time) on iOS -- things like multi-column tables and bindings.
There is no reason that Apple couldn't offer a desktop or laptop with both an Intel CPU and Ax APU.
I believe we'll see more of this platform cross-pollination at WWDC 2016!
You missed my point by suggesting that Apple will have the same problem with ARM, because I was suggesting that Apple could "grow" iOS to fit an ARM based laptop form factor, not "shrink" OS X to fit ARM. Also, while not specifically ARM related, by building on iOS, Apple would avoid trying to create a touch-friendly version of OS X, a challenge that MS and most all Windows app developers must consider.
I do understand your concern about what may appear to be a "split" in Desktop/Laptop, but who's to say that it would be so confusing to have iOS based "laptops" with a permanently attached keyboard, and regular workhorse laptops with full OS X? In my mind (which is to say just my opinion), a spectrum of product offerings could be offered with a slight amount of feature overlap and would make perfect sense.
Yea, sorry I did misinterperate. Creating a fully-grown ARM-based iOS(ish) laptop as an alternative to a MacBook (Reintroduction of the iBook?) would be a fantastic alternative to shrinking OSX, and it would be fantastic if it'd allow mouse support.