cavOS is a POSIX x86_64 kernel built on Alpine packages

There is no download, and that is stated as a fact

The first FAQ entry answers the obvious question bluntly. You do not download cavOS. It is by no means mature enough for an actual release yet, so you have to compile it yourself, and the author adds that it is not as difficult as other OSes because there are only a few short commands to run. That framing sets the expectations for everything else. This is a project to read and build rather than to install and use, and the documentation is written accordingly, with the compiling guide at docs/install.md and the contribution notes at docs/contributing.md. The stated motivation is also plain: having a good time, with the low level learning as the side effect. The homepage sits at malwarepad.com, and the repository is written in C with the kernel under src/.

A monolithic kernel where clarity beats the last percent

The kernel status section describes the design in one sentence: a monolithic x86_64 kernel written in relatively simple C with a few bits of Intel assembly here and there. The stated priorities are code structure kept clean and fairly easy to understand, while avoiding too much abstraction, and the consequence is spelled out, with code quality and clarity sometimes prioritised over performance gains. That is a real design position rather than a disclaimer, and it shows in the feature list, which covers the architecture pieces in full: the GDT, IDT, ISR, I/O and local APICs, SSE, the LAPIC timer, the RTC clock and the syscall instruction, with ACPI mode using I/O APIC redirects for interrupts, PCI scanning and various PCI device drivers. The result is a kernel whose structure you can follow without first learning a framework's conventions.

The feature list is a real POSIX surface, not a toy shell

The list of what works is long enough to establish that this is more than a hello-world kernel. On the systems side there is a full network stack including TCP and DHCP with support for the Intel E1000 and Realtek RTL8139 and RTL8169 interfaces, two-way pipes, Unix domain sockets, eventfds, futexes and signals with some BSD extensions, and FAT32, Ext2 and virtual file systems for proc, sys and dev. ELF64 binary loading with dynamic linking and shared libraries is there, along with PS/2 keyboard and mouse drivers and serial port output on COM1 and COM2. The graphics side uses the BIOS or UEFI framebuffer and exposes it to userland through /dev/fb0, and there is a primitive kernel tty with 8-bit colour, some basic ANSI codes and psf1 fonts. The userspace side is musl libc with a Linux system call layer and pre-emptive multitasking.

Userspace comes from Alpine, and the author says so

The most consequential decision is that cavOS does not build its own userspace. The README states that the apk package manager from Alpine Linux and their respective repositories are used for userspace assembly, and the reasoning is given plainly: Alpine's and musl's philosophy align with the cavOS one, and there is no point in recompiling things if it is not necessary. That is why the kernel ships a Linux system call layer, with system calls that are exactly like Linux's, and the author's stated goal is to be as binary compatible with Linux as possible. The FAQ is careful to draw the line, saying the cavOS kernel does not share source code or headers with Linux, and that some header definitions are obviously present only to support the userspace. The internal structure of the kernel has little in common with Linux beyond being monolithic, and the README notes this layout may change as cavOS-specific extensions are added.

Building the image is a chain of make targets

The Makefile at the root shows the build order, and the primary target is the disk image. The disk_prepare target depends on verifytools, limine, uacpi, musl and ports, and disk_prepare in turn runs the test programs under src/software, the badtest and drawimg helpers, before the kernel Makefile under src/kernel produces the image. Each external dependency has its own target that fetches and builds it: musl runs the build script in src/libs/musl, limine runs src/bootloader/assert.sh, uACPI runs tools/kernel/uacpi.sh, and the essential ports are built by tools/userland/ports.sh. The dependency targets read like this:

# Musl libc
remusl: cleanmusl musl

cleanmusl:
	rm -rf src/libs/musl/cavos-build
	rm -rf src/libs/musl/cavos-out/include
	rm -rf src/libs/musl/cavos-out/lib

musl:
	chmod +x src/libs/musl/build.sh
	./src/libs/musl/build.sh --noreplace

The toolchain check is the part that bites: the Makefile looks for a cross compiler at ~/opt/cross/bin/x86_64-cavos-gcc and fails with a message telling you to run make tools, and it also compares the compiler's timestamp against a fixed date and refuses to continue if the toolchain is older than that, telling you to remove the directory and rebuild. The check itself is a few lines of Make:

verifytools:
ifdef TOOLCHAIN_GCC_VERSION
	@echo "$(TOOLCHAIN_GCC_VERSION)"
else
	@echo -e '\033[0;31mx86_64-cavos-gcc was not found! Please use "make tools" to compile the toolchain!\033[0m'
	@exit 1
endif
	@if [ $(GCC_ACTUAL_DATE) -lt $(GCC_CHECK_DATE) ]; then \
		echo -e '\033[0;31mThe cavOS toolchain is outdated! Please remove the ~/opt/cross/ directory and re-build it via "make tools"!\033[0m'; \
		exit 1; \

The X server is the way into the graphical side

The graphical stack is X11 rather than a bespoke compositor, and the README says cavOS uses the xorg server, also known as X11 or X.org, to render the graphical UI. To start it from the console you run a single command, which the FAQ gives as just a. The screenshots in the README show what that surface looks like in practice, with a terminal and Xorg utilities, an image viewer and a mesa demo, Thunar and MPV, the games Quake and Doom, Wikipedia in the NetSurf browser, and HexChat on a Liberta IRC with TLS. The screen content is assembled from Alpine packages, which is why a file manager, a media player, a browser and a chat client are all present at once. The X server process, the graphics driver and the widget toolkit all come from that package set rather than from cavOS.

Known rough edges the maintainer documents himself

The FAQ is unusually candid, and two entries are worth reading before you start. The first is about RAM usage. The numbers reported by tools like fastfetch or free are misleading and do not match the typical Linux counterpart, because a lot of mmap() operations are counted in other categories such as Buffers or Cached, and the author expects the issue to be fixed when features like copy-on-write are implemented. The second is the TTY. The terminal equivalent does not support many ASCII codes and is generally badly written, and while pull requests to fix it are welcome, the maintainer is focused on other things. That is an honest description of a rough edge, and it is also a fairly direct answer to the question of whether cavOS is a daily driver, which it is not.

What the project borrows and what it writes

The credits section is a good map of the architecture. Limine is the bootloader, a modern and portable multiprotocol bootloader and boot manager, uACPI is the ACPI implementation, Alpine Package Keeper is the package management solution and the source of the repositories, lwIP is a small independent implementation of the TCP/IP protocol suite, dlmalloc is Doug Lea's memory allocator, and a tiny self-contained printf implementation handles formatted output. One credit is purely cosmetic: the ASCII art for the kernel shell's fetch command was made by someone else. The project itself is licensed under GPL v3, with the licence text in the LICENSE file at the root. The top level layout, with src/, docs/, tools/, patches/ and a target/ directory, and the .vscode/ directory for editor configuration, is what you would expect from a hobby kernel kept in a single repository.

Editorial conclusion

cavOS suits a systems programmer who wants to read a complete, deliberately plain x86_64 kernel and userspace in C rather than a minimal teaching kernel, and who is prepared to build a cross toolchain and a disk image to do it. It does not suit anyone looking for a usable operating system to install, because the README states there is no download and the project is not mature enough for a release. Before starting, read docs/install.md for the build order, expect the make targets to need a cross compiler at a specific path, and note that the last push to the repository was on 2026-06-13 with no GitHub releases published.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. malwarepad/cavOS on GitHub
4. Project website
5. README