ARM-Ed Mac: We Have an Answer
mondaynote.com
mondaynote.com
"ARM-Ed" sounds like a special ARM architecture, while ARM-ed and ARMed elicit the author's intended meaning to me. It's pretty clear as to why the author didn't capitalize "ed" in their own title.
It really annoys me when submitting; it does it only if there's a certain number of capitals in the submission, so 'ARM' probbaly triggered it. (It's now 'Arm' anyway, so it needn't have.) It does accept a more sensible case on re-submission if the submitter edits it quickly enough.
I don't agree with that position; I think the form factor of the Mac and the capabilities of MacOS are going to continue to be relevant, even in a world where a fully featured Xcode can be run from an iPad Pro.
It seems more realistic to me that apples' efforts to get catalyst to a point of usability is about enabling software to make a seamless transition to the arm architecture.
I actually suspect the move to/inclusion of ARM in the macOS lines of product is part of the motivation behind dumping support for 32-bit apps in Catalina. By preemtively removing support for a large amount of legacy software, which will likely never be recompiled for ARM, they avoid the situation where their new machines appear much less capable than the old ones.
There was a push to make all laptops have a touchscreen a few years back, but this seems to have fizzled out, and I've seldom seen anyone use them (deliberately anyway).
This whole "ask apple's permission" thing really annoys me.
(A) It doesn't contact Apple for permission; it's asking you, the user, for permission to access certain aspects to prevent malicious apps from encroaching on user privacy and security — in no part of the transaction is it phoning home.
Locking applications out of unfettered access to the system is nothing new nor particularly Apple-specific.
Please do not spread unnecessary FUD.
> This whole "ask apple's permission" thing really annoys me
(B) I will direct you to point A.
When you install little snitch, you have to go to the security and privacy pane, which should have a dialog to allow obdev.at to install a kernel extension.
However, if you're not connected to the internet, that dialog doesn't seem to show up.
The iPad tablet form factor will eventually hit limits in screen size. Is a 15”, 24” or even 27” tablet really feasible? If eventually the iPad becomes highly usable in docked mode with a keyboard, why not bring it out in a full clamshell or even desktop form factor?
Looking at it this way ok, maybe the Mac will move to ARM, or maybe it won’t. The thing is in the long run it might not matter.
The people that required desktop like compute power either got a laptop workstation like Thinkpad W series (now P), or some server connected via RDP.
Apple just needs to have a docking station on their offerings.
It's still very common for companies to supply desktops to lower paid desk workers that don't work from home. The total cost is lower, fewer failures, etc.
But they do, it's called Thunderbolt, and they were the first manufacturer to really buy in hard.
For any laptop that can run within the 100 watt limit of USB-C charging there's little to nothing a proprietary docking solution offers compared to TB3, and even those that require more power can still use a TB dock just with one additional cable to plug in.
Yes there are a lot of crappy Thunderbolt and/or USB-C docks out there, but it's not like proprietary docks were ever bug-free either. At least now you have a choice of dozens of vendors rather than being stuck with whatever the laptop OEM wants to offer, and changing model lines doesn't mean buying a whole new set of docks.
> An answer to the now age-old ARM-ed Mac question now emerges: With the emphasis on the iPad Pro as a real computer, there’s no reason for Apple to move the Mac off of trusty if perhaps less glamorous Intel processors. Does this mean that iPad Pro sales will cannibalize the Mac? We’ve long known the answer that one. It doesn’t really matter to the company as long as customers enjoy their Apple devices.
I don’t think Gassée is arguing that the iPad definitively will replace the Mac, or that this is Apple's intention. I think he’s arguing that Apple is positioning the iPad in a way that it could, and that this positioning lets the Mac off the hook for an architecture transition.
But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing.
So in the meantime, it makes sense to push the iPad toward being a stronger and stronger computing platform with things like the recently added trackpad, better multi tasking, etc. They’ve got a way to go, but given a few more years of iteration, who knows how many more of the “real computer” niches the iPad can fill.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition, and Apple will probably shift it farther upmarket as the iPad cannibalizes every use case that doesn’t need x86. And if the processors do get that much better, then ARM comes to the Mac.
Either way, Apple is in a good place to leverage the iPad as their vision of what the next generation of the personal computer looks like.
Apple has already done this. The 68K to PPC transition wasn't nearly as quick as the PPC to x86 transition. They released new 68K Macs after releasing PPC Macs. The apps were "fat binary".
When I bought my first PPC Mac, all of my apps were on an external SCSI drive. I attached the drive to PPC Mac and it ran native software.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition,
Again it doesn't have to. I had a first generation PPC Mac 6100/60 that ran emulated code slightly slower than my accelerated 68030-40Mhz LCII. My 68K Mac was about half the speed of the high end 68040-40Mhz Macs. It couldn't emulate programs that used the 68040's FPU at all. There were third party hacks that you could run like SoftwareFPU (a 68K program nonetheless) that could emulate an FPU.
The high end programs are always the first to be ported. The other apps are "good enough" and depending on how much time an emulated app spends running native operating system code, it won't be all emulated.
It took me forever to realize where the name came from.
“Close but no cigar”.
You mean a third time though! The mac went through three architecture transition, and each came with an emulator to keep compatibility for a while. The first one was when they went from Motorolla 68000 to PPC, and they built the Mac 68k Emulator[0] to keep software going.
I also think they could pull it off again. Microsoft has shown us that it's possible to run a lot of x86 software on ARM64 with little noticeable impact[1]. It would, however, require immense engineering effort.
[0]: https://en.wikipedia.org/wiki/Mac_68k_emulator
[1]: https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
Emulating x86 on ARM is very hard because x86 has a strong memory model while ARM has a weak one. This either makes emulation very slow or will break lots of multithreaded applications.
The other emulation direction (ARM on x86) works much better.
If emulation were taken seriously, Apple could add extra features to their ARM-ISA processors in support of x86 emulation, including x86 compatible implicit memory barriers.
In fact, out of Intel and ARM, ARM is the only one I know that tried to shut down software emulation...
(ARM blocked parts of QEMU from being published for a while, citing "you must have read the manual to implement this therefore you are bound by the terms of the manual". They also had an open source design removed from OpenCores.)
It would not be completely silly to modify QEMU with x86 guest and modified-ARM target (for implicit-barrier mode), and then just use QEMU for the emulation.
As long as implicit-barrier mode was generic enough I think Intel would have an interesting time claiming it infringed some patent of theirs. Making it efficient would remain Apple's problem but they are good at that. (Or were until the CPU designers left to start Nuvia.)
If Intel won that, implicit-barrier would have to be explicit-barrier which is just normal ARM, but there is no fundamental reason why that cannot be fast, if the processor is designed to expect a lot of barriers and optimised accordingly. Especially if a dense instruction encoding is created for it.
(Everything I just said applies to RISC-V as well as ARM, should Apple decide to change course again.)
https://www.forbes.com/sites/tiriasresearch/2017/06/16/intel...
Thanks for clearing that up. Wonder what the difference is that this article mentions.
But most apps are not very parallelized, only computationally heavy ones are. Those are of course going to suffer from emulation anyway. As a performance lower bound we can imagine that it would emulate a single-core x86 so the memory model differences wouldn't come into play.
Microsoft already has x86 emulation working in Windows for ARM, anyone know implementation details of that, or even publications?
It seems to depend on a feature that is specific for Qualcomm processors: https://news.ycombinator.com/item?id=14318877
I know that to be true, but could you point me to some articles and documentation that tell more. I'd like to learn more.
Of course, as always, whether this is "an answer" or not depends on whether you happen to believe in this particular branch of Apple Kremlinology.
I love this term. What a fantastic way to look at this story and take a step back so that we recognize what we're doing here. Maybe Apple, like the Soviet Union, doesn't have it all figured out? Maybe they're just trying stuff to see what sticks?
I think, deep down, there are a bunch of people at Apple that know they'd have to pry the Terminal, vim/emacs, and command line tools out of macOS developers' cold, dead hands before they'd ever switch to iOS full-time.
[1] https://www.itworld.com/article/2782495/apple-kremlinology.h...
* I'm sure Microsoft's Windows developers all work on Windows.
* I assume Apple uses Macs for all development right now.
* If memory serves, Google uses a lot of Macs themselves, but did at least make an effort to make it possible to do development on Chromebooks.
* Oracle... it's not clear to me that Oracle actually has anybody working on Solaris, but if they do then they have to use Solaris to work on Solaris unless they've managed to completely overhaul the build system. For everything else, OEL should at least theoretically be completely adequate.
* I'd be interested to know what IBM uses internally; AIX was a workstation OS but I have no idea if they've maintained that capability, and they own RH now so that's an option if they wanted to stay "in-house"
* I don't have any specific knowledge about it, but Red Hat absolutely could use Fedora and/or RHEL for most everything.
* Canonical is almost certainly running Ubuntu everywhere.
I wish I had a super-like for this answer.
edit: "but iSH is Linux, surely Apple would do Darwin!" you say. By looking at how poorly they're maintaining the command line experience on the Mac (deprecating their bundled Python, Ruby, not updating anything GNU GPLv3 etc), it's easy to imagine them happy to outsource that drudgery to the Linux community, like Microsoft is with WSL. Add to that all the web developers telling them they want a deploy-ready environment...
Hire the guy and do it natively in house.
$ brew list | wc -w
244
And as someone on the inside, who knows the answer to this story (nope, not telling) it's interesting to read the conjecture :)
Those toy environments on Amiga, Mac OS, Windows, Symbian, J2ME, Android.
What are you talking about? You've got basically a complete unix shell available there.
It's very limiting not to have a shell, and arbitrary execution environment, and the wealth of tools which have been created over the years for the *nix environment.
The shell is a subset of what an IDE REPL is capable of, with OS API integration and structured data manipulation.
As for background processes, that is a basic feature of any modern IDE.
Apple has made it quite clear that neither of those is ever going to happen on IOS.
Now that it isn't happening, lets see how it goes.
It won't split the Mac lineup into ARM and x86, it will split it into iPad and Mac.
Describe pre-pointer iPads as Model T fords, and now we're entering the 1950's…
Unless an iPad can compile code at speeds equivalent of C / C++ I cannot see it happening. I could see some programming on the new iPad though. Would be nice if Apple opened it up for trivial scripting though.
Have you used Swift Playgrounds?
Besides that, why do you think that the current ARM chips aren't already faster than most x86 chips that people use?
Would be nice if Apple opened it up for trivial scripting though.
You can already do that using Shortcuts and various third party apps..
During the Mac Pro redesign, Apple said developers are by far their largest group of "pro" users. Then they built a $6000+ workstation (with a $6000+ display) that appears to be primarily aimed at video editors. I don't see why adding some real programmability to iOS would be too niche.
I think the more likely answer is that Apple is suffering from tunnel vision in their conception of what "software development" means.
It looks like a great machine for developing software (if you can afford it) but all of its strengths as a development machine look like simply side effects of video editing machines needing lots of power. There is no design or feature on it that I can point to and say "this was done for developers". There are many that were obviously done for video -- like a $2000 FPGA option that's only good for 2 intermediate video codecs.
†Not that they'll actually ever say "I'm sorry" out loud, but it's pretty clear they're rolling back some of the late stage Ive-isms. Yes, I know they kept the Touch Bar and didn't add ports, but I think they're all fully committed to USB-C as the Way Of The Future™ and, uh, somebody high up loves that damn Touch Bar.
Without a reasonably performant platform to develop on the iPad will kill itself.
But where iPadOS lacks significantly behind MacOS is the software. And this is based on the AppStore rules. Applications are limited in their capabilities which would be natural on a "computer". With "Files", applications can finally exchange data, but that still has complexities for the user and is less natural than it works on the Mac.
The biggest elephant in the room is the missing ability to do any real software development on the iPad. One might say that the software developers are the minority of the users and that is correct, but the software developers are the critical group for a platform which creates the software which all the other users can use. While the AppStore on the Mac has grown over time, just look how large the software universe outside the AppStore is, to get an idea, how important this is for the Mac platform. Not even counting the number of users, which wouldn't qualify as software developers, but are running a few scripts here and there for special task, either written by themselves or grabbed from the internet and modified to their needs. And yes, sometimes you really need a shell.
It will be interesting to watch what gets shown for iPadOS 14. If the iPad should go further into the Mac space, some significant changes need to be announced. The trackpad addition goes in the right direction, but does not address the points I mentioned above.
What did Apple gain from switching from PPC to Intel in the first place? They gained faster processors (their market share was insufficient to keep performance parity) and the ability to virtualize or even dual-boot Windows on Mac hardware. I don’t see these factors changing; iPhones and iPads don’t have the performance properties of laptops and desktops, meaning even Apple’s internally-developed ARM architecture is going to treat Macs as as much of an afterthought as Motorola and IBM did back in the day. Meanwhile, even if Windows compatibility is less relevant, the ability to virtualize Linux distros on Macs has become more relevant.
If I’m a software developer and I want to run my code on a x86-based Linux server somewhere, I’ll often want my development environment to be capable of reproducing that same environment, and tools like Vagrant and Docker accomplish this on Macs using virtualization. Without a shared CPU architecture, these tools will either stop working entirely or rely upon emulation, which would hinder performance and potentially introduce inconsistent behavior compared to the real hardware. Now, it’s true that iOS development relies on the Mac performing ARM emulation. But there’s already a working solution for this, and you can still use actual iOS hardware for testing. If I had to connect my Mac to an x86-based Linux box for testing and development, why wouldn’t I just use the Linux box? And the Linux box is a server that I can either Remote Desktop or SSH into, why would I need a Mac to be able to do that? Maybe I’m biased because I already think Macs aren’t a very good development environment, but I don’t really see switching CPU architectures as a move that makes them any better. All bets are off if ARM servers actually take off, though.
[1] https://www.phoronix.com/scan.php?page=article&item=ampere-a...
But the more you live in the terminal, the more of a mess it becomes compared to Linux. All the built in utilities are either very old or feature-impoverished BSD variants. Making it usable at all requires Homebrew, which manages to get broken by every major OS update. The default file system is case insensitive, which probably improves usability for mundanes but can result in some utterly broken Git workflows. And the more effort you invest into automating your workflow, the more time and effort you have to expend on the relatively useless and non-transferrable skill of macOS system administration. So I switched to Linux. Tiling window managers are nice, too.
To me it seems like another case of big-company-itis. Someone on the processor design team wants a promotion. Someone on the Macbook Air team wants a promotion. Working together is not the easiest path to that promotion, so the products remain separate. That is the reality of big companies and why startups get so much done. Nobody on the MacOS team is going to say "we should delete this thing and start working on XCode for the iPad instead", and so... as end-users we wonder wtf they're up to.
Obviously engineers play a role in evaluating the practicality of running it on an iPad, but that's such an incredibly strategic decision for Apple it's hard to imagine it's purely a question of Mac engineers not feeling like doing it.
OTOH, another case of big-company-itis is over-segmenting your products and not allowing them to grow organically our of fear of cannibalizing your higher profit margin products.
Apple never letting the iPad get full keyboard and cursor support and saying "that's a Mac thing" leaves them open for disruption from Microsoft instead.
Xcode is likely planned for iPad, but it's a massive ecosystem (not just one app, don't forget there's Instruments, the Simulator, compiler build step scripts, etc etc) and will take a LONG time to port
Full keyboard and mouse support is in iOS 13.4.
The Surface is just another Windows computer with all the baggage that entails - x86 processors with horrible battery efficiency, an operating system that requires more RAM and storage, an operating system that still has parts that aren’t touch friendly and plenty of apps that still have a UI that doesn’t work well with touch.
Sorry, that was the point I was trying to make. Apple isn't afraid to cannibalize their own product lines by improving their "lesser" product. Rather than being a sign of "big-company-itis", it's a sign of being agile.
> The Surface is just another Windows computer with all the baggage that entails
Microsoft has a history of evolving their products until they are a success, I wouldn't count anything out on it's current iteration.
There's not just the Surface either, the Chromebook could have a future as software moves more and more onto the web and people don't really leave their browsers.
The entire idea of the Surface is fundamentally flawed because of three factors - it’s dependence on backwards compatibility with Windows and using x86 processors.
The Chromebook is already a success in education, but it has the opposite problem than the Surface. Google has no clue in how to create an ecosystem. Android on tablets have been a non starter and Chromebooks are still nowhere as capable as iPads.
Android succeeded because Apple refuses to compete on price and everyone needs an phone. A tablet is a luxury product and Apple competes pretty well on price. The $329 iPad is a very good device with a better ecosystem.
Seems like a lot of work would need to go into moving existing macOS apps to touch friendly interfaces if that were the case. I’m using a Bluetooth mouse and the cursor is finger sized.
Microsoft currently has 32-bit-only x86 emulation on the ARM-powered Surface X and the reviews aren't positive. I don't know if it's actual emulation, trap/HLE emulation, dynamic translation, or something else - but Microsoft takes backwards compatibility far more seriously than Apple does, and if that's the best Microsoft can do, what hope does Apple have?
While x86 and ARM's ISAs are fundamentally different (y'know: CISC vs RISC) but given that x86 CPUs today are generally implemented using RISC microcode - could x86 be emulated by instead translating x86's RISC microcode to ARM?
I realize another alternative exists: Apple could buy-up cheap, low-power Intel x86/x64 chips (like an i3 or something) as a co-processor to the primary ARM chip and only use the i3 if ARM-based emulation is too slow for a given process?
Phones are another matter, of course.
I'm temporarily between computers and using my iPad as my main computer. I also thought it would be a fun experiment so that I could learn the pros and cons of using an iPad as my main computing device first hand.
The new(-ish) mouse support is wonderful. Absolutely wonderful. I have a keyboard with a built-in trackpad, and when I'm using my iPad at a desk, it's far superior to constantly reaching up and pawing at the screen. Apple took a huge step forward here.
But there are still some pretty serious issues. The iPad is really aggressive about killing apps, to the point that I'd switch back and forth between apps (using Cmd+Tab on the keyboard) and it would frequently restart the apps from scratch. Even when switching between just two apps. And a lot of apps don't fully restore where you were at when the app was killed.
This issue alone is bad enough that, long-term, there's no way I could use my iPad as a laptop replacement.
The other issue is that I'm a software developer, and the software development story on the iPad (not for the iPad) is quite sad. There's absolutely no support for the two languages I use most frequently (Java and C). I can't even develop a simple web page (HTML/CSS/JS) on the iPad itself. There's no way to save and view local web pages.
Based on Apple's history, I think they'll be stubborn and thus really, really slow to add the features I want (though I think they'll add them eventually).
I am personally a Linux/Thinkpad person, but all the persons I am working with who happen to have a Surface just love it.
Well executed, the concept is beautiful and practical. Apple is coming from the tablet side and Microsoft from the laptop side, they will converge at some point.
ARM is an implementation detail.
As for having a single appleOS, we're talking about the company that owns (1) watchOS, (2) iOS, (3) iPadOS, (4) macOS, and (5) tvOS - I believe that's more than Microsoft and Google combined.
[0] They're slowly making everything more touchpad-centred and graphics-oriented, for example.
There's not much to port. The underlying Darwin operating system is shared by all Apple products (AFAIK, excepting Airports for some weird reason). They would have to do a recompile and maybe make sure that nobody accidentally put architecture specific bugs into the finder or something stupid, but the grand difference between Apple's different operating systems is which graphical interface they put on and some amount of user space tooling. And honestly, I would be absolutely shocked if Apple doesn't have internal builds of the desktop-oriented "Mac OS" for ARM, probably as part of the usual CI pipeline.
Non-touch iPods as well.
QEMU can run Intel MacOSX code and they can use it to emulate the old Intel Macs. This version of QEMU was designed to run older OSX Intel versions under new Intel versions to run legacy software.
CommodoreOS is based on Linux and in order to run old Amiga apps they use UAE for 68K and PowerPC Amigas. This seems to be that virtual machines and emulation can run the legacy software needed on the new ARM Macs.
The Air and mini just got an update that brings the T2. I’m not sure if they are still shipping any non-T2 Macs, I don’t think they are.
But I don't see what's in for the users and software developers? Transition to another architecture might mean more money spent for end-users and more money and time spent for software developers.
Why is everybody so excited?
As for more money and time… I dunno, I make my living writing mostly iOS and Mac software and I can't recall the last time I did anything that was architecture specific. I'd imagine that applies to the vast majority of people working on ordinary application software on these platforms.
As for the cpu side.. Apple switched before. Also, the tooling is way more up to date and code is more high level these days than before.
Intel as a company isn’t performing, so it’s been AMD and their own CPUs.. they pulled it off before, and I think it will depend on tooling, and app compatibility/performance when emulating. Although I’m not sure if that would require a license