Live data from Hacker News

Docker fails to launch on Apple Silicon

github.com

91–100 of 281 posts

Re: Docker fails to launch on Apple Silicon

#91

Perhaps is time to stop virtualizing to run containerized software! Someone said WebAssembly? :P

Docker for Mac is a Linux VM with some tools to glue your Mac to that VM. It gives you the illusion that your Mac is running containers, but it's not -- Linux containers are a Linux thing. Some virtualization is going to be necessary unless your host OS is Linux. One could argue that maybe MacOS should somehow run the Linux kernel. Windows tried that as WSLv1 and it didn't work that well; WSLv2 just uses a VM. The ne…

Windows runs containers without a Linux kernel. They made a runC API out of existing Windows APIs.

runV and VMWare Vsphere 7 can run each container in its own VM.

WSL v1 did not run a Linux kernel at all, but v2 does.

Re: Docker fails to launch on Apple Silicon

#92
post #51
post #39

Earlier quoted context omitted.

That’s why I got the Pro (also my laptop is from 2013 and I’m desperate). I love and use Docker every day, and know it’s a mess right now, but I’m still excited to jump in head first. Edit: This is my personal laptop fwiw. My work one is still Intel.

What is the difference between the M1 Air and the M1 Pro 13"? From what I can tell, they are basically the same spec except for small differences like slightly bigger battery life, active cooling and touchbar in the Pro. Is that worth $300, for a larger form factor?

The Air is passively cooled, so the theory is it won't sustain higher workloads for as long as the Pro should be able to.

From what we know right now - same processor, different thermal envelope.

Re: Docker fails to launch on Apple Silicon

#94
post #16

I'm actually tempted to get one of the new Macbook Airs. There's something intriguing and fun about navigating the brokenness of a new ecosystem. Does anybody know how Steam handles the new macs?

If you can burn the cash then go for it, but unless these laptops can support something other than MacOS I'm (with a sad expression) staying away from them.

Obviously if you just make websites it doesn't matter but if I'm buying an ARM device I want to play with the bare metal (you can't even access performance counters in MacOS IIRC)

Re: Docker fails to launch on Apple Silicon

#95
post #90
post #34

Earlier quoted context omitted.

Here we go... Boot your container host in the browser! https://copy.sh/v86/?profile=archlinux

Wow, that's doing every filesystem operation as a separate fetch to the server? With no caching? Simple to implement, but about as slow as you could possibly get!

Yeah, but it boots up really fast (from a snapshot), and that's the important thing for a demo!

Re: Docker fails to launch on Apple Silicon

#96

I will not be buying one of these first generation M1 devices because of issues like this. But in the long term I actually think it’s going to be a really good thing for the industry if we can get more developers using non-x86 devices and deploying code to non-x86 servers.

It also marks the end of using the same artifact (container) to debug issues which is a huge selling point of docker.

Re: Docker fails to launch on Apple Silicon

#97
post #68

Why is this even a discussion? There are thousands of applications that don't (yet) work on Apple Silicon. When the hardware actually releases the software will be slowly ported over to it.

Because Apple would like us to believe that Rosetta is a panacea that makes everything work.

Re: Docker fails to launch on Apple Silicon

#98
post #5

The first AS Macs are targeted at people who don't need things like docker. Eventually all the support needed will be available. It's a two year transition, you have to start somewhere.

We don't know yet whether M1 will be able to support a hypervisor, so it's just too soon to say. I know it's not the HN culture, but I encourage everyone to take a deep breath and be patient for the actual hardware to arrive.

The Apple documentation for Hypervisor.framework now explicitly includes references to Apple Silicon, and even ignoring that, they showed Debian running in Parallels back at WWDC during the announcement. They literally had a giant interstitial during the talk that was titled "Virtualization," complete with a cute little logo/icon and a demo, in classic Apple style.

Re: Docker fails to launch on Apple Silicon

#99

This link is a little confusing because the top comment and much of the conversation is talking about the DTK which was based on the much older A12X CPU and not the M1. As far as I can tell, the M1 does have virtualization support, Docker just isn't ported yet. Update: Also, from Apple docs it seems like you won't be able to run emulation and virtualization in the same process. So you can run x86 Mac apps, but it's l…

Right, lots of confusion in this thread. A12Z/DTK: HW does not support virtualization at all. Apple M1 / New Apple Products: HW does support virtualization for ARM64 guests (both windows and linux demonstrated). What about x86 software in the guestOS? Not with Rosetta. Instead, the guest OS will have to provide its own translation (such as windows/arm's current x86->arm64 or upcoming x86_64->arm64 feature). I'm not f…

> Docker w/ arm linux kernel + x86 userland images

as mentioned in the issue comments: Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac, so x86 images via qemu on ARM host should not be a problem...

Re: Docker fails to launch on Apple Silicon

#100

I will not be buying one of these first generation M1 devices because of issues like this. But in the long term I actually think it’s going to be a really good thing for the industry if we can get more developers using non-x86 devices and deploying code to non-x86 servers.

It also marks the end of using the same artifact (container) to debug issues which is a huge selling point of docker.

Yup it almost feels a little short sighted now the way we have embraced taking applications written in architecture independent languages like java, python, etc., and packaging them up in architecture-dependent artifacts.
Post reply on HN