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.sh100 MB RAM
usage on boot
≈1 GB of disk
space after install
Official support of
Apple Silicon Macs
Compatible with
Alpine Linux binaries
M3, M4, M5 support coming soon.
Install the build prerequisites, then let the launcher build and start the desktop.
Vinix in action
Features
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.
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.
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.
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
No extra padding or rounded corners. More room for your work.
One distro, UI, package manager, init system, and binary format. No need to make constant choices. And it all just works.
Customize the system to work the way you want.
Pick from many themes. You can make it look like macOS Catalina or even Windows XP.
Uses about 100 MB of RAM at startup and 1 GB of disk space.
Vinix stays small and minimal. It will not get more bloated with each release.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Support Vinix
Help make Vinix a better operating system. Your sponsorship gives the project more time and resources for development.