r/osdev

so i've been building this hobby microkernel called Rustix OS (or AE Rustanium) entirely from scratch using safe Rust and no_std.

instead of sticking to boring VGA text mode, I went down a rabbit hole and built a ring 3 user-space vector GUI that boots over UEFI GOP. it handles alpha blending for shadows and has a functioning mac-like dock.

the main experiment here is handling bitflips in software. i implemented a software SECDED ECC layer, a background memory scrubber, and a TMR voting engine in the scheduler so it can survive simulated cosmic radiation without hard crashing.

i also threw together a quick "Radiation Simulator" app inside the desktop to test things out (the screenshot attached):

- single bit flips get fixed in the background via hamming codes, no lag at all.

- double bit flips don't trigger a kernel panic. the virtual-fs and memory manager just quarantine the broken physical frame, relocate the data, and keep the user-space running.

runs fine in QEMU and boots on real hardware via UEFI (flashed with Rufus DD mode).

repo is here if you want to check out the workspace: https://github.com/AethelisDEV/rustix-os

wondering if anyone else has tried implementing software ECC in their hobby kernels? how bad is the CPU overhead compared to just relying on actual hardware ECC?

Over the past few weeks I've been reconstructing CHARM-II, an RTOS I originally developed in 1986.

Some previous posts about this project:

• Visualizing a 1986 RTOS in a Modern Browser https://www.reddit.com/r/osdev/s/XeZDemN4Wk
• Visualizing a 1980s Commercial Messaging System Running on a Reconstructed RTOS https://www.reddit.com/r/osdev/s/gu8LBK5iev

While working on those, I realized something that I had completely forgotten about the original development process.

When I started this reconstruction, I thought the challenge would simply be getting the old code running again.

Instead, I ended up rediscovering why I developed it the way I did.

Back in 1986, the RTOS was developed on a SUN-2 with a Motorola 68010 and deployed on a separate 68000 target board.

I had always remembered debugging the kernel on the SUN-2.

What I had forgotten was why I stopped there.

During the reconstruction, I realized that this had been a deliberate engineering decision.

A fully preemptive kernel, including interrupt handling, context switching, and processor state management, is by far the most hardware-dependent and complicated part of an RTOS.

Implementing all of that on the host would have made the project much more complicated.

So I postponed it.

Instead, I developed almost everything else on the host:

• queues
• events
• timers
• scheduling
• message passing
• application logic

By the time the software was moved to the target hardware, most of the debugging had already been completed.

At the time, I don't think I consciously thought of this as a development methodology.

It was simply the most practical way to make progress.

Forty years later, reconstructing the project made me realize how effective that approach actually was.

Interestingly, I ended up following almost the same process again.

The original SUN-2 has been replaced by a POSIX environment.

The target will be a Raspberry Pi Pico.

A browser-based visualization was added along the way, but the overall host-target workflow is remarkably similar.

One thing that surprised me during this reconstruction is that the biggest changes rarely came from the original plan.

The browser visualization, for example, was inspired by WebAssembly that I encountered while working on an unrelated project.

It reminded me that engineering projects often evolve through unexpected discoveries rather than carefully planned roadmaps.

I'm curious whether anyone else has experienced something similar.

Have you ever reconstructed an old operating system, or any long-lived system, and discovered that the original engineering decisions made much more sense decades later than they did at the time?

For those who might care, I am continuing my series on what I learned this week while documenting my kernel. (https://github.com/tedavids/DragonOS)

1. I really hate documenting LOL. OK, I already knew this, but it is something that has to be done. And I'm glad I took some time to do it. It will help if I ever decide to do a 86_64 kernel.

2. There is really no such thing as 'AI Slop'. There is useful AI, kind of useful AI, and useless AI. I found a useful application of AI for my project. As those who follow know, I use QEMU to do most my testing, then move to a VirtualBox machine for secondary testing. This week I used AI to create a configuration for QEMU With specified memory, a single CPU, A SATA controller, a 100M Hard Disk, a CD ROM, and a USB 3.0. I did this because I have no real desire to learn all the in's and out's of QEMU. It is a tool much like a hammer. If you just want to drive nails, you don't need to know what the claw on the other end does.

3. I decided on my future course. Next I am going to start writing a SATA (AHCI) driver. I will use this to create a swap partition, and a regular file system partition on my drive. I know there a lot of steps between the drive and creating a partition. Much less writing the swap and file system portions.

4. I haven't shown any screens yet so I'll share one, it is incredibly boring, but a lot of work went into getting to 'Success' LOL

As always if you have any good resources for me, I will dutifully read them. I have couple of papers on single level store that I will be reading this week.

I hope you all have a good week.

KARM (Kernel Almost Reaching Milestones) is a small OS, I stole a LOT of code (thanks Lightweight AML Interpreter). Now I will admit, in the past I did use AI to write a lot of it (thanks to my idiocity) but I have stopped with doing this. Yes there are some remnents of me using AI in this, but I have stopped and have started to repair for my past sins.

Anyways I have been working on some fun things. I currently have:

• A simple test userland (a small shell that attempts to spawn applications, it causes a crash right now, but hey, thats a WIP)
• IOAPIC/LAPIC working
• ATA DMA access
• ATA PIO fallback (if DMA fails to initialize/is not supported on the hardware)
• A VFS (its not very good, a rewrite is in order since I rarely ever use it, its not even good enough to launch userland apps ffs)
• A functional PCI parser
• Functional (for the most part) AML thanks to the LAI project, which while no longer updated was pretty easy for me to implement (I would recommend if uACPI is too hard/weird for you to implement)
• Putting logs into RAM (able to be dumped during a kernel panic)
• A port of FATFS
• A HAL for disk access (three others exist but not worth mentioning)
• Syscalls for putchar and getchar, and of course full FS IO (you can do a write(1, string, size) if you want instead though)
• Ability to request pages from the kernel.
• Process killing, getting your own process ID, and spawning (spawning is broken for now) in the API.
• Unique API implementation (will explain later)
• Able to read ELF files (static binaries only)
• Round Robin scheduler.

The API:

Basically my API is not built around registers for every argument, but is instead built around passing a pointer to the kernel based on the standard request header, or cmd_ctx_t. cmd_ctx_t contains the standard header (size and revision) which I should really check but I never do (for now, yes its risky). Then each command parser for IO, scheduling, or memory, will then check the ctx pointer (if applicable to the command being used) or use ctx itself (say it might be a character) or ctx is not used at all. From there whatever is in the CTX/pointed to is used (for example it may be cmd_fil_t which contains info on file processes) and then things return.

Source: https://codeberg.org/KARM-Project/default

Hey guys,

For the past few months, I've been working on a hobby 32-bit x86 operating system called **nyanOS **. I wanted to move away from text mode as fast as possible, so I ended up programming the VGA registers directly (Mode 13h, 320x200x256 colors) to build a custom graphical user interface without relying on any BIOS calls after boot.

It's written in C and Assembly, booting via Multiboot.

### What's working right now:

* **Interrupts & Drivers:** Real IRQs for the PS/2 keyboard (IRQ1), mouse (IRQ12), and PIT timer (IRQ0). No busy loops for polling.

* **Window Manager:** Draggable, focusable, and z-ordered windows, complete with a taskbar and a start menu.

* **RAM File System:** A basic in-memory FS that handles real read, write, list, and delete operations.

* **Built-in Apps:** A working terminal shell, a text editor (Notepad with save/load), a basic mouse-driven paint program, and a local document viewer (packaged as a "browser" that reads a tiny custom markup from the RAM FS).

The source code is heavily commented, especially around the tricky parts like the GDT, IDT remapping, and direct VGA port I/O, because I wanted it to be readable.

* **GitHub:** https://github.com/yunusemreduran388-ux/NyanOS-v1

* **mywebsite** https://yunusemreduran388-ux.github.io/

* **Releases:** I also uploaded the pre-compiled `.iso` and `.elf` files to the GitHub Releases tab, so you can just grab the ISO and test it instantly in QEMU via `qemu-system-i386 -cdrom nyanos.iso` without needing to build it from source.

I posted this days ago but the 'automated admins took it down saying was generated by AI' as the formulation was maybe too academic. Trying now with other words.
Short storry: I wanted to generated python glue code for webgpu based on webgpu header. After exploring libclang and generating correct results, I wanted something more generic, more 'built in into C++'. At the beginning I thought will be easy with constexpr compile time tricks, but turned out the compile time 'runtime' is very restrictive. And I solved the challenges with ycetl. https://github.com/zokrezyl/ycetl

This is not a toy project, it is work of couple of months, fight with windmills of compile time runtime. If you see issues that can make it production ready, please share.

What the fuck is wrong with people on this subthread? I've been busting my ass for 6 months building my operating system, and all it took was a comment saying "vibe-coding" to destroy my post. What kind of mental retardation problems are you suffering from? The war against automated intelligence has turned you into idiots, you no longer know how to differentiate between a tool and a fucking human being. I'm also known to say that half of the Turing Award winners won it for their contributions to LLM models, you only know how to talk about slops? What the fuck is so backward? Thank goodness there's someone among you who understands people's efforts and isn't a fucking selfish person, because among all those who commented on me I haven't seen one who had created any content for this subthread on their page. What are you doing here? Are you here to insult? You're lucky to have an application that separates you from real life, you encephalitic bunch, start programming with perforated boards if you want to be purists, clowns, for everyone else instead a hug, we love you

I'm posting a video again, just to annoy, yes it's a slop, and it works better than yours, repeat out loud smp
Smp
smp👀

I've been working on PogOS for a little over a year and a half now. Recently, I just got .tga image rendering done. The GUI is far from finished, but I am happy with where the shell is.

On root, there's a config directory used to modify system files. There's not much there at the moment, but I'll add to it.

It can run doom, a calculator, a clock, something similar to xeyes, and images. Everything is made from scratch by me.

The filesystem is ext2 as the OS is x86, so it'll stop working in the year 2038. I plan on fixing it by then.

The wifi support won't work on real hardware, as the driver is made for much simpler hardware. I plan on working on a network abstraction layer next.

If you have any feedback or comments, let me know!

Finally transitioned to limine, thank god limine made the c templete since i failed so many times to use limine myself, repo: https://github.com/NoTheIdiot/WindogeOS

The creator of BoredOS writes under every post that my OS is Vibecode, because I have Claude as a contributor. It's immediately obvious that this person doesn't have a clear mind. So we decided to look at the BoredOS repo itself. "Fan fact: real Vibecoders shout loudest that other people are Vibecoders, but keep quiet about themselves." I'm attaching a screenshot with some lines from the BoredOS repo.

NexsOS1 is a multitasking operating system, with smp support for aarch64 and amd64, developed from scratch, the kernel is hybrid / monolithic with a tendency and research to be a microkernel, all applications (including the shell) are executables elf loaded from the file system, the system has been tested and stressed for hours with multiple processes running and is very reliable (we still have some kernel faults, but they have become very rare), the system was developed with all the means available in 2026, following a pragmatic approach and inspired by plan9, sel4, linux, windows nt, fucshia, macos and android, the system has a research purpose, and is basically simple and open source for projects that require an operating system with working graphics, and entirely readable without the accumulated complexity of linux, I do not consider myself an expert, nor one who wants to be, I just wanted to bring you a project that for me is fun and I am very fond of it

https://www.youtube.com/shorts/aCWWq5zwdOg
Except / or null byte.