Vinix — A modern operating system written in V

A modern operating system in V

Features
About
FAQ
Roadmap
Sponsor development
Contact the maintainer

Dark mode

100 MB RAMusage on boot
≈1 GB of disk space after install
Official support of Apple Silicon Macs
Compatible withAlpine Linux binaries

Install on your M1 Mac

Download nightly

Explore the source

M3, M4, M5 support coming soon.

Alpha software. Vinix is under active development and is not
intended for daily or production use yet.

Run Vinix in QEMU
Install the build prerequisites, then let the launcher build and start the desktop.

Apple Silicon Macs
QEMU uses macOS hardware virtualization for the ARM64 desktop.
brew install qemu
git clone https://github.com/vlang/vinix
cd vinix
./run-desktop-aarch64.sh

Other computers
Use the x86_64 launcher. It uses KVM when available, otherwise QEMU emulation.
git clone https://github.com/vlang/vinix
cd vinix
./run-desktop-amd64.sh

Runs on Vinix

Languages & toolchains

Clang / LLVM
GCC / G++
Go
Rust
Java
Node.js / npm
Python 3
Ruby 3
V

Developer & infrastructure

Codex CLI
Claude
Git
OpenSSH
curl
nginx
GNU Make
CMake
Meson
GDB
radare2
strace
SQLite
Bash
BusyBox

pkg / APK / XBPS

Desktop & applications

Firefox ESR
Chromium
Blender
GIMP
Wine
Minecraft / Minetest
Gnumeric
GTK 3
X.org
Wayland
Hyprland
Mesa / OpenGL
Nano
Vim
Terminal
tmux
Sublime Text
File Browser

Vinix in action

Vinix desktop on an M1 MacBook Air.

Chromium

Wine apps: Calculator and Notepad.

MS Office on Vinix: an x64 Windows app runs through Wine—an Alpine Linux binary—on ARM64 hardware.

Blender.

Minecraft.

Wayland / Hyprland on Vinix.

Gnumeric on Vinix.

Sublime Text on Vinix.

radare2

Vinix desktop written from scratch in V + V UI2.

Features

Vinix uses a small fraction of a modern machine's memory and disk

RAM ON BOOT — 100 MB

DISK AFTER INSTALL — 1 GB

BOOT TO DESKTOP — SECONDS

NO GC · NO SYSTEMD · NO TELEMETRY

Speed and performance

Vinix boots to a desktop in seconds and settles at about 100 MB of RAM and 1 GB of
disk. That is the whole system, not a stripped-down mode you switch into.

The kernel has no garbage collector. It is built with -gc none and manual
memory management, so no collection pass can stop a system call, an interrupt handler,
or the compositor at a moment of its own choosing. Memory use stays flat instead of
sawtoothing while the machine stays up.

Nothing runs that you did not start. There is no systemd, no background indexer, and
nothing phoning home. The desktop draws straight to the framebuffer and composites its
own windows, with no display server underneath it, and the machine feels the same on
day ninety as it did on day one.

A sandboxed application cannot reach the filesystem outside its own directory
SANDBOX (OPTIONAL)

REST OF THE SYSTEM

/home
~/.ssh
other apps

Optional per-app sandboxing

An application can be started in a sandbox, the way apps are confined on iOS. A
sandboxed program gets its own private directory and that is all of the filesystem it
can see. Your documents, your SSH keys, other applications' data, and the rest of the
system are simply not there for it, so a bug or a bad dependency inside that program
cannot read what it was never given.

This is optional and off by default. It is something you turn on for the programs you
choose, not a wall the system puts between you and your own computer. Run the same
binary without a sandbox and it behaves like any other Unix process, with the usual
file permissions and nothing else in the way.

It is meant for the cases where it actually helps: a browser, a downloaded binary you
have not read, a build script from someone else's repository. Your own tools keep
running exactly as they do now.

Alpine Linux binaries call the Vinix kernel directly through Linux system calls
ALPINE AARCH64 BINARY

ELF
musl
chromium
blender
VINIX KERNEL

VFS
SCHEDULER
MEMORY
DRIVERS

openat
mmap
futex
ioctl
NO VM · NO CONTAINER · NO EMULATION

Full compatibility with Linux syscalls and Alpine Linux binaries

Vinix is not a Linux distribution. The kernel is written from scratch in V. But a
Linux program does not really talk to Linux, it talks to a fixed, numbered interface:
openat, mmap, clone, futex, and a
few hundred more system calls. Vinix implements that interface, plus the ELF layout
and the musl behaviour those programs expect on entry.

So an unmodified aarch64 Alpine Linux package runs here natively. There is no Linux
virtual machine, no compatibility container, and no CPU emulation in that path: the
binary executes on the bare CPU, and its system calls land in the Vinix kernel.
pkg install chromium pulls the same package Alpine ships, and it starts.

That is why Chromium, GIMP, Blender, Sublime Text, Gnumeric, and Wine already run on
Vinix: thousands of existing packages instead of a handful ported by hand.
Applications that need Linux kernel features Vinix has not implemented yet can still
fall short, and those gaps are closed as they are found.

The Apple M1 AGX GPU driver, currently in development

APPLE M1 — AGX GPU

M1–M5 GPU drivers

Apple publishes no documentation and no driver for its GPUs outside macOS, so any
other operating system that wants hardware acceleration on a Mac has to write one.
Vinix is writing its own, starting with the M1.

On M1 that means two drivers: AGX, the GPU itself, and DCP, the display controller
that owns the screen. Both are coprocessors reached over Apple's mailbox and RTKit
interfaces, with the DART IOMMU keeping the GPU's view of memory separate from the
kernel's. Above them sits a minimal DRM subsystem with GEM buffer objects,
implementing only what those two drivers need to allocate, share, and present frames,
with Mesa and OpenGL on top so applications get real acceleration instead of software
rendering.

This is the work in progress right now, and much of the rest depends on it: a
hardware-accelerated desktop, smooth video, and eventually games through Wine. M2
through M5 come after M1 is finished. Their GPUs are close enough relatives that the
same driver grows to cover them rather than starting over.

What Vinix is about

Use the screen well
No extra padding or rounded corners. More room for your work.

One way to do things
One distro, UI, package manager, init system, and binary format. No need to make constant choices. And it all just works.

Change what you need
Customize the system to work the way you want.

Themes you can choose
Pick from many themes. You can make it look like macOS Catalina or even Windows XP.

Uses few resources
Uses about 100 MB of RAM at startup and 1 GB of disk space.

Stays small
Vinix stays small and minimal. It will not get more bloated with each release.

Officially supported hardware
Vinix initially is going to support every Apple Silicon Mac (only M1 Macs for now as of Sep 10 2026).

Support for Intel Macs, back to the 2010 Mac mini, is next. So you can give an older Mac a fast, modern, fully supported OS.

The entire stack is built and tested together. No hunting for drivers or workarounds for sleep, wake, lid closing, hibernation, Wi-Fi, graphics, audio, or the other hardware basics that too often turn a Linux install into a project.

You can also already install Vinix on an amd64 machine, but the driver support won't be great. Better to run it in a VM.

Frequently asked questions

Why Vinix over macOS?

This is the main reason Vinix exists: to offer a fast, open source, minimal operating
system for MacBooks. Apple builds excellent hardware, and there was no lightweight
system built specifically for it.

macOS gets slower and more bloated with every release. The same Mac that felt instant
when you bought it feels sluggish a few updates later, and the system now takes tens of
gigabytes of disk and gigabytes of RAM before you open a single app. Releases have also
become less stable, with questionable design choices, settings that get rearranged or
removed, features nobody asked for, and more of the system tied to online accounts and
services.

Vinix goes the other way. It starts in about 100 MB of RAM and 1 GB of disk, boots in
seconds, and stays that way. The entire system is open source, so you can read any part
of it, change it, and rebuild it yourself. Nothing phones home.

There is also gaming. Vinix is going to turn your powerful Mac into a gaming machine.
Apple Silicon has the GPU for it, but the games are not there: most publishers skip
macOS entirely, and the ports that do exist get dropped. For example, Valve ended macOS support
for Counter-Strike 2. Vinix is going to support popular titles that
have no macOS version, including The Witcher 3, Counter-Strike 2, Elden Ring, Grand
Theft Auto V, Red Dead Redemption 2, Skyrim, Doom Eternal, and Hogwarts Legacy.

That is planned work rather than something you can play today. It builds on two pieces
that already run here: Wine, which runs Windows applications on Vinix, and a user-mode
x86 translation layer, which runs x86-64 binaries on ARM64 hardware. The remaining
piece is the Apple GPU driver work now in progress.

Why Vinix over Linux?

Fewer reasons here. Linux is a good system, and if it works for you there is no need to
switch.

What Vinix offers is minimalism and a system without systemd. There is one way to do
things: one distribution, one desktop, one package manager, one init system, one binary
format. Nothing to choose or configure before you can start working.

And there's the appeal of a new kernel. Vinix is not another distribution on top of
Linux, it's a kernel written from scratch and small enough that one person can
understand all of it.

Why is Vinix written in V?

Compilation is very fast. The entire kernel rebuilds in seconds, so changing something,
rebuilding, and booting it is one quick step instead of a coffee break. That keeps the
whole system enjoyable to work on.

V is also simple and readable. The language
is small enough to learn in an afternoon, the code stays easy to follow months later,
and it allows development to move quickly. That matters for an operating system built
from scratch.

Is Vinix a Linux distribution?

No. Vinix is an independently developed, Unix-like operating system with its own kernel,
drivers, process model, filesystem layer, and system calls. It targets x86-64 and ARM64;
Linux is not running underneath it. But you can run Alpine Linux binaries on Vinix.

It deliberately follows familiar Unix and Linux conventions where that makes software easier
to port. Compatibility is a practical goal, not the operating system’s foundation.

What is the technology stack?

Vinix boots with Limine, a
bootloader that loads the Vinix kernel and supplies the early memory, framebuffer, and
boot-module information. Above it is a freestanding kernel written mostly in V, with C
and a small amount of architecture-specific assembly where hardware requires it.

The original kernel core (including its physical and virtual memory managers and scheduler) was written by mintsuki, the creator of Limine. After a roughly two-year pause in development, Alexander Medvednikov became its new maintainer. Since then, Vinix got storage, networking, input, graphics,
Unix-style userspace support, and compatibility with Alpine Linux binaries.

The system image pairs that kernel with an initramfs and a
familiar command-line and development userland; native Vinix applications and its desktop
are written in V with V UI2.

What kernel architecture is it? Monolithic or a microkernel?

Monolithic. The scheduler, the physical and virtual memory managers, the virtual
filesystem, the device drivers, and the network stack all live in one kernel image and
run privileged in a single address space, calling each other directly instead of passing
messages. That is the pragmatic choice: no IPC round trip on every disk read or network
packet, and Linux-compatible behaviour stays straightforward to implement.

Monolithic does not mean big. The kernel is written mostly in V and is small enough for
one person to read through. It is a higher-half kernel loaded by Limine, preemptive and
SMP-aware, with per-CPU state, fine-grained locking, and awareness of NUMA and
multi-socket memory topology. Every process gets its own address space, and user code
runs unprivileged and enters the kernel through Linux-compatible system calls.

There are no loadable kernel modules. Drivers are compiled into the kernel image, and
because a full kernel rebuild takes seconds in V, rebuilding and rebooting is the fast
path anyway.

How do drivers work?

A driver is an ordinary V module inside the kernel tree with an initialise()
function that kernel startup calls in order. Hardware is discovered per platform: a PCI
bus scan plus ACPI on x86-64, and a device tree handed over by firmware on Apple Silicon.

Once initialised, a driver publishes its node under /dev through devtmpfs and
implements the kernel’s Resource interface: read, write, ioctl, mmap, and the
rest. Regular files implement that same interface, so the VFS, the read and write system
calls, polling, and memory mapping all work over devices without a separate path.
Interrupts arrive through the platform’s controller, AIC on Apple Silicon, GIC on generic
ARM64, APIC on x86-64, and the handler wakes whichever threads were waiting on that event.

What exists today: NVMe, AHCI, and ATA storage with GPT partitions and ext2; console, pty,
serial, keyboard, mouse, HD Audio, and framebuffer devices; the virtio family (block,
network, GPU, input) for virtual machines; and, on Apple Silicon, ANS storage, the DART
IOMMU, mailbox and RTKit for the coprocessors, SMC, the SPI keyboard and touchpad, Type-C,
and Wi-Fi. Graphics goes through a minimal DRM subsystem with GEM buffer objects that
implements only what the AGX GPU and DCP display controller drivers actually need.

Is Vinix deterministic?

Not in the real-time sense. Vinix is not a real-time operating system and makes no
latency guarantee. The scheduler is preemptive and has exactly one policy: a thread gets
a timeslice weighted by its nice value, and the kernel arms a one-shot timer for it.
Asking for SCHED_FIFO or SCHED_RR fails with
EINVAL instead of being accepted and then quietly scheduled like everything
else, because answering yes there would be a lie. Hard real-time work needs a different
system.

Where it is predictable, deliberately so: the kernel has no garbage collector. It is
built with -gc none and manual memory management, so no collection pass can
stop a system call, an interrupt handler, or the compositor at a moment of its own
choosing. Memory use stays flat and bounded rather than sawtoothed, which is a large part
of why the system still feels the same after it has been running for a while.

The same applies to what runs at all. One distribution, one desktop, one init system, one
package manager, and a fixed boot sequence mean two machines booting the same image bring
up the same services in the same order. There is no accumulated local configuration
deciding how your computer behaves today.

Kernel subsystems are tested the same way, with seeded pseudo-random sequences rather
than live randomness: the page cache runs hundreds of deterministic randomized
operations, and drivers such as Apple’s ANS storage and SPI keyboard are fed thousands of
deterministic mutated packets, so a failure reproduces exactly instead of once in a
while. Build output is a separate question: images come from a single release build
script, but byte-for-byte reproducible images are not something Vinix claims yet.

How can Vinix run Alpine Linux binaries?

On ARM64, Vinix can use selected Alpine Linux aarch64/musl packages. They run natively on
the same CPU architecture: there is no Linux virtual machine and no CPU emulation in that
path. Vinix supplies the supported Linux-facing ELF, musl, and system-call behaviour the
programs expect.

The pkg tool resolves a package and its runtime dependencies from Alpine’s
repositories, stages them in the Vinix image, and skips Alpine maintainer scripts that
assume Alpine’s own init system. This is targeted compatibility, so supported and tested
applications work directly while unimplemented Linux kernel features can still limit others.

Does Vinix have a package manager or an app store?

Yes. Vinix ships with pkg, a command-line package manager that installs
software from Alpine Linux’s aarch64 repositories, so there are thousands of existing
packages to draw on instead of a small handful ported by hand.

pkg update refreshes the indexes, pkg search finds a package,
and pkg install pulls it in along with its dependencies. There is also
pkg remove, pkg upgrade, pkg list, and
pkg info. Package names are Alpine’s own, and Vinix currently tracks Alpine
3.21 for aarch64. Chromium, GIMP, Blender, Gnumeric, Sublime Text, GTK, and the usual
command-line tools all install this way, though applications that need Linux kernel
features Vinix has not implemented yet can still fall short.

There is no graphical app store yet. pkg is a terminal tool for now.

What desktop environment and window manager does Vinix use?

The default is Vinix’s own native desktop: a V + V UI2 desktop environment and window
manager in one. It reads input and draws directly to the framebuffer, compositing its own
windows without a display server beneath it.

Vinix also supports X.org with an X window manager, plus an optional ARM64 Wayland session
using Hyprland. Those are compatibility and experimentation paths; the native Vinix desktop
remains the normal session.

Project roadmap

The foundation reaches from a native toolchain and familiar userland to
desktops on both major architectures.

Available today

mlibc, bash, GCC/G++, V, and nano
Storage drivers and ext2
Networking
V-UI
X.org and an X window manager
Wayland with Hyprland on aarch64

Intel VT-x hypervisor

On the horizon

Intel HD graphics driver
M1–M5 GPU drivers

Support Vinix
Sponsor the development.

Help make Vinix a better operating system. Your sponsorship gives the project
more time and resources for development.

Sponsor on GitHub

Get in touch
Contact the maintainer.

For questions, feedback, or collaboration, email
[email protected].

Email the maintainer

Vinix is open source and built by its community.

Vinix is presented as a modern operating system developed from scratch in the V language, designed to offer an extremely minimal, fast, and highly controllable experience, particularly targeting Apple Silicon Macs. The core philosophy of Vinix centers on efficiency and direct system control, aiming to counteract the perceived bloat and sluggishness of existing systems, especially macOS.

The system is designed to be inherently lean, consuming only about 100 megabytes of RAM upon boot and 1 gigabyte of disk space after installation, leading to a desktop that boots to full functionality in seconds. A key technical feature is the absence of traditional operating system overhead, as Vinix features no garbage collector, no systemd, and no telemetry, ensuring memory usage remains flat and bounded rather than sawtoothing, which contributes to system consistency. The desktop environment draws directly to the framebuffer and composites its own windows without an underlying display server.

Vinix achieves broad compatibility by implementing a fixed, numbered interface of system calls (such as openat, mmap, and futex) and the ELF layout expected by Linux and Alpine Linux binaries. This allows unmodified packages from Alpine Linux, like Chromium, Blender, GIMP, and Wine applications, to run natively on the Vinix kernel without requiring emulation or virtual machines. Vinix is explicitly not a Linux distribution but adheres to Unix and Linux conventions to facilitate software portability rather than basing its entire structure on Linux compatibility.

The kernel architecture of Vinix is monolithic, where all critical components, including the scheduler, memory managers, device drivers, and the network stack, reside in a single address space. This design choice prioritizes efficiency by eliminating inter-process communication overhead associated with microkernels. Drivers are integrated directly into the kernel as modules, initializing through a strict sequence, and hardware discovery is handled via platform-specific methods, such as an ACPI device tree on Apple Silicon.

Regarding hardware acceleration, Vinix is developing its own drivers for Apple Silicon GPUs, starting with the M1, which involves handling the AGX GPU and the display controller (DCP). This work is focused on implementing the necessary subsystems for hardware-accelerated graphics and smooth video output, which are foundational for potential gaming capabilities.

To manage applications securely, Vinix offers optional per-application sandboxing, confining a program to its own private directory and restricting its access to the filesystem, mimicking security models found in systems like iOS. This optional feature is meant to be opted into by the user where it is beneficial, such as for inspecting downloaded binaries or browser operations.

The system employs a custom package management utility called pkg, which draws upon Alpine Linux aarch64 repositories to install software and its dependencies. This package manager handles dependency resolution and staging within the Vinix image, allowing the system to leverage thousands of existing packages instead of maintaining a limited set of ported ones.

In terms of user experience, Vinix defaults to its own native desktop environment and window manager based on V and V UI2. However, it maintains flexibility, offering compatibility paths through support for X.org and an optional Wayland session utilizing Hyprland for ARM64 architectures. The development roadmap aims to expand support across both Intel and Apple Silicon platforms, with future work focusing on further hardware driver development and expanded application support, including support for popular titles like those from Valve. The system is ultimately built on the principle of simplicity, where one unified distribution, desktop, package manager, and initialization system converge into a single, predictable operational environment.