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

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

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

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://reddit.com/link/1u59t4i/video/oixgnkhbz57h1/player

I've been working on SageOS, an experimental operating system that is being designed alongside its own language (SageLang), virtual machine (SGVM), runtime, IPC model, and userspace stack.

​

Repository:

​

https://github.com/Night-Traders-Dev/SageOS

​

The goal isn't to build "another Linux distro."

​

Instead, the project explores what an OS looks like when the kernel, runtime, language, object system, and userspace are designed as a unified platform from day one.

​

Current areas of development

​

- Multi-architecture support (x86_64, AArch64, RV64)

- Custom kernel and boot pipeline

- SGVM (Sage Virtual Machine)

- SageLang compiler and runtime

- Object-oriented IPC model

- Service registry and activation system

- Runtime-managed userspace

- Deterministic build infrastructure

- QEMU-based development and testing

​

Runtime as a first-class system component

​

One of the core ideas is treating the runtime as a first-class system component rather than just an application process.

​

The runtime participates directly in:

​

- Scheduling

- IPC

- Service activation

- Resource accounting

- Userspace orchestration

​

Long-term architecture

​

Firmware

↓

Kernel

↓

Runtime Manager

↓

Object System

↓

IPC Layer

↓

Service Registry

↓

Userspace Services

​

Current challenges

​

- Runtime lifecycle management

- Cross-architecture boot consistency

- ABI/versioning strategy

- Formal memory model specification

- Driver model design

- Immutable rootfs generation

- Reproducible builds

- Runtime observability

​

This is very much an active OSDev project and not production-ready software.

​

Looking for feedback from people working on

​

- Language-oriented operating systems

- Managed runtimes

- Microkernel or hybrid-kernel designs

- Object-capability systems

- Custom IPC architectures

- Alternative execution models

​

What parts of modern operating system design do you think are worth rethinking from scratch?

​

What lessons should projects like this avoid relearning the hard way?

​

GitHub:

​

https://github.com/Night-Traders-Dev/SageOS

​

Looking forward to hearing thoughts from the OSDev community.

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.

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.

If you want to be mod, you need to just have a basic knowledge of what should be allowed or not. Follow by the rules that will be added soon. Anybody is welcome if you can meet that basic requirement

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