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!

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!

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

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

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)

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.

Haven't posted about aurelianOS since the original post so here's a quick update

Since then I've:

• Built the OS as a Fedora bootc image and got it booting successfully in QEMU
• Set up a user with sudo access for the dev VM
• Started the compositor in Rust with smithay
• Got an actual Wayland socket working
• Built the first desktop shell with Slint
• Added a fullscreen wallpaper-based desktop, translucent UI, floating dock, and app launcher and a couple other shit
• Switched the dock to Tabler SVG icons
• Chose a font (Inter)
• Switched to a 4K purple/blue abstract wallpaper that looks SO much better

Next up is the compositor rendering pipeline and real backdrop blur

Still early but its finally starting to feel like an actual desktop, still mostly placeholder stuff

Quality looks bad because I can't printscreen from inside QEMU for some reason

I literally have to implement IDT, GDT, TSS and syscalls, yet all it does is freeze
It's all stack aligned, i seriously have zero idea how is it done

How do yall run programs? Im wondering.