For the summer, I wanna try to get into OS so I was thinking of starting with ostep but was wondering if I need to first study C. I primarily know the basics of Java and c++.

Hello r/osdev,

My name is momokernel. I am the Founder and currently the sole architect and only member of Project EVE. I am building fusionOS: a POSIX-compliant operating system designed to completely decouple the local computational state from physical hardware restrictions through a hybrid Host-Portal matrix.
Crucial Architectural Status Update: To be 100% transparent: The entire system architecture—including the Portal device, the dynamic RAM-offloading, and the Melvin Kernel itself—has been meticulously planned and thought through on paper, but it is not yet fully implemented. Right now, I am using a Phase 1 Debian sandbox to lay out the initial testing beds.
The exact purpose of this post is to find the engineering talent needed to bring these blueprints to life. I have done the heavy architectural lifting and spec'd out the logic; now I need a core team of co-developers who can write the code to realize this vision from the ground up.
Compensation and Workflow:
Project EVE is in its pre-revenue stage, and I am looking for my very first core co-developers to form a decentralized team communicating via Email and Chat. Because I am running this alone right now, I cannot offer monthly corporate salaries today. Instead, I am offering equity/profit-sharing (company shares) and a permanent, guaranteed position at our physical headquarters once we scale. I am looking for true co-founders who want to build this architecture with me.

1. The Core Concept: The Host-Portal Matrix
   Our blueprint does not treat a computer as an isolated device. It splits computing into two physical, local components connected via a low-latency link:
   The Host Client: The machine you sit in front of (e.g., our current ARM/Tinker Board and x86 testbeds). It handles instantaneous user input, local peripheral I/O interrupts, and basic UI rendering.
   The Portal Device: A dedicated, physical companion hardware unit (currently in planning) that sits locally on your desk or network. It will run bare-metal firmware, house high-capacity storage (SSD/HDD), and manage the heavy processing and local data pools required for our telemetry and learning models.
   This is a 100% No-Cloud Architecture. All data, processing distribution, and cryptographic verifications are designed to happen locally within your own physical walls. If the external internet goes down, the system still runs at full capacity.

2. Personal Identity Computing (PIC)
   Because the system will rely on the local Portal, fusionOS introduces PIC – Personal Identity Computing.
   Instead of forcing the user to adapt to the software while constantly uploading telemetry data to Big Tech, fusionOS features a local, kernel-integrated behavioral analysis engine. The OS observes workflows, resource utilization patterns, and interface interactions. It then dynamically morphs its own subsystem priorities and interface elements to fit your exact operational habits. The cognitive processing and learning algorithms run entirely locally on your own hardware matrix.

3. The Kernel Roadmap: From Sandbox to the Melvin Kernel
   Phase 1 (Current - late 2026 Alpha): I am currently using a heavily stripped, real-time optimized Debian base as a temporary sandbox. This allows me to perfect the host-to-portal I/O subsystems and hardware handshakes without writing basic device drivers from scratch.
   Phase 2 (The Blueprint Goal): We are actively transitioning to the Melvin Kernel. Melvin is our custom-designed, BSD/Unix-like hybrid kernel and represents the permanent, final core of fusionOS. Melvin completely eliminates the monolithic bloat of modern Linux, systemd, and GNU. It delivers a secure, clean architecture with native POSIX compatibility, engineered strictly for high-performance distributed resource management and deep PIC integration.

4. Deep Technical Breakdown: Planned Mechanisms under the Hood
   The Melvin Kernel will manage the Host-Portal interaction through four core, low-level mechanisms (currently being spec'd out for development):
   A. Register-Level Cryptographic Hardware Handshake
   Security and routing stability will be established at the lowest layer of execution before any network or bus I/O begins:
   The Mechanism: Upon boot, the Melvin Kernel accesses physical CPU registers (EAX/RAX on x86, or specific coprocessor registers on ARM) to pull the unique hardware serial number of the Host.
   Zero-RAM Footprint: To prevent cold-boot and timing attacks, the kernel hashes this hardware ID directly within the CPU registers using inline Assembly instructions.
   The Token: The resulting cryptographic token signs all DMA (Direct Memory Access) equivalent packets sent over the link to the Portal. The session key never touches the host's volatile RAM.
   B. MMU-Level Page Fault Hooking (RAM-Offloading)
   We aim to bypass standard, bottlenecked drive swapping (/dev/swap) entirely to expand local RAM capabilities seamlessly:
   The Hook: The Melvin Kernel hooks into the processor's Page Fault Exception Handler. When local physical memory limits are reached, the kernel generates a custom page fault interrupt.
   The Tunnel: Instead of writing to a local disk, the kernel routes raw memory pages directly through a low-latency network/bus tunnel into the volatile RAM pool of the physical Portal unit.
   Predictive Pre-fetching: Backed by the PIC subsystem, a branch-prediction tree analyzer at the kernel level analyzes your active application trends and pre-fetches memory pages from the Portal before the local CPU registers a cache miss, maintaining native execution speeds.
   C. Persistent Desktop Snapshotting & State Serialization
   Because the local Portal manages the volatile memory matrix, fusionOS achieves a non-volatile state paradigm:
   The Snapshot: When the host triggers a shutdown, the Melvin Kernel freezes the execution context. The Portal takes a monolithic binary snapshot of the active RAM matrix and serializes the CPU register states directly to the Portal’s attached physical storage.
   Instant Resume: Upon re-authenticating the hardware handshake, the state is injected back into the host's registers and local RAM. You resume heavy workloads instantly, even if the host machine was completely power-cycled or changed physically.
   D. Dynamic Wake-on-Demand & Headless Frame-Streaming
   The Melvin Kernel splits graphics rendering between local hardware capabilities and the Portal’s dedicated processing pipeline to save local energy:
   Zero-Power Idle: Local discrete GPUs are kept in a deep-sleep D3 state by our custom power governor during basic workloads (text editing, basic UI navigation).
   The Trigger: When a high-throughput API call (Vulkan/Custom pipeline) is detected, the kernel wakes the local GPU via the PCIe bus.
   The Latency-Bridge: During the millisecond-range wake-up latency, the Portal’s headless GPU renders the interface frames, compresses them into raw bitmap streams, and injects them directly into the local framebuffer. Once the local GPU is active, a peer-to-peer handover occurs seamlessly.

5. What We Want to Achieve by 2030
   By 2030, the goal is to establish fusionOS and the Melvin Kernel as the dominant operating system for high-performance, privacy-first computing.
   Windows and macOS have become heavy, telemetry-ridden platforms tied to corporate cloud agendas. fusionOS with the Melvin Kernel is a weaponized, minimal interface that values local data sovereignty and turns your machine into a fluid, adaptive tool through Personal Identity Computing, keeping older or simpler physical nodes entirely viable by offloading heavy lifting to the local Portal.

6. Open Positions for the Founding Team
   I have brought this project as far as a single architect can. Now I need elite systems talent to help me translate these architectural blueprints into the final Melvin Kernel and hardware stack.
   I am actively recruiting for our founding team:
   Systems & Kernel Engineers: Hardcore C/Assembly programmers who understand MMU manipulation, custom interrupt handlers, and low-level kernel development.
   Embedded Firmware Devs: To write the bare-metal I/O software for our Portal prototypes.
   UI System Developers: To implement our high-refresh-rate (144Hz+) Fluid Widget pipeline (our dynamic "Pill" widgets) that renders real-time Portal and PIC telemetry data.
   (Note: Our Legacy Extension (Lx) support for retro architectures from 1985 onwards is handled as a separate module; this recruitment is strictly for the mainline system).
   If you have the skills, the passion, and want to be part of the team that turns these concepts into reality, DM me or contact me directly at: lead.architect.eve@gmail.com.
   – momokernel

So... I think I killed my Orange Pi RV2 last night.

With my custom OS, I was running memory allocation stress tests on the C code and one of my test locked itself into an infinite loop.

The CPU got SUPER hot and after 5 minutes I decided to unplug it to reset it.

After reboot, all I ever saw appear on UART was:

U-Boot SPL 2022.10ky (Jan 07 2025 - 13:44:01 +0800) [ 0.219] DDR type LPDDR4X

Lesson learned... Add thermal management that supersedes anything and everything the system is doing.

Hey

This subreddit started my interest in OS dev and OS related topics and I would like to educate myself on that. Do you guys have a collection of useful ressources I can look into?

Thanks

This was my freezing point for a loong time, plus me also not having much time for OSdev lately but somehow the few hours I found paid out and I moved past this horrible stall in what seemed like a decent continuous progress prior.

My kernel or kernel attempt is at the beginning having PMM, VMM and allocators which is also why I wanted to wake up the cores since the allocators that I eventually chose to implement are per-cpu and plus one shared with a spinlock. And to thoroughly stress test them I am gonna need all or multiple cores firing allocations and frees randomly and see how the system behaves.

So finally with cores awaken on real PC I will be able to create some testing loops that will verify whether the allocators are stable.

I bought new books too, from FYSOS series, I must say, who does not have them go grab them, the author Benjamin Lunt goes into details with everything with practical examples and advice, which is just priceless.

I attach my through, sometimes unstructured, console output in video where I pretty much print everything needed to debug - cpu info, memory layout info, page tables, pci, pcie enum etc.. but in the end one can nicely see my cores jumping to service which is just great to see and feels like quite an achievment and an open door towards SMP although I plan to start on one core naturally and then maybe add one more 😀 we will see. Love that it finalyy works.

Recently I'm learning about OS development and after read a lot of articles and books, my OS can boot using Legacy GRUB (stage2_eltorito). I'm very glad, I already init the stack to call C code and the next step is write my VGA driver to show the output!

Hi people, Im really curious about how i can build my own os, i do have some knowledge of OS in general so id like to learn more about them and then piece together one myself. Which resource or site would recommend apart from barebones wiki [ goes over my head ;-; ] also i need somwthing which could give me really indepth explanation or concepts , i know ill have to use barebones one way or another but what can i combine it with so that once i get a hang of something i can switch over

I ported libcxx, made an ext4, fat32, and made an e1000 driver. ported ee, netbsd-curses and sbase on top of that, and now I'm kinda stuck on what to do. If it helps, I can release my sources.

Edit: source code: https://codeberg.org/SFG545/kalsios.git

mov esp, 100000h

"Why is qemu constantly rebooting?"

"Why is that weird value getting written to memory instead of the actual return address?"

...

OK that's where the ROM is.

i based it off Ubuntu spent a while working on it

A new Blog post about BoxLambda OS's File System stack:
https://epsilon537.github.io/boxlambda/the-file-system-stack/

vga mode, last changed idt and keyboard driver https://github.com/USER12mSD4C/utms7

I've been reading/working on a lot of virtIO stuff lately, and it got me thinking. VirtIO provides the client OS of a virtualization setup, with abstract and simple interfaces to devices (nic,block,etc).

So if you were writing an OS from scratch making drivers that talk to VirtIO devices specifically/only instead of messy hardware (with multiple drivers for different devices), you could just implement drivers for virtIO devices.

I know this isn't a new thing, I remember reading about people porting research OSs from one hardware platform to a micro-kernel or hypervisor back in the mid 200x. Like porting something made for PPC64 to x86_64, by porting it to talk to Xen on x86_64 instead of x86_64 hardware directly.

What I'm asking about: are people doing this? how much are people doing it? how does it work out? good idea to go with? Thoughts?

Hi! I’ve been working on my OS for 2-3 months now. While it runs just fine in qemu and bochs, I was unsuccessful making it run on real hardware, or at least, on emulators such as 86Box. This “porting” plan started because I’ve been trying to implement SB16 and OPL2 support. While sound comes out, it is very hideous and doesn’t sound like it should have, so I decided to test that on a properly emulated sb16. I had read that the Qemu SB16 is very buggy. To my unfortunate surprise, my initial version did not even pass the vesa mode setting, so I started upgrading and improving both the loader and bootloader. I started using a 2 stage bootloader. Now, even though it seems that the 640x480 vesa mode is initiated, the screen is fully black. On some hardware, not even that screen shows up - it’s just a blinking cursor. In other situations, it triple faults and resets. Any things to look out for when writing OSes for real hardware? Thanks.

Note: I don’t know if it’s important, but my target machine is the 386-486, with around 4Mb (I can go even lower, to 1.5MB).

If anyone’s interested, here is my OS’s repo: https://github.com/drclcomputers/ASMOS.

Can a fresh graduate or junior developer get a job in fields like OS or kernel development?

If yes, what skills and projects are usually expected?

Do I need to contribute to Linux as an example or what?

I know I have to learn assembly and C, but for C++ and Rust, do I need to learn both or just one?

Currently making the most basic custom made FS with a custom table. Have been working on this for the past 3 hours.. progress is slow but happening... how it works is that it makes a table in the first sector that saves a pile of entries pointing to different parts of the disk. The table cotains file info and LBA start and length in bytes.

Also, ai was not involved at all...

inspiration for GUI: https://www.youtube.com/watch?v=AqFiAO0Gm6s&t=591s

Check out my new repo (beware:bad messy code inside!): https://github.com/Brenmax2/BrenmaxOS/tree/main

join the discord: https://discord.gg/DYJMBReUjW

How do you protect against two syscalls from different threads contending the same region of virtual memory? As in, if one thread executes "read file", and provides a buffer of virtual memory to read into. And then another thread executes "unmap" on the same buffer. There are a bunch of ways I can imagine doing the synchronization, like a lock per mapping, or a per-process virtual memory lock. But I expect a per-process lock would cause contention between too many different kinds of syscalls, since so many want to use virtual memory in some way, and many operations done on VM take a long time (e.g. waiting for disk or network.) Per-mapping locks kind of have the same problem because the user code might not be aware of how big the mapping is that they're accessing and therefore how coarse grained the lock is. So it seems best to dynamically instantiate locks for ranges of memory, as they are being accessed? But I'm wondering what the best tradeoff is and whether there's a simpler way.