RedTTG/reddyos-osdev

ReddyOS is a very early but already substantial hobby OS/kernel project. The README is only a sentence right now, so the repository undersells itself: the tree shows real kernel work across Limine boot integration, x86-64 assembly, CMake build setup, linker scripting, physical and virtual memory management, heap canary self-test support, GDT/IDT/IRQ setup, APIC handling, ACPI/uACPI integration, framebuffer output, syscalls, process/thread scheduling, VFS support, devfs, tarfs, and a small userspace init program. That is a lot of meaningful infrastructure for a repo created recently, and the June 2026 activity suggests the project is still moving quickly.

What stood out most is that this is not just a “prints text after boot” kernel. src/main.c has a clear bring-up sequence from memory and interrupts through ACPI, clocks, APIC, filesystem/device registration, syscall setup, scheduler initialization, and loading /bin/init. The userspace system/init/src/main.c also gives the project a visible payoff by drawing and animating through /dev/fb0, which is a good sign that the kernel/device/syscall layers are being exercised together rather than developed as isolated stubs. The Limine ISO script and Nix shell are also useful choices for OS development because they give future contributors a path toward reproducible boot testing.

The main thing holding the repo back is documentation. A maintainer or reviewer can infer a lot from run.sh, make_iso.sh, .gitmodules, and system/CMakeLists.txt, but a newcomer should not have to reverse-engineer the toolchain story. I would add a README section that explains the target architecture, required host packages, submodule setup, how to build the custom x86_64-reddyos-gcc/mlibc toolchain, how to produce the ISO, and what QEMU command is expected to show. A screenshot or short boot video would also help a lot, especially for a hobby OS where the visible milestone matters.

I would also consider adding basic CI even if it only runs formatting checks, verifies submodules, and configures the kernel build in a container with the expected tools. Full QEMU boot testing can come later, but some automated check would make the fast commit activity easier to trust. Overall, this is a promising low-level project with much more substance than its current README communicates; the next big improvement is making the build, boot, and current feature set legible to people who did not write it.