They mention using Apple's Hypervisor Framework. On Apple Silicon, this runs ARM64 programs only (Rosetta 2 is unavailable to programs running inside Apple's Hypervisor Framework).
Unless they plan to run an emulator inside the Hypervisor Framework (a seemingly unnecessary effort since you could run the emulator without Hypervisor) this implies x86 containers will not work.
Seamlessly, but with a heavy performance impact. In my experience it's not really usable in anything other than running specific single tests, or some short demos.
It runs user space x86 under arm, and those are all well formed programs that the os understands. Rosetta is a translator - to run a vm in a different architecture requires an emulator.
That requires that ARM images are available, which will take time and always have a disconnect. It also violates the idea of being able to run the exact same image on your laptop (ARM Mac) and in prod (x86 server).
You can run on ARM servers in production. They're even cheaper than x86 servers. (Though also slower, at least AWS's version.)
Realistically, ARM is probably the future, and just needs something to push society in the direction of the future. A lot of people use Macs, so this forces people to become interested in switching, which has some value. Remember when the original iMac had USB instead of ADB ports? Everyone was mad about it. But USB was the future -- you can plug that iMac's mouse into pretty much any computer you have and it still works.
(I've been wanting an ARM desktop for a while, but it seems there is trouble standardizing something like BIOS/UEFI, and the CPUs you can buy are more expensive and slower than x86 alternatives. I'm also not sure if anyone ever decided what the standard "ARM" configuration looks like... binary calling conventions, endianness, supported instructions? But, if Apple can make a competitive ARM chip, so can others, and the standards will follow. We'll see!)
> You can run on ARM servers in production. They're even cheaper than x86 servers. (Though also slower, at least AWS's version.)
Where can I buy ARM server comparable with x86 server on performance? I'm not interested with clouds, I want bare metal server. I'm not aware of any server brand like HP or Dell producing ARM servers. I'm also not aware of any CPU manufacturer producing computer desktops with ARM comparable with x86, outside of Apple macs. I'm not convinced that ARM is the future. For me the future is both architectures co-existing.
I promise that is not what 90% of people mean when they say they want bare metal, and not what 99% of people mean when they say they don't want "cloud"; it's still AWS's machine.
Honestly, if they mean "owned machine in colo" they should say that rather than "bare metal". Those are orthogonal concepts. (You can have VM instances on a private cloud on owned machines as well)
If you're actually interested in buying servers this is not a pedantic difference.
Running the same image on dev machine and prod was an illusion brought by the fact the underlying architecture was the same. It’s not reasonable to expect images to magically be cross-architecture.
> It also violates the idea of being able to run the exact same image on your laptop (ARM Mac) and in prod (x86 server).
99% of people are running node/python/RoR/PHP on Ubuntu/Debian/Arch. It works the same for most cases. (possible caveat: I'm not sure if numpy and TensorFlow is supported already but it probably is)
You still can't use the same container image across architectures, even if the important parts are interpreted code. You can package the architecture-independent parts for both x86 and ARM, of course, but as you sort of touch on, that still leaves dependency issues and surprise differences in the platform ("oh look, this is so fast on my mac where there's hardware acceleration for the C library used in this hot path" followed 3 weeks later by, "why is this so slow on our x86 servers?").
Aws Graviton2 images. It’s exciting to finally have ARM consumer laptops: it’ll encourage people to port applications to ARM which will make it easier to take advantage of cheap ARM servers.
No. That's what they said: you will build for your deployment architecture, just as you would today with the arm aws systems. The virtualization is that: virtualization. It isn't emulation for that you need Qemu or similar.
If Docker can run on Raspberry Pi's ARM chips, it can run on Mac ARM chips. I expect we'll see this working very soon after the new Macs start to arrive.
Docker is architecture specific though. The meaningful question is whether it can run the same docker images as it did on the previous Mac hardware or not.
Sounds a bit like Docker is at a loss. Caught between a closed source OS (rock) and an architecture change (hard place).
Ideally, they could leverage Rosetta2 to run x64 containers under macOS on Apple Silicon ... but I guess Apple isn't playing ball (because otherwise they would have probably announced it at WWDC).
At this point I see an Apple Silicon based Mac is just a consumer device, I don't think I'm going to be able to use it in anger for development work at the moment (other than for Mac consumer apps).
Not really sure what Apple have to lose here ... but if Macs with Apple Silicon are not a viable dev platform for "mainstream" containers, then that's going to drive developers to Linux (or Windows).
I think Apple didn’t want to support x86 emulation at all, and made Rosetta 2 purely AOT compilation (which you can’t really do with virtual machines). It makes it so they don’t have to deal with having x86 VMs available but super slow making people think that Apple Silicon is slow (even if that’s untrue), and that’s kind of the growing pain that Microsoft is going through at the moment with Windows on ARM.
It certainly still does some JIT/interpretation at runtime but it does indeed translate the executable upon first launch.^1 I can’t imagine how it would be able to fully translate a browser JavaScript engine that’s doing its own JIT, for example.
Automatic translation of a hypervisor, guest kernel, and guest userspace is a far different level of difficulty than translating a userspace application.
Saying "didn't want to support" implies that one can "just" repurpose binary translation with a few build settings. You're off by several orders of magnitude.
I agree with you, but there's probably already been some pressure with people wanting to use Raspberry PIs/other ARM-based boards for K8s clusters. I wonder where that tipping point will come.
Most of the Raspberry Pi trials I see end in lots of $100/hr developer time spent waiting for a $10 device to finish being slow. Or, worse, inflicting that experience on customers at a demo booth. It's not an attractive look. A high quality ARM desktop experience could change that.
> At this point I see an Apple Silicon based Mac is just a consumer device
Not everyone runs Docker or similar to do their work.
If it turns out that Apple’s performance claims are true, I don’t see people easily letting it go, a snappy machine is a serious advantage. After all, we are in this deep trouble because of the endless layers of abstraction, so I don’t see it getting any speedier anytime soon for the status quo.
Amazing blank sheets could open on this news M1 macs.
The performance claims are substantial, it could mean 3000$ snappiness at 1000$. A bit like making cheap DSLR and now everyone is a professional photographer, making room for new tools for the new comers.
Mac prices are the gatekeeper for the Apple dev ecosystem in the developing world or students from low income background because most will try to get the best bang for their limited bucks. Maybe it’s possible to unlock it?
If Docker performance on Mac was a disincentive for using it, then people would have abandoned it because of the hypervisor instead of container architecture.
Not docker performance but IDE and other tools performance and effortlessness.
That's where tool user, AKA "The Developer" experiences the performance. If the autocomplete comes up fast, you are a happy developer, if your scripts finish running instantly on every save, you are a happy developer. If you click and it runs, you are a happy developer.
If you think about it, Docker itself is about that comfort of not having to deal with the tool setup every time. On Apple dev technology that's the default without Docker. Search for Xcode on AppStore, click download, click open once it's downloaded, write your Swift code that can do UI and backend , click run and it runs. Sometimes autocomplete stops working but you just close Xcode and open it again and it works :)
There's nothing you can't do on 2015 Macbook Air that can be done on a fresh high end Macbook Pro. The difference comes from the comfort of being snappy and people pay multiple times more for that snappiness.
It's $99 and it's not a gatekeeper to anything. People who need the developer program subscription easily make multiple of it each month even in the poorest countries. You only need it if you are going to distribute apps through Apple AppStore, you don't need it for anything else.
I have bought a computer, I have now bought a chair. I don't need to buy a new computer or a new chair if my development takes longer than a year.
I don't know what you mean about a social security system, I don't think anyone is talking about that so it's a bit nonsense.
The point is it is a gatekeeper. Your first app that you build doesn't make $115? Then you didn't break even and you are down, and are taxed another $100. Considering that Apple then billing you 15% on your takings, it is another bar to clear.
It's hard to follow this thought process. Somehow you claim that you are entitled to do business on one company's systems on terms that you decide. This doesn't make any sense what so ever. It sounds like those people who think they should own all the movies, music or software for free because they pay for an internet connection.
If you don't like the business proposition, just don't do business with Apple. Go make apps for Google Play store or Huawei or anything else.
Yes, you need to pay the $99 to have a registered developer account, which is required to digitally sign apps to distribute through the App Store. Of course, you can download and use the dev tools for free, and distribute/sell your apps any way you like, without paying Apple anything. So if the App Store isn't worth $99 as a sales channel, don't pay it.
I have been coding for 30+ years, and am yet to run Docker in anger.
And by the looks of it, when I finally get to do some project with it, the language specific runtime tools like Project Tye for .NET would already have replaced it.
Docker Desktop is closed source on all platform it supports. It’s one of the reasons I don’t like to use it even on Windows. There is no way to report bugs (no one from dev team replies to it), and no bug fixes from the community are possible.
When using containers nowadays I would keep everything open source, like LXC/LXD, Cri-O, Podman. All run perfectly fine on the Linux kernel that comes with Windows. Apple has to do something similar to WSL to make devs happy.
I want x64 docker on Arm , as this could also be massive for server power consumption. But things take time . If your some wiz kid who can crack this puzzle you’ll have a billion dollar startup within 6 months
As someone who’s published on the App Store , having a single binary run on IPhone , IPad and Mac is a much much bigger deal than most of you realize .
Why? I would expect the user experience to suffer on one or both. MS already went down this path and the end result were apps that made compromises to try being usable on both platforms.
And if some startup is doing it, i know enough companies who will instantly buy a better docker for mac solution if it does have better filesystem performance. Accessing the macs filesystem from the docker container is really slow, there are some solution (e.g. docker-sync) but they all stop working after some time.
Because years , if not decades of legacy server code could be ran on Arm without re-writing anything.
An EC2 rival could run the same processes using 30% of the power. Plus as ARM tends to run on much smaller devices, you could theoretically save tons of physical space with data centers.
Assuming you could also have the same reliability, I'd believe you could get the cost way down. Who wouldn't want to operate their service for half price
Maybe building containers for one operating system and architecture from a completely different operating system and architecture is not the best idea.
How do you think people write and compile software for any embedded or other low-powered architecture out there? The vast majority of hardware in use around the world today isn't desktop class, and emulation works just fine for building on those.
Cross compilers are nowhere near the same as Docker on ARM Mac building x86 Linux containers. The biggest difference: no one expects you to be able to run your MIPS binary on the machine you built it on.
The really perplexing thing to me here is that Docker Desktop...was featured on stage at the Apple event. How? Did Apple just hack it together and get it working? Was it just fake? Was Docker involved at all?
I feel like it was implied that Apple was doing the hard work here, but now it looks more like nobody was doing the work, and showing it off working was a hat trick?
Docker is likely saying that it doesn’t natively run on ARM yet. Apple’s demo was likely using Rosetta. That said this is all speculation at this point. We’ll know tomorrow.
That screenshot shows a full Linux VM running on the machine using Parallels. That VM then has Docker running inside it. Docker for Mac isn't involved at all.
Oh yeahh..my guess is that was fake. More so considering that the development kit released back in June didn't even support virtualization, making both Parallels and Docker impossible to run.
Here's how I expect things to go with Docker on Apple Silicon:
- Rosetta 2 will not be involved at all
- They will recompile the CLI, daemon and other parts of Docker Desktop natively for arm64 (but this has a dependency on the Go toolchain)
- There will likely be a bunch of bugs or general inconsistencies in the new Mac Hypervisor (their dev hardware didn't even support virtualization), so it's unlikely that Docker's Hyperkit will just work out of the box on M1
- The above will take till mid-2021 at the earliest, but should hopefully release along with more "pro" Mac hardware
- Once it is ready, you should be able to cross-compile and run x86_64 containers on new Macs, considering Docker Desktop will still automatically use QEMU to do the emulation. I expect running native arm64 containers will still be better though.
TL;DR - don't buy the current lineup of Apple Silicon machines just yet for serious Docker work.
Your mention of “pro” makes me wonder - isn’t one of Apple’s big pushes to sell to professional designers, photographers, etc.? Don’t they realize that some huge percentage of engineers and tech workers use their macs? That’s a whole segment that quite literally builds and runs all the platforms where macs are advertised or talked about...where is the “pro” MacBook targeted at that segment? With advanced virtualization, strong dev tools, whatever. You would buy so much loyalty and word of mouth from people who set the standard for technology. Heck, who actually write the standards of technology.
They are aware of it, thats the reason why the 15 inch macbook pro for example does not have apple silicon yet. They released the consumer hardware now so everyone has 1 year to port their tools to apple silicon until the bigger (more professionell) machines arrive.
Both Electron and Go were referenced in the article but without links, so I went looking for them to understand how far along this work was. From the pages linked below it seems like with virtualization is the real challenge.
And the GitHub issue tracking Go on AS, which mentions that support is coming in version 1.16 scheduled for release on Feb 1st 2021: https://github.com/golang/go/issues/38485
The virtualization apps for mac/win seem to be a big distraction for them and muddy their product image. Trying to hide ISA differences in the next version would be a logical continuation of this track of course... Maybe they should pivot to the WebAssembly direction thay the founder was talking about before.
> Along with this, we have technical dependencies upstream of us that need to make changes prior to making a new version of Docker Desktop GA. We rely on things like Go for the backend of Docker Desktop and Electron for the Docker Dashboard to view your Desktop content. We know these projects are hard at work getting ready for M1 chips, and we are watching them closely.
The only time I used docker mac ui is to change some docker machine config. If electron is a blocker then I think they can release the beta version without the ui and their users will hardly notice.
Given there is a bunch of software that is still incompatible to run on the new chip, what are all the benchmarks actually testing? I'm not disregarding the fact that the chip is fast but I'm just curious
128 comments
[ 4.0 ms ] story [ 206 ms ] threadWill docker running on ARM run docker containers from images built for x86? Will docker running on ARM be able to build images for x86?
EDIT: Just realized that you probably meant for binary compatibility. That also is not Linux-only, but https://qemu.readthedocs.io/en/latest/user/main.html#support... only talks about Linux and BSD, with no mention of Darwin.
There are already attempts in progress: https://news.ycombinator.com/item?id=25064593
https://developer.apple.com/documentation/apple_silicon/abou...
Unless they plan to run an emulator inside the Hypervisor Framework (a seemingly unnecessary effort since you could run the emulator without Hypervisor) this implies x86 containers will not work.
And if you're on x86, you can run ARM containers with QEMU userspace emulation seamlessly after running
The inverse would be extremely easy as well.If not, then why expect Apple ARM to run x86?
Yes. There are ways to set up Docker to seamlessly run arm containers on x86 using CPU emulation.
Use an Arm image. For docker, it makes little to no difference
Realistically, ARM is probably the future, and just needs something to push society in the direction of the future. A lot of people use Macs, so this forces people to become interested in switching, which has some value. Remember when the original iMac had USB instead of ADB ports? Everyone was mad about it. But USB was the future -- you can plug that iMac's mouse into pretty much any computer you have and it still works.
(I've been wanting an ARM desktop for a while, but it seems there is trouble standardizing something like BIOS/UEFI, and the CPUs you can buy are more expensive and slower than x86 alternatives. I'm also not sure if anyone ever decided what the standard "ARM" configuration looks like... binary calling conventions, endianness, supported instructions? But, if Apple can make a competitive ARM chip, so can others, and the standards will follow. We'll see!)
Where can I buy ARM server comparable with x86 server on performance? I'm not interested with clouds, I want bare metal server. I'm not aware of any server brand like HP or Dell producing ARM servers. I'm also not aware of any CPU manufacturer producing computer desktops with ARM comparable with x86, outside of Apple macs. I'm not convinced that ARM is the future. For me the future is both architectures co-existing.
You can have both.
https://aws.amazon.com/blogs/aws/now-available-bare-metal-ar...
If you're actually interested in buying servers this is not a pedantic difference.
99% of people are running node/python/RoR/PHP on Ubuntu/Debian/Arch. It works the same for most cases. (possible caveat: I'm not sure if numpy and TensorFlow is supported already but it probably is)
But for basic stuff, it's a non-issue
Apple may be the loudest and now the fastest available, but the ARM consumer laptops existed for some time already. For example https://www.lenovo.com/au/en/laptops/ideapad/ideapad-s-serie...
The "different beast" is just some go wrappers.
Ideally, they could leverage Rosetta2 to run x64 containers under macOS on Apple Silicon ... but I guess Apple isn't playing ball (because otherwise they would have probably announced it at WWDC).
At this point I see an Apple Silicon based Mac is just a consumer device, I don't think I'm going to be able to use it in anger for development work at the moment (other than for Mac consumer apps).
Not really sure what Apple have to lose here ... but if Macs with Apple Silicon are not a viable dev platform for "mainstream" containers, then that's going to drive developers to Linux (or Windows).
1: https://www.macrumors.com/2020/11/12/rosetta-2-translation-c...
Saying "didn't want to support" implies that one can "just" repurpose binary translation with a few build settings. You're off by several orders of magnitude.
Anandtech's benchmarks: https://www.anandtech.com/show/15578/cloud-clash-amazon-grav... Here's a tweet about one company's experience: https://twitter.com/lizthegrey/status/1314618333140971521
Not everyone runs Docker or similar to do their work.
If it turns out that Apple’s performance claims are true, I don’t see people easily letting it go, a snappy machine is a serious advantage. After all, we are in this deep trouble because of the endless layers of abstraction, so I don’t see it getting any speedier anytime soon for the status quo.
Amazing blank sheets could open on this news M1 macs.
The performance claims are substantial, it could mean 3000$ snappiness at 1000$. A bit like making cheap DSLR and now everyone is a professional photographer, making room for new tools for the new comers.
Mac prices are the gatekeeper for the Apple dev ecosystem in the developing world or students from low income background because most will try to get the best bang for their limited bucks. Maybe it’s possible to unlock it?
That's where tool user, AKA "The Developer" experiences the performance. If the autocomplete comes up fast, you are a happy developer, if your scripts finish running instantly on every save, you are a happy developer. If you click and it runs, you are a happy developer. If you think about it, Docker itself is about that comfort of not having to deal with the tool setup every time. On Apple dev technology that's the default without Docker. Search for Xcode on AppStore, click download, click open once it's downloaded, write your Swift code that can do UI and backend , click run and it runs. Sometimes autocomplete stops working but you just close Xcode and open it again and it works :)
There's nothing you can't do on 2015 Macbook Air that can be done on a fresh high end Macbook Pro. The difference comes from the comfort of being snappy and people pay multiple times more for that snappiness.
Isn't the yearly $199 developers fee a greater gatekeeper by design for people with a low income from participating in Apples ecosystem?
AppStore Developer subscription is not a social security program, you will need some capital to run business on it.
It is like the need to spent money to buy the flour and the chocolate before making money from your first donuts. Standart business stuff.
I don't know what you mean about a social security system, I don't think anyone is talking about that so it's a bit nonsense.
The point is it is a gatekeeper. Your first app that you build doesn't make $115? Then you didn't break even and you are down, and are taxed another $100. Considering that Apple then billing you 15% on your takings, it is another bar to clear.
If you don't like the business proposition, just don't do business with Apple. Go make apps for Google Play store or Huawei or anything else.
And by the looks of it, when I finally get to do some project with it, the language specific runtime tools like Project Tye for .NET would already have replaced it.
This is actually going to make it easier for me, as more ARM base images will get created.
I want x64 docker on Arm , as this could also be massive for server power consumption. But things take time . If your some wiz kid who can crack this puzzle you’ll have a billion dollar startup within 6 months
As someone who’s published on the App Store , having a single binary run on IPhone , IPad and Mac is a much much bigger deal than most of you realize .
That way you don't have "works on my machine" problems, because both prod and dev are clean virtualized identical systems (containers)
Docker was snapshots of developer machines you can run in production. They never promised that it would run everywhere.
I would have thought that anything of lasting interest would be available in source code and thus ported to run natively on ARM...
An EC2 rival could run the same processes using 30% of the power. Plus as ARM tends to run on much smaller devices, you could theoretically save tons of physical space with data centers.
It has been since July that you can have developer kits for Apple Silicon. This should not have been a surprise.
Why couldn’t they just write a quick set of native panels and call it a day? Sigh.
Edit: although sometimes you can through qemu.
I feel like it was implied that Apple was doing the hard work here, but now it looks more like nobody was doing the work, and showing it off working was a hat trick?
Makes you wonder what else was "simulated" during the demo?
EDIT: change "was" to "could have been".
Docker's blog post says "Docker for Mac (silicon)" dependencies are not working yet. Apple gave the demo 3 months ago.
Will I be able to build/run x86 (64bit) docker containers?
Will I be able to build/run ARM containers (and without "switching" something)?
Docker here is saying their "for mac" application dependencies are not even all working yet.
Unless I am missing something - Apple's Docker on silicon demo was fabricated?
Linux containers need a Linux kernel to function.
[1] https://developer.apple.com/documentation/apple_silicon/abou...
- Rosetta 2 will not be involved at all
- They will recompile the CLI, daemon and other parts of Docker Desktop natively for arm64 (but this has a dependency on the Go toolchain)
- There will likely be a bunch of bugs or general inconsistencies in the new Mac Hypervisor (their dev hardware didn't even support virtualization), so it's unlikely that Docker's Hyperkit will just work out of the box on M1
- The above will take till mid-2021 at the earliest, but should hopefully release along with more "pro" Mac hardware
- Once it is ready, you should be able to cross-compile and run x86_64 containers on new Macs, considering Docker Desktop will still automatically use QEMU to do the emulation. I expect running native arm64 containers will still be better though.
TL;DR - don't buy the current lineup of Apple Silicon machines just yet for serious Docker work.
Disclaimer: These are all just guesses
Here is a post saying that the latest beta release of Electron supports Apple Silicon: https://www.electronjs.org/blog/apple-silicon
And the GitHub issue tracking Go on AS, which mentions that support is coming in version 1.16 scheduled for release on Feb 1st 2021: https://github.com/golang/go/issues/38485
Electron 11 was released today and supports AS, but it is listed as experimental.
Would love to see an experimental docker for mac soon.
The only time I used docker mac ui is to change some docker machine config. If electron is a blocker then I think they can release the beta version without the ui and their users will hardly notice.