Out of curiosity, what pain are you expecting?

Maybe I'm spoiled because my development is mostly java, python, Go, docker, etc, all of which should have no runtime problem.

In terms of IDE, It looks like vscode is ported which is great.

I see two projects in my workflow: intellij and iterm2. I can live with a vanilla terminal but I'll need intellij. It looks like there's some[1] discussion around support.

1. https://github.com/JetBrains/intellij-community/commit/db531...

How do you expect docker to run fine when it doesn't even run good on x86 OSX? There are constant performance issues (https://github.com/docker/for-mac/issues/3499) because docker-on-mac is basically a VM running Linux

Docker is a linux tech tied to features in Linux kernel. You don't have cgroups and the like in XNU (OSX kernel) to be able to run docker natively on OSX.

It's OSX's fault then. Windows can run containers natively now as long as the base image is windows too. No reason why OSX couldn't extend support either.

I would suggest that the VAST majority of Docker usage on Windows is not “windows containers” but Linux-based containers in a VM, be it WSL or Docker for Windows. The promise of Docker is that a container image built on machine A will run on machine B. That relies on them running the same operating system in some capacity.

I don't expect it to be too painful. Most common software has already been build for ARM on Linux. A lot of things have event been built for Apple's ARM chips running iOS, though the App Store restrictions have limited the usefulness of these builds. Unmaintained closed source software will stop working but most of these applications were already killed by the removal of 32-bit x86 support in Catalina.

The biggest potential issue will be how people get hardware for doing the builds. Hopefully Apple will provide a good way of cross-compiling or a new machine that is suitable for datacenter deployment (ARM based mac mini?). We'll have to wait for the WWDC announcement to find out.

You mention Docker which most definitely will be impacted by this change. Docker on Mac runs off a virtualized x86 Linux instance. Docker only announced ARM support last year I think, I can't imagine Docker for ARM would be as anywhere near as fully supported as it is for x86, and you certainly won't be able to build x86 images to push to x86 servers, without using some sort of emulation layer which will be horribly slow compared to current macOS x86 docker.

Currently running docker using WSL2 on an ARM laptop. So it's pretty much native Linux, as an anecdote I can tell you that it's just that much more stable than with my Mac or with a traditional Windows laptop. The only downsides is there's a few docker containers that you have to hunt around for to get the ARM64 version. The only way I see docker performance to be better than this or more stable is to switch to a Linux machine entirely.

Yes - that's what I was alluding to in my original reply, re: lack of support, lack of images. Docker running on ARM might be great, but one of the original purposes of docker was to build and run the exact same images that would run on your servers, which will no longer be the case unless those servers are ARM based as well.

What laptop ?

Surface Pro X

I use ARM64 Docker on my Raspberry Pi 4s, it’s excellent and loads of images are already available.

But for instance emulating an ARM raspberry on a fairly powerful i7 through qemu is... an exercice in patience to say the least, from my experience compiling the same codebase on the host system and the emulated Pi, it is almost 10x slower. So I'm not holding out on ARM having powerful x86 emulation.

Use qemu user mode with a chroot, it's much faster.

I'm using https://github.com/multiarch/qemu-user-static - that's what it is, right ?

Yes, indeed.

But instead of docker, just deboostrap the amd64 release under a directory, copy qemu-amd64 to $DIR/usr/bin and chroot into that directory. Docker is a bit of a mess.

Before chrooting, bind-mount:

/dev to $DIR/dev

/proc to $DIR/proc

/dev/pts to $DIR/pts

/sys to $DIR/dev

/home to $DIR/home

copy /etc/resolv.conf to $DIR/etc/resolv.conf

Then chroot and login (su -l yourusername). That way you could try running a lot of software.

okay, will try to see what that gives. I'm curious as to why it would be slower (when taking into account that an equivalent docker container, say running debian stable, but with the same architecture as the host, runs in more-or-less the same time as building directly with my host's GCC)

>ut with the same architecture as the host

debootstrap an ARM rootfs, please.

Yeah but that's Linux. Docker works excellent on Linux distros

Yep - I make no claims as to how well Docker works on an ARM Mac.

You are probably going to have a great deal of pain with Docker. If you use Docker for Mac, it basically uses Hypervisor.framework to run a slim x86_64 Linux virtual machine. Rumors suggest that Hypervisor.framework won't emulate x86_64 in the next version of macOS. We'll find out tomorrow. So you'll either set up docker-machine with a x86_64 based remote server to run your docker commands, or you'll just use ARM versions of the various docker images. I don't know where you get your images from, but many of them won't be available for ARM.

There's a surprisingly large number of ARM docker images. You can partially thank the Raspberry Pi for that.

Is that ARM v6/v7 32bit or ARM v8 64bit? Most Raspberrys run a 32bit userland (armhf).

Plenty of ARM64-architected images available. Lots of us using 64-bit Ubuntu.

Yeah but then you have consistency issue which Docker aimed to get rid of. You local setup won't replicate what runs on production. The enterprise infra isn't going to switch to ARM in next 1-2 years as Apple hopes to.

I bet that all popular docker images will be available for ARM very soon. It's a matter of recompiling.

What are the largest benefit for iterm2? I use it but honestly I don't see much improvement over Terminal.

Probably tmux integration, but the speed decrease against Terminal doesn’t warrant the additional features for me at least.

A trick I recently learned is to add iTerm 2 to the “Developer Tools” section of the Security prefpane - it makes it fly. Similarly if you’ve ported your config through several versions of iTerm, ensure that GPU-accelerated rendering is on.

It’s no stretch to say that iTerm 2 is a major one of the reasons I cannot stand desktop Linux (or Windows, even with the new terminal there).

For me, it's the little things such as ability to undo accidental terminal tab closing with cmd+z, restoring sessions after restart so I don't need to reopen a bunch of tabs and cd manually, ability to show timestamp for each command run, etc.

VS Code is not yet ported to ARM, there are bootleg builds but they do not work with many extensions, for example Remote SSH relies on a project that lies below the VS Code project proper, and that (apparently) is a fair bit of work to bring to ARM (though it's being worked on) [0]

[0] https://github.com/microsoft/vscode/issues/6442

You are wrong. I currently use VS Code insiders daily on ARM with all my extensions working.

https://code.visualstudio.com/updates/v1_46#_windows-arm64-i...

I second this, of course VS Code needed Electron which needs Node all ready for ARM https://github.com/nodejs/node/issues/25998#issuecomment-637... Also to note Edge is available on ARM. Very happy Surface Pro X user here.

I second Edge working fantastic on ARM! I have a Galaxy Book S.

Really? That is GREAT NEWS!!!

EDIT: It works great, and it has remote for ssh and wsl!!! This made my day!

out of what you've listed docker is probably the biggest issue -- there is support for multiarch containers but migration has some pain points depending on your setup, also docker will be have to made to work on the arm build of macos assuming virtualization is supported and speedy

What about legacy software and software provided by a vendor? Let's say I want to run Fusion 360 and Altium on my hypothetical ARM Mac. Can I do that today?

Outdated information: Windows on ARM requires you to build UWP apps which is more work than just a recompile.