I mean the post is technically right. You're probably better of skipping the first generation of ARM Macs until software support happens unless you're someone who wants to work on that software support.
I think you missed the point. What about all the dependencies of your code that are only compiled for x86_64? The article isn't talking about native apps on the laptop, it's about apps that run on a server but that you are developing locally.
You can't run your x86 docker image on your ARM mac without emulation. You can't run your x86 Windows VM without emulation etc.
Of course there are solutions like using a remote server or a VM in the cloud, but if you're buying a decent machine then you would normally expect to be able to run these things locally.
Do you have any examples of this? The last time I tried an AWS ARM server, it was literally no modification other than changing the server type — Linux has run on ARM for many years and Apple is far from the first company to use the platform.
For example, back in 2017 Cloudflare was basically looking at this as a question of which hardware ran most cost-effectively rather than having engineering heroics first:
https://blog.cloudflare.com/arm-takes-wing/
I want to say Oracle database clients as an example.
My company definitely had problems to get database drivers to work generally speaking and on both 32 bits and 64 bits. Have a look at postgres, oracle, cassandra, redis, sybase to name a few, I am not sure which one was worse, it wasn't me doing the work. But I've seen some of the C and C++ dependencies that needed to compile with the errors that happened and that was horrendous.
The problem wasn't in our code, it was in the database code that was either from open source or from a vendor.
If you want a sample. Try to install the cassandra client library in python. It will pull in and compile all sort of shit. That's supposed to be python and easily cross platform.
Reading the comments here flow something like this: 1. complain that switching to ARM is a mess 2. no it's not a mess, it's easy 3. no, see it's a mess 4. fine, clean up the mess.
Yes, we should clean up the mess! It doesn't mean it's not a mess. And I think the mess is actually still understated.
I've been using postgres, cassandra, redis and mysql/mariadb on aarch64. Only ran into issues with MySQL, which we rootcaused to some weird atomic locks not working as expected on the first generation of ARMv8(.0) a couple years back.
Mono and .NET Core run terribly on ARM. I have several containerized C# apps that I need to run on x86_64 hosts, because on ARM they'll just crash randomly.
AWS has put out some very impressive ARM instances running on the Graviton2 processors. The reviews I read show better performance per dollar. So maybe the solution is to further embrace ARM and run your code on ARM servers?
This will always be a problem, unless one emulates the x86_64 architecture, which is then again the other problem w/ Docker.
I assume main libraries (i.e. dependencies) are already or will be ported, so theoretically recompilation should work for many, although not the most applications. Other applications will need to either change dependencies, or port dependencies to enable full performance.
It's not about stealing users from macOS. It's about stealing developers. Hell, Apple is at the mercy of Microsoft and Adobe right now. I'd bet they had to line their pockets very well, so that they don't get any funny ideas.
But Apple can't just pay-up every cross-platform software developer. Smaller developers will have to re-evaluate whether macOS remains a viable target platform for them. Which can translate to a dev-gain for Linux. The catch is that Linux is in much better position to translate an influx of developers to an influx of new users: Linux runs on what you have, while macOS requires you buy Apple hardware.
And let's not forget about macOS as a gaming platform. Linux has made a huge leap forward with Steam Proton. On macOS there's still a ton of games not supporting x86_64 (Catalina), and situation won't get better by transition to ARM.
Hell, Apple is at the mercy of Microsoft and Adobe right now. I'd bet they had to line their pockets very well, so that they don't get any funny ideas.
I’m sure that's not the case. It's much more in Adobe’s interest to be ARM-ready on day 1; there are plenty of Photoshop alternatives in the Mac App Store—notice they demoed Affinity Photo running on the ARM Mac and Affinity is much better at using Apple's native APIs and technologies than Adobe every was. And it's just a one-time cost of $49.99 vs. renting Photoshop from Adobe. Users of Apple devices are continue to be a large segment of their customer base.
Adobe has already migrated all of their core applications to a new codebase that should be relatively easy to bring to ARM Macs. Photoshop and several other of their apps already runs on iPadOS, so it won't be that big a deal to move it over to Big Sur.
macOS users actually pay those smaller developers, it would be foolish for them to expect anything from Linux users, it is hard but it is the reality.
Hence why plenty just target Android, although some of their apps could easily be targeting GNU/Linux as well (specially the ones that are mostly NDK glue + whatever framework).
Every time Microsoft or Apple majorly screws something up, people say this. It still hasn't happened yet.
However, I think Apple has been a far greater threat to Linux adoption than Microsoft. Why? Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux.
There is real value in proprietary commercial end-user application software. Most companies who make such software couldn't care less about supporting Linux. So if you want to use Linux, you have to use F/OSS alternatives and continue to try convincing everyone that somehow they're better than the commercial options... even when the rest of the world has agreed that they're really not.
The whole incentive structure around F/OSS development really doesn't work for software where the profit motive is in the product itself... Not some nebulous "support contract" that you don't actually need. (Which is a far bigger issue for end-user applications.)
> Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux.
The UNIX experience on the Mac is pretty shitty. Ancient versions of all the tooling. Command-line utils have that weird BSD well-water flavor. No package management. Funny Docker quirks.
The hardware used to be pretty nice, but honestly I'm still having trouble forgiving them for getting rid of the physical ESC key and turning volume control into a two-step routine on the TouchBar.
Honestly if I'm doing server-side development, I much prefer using my ThinkPad (Ubuntu) over my MacBook. About the only thing I miss is the far superior touchpad on the Macbook. That's it.
I was with you until they released the newest MBP. Now my beloved ESC is back. I already do all my development in a Vagrant instance so I've never been bothered by the tooling. In all other regards I prefer MacOS as a desktop environment to the currently available Linux choices.
>> Because it gives techies the nix environment they want, with the software and hardware support no one will give them on Linux.
> The UNIX experience on the Mac is pretty shitty. Ancient versions of all the tooling. Command-line utils have that weird BSD well-water flavor. No package management. Funny Docker quirks.
It doesn't have to be the best nix environment. Hell, it doesn't even have to be a good one. It just has to be "good-enough". For this, they still have an advantage over Windows. And compared with Linux, they still have the advantage that by-and-large, things "just work". I have never personally been able to say that about a Linux desktop I've had. There is always one more thing to tweak, one more knob to turn, etc...
I'm with you on the ESC key and touch bar though... which they thankfully fixed the missing ESC key.
Everything WSL2 does has already been do-able with Windows for at least 10 years. It’s a VM with some file system sharing. You might as well just ask what advantage does MacOS have over Windows. WSL hasn’t changed anything really.
Last week I had to drop to vi and edit nfs.conf on a friend's Mac to solve very slow transfer rates. "Just works" within a very narrow definition of primitive use cases.
Touch and drag is easy to jump the volume up/down variable amounts but really sucks compared to a single key press for "just a little louder" or "just a little quieter." There is something satisfying in the discrete steps of volume notches.
On the other hand, my speakers have a physical volume dial that provides feedback via friction on movement so I like that better than touchbar or physical up/down buttons.
So there’s actually two types of touch and drag you can do. One is holding until the slider appears and then dragging, the other is flicking the icons left and right which causes single step increments.
Discoverability certainly sucks for that second one.
> The UNIX experience on the Mac is pretty shitty. Ancient versions of all the tooling. Command-line utils have that weird BSD well-water flavor. No package management. Funny Docker quirks.
Very, very true. And Homebrew is actively becoming worse now. A few years back, Homebrew was great - now using it feels like using some weird underground software stack that exists only because Apple hasn't come around to nixing it yet.
> However, I think Apple has been a far greater threat to Linux adoption than Microsoft. Why? Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux.
With WSL, you basically get an actual Linux userland (with WSL2, I think you get an actual Linux kernel too), not just a Unix that's like Linux but different enough to be annoying. But I'm not sure that will be enough to convince people to move to Windows.
What for? That is what having something like Hummingbird took care of.
I used to admin UNIX and develop for it from Windows NT/2000 workstations.
Also the FOSS version of Motif only appeared when Motif wasn't that much relevant and most enterprise shops were migrating to CORBA and Web as integration points.
Indeed, and WSL instead of a pure POSIX, because that allows to tap into the ecosystem that thinks Linux === UNIX, without having to recompile anything.
An approach already taken by other UNIX clones with their Linux compatibility syscalls layer.
To give a different perspective: I find Apple's move to ARM the most exciting thing to happen in desktop computers in many years. I'm typing this from a PC running Win10. Current plan is: as soon as ARM desktop Macs become available (and assuming they don't screw it up in some weird way), I'd like to switch.
So, and I say this as someone who's stoked to see any non-x86 system going mainstream... why do you want to switch? What benefit do you see to switching to an ARM laptop? Or is it just "this is a good thing (in general) so I want to get on board with it"?
I'm also excited about a non-x86 architecture on the desktop again. Monoculture is bad, and I find x86 to be especially ugly...
As for switching... I'm increasingly unhappy with Microsoft's complete disregard of user privacy. Apple isn't perfect with that either, but IMO much better at least. For my use cases, Win and Mac are the only credible options due to software availability. So to get away from Windows.. there's not much choice these days.
Why do you feel like proprietary software monocultures are better than commoditized hardware monocultures? OS vendors selling 100% custom silicon is not the path to diversity and freedom of choice.
If it's ARM that excites you, Surface Pro X (Windows) and Pinebook (Linux) exist today. If it's macOS, you could switch now. What about the combo of macOS + ARM do you find compelling?
Because of the network effects of software development. The number of people that use those devices you list is basically a rounding error, so they're ignored by most software development.
Apple has a monopoly on their hardware, and they will likely sell a significant number of devices. This will lead to a lot more development for ARM that never would have happened otherwise.
That, in turn, may make tilt the balance in favor of ARM for a lot of other use cases outside of OSX when other tools, applications, and hardware vendors better support ARM.
Having an x86 dev machine is useful because it matches most production environments pretty closely. This might be changing somewhat with AWS Graviton, it's not the default yet.
What makes ARM so exciting? Maybe battery use will be better? Maybe it will be slightly faster? Maybe? There's also been a lot of tuning done for laptop workloads on x86, it's definitely a maybe. I expect the only noticeable changes for most users to be somewhat better battery life, some apps not working, and occasionally having to know which package to download.
It didn’t take months, the time I did it (running Docker on a Pinebook, which was not a great experience). It took a couple of hours to flip some base images away from Alpine, as Debian already has a load of ARM packages built.
This assumes that your Docker workload can run on an ARM system without lots of hacking, and also that you trust the ARM-compiled version you're running locally to function identically to the x86-compiled version running on your server.
No, it doesn't. If I'd made the statement "all you need to do is…" then it would have involved some assumptions. What I said was "I did this and all it took was…" no assumptions, just experience.
> It took a couple of hours to flip some base images away from Alpine, as Debian already has a load of ARM packages built.
Why did you have to switch from Alpine to Debian? Alpine supports ARM quite happily, and it looks like they're shipping Docker images for ARM (and other architectures, too).
Not op, but alpine package manager leaves a lot to be desired especially compared to ubuntu. Also much easier to set locale. Since minimal ubuntu & debian exist, I think the question should be: "Why would you use alpine?" especially considering potentially slower performance:
> Not op, but alpine package manager leaves a lot to be desired especially compared to ubuntu.
How so? If anything, apk is way nicer than apt in a container build script (or anything automated); with apt you have to use -y and maybe force the noninteractive frontend, where `apk add foo` just works, correctly, automatically, with no effort required.
> Also much easier to set locale.
> considering potentially slower performance:
It's slower at installing python packages from pypi since it can't use cached versions. That's not the same thing as "it's slow".
> Since minimal ubuntu & debian exist, I think the question should be: "Why would you use alpine?"
Because minimal ubuntu is still ~3 times the size of alpine, alpine is much smaller and simpler, alpine defaults to staying small (even if you remember to --no-install-recommends, deb packages are bigger and less modular), and I don't have to remember how to force apt to run in "no really install without asking questions" mode.
Having built several Alpine and Debian-based images, Alpine has always been very nice for the happy path, but much more hassle to get out of a hole when something broke due to software misbehaving due non-Alpine assumptions.
Debian in Docker in comparison offer less surprises, but you have to consistently do the right incantations.
Regarding missing binary wheels on ARM: with more ARM laptops in the wild those would eventually become more common.
Didn't think of that. If running Docker is 10 times slower on ARM and virtual box doesn't support the architecture at all, this might indeed end developers using Mac.
Running Docker on an emulated x86 will be slow, but I doubt it'd be 10x slower. There are snapdragon laptops running Windows. How much slower is running Docker on them?
I've been developing on a Mac for years, and I've never needed to use Docker or virtualisation to do it. (I've been doing game development, and now web front end development. I'm sure the major game engines and browsers will be ported to run on ARM chips (although it may take a while)).
Honest question: What sort of development regularly requires using docker or virtualized OSes?
Almost every server applications (databases, webservers, webapps) are available as docker images. It's very easy to deploy those apps using docker, which is why it's taking over sysadmin world by storm. Previously, handling a big web application deployment is a complex task that requires a dedicated team. Now, you can just package your app as a docker image, and other people that know docker will know how to deploy your app without having to know its internal dependency graph first.
It's not quite as simple as GP implies, but why not? I work at a place running Docker in prod, and our only issues are with the swarm networking, not Docker itself.
Certainly not for production, but when you can't run x86-64 images, just simple prototyping or building images that requires x86-64 will require using external servers instead of using locally installed docker, which will be a huge barrier for casual prototyping.
Web development doesn't "require" it per se, but it's easier to keep track of the mess of ad-hoc dependencies with Docker. Really, I think the solution is keeping better track of your dependencies and avoiding ad-hoc system configuration, but...
Honest answer: almost not much. Except, virtualization is a big trend, since it's a hugely convenient way to package a complex thing into a black box and run it with minimal attack surface.
If you sit back for a second, you can see that things like systemd provide nearly everything you'd want from a container, that, like, who cares is the approach you could have, for the top ten languages.
If you are running a massive stack then maybe you do need Docker and VirtualBox but at this point, shouldn't you be using a staging server anyway?
1) I wanted to provide a Jupyter notebook with IBM DB2 support for a university course. (Why DB2? Because its optimizer can transparently use materialized views for query optimization which PostgreSQL can't AFAIK.) IBM provides a Jupyter magic which requires the Python package ibm_db. ibm_db requires a DYLD_LIBRARY_PATH hack which macOS doesn't support unless you disable System Integrity Protection. I don't want to disable SIP on my system and I can't ask our students to do that. A Docker image provides a convenient solution to the problem.
2) I do a lot of disparate project development using Flink and Hadoop. These get deployed on Linux machines. My preferred way to develop on my Macbook is to boot up a headless Ubuntu system inside VirtualBox, SSH into it, and then start a TMUX session. This has a number of advantages. a) The dev environment more closely resembles the production environment. b) I can setup my TMUX session, save the state of the VM, and then restore it months later to the exact state just by booting up the VM. c) I don't have to pollute my macOS environment with dev tools that I rarely use. It's not strictly necessary but it's actually quite convenient. I can even do development in IntelliJ on macOS, run the services inside the VM, and thanks to remote JVM debugging use the IntelliJ debugger on macOS to step through the code running inside the JVM.
It will be extremely interesting to see what the dev's say with the test boxes. Curious if there's any magical fixes like switching over to ARM Linux, since the software of an image would likely be compiled for x86 I really doubt it...
Perhaps this will spur some people over to running ARM servers in the cloud...
Has anyone received an invite into the program yet? I applied on day one, but don’t have a Mac Store app currently published, so I’m not sure if I will get accepted.
> Why can't you update the Docker image to also support ARM? You theoretically could switch your backend to run ARM Linux. However, this would take months - renting out ARM instances, re-building all repositories, and a tense switch over.
I don't see why this would be so hard. If anything, I expect to see a massive upswing in things like AWS Graviton2 uptake, and a lot of common Docker images being built with ARM versions out of the box. It might be about a year or so, but eventually we'll be able to just go ARM-native the whole way.
What Apple needs to do is make a first-class, WSL-tier implementation of Docker for Mac for ARM.
The Honeycomb.io folks reported 40% more capacity per dollar on Graviton 2 over x86. That alone should motivate people to start looking into ARM backends.
I'm kinda thankful to Apple for biting the bullet on this one. For whatever reason people will move mountains for Apple where other companies' products would just languish and die. The second order effects of ARM being something that's "safe" for people to use should be great!
>>> expect ... a lot of common Docker images being built with ARM versions out of the box.
This has no chance of happening. The common cloud CI systems do not support ARM at all (travis, circle CI and co). There is only a minority of developers with macbook and the rest is not going to spend $2000 to buy one just to build some docker images.
It's ludicrous to assume that anybody has $2000 to spend on fantasy hardware. It's month of disposable income outside of the SV bubble.
Better question might be, how many of the most common open source projects are managed by volunteers in their spare time? These will not build for ARM, unless there is a free tool doing it automatically for them. Currently GitHub + travis/circle can do for x64 on every push to master.
You don't need a cluster of them, one $50 machine is enough for home use. Travis et. al. will be buying those 96-core Marvell ARM machines and plowing through builds.
I think they have both. They offer POWER and LinuxONE as options and those aren't available in your average cloud provider. They probably have a sweet deal with IBM Cloud.
I'd love to have a POWER and an IBM LinuxONE in my shed, but that's not going to happen.
I'd be very surprised if this didn't become more common given the high levels of interest people are showing towards ARM server offerings in the cloud space.
I don't think this is actually the big problem some people make it out to be. You can cross compile ARM binaries on x86. You can even run ARM binaries on x86 (with qemu.) Any CI system can easily call scripts to do this.
Do we know that Boot Camp isn’t supported by Big Sur? Or is it just that one can’t run an x86 OS on an ARM architecture? In other words - will I still be able to dual-boot into something like ARM-flavored Linux?
This is the limitation. There is an ARM version of Windows, but the comments from Microsoft don't sound terribly promising:
“Microsoft only licenses Windows 10 on ARM to OEMs. We have nothing further to share at this time.” [1]
And Apple has more firmly stated that this won't be an option:
“We’re not direct booting an alternate operating system,” says Craig Federighi, Apple’s senior vice president of software engineering. “Purely virtualization is the route. These hypervisors can be very efficient, so the need to direct boot shouldn’t really be the concern.” [1]
And the iPhone didn’t permit native third part apps when launched. Not because they weren’t ready to announce it yet but because at launch time they figured web apps would be enough.
I have no idea what plans they might have but I would be surprised if you couldn’t install some ARM Linux distros on their laptops sometime next year.
My 2017 Macbook pro still has quite a lot of life in it, but it seems unlikely I will replace it with another Mac in a few years. Before the Mac I had a Lenovo X1 Carbon running Linux and it was great; and even then was a better development environment in some ways (docker has better filesystem performance, pacman is much better than homebrew). I do use some audio processing applications and my kids play a few games that do not run at all on Linux. I may try WSL again instead of going straight back to Linux, but its hard to imagine Mac will be the best OS for me.
I recently had to get a new laptop and went with windows for the first time in a decade. Macs are still great to develop on for now, but looking at the trajectory apple has taken, the growing pains ARM will likely bring, and also the trajectory of Windows, it seemed like Windows would be the safer choice over the next few years.
But linux can be run on arm natively. Moreover, most packages are also compiled for arm. So apt-get install will work just the same. I'm sure they will be able to target Apple's specific arm chips when they come out.
Given how much Microsoft's React Native team bashes Electron with their performance bar charts (300x more bloat than RN), I look forward that, as soon as it is mature across Linux, macOS and Windows, they replace Electron with RN on VSCode.
It's also interesting that this won't fix old Electron applications. The idea of easy cross platform development via Electron is a myth because most developers won't support your platform even if all support requires is checking a box. When you consider that this is the primary justification for using Electron over other stacks it just makes your blood boil. All the downsides with none of the benefits.
I feel like the ARM transition is why MacOS hasn't progressed much (IMHO) in the past 2 or 3 years. It was a common assumption around here that they were diverting all their top resources to iOS/iPadOS development.
The reality seems to be that their top MacOS developers have been busy laying groundwork for the ARM transition. There's so much to be done.
A free market wouldn't have saved you because the market has every incentive to gravitate to a single architecture because vendors and customers want the best software compatibility. The more popular an architecture (or really any platform) gets the more software that's written for it until it starves out competitors because they can't run the software their customers want.
> Mac book was never really a dev platform. Maybe for front or nodejs, or definitly for native apple apps, but seriously, brew and so are so subpar.
I'm not sure what you're asking? It's lower level than the examples which were given.
There's nothing stopping you using a MacBook for almost any development task. It's not just for front-end tasks. You can do work that runs directly on the architecture.
I've been doing dev work on Macs since 2002. Perl, PHP, Java, C++. It's been a great environment. I don't expect most of my workflow to be impacted by the ARM transition, but given I've refreshed my Mac Mini and laptop both in the last 18 months, I don't expect to be changing architectures any time soon either.
It is very likely that ARM-based Macs will lack a performant hypervisor upon release. We will have to see how VMWare responds. I'd bet it will inspire new products and innovation and the desktop space will move towards a less x86-x64 centric world. In the end it is a short term problem. Someone will respond and provide a performant hypervisor that can run on an ARM host and virtualize x86-x64 and ARM guests.
It's true it will cause some pain in the first year or two, but even as a heavy VMWare Fusion user I am really looking forward to the benefits of a vertically integrated laptop.
No. Virtualization (dividing a host into different logical hosts but executing unmodified CPU instructions, like VMware, VirtualBox, ...) and emulation (translating instructions, like Rosetta) are two different beasts.
That's pretty much what I assumed from what I know of VMWare. It's going to be a big issue for future Macs, there are entire segments of developers who may have to abandon Macs if we can't run VMs of x86 operating systems.
Apple has Hypervisor.framework which has been updated for ARM Mac[1].
Xhyve and HyperKit (used by Docker for Mac) uses Hypervisor.framework exclusively. The last time I tried Hypervisor.framework on x86-64, the CPU performance was quite fine (matches that of VMware/VirtualBox), but I/O was pretty abysmal. Emulating x86-64 on ARM is probably going to be a role of something similar to QEMU.
> In Linux, Docker uses kernel features. It does not use any hypervisor.
> In Windows, Docker desktop uses Hyper-V.
> In Mac, Docker desktop uses Apple Hypervisor.framework.
If I understand correctly, hypervisors don't emulate hardware, that's what emulators (like QEMU) do. That would mean that physically the most performant option to run x86 code on an ARM CPU is dynamic translation (like QEMU-TCG or the new Rosetta JIT support).
Broadly speaking yes. Generally, hypervisors mediate access to shared hardware whereas emulators implement simulated hardware in software.
The very first hypervisors worked using dynamic binary translation. They would run a "guest" operating system by executing a stream of native instructions directly on the host CPU. This stream would be dynamically translated to remove and trap in software any privileged operations so the hypervisor could handle them. Modern hypervisors take advantage of hardware features that allow you to more efficiently trap on privileged operations. ARM started to add some of these features starting in 2013 [1]. In contrast Intel first started adding these features to the Pentium 4 in 2005 [2]. When such hardware features were released, they actually were not faster than the software translation. These days the hardware based options are faster. There is even hardware support for running nested hypervisors. So the first question we need to ask is how hypervisors implemented with ARMs hardware features stack up to Intel. I have no doubt that parity at a minimum will be reached I just don't know what the current state of play is. As indicated in my original comment, if I had to bet on release we wont quite have the performance or feature set you would be used to with a product like VMWare Fusion.
The second question we need to ask is whether there is a way to efficiently emulate x86-64 processors on ARM hosts. Even better if you can do this while taking advantage of the supporting infrastructure hypervisors already have in terms of the emulated devices and other features. QEMU just gets you the CPU and a short list of a devices. The fully experience of a seamlessly virtualized guest requires a lot more than that. But at the core you are right that it is going to require QEMU-TCG, Rosetta 2, or some similar technology because the silicon just is not there to execute x86-64.
With just less than 10% of market share, do you really think it will change the whole thing? Unless Microsoft pushes for ARM too, I don't see any changes soon
We'll have to see. As another person already pointed out, VMWare has experimented with ESXi on ARM and they claim their customers could realize significant cost savings by migrating to ARM [1]. So if they've already done a good amount of engineering work on it, we may well see VMWare Fusion on ARM that can efficiently run ARM guests. They plan on releasing a tech preview in July [2].
Whether you can stick an emulated x86-64 CPU in there is another matter. It's a much bigger engineering lift and unless Apple puts some resources into it it's not clear to me a virtualization company by themselves would want to incur the cost. I hope there is enough demand for it and that someone will provide it. For me personally the only reason I run VMWare Fusion is to access x86-only Windows applications for which there is no replacement.
Microsoft has been dabbling with ARM for a long time now.
It will all come down to whether this move gives Apple a significant performance and/or battery life advantage. If Apple pulls it off it will force Microsoft and other vendors to respond.
EDIT: I suppose I should clarify; I don't totally disagree. I personally run Ubuntu on my laptop and servers. But plenty of people are quite happy developing on Darwin and deploying to some sort of GNU/Linux.
I remember the days when having to switch between x86, ppc, sparc, etc was a thing (not to mention the many flavors of UN*X) and we survived. In fact I think it was more fun back before the x86/Linux server domination. Architecture diversity is good.
I'm not a heavy docker user but why can't I develop docker containers on Arm (as native containers, no emulation) and deploy to x86_64? Or vice versa? I understand that some packages are binary only and wouldn't be necessarily available for Arm, especially initially, but the majority should be.
You can. Because of the Raspberry Pi and other ARM SBCs, the most popular base images already run on ARM. The ones that are missing will catch up pretty fast.
It's not that you can't, you just have to be mindful. Because docker containers contain compiled applications, you have to be aware of what CPU architecture they're compiled for. ARM can't natively run x86 binaries, x86 can't natively run ARM binaries.
If you want to develop containers for x86 systems on an ARM system, you'll have to cross compile your containers, which I'm not sure if docker actually supports outside of emulation.
If you are only a consumer of containers, most of the popular ones have been compiled for multiple architectures.
If I were to describe my job, or programming in general, it might be "problems that have no obvious solution". This is a sad article that just seems to be the opposite in spirit to "Hacker" ethos.
A lot of developer-centric focus discussion on how Docker would work (hint: it does), but VirtualBox is still pretty common in the sysadmin world and other industry circles. Moreover, there seems to be no way it will ever work. It will be interesting to see how that turns out.
Author here. That's a major point of the article - "are we screwed?"
I'm not an expert on virtualization but I wanted to see some discussion on this topic, because it feels like we might be screwed and nobody is talking about.
Anyway I was happy to see Docker worked, at least on a basic level.
Cool. Thanks for writing it. It summarizes and collects a lot of issues we were all grumbling about here and there. The main hurdles for Docker are organization, not technical. However, the other issues you bring up are going to be more technical (same as you, though, not a hypervisor expert and/or we're going to be at the mercy of big vendors like Apple, Oracle, and Microsoft. Those are much harder problems to overcome.
I'm more convinced dropping dual boot and supporting virtualization is the right move.
Only the host OS is going to have the right drivers for the trackpad, wi-fi, GPU, power management, etc. etc. Through virtualization, the guest OS doesn't have to worry about constantly evolving hardware models.
Virtualized OS performance is already very good, and USB passthrough has existed for a while. Snapshots are a godsend.
What won't work are things like CUDA for eGPUs over Thunderbolt 3, and you'll have to share disk and RAM with the host OS.
But for most use cases it's probably the right choice. (This doesn't address the author's concern about moving away from x86.)
1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling.
2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case.
3. You won't be able to use most software because they don't release ARM binaries ... and the example uses `wget` && `tar xf`, with no binary signature check. As someone who has been porting stuff from x86_64 to aarch64 for a couple of years, I admit I've seen this pattern frequently. The most obvious solution is to build from sources, which would have been better off on x86_64 too, instead of fetching a prebuilt (and unverified) binary from the internet. Maybe there are some CPU flags the compiler could notice and apply optimizations which are not included in the prebuilt binary.
I'm not an Apple fan and I'm certainly not a fan of cross-architecture development either. I do agree with the general idea behind the article, however I find it a bit hand wavy.
Yes, agreed. And the examples exposed are not fair. There are a lot of optimizations one can do in Docker, specially when dealing with I/O workloads (dd example in the article). Cloud providers have been doing this for long, long time already.. Why the author did not mention those, it is to be seen..
> Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case.
I think the argument here is you can't build your own docker images that you use in production and run them on your mac without emulation (unless your production workload also runs on ARM).
That's a fair point.
Emulation implies other limitations too - code compiled on your machine might leverage only the CPU features emulated, which would lead to sub-optimal binaries, not to mention much slower builds.
> 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling.
Yup, performance benchmarks are inherently flawed and nobody knows anything right now without the hardware. However if ARM -> x86 emulation is anything like x86 -> ARM emulation, I would expect a really big performance loss.
> 2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case.
Ah actually I address this in the article, and even run an arm64 image. The short version is, it would be a lot of work to convert your whole backend infrastructure to ARM just because you got a new laptop.
> 3. You won't be able to use most software because they don't release ARM binaries ... and the example uses `wget` && `tar xf`, with no binary signature check. As someone who has been porting stuff from x86_64 to aarch64 for a couple of years, I admit I've seen this pattern frequently. The most obvious solution is to build from sources, which would have been better off on x86_64 too, instead of fetching a prebuilt (and unverified) binary from the internet. Maybe there are some CPU flags the compiler could notice and apply optimizations which are not included in the prebuilt binary.
Yes, if only everything were built from source! I'm not saying there's no solution, just that the solution would be a lot of work. If the library is obscure enough and the errors are strange enough, it might be so much work as to be impossible to the busy web developer.
My goal was to write a kind of hand-wavy article to get people talking about this problem.
I agree on the performance loss. Just for kicks, I ran the same commands on some real aarch64 (32 cores, 3.0GHz, ARMv8.? - can't remember and already logged off the machine, but I can double check tomorrow).
Without further context, numbers:
someuser@some-aarch64-machine:~$ docker run arm64v8/ubuntu bash -c 'dd if=/dev/urandom bs=4k count=10k | gzip > /dev/null'
10240+0 records in
10240+0 records out
41943040 bytes (42 MB, 40 MiB) copied, 2.18298 s, 19.2 MB/s
someuser@some-aarch64-machine:~$ docker run amd64/ubuntu bash -c 'dd if=/dev/urandom bs=4k count=10k | gzip > /dev/null'
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
10240+0 records in
10240+0 records out
41943040 bytes (42 MB, 40 MiB) copied, 6.72324 s, 6.2 MB/s
A 3x slowdown is not as bad as 6x, but it's still quite a bit. I also saw a slowdown of ~4x when I tried this experiment on a native Linux x86_64 running ARM - perhaps the Mac -> Linux virtualization slowed it down further.
5x may have been a bit alarmist, but regardless we should brace ourselves for a big performance hit on x86_64 virtualization.
I'm surprised it's only a 3x slowdown.
But the single-thread performance of native execution (without emulation) is worse on aarch64, which was expected.
Imo, a better benchmark would take into account the multithread performance with/without emulation.
312 comments
[ 2.8 ms ] story [ 273 ms ] threadThings like the pinebook pro (and hopefully more linux ARM devices) will keep pushing this further.
The one use case when this might be viable is targeting AWS Graviton2. Does anybody know if you can run an emulated Graviton2 on ARM Mac?
You can't run your x86 docker image on your ARM mac without emulation. You can't run your x86 Windows VM without emulation etc.
Of course there are solutions like using a remote server or a VM in the cloud, but if you're buying a decent machine then you would normally expect to be able to run these things locally.
For example, back in 2017 Cloudflare was basically looking at this as a question of which hardware ran most cost-effectively rather than having engineering heroics first: https://blog.cloudflare.com/arm-takes-wing/
My company definitely had problems to get database drivers to work generally speaking and on both 32 bits and 64 bits. Have a look at postgres, oracle, cassandra, redis, sybase to name a few, I am not sure which one was worse, it wasn't me doing the work. But I've seen some of the C and C++ dependencies that needed to compile with the errors that happened and that was horrendous.
If you want a sample. Try to install the cassandra client library in python. It will pull in and compile all sort of shit. That's supposed to be python and easily cross platform.
Yes, we should clean up the mess! It doesn't mean it's not a mess. And I think the mess is actually still understated.
But Apple can't just pay-up every cross-platform software developer. Smaller developers will have to re-evaluate whether macOS remains a viable target platform for them. Which can translate to a dev-gain for Linux. The catch is that Linux is in much better position to translate an influx of developers to an influx of new users: Linux runs on what you have, while macOS requires you buy Apple hardware.
And let's not forget about macOS as a gaming platform. Linux has made a huge leap forward with Steam Proton. On macOS there's still a ton of games not supporting x86_64 (Catalina), and situation won't get better by transition to ARM.
I’m sure that's not the case. It's much more in Adobe’s interest to be ARM-ready on day 1; there are plenty of Photoshop alternatives in the Mac App Store—notice they demoed Affinity Photo running on the ARM Mac and Affinity is much better at using Apple's native APIs and technologies than Adobe every was. And it's just a one-time cost of $49.99 vs. renting Photoshop from Adobe. Users of Apple devices are continue to be a large segment of their customer base.
Adobe has already migrated all of their core applications to a new codebase that should be relatively easy to bring to ARM Macs. Photoshop and several other of their apps already runs on iPadOS, so it won't be that big a deal to move it over to Big Sur.
So nothing is changing. ARM Mac isn’t going to change the Linux desktop/laptop story.
Hence why plenty just target Android, although some of their apps could easily be targeting GNU/Linux as well (specially the ones that are mostly NDK glue + whatever framework).
However, I think Apple has been a far greater threat to Linux adoption than Microsoft. Why? Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux.
There is real value in proprietary commercial end-user application software. Most companies who make such software couldn't care less about supporting Linux. So if you want to use Linux, you have to use F/OSS alternatives and continue to try convincing everyone that somehow they're better than the commercial options... even when the rest of the world has agreed that they're really not.
The whole incentive structure around F/OSS development really doesn't work for software where the profit motive is in the product itself... Not some nebulous "support contract" that you don't actually need. (Which is a far bigger issue for end-user applications.)
The UNIX experience on the Mac is pretty shitty. Ancient versions of all the tooling. Command-line utils have that weird BSD well-water flavor. No package management. Funny Docker quirks.
The hardware used to be pretty nice, but honestly I'm still having trouble forgiving them for getting rid of the physical ESC key and turning volume control into a two-step routine on the TouchBar.
Honestly if I'm doing server-side development, I much prefer using my ThinkPad (Ubuntu) over my MacBook. About the only thing I miss is the far superior touchpad on the Macbook. That's it.
> The UNIX experience on the Mac is pretty shitty. Ancient versions of all the tooling. Command-line utils have that weird BSD well-water flavor. No package management. Funny Docker quirks.
It doesn't have to be the best nix environment. Hell, it doesn't even have to be a good one. It just has to be "good-enough". For this, they still have an advantage over Windows. And compared with Linux, they still have the advantage that by-and-large, things "just work". I have never personally been able to say that about a Linux desktop I've had. There is always one more thing to tweak, one more knob to turn, etc...
I'm with you on the ESC key and touch bar though... which they thankfully fixed the missing ESC key.
I can also install something like multipass on macOS if I want a good integrated virtual machine.
Last week I had to drop to vi and edit nfs.conf on a friend's Mac to solve very slow transfer rates. "Just works" within a very narrow definition of primitive use cases.
To be fair it's always been a one-step routine on the touchbar (touch and drag the icon) and they brought back the escape key.
On the other hand, my speakers have a physical volume dial that provides feedback via friction on movement so I like that better than touchbar or physical up/down buttons.
Discoverability certainly sucks for that second one.
Well, OS X is Unix, but GNU is not Unix.
That's what MacPorts is for ;)
Can be easily fixed by installing homebrew. Also you claim it is a shitty Unix experience while complaining about BSD flavoured tools.
> Funny Docker quirks.
How is that Unix related? BSD has similar issues.
Maybe you should have written the GNU/Linux experience is pretty shitty on macOS but no one claimed otherwise.
Very, very true. And Homebrew is actively becoming worse now. A few years back, Homebrew was great - now using it feels like using some weird underground software stack that exists only because Apple hasn't come around to nixing it yet.
Not a fan of the touchbar of course.
Otherwise everything else I need is usable on a Mac.
Linux is its own thing and trying to mix UNIX with Linux is always going to lead to disappointment.
With WSL, you basically get an actual Linux userland (with WSL2, I think you get an actual Linux kernel too), not just a Unix that's like Linux but different enough to be annoying. But I'm not sure that will be enough to convince people to move to Windows.
Most devs only want some kind of CLI and POSIX like capabilities.
Back in the day I was using Hummingbird.
I used to admin UNIX and develop for it from Windows NT/2000 workstations.
Also the FOSS version of Motif only appeared when Motif wasn't that much relevant and most enterprise shops were migrating to CORBA and Web as integration points.
which is why WSL is so great...
An approach already taken by other UNIX clones with their Linux compatibility syscalls layer.
As for switching... I'm increasingly unhappy with Microsoft's complete disregard of user privacy. Apple isn't perfect with that either, but IMO much better at least. For my use cases, Win and Mac are the only credible options due to software availability. So to get away from Windows.. there's not much choice these days.
Apple has a monopoly on their hardware, and they will likely sell a significant number of devices. This will lead to a lot more development for ARM that never would have happened otherwise.
That, in turn, may make tilt the balance in favor of ARM for a lot of other use cases outside of OSX when other tools, applications, and hardware vendors better support ARM.
What makes ARM so exciting? Maybe battery use will be better? Maybe it will be slightly faster? Maybe? There's also been a lot of tuning done for laptop workloads on x86, it's definitely a maybe. I expect the only noticeable changes for most users to be somewhat better battery life, some apps not working, and occasionally having to know which package to download.
Why did you have to switch from Alpine to Debian? Alpine supports ARM quite happily, and it looks like they're shipping Docker images for ARM (and other architectures, too).
https://pythonspeed.com/articles/alpine-docker-python/
How so? If anything, apk is way nicer than apt in a container build script (or anything automated); with apt you have to use -y and maybe force the noninteractive frontend, where `apk add foo` just works, correctly, automatically, with no effort required.
> Also much easier to set locale.
> considering potentially slower performance:
It's slower at installing python packages from pypi since it can't use cached versions. That's not the same thing as "it's slow".
> Since minimal ubuntu & debian exist, I think the question should be: "Why would you use alpine?"
Because minimal ubuntu is still ~3 times the size of alpine, alpine is much smaller and simpler, alpine defaults to staying small (even if you remember to --no-install-recommends, deb packages are bigger and less modular), and I don't have to remember how to force apt to run in "no really install without asking questions" mode.
Debian in Docker in comparison offer less surprises, but you have to consistently do the right incantations.
Regarding missing binary wheels on ARM: with more ARM laptops in the wild those would eventually become more common.
Honest question: What sort of development regularly requires using docker or virtualized OSes?
If you sit back for a second, you can see that things like systemd provide nearly everything you'd want from a container, that, like, who cares is the approach you could have, for the top ten languages.
If you are running a massive stack then maybe you do need Docker and VirtualBox but at this point, shouldn't you be using a staging server anyway?
1) I wanted to provide a Jupyter notebook with IBM DB2 support for a university course. (Why DB2? Because its optimizer can transparently use materialized views for query optimization which PostgreSQL can't AFAIK.) IBM provides a Jupyter magic which requires the Python package ibm_db. ibm_db requires a DYLD_LIBRARY_PATH hack which macOS doesn't support unless you disable System Integrity Protection. I don't want to disable SIP on my system and I can't ask our students to do that. A Docker image provides a convenient solution to the problem.
2) I do a lot of disparate project development using Flink and Hadoop. These get deployed on Linux machines. My preferred way to develop on my Macbook is to boot up a headless Ubuntu system inside VirtualBox, SSH into it, and then start a TMUX session. This has a number of advantages. a) The dev environment more closely resembles the production environment. b) I can setup my TMUX session, save the state of the VM, and then restore it months later to the exact state just by booting up the VM. c) I don't have to pollute my macOS environment with dev tools that I rarely use. It's not strictly necessary but it's actually quite convenient. I can even do development in IntelliJ on macOS, run the services inside the VM, and thanks to remote JVM debugging use the IntelliJ debugger on macOS to step through the code running inside the JVM.
Almost all the compiler toolchains for embedded devices will not run under anything but some esoteric specific version of Linux or Windows.
I generally write code on Mac native (C or C++), then put it into a VM configured with all the right tools and such to build and install.
Usually that VM is a copy of the VM I use for CI/CD with gitlab.
I don't know how common that use case is, but I know everybody I know who does embedded work does it that way or something like it.
> However, this would take months
(infomercial arms)
I'm sure it won't make sense for everyone, but I'm just as sure it will make sense for many.
Perhaps this will spur some people over to running ARM servers in the cloud...
We can have the experience of developing on ARM to deploy on x86 right now with ARM workstations. A 16 core barebones costs around $700
I don't see why this would be so hard. If anything, I expect to see a massive upswing in things like AWS Graviton2 uptake, and a lot of common Docker images being built with ARM versions out of the box. It might be about a year or so, but eventually we'll be able to just go ARM-native the whole way.
What Apple needs to do is make a first-class, WSL-tier implementation of Docker for Mac for ARM.
This has no chance of happening. The common cloud CI systems do not support ARM at all (travis, circle CI and co). There is only a minority of developers with macbook and the rest is not going to spend $2000 to buy one just to build some docker images.
Better question might be, how many of the most common open source projects are managed by volunteers in their spare time? These will not build for ARM, unless there is a free tool doing it automatically for them. Currently GitHub + travis/circle can do for x64 on every push to master.
[1]: https://aws.amazon.com/blogs/aws/new-ec2-instances-a1-powere...
I'd love to have a POWER and an IBM LinuxONE in my shed, but that's not going to happen.
Maybe the POWER, but the Z most likely not.
https://docs.travis-ci.com/user/multi-cpu-architectures
GitHub lists it as a feature now:
https://github.com/features/actions
I'd be very surprised if this didn't become more common given the high levels of interest people are showing towards ARM server offerings in the cloud space.
I travel the world meeting developers from multiple communities. I very rarely see one without a MacBook.
I have no idea what plans they might have but I would be surprised if you couldn’t install some ARM Linux distros on their laptops sometime next year.
I'm guessing new ARMv8 ISA features, PAC/BTI/MTE?
The reality seems to be that their top MacOS developers have been busy laying groundwork for the ARM transition. There's so much to be done.
I'm not sure what you're asking? It's lower level than the examples which were given.
There's nothing stopping you using a MacBook for almost any development task. It's not just for front-end tasks. You can do work that runs directly on the architecture.
Or, you could use already-extant Debian ARM releases and spend minutes rather than months switching over.
Slightly longer (but not much) answer: https://www.youtube.com/watch?v=Hg9F1Qjv3iU&feature=youtu.be...
It's true it will cause some pain in the first year or two, but even as a heavy VMWare Fusion user I am really looking forward to the benefits of a vertically integrated laptop.
Xhyve and HyperKit (used by Docker for Mac) uses Hypervisor.framework exclusively. The last time I tried Hypervisor.framework on x86-64, the CPU performance was quite fine (matches that of VMware/VirtualBox), but I/O was pretty abysmal. Emulating x86-64 on ARM is probably going to be a role of something similar to QEMU.
[1]: https://developer.apple.com/documentation/hypervisor/apple_s...
https://www.parallels.com/blogs/apple-silicon-wwdc/
> In Linux, Docker uses kernel features. It does not use any hypervisor. > In Windows, Docker desktop uses Hyper-V. > In Mac, Docker desktop uses Apple Hypervisor.framework.
The very first hypervisors worked using dynamic binary translation. They would run a "guest" operating system by executing a stream of native instructions directly on the host CPU. This stream would be dynamically translated to remove and trap in software any privileged operations so the hypervisor could handle them. Modern hypervisors take advantage of hardware features that allow you to more efficiently trap on privileged operations. ARM started to add some of these features starting in 2013 [1]. In contrast Intel first started adding these features to the Pentium 4 in 2005 [2]. When such hardware features were released, they actually were not faster than the software translation. These days the hardware based options are faster. There is even hardware support for running nested hypervisors. So the first question we need to ask is how hypervisors implemented with ARMs hardware features stack up to Intel. I have no doubt that parity at a minimum will be reached I just don't know what the current state of play is. As indicated in my original comment, if I had to bet on release we wont quite have the performance or feature set you would be used to with a product like VMWare Fusion.
The second question we need to ask is whether there is a way to efficiently emulate x86-64 processors on ARM hosts. Even better if you can do this while taking advantage of the supporting infrastructure hypervisors already have in terms of the emulated devices and other features. QEMU just gets you the CPU and a short list of a devices. The fully experience of a seamlessly virtualized guest requires a lot more than that. But at the core you are right that it is going to require QEMU-TCG, Rosetta 2, or some similar technology because the silicon just is not there to execute x86-64.
Exciting stuff! We'll see where it all lands.
[1] https://lwn.net/Articles/557132/
[2] https://en.wikipedia.org/wiki/X86_virtualization#Intel-VT-x
Whether you can stick an emulated x86-64 CPU in there is another matter. It's a much bigger engineering lift and unless Apple puts some resources into it it's not clear to me a virtualization company by themselves would want to incur the cost. I hope there is enough demand for it and that someone will provide it. For me personally the only reason I run VMWare Fusion is to access x86-only Windows applications for which there is no replacement.
[1] https://blogs.vmware.com/vsphere/2019/10/esxi-on-arm-at-the-....
[2] https://twitter.com/VMwareFusion/status/1275466832002945024
It will all come down to whether this move gives Apple a significant performance and/or battery life advantage. If Apple pulls it off it will force Microsoft and other vendors to respond.
This is critical especially when they make their older devices "EOL" and there are no more OS updates.
I would not personally buy a Mac product for the next 2-3 years.
Project is part of Office.
In any case I though we were talking about consumer devices here.
EDIT: I suppose I should clarify; I don't totally disagree. I personally run Ubuntu on my laptop and servers. But plenty of people are quite happy developing on Darwin and deploying to some sort of GNU/Linux.
If you want to develop containers for x86 systems on an ARM system, you'll have to cross compile your containers, which I'm not sure if docker actually supports outside of emulation.
If you are only a consumer of containers, most of the popular ones have been compiled for multiple architectures.
Only the host OS is going to have the right drivers for the trackpad, wi-fi, GPU, power management, etc. etc. Through virtualization, the guest OS doesn't have to worry about constantly evolving hardware models.
Virtualized OS performance is already very good, and USB passthrough has existed for a while. Snapshots are a godsend.
What won't work are things like CUDA for eGPUs over Thunderbolt 3, and you'll have to share disk and RAM with the host OS.
But for most use cases it's probably the right choice. (This doesn't address the author's concern about moving away from x86.)
1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling.
2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case.
3. You won't be able to use most software because they don't release ARM binaries ... and the example uses `wget` && `tar xf`, with no binary signature check. As someone who has been porting stuff from x86_64 to aarch64 for a couple of years, I admit I've seen this pattern frequently. The most obvious solution is to build from sources, which would have been better off on x86_64 too, instead of fetching a prebuilt (and unverified) binary from the internet. Maybe there are some CPU flags the compiler could notice and apply optimizations which are not included in the prebuilt binary.
I'm not an Apple fan and I'm certainly not a fan of cross-architecture development either. I do agree with the general idea behind the article, however I find it a bit hand wavy.
I think the argument here is you can't build your own docker images that you use in production and run them on your mac without emulation (unless your production workload also runs on ARM).
> 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling.
Yup, performance benchmarks are inherently flawed and nobody knows anything right now without the hardware. However if ARM -> x86 emulation is anything like x86 -> ARM emulation, I would expect a really big performance loss.
> 2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case.
Ah actually I address this in the article, and even run an arm64 image. The short version is, it would be a lot of work to convert your whole backend infrastructure to ARM just because you got a new laptop.
> 3. You won't be able to use most software because they don't release ARM binaries ... and the example uses `wget` && `tar xf`, with no binary signature check. As someone who has been porting stuff from x86_64 to aarch64 for a couple of years, I admit I've seen this pattern frequently. The most obvious solution is to build from sources, which would have been better off on x86_64 too, instead of fetching a prebuilt (and unverified) binary from the internet. Maybe there are some CPU flags the compiler could notice and apply optimizations which are not included in the prebuilt binary.
Yes, if only everything were built from source! I'm not saying there's no solution, just that the solution would be a lot of work. If the library is obscure enough and the errors are strange enough, it might be so much work as to be impossible to the busy web developer.
My goal was to write a kind of hand-wavy article to get people talking about this problem.
A 3x slowdown is not as bad as 6x, but it's still quite a bit. I also saw a slowdown of ~4x when I tried this experiment on a native Linux x86_64 running ARM - perhaps the Mac -> Linux virtualization slowed it down further.
5x may have been a bit alarmist, but regardless we should brace ourselves for a big performance hit on x86_64 virtualization.