cix
The case for Cix
Because infrastructure can expose Linux mechanisms directly without accumulating an orchestration stack between the operator and the machine.
The premise
Namespaces isolate processes. Cgroups govern resources. OverlayFS layers filesystems. Rtnetlink configures the network. Device nodes connect workloads to hardware. Cix builds a coherent operating system around those mechanisms instead of replacing their semantics with an opaque control layer.
The host exists to boot, expose hardware, run the control plane, and support containers. Workloads carry the functionality. A read-only squashfs root and A/B update model keep live mutation out of the host upgrade path.
Inspect the host architecture →Cix’s package system connects recipes, verified inputs, builds, packages, immutable images, artefacts, and rolling delivery. It can use its own container and recipe machinery to rebuild Cix and the kernel on-box.
Read the build guide ↗cixd alone reaches the runtime and host primitives. The CLI and dashboard are clients of the same REST contract. Automation does not depend on reproducing private UI behaviour.
Disks, physical interfaces, GPUs, USB and PCI devices, CPU, and memory become visible, assignable resources instead of implicit properties hidden behind “the host.”
Follow the resource path →Clear boundaries
Not a Kubernetes replacement.It is a systems distribution with its own operating model, not a drop-in implementation of another platform.
Not merely a small distro.Size supports the architecture; it is not the entire proposition.
Not a virtual-machine platform.Cix containers use Linux namespaces and cgroups. Device grants do not create a hypervisor isolation boundary.
Not abstraction-free.Cix keeps abstractions that make necessary complexity more legible and rejects those that only obscure causality.