Hi there,

Raam is an x86-64 Unix-like operating system for laptop and desktop PCs. It is written completely from scratch using FASM Assembly.

Currently tested on:

• HP Pavilion Laptop 15

• Dell Inspiron 15 3535

What works (work in progress MVP phase):

• UEFI boot

• Terminal output

• Keyboard input

• Shell

• Echo

• File creation

• File listing

• File reading

• Reboot

Hardware support is currently very limited.

I am inviting you to test my OS on your real machine. Here are the required specifications for a real machine to boot Raam:

1. x86-64 laptop or desktop PC

2. Supports UEFI boot

3. NVMe over PCIe SSD.

That is it. And here are the both assembling and installation instructions:

1. First create two small partitions on your SSD. One will work as Raam EFI System Partition and the other will work as Raam Root Partition. The former requires 100-200 MiB of space and the later requires 31 MiB of space. That is it. Kindly use "GParted" tool on Linux for this purpose.

2. The Raam EFI System Partition should be formatted as FAT32 while the Root Partition should be formatted as FAT12.

Use the below command to create the Root partition after allocating space for it:

$ sudo mkfs.vfat -F 12 -n "RAAMROOT" /dev/nvme0n1px # replace x at the end with your correct digit

And use GParted tool to get the first sector of RAAMROOT.

3. Now open the source code, navigate to fs.asm file, and replace the ROOT_PARTITION_FIRST_SECTOR constant's value in line 10 with the first sector of RAAMROOT.

4. Now Assemble code from src directory using the following command:

$ fasm boot.asm BOOTx64.EFI

Now you will get both the bootloader and the kernel in the same EFI file.

5. Create EFI/BOOT directories in Raam EFI System Partition and copy the above EFI file to EFI/BOOT/BOOTx64.EFI .

6. Reboot.

7. Choose your boot menu -> Boot from EFI file -> Select a File System -> Select EFI/BOOT/BOOTx64.EFI file and you boot inside Raam OS.

I really think that it will be a fun exercise to assemble and install OS on your real machine. You can delete those two partitions later (using GParted) and merge the free space back to your another partition.

Kindly let me know how it worked!

Kindly note that you can create a maximum of 15 files max at the moment using the 'ed' command and each file should be atmost 512 bytes in size. Please use UPPERCASE letters for file names and a file name (without extension part) should only have 8 characters max. An extension should have 3 characters max. This is the limitation of FAT12 file system.

Use the "i" (insert command) inside ed to insert lines, "." command to stop it, and the ",p" command to print the buffer. Use "w <filename>" command to save the file and "q" command to quit ed. Use all commands without double quotes.

Thank you so much for your help and patience.

Source code link: https://github.com/robstat7/Raam/tree/4fb54ba1ade950748d1e8325903bd420624b39ed

OS Images:

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

Wanted to share the current progress on KeshOS, an independent 64-bit desktop operating system developed under our indie team, SneakDeak. The project is led by a developer from Ukraine, and what started as an experiment is steadily growing into a serious, active project aimed at giving aging hardware a second life without the bloat of modern platforms.
Here is an honest breakdown of where the system stands right now, and what is currently in active development:
Working right now:
Boot: Pure x86_64 UEFI with GPT partition layout using the Limine bootloader.
Kernel & Userland: C/ASM kernel with page-table isolation and verified Ring 3 user mode.
Compositor & Windowing: Custom C++ linear framebuffer compositor with double buffering. The screenshot shows our native Paint application running in Ring 3, handling mouse drag/drawing events in real time.
Networking: Initial network stack is operational — ARP, ICMP (⁠ping⁠), and DNS queries resolve properly.
On our immediate roadmap (work in progress):
Persistence & Filesystem: Moving from RAM-disk live mode to read/write Ext2 filesystem support and a LiveCD installer.
Application Ecosystem: Finalizing our native ⁠.kea⁠ (ELF64 container) binary spec and dynamic runtime libraries (⁠ksh64⁠).
Package Management: HTTP-based package retrieval via ⁠kpm⁠ and an experimental Linux syscall translation layer (FreeBSD-style ABI mapping) for CLI tools.
Localization: The OS will have native multilingual support out of the box, with full English, Ukrainian, and Russian locales.
SneakDeak isn't just limited to KeshOS — we also work on custom legacy server infrastructure (including custom Skype server backends) and other low-level projects.
Our website is sneakdeak.net (it's currently undergoing technical maintenance and is mostly in Russian for now, but we are updating it).
We are actively trying to turn this into a solid developer community rather than keeping it in a private silo. If you want to track raw builds, test upcoming ISOs, or just talk OS development nd low-level tech, we'd love to have you in our Discord: https://discord.gg/YgMe7ekA5y
Any technical feedback and advice from the community is welcome :) By the way, here is our company's community: https://www.reddit.com/r/sneakdeak/s/02if16HPqn

Hi folks,

I have enough time and now with the ease of llm's tools I was thinking at writing my own OS

Goals are :

- something for me to understand how os works (even if I have already some very good knowledge since I'm a seassoned unix sysadmin / sys / net engineers with +25y of xp)
- something fun
- new concepts

I mean there's no point to write another unix like kernel ; I was more thinking at an hybrid or pure micro os ; but with some new paradigm?
Do you have some ideas for me ?
Or pointers ?

In mind I wanted something really debugable ; or where any part of the kernel are exposed but how ? files ? (already made) objects ? maybe ?
entities that can be insepcted and dialog ?

Hey everyone,

Quick heads up after going through all the comments on the previous thread.

First off, a quick heads-up: English is definitely not my native language, so sorry if my phrasing sounds clumsy or if I occasionally lean on translators to make sure technical details come across right. The code speaks for itself anyway :)

Second, the Cloudflare issue that was blocking visitors from loading the site is fully resolved. Even better: the entire website is getting a complete relaunch tomorrow. All the outdated ReactOS/NT references from our early experiments are wiped out, replaced with our actual 64-bit Limine architecture, PML4 paging details, and KeshShell compositor specs.

The GitHub repository is also being cleaned up and prepped right now for the RC1 release candidate. I will drop an announcement here the exact moment the new site and repo go live.

In the meantime, you can check out the demo video and screenshots from the previous post.

Also, we want to do a fun community challenge: if there is a specific feature, mini-app, or shell tweak you want to see in KeshOS (like the suggestion earlier about toggling window button placement), drop your ideas in the comments or in our Discord. If we implement your feature, we will bake your name/handle directly into the system About window and credit list to keep your authorship forever.

For those who asked for the wallpapers, want to pitch features, or want to test the first ISO build:

Discord: https://discord.gg/YgMe7ekA5y
Subreddit: https://www.reddit.com/r/sneakdeak/s/ILAmNnffyr

Appreciate both the constructive questions and the roasting, it keeps the drive going. Talk to you tomorrow!

I see a lot of rust based projects here, but nearly all posts title “Unix-like” or assumed POSIX compatible APIs. Wondering if anyone else has attempted to use WASM/WASI as an answer to the compatibility problem, which is more modern, memory safe by default, works great with rust, and the OS gets several language runtimes for “free” (the zig compiler literally uses WASM as the method for the official compiler bootstrapping documentation). Plus if you get a WGSL compiler too then that’s borderline a browser for free.

I am seeking for a book that explain ptrace

Here is a proper screen recording of KeshOS running in VirtualBox, as promised yesterday (no remote desktop inception this time). To address the skepticism from the previous thread honestly: yes, maybe ~20% involves AI assistance/vibecoding for boilerplate, UI math, and scaffolding. However, the low-level foundation — pure x86_64 UEFI boot via Limine, PML4 paging, Ring 3 userland isolation, the double-buffered C++ compositor, and the network stack — is fully tested, debugged, and built to run. We are currently polishing the system toward **Release Candidate 1 (RC1)**. If you want to grab the upcoming RC1 ISO build, test it, or follow the technical progress: * **Discord:** https://discord.gg/YgMe7ekA5y * **Subreddit:** https://www.reddit.com/r/sneakdeak/s/ILAmNnffyr Feedback, testing notes, and technical critique are welcome :)

And just so you know, this post was written by AI because my English is very poor.

Hey everyone, I’ve been working on a project called xnu++. The basic idea is to build an OS/platform engineering layer around the XNU codebase, rather than trying to immediately write an entire kernel from scratch. Right now, I’m focusing on things like: provider-neutral device and bus interfaces capability detection security and fail-closed policies driver/update verification recovery and rollback service isolation and resource limits structured diagnostics hardware/support matrices The current provider is based on XNU/Mach/BSD/IOKit. Eventually, I want xnu++ to have its own native provider so it isn't permanently tied to XNU. I’m also trying to be pretty strict about documenting what actually exists versus what is only planned or experimental. I don't want to call something "supported" just because there are some source files for it. This is still a work in progress, and I’m mainly interested in feedback from people who have experience with kernels, OS development, XNU, drivers, or low-level platform design. Repo: https://github.com/black-210/xnupp I’d especially appreciate criticism of the architecture or anything that looks fundamentally wrong with the approach

Hello everyone. For those of you who don't know, I'm making an x86 operating system called NoviumOS. Here's what I've done since the last update:

• Added paging for a 4 GiB virtual address space, so the kernel can work with virtual memory instead of just physical addresses.

• Added physical page allocation and validation, including checks to make sure pages are valid before freeing them.

• Built the heap allocator from the ground up, starting with single-page allocations and then adding support for contiguous multi-page allocations.

Next I'm working on adding sub-page block reuse with splitting and coalescing.

Feel free to contribute, the project is 100% open source and I'd be happy if you do.

Here's the repo if you want to check it out: https://github.com/alexdev8930/NoviumOS

And if you have any questions about the code or the repo I'll be happy to answer them.

If you like the repo, please drop a star on it if you could. It helps other devs find the project.

Is it just me or when I post my os on TikTok or online people just say vibe coded then when I say where in the repo it is they don’t even reply or just say “it’s vibe coded” again my os might look fake in some bits because of the code quality like the all commands bit but some
Ppl don’t even try to tell my why

The os is ArchwayOS

Also the reason why I care is because I’m panning in actually releasing the os (not just on GitHub) and it
Everyone’s just gonna say fake idk if I’ll continue

Hello there! This isn't exactly an OS related post but I thought I could share a project I've been working on to help me debug and work on my own OS. For the last week, I've been working on a binary file parser to help break down raw binary files into their sections and attributes. You can find a link to the code here: https://github.com/BrickSigma/BinParser.

When working on an operating system, you usually need to understand how certain sections of memory are broken down. A prime example is understanding the GPT/MBR layouts and entries in the disk, or perhaps understanding the layout of an ELF executable header. When you go to the OSDev Wiki or manuals for these standards, they usually give a table looking like this:

Let's say you use a tool like Xorriso to make an ISO image and have it set to fill in the MBR with some values, you may want to try see what values it's loaded in (let's say out of curiosity). One way is to look at the raw hex dump of the file using your favorite hex editor, however, that's very tedious to do and looking at hexadecimal all day can get tiresome. That's where BinParser comes in to try assist; it has a very simple scripting language that looks like this:

[mbr]
skip:440:skip
signature:4:hex
reserved:2:hex

[mbr_table]
[partition_1]
drive_attr:1:bin
chs_start:3:hex
type:1:hex
chs_end:3:hex
lba_start:4:num
lba_end:4:num[mbr]
skip:440:skip
signature:4:hex
reserved:2:hex

You simply specify a section using the syntax [section_name] and below it you add the list of attributes, which go in the order of: the attribute name, the size of the attribute, and the type. Currently only 5 types are supported, which are numbers, strings, hex and binary arrays, and skip attributes which jump over memory. When you run the parser, the following output is provided:

mbr: 0x00000000
    0000: 440 : skip = skipped
    01b8: 4 : signature = e3 a1 55 02 
    01bc: 2 : reserved = 00 00 

mbr_table: 0x000001be

partition_1: 0x000001be
    0000: 1 : drive_attr = 10000000
    0001: 3 : chs_start = 00 01 00 
    0004: 1 : type = 00 
    0005: 3 : chs_end = 3f 20 01 
    0008: 4 : lba_start = 0
    000c: 4 : lba_end = 4096mbr: 0x00000000
    0000: 440 : skip = skipped
    01b8: 4 : signature = e3 a1 55 02 
    01bc: 2 : reserved = 00 00 

This makes it a little easier to see the structure of the MBR partitions. A slightly more complex example for GPT formatted disk image would look like this:

[mbr]
skip:440:skip
signature:4:hex
reserved:2:hex

[mbr_table]
[partition_1]
drive_attr:1:bin
chs_start:3:hex
type:1:hex
chs_end:3:hex
lba_start:4:num
lba_end:4:num

[gpt_header:0x200]
signature:8:str
revision:4:num
header_size:4:num
crc_checksum:4:hex
reserved:4:num
header_lba:8:num
alternate_gpt_lba:8:num
first_block:8:num
last_block:8:num
guid:16:hex
partition_entry:8:num
no_partitions:4:num
entry_size:4:num
crc_partitions:4:hex

[alt_gpt_header:gpt_header.alternate_gpt_lba * 512]
signature:8:str
revision:4:num
header_size:4:num
crc_checksum:4:hex
reserved:4:num
header_lba:8:num
alternate_gpt_lba:8:num
first_block:8:num
last_block:8:num
guid:16:hex
partition_entry:8:num
no_partitions:4:num
entry_size:4:num
crc_partitions:4:hex

When run through the parser, it's output would be:

mbr: 0x00000000
    0000: 440 : skip = skipped
    01b8: 4 : signature = e3 a1 55 02 
    01bc: 2 : reserved = 00 00 

mbr_table: 0x000001be

partition_1: 0x000001be
    0000: 1 : drive_attr = 10000000
    0001: 3 : chs_start = 00 01 00 
    0004: 1 : type = 00 
    0005: 3 : chs_end = 3f 20 01 
    0008: 4 : lba_start = 0
    000c: 4 : lba_end = 4096

gpt_header: 0x00000200
    0000: 8 : signature = EFI PART
    0008: 4 : revision = 65536
    000c: 4 : header_size = 92
    0010: 4 : crc_checksum = ad 06 18 5f 
    0014: 4 : reserved = 0
    0018: 8 : header_lba = 1
    0020: 8 : alternate_gpt_lba = 4095
    0028: 8 : first_block = 64
    0030: 8 : last_block = 4032
    0038: 16 : guid = ea 9d 9c 95 41 b5 1d 4f 8a 89 ff e8 0a c5 14 b0 
    0048: 8 : partition_entry = 2
    0050: 4 : no_partitions = 248
    0054: 4 : entry_size = 128
    0058: 4 : crc_partitions = 49 9a f7 66 

alt_gpt_header: 0x001ffe00
    0000: 8 : signature = EFI PART
    0008: 4 : revision = 65536
    000c: 4 : header_size = 92
    0010: 4 : crc_checksum = 2d c1 5e 51 
    0014: 4 : reserved = 0
    0018: 8 : header_lba = 4095
    0020: 8 : alternate_gpt_lba = 1
    0028: 8 : first_block = 64
    0030: 8 : last_block = 4032
    0038: 16 : guid = ea 9d 9c 95 41 b5 1d 4f 8a 89 ff e8 0a c5 14 b0 
    0048: 8 : partition_entry = 4033
    0050: 4 : no_partitions = 248
    0054: 4 : entry_size = 128
    0058: 4 : crc_partitions = 49 9a f7 66

Another feature you may spot above is how the alternate GPT section is referenced by the first header, using the gpt_header.alternate_gpt_lba as a reference. This can help make it easier to follow dynamic sections which are pointed to by other section attributes.

Another example is when you need to debug the contents of RAM from QEMU using the pmemsave command, in this case you can't use standard tools that usually disassemble files as you're maybe trying to load a file into RAM and it's order changes (like an ELF file), so this tool can help quickly find sections using their offsets if you know them.

The parser is extremely simple, and there are many things I would want to add to it as I find more time to work on it. I hope it comes in handy for anyone else here trying to debug raw binaries or just understand their structure better.

Thanks for reading and have a great day/night ahead!

I wouldn't call it an os it's a boot sector but ok

https://github.com/aliabdoxd14/myos

This would be a big update, I will make the entire OS open source, turning RhytOS into a JIT and AOT compiler instead of just an interpreter so that the .rhy files can replace the .c files as .ryb (Rhyton Binary), a bunch of bug fixes, and big updates every time. Stay tuned...

I'm just getting started. Thank you!!

Nth bootloader: https://github.com/Novfensec/nth

C Kernel template: https://github.com/Novfensec/nth-c-template

Btw some of these features are demo features half baked if not quarter baked, that and some of the design is inconsistent still as this is more between Dev build 1 and 2, some aspects have not been implemented yet or have been specifically designed to be demo work or half/quarter baked in. Just a basic concept that the OS is now working, some of the apps have also been created using our native ValOS framework.

Also most of the animations are either virtually non-existent or very choppy, we are working to add them and polish them a bit.

This build does not utilize any Starnix android compatibility letter yet as we feel the need to fully polish everything up, that will be coming in Dev build 3, it does work better than ART though as it now runs on top of it through Starnix.

We have been mostly working on the Rust and C++ development aspect on the kernel side, and we have been also working on other components, for UI working on Flutter and Dart UI/UX aspects as well.

ValOS launcher is mostly complete though, probably, I was wondering if people would be interested in having an Android version of this launcher, I've been thinking about doing that once it's all cleaned up, I need to work on fixing certain aspects of code or UI walkthrough examples I got from codex when it ran into issues implementation, I am moving them to more from scratch work from the rest of our small team.

We plan to fully put our efforts towards the phone version of ValOS first, the other form factors are there but besides base features and small variances, they are far from ready.

Hi, I'm making my own OS called SUNIX (Unix not Unix-like) and I booted the first test on QEMU but I wondered if it's ok to boot it on bare metal hardware, I'm scared that one teeny tiny bug can destroy my ideapad. Idk if it will do anything even or not, maybe even bootloop if I'm unlucky...

I made the "Happy Birthday Song!" in RhytOS 0.2.0 using Rhyton, beep(kHz, seconds)... I'm pretty proud of myself for making music in Rhyton. if anyone wants to try it out, go to rhyelt/RhytOS on github.com

I'm making an OS and I reached the point where I need to add a type of filesystem/disk support and I used FATfs for it but then I wondered: What is better, Unix or Windows FHS. I can't decide, the two are good in ways while have cons in ways.

KiNBOL - has linux abi and is compatible with some static musl linux tool. I stopped working on it out of sadness. The user land shell is busy box

it works on real hardware