The Linux VM host and guest components are all custom, as well as the daemon that manages machines. It currently uses LXC as the runtime but that's being replaced as well. For containers we run a standard Docker engine inside a special machine.
Can you share more details? OrbStack has always supported inotify/fanotify (Linux fs watching APIs) on bind mounts and most people use watchers with no issues. Happy to look into whatever you're running into: [email protected]
That's my bad, I used the example alpine commands and the official alpine doesn't have init. It's supported if you build an image with systemd installed
Yep! Still refining it but isolated machines now have fine-grained settings for filesystem mounts, network isolation, SSH agent forwarding, and CPU/memory/disk limits
Curious if you've tried OrbStack? There's always more work to do (test workloads appreciated!) but we've put a lot of effort into optimizing for small files and other common developer workloads in OrbStack's customized filesystem sharing protocol (not standard virtiofs).
(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers.
Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.
I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
This is supposed to be possible on macOS, but it's basically completely broken (just doesn't work) due to a bug. Apple is aware of it but unfortunately hasn't said much more.
Obviously that limits the options, but I'll still be taking one last shot at using creative workarounds to tackle the memory problem in OrbStack (another containers-on-macOS product).
Totally fair! There are definitely still limitations.
Support for "isolated" machines that don't have bind mounts is planned (https://github.com/orbstack/orbstack/issues/169). This is actually mostly implemented internally, but I'm not exposing it until a few remaining security gaps are plugged or it would just give a false sense of security.
If you meant binding servers to specific interface IPs, it might be possible one day but it's very challenging to implement as all of the host's IPs need to be assigned to an interface in the guest and managed accordingly. If you meant connecting machines directly to your LAN, it'll be supported eventually but it's low priority due to unavoidable compatibility issues. https://github.com/orbstack/orbstack/issues/342
The free plan for personal use should be here to stay. What's not set in stone yet is whether there will be a Pro plan for more advanced features, and if so, what said advanced features would be (likely cloud services / Kubernetes). But I'd expect the core Docker and Linux machines functionality to stay free.
There's currently no support for changing the kernel version. I think it may not be feasible to support many versions because a lot of OrbStack's improvements are very closely tied to the kernel, and maintaining the patches for multiple versions wouldn't be worth the work. Outside of regression testing, it's rare that anything breaks and in the event that such changes occur upstream, I try to hold off on updating until they're fixed.
Are you mainly interested in 5.15/6.1 LTS or other specific versions? Having an alternate LTS kernel (for a total of two options) might be a possibility in the (long term) future.