201–210 of 231 posts
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.
Earlier quoted context omitted.
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…
I was fiddling for a while on x86 emu for arm, it’s definitely possible to be faster than qemu, but it’s a very big project and unclear whether somebody will just do it in their free time.
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…
Yeah, until the developers decide to release only for Arm targets and when you search issues for x86 build, the maintainer says "just compile it yourself"... And you look into the dockerfile manifest and see that it wants to pull the whole stack of history of computing...Then you figure maybe you don't need that shiny utility in the first place and move on... It's "64 vs 32-bit" or "Ubuntu vs Arch vs Fedora binary" a…
Personal computers generally go where Windows goes. Heck, that's arguably part of why Apple left PowerPC for Intel in the first place. Apple has tremendous impact on design, form factor, and other visionary steps that the market takes. I do not deny that. Still, in terms of hardware and the development ecosystem, Microsoft simply has a lot more market inertia than does Apple.
This is nothing like 64bit vs 32bit. That was a difficult (MacOS didn't drop 32bit app support until Catalina) but obvious (unless you hate RAM) leap forward. In contrast, Apple Silicon is a leap sideways whose opportunity arose because Intel's flagship process node has had a rough few years. There may be inherent advantages to Apple Silicon as a technology, but nobody should make the unproven assumption that Apple Silicon is universally superior to any and every possible TSMC 5nm x86 chip.
Earlier quoted context omitted.
They were not available for purchase by everyone.
Other than being unavailable outside the US, I'm pretty sure everyone who ordered one received it. Apple also donated at least a few of them to OSS projects.
After reading the article, I still don't quite understand how this works. I've used multi-platform Docker containers before, and that makes sense to me. What I don't understand is how they are running x86 containers on an ARM64 VM? Docker Desktop still works by building a Linux VM and running Docker there. But the VM would be an ARM VM. So, are they running qemu in the ARM VM to emulate an x86 processor in a nested V…
Which means really, really slow.
Earlier quoted context omitted.
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 hard…
> The screensize/weight ratio, the screensize/body size ratio Based on HN comments, one of the most popular non-Apple laptops seems to be the Dell XPS. XPS: via https://downloads.dell.com/manuals/all-products/esuprt_lapto... - 15.61” - 4.14lbs - overall dimensions 14.06 x 9.27 x 0.66in or about 86in^3 Apple 16” MBP: via Apple.com - 16” screen - 4.3lbs - overall dimensions 14.09in x 9.68in x 0.64in or about 87.3in^3 —…
But I'd rather just use my desktop M1 Mini than both. It has a 27" screen and a proper keyboard (Durgod K320) attached to it. All my shit is in AWS now.
Earlier quoted context omitted.
QEMU can (slowly) emulate any architecture on any other architecture. In this case, they're using QEMU to emulate x86-64 on ARM64. No nesting or Rosetta is needed.
Why wouldn’t they use Rosetta though? I’d wager the performance of Rosetta would be better than QEMU emulation, but perhaps it’s more optimised for desktop apps
Now come on Windows! Give me a solution for that (although I rarely use it) and I’m sold or maybe I moved the goal post to requiring more than 16gb RAM again but come on everyone you can do it! edit: guys I'm talking about running Windows on a VM on a M1 macbook. Just going down the checkbox of virtualization options. Docker is one checkbox. Now want Windows and Vmware/VirtualBox/Parallels
If you mean the regular x86_64 version of Windows, forget it.
Docker Desktop uses qemu, which is the only way you can run an x86_64 OS on an arm64 machine. It can be usable for Linux kernel and command-line applications.
But for Windows, it is very likely that it will be too slow to be usable. People have tried running Windows XP on Raspberry PIs successfully, but it is very slow as expected. https://youtu.be/QQOP29yLOxQ
Earlier quoted context omitted.
Are users able to check if they are running a native arm64 container image, as opposed to an amd64 emulated one? Or that’s something you have to infer from the execution speed?
You can use manifest inspect[1] to see all supported architectures, and you should also be able to see on Docker Hub[2] as well. EDIT: If you're asking specifically if you can tell what architecture a running container is using, a simple `docker inspect CONTAINER_ID` should show it. [1] https://docs.docker.com/engine/reference/commandline/manifes... [2] https://hub.docker.com/_/node
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requestedEarlier 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…
(5) Docker Image (amd64)
^
|
(4) QEMU Binfmt (arm64 amd64 binary emulation layer)
^
|
(3) Linux VM (arm64)
^
|
(2) Hypervisor.framework (arm64, macOS native virtualization framework)
^
|
(1) Docker for Mac
This is also how multiarch[2] works (for amd64 to arm64/ppc64le/etc.) which might even be what Docker is using. In case of multiarch, the qemu-*-static binary is provided as a container running in privileged mode.
[1]: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-mi...