Vinix — A modern operating system written in V

100 MB RAMusage on boot ≈1 GB of disk space after install Official support of Apple Silicon Macs Compatible withAlpine Linux binaries 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 Vinix in action 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.

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.

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.

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.