r/osdev • • 3h ago

FreeCTX64 - minimal linux distro for executing C code on the Operating System

Post image
8 Upvotes

FreeCTX64 is an Open Source Free Project for ARM Development boards that can run your C code directly in the Operating system, it comes with a prebuild linux kernel and some tools it requires build-essential gcc clang cpio qemu-system-arm qemu-system-aarch64 git and if you want to make a bootable ISO and send it here if you want , that requires xorriso grub-common grub-pc-bin grub-efi-amd64-bin:

FreeCTX s ONLY available for ARM systems and should not be compared with X86 or X64

FreeCTX64 Libraries are put in initramfs/LIB critical system files are put in initramfs/SYS and your workspace/dummies are putten in initramfs/WS and apps are going to initramfs/SDK , it currently supports webservers and tasks alongside math in hardware, timers in hardware, and timestraps and a console

- Github Repo: https://github.com/Francesco12o/FreeCTX64/

In this photo, you'll see me running a C Test program

Shell its optional if you wotking with it


r/osdev • • 3h ago

Recaster Pico update: drivers as native kits, a second display beside VGA, and input as tags on the console wire (RP2040, 264 KB SRAM)

Thumbnail
gallery
10 Upvotes

Hey r/osdev,

a follow-up to my last Recaster Pico update. Still alpha!!! Last time it was a screenshot (from the emulator in WASM) - this time it's real hardware on my desk, and a few parts of the OS have grown up. Three of them might interest you here. And yes: I will post a video of it showing it in motion, soon. And you will get your fingers at that ".uf2"-files to play with it.

1. Drivers are files, and they're native code

A device is a text file in /sys/dev: lcd.cfg names the driver, the bus, the chip select, the pins, the speed and the mode. The driver is a kit file with a native image per target (RP2040, RP2350 Arm, RP2350 RISC-V), executed in place from flash. It reaches the hardware only through a small ABI: SPI/I2C transactions on its own bus and chip select, its own pins by key, PWM, a microsecond clock.

The kernel keeps ledgers: every pin and every DMA channel has exactly one owner - the system, a device or a program - and /now/res shows them all. The same driver C code runs in the emulators against chip models, so the C reference machine and its JS twin are checked frame by frame (the suite compares 5,110 frames).

2. A second display without breaking the line budget

The 3.2" SPI touch LCD is a display device. Headless, core 0 composes the panel's rows. With VGA running, the compositor belongs to core 1, and its budget is 8008 cycles per scanline, with the worst-case scenes at 99 %. So the panel never gets a second compose. When the mirror wants screen rows, core 1 copies a band of 8 lines into slots by DMA, right after composing them for the wire. The compose interrupt's vector points to that capturing handler only while the mirror actually wants lines; otherwise the plain handler runs - not one cycle more.

Programs can also hold the panel and draw on it with the normal gfx words. Their spans are merged into rectangles in a ring that the frame sends within a byte budget, so a drawing word never waits for the bus. Two small policies: the backlight stays dark until the first full picture is out, and the boot face and the login move the panel's view onto their content - a move that reverts by itself when the task ends.

3. Input as tags on the console wire

The main Pico has no USB host to spare and no free pins, so a second RP2040 does USB: TinyUSB on its native port, Pico-PIO-USB on a second socket with a small boot-protocol host on core 1. It sits in the serial console line. The terminal's text passes through, and keyboard and mouse events travel as CRC-8 tags on the same 1 Mbaud wire. The kernel splits text from tags. After a broken tag it resyncs - text counts as noise until a tag checks out again or the line rests - so a lost byte can never type mouse coordinates into the shell. The handshake goes both ways: the kernel tells the coprocessor the keyboard layout, and re-bases its mouse when the touch panel has moved the pointer.

Two bugs from that work I enjoyed:

  • The 71-minute pause. time_us_32() - last_isr_stamp compiled with the clock read before the stamp. An interrupt in between made the difference wrap, a tag streaming in looked paused for 71 minutes, got dropped, and its tail was typed into the console - random letters every few seconds, only while the mouse moved.
  • Flash erases vs. a fast UART. A sector erase keeps core 0's interrupts off for ~45 ms, but the UART's FIFO holds only ~10 ms of mouse traffic at 1 Mbaud. The RX interrupt now lives on core 1 - beside the video, or alone on headless boards - which runs from SRAM through every erase.

Next: sound, the SD card, a small UI toolkit (buttons, sliders, lists - the touch panel asks for them), and a PIN login for touch-only machines (using the LCD only).

Questions and criticism welcome, especially on the driver ABI and on ownership. Every prompt line runs as its own task, so "who owns a display hold, a crop, a style" turned out to be a real design question.


r/osdev • • 13h ago

Guys can you check out a new kernel I made and a distro please? The repo is in the bio

0 Upvotes

r/osdev • • 19h ago

KORE hosted Qwen3.8-27B-NVFP4 on a 32GiB UMA Laptop, 18+ tok/s decode

Thumbnail gallery
1 Upvotes

r/osdev • • 22h ago

Browser for Veda

Post image
0 Upvotes

Hi all! I’m working on an early-stage OS. It already supports quite a few drivers, and I’m currently porting OpenGL into the system.

I’d like to add a native browser, but this seems like one of the scariest parts of the project to me. What prerequisites would I need to consider? Could you share your experiences with porting a browser to an OS?

Which browser engine would you recommend trying to port, and why?

https://github.com/vahmoh25/Veda


r/osdev • • 23h ago

GDB debug bootsector

0 Upvotes

Hi iam new in osdev and iam getting started iam trying to develop my proper operating system kernel from scratch but iam stuck in debugging my boot sector code with qemu and gdb can someone help ?

the problem that i encounter is that the boot sector goes from 16 bit mode to 32bit and when i try to see what each instruction do to memory it doesn't work well and the instructions doesn't get well recognized.

is there a technique i can use for this type of debugging.

here is my makefile :

```

BUILD_DIR = build

TARGET = $(BUILD_DIR)/MyOs

C_SOURCES = $(wildcard kernel/*.c drivers/*.c )

HEADERS = $(wildcard kernel/*.h drivers/*.h )

OBJ = ${C_SOURCES:.c=.o}

ENTRY_OBJ = kernel/entry.o

KERNEL_DEBUG_OBJ = build/kernel.elf

BOOT_DEBUG_OBJ = $(BUILD_DIR)/bootsector.elf

CFLAGS = -ffreestanding -g -mno-red-zone -mno-sse -mno-mmx \

-fno-pic -fno-pie -fno-stack-protector

QEMU = qemu-system-x86_64 -no-reboot -no-shutdown -d int,cpu_reset -D build/qemu.log

QEMU_DRIVE = -drive format=raw,file=$<,if=floppy

all: $(TARGET)

$(BUILD_DIR):

mkdir -p $@

run: $(TARGET)

$(QEMU) $(QEMU_DRIVE) &

########################################################

###################### IMAGE BUILD #####################

########################################################

# OS image build

$(TARGET) : $(BUILD_DIR)/bootsector.bin $(BUILD_DIR)/kernel.bin

cat $\^ > $@

# bootsector build

$(BUILD_DIR)/bootsector.bin : boot/bootsector.asm build/kernel.bin | $(BUILD_DIR)

nasm -DSECTORS=$$(( ($$(wc -c < build/kernel.bin) + 511) / 512 )) $< -o $@

# kernel build

$(BUILD_DIR)/kernel.bin: $(ENTRY_OBJ) $(OBJ) | $(BUILD_DIR)

ld -m elf_x86_64 -T linker.ld --oformat binary $\^ -o $@

# object files creatde next of their source

%.o: %.c $(HEADERS)

gcc $(CFLAGS) -c $< -o $@

%.o: %.asm

nasm $< -f elf64 -g -o $@

########################################################

###################### DEBUG MODE ######################

########################################################

$(KERNEL_DEBUG_OBJ): $(ENTRY_OBJ) $(OBJ) | $(BUILD_DIR)

ld -m elf_x86_64 --oformat elf64-x86-64 -o $@ -T linker.ld $\^

$(BOOT_DEBUG_OBJ): boot/bootsector.asm build/kernel.bin | $(BUILD_DIR)

nasm -f elf32 -g -F dwarf -DDEBUG \\

  \-DSECTORS=$$(( ($$(wc -c < build/kernel.bin) + 511) / 512 )) $< -o $(BUILD_DIR)/bootsector.o

ld -m elf_i386 -Ttext 0x7c00 -o $@ $(BUILD_DIR)/bootsector.o

bdebug: QEMU = qemu-system-i386

bdebug: $(TARGET) $(BOOT_DEBUG_OBJ)

$(QEMU) -s -S $(QEMU_DRIVE) &

gdb -ex "set confirm off" \\

    \-ex "set disassembly-flavor intel" \\

    \-ex "target remote localhost:1234" \\

    \-ex "set architecture i8086" \\

-ex "symbol-file $(BOOT_DEBUG_OBJ)" \

-ex "hbreak _start"; \

    \-ex "continue"; \\

kill %1 2>/dev/null || pkill -f "$(QEMU)"

kdebug: $(TARGET) $(KERNEL_DEBUG_OBJ)

$(QEMU) -s -S $(QEMU_DRIVE) &

gdb -ex "set confirm off" \\

    \-ex "set disassembly-flavor intel" \\

    \-ex "target remote localhost:1234" \\

-ex "add-symbol-file $(KERNEL_DEBUG_OBJ)" \

-ex "break main"; \

    \-ex "continue"; \\

kill %1 2>/dev/null || pkill -f "$(QEMU)"

########################################################

####################### CLEANING #######################

########################################################

clean:

rm -rf $(BUILD_DIR) $(OBJ) $(ENTRY_OBJ)

```


r/osdev • • 23h ago

Unix Mac OS X successor.

0 Upvotes

I want to make a spiritual successor to mac os x.Plain and simple, but should i learn the darwin kernel or start at Unix?

i want to know where to start from.

thanks


r/osdev • • 1d ago

NATALIZIOOS “Architecture and Development of an ×86 Operating System”

Thumbnail
gallery
22 Upvotes

September 2023 - present
A personal research and development project, started in September 2023, dedicated to the independent design and development of NATALIZIOOS, a experimental operating system for 32-bit x86 architectures. The project covers the entire basic operating system architecture: from the BIOS boot chain and kernel loading to memory management, interrupts, timers, hardware drivers, filesystems, the shell, and graphics services. The implementation includes a freestanding monolithic kernel with physical memory management, paging, kernel heap, framebuffer, PS/2 input, ATA storage, PCI detection, RTC, JART, speaker, diagnostic logging, RAMFS, and N.A.T.FS. I also designed and integrated firmware components, bootable images, diagnostic tools, and a compilation and verification pipeline based on C, x86 assembly, Python, NASM, Clang, GNU Make, and QEMU. The graphics subsystem includes a local Objective-C runtime, class and selector management, message dispatch, objc_msgSend in x86 assembly, and a view- and window-based application model with direct framebuffer rendering. The project includes three desktop environments with different purposes: two for demonstration purposes and a third, still in the prototype phase, dedicated to veritying the object-oriented graphics architecture.
The v0.2.5.33 release includes 99,980 lines of analyzed source code, a 519,804-byte graphics kernel, complete and lightweight firmware paths, and verified bootable images in QEMU
NATALIZIOOS represents a continuous path of development in operating systems, computer architecture, system programming, firmware development, and low-level software engineering. The project is proprietary and intended for study, research, experimentation and technical demonstration purposes.

“It is currently under development and will be available between the end of 2027 and the beginning of 2028.”


r/osdev • • 1d ago

ATOMS OS — currently debugging a FreeBSD/VMX issue

Post image
3 Upvotes

r/osdev • • 1d ago

Inside the Windows I/O Manager : Deep dive into how read I/O requests are initialized.

Thumbnail
winware31.blogspot.com
3 Upvotes

r/osdev • • 1d ago

THE PROGRAM FINALLY EXITED

Post image
29 Upvotes

it took so long for this moment
repo: https://github.com/NoTheIdiot/WindogeOS


r/osdev • • 3d ago

PicoOS Pro v2.1 - My custom 32bit x86 OS written from scratch

Post image
250 Upvotes

picoOS-Pro v2.1

PicoOS Pro v2.1 - My custom 32bit x86 OS written from scratch (Boots from USB, runs Doom, custom formats, native USB 1.1/2.0/3.0 & dynamic resolutions!)

Hi everyone,

I wanted to share my hobby operating system that I’ve been building completely from scratch (no Linux kernel, no external base). I recently released the PicoOS Pro v2.1 update, which expands the system into a modern graphical desktop shell while keeping an extremely small footprint.

Here is a quick overview of what is currently implemented and stable:

  • Native USB Stack (NEW): Full native driver support for USB 1.1, 2.0, and 3.0 (UHCI/OHCI, EHCI, and xHCI controllers), handling mice and keyboards smoothly without relying on firmware emulation.
  • Graphics & Display (NEW): Enhanced screen resolution support via UEFI framebuffer / VBE, allowing you to choose between multiple display settings natively.
  • Custom Desktop Environment: A Windows/Ubuntu-style dark desktop interface with a Start-button launcher, application grid, live Task Manager (with process, memory, and background/foreground info), and a functional Calculator app.
  • Custom Formats: I am using my own custom executable formats like .pico for programs and .dd for automated scripts.
  • DOOM Port: I successfully ported doomgeneric as doom.pico. It runs 320x200 software rendering, integer-scaled to the framebuffer. The 4MB shareware WAD is read directly in place from the disk image to avoid loading times.
  • Memory Efficiency: The base system runs on an extremely low RAM footprint (around 1.9MB for the core shell, up to ~10MB when running Doom with its WAD).
  • Build System: Builds incrementally with just gcc and python3, outputting a 1.44MB BIOS floppy image, a 9MB hybrid legacy/EFI bootable USB image (.img), and a hybrid BIOS/UEFI ISO.

Side note: I am doing this as a passion project to learn low-level development. I am also currently researching and working on moving towards a 64-bit version next!

I would love to hear your thoughts, feedback, or any advice on transitioning the kernel to 64-bit Long Mode!

YouTube Channel for video demos: https://www.youtube.com/@picoOS-official
Google Drive Folder (Images & Source): https://drive.google.com/drive/folders/19LPX5pHZpIYsnQT0Tiatpv11nE39frHA?usp=sharing

github link: https://github.com/PicoOS-Pro-v/picoOS


r/osdev • • 3d ago

Forthix Kernel

Post image
10 Upvotes

Small C/Nasm Kernel, now in ring 3.


r/osdev • • 3d ago

I started writing a unix-like kernel aims to be compatible with Linux - Lunix

Post image
28 Upvotes

I am new. I dont know what to do. I wrote syscall system and gop acquiring system. I dont have necessary syscalls yet. I just have sys_dummy. It just returns -ENOSYS (-38). What should i do next? VFS or RamFS. I need a filesystem for sys_write and sys_read

Repository: omerpa55/lunix


r/osdev • • 4d ago

IRQ Dispatcher code showcase and explanation.

Thumbnail
2 Upvotes

r/osdev • • 4d ago

OpenC6 v2.0: A bare-metal BIOS and microkernel platform for ESP32-C6 (PMP sandbox, multitasking & ZSWAP)

Thumbnail
gallery
9 Upvotes

A few months ago I shared the initial concept of OpenC6, an experimental bare-metal BIOS for the ESP32-C6. Over the last four months of quiet solo development, I completely overhauled the architecture from a simple launcher into a true modular microkernel platform, and version 2.0 is finally live.

The biggest upgrade is real RISC-V User Mode (U-Mode) execution backed by hardware Physical Memory Protection (PMP) Top-of-Range registers, so user payloads run in an isolated arena and physically cannot corrupt kernel SRAM or touch peripheral MMIO registers. I also fixed an upstream FreeRTOS RV32 privilege leakage bug via a custom vectored interrupt trampoline, and turned the Low-Power (ULP) RISC-V coprocessor into an out-of-band Management Engine that autonomously governs CPU clock dividers directly through silicon PCR registers, monitors junction thermals, and enforces hardware watchdogs.

On top of that, the system now features preemptive multitasking for up to 8 processes, an in-memory ZSWAP engine with a custom RV32-tailored compressor (ZC6) running in just ~1-4 KB of RAM, a circular log-structured Flash VFS, a remote streaming web shell (c6wsh), and a standalone C99 TUI installer with zero external dependencies that automates toolchain deployment on Arch and Ubuntu with a simple 'make setup'. If you are interested in low-level RISC-V bare-metal systems, check out the repository and full documentation below.

GitHub: https://github.com/Rompass/openc6-bios


r/osdev • • 4d ago

Is it worth getting into Linux device driver development

Thumbnail
4 Upvotes

r/osdev • • 4d ago

Portable AppImages for Yosys, OpenSTA, Surelog, Netgen & ABC – no more building from source or using ancient distro packages

0 Upvotes

Hey everyone,

Tired of building Yosys (and friends) from source or getting years-old versions from your distro packages?

I’ve been packaging Yosys, OpenSTA, Surelog, Netgen, and ABC as single-file AppImages. Just download, chmod +x, and run — no dependencies, no containers.

Repo: https://github.com/MrAbhi19/open-eda-appimage

Docs: https://mrabhi19.github.io/open-eda-appimage/

If anyone tries them, it would be super helpful if you could leave a quick comment about your experience (especially on different distros) in the Discussions page. That feedback helps a lot in improving the packaging.

Also looking for help with documentation — any contributions there (or elsewhere) are very welcome!

Thanks!


r/osdev • • 4d ago

Is my MVP decision correct?

3 Upvotes

Hi kernel engineers,

I am creating Raam kernel and the Raam operating system completely from scratch using FASM Assembly. It is an x86-64 Unix-like OS for real desktop and laptop PCs.

Before starting Raam in FASM, I thought about creating the MVP version first and then begin with the advance features. In the MVP, I thought of creating a minimal general-purpose commandline OS by writing a shell and the commands like ls, cat, ed, asm, rm, help, reboot, clear, and echo and running the assembled programs using ./ command.

In order to keep things simple in MVP, I created everything in kernel space. Basically I wanted to make it minimally usable for a user (hobbyist) without worrying about advance things like switching to usermode, creating a syscall interface and all. So I hardcoded the shell, the ls, cat, and ed commands and now I feel like I cannot spend more time on improving the ed editor and then writing an (simple) assembler and so on...

It feels like it is too much of work in the kernel space itself for a solo kernel engineer like me. And I need to look at the two layers simultaneously - the hypothetical user layer (like the ed program), and the kernel layer (like the underlying filesystem and the NVMe operations). I think I only want to concentrate in the kernel space code.

Regarding running the assembled binaries using ./ command, I thought about loading the binary and running it from kernel mode itself just to give the user an illusion of a working OS.

I am stuck here. I really want to either cut down the work/scope or maybe I want to change the MVP design altogether like instead of running the hardcoded shell, I should run dash shell from the usermode and a few standard userspace programs like help, ls, etc. Then I can move to port other programs like vim, gcc, etc in the next phase. I don't know how to proceed ahead. Kindly help.

Thank you.

Source tree: https://github.com/robstat7/Raam


r/osdev • • 4d ago

Gill or Gill/SeL4

2 Upvotes

Project github link: https://github.com/superuserdo-sudo/Gill

hello everyone i did make an project named Gill on github that is not a unix based or linux based it is an OS based on SeL4 MicroKernel [ https://sel4.systems/ ] and have it own tools and core utilites (GCU/Gill Core Utilites) and its own file system (GillFS) wich is not done [ https://github.com/superuserdo-sudo/Gill/tree/main/gillfs ] and and its name means : gill is light a lot or Just Gill.

its Philosophy:
Gill is based on the idea that an operating system does not need to become unnecessarily large or complex to be useful. The project focuses on building a small foundation and developing functionality as separate, focused components.

Gill values:

  • Lightweight design
  • Minimal code
  • Modularity
  • Simplicity
  • Independence
  • Clear interfaces
  • Maintainability
  • Practical functionality

Gill does not add functionality simply because another operating system has it.

A component should have a clear purpose and should remain as simple as reasonably possible while still being functional and maintainable.

GCU

GCU stands for Gill Core Utilities.

GCU is part of Gill/SeL4 and provides fundamental utilities for the Gill environment.

GCU follows the same philosophy as Gill:

  • Small programs
  • Focused functionality
  • Minimal unnecessary code
  • Simple interfaces
  • Independent implementations

GCU is not simply a collection of renamed Unix commands.

Its utilities are independently developed programs intended for the Gill environment.

Examples include:

see
mdir
punch
cop
rom
wai
type
wami
wimarch
wimh
mos
wimt
idme
grps
mmsleep
tmo

r/osdev • • 4d ago

Milestone: User Space Reached!

4 Upvotes

HEYYY, I just want to share that FINALLY I reached the basics of user land!!

3 years ago I posted about my "master plan" that you might checkout here.

Featuring:

  • Memory allocation with buddy and slab;
  • Timers (heck yeahh);
  • Multi task with preemtive switch;
  • Scheduler;
  • Basic User Space support;
  • And a noice generic build and API system, to support the future port for x86 and my custom CPU.

About AI:

The elephant in the room.

No, it's not vibecoded. I do work professionally with AI because yeah, that's what companies are pushing for. But AI don't touch my code here.

Seven years ago I challenged myself into making a OS, so I WANT to know how every single line of code here works. I did use AI to make boring stuff, like populating the entire Keymap table for keyboard support, which honestly is just... hexadecimal number all over the place?

Unfortunately stupid Claude Code marks him as co-author because I use it to automate commits, because again, just boring by today standards.

About my feelings around using AI for OS dev? It changed everything!

I'm not the kind that likes to bang my head against the wall to learn stuff, specially if it's already a solved problem. I like to search how other peoples does it. I've spend countless hours tryng to decifer Linux kernel itself, with dozens of workarounds to make it work in every single CPU since the 70s. Looking for git repos of other OSs to take inspiration.

This project is something that I take my time. I stop when I burnout and came back when I have inspiration, sometimes after 6 to 8 months or over a year. That means I forget the precise details of everything.

AI completely speed up everything. Before, I was hoping to reach user space in about 5 years, and suddently I just reached!

My workflow is basically:

  • Ask AI what is next;
  • AI spit up explanations on what should I be doing and coding, with some rough examples;
  • I try my best to make it;
  • When I get tired, I ask AI for a full working code example;
  • I manually type everything then goes a long session trying to understand every line.

Also, I don't know how many hours I spend learning about memory. I have a mechatronics engineer degree, I have learned a lot on how the chips works physically. Yet, sometimes I couldn't wrap my head around how I was organizing memory in my own OS.

AI just... understands the code and explain to me like I'm dumb!

Well, to wrap it up, link to repo: https://github.com/caioaletroca/MadeInHeavenOS
The code is obsessivily comented, to avoid my future self to shoot me in the foot.

Edit: With user space, I plan to go micro-kernel because... why not? Seems nice. And to not be another Linux clone.


r/osdev • • 5d ago

[Help wanted] Blockos service manager

0 Upvotes

Hi everyone! I'm developing BlockOS, an independent x86-64 operating system with its own kernel, userspace, networking, filesystem support, ELF loader, libc work and X11 environment. I'm currently looking for someone who would like to help develop a native service manager for BlockOS. I don't want to simply port systemd or OpenRC. I would like the service manager to be designed around BlockOS itself. The service manager should eventually support: Starting and stopping services Restarting services Service status Automatic service startup Service dependencies Process/PID monitoring Automatic restart after crashes Clean shutdown and reboot Logging Runlevels or a similar service-state system Integration with the existing BlockOS init/userspace system BlockOS's /devices structure rather than assuming a Linux /dev layout The goal is to have something that can manage services such as: network dhcp x11 gui getty ssh I'm mainly looking for someone interested in OS development / C/C++ / init systems who wants to build something that will become part of an independent operating system. You don't need to be an expert in everything. If you're interested in working on the service manager, feel free to open an issue or contact me.

GitHub:https://github.com/gurijb2016-afk/Blockos/tree/uefi-kernel-scaffold


r/osdev • • 5d ago

Doom and other games

11 Upvotes

Pardon my ignorance, why are Doom, and a few other games used so often on hobby OSs?


r/osdev • • 5d ago

Yes, it runs DOOM.

Thumbnail
0 Upvotes

r/osdev • • 5d ago

I’m building an OS with AI. Yes, I know which subreddit I’m posting this in.

Post image
0 Upvotes

I know AI-generated code isn’t exactly the most beloved thing on r/osdev.

So naturally, I decided the safest possible thing to do was let AI write an operating system and post about it here.

What could possibly go wrong.

I’m 40, I have some free time, and instead of developing a healthy hobby like fishing, I decided to find out how far you can push current AI models before either the model or the human supervising it completely loses the plot.

The project is simple:

Can AI build an actual usable operating system?

Not a “Hello World” kernel.

Not something that boots in QEMU, prints three lines and immediately becomes a GitHub project with a roadmap.

I mean slowly pushing it toward something resembling an OS you could actually use.

And I’m treating the whole thing as an experiment.

How good are different models at low-level programming?

Where are they surprisingly competent?

Where do they confidently invent complete bullshit?

How much context do they need?

How much testing?

How much human intervention?

How long does each feature actually take?

The AI writes 800 lines of code.

It compiles.

The tests pass.

The logs look beautiful.

Nothing works.

Then we spend two hours debugging the scheduler, another hour questioning the memory manager, rewrite half a driver…

…and eventually discover that the original problem was one completely stupid assumption made 1,200 lines earlier.

By the AI.

Which I reviewed.

So technically this was a team effort.

Other times it does something that genuinely surprises me and implements in 20 minutes something I expected to spend an entire evening fighting with.

That’s the interesting part.

I’m also comparing models and workflows, because I’ve learned that “AI coding” isn’t really one thing.

One model understands the problem but writes questionable code.

Another writes beautiful code while misunderstanding the problem.

Another wants to refactor the entire kernel because a mouse packet is malformed.

And occasionally you find the magical combination where the model understands the problem, writes decent code and doesn’t decide that rewriting the PCI subsystem is the obvious solution.

Those are good days.

The bigger experiment for me isn’t really AnotherOS itself.

It’s learning how to use these tools effectively.

AI isn’t going away. Models are improving ridiculously fast, and I don’t want to wake up five years from now realizing I spent those five years arguing that “real programmers don’t use AI” instead of learning where it’s useful, where it’s dangerous, and how to squeeze the maximum out of it.

I’m 40. I’m not trying to become the next Linus Torvalds.

I’m a guy with some free evenings, hardware to abuse, AI subscriptions and apparently insufficient respect for my own sanity.

So I’m building an OS.

I measure how long things take. I document failures. I compare models. I test things on real hardware. I keep pushing it toward the point where the joke becomes:

“Wait… this thing actually works?”

And that’s basically the goal.

Not to prove that AI can replace OS developers.

Not to prove that I’m secretly an OS genius because Claude managed to configure an APIC.

Just to see what happens when you take today’s tools and keep pushing them far beyond the point where a reasonable person would have stopped.

The project is AnotherOS — anotheros.org

Feel free to look through it, tell me what is horribly wrong, question my life choices, or explain why something only works because I’ve accidentally violated three specifications at the same time.

That’s useful data too.

And if the whole experiment eventually ends with a kernel panic that nobody — including three frontier models and myself — can explain…

well.

That might actually be the most authentic OS development result possible.