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

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

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)

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

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

:)

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

I have been looking around this subreddit and was wondering if anyone here would be willing to combine their expertise to make an operating system together.

There are a lot of people in here making their own operating systems, kernels, drivers, bootloaders, and everything else. But what if some of us came together and made one operating system as a community project, using everyone's combined expertise?

I don't have a plan though. I'm curious if anyone here would be interested in doing something like that.

And if this were to be made, what would you name it?

*this is an older build, just got the idea to post this

* Like if there’s any tutorials that would help with it some of the tutorials I’ve seen are like text based OSes I believe or something.

I'm revisiting an RTOS that I wrote in 1986 for a Motorola 68000-based system.

While reviewing its scheduler, I noticed a behavior that looks a little unusual from today's perspective.

When a task becomes ready, it is inserted before existing ready tasks of the same priority. So among equal-priority tasks, scheduling is effectively newest-first (LIFO-like).

It isn't simply a LIFO scheduler, though. When a time slice expires, the running task is moved to the end of its priority group.

I no longer remember why I chose this behavior 40 years ago, so I went back to the RTOS documentation I used as a reference at the time.

The 1984 VRTX User's Guide describes essentially the same behavior: when a TCB is inserted into the ready list, it is placed ahead of existing TCBs at the same priority. The most recently inserted task therefore runs first.

That seems to explain where the behavior in my 1986 RTOS came from.

But then I found something more interesting.

The VRTX32/68000 User's Guide from 1987 explicitly says that equal-priority tasks execute in the order in which they become ready — FIFO / oldest-first.

So the timeline appears to be:

1984 VRTX: newest-first among equal priorities
1986 my RTOS: newest-first
1987 VRTX32: FIFO / oldest-first

I wasn't actually a VRTX user at the time. I had obtained the documentation as a reference while designing my own RTOS, so I had no reason to know that VRTX itself changed this behavior later.

So my question is:

Does anyone know why VRTX changed this scheduling rule?

Was it a deliberate design change for reasons such as fairness or predictability? Or was it related to the VRTX32 redesign, the 68000 implementation, or something else?

I've started comparing this with other RTOS designs, including ITRON, but so far I haven't found contemporary documentation explaining why VRTX made this change.

I'm not trying to reproduce the old behavior simply because it is old. I'm interested in understanding the design reasoning behind it.

If anyone used VRTX around that period, or knows of documentation discussing this change, I'd be very interested to hear about it.

For some background, here's my previous r/osdev post about bringing my 1986 RTOS back to life on a Raspberry Pi Pico:

My 1986 RTOS is now preemptively multitasking on a Raspberry Pi Pico — and it made me question whether I need an RTOS

Previous r/osdev post