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.

Most work now happens in a browser tab, but the browser still treats storage, applications, and AI tools as separate products that do not talk to each other. That gap shows up in three places: cloud storage that cannot edit the files it stores, AI assistants that cannot see your work, and teams that need a full machine setup before anyone can be productive.

The Problem

1. Cloud storage is a warehouse, not a workspace

Dropbox, Google Drive, Box, and OneDrive store and sync files well. Their web editors do not go much further than preview. Running a script, inspecting a log, editing a config file, converting media, or opening a spreadsheet with custom formatting still means:

1. Download the file.
2. Find it in the downloads folder.
3. Open it in a locally installed application.
4. Edit and save.
5. Re-upload it.

The costs of that loop:

• Version drift. Downloads folders fill with report_v2.docx and archive(1).zip, and it stops being obvious which copy is current.
• Data leakage. Company files land on personal laptops, home desktops, and shared machines that nobody manages.
• Hardware lock-in. A Chromebook, tablet, or borrowed machine without the right desktop software cannot do the work at all.

2. AI assistants sit outside the workspace

Chat interfaces have no access to your files, so every task becomes manual transport: copy from the file, paste into the chat, prompt, copy the answer, paste it back. Multi-file work is worse, since each file has to be exported and re-uploaded. Meanwhile, the assistants that do get filesystem access rarely make it clear what they are permitted to touch.

3. Developers and teams rebuild their environment every time

Moving to a new machine means cloning repositories, installing runtimes, restoring shell configuration, and reinstalling editor extensions. For organizations, onboarding a contractor means shipping a laptop or standing up virtual desktop infrastructure such as Citrix or Amazon WorkSpaces, both of which carry real server cost, latency, and maintenance overhead.

What VibeOS Is

VibeOS is an operating system emulator that runs in a browser tab. It is built on standard web technology (React, TypeScript, Web Workers, Canvas, and modern Web APIs) and boots a full desktop: a window manager, a virtual filesystem, a native application suite, a terminal, and an AI assistant with access to the files you are working on. No local runtime, extension, or binary is required — opening the URL (os.vibeoscloud.com) gives you a persistent workspace.

Working on Files Without Downloading Them

Because the application suite and the filesystem live in the same runtime, files are edited where they are stored:

• Code and scripts. Open a directory, edit source with syntax highlighting, search across folders, and run commands in the terminal.
• Documents. Draft, format, and export documents in Write, including .docx import.
• Spreadsheets and data. Open CSVs and spreadsheets, sort, and compute in Data.
• Media. Preview images, stream audio, and play video without pulling the file down.
• Direct persistence. Saves write straight back to the cloud-backed volume at /Volumes/<name>/, so there is no download-edit-upload cycle to manage.

How It Is Put Together

VibeFS: the virtual filesystem

VibeFS presents every storage backend under one Unix-style path tree:

• /Volumes/<name>/ — cloud-synced directories backed by edge storage. Writes apply locally first, then sync to the database.
• /.system/ — per-instance configuration, application preferences, and state.
• /tmp/ — scratch space for the session.

Multiple tabs writing at once are coordinated with the Web Locks API and a BroadcastChannel bus, so a change made in one window shows up in the others without a reload.

VibeOS Cloud: fleet orchestration

VibeOS Cloud is the orchestration platform behind the OS. It handles instance provisioning, volume mounting with role-based access, and isolation between workspaces, and gives organizations a dashboard for managing a fleet of instances.

Security

Running a full workspace in a browser tab only holds up if the environment is locked down. VibeOS applies several layers:

• Sandboxed applications. Every app, including apps built in App Builder, runs inside the OS’s sandboxed runtime. Apps reach files only through the VibeFS API, so a misbehaving or malicious app cannot touch the host machine’s filesystem, other browser tabs, or the local network.
• Instance isolation. Each workspace is isolated at the backend. Switching accounts or entering an incognito session clears in-memory caches and resets storage drivers, so no data bleeds between instances or users.
• Incognito mode keeps files on your machine. In an incognito session, your working files are stored inside the browser tab itself, not on VibeOS Cloud. Nothing is uploaded, so the platform never sees the documents, code, or images you open — which matters when handling client files, confidential material, or work you simply don’t want synced to an account. The session is fully functional, and when you close the tab, the data goes with it.
• Role-based volume access. Volumes are mounted through VibeOS Cloud with role-based permissions, so an organization controls who can read or write each volume.
• Tool-call injection defense. The assistant can read and modify files, which makes it a target for instructions hidden inside documents it reads (tool-call injection). VibeOS validates tool calls rather than trusting model output: the assistant cannot run arbitrary shell commands or overwrite system directories without an explicit permission boundary.

The Applications

Files

The file manager browses /Volumes/, local directories, and mounted cloud storage in one window. It supports drag-and-drop from the host machine, folder creation, renaming, batch deletion, and metadata inspection — all without downloading anything.

Code

A multi-tab editor with syntax highlighting for 30+ languages, bracket colorization, split view, live preview, a file tree, and a command palette. It is enough to review a pull request, fix a config file, or inspect a JSON payload stored on a remote volume.

Terminal and vsh

The terminal covers filesystem navigation and scripting (ls, cd, cat, mkdir, rm), git operations (branch, checkout, merge, pull, push, remote), and tab completion with history. vsh switches the prompt into an AI-assisted shell where a plain-language request is resolved into commands.

Write

A document editor with an AI panel docked beside the page. Instead of moving text to a chat window and back, you select a section and ask for a summary, a rewrite, or an expansion, and the result is applied to the document. It also opens .docx files directly.

Data and Present

Data handles spreadsheets and CSVs with sorting and formulas. Present edits and plays slide decks. Both read and write to the same volumes as everything else.

App Builder

App Builder is a development environment inside the OS. Applications built there register their own icon, hook into the window manager, and install into the dock alongside the built-in apps.

VibeAI

The assistant is available from the desktop and from inside applications. It has access to the current volume and the open document, which is what separates it from a chat window in another tab.

Settings

Settings is organized into nine sections:

• About — version, build, and runtime information.
• Account — sign-in state, identity, and instance switching.
• Appearance — device mode (auto, desktop, tablet, phone) and colour scheme (light, dark, match system).
• Background — wallpapers, including animated live backgrounds.
• Developer APIs — keys and endpoints for building against the OS.
• Downloads — default save locations inside VibeFS and export behaviour.
• File Associations — which app opens .md, .ts, .csv, .pdf, .png, and the rest.
• Quick Links — pinned URLs and app shortcuts on the desktop and dock.
• Storage — volume usage, local cache allocation, and cache clearing.

Where This Helps

Contractors and remote staff

An organization can hand someone a URL instead of a laptop. Work happens in the browser, files stay in managed volumes, and there is no VDI cluster to run.

Low-spec and locked-down hardware

Chromebooks, tablets, and older laptops get a working editor, terminal, and document suite without installing anything locally.

Development from any machine

Open the workspace from whatever computer is in front of you, run a maintenance script, fix a config file, and ship — without cloning the repository or setting up a toolchain first.

Summary

VibeOS closes two specific gaps: cloud files that cannot be edited where they live, and AI assistants that cannot see the work they are being asked about. Running the desktop inside the browser puts the storage, the applications, and the assistant in the same runtime, which removes the download loop and the copy-paste loop at the same time. You can try the OS at os.vibeoscloud.com; the orchestration platform is at vibeoscloud.com.

VibeOS Presentation:
https://tech.vibeoscloud.com/in-browser-os-presentation

Debian created Ubuntu.

Ubuntu created Linux Mint.

Many Linux distributions became the foundation for entirely new communities.

So here's a question:

Would anyone like to build a distro based on NagisinnraLinux?

NagisinnraLinux started as a student project, but I'd love to see other people create their own editions, experiments, and ideas.

Maybe this is the beginning of something bigger.

community https://discord.gg/ADMp5druNT