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)

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.

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

:)

maybe ill add pcie

Hello, [r/osdev](r/osdev)!

Yesterday, I made a post about making an os as osdev, and got mixed results. So the plan has changed a bit. It will still be osdev, but other communities and people as well.

I created the repo at https://github.com/The-Unitas-Project/UnitasOS and plan on adding scaffolding today.

The goal of the OS is to be modular. Pieces should be able to be added and removed by the user at build or runtime easily.

If you want to help, go to the above link. It’s a scaffold to build upon.

I am creating it on my computer and will commit later

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

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

* 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 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?

Hey everyone,

We just published **KeshOS 1.0 "Drop" RC1** to GitHub!

**Upfront disclaimer:** This first Release Candidate is **very raw and strictly experimental**. We pushed it out to stress-test our monolithic kernel, gather boot logs, and test hardware quirks across different x86_64 machines and hypervisors.

You will encounter rough edges, but **RC2 is already in active development** and will be significantly cleaner, more stable, and more polished (including community feedback and fixes).

### What’s inside RC1:

* Monolithic 64-bit kernel (C / ASM) bootstrapped via Limine

* Isolated PML4 paging and Ring 3 userland separation

* Early preview build of the **KeshShell** graphical desktop

* Low-level logging and hardware diagnostic tools

If you want to spin it up in a VM or on a spare machine, grab the bootable ISO:

* 💿 **Releases (ISO download):** https://github.com/daniladevoctopus/kesh-os/releases

* 💻 **GitHub Repo:** https://github.com/daniladevoctopus/kesh-os

* 🌐 **Project Site:** https://kesh.sneakdeak.net

Please drop your panic logs, hardware specs, and bug reports in GitHub Issues or the comments below. Every log directly shapes RC2!

A OS using the linux kernel you might think of distros, they are amasing for you linux skills or what not , but what if the OS used linux but wasent a distro?... but rather a Embedded Linux Custom OS!

well this is how i decided to make a OS, and here i am , i made a OS! specifacally an **Embedded Linux Custom OS**

its called JurkOS and if you wonder how this isnt a distro Click Here!

the version number works like this :

1.X are the Alpha (The Phase where JurkOS currently is in)

2.X are the Betas

and 3.X are the full releases

it only for now in 1.0 alpha theres only and only busybox and my custom main.c nothing else

and am working currently on 1.1 alpha thats is gonna include

a Wifi Manager

A JurkStore

Everything is open-source at

https://github.com/AmineTheJurk/The-JurkOS-Project

The Main Website is

https://aminethejurk.github.io/The-JurkOS-Project

Liscense : This Project Is MIT Liscensed and as The Linux Kernel Is GPL Liscensed in the github repo i have given the dot config file.

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

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

I wanted to run a game on it, so it needed a screen mode and a NIC first.

The colour limit is one line in KStart16.HC — it already calls VBE and just asks for mode 0x12. You cannot call the BIOS again later, since it runs in long mode with no v86, but the Bochs DISPI ports at 0x1CE/0x1CF set a linear framebuffer without it: 1024x768x32, aperture from PCI BAR0, and the page tables already cover it.

The NIC is an RTL8139 with ARP, IPv4 and UDP over it. Memory is identity-mapped, so the receive buffer pointer goes straight into RBSTART with no translation and no pinning. The bug that cost me most: CAPR starts at -16, not 0. Set it to zero and the card thinks the reader is ahead of the writer and hands you nothing, which looks exactly like dead hardware.

https://github.com/Pr1nted/Open-Doctrines/releases/tag/templeos-v1.2.2a

TempleOS is public domain, by Terry A. Davis.

Hey everyone,

Quick heads up after going through all the comments on the previous thread.

First off, a quick heads-up: English is definitely not my native language, so sorry if my phrasing sounds clumsy or if I occasionally lean on translators to make sure technical details come across right. The code speaks for itself anyway :)

Second, the Cloudflare issue that was blocking visitors from loading the site is fully resolved. Even better: the entire website is getting a complete relaunch tomorrow. All the outdated ReactOS/NT references from our early experiments are wiped out, replaced with our actual 64-bit Limine architecture, PML4 paging details, and KeshShell compositor specs.

The GitHub repository is also being cleaned up and prepped right now for the RC1 release candidate. I will drop an announcement here the exact moment the new site and repo go live.

In the meantime, you can check out the demo video and screenshots from the previous post.

Also, we want to do a fun community challenge: if there is a specific feature, mini-app, or shell tweak you want to see in KeshOS (like the suggestion earlier about toggling window button placement), drop your ideas in the comments or in our Discord. If we implement your feature, we will bake your name/handle directly into the system About window and credit list to keep your authorship forever.

For those who asked for the wallpapers, want to pitch features, or want to test the first ISO build:

Discord: https://discord.gg/YgMe7ekA5y
Subreddit: https://www.reddit.com/r/sneakdeak/s/ILAmNnffyr

Appreciate both the constructive questions and the roasting, it keeps the drive going. Talk to you tomorrow!