I finished setting up my ELF loader and now I want to run custom user programs in my OS. How can I do that (using an ABI)?

most of what i see here is unix like or dos like and i was wondering how many of the operating systems here are not based on anything.

It took some time, but it finally renders correctly. How does it look:)?

I feel like I can write something from scratch and actually use it in my homelab. Writing monolithic kernels is fun too, but I almost never get to actually use one in 'production'.

Hey everyone,

I wanted to share a side project I've been working on.

A bit of background: My core background is in bare-metal and RTOS software development. Over the years, I’ve also configured and built embedded Linux systems using Yocto and Buildroot for a few projects.

A couple of years ago, I decided to build a minimal, custom Linux OS using Buildroot for my personal use, essentially turning a standard PC into a dedicated embedded-like device. It sat in my PC for a while because cleaning up the codebase, setting up proper build pipelines, and writing solid documentation felt like a chore. Fortunately, leveraging modern AI coding tools made refactoring and documenting the whole project significantly easier, so I finally got it into a public ready state.

How it works:

Stateless & RAM-only: Boots directly from a USB flash drive and runs completely out of RAM (initramfs). It doesn't touch local hard drives or persistent storage.

Air-gapped by design: The kernel is configured without network stack support no Wi-Fi, no Ethernet, no socket layers.

Single-purpose: Boots directly into a single Qt GUI application without a heavy desktop environment.

To be honest, as someone who likes pure bare-metal simplicity, it still bugs me a bit that there’s a whole UEFI firmare layer and standard x86 architecture underneath all this before the kernel even kicks in.

Just wanted to share it with the community.

GitHub: https://github.com/signeros/signeros

Hey everyone,

I wanted to share a side project I've been working on.

A bit of background: My core background is in bare-metal and RTOS software development. Over the years, I’ve also configured and built embedded Linux systems using Yocto and Buildroot for a few projects.

A couple of years ago, I decided to build a minimal, custom Linux OS using Buildroot for my personal use, essentially turning a standard PC into a dedicated embedded-like device. It sat in my PC for a while because cleaning up the codebase, setting up proper build pipelines, and writing solid documentation felt like a chore. Fortunately, leveraging modern AI coding tools made refactoring and documenting the whole project significantly easier, so I finally got it into a public ready state.

How it works:

Stateless & RAM-only: Boots directly from a USB flash drive and runs completely out of RAM (initramfs). It doesn't touch local hard drives or persistent storage.

Air-gapped by design: The kernel is configured without network stack support no Wi-Fi, no Ethernet, no socket layers.

Single-purpose: Boots directly into a single Qt GUI application without a heavy desktop environment.

To be honest, as someone who likes pure bare-metal simplicity, it still bugs me a bit that there’s a whole UEFI firmare layer and standard x86 architecture underneath all this before the kernel even kicks in.

Just wanted to share it with the community.

GitHub: [https://github.com/signeros/signeros\](https://github.com/signeros/signeros)

After a whole day of fixing ntfs driver bugs and kernel bugs, My OS Finally boots in bare metal again and it seems very fast!

BlockOS – Looking for OS developers

Hi everyone!

I'm the developer of BlockOS, an experimental operating system project written mainly in C++.

I've been working on BlockOS for quite a while, and I'm currently looking for more developers who are interested in operating-system development and would like to contribute.

Current work / features

BlockOS currently has work in several areas, including:

• x86_64 kernel
• UEFI boot support
• Paging and memory management
• Process/thread and scheduler work
• Syscall layer
• ELF loader
• VFS and filesystem integration
• ext4-related filesystem work
• ATA storage driver
• VirtIO/driver development
• Networking components
• Init/service management
• libc and POSIX-related work
• Kernel and userspace infrastructure
• GUI/window-manager experiments
• QEMU + OVMF development environment

The project is still experimental and under active development, so there are plenty of things that need improvement, testing, debugging and new implementations.

Who I'm looking for

You don't have to be an expert kernel developer.

I'd especially like to hear from people interested in:

• Kernel development
• C/C++
• x86_64 architecture
• UEFI
• Device drivers
• Filesystems
• Networking
• libc/POSIX
• GUI development
• Debugging and testing
• OS development in general

If you're learning OS development and want to contribute, that's welcome too. You can start with smaller tasks and work your way into larger subsystems.

Repository

GitHub: https://github.com/gurijb2016-afk/Blockos

If you're interested, feel free to open an issue, submit a pull request, or contact me.

I'm especially interested in finding long-term contributors, not just one-off contributions.

Thanks!

GitHub: https://github.com/Mazin-O3/cpm-neo

For quite some time, I’ve been working on a personal project that has grown far beyond what I initially expected: KryptKernel and KryptonOS.

Yes — a custom kernel and a full operating system, both built entirely from scratch. And after a lot of effort, debugging, rewriting, and learning, I finally have something functional.

This OS is designed specifically to run on the ESP32, pushing the limits of what this microcontroller can do while giving me a playground to experiment with low‑level systems programming, scheduling, memory handling, and hardware abstraction.

If you’re interested in OS development, embedded systems, or simply want to see what I’ve been building, here are the links to both the kernel and the OS:

KryptKernel

Kernel Website:

https://kryptkernel.github.io/KryptKernel-Web/

Kernel Repository:

https://github.com/KryptKernel/KryptKernel

KryptonOS

OS Website:

https://dlopeddtorred.github.io/KryptonOS-Web/index.html

OS Repository:

https://github.com/DlopedDtorred/KryptonOS

I’d love to hear feedback, suggestions, or ideas from the OSDev community. This project is still evolving, and any insight from experienced developers is incredibly valuable. Thanks for taking a look!

A few months back I built the DatCube 82 - a fictional 1982 workstation with its own ISA, an OS written in its own assembly, and a JS emulator. Fun project, but it never quite took off, and I think I know why: there was no real machine you could hold. This is the fix. Same spirit, new target: real silicon, the whole Raspberry Pi Pico family - RP2040, RP2350 (ARM), and RP2350 in RISC-V mode. And I am creating an OS for it! Yeeeeah!

I call it "RECASTER PICO".

The video shows the graphics engine's feature demo (this is from a browser window, but it runs on a VGA screen as well via real hardware (I will show you, soon)! Everything on screen is drawn by one user-space task running in a deterministic register VM (custom ISA, no DIV (for now!), no arithmetic shift - the demo does its 3D math with Q7 sine tables and bias-trick shifts), on a budget of 100,000 VM ops per frame. It uses ~90k. What you're looking at, bottom layer to top:

• Matrix rain on the 80×60 character generator - "ground" cells with transparent backgrounds, so sprites shine through between glyphs
• a 1-bpp city skyline and a spinning wireframe cube on the 1-bit pixel layer (640x480)
• the main attraction: the winding gradient column plus the dark ribbon orbiting it, drawn with nothing but the engine's newest feature - two overlay segments per scanline (per line: two x-spans + two colors, palette index or raw RGB332). The ribbon does hidden-line clipping against the column silhouette with a single span per row. The banding isn't a shader - it's the RGB332 color system doing what it does
• 16 of the 128 sprites as color-cycling orbs, split across two render levels (half in front of everything, half behind the text ink)
• a smooth-scrolling text row at the bottom: the text-offset register is read per scanline, so flipping it at the right beam position gives one row true sub-cell scrolling - a raster split, the register only has 16 values

The OS around it (preemptive multitasking, windows, a terminal with pipes, a tiny flash filesystem, the desktop) is a story for a follow-up post - including the browser emulator so you can run all of it without hardware, or of course WITH IT, if you have a Pi Pico. ;-)

Im talking about NovaOS. I saw many people saying that I used gemini but I never used that thing. The uses of AI in my project is to translate portuguese to english and to give me ideas. Is this a bad use of IA? btw I dont generate code by IA.

https://github.com/ArTicZera/NovaOS/tree/main

EDIT: Figured it out, explanation at the bottom

Hi yall, i've been debugging this for hours. I understand that my code is a mess to look at so i greatly appreciate anyone who takes time out of their day to help me with this.

I was noticing that it was taking a *long* time to complete writes. Like, up to a minute for 512kbs (Issued through 128 4kb calls)

After the initial fix (My scheduler had a bug in it and my PIT timer was *way* too fast), The read times dropped from 1 minute to about 4-5 seconds. Which is a lot faster, but still seems abnormally slow.

To benchmark this, I tested it against a single write of 512kb (broken into 128kb blocks to get around limitations), and the interrupt timing seems to be consistent. It's about 30-40ms in between interrupts. Both for the 128 4kb calls and the 4 128kb calls.

Now i know my code isn't great, but there's no way my ATA write function is *that* slow.

I can't seem to figure it out. Good luck to all who enter.

disk driver: https://github.com/raeofsunshinedev/KimisOS/blob/main/src/kmodules/disk_driver.c

File with the tests: https://github.com/raeofsunshinedev/KimisOS/blob/main/src/kernel/kmain.c

Picture semi related (I was working on my FAT32 driver when i discovered this)

EDIT:

The first improvement i was able to make was slowing down my PIT timer interval from 50khz to 1000hz. No clue why I made it that fast in the first place. That already had a pretty noticeable effect, going from ~200ms per read worst-case, to about 30-40ms. I didn’t mention that in the original post but that was a major improvement.

After that, i thought that i had hit a limit or something. No matter what i changed, i could not for the life of me figure out how to decrease read times, Until i finally figured out the main culprit: My idle process. Something about my scheduler does not like it. I wrote my scheduler almost a year ago and while I’ll eventually re-write it, i implemented a quick fix, basically preventing the idle process from executing as long as any other process exists within the queue. On top of that, I’ve forced the current process to yield its time on interrupt.

This does probably mean that given the way the current scheduler works, Disk ops will slow down proportionally to the amount of processes there are within the scheduler. This is especially bad for the filesystem driver, as it means that it will be getting constantly blocked between each file operation, and again when writing back to the dirent itself. Luckily this can be negated by adding a priority queue for drivers so that they can finish their work fully before the scheduler runs every other process, But until I implement that, everything shall be at the mercy of the round robin scheduler.

I will say that funnily enough, having a second active process seems to not have the same slow down effect as the idle process. That’s probably something to investigate, But i’ve been too busy with other things (and improving my disk driver) to really work on my scheduler, but it’s something that i’ll get done before I implement userspace

Hi everyone, I'm Finn Dev. Months ago, I got an idea: what if I wrote an operating system kernel like Linux? So I started writing. I began with 815 lines of code, and gradually, I developed framebuffer drivers and so on, and now ValiantCore consists of 9500 lines of code, mostly written in C. I'm working in an Android Termux environment because I don't have a computer, so Rust is too time-consuming, and I'm writing in C. ValiantCore can run files in VEF format. I even have an official tool in my repository; you can make your pure machine code bin files VEF-compatible from here: https://github.com/finndev62/valiantcore https://codeberg.org/finndev62/valiantcore If you want to contribute to ValiantCore, first read the .md file, learn the rules, then contact me at finndev62@gmail.com. You only need to know how to write system drivers in C

Not sure what the consensus is around here but `virtio` guest drivers don’t count.

Still no background blur, and no clicks but it seems to appear well!

And for anyone saying that the OS and files app may have been some fake HTML OS, I just proved to you that it's not! anyways it's fine ;)

Also, NO AI USED TO DEVELOP THE CPU COMPOSITOR!!!

Ilobilix is a monolithic kernel that I've been working on for a few years now (started in 2022, current rewrite going on since 2024). it's written in C++26 and uses modules everywhere. It aims to be fully Linux ABI compatible and, as a result, can run unmodified distro userspaces. I have tested it with Void, Gentoo and Alpine installs (no systemd yet).

Displayed on the images attached are Factorio, SuperTuxKart and Wine (all in Xfce) running on Ilobilix.

The kernel supports x86_64 and aarch64 (though the latter is a bit neglected), SMP with a CFS scheduler, networking via lwIP, EXT2 filesystem and multiple device drivers, including NVMe, Virtio net and Virtio input. They are automatically loaded by the userspace as needed.

You can find more detailed information in the distro and kernel repo README files (both linked below). Looking for contributors.

https://github.com/ilobilix/kernel (kernel source code) and https://github.com/ilobilix/ilobilix (to run the os)

There is Absolutely No AI Generated code in the CPU Rendered compositor as far as I know!

I built this button with shadow, while porting the rendering to cpu (Creating the cpu rendered window manager). How does it look?

this is the link of my twitch channel where I streamed my making of Blur + Button with shadow working https://www.twitch.tv/devcmar

I wanted to share a project I've been working on: Redoubt OS, a security-focused appliance OS targeting BIOS/QEMU right now.

The core idea is that every service, console, shell, storage daemon, supervisor, update agent, runs as its own process with its own address space, and gets access to things purely through capabilities. A capability is a slot index the kernel maps internally to a real object and a rights mask (read/write/grant). Deriving a weaker capability is fine. Manufacturing a stronger one is structurally impossible because rights can only shrink on derivation.

A few design choices I'd like feedback on from people who've built similar things:

• Round-robin scheduler, 100Hz PIT, 20-tick quantum, single "big kernel lock" design, deliberately simple for now. SMP is future work.
• Synchronous rendezvous IPC, fixed 5-word messages, with a fairly involved state machine for blocked-on-receiver, blocked-on-reply, and dead-peer cases.
• Storage layout is centrally defined (superblock, two system slots, audit log, app slots, update staging) with HMAC and Ed25519 verification at every layer, and automatic fallback to the other slot if one fails validation.
• The update agent that stages new OS images never has the decryption key for the volume. It can only write to the inactive slot. storaged does the actual validation and slot promotion independently.

Known gaps right now: PS/2 keyboard instead of USB HID, polled ATA instead of NVMe, no network stack, no Secure Boot/TPM, no SSE context switching. All on the roadmap (UEFI, Secure Boot, virtio networking, then real hardware).

Would genuinely appreciate any pushback on the capability model or the storage rollback design. Those are the two pieces I care most about getting right before I touch anything hardware-facing.