This is my operating system I made. Please look over the single 50k line commit.

The code is github.com/claudeAIgeneratedOS

NO I DID NOT USE AI.

I’m working on Kryon, an open-source execution layer intended to sit underneath terminals and developer tools.

The problem I’m exploring is slightly different from building a shell or terminal emulator:

How do you define a consistent process model across operating systems and programming languages?

Kryon currently implements the execution layer in five SDKs:

- Python

- TypeScript

- Dart

- Java

- Kotlin

The common model covers:

- spawning processes

- stdout/stderr streaming

- cancellation

- timeouts

- output limits

- termination

- lifecycle handling

- structured execution results

The five implementations are checked against one shared conformance corpus rather than having five independently evolving definitions of "correct."

The architecture deliberately separates:

1. Execution engine

2. PTY engine

3. Transport

4. Terminal emulator

5. Renderer

Only the execution engine is currently implemented.

PTY, ANSI/VT terminal emulation and transports such as WebSocket/SSH are specified for later phases.

One thing I’m being particularly careful about is not pretending this is a sandbox. Kryon executes commands with the privileges of the calling process. If hostile code needs isolation, the documentation explicitly recommends containers, VMs or unprivileged OS accounts.

The repository:

https://github.com/PIYUSH-MISHRA-00/kryon

Current 1.0 status: all five SDKs implement command execution and process streaming and pass the same conformance corpus on Linux, macOS and Windows.

I’d be interested in hearing from people who have implemented PTYs, terminal emulators or process supervisors: does this layer separation make sense, or would you structure the execution/PTY boundary differently?

This took so long to make.... And it is a html os like firefox os, and this is is based off of chromeOS, ubuntu touch, and Firefox os. I still have to fix the emoji problem on the keyboard. But overall the os works fine.

That's my operating system built from absolutely scratch without 3rd party library, AI or anything else. It is written in Assembly and C(Bootloader for BIOS 100% Assembly). I wrote it in 6 months. Well, it doesn't have functionalities yet, but still in development. I wrote keyboard,VGA driver and First-fit MAlloc/CAlloc. It is my first project ever, i gained c and assembly knowledge here. It wasn't university homework, just raw curiosity.

Built from scratch in x86 assembly and C, the OS core uses no paging, runs on a single core, and has no third-party libraries. ~8,000 lines of code compile in ~2s into a 100 KiB boot image (icons included, LZ4-compressed onto the medium), and it boots on actual BIOS hardware - floppy or CD. Doom and the other applications are separate loadable programs.

Edit:
I was building this for a while, and wanted to share with the rest, and there is a lot to share.
I wanted to answer techincal questions and was really looking forward to.

Toxicity of those who commented (first four comments at least) is a confirmation and a reminder for me and I believe for the others to minimize such desire. Such people while living in dissaray and in hate, prove to deserve to be there, nothing more. For the rest of you, enjoy.

Links:
Try it in the browser:
https://branchpredict.com/post-play-doom-on-a-100-kib-os

Raam is an x86-64 Unix-like operating system for my HP Pavilion Laptop 15 machine. I am writing it completely from scratch using FASM assembly.

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

Raam Raam Ji 🙏🙏🙏 (greeting with God's name)

I'm developing a very simple Kernel with some goals, namely: being beginner-friendly and developer-friendly.

What’s already done:

• Bootloader: Limine for support of ready-made headers
  
• Basic video framebuffer support with some graphic tools
  
• Partial SMBios support, with Qemu tools to create a custom SMBios
  
• RAM support not complete: PMM working, VMM not working, raw RAM working
  

Future goals:

• Working RAM
  
• PCIE controls and GPU command
  
• Elf loader
  
• Scheduler
  

Please help me, I don't know what to do. If it helps, I use Arch with x86_64-elf-gcc compiled via yay.

Here’s GitHub: https://github.com/Alessio-Valluzzi/Trikernel

We built BareMetal OS - an exokernel with sub-millisecond cold boot and hardware level microVM isolation. We think it's small and fast enough to be genuinely interesting to build on. So we're running a 2-week challenge to find out what you can build. See attachment for contest details and rules.
Complimentary cloud credits for every applicant to help you build on our servers. Grand prize winner announced Sep 24, 2026. See link for details

I’ve been working on RESENTMENT, an open-source experimental operating system built around the idea that AI agents should behave more like OS processes than unrestricted applications.

The project has both a from-scratch kernel and a browser-based desktop.

Some of the ideas I’m experimenting with:

Capability-based security — kernel capabilities and desktop agent permissions are explicitly granted

Expiring authority — permissions use time-bounded leases instead of permanent access

Agents as processes — agents have state, scopes, resource/token budgets and a kill mechanism

Auditable actions — tool calls become ledger entries and file changes record their causal operations

System as a hash — system state can be represented through Merkle/SHA-256 digests, with snapshot, diff and attestation

BYOK AI — API keys stay on the client; there is no RESENTMENT server

Multiple providers — including OpenAI-compatible endpoints and local runtimes such as Ollama, LM Studio, vLLM and llama.cpp

Architecture targets — x86_64, ARM64 and RISC-V

The kernel is written from scratch and currently boots with the OS ramdisk. The desktop communicates with it through a QEMU/serial bridge.

One important limitation: the desktop does not yet run inside the kernel. That is one of the major pieces still to be developed.

The four principles I'm trying to carry consistently from the kernel into the AI layer are:

Authority expires.

The system is a hash.

Agents are processes.

Nothing is forgotten.

I'm interested in feedback particularly from people who have worked on kernels, operating systems, capability security, microkernels or distributed systems.

Does treating AI-agent authority as an OS capability/lease make sense, or am I introducing complexity without enough security benefit?

GitHub: https://github.com/ni-sh-a-char/RESENTMENT

Browser demo: https://ni-sh-a-char.github.io/RESENTMENT/os/

Apache-2.0 licensed.

Hello everyone! While reading my DSA book, I’ve noticed that it also explains many fundamental concepts such as what software is, what a program is, what program code is, and so on. At the end of each chapter, there are also some questions to help reinforce the concepts.

Today, one of the questions was about the difference between single-user and multi-user operating systems, and I’d really like to understand this topic better. What exactly is the difference between a single-user and a multi-user operating system?

I’m learning all of this purely as a hobby. I don’t have a university or computer science background, but I’m very interested in programming and computer science, so I’m studying on my own as a self-taught learner.

I hope this isn’t a silly or inappropriate question. I’d really appreciate any explanations or resources that could help me understand it better. Thank you!

Thanks to https[:]/github.com/cfenollosa/os-tutorial I was able to learn a lot about how an operating system is written. I think a lot of people would remember his tutorial. Revisit it gives me more. Start with printing some text in boot sector. The repo used software interrupt to finish the task. Yet there is another way to accomplish the same, by utilizing the direct memory accessing method. Long story short, in legacy boot mode (CSM), we can access VGA memory directly during boot time at address 0xB8000. So we can drop in each character and have them printed out, starting from the top left corner. We can print color text, and we can also move the cursor and print the text anywhere we want (with the cursor blinking at the text).

I have documented the process here: ellog[.]buzz/posts/hello-world-in-boot-sector

For this chapter and the previous one (First boot sector), what other questions do you think is worth asking and figuring out?

Has anyone built kernel in rust? If you have can you send the link to your project, I want to look for reference...

I've been developing Robu, an independent, platform-independent microkernel operating system written primarily in C and assembly.

Robu started as a kernel project, but it has grown beyond simply booting and printing text. The goal is to build a usable general-purpose operating system around a small microkernel while keeping drivers, filesystems, paging policy, and other major services outside privileged kernel space.

Robu is influenced by ideas from the L4 microkernel lineage, especially around fast IPC, direct switching, and keeping the kernel focused on mechanisms rather than policy.

Current target architectures include:

• x86_64
• i386/i486
• ARMv7
• ARMv8 / AArch64
• RISC-V 32-bit
• RISC-V 64-bit

x86_64 is currently the main development platform, but Robu is designed to remain architecture-independent.

Current work already includes:

• Microkernel core
• Threads and address spaces
• Synchronous IPC
• Register-based short-message IPC
• Direct thread switching during IPC
• Lazy scheduling
• Timeslice donation
• User-space paging architecture
• Virtual memory and address-space support
• Process and thread management
• SMP / multicore bring-up
• ACPI-based CPU enumeration
• Per-CPU infrastructure
• Framebuffer support
• Ring-3 framebuffer mapping
• PS/2 keyboard and mouse support
• Serial console support
• Device filesystem infrastructure
• ELF userspace support
• POSIX-oriented userspace
• mlibc port
• BusyBox
• Bash
• GNU Readline
• poll()
• System V shared memory
• Bootable root filesystem
• Custom BIOS bootloader
• EFI boot and filesystem integration
• QEMU-based development and testing
• Early Xorg-related userspace work

The kernel is intentionally kept small.

The basic design is:

Applications > POSIX / mlibc > Userspace services > Robu IPC > Robu Microkernel > Hardware

Drivers, filesystems, pagers, and similar services are intended to run as isolated userspace processes rather than being permanently linked into the kernel.

One of the main design goals is keeping IPC fast enough that using a microkernel does not automatically mean accepting poor performance.

For short messages, Robu uses registers instead of copying data through temporary kernel buffers. IPC is synchronous, and when a sender reaches a waiting receiver, Robu can directly switch execution to the receiver instead of performing a full scheduler round trip.

The remaining timeslice can also be donated to the receiving thread.

Robu also provides a POSIX-oriented userspace environment using mlibc, allowing work toward familiar Unix-style applications and tools without moving large amounts of operating-system policy into privileged kernel space.

I'm looking for contributors interested in:

• Microkernel IPC
• Scheduling
• Memory management
• User-space paging
• SMP / multicore support
• ARM support
• RISC-V support
• ACPI
• PCI / PCIe
• USB / xHCI
• Storage drivers
• Network drivers
• User-space device drivers
• Filesystem servers
• Networking
• mlibc / POSIX compatibility
• Xorg bring-up
• Graphics and input
• Real-hardware testing
• Kernel debugging
• Documentation
• Code review
• Automated testing

You do not need to understand the entire codebase to contribute. Individual subsystems can be worked on independently.

Experience with Linux kernel development is useful, but Robu is not intended to be a Linux clone.

Experience with FreeBSD, L4, seL4, QNX, Minix, Zircon, Mach, or other kernel architectures is also very relevant.

The goal is not to make another toy kernel.

The long-term objective is to build a complete operating system that can eventually boot on real hardware, run normal POSIX-oriented software, support isolated userspace drivers and services, provide a graphical environment, and support multiple architectures.

Robu is still in alpha, so incomplete subsystems and bugs should be expected.

GitHub: https://github.com/bayar17/robu_microkernel

If you're interested in microkernels, operating systems, low-level C, assembly, drivers, libc work, toolchains, graphics, or kernel architecture, contributions and technical discussion are welcome.

Testing, bug reports, documentation, code review, and architectural criticism are welcome too.

Hello everyone, how are you?

The Lunaris project is growing exponentially and getting bigger by the day; we already have the IceDog browser with its own private intranet (all sites in the system use the .icedog extension and are inaccessible from the open web), and that excites me.

I am gradually introducing everyday tools (such as a word processor, spreadsheets, and a media/file viewer); I will share more information as things progress. See you soon.

I've been developing BlockOS, an independent x86_64 operating system written primarily in C/C++.

BlockOS is no longer just a basic kernel experiment. The project currently includes:

• x86_64 kernel
• VFS and multiple filesystem implementations
• ELF loader
• PCI/PCIe support
• VirtIO block/network/input drivers
• networking stack
• POSIX compatibility layer
• libc
• process and scheduler infrastructure
• framebuffer and GUI framework
• BX11/X11-related work
• ACPI support
• USB/xHCI development
• examples and driver development infrastructure

I'm looking for OS developers and especially Linux kernel / low-level C/C++ developers who would like to contribute.

Areas I'd particularly like help with:

• memory management / virtual memory
• SMP and multicore support
• ACPI
• PCIe
• USB/xHCI and USB HID
• device drivers
• filesystems/VFS
• networking
• POSIX/libc
• GUI/window management

The goal isn't to make another toy kernel. I want to develop BlockOS into a stable, usable general-purpose operating system that can eventually be used on real hardware.

You don't need to understand the whole codebase to contribute. Individual subsystems can be worked on independently.

GitHub: https://github.com/gurijb2016-afk/Blockos

If you're interested in OS development, kernel development, drivers, or low-level C/C++, feel free to comment or message me.

Contributions, testing, code review and technical discussion are all welcome.

Continuing my post on my journey to learn how to create an OS. Right now I'm just working on a kernel. I have spent the last 10 days trying to get my head around a recursive page directory. I have no idea why it took me so long, I've used recursion since the mid 70's walking tree structures.

1) Understanding a recursive kernel. Finally getting my head around this lets me 'recover' 4M I had planned on using to keep track of page tables. As part of this journey I finally had AI write some functions on initializing, getting both physical and virtual addresses of page tables, and using a recursive page table. Once I finally figured it out, I threw them all away and wrote my own.

This leads to my second learning.

2) AI can be really touchy. I have two types pde_t and pdt_t (both uint32_t), but I tend to think of the indexes (pde and pdt) as the references to the page themselves. AI insisted on referring to them as the pages instead of the indexes they really were. I know that this was MY fault, but it did nothing to make things clearer. The real learning was I'm not much better at talking to AI than I was a week ago.

3) I still hate writing test script. I am doing it, but have taken to writing a test script on things as part of debugging. It seems a reasonable compromise. If I just write test scripts, knowing myself, I will eventually lose interest in the project itself. I know I have a prior (re)learning about don't skimp on the test scripts. So if I have a few minutes between household tasks, I am still writing some of the simpler test scripts.

Finally:

4) I forget if it is posted in r/osdev or r/kerneldevelopment, and I can't find the post again to credit the person that found it (my apologies there), but I found a new resource today, it it is on the University of Wisconsin (my alma mater) titled: Operating Systems: Three Easy Pieces and it looks really interesting.

These are the main thing I've learned over the last 10 days. And now that I know them, I have some questions.

a) Where do you map your video memory, in the kernel, or in user space? One point of a kernel is to coordinate access to shared resources. I think video memory fits this definition, and it could be really bad when I introduce multiple processes, if they are all writing to video memory. I am definitely going to map vga memory (0xB0000 into my kernel, with SYSCALL access to update it. I am unsure about ega, I'm not sure I want to support it, at least to start. What are your thoughts?

That's all for this post, thanks for reading, I hope it helps others that are trying to learn OSdev.

Nothing huge. Just a highly opinionated Mint-flavored Arch. I like my system. That should be enough, no?

I want to compile C programs in my OS itself rather than copying it manually to the disk image every single time. How can port GCC, or is there any other way to do it?

Hi!

Context:

I am currently in the process of trying to build a simple recreation of Amazon's EC2 on top of a type 1 hypervisor for fun :)

Since I am planning on making the memory each vm takes static and non-changing, it came to my awareness that I would need to allocate big consecutive blocks from RAM (in the GBs).

I was planning on using a buddy allocator with blocks of actual page sizes (1GB, 2MB, 4KB) with a free-list for each of these, but I lack enough experience in that regard to understand how dumb or ok-ish my idea is

If this is a dumb idea, go roast me :), that's the best way for me to learn and understand.

I want to understand if this idea is worth my time and effort before building a whole unit just to realize I need a different thing.

(I write all of my code by hand, if some AI usage is bothering you please let me know)

Repo: https://github.com/NoamRothschild/hypervisor

I'm talking stuff like the bootloader, writing method to the SSD, printing stuff, etc.

I am currently using the Ubuntu 26.04 in my Victus by HP Gaming Laptop 15-fa1xxx laptop.

I want a OS which is very small in size and usage , i want the most battery backup as much as possible, i will be triple booting it .

There is a dGPU of nvidia 2050 and tht new OS shld not be using it.

Try it online: https://mazin-o3.github.io/vemu/

GitHub repo: https://github.com/Mazin-O3/cpm-neo

Until now, I've been refering the osdev wiki and using a little bit of AI (only for guidance and answering questions, no vibe coding). Is this the right way to learn osdev? What should or shouldn't I do? Also I've already started osdev, finished making a file system, and am now working on my own very simple file format for my os. I just wanted to clarify if I need to change my habits or something.