Apple already has several ARM powered laptops drifting around internally
hardware.slashdot.org
hardware.slashdot.org
Looks like a) he's not extrapolating anything, and b) the AC knew those huuuuge barriers existed when he wrote his post.
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.
Give me a foldable iPad that still has screen in both halves, but that is usable in landscape, and I will buy.
Appropriate haptics could make it work like a tiny laptop in portrait, but like a regular all-screen iPad in landscape.
Non-strategic value though is probably just as important as any of this stuff: as probably most of HN knows well, keeping a codebase portable can be quite helpful in terms of plain and simple quality. Obscure bugs or bad patterns that are hard to find on one architecture can be a lot easier to identify on another. It can help promote discipline and good practices. Portability I think is really a constant process rather then a goal or single thing, it's a lot easier to have worked on it all along for years before you need it then try to "port" something later because without the constant pressure of staying portable it's all too easy to start falling into dependence on features (or worse, quirks) of a single arch and build up more and more technical debt. Then when the "bill" (not necessarily just in terms of money but sheer developer hours) finally comes due it's effectively unpayable.
• 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.
This is just my speculation. But, 1) You learn things; 2) You lessen lock-in / dependence, in turn reducing the markup you have to pay on existing production inputs.
Apple's benefited very considerably from the increasing customization and optimization of its phone CPU et al. platform. What's the argument against carrying that over to their computer lines, if and when they can make that a relatively smooth transition?
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.
(That said, even on this account they had laptops running Intel for several years before the transition was decided upon).
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.
Although if the software is through the Mac App Store only, then... well, it won't be a very useful device. I hope that they're looking to replace the Macbook with an ARM device, not create a new Chromebook.
As I think about it -- wouldn't app store (if well run, then it provides the best possible security for distribution of binaries without source code and the most consumer friendly commercial licensing model) + open source eco-system (self-compiled -- source only distribution) pretty much the best possible world for users? There is (kind of) an open-source argument for making binary distribution without source onerous or impossible...
Perhaps they'll bundle or distribute an official version of something like homebrew to make installing open-source software as easy as possible and maybe even provide a way for binaries generated from these packages to become signed and distributed as binaries as an optimization?
I don't think I would mind app-store being the only way to get pre-compiled binaries if augmented with a well-supported open-source ecosystem for utilities that need to venture beyond the capabilities of the app-store sandbox. There is a technical argument for making any software that needs to operate beyond the sandbox subject to source code auditing simply because of the potential attack surface ... I wouldn't necessarily mind if subscription pricing was the only business model for such sandbox-spanning utilities -- continuance maintenance (and ongoing revenue) for software that works beyond the sandbox is needed from a security perspective ...
One of our devs just got a new XPS 15. It's a gorgeous machine. Amazing. First time I've envied a non-Apple machine since the early 2000s. I still marginally prefer the Mac track pad but the rest is on par or better.
For a preview of the future, try this one on macOS 10.12 today:
% lldb --one-line run /usr/bin/python
spoiler:
Current executable set to '/usr/bin/python' (x86_64).
error: process exited with status -1 (cannot attach to process due to System Integrity Protection)There is a genuine argument about control but overselling it just lowers your credibility, especially since it reveals tunnel vision: statistically very few Mac users need to run a debugger but more are at risk for malware which uses sensitive APIs.
Also, if you have malware getting far enough to try to ptrace binaries running on your uid, I would imagine things are still game over despite being prevented from debugging a new interpreter process. I'm not buying the malware scare when it comes to debugging newly forked processes on a non-root uid.
I think your argument would have been valid if I'd never clicked "enable debugging for this mac" in xcode.
It made things easier for developers because they only had to ship one set of installation media regardless of the CPU the user had.