Apple will announce move to ARM-based Macs later this month
theverge.com
theverge.com
https://www.bloomberg.com/news/articles/2020-06-09/apple-pla...
older: https://www.bloomberg.com/news/articles/2020-04-23/apple-aim...
---
Personally, I gave up on the Apple ecosystem years ago and moved to Linux. But I feel ambivalent about this.
On one hand, the iPhone/Pad chips have impressive performance and power consumption, at least for the mobile use case. Some competition in this space can't hurt, and it will be interesting how well they fare against Intel and AMD in a different environment.
On the other hand: this seems like a golden opportunity for Apple continue the path of merging iOS and Mac OS, turning the desktop platform into an equally walled and locked down garden.
This will also be a rocky road for very performance sensitive applications which Macs are used for a lot. Like video editing, Photoshop etc.
"According to people familiar with the matter."
Does this article provide any actual new info compared to the one from Bloomberg?
They can't turn macOS into a totally walled garden, without making it impossible to use as a development platform. If I can't compile and run my own software, or software I downloaded from others in source form, I can't use it as a development platform.
And Apple needs a development platform, for people to develop iOS/macOS apps on, and for its own OS developers to use in developing iOS/macOS.
It’s an extremely shitty limitation that Apple put in place to give the appearance that they allow sideloading.
Have they shown developers much respect in the past? You can't even compile for the mac on other OSes, from what I hear.
I totally agree Apple is not the most developer-friendly company, and I wish they'd focus on developer needs more. They should copy a page out of Microsoft's book and take Steve Ballmer's "developers, developers, developers" to heart.
> You can't even compile for the mac on other OSes, from what I hear.
I can compile Windows software on Linux or macOS using MinGW. Did Microsoft do anything to enable that? No, independent developers cloned the Microsoft API headers, etc, to build a cross-platform compilation environment for Windows.
There really isn't a MinGW-equivalent for macOS. There should be. But, just as Microsoft didn't do anything to produce MinGW, I don't know why we should expect Apple to do anything to produce the equivalent for macOS. (It should actually be an easier job than the MinGW developers had – macOS uses the open source LLVM toolchain which is already cross-platform – it is just a matter of providing header files and library stubs for use when compiling on other operating systems.)
(You might try testing the Windows executable under Wine on either macOS, or even a Linux Docker container with Docker for Mac – however, that doesn't work well in practice, because Wine is full of bugs and gaps, and a lot of the time the executable doesn't work properly under Wine due to Wine bugs/gaps but works fine on real Windows. So you still need the Windows VM for testing. But you can stay away from it during compilation.)
Mingw on mac is evidently in homebrew. I've never used it, no idea how well it works. I don't write Windows software if I can ever help it.
Well, it works just as well as MinGW on Windows does. If something isn't working with MinGW on macOS/Linux, it isn't going to work in MinGW on Windows either.
And MinGW on Windows works pretty well, but occasionally you hit some odd problems you might not have had with the Microsoft SDK (e.g. [1]).
[1] https://stackoverflow.com/questions/57885666/mingw-localtime...
The future was very bright when that happened.
Now, it seems apple is gazing ever more inwards.
Maybe they can get close enough on power consumption or instructions per dollar to be worthwhile, but I can't imagine any way an ARM Mac is going to be competitive for a workstation or gaming machine.
It's not going to compete with the Mac Pro for a little while, but who knows.
I think this is the result of two trends, firstly ARM getting so much better faster (especially Apple SoCs). Secondly, how dire Intel has been at improving performance. They really haven't got very far over the last decade.
Switching to arm might improve power efficiency (though surely most power goes to the screen?) but it could have a bigger impact on cpu temperature and reducing thermal throttling.
Bloomberg suggests that other laptop makers might also switch to arm. I think this is a place where apple could have a key advantage because their arm chips seem to always be significantly better than the competition (at least for mobile).
Most people will do computing consisting of:
- browsing the web/using complicated web apps
- watching video
- word processors or similar programs
I think these days we should be less concerned about some traditionally compute-heavy tasks because they have been being encouraged to switch to gpu compute for performance gains for a while now. Most things that care about performance will have been ported to gpu already if possible.
I feel like programs like word processors are probably more memory than cpu constrained and a small potential drop in cpu performance would not matter so much to programs that were designed to run on much slower hardware.
Web browsers (well chrome and safari) have already been seriously optimised for running on atm chips.
I saw a really cheap MacBook Air deal the other day and was tempted until I saw they're i3 based. Assuming App support, I could see them replace that with an ARM based CPU without anyone noticing.
68k->PPC, PPC->PPC64, PPC->x86, x86->x86-66, arm->arm64
More practically, the transitions so far have been like this: 68k -> PPC (With full 68k emulation) -> x86 (with partial PPC emulation) -> x86_64
Then there is the NeXT side that ran on 68k, x86, PA-RISC, and SPARC
Of course OS X was the foundation to iOS
I think the forced death of 32bit apps last year entirely in preparation for moving to ARM.
You probably mean this is so they're not in multiple transitions at once. Something to note here is that Microsoft's x86 emulation only works for 32 bit apps (a processor limitation?), but with Apple having more control over their chips (and no knowledge about the exact issue) I could imagine them having it solved.
(Of course, there are always difficult cases that will take lots of work)
I hope they don't also continue to lock down macos (though I imagine they intend to) by restricting applications to only being available from the app store. That would set a terrible precedent for personal computing.
Just like they did with the mk86->ppc transition, just like they did with the ppc->x86 transition.
> I hope they don't also continue to lock down macos
Let's not confuse moving Macs to ARM processors with turning Macs into iOS devices. Apple has always treated the OS families differently and will continue to do so because they know more than anybody that they meet different needs.
Will they, though? Because Catalina seems like a giant step in the wrong direction if you’re thinking they’re acknowledging the developer - or even power user - need. Seems to me they’ve doubled down on the iOS approach to macOS.
I don't necessarily see it as trying to create a single OS for both desktop and mobile.
I, in fact, find the catalyst apps on macOS still needing work. And I’m talking the Apple ones: Music, News
macOS is for everything, including Dev. They need that for the ecosystem. Look at the new Mac Pro ffs.
Can’t most apps just recompile to support new chip? We don’t need fat binaries right?
10 years from now, we'll probably be having the same argument, and people will be pointing to the latest release of macOS and complaining that surely this one means the end is nigh.
Remember how they turned their backs on the creative people that kept them alive for over a decade when everybody else had switched to windows? Similar story, similar ending.
Sure, the industry ended up following them on a lot of this, but that should be as much a cause for concern as the rest of it. An awful lot of the pro audio / video work that happens on high end Apple hardware could absolutely happen on a machine where the only software comes in via an app store.
sure, but all that functionality remained externally - just not as part of the laptop. locking down the laptop is fundamentally different.
I think what they did was they changed what it looks like to be a pro user. The average user gets a sleak experience while a "pro" user is going to have a docking station.
I actually like that they transitioned to the docking station approach. It means two things:
1. I have a lighter macbook pro for work travel 2. At my desk, one single cable: charges the computer; connects two additional monitors, ethernet, keyboard, mouse, sd card reader, high speed storage, and a scanner. I much prefer that one single cable vs the bundle of cables I used to have to plug/unplug each time I wanted to take or return my computer.
I wouldn't be surprised if they just do that. Ship the lower end laptops with ARM and either an extended iOS or a constrained MacOS.
> Apple has always treated the OS families differently and will continue to do so because they know more than anybody that they meet different needs.
But the different needs part only really applies for the high end Mac Books and from apples POV might no longer be a think if you can develop Swift/Objective-C and similar on iOS.
Hard to predict which path they choose, but I try to stay positive and assume that they have at least one manager capable of thinking rational and in favor of the pro users.
I tend to think that Safari, iPhoto, iMovie iWork, Mail, Calendar and maybe Office support (initially) would be more than enough for that segment of users.
Also don't forget that ARM has weaker memory ordering, so expect to see some fallout from not completely correctly written atomics/lock-free code.
That precedent was set about a decade ago, and even here on HN there is a vast crowd of people who happily support(ed) that.
As a developer there is a nuisance of one more damn thing to test, but compared to the nuisance iOS developers go through to make sure it looks nice on all the different sized devices, testing on an ARM before release isn't bad.
Having developed through the 68k-to-PPC and the PPC-to-x86 and the x86-to-amd64 days I think I can safely say I never had a problem with any code in a transition¹². There are developers that will, if you have written optimized vector code or some such and you care to also be highly performant on the ARM you will be spending resources to make sure you map onto whatever the hardware provides, but you've been doing that for the various Intel instruction set changes anyway.
␄
¹ I'm not saying architecture doesn't matter, doing early ARM porting for Debian I can tell you having C "char" be unsigned was a huge pain in the codebase. But Apple has control top to bottom and has every incentive to make it easy for developers, if only for themselves.
²At least not any problems bad enough to leave a mark on my memory. I'm sure I had to learn about intptr_t sometime after it was invented and probably learned a lesson about size_t at some point.
If you run into this it can:
1. take a while until you aware there is a bug (as it likely only happens spurious potentially with different effects every time)
2. take quite longer to somewhat pin down
3. And if you have not atomic experience and the bug is in a library might be outside of your skill/payment level to fix requiring major rewrites. And all of this parallel to all the other work you have to do.
=> While this should be rather easy for many app for some it might be a nightmare which is combined with the regularly planed work might very well take many month, after customers start using it and run into the bug.
Ah, so just like the Catalina 32-bit Armageddon.
Uuuh, but they have a track record of terrible developer support, so I don't see this actually happening.
Fun fact: Kalamata is the second largest city in southern Greece. I tried finding why they named the Apple project like this, but couldn’t find anything relevant. Any ideas?
(Kalamata is a kind of olive, a small tougher and pithier version of its blander behemoth brethren.)
Looks like that ship has sailed unfortunately. ARM has won, and it won't be long before it conquers the minds of other laptop (and desktop) manufacturers.
EDIT: also see https://news.ycombinator.com/item?id=23076929
Basically just never go more than 24 hours without backing up, one is none, keep multiple offsite backups, etc.
I don't think Apple was in any way naive about how hot Intel chips can run under load. It's also not impossible to make a laptop body that can run those chips with decent temperatures... if you're willing to make compromises on size.
IMO, the biggest issue was they still chose to make the systems thin in spite of the thermal tradeoffs that would result from that.
Yes, thinner's probably more desirable, but would people have stopped buying MBPs if they were a little less thin? I don't think their sales would have shrunk by much, since most Mac users are for the most part a captive audience, because they love MacOS.
It seems like for the 2016 MBP, they either made significant last minute changes or moved up the release date by several months. When they released the computers the Apple stores didn't even have the right screwdrivers to open them for several months. That doesn't seem like something that was planned, but rather the result of some sort of timeline shift.
My guess is that they decided they needed them out the door before Christmas and so skipped the last six months of QA. Maybe it was something else, but I think it was more than just being unwilling to compromise on size.
Regardless, the 2020 models are basically flawless so far, so at least there's that.
Also adds more fuel to the merging of iOS/macOS.
Does somebody have an idea how much approximately would it cost Apple to switch the Apple A14 from ARM to POWER? Usually it is said that the instruction decoder is a small part of a CPU core, and the architectures are not hugely different (compared to AMD64/Intel, at least).
Sure for high end mac the ARM chips probably wouldn't be the best fit for now. But staying with x86 for them is just way easier. POWER might only be interesting if they do a server OS. Which they made pretty clear they are not interested in in the near future. (The rack mounted mac is still a rack mounted workstation. Rack mounting high end workstations isn't that uncommon in certain audio/video processing related job areas. For a server it is missing some pretty basic thinks like: Redundant power supply, management interface, trivial easy to swap RAM/Disks without removing it from the rack, and probably more. ).
How close are arm chips to PowerPC? They’re both risc architectures, right?
The 68k emulation was present up until the death of Mac OS 9, so there is some software that could run on the original Mac all the way to the Classic environment in OS X.
Rosetta was sufficient for most applications during the transition, but there will always be software that doesn't get re-written. Rosetta was introduced in 10.4, and dropped in 10.7. Only 3 versions.
Then there's everyone doing local development in interpreted languages, most of which have stable support for AArch64. Java, python, ruby, go on AArch64? No problem.
The biggest hit things will be mac-specific programs and software built specifically to work with BSD syscalls. We'll see about that stuff.
1. https://www.fool.com/investing/general/2014/04/24/how-much-d...
- Does the T2 have a private uncontrolled connection to system RAM? I know it has some connection to the onboard SSD, other IO and serves as an enclave for platform keys.
- Does the T2 have a private bus/connection to any onboard Ethernet adapter or Wifi like ME does?
- Does the T2 serve as the foundation of remote management features (that are present in all CPUs even if not vPro enabled) like ME does? This is important because it means that it's supposed to be accessed remotely by design.
- Does the T2 serve as the foundation of anti-theft features like ME does? This facility also has remote-access-by-design components.
- Does the T2 serve as the foundation of Protected Video or Audio path type features?
- What can the T2 make the CPU do? Can the T2 freeze the CPU, redirect the CPU to other code, then restore CPU state (I'm fairly sure the ME can do this)
- Intel CPU's have a built-in display adapter and you can't really disable or sidestep it. Hence, there is no separation between what is on the screen and the CPU, and by proxy the ME. To what extent can the T2 modify video RAM without the CPU knowing?
If you’re generating the machine code then it’s your problem isn’t it?
If you’re writing lock-fee code that doesn’t use the C memory model then it’s your problem isn’t it?
> then you probably have lots of other issues to worry about
Yes, yes we do.
Also, failing to adhere to a memory model is one of those tricky things where things seem to work alright on architectures with a strong SMP coherency. But then it all breaks down and you end up chasing heisenbugs all over the place when those assumptions no longer hold. It's not easy to prove a lack of race condition bugs. You usually don't get a compiler error if you forget to mark things volatile, forget memory barriers or forget proper locking.
I guess though simple apps should be easy. It’s just heavy apps that would require more than a simple recompile right?
Going to be interesting which models actually debut this month and their availability. Currently I am not in favor of moving to ARM but I leave the door open for Apple to surprise and tempt me
Much like Apple turned Final Cut Pro into iMovie Pro, this is looking like every Mac Pro will turn into an iPhone Pro. I could be mistaken, maybe they'll figure out some way of handling x86 with real hardware, but if not this is a massive gift to Microsoft.
Docker can run a different OS but not a different arch.
The point of Docker is kind of having the exactly same thing here and there.
With Docker, I can compile, run, test and debug my backend service on Windows or Mac and deploy to Linux, knowing that I ran and tested the exact same binary.
If you deploy on x86 (as you do), having ARM Docker doesn't help you much.
Also slack and zoom for linux suck :(
Apple switched to x86 in the first place because it had become a standard. Adopting a common standard is always going to have advantages. The advantages of supporting or adopting ARM has to outweigh those advantages to be worthwhile. This is true not just for Apple but for the server market as well.
For Apple, there are two clear advantages: power efficiency (which is the same thing as heat) and vertical integration. AWS can enjoy the same advantages from ARM. But these are both essentially hardware providers. AWS still offers x86-based EC2 instances and while they might encourage users to migrate to ARM (by perhaps passing on their own savings), there’s a lot of inertia there. Apple is a company that bites the bullet and forces these migrations, but how many developers will support or migrate to ARM just because that’s what’s running their MacBook?
1. Build docker containers for ARM.
2. Run Intel containers under qemu.
> Like it did then, the company plans to eventually transition the entire Mac lineup to its Arm-based processors, including the priciest desktop computers, the people said.
If the hardware is available but you can't run the usual software no one is going to buy that. this is what I meant.
The hardware might be announced but it might not come until a decent enough number of key apps are ported.
My understanding is when you develop for Mac, you already have to compile to bytecode which means it's already compatible with other architectures.
The only software platform that might be the case is Android.
Wake me up when they use less glue to hold their computers together...
Is it somehow more proprietary and locked-down than the Intel ones?
We really haven't seen such a large technological separation like this. At least back in the old days you could still run what you want.
macOS moving to the iOS route where you have to jailbreak your device to get any sort of usability out of it is not a space I want to participate in, and yet it seems that's how the entire Apple line is moving. They're almost the complete opposite compared to Microsoft these days.
I just heard some stories that you can't recover your data when your hardware fails (which is not that huge of a problem, who does not sync their files nowadays), and that some laptops get 'improperly' resold (not being deactivated), but thats it. I probably missed something.