Naming/Marketing Semantics

[s0ssh]

I'm opening this issue because I'm more than a little confused about the naming of this project, and having discussed with fellow technical colleagues, I know I'm not alone.

In many places in this repository, it's documented that this is not in fact a containerization framework, but rather an OCI-compatible VM orchestration framework.

A tool for creating and running Linux containers using lightweight virtual machines on a Mac. It's written in Swift, and optimized for Apple silicon.

container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. [...]

My question here is - Why name this container and market it as a novel containerization framework, when it's definitionally a misnomer even by the documentation present in this very repo? While I understand that virtualization is necessary to run Linux images on an XNU kernel that doesn't support the Linux internals used by Linux containers, I find it confusing at best that a VM orchestration framework be named container and referred to as a containerization framework.

I mean this issue to be a grounds for civil discussion and constructive criticism, and I aim for it to arrive at a reasonable conclusion.

[andrewmzhang]

I might be missing something in your question, but I don't think this tool orchestrates VMs. It uses a specific Linux VM implementation, the "lightweight Linux VM"¹, to run containers on top of. Unlike Docker on non-Linux OSes, instead of running a single VM for all containers on a host, this framework runs a "lightweight Linux VM" per container. Maybe the wording is tripping you up? "Lightweight Linux VM" appears to be referring to a very specific Linux image and not just any "lightweight" Linux VM.

Put another way, I would expect a VM orchestration framework to be able to run a Windows 10 for ARM VM, which I don't this tool is meant for.

Footnotes

1. This video explains that the "lightweight Linux VM" is stripped of many core utils, shared libs, and uses musl in place of glibc. https://developer.apple.com/videos/play/wwdc2025/346/ ↩

[s0ssh]

Hi Andrew, I respectfully disagree. Even if it does not look like traditional VM orchestration frameworks, I think it's still a misnomer to call this project a container orchestration framework. If it is, as you say, running a '"lightweight Linux VM" per container', that definitionally makes it a VM orchestration framework.

Containerization is a means by which features such as namespacing and resource groups are used to run multiple sandboxed pieces of software on one host - this is fundamentally different from what this project does, which is virtualizing each container image in its own "lightweight Linux VM". Even if it is not compatible with traditional VM images due to its architecture, it's still virtualizing each OCI image.

However, I appreciate your input and discussion with me on this issue!

[andrewmzhang]

Ah I see your point. However I'd like to point out that Docker for Mac/Windows is generally considered a container orchestration platform, even though it launches a VM (albeit a single Linux VM per Mac/Windows host).

[crosbymichael]

Let's convert this issue into a discussion.

[afbjorklund]

This tool uses container images, not containers. They are normally confused, since they are used together...

"A tool for creating and running Linux containers container images using lightweight virtual machines on a Mac."

Calling virtual machines also for "containers" is something that has been going on since (at least) Kata containers.

But it is not using single-kernel OS-level virtualization, which is what we normally mean when we say Linux containers.

---

To make it more interesting, we can now run containers (with containerd) in containers (with Containerization.framework).

For instance, we can now run Kubernetes nodes as containers (VMs) containing Kubernetes pods as containers (processes)...

https://kubernetes.io/docs/concepts/architecture/

• run kubernetes #81

This is making the term "container" rather ambiguous, and we still don't know that it is specifically Apple Container - or not.

Situation with Docker Desktop and Podman Desktop is different, they do launch containers - even if in a VM behind the curtain.

[afbjorklund]

I should also mention that it didn't work out of the box, precisely for the reason that virtual machines are not containers...

So the OS images did not contain an init system, that is needed for the node to operate. The workaround is to re-add one.

Unfortunately that means the init system on the VM (vminitd) is now fighting with the container init (systemd) over cgroups.

In order to make things work with cgroupfs, one has to replace systemd with openrc. Which is not supported in all distros.