Posted by noone_youknow 3 days ago
LLMs (mostly Claude Code) have been used during development, but I learned early on that it's not _great_ at code at this level, so I've restricted its use to mostly documentation and tests. There's _a little_ AI code in the user space, but I have a strict "no AI code" rule in the kernel itself. I find this helps not only with the quality / functionality of the code, but also with learning - for example, even though I've written multiple kernels in the past, it wasn't until Anos that I _truly_ grokked pagetable management and what was possible with a good VMM interface, and if I'd outsourced that implementation to an LLM I probably wouldn't have learned any of that.
In terms of approach, Anos avoids legacy platform features and outdated wiki / tutorial resources, and instead tries to implement as much as possible from manuals and datasheets, and it's definitely worked out well so far. There's no support for legacy platform features or peripherals, with all IO being memory mapped and MSI/MSI-X interrupts (no PIC), for example, which has helped keep the codebase focused and easy to work on. The kernel compiles to about 100KiB on x86-64, with enough features to be able to support multitasking and device drivers in user space.
As a hobby project, progress ebbs and flows with pressures of my day job etc, and the main branch has been quiet for the last few months. I have however been working on a USB stack as time allows, and hopefully will soon have at least basic HID support to allow me to take the next step and make Anos interactive.
I don't know how useful projects like Anos are any more, given we now live in the age of AI coding, but it's a fun learning experience and helps keep me technically grounded, and I'll carry on with it for as long as those things remain true.
Although I don't practice vibe coding, I'v observed that the first principle of vibe coding is to never look at the generated code. (You learn the code from external metrics, such output correctness and memory usage)
Love that Linus quip! Hopefully it will be. Non-POSIX sounds exciting
Porting the programs that you are more interested in from Linux or *BSD to your own OS is the best, but this is necessarily slow and also the work of porting rarely used applications may not be worthwhile.
An alternative to a syscall translation layer is for your OS to act as a hypervisor for Linux or other OSes VMs. However, this would have a lower performance than using natively your IPC-based OS.
I’ve always found hobby OS projects like this interesting, and I hope there’s never a shortage of them in the future
It's certainly useful _to me_ and has helped me really nail down concepts I thought I already understood, but it turns out I didn't.
I just hope that, in an age where it feels like code, and maybe even deep technical knowledge have diminishing value, projects like this don't become completely anachronistic.
I get pretty excited when project like Anos come out, I love Anos. Long live all Anos.
Looking at syscalls.h, it looks like it abstracts the platform details, for example.
Is SYSTEM for amd64 source-compatible with the riscv version?
SYSTEM has a tiny arch-specific assembly trampoline which just sets up the initial stack pointer for new processes that it creates and makes the jump, but other than that it's source-compatible across architectures.
The platform detail extraction isn't yet complete, such that devices management on non-ACPI platforms isn't finished, but the idea is the abstraction will be enough that drivers for (at least) MMIO devices will be trivially portable.
They have the same utility they always have. They help you and the people you share it with learn. So it's exceedingly useful.
> given we now live in the age of AI coding
We live in an age of AI overinvestment. I would reserve judgement until they prove they actually have something.
Haha yes, that's a very fair comment!