Tech Preview of Docker Desktop for M1 • Hacker News Board

Re: Tech Preview of Docker Desktop for M1

#181

Post by flarex » Thu, Dec 17, 2020, 3:20 AM UTC

Demiurge wrote: post #165

jeppesen-io wrote: post #27

Wow, that was fast. I was expecting to wait unil January. Key takeaway for me is the ability to run/build both x86 and Arm images on a M1. Can't see any reason M1s can't be used for everyone at my work now. Very nice.

I just tried to build an image from a work project, and it crashed. So, not yet. #10 11.95 Starting Installer ... #10 13.14 qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Had a similar issue with an image I tried.

qemu: uncaught target signal 4 (Illegal instruction) - core dumped

Re: Tech Preview of Docker Desktop for M1

#182

Post by stephenr » Thu, Dec 17, 2020, 3:44 AM UTC

geofft wrote: post #167

stephenr wrote: post #159

Earlier quoted context omitted.

> considering Docker's use of a VM behind the scenes in some situations (in which case the "host running the container" is technically the VM, not the user's PC). That is exactly the point. If you want to run Linux binaries you need a Linux container. On windows or macOS that means a Linux vm. If you want to run windows binaries you need a windows container. Conversely if you had a macOS container you’d only be able…

One, it might be totally fine to run macOS binaries! If your code is portable to macOS and Windows, you might still want to use Docker for dependency management, network isolation, orchestration of multiple processes, etc., but you might not care what the actual host OS is. (Just like how people are interested in running ARM binaries, even though Docker started out as x86-64.) At my day job, all the stuff we put in D…

> Two, it's not at all true that to run Linux binaries on non-Linux, you need a Linux VM.

So (a), this entire thread, the entire post, is about docker. (b) WSL1 worked so well, Microsoft not lonely abandoned that approach for WSL2, they also never used that approach for containers on Windows. Hence, Windows native containers are, drum roll... Windows.

Re: Tech Preview of Docker Desktop for M1

#183

Post by TheOperator » Thu, Dec 17, 2020, 3:46 AM UTC

jsjohnst wrote: post #170

swagonomixxx wrote: post #79

Earlier quoted context omitted.

I don't want to be _too_ pedantic but the M1 macbooks are significantly cheaper than their Intel counterparts. The 13 inch one is around $1300 USD. But I do agree with you. Cheaper laptops means a worse experience with almost everything.

> I don't want to be _too_ pedantic but the M1 macbooks are significantly cheaper than their Intel counterparts. The M1 MBP is about 15% cheaper, which I guess might be significant to some, but isn’t a huge selling point to me like you’re making it out to be. GP was talking about a 15/16” MBP at $3k, not the 13”.

Developers for the most part have or can look forward enough to enough income to make a tool like a mac relatively inexpensive. My biggest problem with buying them has been how absurdly bad the hardware has been for years other than the trackpad. The screensize/weight ratio, the screensize/body size ratio, the keyboards, and the performance were all well behind the competition. MacOS only running natively on bad hardware was a great reason not to use it, the fact they charged a $500+ premium on their software was really just another nail in the coffin. You had to need or fucking love MacOS to justify buying a mac.

How things change in a year or two. Pretty much only the weight/size relative to the screen size remains substandard and I expect them to improve on those fronts.

Re: Tech Preview of Docker Desktop for M1

#184

Post by sneak » Thu, Dec 17, 2020, 4:09 AM UTC

I would strongly advise anyone considering running this closed-source, proprietary software on their machine to examine the large amounts of private data it uploads to Docker Inc when it crashes before they install or run it.

I was surprised. You might be surprised, too.

I was so surprised that I decided to only ever run the open source command line docker client on my machine, and to avoid any proprietary software that comes out of Docker Inc in the future. It is absolutely not reasonable for them to upload some of the data that they do, and I no longer trust their judgement about what happens on my machine.

If they did that sort of stuff in the open source cli app, it would be patched out in minutes.

Re: Tech Preview of Docker Desktop for M1

#185

Post by m1gu3l » Thu, Dec 17, 2020, 4:16 AM UTC

sneak wrote: post #184

I would strongly advise anyone considering running this closed-source, proprietary software on their machine to examine the large amounts of private data it uploads to Docker Inc when it crashes before they install or run it. I was surprised. You might be surprised, too. I was so surprised that I decided to only ever run the open source command line docker client on my machine, and to avoid any proprietary software t…

God can’t anyone do their job without slurping massive amounts of data behind shady processes. Docker folks , care to explain this?

Re: Tech Preview of Docker Desktop for M1

#186

Post by cpuguy83 » Thu, Dec 17, 2020, 4:19 AM UTC

mbreese wrote: post #163

vocram wrote: post #145

Earlier quoted context omitted.

A Linux VM is still needed because these are Linux containers, ie. they need namespaces, cgroups, layered rootfs, etc.

Of course, but my question is how is it created... MacOS has a Hypervisor framework for creating VMs, which Docker is using. But I don’t know enough about those internals to understand how they are getting an x86 VM on an ARM host. I know it can be done with qemu emulation, but does that still need the MacOS hypervisor framework or does it run as a normal user process? These are the questions I’m trying to figure out…

The VM is an arm64 VM.

Re: Tech Preview of Docker Desktop for M1

#187

Post by ogre_codes » Thu, Dec 17, 2020, 4:20 AM UTC

fomine3 wrote: post #174

Wowfunhappy wrote: post #164

Earlier quoted context omitted.

I'd expect it to be exactly as performant as qemu's x86 emulation always is. The M1 is new, but qemu is not.

So it means plain old binary translation without hardware assist. I wonder that whether QEMU's binary translation is not optimized well nowadays because no one uses it for production (we use with VT-x/EPT or AMD equivalent).

I think QEMU is hardware emulation, not translation.

Re: Tech Preview of Docker Desktop for M1

#188

Post by cpuguy83 » Thu, Dec 17, 2020, 4:21 AM UTC

wmf wrote: post #173

mbreese wrote: post #140

Earlier quoted context omitted.

But if they are doing that, then why do they need to use the Mac Hypervisor Framework to setup the VM? That wouldn't be required if you were using qemu, would it? (How you mention it would be the simplest possible thing that would work)

Docker Desktop uses Hypervisor.framework to run ARM containers on ARM. Docker Desktop uses QEMU to run x86 containers on ARM.

Docker Desktop uses Hyperbisor.framework to run an arm vm, which runs arm containers natively, or x86 containers via qemu (in the arm VM).

Re: Tech Preview of Docker Desktop for M1

#189

Post by cpuguy83 » Thu, Dec 17, 2020, 4:25 AM UTC

YetAnotherNick wrote: post #100

birdyrooster wrote: post #94

Earlier quoted context omitted.

Apple probably uses this technology a lot for themselves and has given support to Docker to implement this quickly.

> has given support to Docker to implement this quickly Any proof? As far as I know apple, they are not that developer/open source supportive.

I happen to know a few ex-Docker folks working at Apple, along with a bunch of other k8s related talent they recently hired.

Re: Tech Preview of Docker Desktop for M1

#190

Post by skissane » Thu, Dec 17, 2020, 4:28 AM UTC

musicale wrote: post #176

ogre_codes wrote: post #162

Earlier quoted context omitted.

This whole territory is pretty much unknown right now. Whether we can have reasonably performant x86 containers is up in the air.

Yes, it's definitely "performant" if by "performant" you mean "exactly matching the well-established performance of qemu emulation" which means: slower than Rosetta2 with higher CPU/memory/power usage but still functionally correct for the most part. If by "performant" you mean "as fast as it used to run on x86 Mac hardware" than the answer is: No, it's emulation, and it's slower than Rosetta2.

> If by "performant" you mean "as fast as it used to run on x86 Mac hardware" than the answer is: No, it's emulation, and it's slower than Rosetta2.

I wonder if this would motivate someone to build an x64-to-ARM translation layer for Linux which is closer to Rosetta2 than qemu-user-static in performance?

One of the secrets of Rosetta2's performance is Apple Silicon processor extension enabling ARM code to use the x86 memory model. There is no reason in principle why some x64-to-ARM translator running on Linux on Apple Silicon could not exploit the same processor extension.

Another secret is that it predominantly does AOT translation, and only uses interpretation/JIT for x64 code generated dynamically (such as by an x64 JIT). There is no reason in principle why something on Linux couldn't do the same thing.

Perfect world scenario, Apple would open source Rosetta2 and it would be ported to Linux. Apple probably won't do that because they've invested a lot of money into it and it gives them a competitive advantage over other ARM-based platforms (such as Microsoft Surface Pro X). (I do hope I'm wrong about this though.)