# Vinix: an operating system written in V that boots Alpine binaries

> A pre-alpha OS that skips toolchain bootstrapping entirely, pulls a pinned minirootfs instead, and ships bootable amd64 and arm64 desktop images with Hyprland, Firefox and a C toolchain inside.

**vlang/vinix** — Vinix is an effort to write a modern, fast, and useful operating system in the V programming language

- Repository: https://github.com/vlang/vinix
- Website: https://vlang.io
- Stars: 2,598 · Forks: 152
- Language: V
- License: GPL-2.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/vlang-vinix

## The build skips toolchain bootstrapping entirely

Most hobby operating systems begin the same way: build a cross assembler, then a C library, then a compiler, then hope the thing boots. Vinix refuses that sequence, and the README is explicit about what replaces it. The build downloads Alpine's pinned minirootfs, builds the kernel directly with the host compiler, and assembles a UEFI ISO. Nothing is bootstrapped from source, which means there is no binutils, no GCC and no mlibc toolchain to build first.

The command itself is two lines, and the architecture is a make variable rather than a separate target:

```bash
make all
# Or build the ARM64 image instead of the default AMD64 image:
make ARCHITECTURE=aarch64 all
```

One environment variable decides whether the guest gets a C toolchain. Setting `VINIX_ALPINE_DEVTOOLS=1` stages Alpine's prebuilt C and C++ toolchain into the image, which matters if you intend to compile inside Vinix rather than only run things in it.

The host prerequisites are ordinary: GNU make, findutils, curl, git, file, xz, rsync, xorriso, qemu for testing, Python 3, Clang with LLVM and LLD, and a current V compiler. The README gives per-distro install lines for Ubuntu and Debian, Arch, Red Hat derivatives and Void, which is the right level of detail for a project whose contributors are spread across Linux distributions.

## Downloading a bootable image instead of building one

Each release publishes a desktop ISO per architecture, linked from the README as `vinix-amd64.iso` for x86-64 PCs and VMs under either BIOS or UEFI, and `vinix-arm64.iso` for arm64 VMs under UEFI, specifically QEMU and VirtualBox on Apple Silicon Macs. Older and nightly images live on the releases page.

The QEMU invocation for amd64 is a single line:

```sh
qemu-system-x86_64 -machine q35 -accel kvm -cpu host -m 4096 -smp 2 -cdrom vinix-amd64.iso
```

The `-accel kvm -cpu host` pair is a Linux instruction; on an Intel Mac you use `-accel hvf` instead, which the release notes spell out. The arm64 line is longer because it needs an explicit UEFI firmware blob, a virtio-scsi CD-ROM chain and framebuffer devices:

```sh
qemu-system-aarch64 -machine virt -accel hvf -cpu host -m 4096 -smp 4 \
    -bios "$(brew --prefix qemu)/share/qemu/edk2-aarch64-code.fd" \
    -device virtio-scsi-pci -device scsi-cd,drive=cd \
    -drive if=none,id=cd,media=cdrom,file=vinix-arm64.iso \
    -device ramfb -device qemu-xhci -device usb-kbd -device usb-tablet
```

The 4096 MB of memory is not a rounding error. The README explains that Vinix loads its entire root filesystem into a ramdisk, which it does to make booting on real hardware easier, and the release notes add that nothing is written to disk, so a reboot returns you to a clean image. That also explains the file sizes in the release table: the amd64 ISO is 388.1 MiB while the arm64 ISO is 1.3 GiB, a difference that comes from how much userland each architecture ships rather than from the kernel.

In VirtualBox the README tells you to create a VM of type Other/Unknown (64-bit) or Other/Unknown (ARM 64-bit) with 4096 MB and no hard disk, or to let `./run-iso-virtualbox.sh` create one. It also notes that VirtualBox only runs guests matching the host architecture.

## What the roadmap marks as finished, and the one item that is not

The roadmap is a checklist, and the checked boxes are more informative than the prose. Alpine Linux and musl userland are done, as are bash, zsh with Oh My Zsh, gcc and g++, V, nano, storage drivers and ext2. On the display side there is X.org, an X window manager, networking, and Wayland with Hyprland on aarch64. Below that sit three features that would each be a project on their own for most hobby kernels: an Intel VT-x hypervisor with its own document at `docs/hypervisor.md`, NUMA and multi-socket memory topology at `docs/numa.md`, and real-time scheduling with SCHED_FIFO, SCHED_RR and SCHED_DEADLINE at `docs/realtime.md`. V-UI 2 completes the list.

Exactly one item is unchecked: an Intel HD graphics driver for a Linux port. That single gap explains a lot of the project's character. Everything else on the list is either kernel work or a userspace stack, and every one of them can be exercised through QEMU or through one of the framebuffer paths. Graphics on real Intel silicon is the piece that needs actual hardware to develop against, so it is the piece that has not landed.

The stated goals in the README match that shape. Modern 64-bit amd and arm architectures, modern CPU features and multi-core computing are explicit targets, as is good source-level compatibility with Linux to make porting programs over easy. It lists running on Apple Silicon Macbooks, only M1 for now, and being a usable OS that runs on real hardware rather than only in emulators. The last item on the list is having fun, which is an honest framing for a GPL-2.0 project at 2,352 stars with 145 forks and 50 open issues.

## The aggregate arm64 image and its package build scripts

The repository tree is the clearest argument that this is more than a bootable kernel. It contains around forty `build-*.sh` scripts, each owning one piece of the guest: `build-python-aarch64.sh`, `build-ruby-aarch64.sh`, `build-go-aarch64.sh`, `build-firefox-aarch64.sh`, `build-hyprland-aarch64.sh`, `build-x11-aarch64.sh`, `build-chromium-aarch64.sh`, `build-blender-native-aarch64.sh`, `build-libreoffice-aarch64.sh`, `build-java-aarch64.sh`, `build-minecraft-aarch64.sh`, `build-wine-aarch64.sh` and `build-steam-aarch64.sh`, plus infrastructure like `build-qemu-ovmf-aarch64.sh`, `build-limine-aarch64.sh`, `build-asahi-aarch64.sh` and `build-x86-translation-aarch64.sh`. There is a `GNUmakefile` at the root rather than a plain Makefile, and an `AGENTS.md`.

One script ties a large set of these together. Running `./build-all-aarch64.sh` produces `build-support/init-aarch64/initramfs-desktop.tar`, and the README lists what ends up inside: Python, Ruby, Go, the current pinned V compiler, network and native developer tools, X11, Firefox, Hyprland, x86 translation, Codex and Claude Code, on top of the native Vinix desktop. Java, Minecraft and Wine are deliberately left out of that default image so they can be installed on demand with `pkg`. The image is what `./run-desktop-aarch64.sh --no-desktop` boots.

Two details in that paragraph are worth pausing on. The aggregate builder rebuilds every owned layer and refuses to publish a partial image, with `--reuse-layers` available to validate and reassemble existing outputs during image work. That is a reproducibility decision rather than a convenience. And Asahi Mesa plus the native Blender backend need their own, mutually different ARM64 Linux build environments, which is the clearest admission in the README that cross-building an ARM64 Linux userspace is not a solved problem.

## Zsh, the desktop shells, and verifying a guest build

Both Alpine userland images include Zsh and a pinned, local Oh My Zsh installation at `/root/.oh-my-zsh`, and Vinix boots into a Zsh login shell. The native desktop Terminal and Hyprland's Foot terminal also default to Zsh, and the root `.zshrc` loads the bundled `robbyrussell` theme without needing guest network access.

The README ships a smoke test for exactly this, which is the kind of thing most projects leave to the reader:

```sh
/root/zsh-smoke.sh
```

The amd64 desktop is newer than the arm64 one, described as framebuffer-native with a build and QEMU launcher matching the aarch64 workflow. After checking out `ui2`, the path is a clone into `third_party/ui2` plus the runner:

```sh
git clone https://github.com/vlang/ui2 third_party/ui2
./run-desktop-amd64.sh
```

For local development a sibling `../ui2` checkout is picked up automatically, and `VINIX_UI2_SOURCE` overrides it. The runner stages Alpine's prebuilt musl development packages, compiles `vinix-desktop` with Clang and produces `vinix-desktop-amd64.iso`, whose init starts the desktop directly. It uses KVM when available and falls back to QEMU TCG, with `--no-build`, `--monitor` and `--mem=MB` as the documented flags.

Taken together, this is a project that has done the unglamorous parts of an operating system seriously: a smoke test in the guest, layered image builds that refuse partial output, documented accelerator fallbacks, and per-distro prerequisite lists. What it has not done is ship a stable system.

## Where the README stops and the docs directory begins

The README is unusually candid about its own status, which is the first thing to read. There is a bolded note that Vinix is still pre-alpha software not meant for daily or production usage. The repository is not archived and was last pushed on 2026-09-28, with the iso-2026-09-24 release published two days earlier, so this is an actively moving project rather than an abandoned experiment. Current commits plus an explicit pre-alpha warning is the honest summary.

Beyond the README, three documents get their own files and are worth knowing exist because they cover the least conventional features: `docs/hypervisor.md` for the Intel VT-x hypervisor, `docs/numa.md` for NUMA and multi-socket memory topology, and `docs/realtime.md` for SCHED_FIFO, SCHED_RR and SCHED_DEADLINE scheduling. A real-time scheduler with documented semantics and a hypervisor guest implementation are two features hobby kernels usually claim and never finish, so their presence in a checked roadmap box is the strongest signal in the README.

What the README does not settle is what the release cadence means for stability, whether the arm64 ISO boots on any Apple Silicon machine newer than M1 given the explicit M1-only note, and how much of the desktop is usable without network access. It also does not explain what the `.codex-gnumeric-session`, `.codex-patterns.py` and `.codex-wine32-init` files at the repository root do, which suggests the agent-assisted build tooling is documented somewhere other than the README. For a first look, download the ISO for your architecture and give it four gigabytes. For a second look, run `make all` and read what it stages.

## Conclusion

Vinix's actual engineering decision is the one the README puts second: do not bootstrap a toolchain. It downloads a pinned Alpine minirootfs and compiles the kernel with the host compiler, so there is no binutils, GCC or mlibc stage to wait for, and on arm64 the guest runs unmodified Alpine binaries. That is what makes an OS in V credible as a running system rather than a paper design, and it is why the repository tree carries around forty per-package build scripts. The limits are just as clear: the README labels it pre-alpha and not for daily or production use, Intel HD graphics driver is the single unchecked roadmap item, and a boot needs at least 4 GiB because the whole root filesystem lives in a ramdisk. Start with a released ISO and the QEMU line from the README before cloning anything.

## FAQ

### Is Vinix an operating system or an investment product?

Vinix here is the V language project at vlang/vinix, an operating system written in V and licensed GPL-2.0. It has nothing to do with Vindex, the investment product those search results refer to. The README describes it as pre-alpha software not meant for daily or production usage.

### Why do the Vinix ISO files need so much memory and disk space?

Vinix loads its entire root filesystem into a ramdisk, which the README says makes booting on real hardware easier. That is why at least 4 GiB of VM memory is requested and why the arm64 ISO reaches 1.3 GiB against 388.1 MiB for amd64. Nothing is written to disk, so a reboot returns to a clean image.

### Do I need to build binutils and GCC to compile Vinix?

No. The build downloads Alpine's pinned minirootfs, compiles the kernel with the host compiler and assembles a UEFI ISO, with nothing bootstrapped from source. On the host you need Clang with LLVM and LLD, a current V compiler, GNU make, xorriso and rsync instead.

### Can Vinix run ordinary Linux programs?

The README states a goal of good source-level compatibility with Linux, and says that on arm64 Vinix runs Alpine binaries on top of an Alpine and musl userland. Both Alpine userland images ship gcc and g++, bash, zsh and nano, and the aggregate arm64 image adds Python, Ruby, Go, Firefox and Hyprland.

## Sources

- [License: GPL-2.0](https://github.com/vlang/vinix/blob/master/LICENSE)
- [Project website](https://vlang.io)
- [README](https://github.com/vlang/vinix/blob/master/README.md)
- [Releases](https://github.com/vlang/vinix/releases)
- [vlang/vinix on GitHub](https://github.com/vlang/vinix)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vlang-vinix