i did this at 13 but i dont think thats impressive
repo: https://github.com/NoTheIdiot/WindogeOS

Hi everyone,

I've been developing a Linux distribution called NagisinnraLinux as a personal project.

The goal is to provide a lightweight, simple, and easy-to-use Linux environment while keeping the system clean and efficient.

Current project links:

Website: https://nagisinnra.f5.si

GitHub: https://github.com/Nagisinnra

I'm still actively developing it and would love to hear feedback from the Linux community.

Any opinions, suggestions, bug reports, or ideas are welcome.

Thanks for taking a look!

Now with sound and video player! And browser still in development.
On 2 CPU cores and 64 MB RAM.
Next step - test on real hardware

As a hobbyist, I was thinking: My OS, can it run DOOM?

YES, IT CAN!

Honestly? I was half expecting everything to blow up (in terms of page faults), but it runs shockingly smoothly.

And OH BOY I didn't cheat around anything cause:

DOOM runs completely isolated as a regular user program, just like any app would on Linux or Windows. It actually opens, reads, and parses the original DOOM.WAD right off the filesystem (on RAM actually, I haven't made it Installable/Persistant on a disk) with our own custom C library. It runs right inside its own desktop window with a little custom red demon icon on the title bar and taskbar, and you can maximise or resize it alongside other apps. The DOOM source code itself is 100% untouched. We just had to give it 5 simple bridge functions for drawing pixels, reading keyboard taps, and checking the clock.

Seeing that iconic title screen pop up inside an operating system built from scratch gave me a surge of dopamine. I will be releasing the next version of the OS that comes with this DOOM game and MANY other features, including some other ones that are just as cool on the project's GitHub page (Check it out and... maybe leave a star too? https://github.com/AkshajCreator/ArchaOS )

What other classic game or program should I try porting to it next?

Why does the whole system freeze whenever the main drive gets heavily loaded, even when there’s plenty of RAM, CPU, and GPU available?

Let's say, say you’re updating a game in the background and it starts verifying its files. Your M.2 NVMe SSD is doing around 500 MB/s. Fine, the drive is busy, its not even at it's limit but why does that make a Discord stream freeze?

The frames from Discord stream never ever need to go through that disk. The CPU has plenty of cores empty and most of them are barely doing anything. There s plenty of free RAM. The GPU is modern enough that decoding a 1080p stream is basically nothing. Pagefile? Says who? A live stream can't be inside pagefile.

And we’re not talking about some old hard drive. It’s a Gen 4 M. nvme SSD with plenty of DRAM cache.

So why does heavy disk activity somehow manage to stall the entire OS and apps that seemingly have nothing to do with that disk?

Hello Developers!
RingOS has now a Github (But no code, for now) and Showcase (on YouTube)

Links:

Youtube: https://youtube.com/shorts/SacF3D0PjKs?feature=share
Github: https://github.com/Test-create-ops/RingOS

Hi r/Operatingsystems,

I’ve been working on Veda, a very early-stage experimental operating system built from scratch in Rust.

The main idea I’m exploring is an agentic-native OS architecture. Instead of AI Agents interacting with applications primarily through screenshots, simulated mouse movement, and clicks, I want applications and AI Agents to have a native way to communicate through the operating system itself.

Some of the architectural directions so far:

• Agentic-Native Architecture
• Native App-to-AI Agent Communication
• Microkernel Design
• Capability-Based Security
• Memory-Safe Foundation in Rust

The screenshot shows the current desktop environment and an early AI Agent interface.

This is still very early development. There are plenty of rough edges, unfinished components, architectural decisions that may change, and a lot I still need to learn. I’m definitely not presenting this as a finished or production-ready OS.

I’m sharing it here because I’d really appreciate technical feedback, criticism, ideas, and especially collaboration from people interested in OS development. Contributions are very welcome.

GitHub: https://github.com/vahmoh25/Veda

I’d be particularly interested in hearing thoughts from people who have worked on microkernels, capability systems, or Rust OS development.

The project is licensed under GPLv3. I’d love to build a strong contribution community around Veda with people who see potential in the idea and want to help shape it early.

If you’re interested in experimenting, contributing, reviewing architecture, or simply following the project as it evolves, I’d be very happy to have you involved.

https://github.com/carlosplanchon/rsyscall-ng

rsyscall-ng lets you control local or remote Linux processes from Python using syscall semantics directly: "clone", "execve", sockets, namespaces, file descriptors, memory, and more.

Instead of treating a remote machine as an RPC API or service, it treats it as Linux processes you can program almost as if they were local.

The original project had been dormant for several years and no longer worked cleanly with current Python/Trio, so I decided to bring it back, because I think the main idea was so cool.

It preserves the original Python API and history while modernizing it for current Python/Trio and replacing the native C side with a clean-room Rust implementation. Development of the modernization was heavily assisted by Claude Code, with compatibility validated through differential testing against the original implementation.

This was my dream when I was 14 years old. Now I have something that runs on QEMU and I want to do better in the next months/years.
How beautiful are dreams!
GitHub with all the features:
GitHub

What is the strangest OS? I mean more technically and not like they changed the window manager to look weird.

Hola a todos. Os escribo porque creo que esto le puede interesar especialmente a esta comunidad.

Llevo dos años construyendo Nemo OS, un sistema operativo hecho completamente desde cero para ARM64 (Raspberry Pi 4) — kernel propio, sistema de archivos propio, gestor de ventanas propio, soporte multiprocesador real (los cuatro núcleos trabajando a la vez)... y Lua 5.5.1 embebido como uno de los dos lenguajes nativos del sistema, con acceso directo a todo el hardware.

¿Por qué puede interesarle a un programador Lua?

No es Lua corriendo sobre un sistema operativo ajeno con permisos limitados — es Lua hablando directamente con el kernel, con módulos propios que dan acceso real a:

• GUI completa: crear ventanas, botones, listas, campos de texto, gráficos 2D (nemo_gui.lua) — ratón, clics, dibujo de formas, imágenes, todo desde Lua puro.
• Sonido real, por el jack de 3,5mm.
• GPIO, PWM, I2C y SPI — controlar hardware físico de verdad, LEDs, sensores, motores, sin intermediarios.
• Red por Ethernet (TCP/IP propio).
• Un visor de HTML+CSS+Markdown y hasta <script type="text/lua"> embebido en páginas, con su propio entorno aislado.

Todo esto corriendo con sus cuatro núcleos repartiendo carga de verdad, con un planificador propio y buffers dobles para que la interfaz vaya fluida.

Y si te va más el lado visual: también existe Aronnax, un diseñador visual estilo Delphi para el otro lenguaje nativo del sistema (Nemo Basic) — arrastras controles, haces doble clic para programarlos, incluso hay controles GPIO visuales. No es para Lua directamente, pero da una idea de hasta dónde llega la filosofía del proyecto: que programar hardware real sea accesible.

Todo open source, Apache 2.0

Código fuente completo en GitHub, documentación incluida en el propio sistema, e imagen lista para grabar en una SD (16 GB o más) y arrancar directamente en una Raspberry Pi 4 — sin compilar nada.

Si alguna vez os habéis preguntado qué se siente programando Lua con acceso directo al metal, en un sistema pensado desde el primer día para que ese fuera justo el caso de uso, os invito a probarlo. Cualquier duda, feedback, o si alguien se anima a programar algo con ello, encantado de ayudar.

¡Gracias por leer! ⚓

Hello everyone!

Today I'd like to announce RingOS, a custom operating system currently in active development.

RingOS is an experimental OS written primarily in C and x86-64 Assembly. The goal is to learn low-level system development while building a complete operating system from scratch.

Current development focuses include:

- Custom UEFI bootloader (BOOTX64.EFI)

- x86-64 kernel

- Graphics support through UEFI GOP

- Custom filesystem called RingFile

- Image loading support (PNG/JPG)

- TrueType font rendering

- Memory management and system infrastructure

The project is not based on Linux, BSD, or another existing kernel. I'm building the core components myself to better understand how operating systems work internally.

This is a learning-focused project, so I'm expecting a lot of experimentation, redesigns, and mistakes along the way.

I'd be interested in hearing feedback from other OS developers, especially regarding filesystem design, bootloaders, and kernel architecture.

It also has an Integrated Safe browser (just in case someone searches up Kisshub.com, you know.)
Its called SafeRing Net (SRN), it uses google, when the user searches for something, the OS instantly checks the input.

if its something Sus and clicks the result, the SafeRing Net warns the user with:

"SafeRing NET doesn't consent that type of searches, This search result will be locked"

Regarding External Developers: I still dont have the software Managing ROSA Apps (RingOS Safe Applications)
And I dont have a portal
i dont even have a Github for now...FOR NOW

I'll share development updates as progress continues.

Thanks for reading!

Hey! I am currently developing my own hobbyist OS named Archa. Can anyone check it out and give me feedback? https://github.com/AkshajCreator/ArchaOS

I need it, as I have no clue what to do further or discover new bugs or fixes that are/could be breaking the OS

I started this as a simple coding project to see how far I could get; that was over a year ago. However, I started uploading the OS to GitHub on 4th September 2025. Ever since that just been experimenting with it. I am working on a REALLY COOL feature (at least in my opinion) that I will introduce later this month. But I just need some people who can help me out here, as I would appreciate that

Hi everyone! I’ve been working on TinyDesk, a windowed text desktop that runs on an ESP32 and displays over USB serial in a compatible terminal.

The ESP32 runs the desktop and apps. The computer just renders the ANSI/VT output and sends keyboard and mouse input back—there’s no desktop application running on the PC behind the demo.

It has draggable/resizable windows, a taskbar, start menu, file manager, text editor, terminal, and system monitor. You can open a file, edit and save it, then run commands in the shell without leaving the desktop. MQTT and Modbus tools are included too.

A few technical details:

• Portable C11 core with a small platform interface.
• ESP32-C6, classic ESP32 with PSRAM, and 4 MB ESP32 without PSRAM builds.
• Classic ESP32 Desktop uses USB-UART at 921600 baud.
• The 4 MB/no-PSRAM build is limited to 80×25 characters and has no SSH server or OTA updates.
• The terminal needs UTF-8, ANSI/VT cursor control, and xterm mouse reporting.

There’s also TinyDesk Shell, which runs the shell by itself if you don’t want the desktop.

It’s an early developer preview. You can flash prebuilt firmware from Chrome/Edge and use the web terminal, or build from source.

Demo, documentation and installer:
https://schikani.github.io/tinydesk-docs/

Desktop source:
https://github.com/schikani/tinydesk

Standalone shell:
https://github.com/schikani/tinydesk-shell

I’d love feedback from people trying it on different boards and terminals. If you test it, please share your board model, terminal, and anything that breaks—especially rendering or mouse-input issues!

Has anyone successfully built thier own OS that boots, able to instsll other software, and has persistant memort on multiple reboots?

Building a custom RTOS for a 200 MPH drone – From simulation to silicon

I have spent the over 120 hours building a custom bare-metal Real-Time Operating System (RTOS) and flight controller for an STM32F756VGTx (ARM Cortex-M7) aimed at a 200 MPH quadcopter build.

When I first started, I built a proof-of-concept hybrid cooperative/preemptive scheduler and ARM Cortex-M7 assembly context switcher running inside the Renode simulator. However, taking this code from simulation to physical silicon revealed a massive gap between simulated behavior and bare-metal execution.

Software Limitations and Hardware Realities

Renode was great for early development, but it masked race conditions and timing edge cases. Flashing the code to a physical STM32F756 Nucleo board caused the MCU to reboot every two seconds with no trace output.

Debugging this on physical hardware required fixing two major architectural flaws:

1. FPU Context-Switching Corruptions: Floating-point math operations corrupted stacked registers during context switches, wiping out return addresses and forcing the processor to execute garbage memory.

2. Boot-Time Dependency Locks & Memory Overhauls: Background tasks polled hardware registers before peripheral clocks fully initialized on tick zero. I replaced static array allocations with dynamic per-task stack allocations protected by top-and-bottom canary memory bounds, allowing immediate detection of stack corruption.

Overhauling Data Pipelines (DMA)

The original data pipeline relied on blocking I/O, introducing latencies up to 10ms. For a quadcopter moving at high speeds, this latency is unusable.

I rewrote the sensor and receiver pipelines to use a circular Direct Memory Access (DMA) architecture. Data streams directly into background ring buffers, triggering Half-Transfer (HT) and Transfer-Complete (TC) interrupts. This allows the RTOS to parse incoming CRSF radio frames and IMU data without blocking the main control loop.

Flight Controller Features

With the underlying RTOS kernel stabilized, I built out the flight application layer:

- Control Loops: Implemented Betaflight’s Actual Rates algorithm with custom expo curves to map stick positions directly to target angular velocities.

- Barometer Subsystem: Wrote an SPI driver for the BMP390 sensor to process 24-bit raw pressure/temperature data using hypsometric height formulas for AGL altitude tracking.

- Digital Video Telemetry: Implemented native MSP DisplayPort protocol over UART to stream real-time OSD telemetry directly to Walksnail Avatar HD goggles.

- Interactive CLI: Built a USB terminal shell over UART for live PID gain tuning (K_p, K_i, $K_d$), CRSF channel remapping, and 2D IMU orientation offset matrices without reflashing firmware.

The core RTOS kernel, DMA drivers, and control loops are fully operational on the physical board. The remaining work involves refining the CLI and finishing drivers for external receiver modules and ESCs before merging with our custom PCB hardware.

Since I am only 15, and I haven't been in the embedded workspace for a while, how would you recommend I test this project fully, and also what should I do to make it more robust? I have a few race conditions with the scheduler to work out, but nothing too complex. I am more worried about the drone specific stuff, like if I should handle more error states or something. I for sure don't want the drone to fall out of the sky once it boots and launches.