What about using D for OSDev ?

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

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.

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

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

TL;DR: turbOS just got an update and its just awesome, without AI slop.

WELL, guess what?? I got a filesystem after a lot of hard work. Long live #NOAI, and this version includes proper PIT integration so screensaver and Pong game work at a sane speed. Next is the turbOS Networking, packages repo or idk what to add lol but I need to fix scrolling.

Sorry for bad spellings, just fumbled out of excitement!! Also late by one day bc of my temporary ban lol.

Link to repo: https://github.com/turbosulovesonions67/turbOS

Also the video of test on real hardware is about to be released by this Saturday (IST, 02/10/2026 or 10/02/2026)

Not sure how many people here are interested in iGPU driver development, but after a long battle, I finally got Intel HD 520 up and running on real hardware.

The display pipeline now works end-to-end, including the switch from the firmware-provided GOP resolution to the panel's native resolution. I also got a hardware cursor displayed through a dedicated Cursor Plane (the cursor icon was shamelessly borrowed from Ubuntu).

AI tools were a huge help along the way, acting as an always-available debugging partner with source code, and register dumps.

Seeing the first cursor appear on screen was surprisingly exciting after all the debugging.

And honestly, the iGPU experience is just buttery smooth. Definitely worth all the effort.

Source code: https://github.com/jjwang/HanOS

hello it has been a while, so i rewrote my OS kernel in C!

it has a little bit less features though...

check it out at https://github.com/hyperwilliam/untitled-kernel

:)

https://reddit.com/link/1wsym6q/video/w7p4i0p3mfsh1/player

nifanfa/re3generic: GTA III easy port software Open GL ES 1.1 rendering This is a portable GTA III project powered by re3symbian and Vincent GLES (a software-based OpenGL ES 1.1 implementation).
nifanfa/BootTo.NET: Providing a minimalist C# UEFI runtime with asynchronous support This is my hobby OS running the GTA III port.

This was a pain. To get any amount of good FPS I had to patch in a range cache for my garbage VMM and then fixup a few TLB shootdown hotspots.

Works though.

https://github.com/sasdallas/Ethereal

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!

maybe ill add pcie

In hobby kernels I often see one gigantic or smaller kernel.c file, I understand that it can also be a collection of all other elements of the initialization system, file system, etc. if it breaks down But why is kernel.c so often used and not, for example, main.c? It doesn't look like this: in the kernel workspace I have the usual main.rs in the main kernel segment without naming it kernel and then the whole crate works. But why the kernel for this glue of the entire system and what does this mean?

Plus the second question is why so few people think about a sensible allocator or scheduler, it's the first element I look at and these algorithms are often at the basic level But there is a graphical interface right away and I see that the allocator has major shortcomings and a high risk that it will allocate incorrectly with the interface and, for example, there are often no mechanisms to check if everything is correct.It works and you can already see graphical interfaces and window management, which supposedly gives you an interface if the system foundations are weak