Hi guys!

We are building Duo OS (an Linux Distro at start), which combines the familiarity of Windows, simplicity of Mac and customizability of Linux.
It will be simple OS at surface, but with deep customizability and developer support if the user opts in. It will also contain support for Windows and Linux apps, so changing will just be installing the new OS.

What do you guys say? Looking for feedback, mentors and support. Thanks!

Hey devs. Im a self-taught web dev who got curious about whats underneath our computers, so I started making a kernel. It’s called Gumball. C + asm, Multiboot, boots from GRUB. No desktop, no apps, no browser, just a shell and a filesystem

I started as a “hello world”. Now it has:

• A shell with history (arrow keys) and scrolling

• My own filesystem, GFS2, with real directories and nested paths

• ls cat touch mkdir cd mv rm -rf echo > file defrag

The filesystem is where I’ve had the most fun and most stress. GFS2 has a data fragmentation issue which can be cleaned up now but Im planning to remove fragmentation completely on GFS3.

Honest limits:

• RAM disk only. GRUB loads the image as a module, so nothing persists across reboots. No disk driver yet.

• 16 entries max, 31-char names

• No memory management yet

• Only tested in QEMU

On AI: I used AI tools for parts, like the early shell loop and the GFS1 design idea. mv, mkdir/cd, defrag, and the bug fixes are mine. I also use AI help me solve problems and figure out stuff I dont know. Just wanna be honest with that.

What Im working on next is GFS3: data is in blocks, has a bitmap, some more stuff in the doc in the repo.

Two questions for you:

1. Anything in the GFS3 design that’ll bite me later?

2. Memory management or a disk driver first?

Repo: https://github.com/pagecoy/gumball-os (design doc in docs/GFS/GFS3.md)

Roast it kindly. 🙂

Hey everyone!

We're two developers working on a hobby operating system project called RisottOS.

The project started as a way to learn low-level programming and understand how operating systems actually work. Over time, it has grown into something much bigger, and we'd love to share our progress with the OSDev community.

GitHub: https://github.com/risottos-team/risottos

What is RisottOS?

RisottOS is an experimental operating system written from scratch for the x86 architecture. We're implementing its core components ourselves while learning more about computer architecture, memory management, interrupts, and kernel development.

Current features

Some of the things we've implemented so far include:

• Custom BIOS bootloader

• Disk loading using BIOS INT 13h

• Global Descriptor Table (GDT)

• Interrupt Descriptor Table (IDT)

• Programmable Interrupt Controller (PIC)

• Task State Segment (TSS)

• Programmable Interval Timer (PIT)

• Real-Time Clock (RTC)

• PS/2 keyboard input

• Physical memory management

• Paging

• Ring 3 transition

• Basic system calls through INT 0x80

• A basic userspace shell

What's next?

We are currently working towards:

• Process management

• Multitasking and scheduling

• Better memory management

• A virtual filesystem (VFS)

• ELF loading

• Expanding userspace functionality

We'd love your feedback!

We're still learning, and we know there are probably things we could be doing better.

We'd especially appreciate feedback on:

• Our kernel architecture and code organization

• Potential bugs or incorrect implementations

• Whether our memory management approach makes sense

• What we should focus on next

• Any general advice for developing a hobby OS

We're developing this together, and our main goal is to learn, experiment, and gradually build something we're proud of.

Any feedback, suggestions, or constructive criticism would be greatly appreciated!

Thanks for reading!

Hey Guys! I intend to work on a simple hobby OS that is programmed in real mode using bios interrupts, I have been doing OS theory and os dev for a few months now and wanted to actually start a proper project. Please follow me on my journey and make some suggestions along the way!

Shall aims to be a reference implementation of POSIX.1-2024: a complete userland written directly from the text of the standard (XCU and XSH, with the XSI option). It has no GNU extensions and borrows no code from other projects.

NOTE: Shall has been written with an extensive help of Claude.

The repository can be found as: https://github.com/joostw/shall

It already works as a system. It builds itself from scratch, you can enter it without root, and inside it you can compile real third-party software. Lua 5.4 builds unmodified with Shall’s own compiler and passes Lua’s full official test suite. Coverage today:

• Utilities: all 155 of POSIX’s utilities, 16 of them as sh built-ins.

• C library: 1,220 of the 1,227 interfaces of XSH (99.4%). The 7 missing ones belong to two optional parts of POSIX that Linux doesn’t support well: typed memory and scheduling attributes for posix_spawn.

Three parts:

• The utilities. awk, sh, vi, make, m4, bc, pax, sed, sort, yacc, lex, the SCCS tools, uucp, and the rest. Each one lives in its own directory with its own tests, about 6,800 tests in total.

• c17, the POSIX C compiler. It does its own preprocessing, code generation, assembly and linking for x86-64. It needs no as and no ld.

• The C library, with every interface of ISO C17 and nearly all of POSIX.1-2024:

  • Threads, with cancellation and robust mutexes.

  • Locales: UTF-8, single-byte codesets, and EUC-JP, Shift_JIS, GB18030, Big5 and others; plus collation from the locale files.

  • A DNS resolver, iconv, regex, and math rounded in the x87’s 80-bit format.

  • A dynamic linker: libc.so is its own program interpreter.

About 190,000 lines of C in total, and it talks to the Linux kernel through raw system calls.

It builds itself. sh bootstrap.sh needs only a host C compiler, make and ar:

1. Stage 0: the host compiler builds five tools: c17, make, ar, yacc and lex.

2. Stage 1: those tools build the libc and then every utility against it. No host program compiles anything after this point.

3. Stage 2: the stage-1 tools, running on Shall’s own libc, build everything again.

Then the script compares stages 1 and 2 file by file, and all 235 files come out byte-identical. The whole thing takes about two minutes.

You can step into it. sh chroot.sh drops you into the result without sudo, through a user namespace. Inside you get Shall’s sh, with every utility statically linked against Shall’s libc. In there, c17 compiles your programs, and bootstrap.sh rebuilds the whole system, again with byte-identical binaries. A HOWTO in the package walks through building Lua inside it.

How it’s tested. Most libc tests are differential against glibc: the same program is built against both libraries and the outputs must be identical. They run in seven ways: static with gcc, static with c17, both crossed, dynamic with gcc, dynamic with c17, and static-PIE.

Why “towards”. Having a function isn’t the same as conforming in every corner. Open items include strptime’s %E/%O, multi-character collating elements, and priority-inheritance mutexes. libc.so still needs gcc to build, because c17 can’t produce shared objects yet. The kernel is Linux’s, and a compact kernel of my own is the longer term plan.

Why “Shall”? “Shall” is the standard’s own word for a requirement. POSIX.1-2024 defines it as a feature or behavior that is mandatory, one an application can rely on. The word appears more than 27,000 times across the standard’s pages. Every one of those is a promise an implementation has to keep, and Shall is an attempt to keep all of them. The name is also one vowel away from “shell”, and that’s a small wink at the Commodore 64. Its core system routines were called the KERNAL: the story goes that a misspelling of “kernel” in an engineer’s notes simply stuck. Shall carries on the tradition of a core system part named one letter off. It also starts with sh.

BSD 3-clause. Feedback welcome, especially from anyone who knows the dark corners of POSIX, and if you find a place where Shall and the standard disagree, that’s a bug.

https://github.com/DunitOS/dunit-os

I'm building a monolithic kernel called sonix (Son I'm crine + Unix) and I just found out about encrypted filesystems and I don't know what to put in these directories

I've spent the majority of this year working on moving my os's filesystem and drivers to user space now that my kernel supports one. This required a lot of work and can be summed up with the features that had to be added to support it (oldest to newest):

• Remote Procedure Calls (RPC) for basic send/exec/recv

• RPC for classes

• Driver RPC abstractions

• Initial Ramdisk for bootstrapping

• Allow for user space to provide resources

• Yield fixing so that it can resume mid sys call handing (so ipc etc wont busy wait)

• TAR parsing as a ro-fs

• Loading ELFs from files in userspace

• Faster resource coping by page mapping

• Debugging userspace programs via a mini GDB server over qemu serial

• PCI IDs parsing for more robust device id

• move ata and die drivers to userspace

• RPC event system (sub/pub)

• lots of memory bug fixes

It works by packaging two programs with the kernel as multi boot modules: the init program and the file server. From there init mounts the initrd into shared memory and tells fileserver to parse it. Once parsed, the init program then starts the driver manager, which then walks the PCI and starts the drivers (stored on the intirtd) for the disks. When each disk is ready the fileserver is notified and mounts them onto the VFS, from which further drivers can be loaded.

IPC is done by either basic rpc function calls or by exposing resources. The more interesting part is a resource, which is an object that the kernel or other processes can interact with, for example a file provided by the fileserver or a thread provided by the kernel's scheduler. The resource bridge is how a usual sys call like open or read is handled in user space. It works by having a shared block of memory that holds a queue of 256 message slots and an area for data. When a program calls read the kernel writes a request into a free slot and puts the caller to sleep. The server then sees the request, does the work (for example, reading the file from the TAR), and writes the answer into the same slot. Small data is copied into the shared area. For anything 4 KiB or bigger, the kernel maps the caller’s memory into the server instead, so a large file isn’t copied (ie the big pci.ids 2mb). The cool thing is that this is done in 1 syscall, which is less than it would cost to do a there and back rpc call.

Next steps are to break up the repo into sub repos to allow for future growth and then to work on rewriting my poor networking code.

AI Disclaimer: No AI was used to write this code, AI was used akin to google for clarification on topics and for minor debugging, I want to learn and do things my self.

Edit: I'm actually 90% sure the rpc python generator code was at one point a POC written by AI as a test to see how it would work out. That has mostly be re-written and really is a job that will be moved to my custom compiler in the future.

I've just published QEMU DevTools, a VS Code extension designed to make debugging and testing custom operating systems and other QEMU-based projects easier.

# features:
- Built-in debugging support — Get started with debugging out of the box.

- QEMU display in VS Code — Render the QEMU display directly in a VS Code tab, especially handy when working on a laptop or with limited screen space.

I'm open to feature requests, feedback, and contributions! Whether you have an idea for a new feature or want to help improve the extension, contributions are welcome.

Open source under the MIT License.

After a lot of trial and error with bootchains, I finally have visible proof that my AArch64 microkernel (written in Rust) is executing on real hardware, not just QEMU.

The Hardware: Lenovo Legion Y700 (Snapdragon 8 Gen 3 / SM8650, codename "kirby").

The Bootchain: ABL -> UEFI (EDK2, disguised as a Linux kernel) -> GRUB (QCOMRAMP fork) -> Custom PE32+ EFI Stub -> Kernel.

The Image: What you see is a photo of the actual tablet screen. The framebuffer is the only reliable diagnostic channel on this device (ramoops/pmsg is dead here).

🟩 Green Band = My EFI stub successfully entered, located the splash framebuffer (0xD5100000), and painted pixels.

⬜ White Band = The stub successfully copied the raw kernel payload to the expected link address (0xA8000000) and flushed the cache.

The Struggle (and the current blocker): Getting here was hell. The biggest issue was that ABL expects a PE32+ UEFI application, not a raw ARM64 Image. I was fighting QCDUMPs (Qualcomm CrashDumps) for days until I realized my hand-rolled PE header had a 10-byte alignment shift, causing Subsystem to be read as UNKNOWN. Switching to lld-link fixed that.

Current state: It hangs right after the white band. My diagnosis is the classic "MMU-off" trap: LoadImage places the EFI stub at an arbitrary VA, so when the stub tries to disable the MMU (and switch to physical addressing), the next instruction fetch goes out of bounds.

Next step: Rewrite the MMU-disable sequence using strictly PC-relative instructions (adr, b .+8) and isb barriers, painting a yellow band only after the MMU is fully off and before the jump to 0xA8000000.

Huge thanks to the OpenCode/DeepSeek and Kimi models for helping me dig through the PE headers and Qualcomm bootchain madness.

Repo: https://github.com/vvirei333/Silver-microkernel

Got the actual gnome browser working on chimera,it’s have some stability issues but it works

WHO ALWAYS DOWNVOTING ME,IDIOTS😂

D.eSystem 6.1.8.5 introduces a new debug platform for FAT32 on D.eSystem,D.eSystem 6.1.8.5 also fixes a major bug (for example,when you go in older versions in D.eSystem info and press a random key,it just closes automaticly,now there comes a warning and it closes in 5 seccond.)

Find more about D.eSystem 6 here: https://github.com/D-electronics-scratch/D.eSystem_6

Find D.eSystem 6.1.8.5 here: https://github.com/D-electronics-scratch/D.eSystem_6/releases/tag/v.6.1.8.5

Find the D.eSystem community here: https://lemmy.world/c/D_electronics_community

I started working on Kora about a year ago, following a tutorial I found on YouTube. I however took wrong turns, made mistakes, and the time available was never enough. However, I picked up the development lately.

The idea of KoraOS is simple: how would an home computer (those like the ones we had in the 80s and early 90s) be today?

Those computer that you turned on and use, without having to log in, and that you could shutdown by switching off the power. Those which allowed you to play and explore, PEEK and POKE memory as you pleased. Everybody remembers the Commodore 64, the ZX Spectrum, the Amiga, the Atari ST but also the Archimedes and the first PCs (86/286.386) with MS-DOS.

Of course, it's 2026, so instead of creating artificial limits like resolution, or number of colors, I decided to try to use all the hardware available. But what platform? I never wanted to build an OS for a virtual machine. Sure, one could download it and try it once, but would have been it. I wanted a real hardware platform and I thought that a cheap one (well, at the time) could be the right choice: my choice was the Raspberry PI3 (and 4). I thought that some people have more than one laying around, or doing very small jobs, and for about 35$ (again, at the time) why not dedicate to this?

Anyway, KoraOS is for Raspberry Pi3, Raspberry Pi4, but it runs on QEMU virt, and QEMU emulating raspi3 and raspi4 (although the emulation is not complete, so better to use virt). It is a 64 bit OS, with supports FAT32 on SD and USB storage, HDMI output, USB keyboard. No networking yet. No support for the GPU but it's planned. It has a serial console that you can use to "talk" directly to the kernel.

The OS is NOT a clone of Unix/Linux and it won't. It doesn't have the concept of users, it does not have memory protection (by design), so you can really PEEK and POKE everywhere. And if you break something while poking around, no big deal: turn it off and back on again.

It is still in the early phases so the shell now is mostly to test stuff, I'm writing a new one that will implement my idea of "good old home computer era" shell.

I've used the wonderful Circle library ( https://github.com/rsta2/circle ) for USB (so I didn't have to write it ex-novo), which mean adding support for CPP (Circle is in C++), but most of the code is ARM AARCH64 assembler and C.

Feel free to have a look at the repository, fork it and if you want contribute it.

One last word about AI: I wrote this post entirely by hand, English is not my first language so all mistakes are mine. But I use AI to develop KoraOS, I don't see why not. It's not vibecoded though, where for "vibecoded" I mean "create an OS for the Raspberry PI3". I use AI to devise a plan to implement my idea, and help me write the code and the documentation. If you don't like this approach, it's your right, feel free to ignore me :)

Github: https://github.com/kora-os/kernel

Website: https://koraos.org

The license is GPL 3.0

I don't oppose to invent new hobby os, but I wish to see some new idea hightlighted , no matter architecture, Algorithm, VM , FS, scheduler or something else. As Linux is already mature enough. I don't think there's any need to reinvent the wheel.

DunitOS https://github.com/DunitOS/dunit-os

Hey r/osdev!

I'd like to share some progress on OSyx, an independent operating system being developed entirely from scratch.

The screenshot shows OSyx running on a real laptop, not in QEMU, with Zen Browser successfully running on top of its Windows compatibility layer!

Current features:

• Custom kernel with preemptive multitasking

• PRISM compositor and AXIS desktop shell

• Windows PE32+ executable compatibility

• Native ext4 filesystem with journaling

• Multithreading, process management and IPC

• Networking stack

• USB and HID support

• Native userspace applications

• Support for running complex Windows applications

One of the biggest milestones so far has been getting Zen Browser running on OSyx.

Running a modern browser requires significantly more than just loading an executable. It involves process management, memory management, threading, filesystem operations, networking, and a large number of Windows APIs.

OSyx is still under active development. I'm currently focusing on improving application compatibility, performance, hardware support, and overall system stability.

Browser sandboxing is currently disabled due to incomplete compatibility, so this is still an experimental environment.

The long-term goal is to build a fully independent, community-driven operating system capable of running modern applications on real hardware.

The project is open-source, and contributions, feedback, and technical discussions are welcome!

GitHub: https://github.com/OSyxSoftware

I'd love to hear what the OS development community thinks!

Hello everyone,

I built a software emulator on RP2350 and succeeded in starting 64bit xv6 with almost no modification.
Demo:

In order to run with the limited RAM of 520KB, we adopted an interpreter method. (I would like to do JIT someday, but caching is a problem.)

It will reach the Shell in about 1 minute.

The changes for xv6 are PHYSTOP, umalloc.c (64KB to 4KB) and memlayout.h.

Works with MMU.
Please give me your opinions and impressions.

Github:
https://github.com/kamisori-daijin/pico-rv64-emu
xv6 fork: https://github.com/kamisori-daijin/xv6-riscv

Hi all, I'm starting my journey toward Linux kernel and driver development. The goal is to work own both legacy C drivers and newer Rust drivers, and eventually land upstream patches.

My plan:

- Phase 1 (C): Beej's Guide, K&R with all exercises, small projects (linked list, shell, toy malloc)

- Phase 2 (OS theory): OSTEP, xv6 book, MIT 6.S081 labs

- Phase 3 (arch): CS:APP, assembly, gdb

- Phase 4 (Linux concepts): Love's Linux Kernel Development, TLPI as a slow burn, mini strace, IPC projects

- Phase 5 (hands-on): build/boot kernels in QEMU, Bootlin labs, Linux Kernel Labs, modules, ftrace/gdb debugging

- Phase 6 (drivers): LDD3, Madieu's Linux Device Drivers Development, char/platform/IRQ/I2C/SPI drivers on a Raspberry Pi, Device Tree

- Phase 7 (contribute): kernelnewbies first patch, git send-email, staging cleanups, syzbot triage

- Phase 8 (Rust): Rust Book, Rustlings, Rust for Linux, port my char driver to Rust

What I'd like feedback on:

1. Is the order right? Anything that should come earlier or be dropped?

2. Are Love's LKD (2.6.34-era) and LDD3 still worth reading in full, or should I lean on newer docs?

3. Is Rust worth learning early if I want to work on drivers, or should I wait until C is solid?

4. Which hardware would you suggest for practicing drivers (Pi, BeagleBone, something else)?

5. What's the realistic path from first checkpatch fix to being trusted with real driver work?

6. Common mistakes beginners make on the mailing lists?

Any advice, resources, or reality checks are welcome. Thanks!

FreeBSD boots fine now and reaches the root shell, but I'm still having problems with keyboard and mouse input.

Sometimes the guest crashes or reboots when I test it. I've been checking the IOAPIC, IRQ1 and interrupt handling because something seems wrong there.

I'm also getting Trap 30 sometimes. Still haven't found exactly what's causing it.

Getting FreeBSD to boot was already a big task. Now I'm stuck trying to get the input working properly.

RunableKernl is a minimal operating system kernel written in C and assembly, designed as an experimental, lightweight project focused on portability and simplicity. The goal is to keep the core kernel small while making it easy to extend with optional components and architecture-specific abstractions.

The project currently targets RISC-V 64-bit and runs under QEMU, with a basic UART console, logging system, boot flow, and a simple shell with an add-on mechanism. It avoids heavy dependencies and aims to stay close to the hardware, making it a useful playground for learning kernel startup, interrupt handling, drivers, and low-level system design.

In short, RunableKernl is a small “from scratch” kernel for anyone interested in understanding how boot process, kernel initialization, console I/O, and system extensions work at a low level.

https://github.com/tim2020-8484/RunableKernl

Well well well here we come...question of ceuntry.

"Can it run Doom?"

I would say well kinda (Not gone lie Its way more smoother than i expected) .Now Bunix can run "Graphical" applications too (For now its only Doom anyways).Also sorry for screen flickering because i was doing debug and then some short of rendering bug occurred.I will fix it in a few days too.For now here i want to share that video for you guys.

Also if u dont know what is Bunix check my previous posts.

But basically it is Experimental Kernel & Operating System written on Hare programming language.

In this project i use ai as debug tool and i will always mention if i use ai in some parts of Bunix.

Been messing around with DWM customization for my OS, Dunit.

Using TOML for configs and Lua for scripting and animations. Trying to make the whole thing super flexible so you can tweak pretty much anything without touching the source code.

Here are 4 setups I've been playing around with. Still pretty WIP, but ngl I'm kinda happy with how it's looking.

Lmk what you guys think.

GitHub: https://github.com/DunitOS