What Is Vinix? The V-Language OS That Runs Docker

304

What Is Vinix?

Vinix is a pre-alpha, Unix-like operating system with a monolithic kernel written mostly in the V programming language. It is not a Linux distribution: there is no Linux kernel underneath. Instead, Vinix implements the Linux system-call interface, ELF loading, and musl libc behavior well enough to run unmodified Alpine Linux packages natively, which is how a from-scratch V kernel ended up running stock Docker containers. It is GPL-2.0 at github.com/vlang/vinix, and as of October 2026 it boots to a desktop in seconds on roughly 50 MB of RAM with about 1 GB of disk after install.

After a roughly two-year pause, the project came back hard with more than 1,100 commits in September 2026 alone. The fall headlines were real milestones: stock Docker, QEMU booting Vinix inside Vinix, and DOOM in the guest. All of it is pre-alpha by the README’s own wording, but unlike most hobby-OS showpieces, Vinix runs real Linux binaries today.

Who Builds Vinix and Why Does It Exist?

Vinix started in March 2021 as the work of mintsuki, the developer who also created the Limine bootloader Vinix still boots through. Development then stalled for close to two years. The comeback is what earned my sustained attention: Alexander Medvednikov, the creator of the V language itself, picked up maintenance. Over 1,100 commits landed in September 2026 alone, and when I checked the repo on October 14, 2026, it had around 2,600 GitHub stars.

The mission is narrow and honest, and it is the pitch I find most credible: a fast, minimal OS that feels at home on MacBooks, starting with the base Apple M1. No systemd, no telemetry, and V was chosen because it compiles fast. For why people keep starting independent operating systems at all, my colleague Liam’s Void Linux explainer covers a different survival strategy for the same indie-OS problem (https://www.fosslinux.com/161587/what-is-void-linux-beginners-guide.htm).

Monolithic Like Linux: What Kind of Kernel Vinix Actually Is

The most repeated misconception about Vinix is that it is a microkernel. It is not. The official FAQ answers “Monolithic or a microkernel?” with one word: “Monolithic.” Scheduler, memory managers, virtual filesystem, drivers, and network stack all live in one kernel image in a single address space. No loadable modules; drivers are compiled in. The kernel is higher-half, preemptive, and SMP-aware: the same structural bet Linux made, written in V.

That choice is why Docker progress was possible on this timeline: containers lean on namespaces, cgroups, and overlayfs, which are far less awkward inside a monolithic kernel than across a microkernel message boundary. For syscall-layer background, my colleague Liam’s Linux kernel beginner’s guide is useful context (https://www.fosslinux.com/160598/what-is-the-linux-kernel-beginners-guide.htm). Here is how Vinix compares.

How Vinix Runs Linux Software Without Being Linux

Compatibility here is not emulation and not a container of Linux. Vinix implements the Linux ABI where it matters: system calls with Linux-compatible numbers and semantics (openat, mmap, clone, futex, and hundreds more), ELF as the executable format, and musl behavior, since Alpine links against musl. Point the Vinix package manager at Alpine’s aarch64 repository and the packages just run. No VM, no container, no instruction translation in that path, which is why I do not file this under emulation.

One scope detail matters more than anything else here. The Alpine parity, pkg tracking Alpine 3.21, the Docker stack, the QEMU-in-Vinix demo, and the Minecraft Java result are all arm64 territory, on the Apple Silicon side of the project. The amd64 ISO I booted gives you a native Vinix desktop and X.org userland, not the Alpine pkg experience. If you follow the try-it section later, do not expect pkg install chromium to behave like it would on an M1. Where a kernel feature a package depends on does not exist yet, the package fails loudly: pkg skips Alpine’s maintainer scripts, so nothing papers over the gaps. I will take that loud failure over a silent half-install any day.

Docker on Vinix: What Works Today

On September 28, 2026, the official Vinix blog published the story of Docker landing on the OS, and the headline hides the real achievement. The engine was never patched: what ran was the stock Alpine stack, dockerd 27.3.1, containerd 2.0, and runc 1.2, all unmodified, on arm64 (as of that September 28, 2026 official blog post). Alpine may bump those versions later.

The actual work happened in the kernel. For stock runc to stand up a container in good conscience, Vinix had to grow a long list of facilities first.

• Namespaces: mount, UTS, IPC, network, PID, cgroup, user, and time namespaces, reachable through clone, unshare, and setns, with /proc/<pid>/ns entries to join them.
• Per-namespace mount trees: bind, move, and remount operations, plus chroot and pivot_root, with read-only mounts actually honored.
• Cgroup v2: mounted at /sys/fs/cgroup, with cpu.max, pids.max, memory.max, and cgroup.freeze enforced, not merely present.
• Overlay filesystem: overlay2 as the Docker default storage driver. The blog’s worked example shrank a python:3.12-alpine image layer from 122 MB to 53 MB.
• Security plumbing: seccomp BPF running Docker’s default profile, plus capabilities support, sealed memfds, openat2 resolve flags, and blocking FIFO opens.

With that in place, the tested images read like a normal server workload: Ubuntu, Debian, Node, Python, Go, nginx, PostgreSQL, Redis, MariaDB, and RabbitMQ all ran, plus a 100-container test loop. What still does not work, per that same post, is Docker bridge networking and its iptables rules. Containers run; container networks as you know them are next.

QEMU on Vinix: Booting Vinix Inside Vinix

The same blog post documented another first: QEMU 9.1.2, the stock Alpine qemu-system-aarch64 package, running inside Vinix and booting a second Vinix guest. The chain runs macOS Hypervisor.framework on an M1, host QEMU, the first Vinix, guest QEMU under TCG software emulation, and a second Vinix on top. Two levels deep, all unmodified upstream QEMU. The blog is explicit that this path uses TCG; there is no arm64 hardware acceleration yet, and QEMU needed a W^X opt-in because its JIT wants writable-executable memory.

One honest caveat: I did not capture that nested demo live. The official blog did, and I am attributing it to them. What I captured is the host-side toolchain, because the same QEMU you run to try Vinix powers that party trick later.

fosslinux@ubuntu:~$ qemu-system-x86_64 --version
QEMU emulator version 10.2.1 (Debian 1:10.2.1+ds-1ubuntu3.2)
Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers

I also tried the arm64 ISO on my x86 test VM under TCG, and it stalled at the EDK2 UEFI firmware banner long past the point where the amd64 ISO had reached the desktop. I file that failure as informative rather than broken: the pkg, Docker, and nested-QEMU stories live on real ARM64 hardware for a reason. On amd64, Vinix is experimenting with its own Intel VT-x hypervisor interface at /dev/hypervisor; note it is Vinix-specific, not /dev/kvm.

What Games Actually Run on Vinix Today?

Games are where pre-alpha operating systems usually embarrass themselves, and Vinix’s late-2026 status deserves a straight scorecard rather than marketing screenshots. The desktop I booted shipped a DOOM icon, which tells you what the project considers its demo of record.

The Steam and Dota 2 screenshots in the project gallery are real, and they prove nothing about playability. A hero pickable at quarter-second-to-minutes frame times demos the translation stack; it is not a game you should plan an evening around.

How to Try Vinix Yourself in a QEMU VM

To verify any of this yourself, the amd64 ISO boots on ordinary PCs under QEMU, and the official README documents the path. My test rig was an Ubuntu VM running QEMU 10.2.1; the blocks below are real captures from that session plus the README’s own documented invocation.

Download the Official ISO

Get the ISO only from the project’s GitHub releases page. This is not a formality: distro.watch has flagged multiple lookalike GitHub repositories squatting on “vinix” and “VinixOS” names that are forks or copies. Official source only: github.com/vlang/vinix/releases. The latest tag as of this writing is iso-2026-10-12-3, about 1 GB for amd64. Verify what you downloaded before you boot it.

fosslinux@ubuntu:~$ ls -l /tmp/vinix-amd64.iso
-rw-r--r-- 1 fosslinux fosslinux 1057193984 Oct 12 12:06 /tmp/vinix-amd64.iso
fosslinux@ubuntu:~$ sha256sum /tmp/vinix-amd64.iso
403facdde44afcccd6407bbbefb29352bfbc8861100db94d531120c5f254321b  /tmp/vinix-amd64.iso

That size and digest match the GitHub API asset for tag iso-2026-10-12-3 exactly. Do the same check against the release’s SHA256SUMS file for whatever tag is current when you read this.

Create the Disk and Boot

The README’s recommended invocation assumes KVM. Check first whether your host has it; inside my nested VMware test VM it did not, so every amd64 capture here ran under TCG. TCG works, it is just slower. Create an empty qcow2 disk (the installer wants a blank target; 16 GB recommended), then boot. The qemu-system-x86_64 line is the documented README command, shown without output; my own launch added -accel tcg and a monitor socket, but the shape is the same.

fosslinux@ubuntu:~$ ls -l /dev/kvm
ls: cannot access '/dev/kvm': No such file or directory
fosslinux@ubuntu:~$ qemu-img create -f qcow2 vinix-amd64.qcow2 16G
fosslinux@ubuntu:~$ qemu-system-x86_64 -machine q35 -accel kvm -cpu host -m 4096 -smp 2 -cdrom vinix-amd64.iso -drive file=vinix-amd64.qcow2,format=qcow2 -nic user,model=e1000

Give the VM at least 4 GB of RAM; 8 GB is more comfortable if you plan to open Firefox.

First Boot and Install

On first boot against an empty disk, the installer puts itself onto the target device (my session watched it install onto a 16 GB virtual disk), then drops you into a “Create your user” screen before the desktop loads. The default shell in Terminal is zsh, not bash. Here is what the guest reported, transcribed from my own capture.

~ uname -a
Vinix vinix 0.1.0 Vinix 0.1.0 amd64 x86_64 Vinix
~ cat /etc/os-release
NAME="Vinix"
ID=vinix
VERSION_ID="0.1.0"
PRETTY_NAME="Vinix 0.1.0"

The desktop is Vinix’s own: a native V UI2 compositor drawing windows straight to the framebuffer, with no display server underneath. X.org plus a window manager is also available, and experimental Wayland/Hyprland exists on aarch64.

Vinix vs Linux: Should You Make the Switch?

Straight answer: nobody should switch to Vinix as a daily driver today, and the project would be the first to tell you so. The README says it is pre-alpha software not meant for daily or production usage. That is also my verdict, and it does not mean you should ignore it. Here is who should do what with it right now.

• If you are a VM tinkerer or a curious reader: try the amd64 ISO in QEMU this weekend. It costs one qcow2 file, boots in seconds, and I can tell you from my own QEMU session that watching a V-composited desktop come up on 50 MB of RAM is a genuine experience.
• If you are a kernel or OS hacker: pay attention and probably contribute. A monolithic kernel in V with a real Linux ABI target, V’s creator as maintainer, and more than 1,100 commits in September 2026 alone is one of the liveliest independent kernels anywhere. Issue triage, drivers, and syscall coverage are approachable entry points.
• If you own a base Apple M1 and like living on the edge: real-hardware support officially targets the base M1 as of September 10, 2026; M3, M4, and M5 are listed as coming soon, with Intel Macs after that. Keep it on a spare machine, not your only laptop.
• If you are a gamer: do not switch. DOOM and a few demos run; Steam and Dota 2 are arm64 proof-of-concepts; the AAA list is planned work waiting on in-development M1 GPU drivers.
• If you want daily-driver reliability: stay on Linux. Narrow hardware support, no Docker bridge networking yet, and pre-alpha instability are disqualifying. If independent-but-stable is your itch, my colleague Liam’s FOSSLinux guide covers the Void Linux path (https://www.fosslinux.com/161587/what-is-void-linux-beginners-guide.htm).

Frequently Asked Questions About Vinix

Is Vinix a Linux distribution? No. Vinix ships its own V kernel booted through Limine. It implements the Linux system-call interface, ELF, and musl behavior well enough to run unmodified Alpine aarch64 packages, but there is no Linux kernel code underneath.

Is Vinix a microkernel? No, and this is the internet’s favorite mistake about it. The official FAQ says the kernel is monolithic: scheduler, memory managers, filesystem, drivers, and network stack in one kernel image, single address space, no loadable modules.

Can it run Docker today? On arm64, yes: stock Alpine dockerd 27.3.1, containerd 2.0, and runc 1.2 ran unmodified as of the September 28, 2026 official blog post, with overlay2 storage and cgroup v2 enforcement. Bridge networking and iptables do not work yet, and the amd64 ISO is not where this stack lives today.

Can it run games? Some, with heavy asterisks. DOOM, the DOOM 3 demo at around 13 FPS, the Gothic II demo via OpenGothic, and Minecraft Java in interpreter mode all run. Steam and Dota 2 are arm64 proof-of-concepts under QEMU user-mode translation; AAA titles are planned work blocked on in-development M1 GPU drivers.

Is it daily-driver ready? No. The README calls it pre-alpha, real hardware support is base M1 only as of September 2026, and the amd64 driver surface is narrow (think Intel e1000 and VirtIO networking, IDE/SATA/VirtIO disks). Treat it as the fascinating VM weekend project it is.

The Bottom Line on Vinix

Vinix is a pre-alpha OS that is real in the ways that count. It has a monolithic V kernel, not a microkernel, despite what you have read. It runs unmodified Alpine aarch64 packages through genuine Linux ABI work, which is how stock Docker landed on September 28, 2026 without a single engine patch. It boots a nested Vinix under QEMU and runs DOOM on the desktop, all on a system that boots in about 50 MB of RAM. I would not daily-drive it, and neither should you, but I would absolutely boot the official ISO in a VM this weekend. I came away from my own amd64 boot impressed rather than converted. The GPU-driver work and the container networking gap are the two things I will be watching next.