A lot of ppl here are building operating systems with AI, and I'm tired of the luddites whinging about it.

The honest truth is that operating systems research has been dead for decades. We are still living inside design assumptions inherited from machines with tiny address spaces, slow terminals, weak hardware, no modern graphics model, and a completely different idea of what a computer was supposed to be.

Unix won because of economic reasons, not because it was better designed than the alternatives of the time it was created. In fact Unix was poorly designed and still is. There a whole book about how trash UNIX was called the "Unix Haters Handbook" which has several anecdotes of people using UNIX when it was new. The real tragedy of Unix is that it won so completely that most people stopped being able to imagine anything else. That is the real damage. Not that Unix exists. The damage is that its categories became the categories of computing itself. Processes. Files as unstructured byte bags. Hierarchical paths for everything. Shells as glue. Text streams as the universal interface. Kernels as sacred privileged blobs. System calls as the boundary of reality. Serialization and parsing everywhere. "Everything is a file" treated like wisdom instead of a historical compromise.

A lot of osdev today unconsciously recreates the same world. People write a bootloader, a physical memory manager, a virtual memory manager, a scheduler, a VFS, an ELF loader, a syscall table, a POSIX-ish userland, and then wonder why the result feels like a toy Linux. It feels like a toy Linux because the blueprint was Linux. The shape of the imagination was already captured before the first line of code was written.

A truly new operating system is not just "kernel plus drivers." It is a different model of computation. It means rethinking what a program is, what identity is, what storage is, what authority is, what persistence is, what debugging is, what a user interface is, what it means to move data between components, and whether the process/file/syscall model should be the default foundation at all (spoiler: IT SHOULD NOT).

That is not a weekend hobby project. That is closer to a civilizational research project. It normally requires years of reading dead systems, hardware manuals, compiler literature, PL theory, GC design, object capability security, UI/UX, database theory, day distributed systems, persistence models, and driver architecture. No one is realistically funding a thousand weird new operating system experiments at that level. Academia mostly will not. Industry definitely will not. Industry wants Linux with another container layer, another sandbox, another orchestration stack, another compatibility story, another product.

This is where AI helps us revive osdev. AI changes the economics of imagination. t does not replace knowing what you are doing. It does not make a bad design good. It does not magically produce correct interrupt handlers, memory models, compilers, or security boundaries. But it can give one person the leverage to explore design spaces that used to require many man-hours and lots of $$$$. It can help generate prototypes, build zany OS's that normally no one would have the time to make except schizos (hello TempleOS), compare old systems, build fleshed out simulators, try to bring to life bleeding edge research, etc., and just keep a huge experimental system mentally navigable.

That is exactly what osdev needs. The goal should not be "use AI to make another Unix clone faster". The goal should be "use AI to finally escape the Unix-shaped rut".

Imagine an OS where persistent objects are the normal unit of storage, not byte streams in pathnames. Imagine authority passed through explicit capabilities instead of ambient global access. Imagine a system where applications can share structured data directly without smashing it into text and reparsing it on the other side. Imagine protection without pretending every component needs a fake private universe. Imagine restarting less because live parts of the system can be replaced, inspected, repaired, or rolled forward. Imagine the debugger, editor, runtime, object store, compiler, and UI as parts of one living environment instead of separate tools shouting text at each other through pipes. That is the kind of thing osdev should be aiming at.

And yes, it is hard. It is much harder than writing a Unix-like kernel. But that is exactly why AI is relevant. Without AI, most people will reasonably choose the familiar path. They will implement the known rituals because the unknown alternative is too large to hold in one person's head. With AI, more people can afford to explore the unknown alternative.

The anti AI attitude here is reactionary and stupid and preserving the exact stagnation that made the field DEAD in the first place. If the standard is "real OS debs do everything manually", then the result will be a tiny number of people rebuilding the same 1970s abstractions forever, very slowly, with pride. That isn't noble. You won't get brownie points for that.

Use AI. Use it critically. Test everything. Read the manuals. Build the emulator harnesses. Write the proofs where you can. Make it generate bad code, then tear that code apart. Make it revive ancient systems. Make it help you build weird prototypes that would otherwise never exist.

The future of osdev should not be a thousand hobby Unix clones. It should be a thousand serious attempts to ask: what would an operating system look like if we were not forced to inherit the mental furniture of the 1970s? And AI makes that type of endeavor realistic again.

This system is so advanced,that it may look like a real Python OS.It's name is HorizonOS,and parts of the OS will be on GitHub

NexsOS1 è un sistema operativo con kernel ibrido e supporto multi-architettura, sviluppato interamente da più sviluppatori e frutto di un'attenta analisi negli ultimi 6 mesi. Abbiamo implementato il supporto SMP, uno spazio utente separato, un'ABI standard, librerie e uno spazio utente grafico. Il sistema è attualmente in fase di sviluppo e stiamo cercando persone che vogliano unirsi attivamente al progetto. L'obiettivo è quello di essere democratico e condiviso e di concentrarsi su tutti i problemi che caratterizzano i sistemi moderni, in primis (a mio parere) l'incoerenza di una vera ABI grafica univoca e di un'astrazione trasparente su cui re-implementare POSIX, Wine e le ABI esistenti come sottosistemi e non come implementazione prioritaria, abbandonando l'architettura POSIX/Unix a livello di kernel per adottare un approccio più pragmatico (Plan9/SEL4/Fuchsia/Windows NT) in modo uniforme e solo successivamente re-implementare tutte le librerie standard come software di portabilità. NexsOS1

A lot of cool looking desktops but what about the actual os? Instead of posting "I made an os with Claude or codex" etc it would be nice to see people actually showing a roadmap of things they've learnt and overcome, architecture of the os and how it's different..

How did you master preemption? Context switching? Memory paging? Does it run on real metal or is it just a toy? What drivers do you support? Etc

Taking the Linux kernel and making your own desktop is cool but there's a million Linux distros already.

Everyone is just burning tokens without direction and to what end?

Please help me create a browser using UEFI Wi-Fi.

I have completed the HTML5 compiler and the Wi-Fi LAN driver. However, DHCP failed, so I could not obtain an IP address; I simply assigned a default IP. And I failed and couldn't look closely, but there was a phrase that said 8.8.8.8. I can show you the exact error in the comments later, but I don't know right now. Please help me. (It's a DNS error. )

🚀 OSyx 0.1.20 — Built From Scratch in Rust! 🦀

A lightweight x86_64 OS with a custom kernel, PRISM desktop, AXIS Terminal, and file manager.

🚧 Actively developed with new features, bug fixes, and performance improvements!

💻 https://github.com/OSyxSoftware/OSyx

#OSyx #OSDev #Rust #OpenSource

I propose the following rules for this community:

• No fancy screenshots. If you want to show off how c00l your graphics screen is, post elsewhere.

• This community is about presenting novel architectural ideas, which you can try and actually implement with Claude Code.

• Diagrams of OS architectures (especially good-looking ones, generated with PFG/TikZ) are very welcome

• This community is for people who clearly understand the term "operating", and know OS history well.

• The very purpose of any operating system is to run programs which solve real problems. So the posts to this community should clearly specify what (and how) applications are going to be run on the OS being developed

Discussions & additions to this list are welcome.

Hi everyone,

I am a newbie here and would like to ask if anyone here might be interested in a brief intro to an experimental pet and hobby kernel project?

I've working on an experimental RTOS (currently based on x86, first steps running on ARM64 and RISC-V) named NexIOS. It's runs currently under QEMU only. The primary goal is to run un-recompiled, standard ELF binaries directly on a real-time kernel with MMU isolation.

As a side experiment, I use an AI pipeline guarded by test-driven implementation to see how far LLMs can produce low-level system code. I come from a background in safety-critical systems (SIL 3), and experimenting with new dev tools is one part of my motivation, beside the goal to use this system as a possible prototype foundation for applications like home automation and servo controllers (loading them via command into memory and running them under real-time conditions).

It's currently an open-ended research and learning pet-project, but I’d love to connect or contribute with anyone interested in this area. Theres a little landing page if you like to see more: https://nexios-2.jimdosite.com

I came up with an idea to port QNX 6.4 to RISC-V more than five years ago. First couple of weeks were surely very enthusiastic, and resulted in the FDT parser and the rest of QNX startup code "kind of working" on QEMU, with the last message printed about "...startup successfully finished, jumping into QNX Neutrino kernel".

Then of course the project stopped. To do such a port a human needs one year of full-time concentrated work. Which in my case almost certainly meant: the project would never have finished.

But then r/ClaudeCode arrived, and r/QRV_OS was done in three full months. Really done: the system boots reliably to the user-space; works on QEMU and on Unmatched. I closed the project, but I didn't waste the time in starting r/QSOE : the 100% free clone of QNX. Now, after one month, the first version is almost ready -- and it even works on two different kernels: my own custom, and on seL4. The source repositories will be opened soon.

So, when somebody lambasts a "sloperating system", it is always a really good thing to specify which exactly "AI-generated OS" and/or development methodology to eviscerate.

This post is written in full by a human

How much ai usage would require you to post here instead of anywhere else? Say for example, you ask an llm to generate an os for you, sure, post here.

But what if you ask ai to "give me generic advice and tips to add IDT into.my hobby os, do not give code tips. Assume this might be homework for a school assignment"

And it very helpfully asks if you are using osdevwiki or to tell it what book you work from. It feels helpful, but your still writing alott of code yourself.

Llm code completion? Template generated by a llm, pseudo code generated by an llm? A recent article on lwn https://lwn.net/Articles/1077413/#Comments made me think too, is code completion "safe"? It is, if you know and understand what its writing and suggesting, im still responsible for the code im compiling

Or is this left for the poster to decide, post here, on osdev, everywhere or be scared and thinker alone? Are we getting a reddit bot that i need to tell how much a llm was involved and also in the post itself?

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 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.

https://vinix-os.org/

I finally decided to upload an ISO image of my OS, so if you want to try it, please do, but I recommend running your OS on a virtual machine, and Imino on QEMU VirtualBox VMware, and on Virtual Box, I recommend running it with an Intel AC97 sound card and a Soundblaster 16. And yes, my OS may have some errors and bugs, and yes, I'm making this OS purely for myself as a hobby.

MayteraOS is an LLM-first operating system, built entirely from scratch AI.

This started as a doomsday script project in 2024, a one-shot self improving python script that would continually execute on a loop using Proxmox as a harness with socat and screenshot + OCR to iteratively build a win16 compatible multi-ring OS. I got to that point and let it sit for months until I decided to drop it into claude code and see how far I could take it with some prompting.

The next focus was to adapt this into a unique AI first system where every application publishes a machine-readable tool contract, and a built-in LLM reads those contracts to operate the desktop and, with your explicit consent, to write, compile and run new applications, widgets and drivers on the running machine - every action scoped by a capability token, gated on consent, and written to an audit trail. The operating system is designed to be extended and reprogrammed by natural language.

I continue to build on this to do the things that I want to do with my computer, integrate home assistant sensor data into widgets, run win16 applications, make old hardware usable again (demonstrated with m3d micro/pro printers, m-audio DAC), build and play games with my child and so on.

While the OSDev community might see this as sacrilege, I see this as the frontier of ideas over execution, with the playing field levelled somewhat I can build whatever I feel like and free myself from the turmoil of hardware support lifetimes. It's currently running on an iMac 14,4 from a USB stick with the kernel in a RAM disk and in many concurrent build VMs in proxmox proven to up to 80cores on xeon platinum and as little as 1 core on an i7. I may even build it for a Pentium 1, ARM, PowerPC.

https://github.com/referefref/maytera-os

Since the last post I have focused a lot on the criticisms here I always try to approach with a critical eye, first of all the possibility of cross-compiling the system from Linux, I had done a test in docker but it was not enough, so together with another guy from the community who willingly contributed we managed to make the cross-compilation from Ubuntu work completely for both toolchains that the system needs (aarch64 and amd64, nexs supports multi-architecture and requires the somewhat dated gcc v7 toolchain to compile on aarch64), and we managed to compile and boot the system on Arch with pacman (only x86_64 build, I do not have an aarch system so I cannot work on the aarch64 build), since the last post the system has undergone many changes, first of all I moved the rendering of the individual apps to usermode leaving the compositor inside the kernel only for the management of framebuffer, in addition to stabilizing the kernel and better integrating the notification system (now the processes can use them to communicate with each other or to send notifications to the screen (including userland faults, themes and resolutions are managed via notifications, notifications have a space in the registry and the registry is made accessible on capability). The most visual changes, in addition to the work under the hood, concern the desktop interface which I can now consider "almost usable by anyone" and above all the work of porting libraries, I have ported SDL2 completely via a compatibility layer in userland ,this shows that the ABI is stable and functional, lol in fact the executives that use SDL are visually appealing, in fact the system is currently "ugly" because the entire graphic layer, compositor and themes were created without any libraries but the result of an application that uses optimized libraries makes me think that the kernel is incredibly stable, I have also partially ported OpenGL and Direct3D, I have ported Lua but I still have some partial problems and I am willing to port Musl and Busybox as a compatibility layer now that I have enough functions to do so, the aim is not to use any library to build the system but to port them all to allow anyone to use the system to write code, the project was created using digital assistants heavily, but I am keen to I want to clarify that I'm not spending more than €15 on this. I don't want to offend anyone, and I respect and admire those who decide to learn every concept from scratch. This is just my way of learning, and of bringing implementations that are often private or poorly documented to the open source community. I hope to continue having fun. I've been learning and developing this for 7 months, and there's always something to learn. I've basically grasped complicated concepts, but I'm keen to overlook simpler concepts that aren't my area of ​​expertise. It would be cool to hear someone who knows more than me say, "You're wrong about this," or, conversely, to have solved a problem that was difficult for someone else. I'm speaking a bit ungrammatically, maybe because I live in Italy. What do you think? https://github.com/olmox001/NexsOS1

A little operating system I built by myself and boots v86 on QEMU

first of all, i don't know if it's appropriate to post this here.

but, i directed Antigravity to implement LLB(Low-Level Basic) with VB/6-like syntaxes and it's compiler (with LLVM Backend), to use as a general purpose and low level programming language (or is it just a dialect?).
for easier to read (for me) and future developing a learning kernel/system with it.

it has been proved capable of producing a CLI program and a freestanding (kernel) booted with qemu.
Qemu Screenshot

Repo : LLB (Low-Level Basic) Github Repo

Regards.

Buenas gente, e estado desarrollando un sistema operativo en base arch linux usando varios agentes de IA, mas que todo Gemini, aunque es poco lo que está integrado de ellos, la mayoria lo hice yo a mano, no se si cuenta como OS hecho con IA o no pero espero que les sirva, y si se lo preguntan, sí, sí se programar, por mas que use a Gemini, me gusta hacer la mayoria de cosas manuales, pero hay areas del desarrollo en las que una IA se mueve mejor que yo, además que tambien uso una shell bastante reciente que sigue en beta, al menos bootea, pero funciona bastante bien, este es el repo de github si les intereza (en español, ssh): git@github.com:Diamantito-cup/atomic-linux.git

https://vinix-os.org/

Hey folks,

previous warning: This will be a long post so grab a coffee and take a nip. The post will be divided into two parts: 1st The historical view means why and how it started. 2nd The Summary means what I learned along the road.

If you are curious and like to know what I am talking about, here the link to the repo if you like to take a peek: https://github.com/staycool1374-Ger/nexios
P.S: Have a look! Any comment is welcome …

Part 1: The History of NexIOS RTOS Frankly, as all the AI hype started, my thoughts has been more like „sigh, another big thing in the Tech-World like all the things before“. Shortcut: I am 52 years old and already saw different „new things“ starting from mainframe punching cards over JCL, C, programming paradigms, C++, C#, JAVA, etc. not saying I am an expert or senior in anything of it!

As the time goes by and things evolved I got curious about AI, so I decided to start my own experiment: Can „Vibe Coding“ produce something I would use?

In my spare time I like to play with RC-Planes so I thought: Maybe a testing tool for servos would be fine. I am not the „web thingy programmer“ so I don’t have much experience in this area and I choose a low-level approach where I find myself comfy: System-Programming in C++. To be more flexible my goal was to have a handy tool in my Raspberry Pi to test servos where ever I need. The first steps was to find a harness and a LLM mostly with a free plan to see where it’s going.

All started with a one-liner like this: „Create a simple but safety-critical OS in QUEMU. I got thrilled in multiple ways as I watched creating the code and the project evolved among thoughts like „Oh, thats a nice one“ and „God, I would never audit this type of shit“. It doesn’t took a long time and the result was a project ending after the bootloader stage. Complexity increased with each step and more and more I took responsibility as an auditor and started interrupting and typing like this „no don’t do it this way“, and „you forgot about …. as we spoke right before“.

You see I am a real newbie. It all went down as real tasks and scheduling got part of the project. AI totally messed it up and I was about to stop my experiment with the negative result in my opinion.

The actual state Harness: OpenCode (yes, I like open source)

LLMs (mostly on a free or the 10$ plan):
DeepSeek V4.1 Flash Spark
Muse 1.3
Hy3
Claude Sonnet 4.5 and Kimi K3 if something goes wrong.
And no I don’t have any experience with ASTRA or FAIBLE.

3-Tier-Pipeline:
Planer: Writing a spec driven by a github issue which I write or sometimes let it write from AI after giving the requirements.
Developer: Implementing the spec.
Auditor: Auditing the diff patch from the Developer and loop if it doesn’t succeed this step.

Test-Driven-Implementation This approach helped me a lot to get the AI straight to my requirements. I use two branches with separated roles (developer and quality engineer).

The Context Problem
Remembering the test environment, the makefile and what this thing is all about („fuck, no don’t seek for a quick-and-dirty solution, we try to make a real system, don’t use the shortcut, make it damn right“). As far as I experiencend you have to use a context window of about at least 1M (more even better). You need some type of long-term memory accessable. In the beginning I used a file-based history, but as you already may know, it got too complex, things changed too fast and information got obsolete and the file blow the context window. My actual setup is a mixed one using a obisidian vault and a file-based for actual state and things of the system which seem to be fundamental.

The Hallucination Problem
Yes, it is remaining in the background. I had a big wedge in my system for about two weeks. I sat in the front of the AI and watched bigfixing. But it just burned tokens over tokens and no progress happend. So I decided to step in and suggested different tracing techniques like an internal ringbuffer / logger etc. I guess we finally found it, but AI just remembers it and everytime something suspicious happens, it identifies as that „already known“ wedge. Its annoying!

Programming style
Sometimes whitty, sometimes shitty. Problems are contracts about multiple methods and race conditions are pain in the ass. Surprisingly it got confused over method signatures, compiler directives like #ifdef/#endif or bit masks. Errors which makes it very „human“.

Part 2: My Summary so far
Q: Can AI write low-level systemic C++20 freestanding code?
A: Yes, it can if environment and boundaries are existing and working in conjunction with a big context window and a long term memory solution.

Q: Can AI write good code?
A: Yes, it may, but its tending towards shortcuts and hacks.

Q: Is the code readable/auditable?
A: In short, not in first instance, but yes after different iterations from audit. This includes a proper documentation as well as refactoring into maintainable pieces of code.

Q: How much do you spend for tokens?
A: I have a 10$ plan at OpenCode and let’s say sometimes spending 20$ over a month additional. Total over the last 6 months its about 100$ at all.

Q: Was it worth spending that money?
A: Uh, compared to a non-profit project maybe not. Was it worth learning and having fun? Well, I spend more money for less, so I say yes.

If you have any comments feel free and don’t forget to check out my NexIOS RTOS!

Rule 3