I still can’t use Containers because of a broken DNS implementation. I suppose I could manually set the DNS as I switch on and off VPN, but I don’t have to with Finch, Podman, or Docker Desktop.
macOS Container Machines
381–390 of 457 posts
Re: macOS Container Machines
#382Earlier quoted context omitted.
Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
> Back in my day you to to download a couple GB worth of cygwin You still can, and it still works exactly the same way.
It's true, but to be honest the MinGW-built stuff that ships with git for Windows has been enough since WSL took off.
Re: macOS Container Machines
#383Earlier quoted context omitted.
Containers (those popularised on Linux by Docker) are built on Linux primitives like cgroups and namespaces, so they're running directly on the same kernel, same VFS, often the same FS, etc. Their isolation properties rely on (a) all those Linux features working as expected, and (b) the container runtime setting them up properly. Depending on your threat model, that's fine, but a lot of people (including me) will say…
The surface of an OS is definitely larger than that of many hypervisors, which is e.g. why browsers often provide their own much narrower sandbox. On the other hand, in other scenarios, people trust the security boundaries of their working as expected all the time, no? This is the basis of e.g. Android app isolation (every app runs under its own Linux UID/GID), and true multi-user Unix systems trusting the OS's secur…
Different threat models. Your typical Android device (and Linux server for that matter, at home or at scale) is not usually running security-sensitive general workloads for multiple tenants in the same OS instance. :-)
Re: macOS Container Machines
#384Earlier quoted context omitted.
Very different: Linux running in a virtual machine can't bind mount into a macOS host's filesystem. So they use virtiofs.
MacOS container filesystem/IO has been bog slow preventing even some basic dev container use cases. Hopefully this will fix the issue.
It's not substantially different from previous approaches (9pfs vs. virtiofs).
My suggestion: Don't use the host filesystem from the guest at all. It'll be faster, and better isolated. It's a false convenience.
Re: macOS Container Machines
#385Earlier quoted context omitted.
Not for long!
Very unlikely to lose support for Rosetta for Linux. Maybe just Rosetta 2 for mac apps.
Oh, didn't read that part of the news. That's great. Ability to run x64 docker images seminatively was one of the big reasons I jumped to the M1 platform when it came out and I was baffled that they would remove it.
Re: macOS Container Machines
#386Handy for sure! In production though, I've moved completely to systemd isolation of apps, rather than Docker-like containers; essentially blackboxes and present a supply chain threat. There's also a DRY principle here. Verification of a host presents a much smaller surface area.
> moved completely to systemd isolation
On MacOS?
Re: macOS Container Machines
#387Anyone know why you would use this instead of QEMU+Lima+Colima+Docker/containerd? The latter works on multiple OSes, has a very large ecosystem of tools, images, documentation, and lets you replace pieces as needed
QEMU has worse performance than Apple's native virtualization framework on macOS, for one thing. That said, Lima supports the latter as well.
Yeah I was gonna say I use Colima with Apple’s virtualization framework (it’s not the default for some reason but it’s a single command line flag), and found it works better than QEMU (better performance and resolved some bugs I was running into with the Supabase docker stack)
Re: macOS Container Machines
#388Earlier quoted context omitted.
Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.
And a limited VM, for example I look at the documentation and it's not possible to share USB devices with the VM, making it perfectly useless for doing embedded development where you have to connect to the boards with USB. I will continue to use UTM for that reason...
Virtualization.framework just gained USB passthrough support in macOS 27. It might be a niche feature for containers to add, but other VM software will likely add support soon.
Re: macOS Container Machines
#389Do these containers share a common kernel? Or are they each ran in a separate VM? Edit: It's a VM per container. https://github.com/apple/container/blob/main/docs/technical-...
Isn't it wasteful? I know it's a "tiny" vm but still is a vm
Re: macOS Container Machines
#390Earlier quoted context omitted.
Which ones? BSD was tied in a lawsuit that left doubts on its future. Minix was a toy OS for university teachings. Coherent was commercial. Nothing else was there on the PC market.
386BSD and its derivatives (eg FreeBSD) weren’t really attacked by SCO like other UNIXes were. In fact SCO filed more lawsuits against Linux than they did (for example) FreeBSD. FreeBSD was also used heavily in the late 90s in ISPs and similar domains.
Those only came to be after AT&T lawsuit was cleared, and by then Linux already had enough wind behind it.
Also SCO lawsuit was more due to IBM's money than Linux.
Both a different situation than Windows NT being available a decade earlier.