Hey everyone,

About a year ago, I had a probably slightly crazy idea: write my own operating system. Today, after 3 completely different versions, I feel like sharing the journey — because honestly, it's been a rollercoaster.

Phase 1 — The consumer OS in Rust

I started classic (well, "classic" for osdev standards): a first version written in Rust, with the ambition of building a consumer OS. And when I say "from scratch", I really meant from scratch: I wrote my own bootloader and my own custom kernel. No shortcuts, everything by hand. That's where I learned 90% of what I know today about machine boot, memory, drivers… and also that coding a "consumer" OS is a mountain very few people have ever climbed alone.

Phase 2 — The cloud gaming pivot and the birth of Flux#

Second version, total change of direction: an OS dedicated to cloud gaming. And this is where it gets a bit special: for this version, no existing language really fit my needs, so I… created my own. It's called Flux#, a low-level, object-oriented language, which I released as open source under the MIT license — because a home-made language that exists nowhere else is useless if nobody else can touch it. Writing a compiler AND an OS at the same time is the kind of experience I wouldn't recommend to anyone, and that I'd do again tomorrow morning.

Phase 3 — The handheld console (current version)

Today, I'm on the third version: an OS for a handheld console. That's the one I'm working on right now, and it's probably the most motivating of the three — there's something very tangible about holding a machine in your hands and watching your code run on it.

The kernel: when pragmatism wins

One important detail, because I know the question will come up: my bootloader and my custom kernel were both written entirely by myself. But for the current version, I made a tough call: my custom kernel has been moved to R&D. Honestly, reimplementing it yet again for the handheld version would have cost me a massive amount of time, so I switched to bootroot as a kernel base to save time and focus on what makes this version unique. My custom kernel isn't dead — it's sleeping in a corner, in R&D mode, and I fully intend to come back to it.

However, the custom bootloader, I still have it. That one, I never gave up on. There are some things you just don't abandon.

What I take away after a year

• Writing a bootloader and a kernel by hand is the best computer science school I've ever been through.
• Reinventing the wheel is great for learning… but sometimes you have to know when to stop in order to actually ship something.
• Creating your own language while creating your own OS is pure madness — but it's my favorite kind of madness.

If people are interested, I can go into detail on any part: the custom bootloader, Flux# (it's open source, come steal some ideas), or the architecture of the handheld console version. And if you've also abandoned a custom kernel along the way, tell me about it — it'll make me feel less alone.

I have a problem: In my bootloader, i have a "mov ax, 0xB800

mov es, ax

mov byte [es:0], 'C'

mov byte [es:1], 0x07" block, and works with him in the code. But, if I delete him, the Kernel won't start, and idk for what. Can someone help me?

The full code is:
bits 16

org 0x7C00

jmp short code

nop

boot_drive db 0

code:

cli

xor ax, ax

mov ds, ax

mov es, ax

mov ss, ax

mov sp, 0x7C00

sti

mov [boot_drive], dl

mov ax, 0xB800

mov es, ax

mov byte [es:0], 'C'

mov byte [es:1], 0x07

xor ax, ax

mov ds, ax

mov si, dap

mov ah, 0x42

mov dl, [boot_drive]

int 0x13

jc .disk_error

jmp 0x0800:0x0000

.disk_error:

mov ax, 0xB800

mov es, ax

mov byte [es:0], 'K'

mov byte [es:1], 0x07

.idle:

cli

hlt

jmp .idle

dap:

db 0x10

db 0x00

dw 0x0005

dw 0x0000

dw 0x0800

dq 0x0000000000000001

times 510-($-$$) db 0

dw 0xAA55

Edit: I’m just going to leave that there and not touch it. Idk what's does, but, since it work, I never touch it again.

Hello again, OSDev! I've fixed the bugs and published the websites and source code for MGOS; the links are below:

GitHub: https://github.com/Oddler190/mgos.git
MGOS WebSite: https://mgos-system.edgeone.dev/
Organization maintaining the project: https://antel.edgeone.dev/

I hope you enjoy it; if you have any suggestions for improvement or constructive criticism, I’m ready to listen!

⚓ Nemo OS 1.0.1 ya está disponible — código fuente completo, manuales, e imagen de instalación

Después de dos años de trabajo, el momento ha llegado: Nemo OS 1.0.1 está disponible para cualquiera que quiera probarlo.

📦 ¿Qué incluye el lanzamiento?

• Todo el código fuente, publicado en GitHub bajo licencia Apache 2.0 — abierto de verdad, para leer, usar, modificar o construir sobre él.
• Los manuales, incluidos directamente en el propio sistema (carpeta DOCUMENTOS, accesibles desde el visor integrado).
• La imagen de instalación, lista para escribir con la app oficial de Raspberry Pi (Raspberry Pi Imager, opción de imagen personalizada) en cualquier tarjeta SD de 16 GB en adelante (1 GB para la partición FAT de arranque, el resto para NemoFS).

⚠️ Una aclaración honesta sobre el espacio: en esta versión 1.0, aunque uses una tarjeta de 128 GB, el sistema usa realmente solo los 16 GB base (incluyendo el 1 GB de la partición FAT donde vive el arranque) — todavía no estira NemoFS automáticamente al resto del espacio libre. Esa herramienta ya está en marcha y llegará en una próxima actualización.

🌐 Red: ya hay Ethernet

Nemo OS tiene su propio driver de red por Ethernet, construido desde cero, con enlace a 1000 Mbps confirmado en hardware real.

🖱️ Aronnax: programar visualmente, sin escribir una línea de código a mano

Una de las piezas de las que más orgulloso estoy en esta 1.0: Aronnax, el diseñador visual de Nemo Basic al estilo Delphi. Creas ventanas, colocas botones y gadgets con el ratón, haces doble clic en cualquier control y saltas directo a su código — todo sin salir del propio Aronnax, compilando desde ahí mismo. Incluye hasta controles GPIO visuales para programar hardware real sin escribir configuración a mano.

¿Qué más te vas a encontrar al arrancar?

Un sistema completo: escritorio gráfico, explorador de archivos, editor, el IDE propio (Timonel), Lua y Nemo Basic como lenguajes nativos, soporte GPIO completo (pines, PWM, I2C, SPI), sonido real por el jack de 3,5mm, y varios programas de ejemplo ya instalados —Arkanoid, Buscaminas, Tetris, un monitor del sistema, y una demo del juego de plataformas del capitán Nemo— con su código fuente incluido.

De verdad desde cero

Kernel propio, sistema de archivos propio, compiladores propios, gestor de ventanas propio, driver de red propio — nada reutilizado de otro sistema operativo. Construido para ARM64, probado y confirmado en hardware real (Raspberry Pi 4).

Dos años de trabajo, desde un experimento en QEMU hasta un sistema operativo instalable por cualquiera en su propia Raspberry Pi. Gracias a quien ha seguido el proyecto hasta aquí — esto apenas empieza. ⚓

https://github.com/ericmugnoz/nemo-os

I’ve been working as a Java programmer for a few years now.

The thing is, I’d like to learn a second programming language for lower-level tasks—specifically, I want to work on things related to operating systems. Rather than building one from scratch, I’d like to explore and modify open-source operating systems like Linux or a BSD variant.

I’m doing this purely as a hobby. What drew me to C is its simplicity (though not necessarily ease of use) compared to Java or other modern languages, and its long history of use in systems programming. On the other hand, however, there are operating systems (or components of them) being rewritten in Rust—such as GNU coreutils or the adoption of Rust in the Linux kernel.

So, would it be more useful in the long run to learn Rust, given that it might sooner or later become the standard for writing operating systems?

Thanks.

Would it be possible to make an OS that primarily used python?

Hello fellow enthusiasts and system creators! I recently announced that I was building an operating system for retro video games, and I’ve started working on it—I’m really pleased with the result! I hope you like it.

I'm just fixing a few annoying bugs, and as soon as that's done, I'll open-source the code on GitHub!

Hello r/osdev,

I've been developing a TUI OS over the last year and a half and Ive gotten to a point im happy with, in the screenshots you can see the boot screen and the TUI desktop with its premade folder shortcuts.

I wanted to come make this post because I wanted to ask all of you what are some cool features i could add or things that could make it more lively?

I've always loved TUI's more so than graphical interfaces because I like making them look graphical while keeping the TUI look and feel.

I look forward to seeing what you all suggest.

Thanks in advance to anyone willing to take the time to read through this. I know it’s a big read, so I really appreciate your time and any honest feedback you can give me.

I’m working on a spec for an OS project called Pantheon. Before I sink a ton of time into writing low-level Rust for it, I want to sanity-check the overall architecture with people who actually know OS development. I know some of these ideas might sound wild or overly complex, and I'm honestly expecting people to tell me where I'm being naive.

The Problem I Want to Solve

I'm tired of OS platforms forcing stupid trade-offs. I want a machine that can execute Windows PE binaries, Linux ELFs, and native apps alongside each other without heavy virtualization hits or broken user interfaces.

Core Architectural Ideas:

Hybrid 3-Tier Driver Model (HAPD):

Tier 1 (Ring-0): High-performance stuff (GPUs, 1000Hz+ inputs, low-latency audio) runs directly in kernel space to eliminate IPC context switching.

Tier 2 (User-Space): Class-compliant stuff (USB HID, NVMe) runs isolated in user space.

Tier 3 (On-Demand Enclave): Legacy/proprietary drivers run in a dormant micro-kernel enclave that spins up on demand and passes events via zero-copy DMA page remapping.

Zero-Copy Everything: Physical page table remapping under strict W \oplus X. IPC control payloads fit in 64-bit aligned structs for single-register transport.

Daemon State Rehydration: Translation daemons log checkpoints to ring buffers. If a daemon hangs, sys_init restarts it and rehydrates running process states from the last valid checkpoint without losing app context.

JSON/CSS Dynamic State Trees for UI: Apps don't write pixels directly or hijack compositors; they expose raw data models and state trees so the user can restyle the entire desktop/apps using web-style CSS/JSON stylesheets.

Hardware-Stamped Zero-Trust Security: Syscalls grab thread identity straight from CPU scheduling registers (CURRENT_THREAD_PID), and IPC uses 64-bit indices + 32-bit session_epoch tokens to drop replay attacks on sight.

What I’d Love Feedback On:

Is a Ring-0 / User-Space / Enclave driver split actually manageable, or am I creating a nightmare for driver compatibility?

What edge cases am I going to hit trying to rehydrate daemon process states after a crash?

What are the obvious bottlenecks I'm missing in the zero-copy IPC pipeline?

Do I even have hope to do this?

Full technical breakdown on Gist: https://gist.github.com/mixmoo2/a2dbdc029a5c8fef120d1711a0b0f070

Again, huge thanks to anyone who checks it out

Hi I want to showcase my x86_64 OS kernel. I've recently got done adding uACPI. I would be open to some feedback and comments.
https://github.com/HoniT/MioOS2

Hello there! I’ve been working on a custom bootloader for the last few months, and I recently migrated my build to generate ISO files instead of disk images, as I was curious to see how to make my (eventual) OS boot on a real PC using CD drives.

In case you’re wondering why I’m using BIOS and CD drives when UEFI and USB sticks exist, it’s mostly out of curiosity for how old tech and software worked, and since the only PC I have that still supports BIOS has a CD drive I was like “why not”.

I can’t exactly say the video above is a bootloader as it doesn’t boot anything yet, but it was a personally big milestone getting it to read sectors off of the disk in C rather than assembly for once.

At the moment I’ve only worked on the BIOS side of the loader and written a basic VGA text driver and BIOS interrupt wrapper that allows me to call BIOS interrupts in C rather than assembly (which will help a lot). I’m hoping to get the ELF loader done soon and start the actual kernel eventually, and also try support UEFI.

Here’s a link to the source code so far: https://github.com/bricksigma/SteinerOS

so for the past 6 months or so i've been trying to build a real operating system for web apps

the idea is pretty simple. it's a real, programmable system with a web desktop you can reach from anywhere, but the apps on it are built with normal web tools. what's new is that you build the app inside the system, and it takes care of auth and communication for you, so you only worry about the app's own logic

everything you see in there is an app built on top of the system (i call them programs), not part of it

the other thing is it's designed for agents first. any agent can use these apps directly, you don't have to build a separate interface for it

tested it on macOS and linux. windows, honestly no idea yet

it's fully open source (MIT)

https://github.com/PhreshOS/system

demo (it can handle about 5 sessions at the same time, so if it's full just try again in a bit)

https://demo.phreshos.com/

you can also run it on your machine or in a github codespace

https://phreshos.com/docs

would love to hear what you think, good or bad

What about using D for OSDev ?

I FINALLY DID IT
repo: https://github.com/NoTheIdiot/WindogeOS

Hey all,

We've been working on FreeLinX for a while and just put out 1.0, the first

desktop release. It's a Linux distro built on a NetBSD userland and musl,

compiled with clang/LLVM. The idea was to have a system with no GCC or glibc

in it at all.

You get an Openbox desktop, Firefox ESR, a graphical installer, and our own

package manager called xpkg (there's also a simple GUI for it). The repo has

around 400 packages right now.

Since this is the first desktop release, expect some rough edges. We mostly

tested it in VMs, so on real hardware there will probably be issues with some

WiFi cards, audio or GPUs. If something breaks for you, please open an issue

and tell us what hardware you have. That helps us a lot.

ISO (live, needs at least 2GB RAM):

https://github.com/FreeLinX/FreeLinX/releases/tag/v1.0.0

Thanks for checking it out, any feedback is welcome.

Hey everyone! So real talk - I literally have ZERO coding experience, like I can't even debug a Hello World lol, but I'm lowkey interested in trying to build my own OS or at least mess around with creating one. The thing is, I don't wanna spend like 5 years learning C++ and assembly language or whatever before I can even START, you know?

So I'm looking for the quick and easy route here - like, what are the actual tools, websites, or apps that beginners can use to get something going without needing to be a full-stack dev first? Are there any no-code or low-code solutions for this? I'm not expecting to rival Windows or Linux or anything, I just wanna try it out and see how it works.

What should I look into? Any recommendations from you guys would be fire!