Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tech Preview of Docker Desktop for M1

docker.com

Post reply on HN
Print view View original

161–170 of 231 posts

Re: Tech Preview of Docker Desktop for M1

#161

Post by Wowfunhappy »

jillesvangurp wrote: post #134
ogre_codes wrote: post #49

This bit about Multi-platform development is most interesting to me. > Many developers are going to experience multi-platform development for the first time with the M1 Macs. This is one of the key areas where Docker shines. Docker has had support for multi-platform images for a long time, meaning that you can build and run both x86 and ARM images on Desktop today. If multi platform images work, a lot of the concerns…

X86 support is a big one for me. I deal with a lot of customer projects; typically with some kind of dockerized stuff as part of their tool chain. So, being able to run those things as is, is important for me. And I don't see those build systems being updated any time soon to be able to accommodate some Apple only hardware.

Note, Docker will run x86 containers via qemu, so you can still use them. They'll just be slower.

Re: Tech Preview of Docker Desktop for M1

#162

Post by ogre_codes »

Wowfunhappy wrote: post #161
jillesvangurp wrote: post #134

Earlier quoted context omitted.

X86 support is a big one for me. I deal with a lot of customer projects; typically with some kind of dockerized stuff as part of their tool chain. So, being able to run those things as is, is important for me. And I don't see those build systems being updated any time soon to be able to accommodate some Apple only hardware.

Note, Docker will run x86 containers via qemu, so you can still use them. They'll just be slower.

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

Re: Tech Preview of Docker Desktop for M1

#163

Post by mbreese »

vocram wrote: post #145
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)

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...

Re: Tech Preview of Docker Desktop for M1

#164

Post by Wowfunhappy »

ogre_codes wrote: post #162
Wowfunhappy wrote: post #161

Earlier quoted context omitted.

Note, Docker will run x86 containers via qemu, so you can still use them. They'll just be slower.

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

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

Re: Tech Preview of Docker Desktop for M1

#165

Post by Demiurge »

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

Re: Tech Preview of Docker Desktop for M1

#166

Post by microtherion »

ogre_codes wrote: post #56
jbirer wrote: post #44

Absolute disaster, this platform. The opacity and lack of early availability for development made for a really ugly adoption experience. I feel that people should not encourage this and vote with their money in the DevOps / Dev sector to discourage other companies from pulling the same stunt.

The expectation that a ~2 month old platform is going to perfectly replicate the functionality of 30+ year old platforms is absurd. Compared to the PPC->Intel transition, this is a cakewalk. Compared to Microsoft's (multiple attempts) to migrate to ARM, this is a true triumph.

It's pretty good for a hardware platform. But I guess if you're a frontend developer, 2 months is enough for a new JavaScript framework to come out, become ubiquitous, get superseded, and get abandoned as legacy code.

Re: Tech Preview of Docker Desktop for M1

#167

Post by geofft »

stephenr wrote: post #159
haswell wrote: post #127

Earlier quoted context omitted.

You've lost me. This sentence does not explain how Docker, or containers work. It explains one aspect/limitation related to the execution of code in a container, but does not foster a deeper understanding of container architecture for the uninformed reader, and is actually somewhat misleading considering Docker's use of a VM behind the scenes in some situations (in which case the "host running the container" is techn…

> 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 Docker is either Python (generally portable), Java (generally portable), or Go (built-in cross-compilation support). It's absolutely sensible to do local dev on a Mac and then deploy on Linux in prod - it's perfectly sensible to do so without Docker in the picture, and plenty of people do just that.

So, maybe all the people you're yelling at understand the concept you think they don't, and they're okay with it.

Two, it's not at all true that to run Linux binaries on non-Linux, you need a Linux VM. WSL1 is an existence proof against this on Windows, as is the Linuxulator on FreeBSD, as are LX-branded zones on SmartOS. Linux itself has a "personality" mechanism for running code from non-Linux UNIXes. You could do the same thing on macOS, and teach the kernel to handle a good-enough subset of the Linux system call interface - it would be far less work than adding containerization (namespacing and resource isolation) in the first place, so I'm not sure why you're so hung up about this.

Re: Tech Preview of Docker Desktop for M1

#168

Post by geofft »

stephenr wrote: post #38
haswell wrote: post #25

Earlier quoted context omitted.

Docker obscures the implementation details. Part of this is by design: don't worry about the hard stuff, because Docker does it for you. It's completely unsurprising that many folks haven't spent the time to dive into the internals. In many cases, because they don't need to. Such is the nature of abstraction and higher level frameworks.

Just because CorporationX says “don’t worry about it we got you bruh” doesn’t mean technologists - people who actively work with technology and write software - should be excused for just throwing up their hands and saying “it’s just ducking magic I don’t know how it works”. I’m not talking about understanding it to the level of being able to contribute a patch to the project. I’m talking about understanding that con…

> “no you can’t just take a SQLServer query and run it on anything that vaguely knows “SQL”.

Not with that attitude you can't. https://aws.amazon.com/blogs/opensource/want-more-postgresql...

The world depends on people who don't take "no you can't" for an answer.

Re: Tech Preview of Docker Desktop for M1

#169

Post by olliej »

mbreese wrote: post #143
wmf wrote: post #136

Earlier quoted context omitted.

Rosetta is limited to running Darwin/x86-64 user processes on Darwin/ARM64 but Docker needs to run Linux/x86-64 containers/processes on a Linux/x86-64 kernel on a Darwin/ARM64 host.

I think the parent comment meant -- why not use Rosetta to run an x86 qemu process? Then the architecture emulation (translation?) would be done by Rosetta (potentially faster), as opposed to software emulation by qemu. Now, this might not work, as I'm not sure Rosetta covers all of the x86 instructions/settings that qemu would need, so you might be stuck with ARM64 qemu emulating x86 anyway.

From the point of view of rosetta, qemu's JIT would be completely opaque, and so would end up suffering severe performance penalties due to it having to translate code from what would appear to be an aggressively self modifying JIT.

That said, assuming Qemu runs entirely in user space I would expect it to be able to run under rosetta, and am genuinely curious if it does, and what the perf is - as I said, I would expect it to be much slower than arm64 qemu emulating x86_64, but I'm curious as to how much.

Re: Tech Preview of Docker Desktop for M1

#170

Post by jsjohnst »

swagonomixxx wrote: post #79
itake wrote: post #67

Earlier quoted context omitted.

cost? if im dropping $3k on a machine, I don't really wanna pay another $2k in cloud fees to do the dev work. you might say, "well get a cheaper computer!" but I find that cheaper computers have worse screens, battery life, and overall quality.

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”.

Post reply on HN