41–48 of 48 posts
I don't know how CPUs and instructions work but wouldn't this mean that every app has to be recompiled for ARM or run in an emulator?
Yes, it would mean that.
It made things easier for developers because they only had to ship one set of installation media regardless of the CPU the user had.
Earlier quoted context omitted.
Yes, it would mean that.
In the NeXT days, a program could be compiled as a "fat" binary that would run on multiple supported CPU architectures. It made things easier for developers because they only had to ship one set of installation media regardless of the CPU the user had.
Earlier quoted context omitted.
Yes, it would mean that.
In the NeXT days, a program could be compiled as a "fat" binary that would run on multiple supported CPU architectures. It made things easier for developers because they only had to ship one set of installation media regardless of the CPU the user had.
Earlier quoted context omitted.
Yes, it would mean that.
In the NeXT days, a program could be compiled as a "fat" binary that would run on multiple supported CPU architectures. It made things easier for developers because they only had to ship one set of installation media regardless of the CPU the user had.
Makes sense. Allegedly they had pretty much every version OS X after Rhapsody continuing to run on x86 in some capacity until the x86 version of OS X finally came out. Keeping an ARM version around seems like a no brainer. I suspect this isn't being held in case the Mac market falls apart, but in case the iPad market starts losing to Surface and friends.
Exactly, in fact there's even more to it then that. Particularly at Apple's scale, maintaining a codebase across multiple architectures internally, even if there is absolutely zero foreseeable intention to use them, offers significant value. Strategically of course it creates some hedge against over dependence on any single supplier, it's not just "the Mac market falling apart" so much as Intel/AMD dropping the ball…
Right. Even if they had no intent of making ARM laptops (although I suspect they probably do have that intent), the exercise of keeping the code portable between Intel and ARM would serve them in good stead even if they later went to yet a third CPU architecture.
Makes sense. Allegedly they had pretty much every version OS X after Rhapsody continuing to run on x86 in some capacity until the x86 version of OS X finally came out. Keeping an ARM version around seems like a no brainer. I suspect this isn't being held in case the Mac market falls apart, but in case the iPad market starts losing to Surface and friends.
I forget the exact magic method, and don't know if it is still in shipping versions of OS X, but I would be surprised if at least internal-to-Apple versions of their compiler and toolchain didn't still have this available for use.
Earlier quoted context omitted.
Exactly, in fact there's even more to it then that. Particularly at Apple's scale, maintaining a codebase across multiple architectures internally, even if there is absolutely zero foreseeable intention to use them, offers significant value. Strategically of course it creates some hedge against over dependence on any single supplier, it's not just "the Mac market falling apart" so much as Intel/AMD dropping the ball…
Should this apply to cloud provider portability?
• which are "obvious" and perhaps even necessary for productive coding of distributed systems software; and
• which have huge economies of scale (one shared cluster for all customers beats the pants off the performance+availability of your company's puny little three-node private cluster), and yet...
• which other major clouds don't support at all.
Effectively, all the "clouds" currently only offer between 30% and 90% of what you'd want in something that called itself "a cloud." Nobody has a "whole cloud" (AWS is closest, but still not there.)
Designing for portability between these clouds would be like writing assembly intended to be portable between processor architectures, when only one architecture had an ALU, only one had registers, and only one could conditionally branch. It would be madness.
---
Personally, I feel like, to be able to sensibly design for portability between cloud providers, they'd need a lot more features in common than they have now.
Maybe we could invent a minimum common standard to hold the cloud providers' stacks to—maybe a small one at first, with a growing list of expectations over time; or maybe a "core" spec, and then a number of "levels" of support atop it. Then you could say you've targeted "IaaS Level 3", and clouds could claim to support that, and cloud-abstraction libraries like Fog could actually do something useful.
Earlier quoted context omitted.
Nothing stopping you from installing Blink Shell or Prompt on your iPad-like device and connecting to a GCE instance or your own linux server to work on those things.
I see we're basically agreeing the future of working on such things in private is not with Apple hardware then. (Unless you are Google)