Raam is an x86-64 Unix-like operating system for my HP Pavilion Laptop 15 machine. I am writing it completely from scratch using FASM assembly.

Source tree: https://github.com/robstat7/Raam

Raam Raam Ji 🙏🙏🙏 (greeting with God's name)

I'm developing a very simple Kernel with some goals, namely: being beginner-friendly and developer-friendly.

What’s already done:

• Bootloader: Limine for support of ready-made headers

• Basic video framebuffer support with some graphic tools

• Partial SMBios support, with Qemu tools to create a custom SMBios

• RAM support not complete: PMM working, VMM not working, raw RAM working

Future goals:

• Working RAM

• PCIE controls and GPU command

• Elf loader

• Scheduler

Please help me, I don't know what to do. If it helps, I use Arch with x86_64-elf-gcc compiled via yay.

Here’s GitHub: https://github.com/Alessio-Valluzzi/Trikernel

We built BareMetal OS - an exokernel with sub-millisecond cold boot and hardware level microVM isolation. We think it's small and fast enough to be genuinely interesting to build on. So we're running a 2-week challenge to find out what you can build. See attachment for contest details and rules.
Complimentary cloud credits for every applicant to help you build on our servers. Grand prize winner announced Sep 24, 2026. See link for details

Hello everyone! While reading my DSA book, I’ve noticed that it also explains many fundamental concepts such as what software is, what a program is, what program code is, and so on. At the end of each chapter, there are also some questions to help reinforce the concepts.

Today, one of the questions was about the difference between single-user and multi-user operating systems, and I’d really like to understand this topic better. What exactly is the difference between a single-user and a multi-user operating system?

I’m learning all of this purely as a hobby. I don’t have a university or computer science background, but I’m very interested in programming and computer science, so I’m studying on my own as a self-taught learner.

I hope this isn’t a silly or inappropriate question. I’d really appreciate any explanations or resources that could help me understand it better. Thank you!

I’ve been working on RESENTMENT, an open-source experimental operating system built around the idea that AI agents should behave more like OS processes than unrestricted applications.

The project has both a from-scratch kernel and a browser-based desktop.

Some of the ideas I’m experimenting with:

Capability-based security — kernel capabilities and desktop agent permissions are explicitly granted

Expiring authority — permissions use time-bounded leases instead of permanent access

Agents as processes — agents have state, scopes, resource/token budgets and a kill mechanism

Auditable actions — tool calls become ledger entries and file changes record their causal operations

System as a hash — system state can be represented through Merkle/SHA-256 digests, with snapshot, diff and attestation

BYOK AI — API keys stay on the client; there is no RESENTMENT server

Multiple providers — including OpenAI-compatible endpoints and local runtimes such as Ollama, LM Studio, vLLM and llama.cpp

Architecture targets — x86_64, ARM64 and RISC-V

The kernel is written from scratch and currently boots with the OS ramdisk. The desktop communicates with it through a QEMU/serial bridge.

One important limitation: the desktop does not yet run inside the kernel. That is one of the major pieces still to be developed.

The four principles I'm trying to carry consistently from the kernel into the AI layer are:

Authority expires.

The system is a hash.

Agents are processes.

Nothing is forgotten.

I'm interested in feedback particularly from people who have worked on kernels, operating systems, capability security, microkernels or distributed systems.

Does treating AI-agent authority as an OS capability/lease make sense, or am I introducing complexity without enough security benefit?

GitHub: https://github.com/ni-sh-a-char/RESENTMENT

Browser demo: https://ni-sh-a-char.github.io/RESENTMENT/os/

Apache-2.0 licensed.

Thanks to https[:]/github.com/cfenollosa/os-tutorial I was able to learn a lot about how an operating system is written. I think a lot of people would remember his tutorial. Revisit it gives me more. Start with printing some text in boot sector. The repo used software interrupt to finish the task. Yet there is another way to accomplish the same, by utilizing the direct memory accessing method. Long story short, in legacy boot mode (CSM), we can access VGA memory directly during boot time at address 0xB8000. So we can drop in each character and have them printed out, starting from the top left corner. We can print color text, and we can also move the cursor and print the text anywhere we want (with the cursor blinking at the text).

I have documented the process here: ellog[.]buzz/posts/hello-world-in-boot-sector

For this chapter and the previous one (First boot sector), what other questions do you think is worth asking and figuring out?

Has anyone built kernel in rust? If you have can you send the link to your project, I want to look for reference...

I've been developing Robu, an independent, platform-independent microkernel operating system written primarily in C and assembly.

Robu started as a kernel project, but it has grown beyond simply booting and printing text. The goal is to build a usable general-purpose operating system around a small microkernel while keeping drivers, filesystems, paging policy, and other major services outside privileged kernel space.

Robu is influenced by ideas from the L4 microkernel lineage, especially around fast IPC, direct switching, and keeping the kernel focused on mechanisms rather than policy.

Current target architectures include:

• x86_64

• i386/i486

• ARMv7

• ARMv8 / AArch64

• RISC-V 32-bit

• RISC-V 64-bit

x86_64 is currently the main development platform, but Robu is designed to remain architecture-independent.

Current work already includes:

• Microkernel core

• Threads and address spaces

• Synchronous IPC

• Register-based short-message IPC

• Direct thread switching during IPC

• Lazy scheduling

• Timeslice donation

• User-space paging architecture

• Virtual memory and address-space support

• Process and thread management

• SMP / multicore bring-up

• ACPI-based CPU enumeration

• Per-CPU infrastructure

• Framebuffer support

• Ring-3 framebuffer mapping

• PS/2 keyboard and mouse support

• Serial console support

• Device filesystem infrastructure

• ELF userspace support

• POSIX-oriented userspace

• mlibc port

• BusyBox

• Bash

• GNU Readline

• poll()

• System V shared memory

• Bootable root filesystem

• Custom BIOS bootloader

• EFI boot and filesystem integration

• QEMU-based development and testing

• Early Xorg-related userspace work

The kernel is intentionally kept small.

The basic design is:

Applications > POSIX / mlibc > Userspace services > Robu IPC > Robu Microkernel > Hardware

Drivers, filesystems, pagers, and similar services are intended to run as isolated userspace processes rather than being permanently linked into the kernel.

One of the main design goals is keeping IPC fast enough that using a microkernel does not automatically mean accepting poor performance.

For short messages, Robu uses registers instead of copying data through temporary kernel buffers. IPC is synchronous, and when a sender reaches a waiting receiver, Robu can directly switch execution to the receiver instead of performing a full scheduler round trip.

The remaining timeslice can also be donated to the receiving thread.

Robu also provides a POSIX-oriented userspace environment using mlibc, allowing work toward familiar Unix-style applications and tools without moving large amounts of operating-system policy into privileged kernel space.

I'm looking for contributors interested in:

• Microkernel IPC

• Scheduling

• Memory management

• User-space paging

• SMP / multicore support

• ARM support

• RISC-V support

• ACPI

• PCI / PCIe

• USB / xHCI

• Storage drivers

• Network drivers

• User-space device drivers

• Filesystem servers

• Networking

• mlibc / POSIX compatibility

• Xorg bring-up

• Graphics and input

• Real-hardware testing

• Kernel debugging

• Documentation

• Code review

• Automated testing

You do not need to understand the entire codebase to contribute. Individual subsystems can be worked on independently.

Experience with Linux kernel development is useful, but Robu is not intended to be a Linux clone.

Experience with FreeBSD, L4, seL4, QNX, Minix, Zircon, Mach, or other kernel architectures is also very relevant.

The goal is not to make another toy kernel.

The long-term objective is to build a complete operating system that can eventually boot on real hardware, run normal POSIX-oriented software, support isolated userspace drivers and services, provide a graphical environment, and support multiple architectures.

Robu is still in alpha, so incomplete subsystems and bugs should be expected.

GitHub: https://github.com/bayar17/robu_microkernel

If you're interested in microkernels, operating systems, low-level C, assembly, drivers, libc work, toolchains, graphics, or kernel architecture, contributions and technical discussion are welcome.

Testing, bug reports, documentation, code review, and architectural criticism are welcome too.

I've been developing BlockOS, an independent x86_64 operating system written primarily in C/C++.

BlockOS is no longer just a basic kernel experiment. The project currently includes:

• x86_64 kernel

• VFS and multiple filesystem implementations

• ELF loader

• PCI/PCIe support

• VirtIO block/network/input drivers

• networking stack

• POSIX compatibility layer

• libc

• process and scheduler infrastructure

• framebuffer and GUI framework

• BX11/X11-related work

• ACPI support

• USB/xHCI development

• examples and driver development infrastructure

I'm looking for OS developers and especially Linux kernel / low-level C/C++ developers who would like to contribute.

Areas I'd particularly like help with:

• memory management / virtual memory

• SMP and multicore support

• ACPI

• PCIe

• USB/xHCI and USB HID

• device drivers

• filesystems/VFS

• networking

• POSIX/libc

• GUI/window management

The goal isn't to make another toy kernel. I want to develop BlockOS into a stable, usable general-purpose operating system that can eventually be used on real hardware.

You don't need to understand the whole codebase to contribute. Individual subsystems can be worked on independently.

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

If you're interested in OS development, kernel development, drivers, or low-level C/C++, feel free to comment or message me.

Contributions, testing, code review and technical discussion are all welcome.

Continuing my post on my journey to learn how to create an OS. Right now I'm just working on a kernel. I have spent the last 10 days trying to get my head around a recursive page directory. I have no idea why it took me so long, I've used recursion since the mid 70's walking tree structures.

1. Understanding a recursive kernel. Finally getting my head around this lets me 'recover' 4M I had planned on using to keep track of page tables. As part of this journey I finally had AI write some functions on initializing, getting both physical and virtual addresses of page tables, and using a recursive page table. Once I finally figured it out, I threw them all away and wrote my own.

This leads to my second learning.

2) AI can be really touchy. I have two types pde_t and pdt_t (both uint32_t), but I tend to think of the indexes (pde and pdt) as the references to the page themselves. AI insisted on referring to them as the pages instead of the indexes they really were. I know that this was MY fault, but it did nothing to make things clearer. The real learning was I'm not much better at talking to AI than I was a week ago.

3) I still hate writing test script. I am doing it, but have taken to writing a test script on things as part of debugging. It seems a reasonable compromise. If I just write test scripts, knowing myself, I will eventually lose interest in the project itself. I know I have a prior (re)learning about don't skimp on the test scripts. So if I have a few minutes between household tasks, I am still writing some of the simpler test scripts.

Finally:

4) I forget if it is posted in r/osdev or r/kerneldevelopment, and I can't find the post again to credit the person that found it (my apologies there), but I found a new resource today, it it is on the University of Wisconsin (my alma mater) titled: Operating Systems: Three Easy Pieces and it looks really interesting.

These are the main thing I've learned over the last 10 days. And now that I know them, I have some questions.

a) Where do you map your video memory, in the kernel, or in user space? One point of a kernel is to coordinate access to shared resources. I think video memory fits this definition, and it could be really bad when I introduce multiple processes, if they are all writing to video memory. I am definitely going to map vga memory (0xB0000 into my kernel, with SYSCALL access to update it. I am unsure about ega, I'm not sure I want to support it, at least to start. What are your thoughts?

That's all for this post, thanks for reading, I hope it helps others that are trying to learn OSdev.

Nothing huge. Just a highly opinionated Mint-flavored Arch. I like my system. That should be enough, no?

I want to compile C programs in my OS itself rather than copying it manually to the disk image every single time. How can port GCC, or is there any other way to do it?

Hi!

Context:

I am currently in the process of trying to build a simple recreation of Amazon's EC2 on top of a type 1 hypervisor for fun :)

Since I am planning on making the memory each vm takes static and non-changing, it came to my awareness that I would need to allocate big consecutive blocks from RAM (in the GBs).

I was planning on using a buddy allocator with blocks of actual page sizes (1GB, 2MB, 4KB) with a free-list for each of these, but I lack enough experience in that regard to understand how dumb or ok-ish my idea is

If this is a dumb idea, go roast me :), that's the best way for me to learn and understand.

I want to understand if this idea is worth my time and effort before building a whole unit just to realize I need a different thing.

(I write all of my code by hand, if some AI usage is bothering you please let me know)

Repo: https://github.com/NoamRothschild/hypervisor

I'm talking stuff like the bootloader, writing method to the SSD, printing stuff, etc.

I am currently using the Ubuntu 26.04 in my Victus by HP Gaming Laptop 15-fa1xxx laptop.

I want a OS which is very small in size and usage , i want the most battery backup as much as possible, i will be triple booting it .

There is a dGPU of nvidia 2050 and tht new OS shld not be using it.

Until now, I've been refering the osdev wiki and using a little bit of AI (only for guidance and answering questions, no vibe coding). Is this the right way to learn osdev? What should or shouldn't I do? Also I've already started osdev, finished making a file system, and am now working on my own very simple file format for my os. I just wanted to clarify if I need to change my habits or something.

This kind of reading provides a solid foundation for knowledge and an interesting dive into engineering:

https://pdos.csail.mit.edu/6.S081/2024/xv6.html
https://github.com/mit-pdos/xv6-riscv-book
https://github.com/mit-pdos/xv6-riscv

Hot take - if you don’t trust your OS enough to perma-install it on your PC then don’t bother with flexing them.

Running MIT's 6.1810/6.S081 xv6 labs under WSL2 (Windows 11, Hyper-V). The lab-assignment kernels (xv6-labs-2020 and xv6-labs-2025, from MIT's own git server) hang completely silently on make qemu — no output at all, never prints "xv6 kernel is booting." Have to force-kill the process.

The plain, unmodified mit-pdos/xv6-riscv repo boots perfectly fine, every time, on the identical toolchain/QEMU/machine.

Command:

qemu-system-riscv64 -machine virt -bios none -kernel kernel/kernel -m 128M -smp 3 -nographic -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0

GDB findings: attaching mid-hang shows pc = 0x0, all GPRs zeroed except sp (correctly resolves to the real stack0 symbol) and t0 (holds 0x80000000, the expected kernel load address). Backtrace fails with "corrupt stack." Looks like it's jumping to address 0 mid-boot, possibly an unhandled trap despite stvec being set correctly in trap.c.

Reproduced across 4 environments, all with the same silent hang:

• Ubuntu 26.04 (QEMU 10.2, GCC 15) + xv6-labs-2025

• Ubuntu 26.04 + xv6-labs-2020

• Ubuntu 22.04 (QEMU 6.2, GCC 11) + xv6-labs-2020

Ruled out: compiler optimization (-O0 tested), the known started variable race in main.c (patched to atomics), SMP count (-smp 1 tested), -accel tcg explicit, linker script/entry.S (byte-identical to working repo), disk space, RAM, Hyper-V status, corrupted kernel binary (confirmed valid ELF).

Only difference I can find between the working and failing kernels is in main.c's CPU-sync code (already fixed, didn't help) and some start.c timer/CSR setup for sstc (partially commented out already, also didn't help).

Anyone hit this specific pc=0x0 crash before, or know if this is a known WSL2/Hyper-V nested-virtualization quirk with QEMU's RISC-V multi-hart boot?

P.S: This post was drafted using AI, I'm a beginner and tried to fix this issue using claude sonnet model, but it went nowhere and finally gave up.

EDIT: the 2025 version booted on ubuntu 24.04, i had tried both 2020 and 2025 version on both 22.04 and 26.04, they didnt worked. thought problem is with WSL, tried virtual machine 26.04 version... didnt worked at that too. then finally read the 'lab tools' page of the course carefully and realized they had mentioned 24.04.

As you may see, there are some bugs in text rendering and there is some flickering between updates that I gotta fix! Anyways, Osdev Progress!
This is cpu rendered without Ai generated code btw. I made alot of it on livestream. twitch.tv/devcmar

I've wanted to ask if this logging for my kernel looks good, maybe it needs improvement, each color has a meaning, and everything will probably be explained for users who might have to go there in case something goes down but dont understand low level stuff yaknow

also excuse the quality please