81–90 of 281 posts
Earlier quoted context omitted.
On ARM in general or with Apple Silicon? The problem with Apple is that processor doesn't supports virtualization mode yet AFAIK
Docker Desktop does not work on Apple Silicon. The M1 processor does support virtualization; just wait for Docker to finish their port.
Perhaps is time to stop virtualizing to run containerized software! Someone said WebAssembly? :P
The net impact of this is not particularly high. I always write my apps so that they can run on the local machine, and just have my CI system put them in Docker images for deployment. But, that does require some effort, and some language ecosystems or applications make this nearly impossible (relying on details like case-insensitive filenames, OS quirks, etc.)... so people just develop inside a container to work around that. (I would never tolerate it, but it can work OK for things like PHP where your edits take effect in the running container without having to rebuild anything.)
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…
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 familiar if there is any usable high performance x86_64->arm translation available for linux.
Docker w/ arm images: needs some work to be able to work on mac/arm virtualization, but it's coming.
Docker w/ arm linux kernel + x86 userland images: Any translation solution would be found within the linux guestOS, not macOS. I don't know if any candidates exist. Maybe qemu?
Docker w/ full x86 image (incl. kernel): I don't think this is possible?
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?
Games are mostly C++, based on my experience with C++ codebases I'd say there's about zero chance that a game could be (easily) recompiled and made to work on ARM.
And games won't be ported anyway because it's too much work for too little sales, even if a developer really wanted to make it work they'd need a $2000 new mac to be able to compile/test in the first place.
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?
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…
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?
>>> Does anybody know how Steam handles the new macs? Games are mostly C++, based on my experience with C++ codebases I'd say there's about zero chance that a game could be (easily) recompiled and made to work on ARM. And games won't be ported anyway because it's too much work for too little sales, even if a developer really wanted to make it work they'd need a $2000 new mac to be able to compile/test in the first pl…
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…
That could be something doing dynarec like box86, which is mindboggingly the only way to run (x86) Zoom on a arm7hf Linux atop a Raspberry Pi 4 (I tried it on a Pi3B: it works but it’s way too slow)
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.
I used to be fairly laissez-faire about it but now I really think it should be legally required for at least some level of freedom for the end users to be supported (technologically rather than as in customer service) by big tech companies selling hardware
Perhaps is time to stop virtualizing to run containerized software! Someone said WebAssembly? :P
Here we go... Boot your container host in the browser! https://copy.sh/v86/?profile=archlinux