4 ms·

This is part of the bigger Macpine project, which to me is much more interesting than LXD: https://github.com/beringresearch/macpine https://github.com/beringre

• _cenw 4y ago
  It feels like lima and colima are much more mature. Being unable to remap the SSH port (or other ports) alone makes this a non-starter.
  • VWWHFSfQ 4y ago
    I ended up just getting a System 76 Meerkat computer for doing anything locally with LXC/Docker. Linux emulation in Windows or macOS is unbearably bad if you really need to do serious work.
    • LoganDark 4y ago
      Even systemd will run in Docker on macOS. Can you clarify what makes macOS unacceptable for emulating Linux?
      • cmeacham98 4y ago
        Using a VM for Docker gives you the worst of both worlds. You get all the downsides of a VM (persistent wasted RAM/disk space, awful disk IO performance, etc) AND all the downsides of containers (difficult to introspect when your minimal image has no shell, janky networking, etc). On recent M1/M2 Macs you take the additional pain (and thus performance hit) of translation to x86 (because that's almost certainly what your containers are in.
        • inkyoto 4y ago
          > On recent M1/M2 Macs you take the additional pain (and thus performance hit) of translation to x86 (because that's almost certainly what your containers are in. What on Earth are you talking about? arm64 Docker images predate the emergence of M1, and their number has proliferated in the last two years like there was no tomorrow. Here is an excerpt from my own tiny, non-representative collection of Docker images I have had to deal with lately: $ (for i in `docker images | tail -n +2 | awk '{ printf "%s:%s\n", $1, $2 }'`; do docker inspect $i | jq '.[].Architecture'; done) | grep -c amd64 7 $ (for i in `docker images | tail -n +2 | awk '{ printf "%s:%s\n", $1, $2 }'`; do docker inspect $i | jq '.[].Architecture'; done) | grep -c arm64 23 Most of the 23 arm64 Docker images is pretty obscure stuff, with one or two manually rebuilt for the arm64 architecture. Yet, I have downloaded all of my obscure images directly from the Docker Hub – not traded them for a pinch of spice from a shady Docker image dealer at a drench inducing corner of the dark web. All of the arm64 images run at the native speed, locally and in the cloud. The only reason I store x86 (i.e. «amd64») images locally is my laptop being a transient transit point between their source and the destination. I would have rebuilt them as well but the build process is either broken for each of them or is too convoluted to justify spending a time trying to fix it.
          • nxrabl 4y ago
            But then it's not the same container, right? Either you'd need to switch your whole cloud infrastructure to run on ARM (which I see is possible now, and I'd be curious to hear if people have done that successfully) or we're back to "works on my machine ^W architecture".
            • inkyoto 4y ago
              > Either you'd need to switch your whole cloud infrastructure to run on ARM … Nope, the whole cloud infrastructure does not need to switch. Since containers are fully self-contained, self-sufficient and isolated from each other, they can coexist peacefully and run alongside each other in a mixed setup in AWS ECS/Fargate clusters. And they do. AWS Lambda also supports aarch64, and the degree of isolation for the lambdas is even higher and they can also run out of a x86 or an aarch64 Docker image (if required), and 30-40% cheaper with performance loss incurred for the workloads I am interested in.
  • MuffinFlavored 4y ago
    At the end of the day, are they all just wrappers around QEMU? The aarch64 -> x86_64 virtualization performance is pretty rough. Like, to the point where compiling a small hobbyist Rust project that needs to be deployed on Linux x86_64 in the cloud (cheap VPS)... you might as well just build it in the cloud and not locally on Mac host because it takes 10 minutes instead of 10 seconds