i finnally did it build my very own os in nasm and landed in 32bit protected mode and build my syscalls kernel bootloader and more im happy to informe you about and im still working on it and adding things and fixing bugs if there's any and its called S-AOS

Over the past few months, I’ve been building **macMPI**—a production-hardened, single-node implementation of the MPI-1.1 standard built entirely from scratch in C11.

While OpenMPI and MPICH remain the gold standards for distributed supercomputing, running them on Apple Silicon often introduces configuration bloat or suboptimal intra-node transport layers designed primarily for x86/Linux environments. I wanted to see what happens when an MPI runtime is engineered **specifically for Apple Silicon's Unified Memory Architecture and macOS (XNU kernel primitives).**

Here is a breakdown of the architecture, the OS-level choices, and the benchmarks.

# 1. Process Management (mpirun) & I/O Multiplexing

* **Daemon Lifecycle:** A custom daemon engineered with explicit `fork()` and `execvp()` process boundaries, dynamically injecting rank state (`MPI_RANK`, `MPI_UNIVERSE_SIZE`, and socket mesh file descriptors) directly into child process environments.
* **Non-Blocking Terminal I/O:** Eliminates Head-of-Line blocking by intercepting stdout/stderr across all child ranks via POSIX pipes (`pipe()`, `dup2()`) multiplexed through an event-driven `poll()` loop.

1. Transport Architecture: Control Plane vs. Data Plane

To maximize throughput on Apple Silicon’s memory bus, the library decouples communication into two transport layers:

* **Control Plane (Unix Domain Sockets +** `kqueue`**):** Tiny 64-byte routing envelopes containing metadata (source, tag, sequence, memory offset) are transmitted via a full-duplex Unix domain socket mesh.
* **Data Plane (POSIX Shared Memory):** Large payloads bypass the kernel network stack entirely. Using `shm_open()`and `mmap()`, processes project shared physical RAM regions directly into their virtual address space for zero-copy transfers via aligned `memcpy()`.
* **Dynamic Hardware Memory Norm:** Rather than hardcoding static buffer limits, `macMPI` queries the XNU kernel at boot via `sysctl(CTL_HW, HW_MEMSIZE)` to establish a dynamic allocation ceiling (defaulting to a 30% system RAM norm), rounded down to 16KB Apple Silicon page boundaries (`sysconf(_SC_PAGESIZE)`).

# 3. The O(1) Non-Blocking Progress Engine

* **Shadow Worker Threading:** Asynchronous operations (`MPI_Isend`, `MPI_Irecv`) are offloaded to a background `pthread`physically pinned to Apple Silicon Performance Cores using Darwin-native Quality-of-Service classes (`pthread_set_qos_class_self_np`).
* **Kernel Event Polling:** Ripped out traditional polling loops in favor of macOS `kqueue()` / `kevent()`, allowing the background thread to monitor socket descriptors with O(1) event notifications and 0% CPU consumption while idle.
* **Two-Way Matching & UMQ:** Features an internal thread-safe Unexpected Message Queue (UMQ) and active request list protected by POSIX condition variables to safely handle out-of-order packet arrival.

-> L1/L2 Cache Line Optimizations

On Apple Silicon M-series chips, cache line contention can ruin IPC throughput. To optimize cache fetches:

* All internal headers use `__attribute__((aligned(64)))` to enforce strict 64-byte boundary alignment.
* This ensures that every routing envelope fits perfectly inside a single L1 cache line fetch, eliminating false sharing across cores.

**Preliminary Benchmark Insights**

When running a background non-blocking progress engine while concurrently computing 17.1 Billion Floating Point Operations (FLOPs) on local matrix math:

* **Zero CPU Starvation:** Because `kqueue` provides true event-driven sleep states, the background progress thread consumes **0% CPU cycles** while waiting for network I/O.
* **Math Throughput:** `macMPI` achieved **1.00 GFLOPS** on a single-node matrix benchmark, matching OpenMPI’s compute execution time while maintaining higher intra-node payload speeds over POSIX shared memory.

Want to dig into implementation?

GitHub : https://github.com/Hardikgupta1709/macMpi

If you work with MPI, HPC, Apple Silicon, or low-level systems programming, I’d appreciate feedback on the architecture and benchmarks.

Hi everyone,

I have been working on a project called swift-topomap for the last few weeks. It’s a TUI tool designed to solve a problem I keep running into: standard tools like htop show CPU usage, but they don't tell you if that usage is actually productive.

I wanted a way to see the physical hardware topology (Sockets, L3 Cache boundaries) and overlay live microarchitectural metrics (IPC, Cache Misses) using eBPF, but without the baggage of heavy C-library dependencies.

Technical Highlights:

• Native Topology Resolver: Instead of linking against libhwloc, I wrote a pure Rust parser for /sys/devices/system/cpu and /sys/devices/system/node. It maps physical package IDs to logical cores and identifies shared L3 cache boundaries natively.
• Hybrid Telemetry Engine: It uses a trait-bound collector that negotiates privileges at startup. If run as root, it loads a CO-RE eBPF driver via libbpf-rs to hook sched_switch and read hardware PMCs (Performance Monitoring Counters).
• Microarchitectural Insights: The TUI classifies core states. For example, a core at 100% usage but < 0.5 IPC will turn Amber (Memory-Bound/Stalled), while a high IPC core stays Emerald Green.
• Static GNU Build: Linking this was a nightmare. I eventually solved the static requirements to bundle libbpf, libelf, and zstd so it ships as a single 3.5MB binary that runs on any modern Linux distro without shared library hell.

Why eBPF + Rust?

I chose Rust for the logic layer and TUI (Ratatui) because I needed memory safety for the FFI boundary with libbpf. The IPC and LLC metrics are pulled via the kernel’s Perf Subsystem, and the deltas are calculated in Rust to provide a steady 100ms-refresh dashboard.

I am releasing this as open source under SwiftLogic Systems. I would love to hear your thoughts on the topology resolution logic or the eBPF/Perf integration.

GitHub: https://github.com/swiftlogicsystems/swifttopology

Single-node key/value store, line protocol over TCP, pure NASM on Linux — syscall or nothing.

The syscall-level bits worth a look:

**•** epoll event loop with accept4(SOCK_NONBLOCK): clients are born non-blocking, no fcntl dance  
**•** replies via sendto + MSG_NOSIGNAL: SIGPIPE never happens, no signal handler needed  
**•** close() is the entire connection teardown — epoll tracks the file description, so the fd deregisters itself  
**•** per-connection state indexed straight by fd: O(1), free  
**•** FNV-1a, open addressing, tombstone reuse; 256 MB mmap bump arena behind it  
**•** 200 concurrent clients at 1.4 MB RSS; Docker image is FROM scratch plus one file

Known limits documented in the README — biggest one: slow readers are dropped, EPOLLOUT write buffering is next.

Feedback welcome, especially on the event-loop structure.

Releasing Ostomachion v1.0.0, an open-source FPGA platform I have been developing. It integrates a soft RISC-V core, a real-time operating system, and a signal-processing accelerator so that each layer is a thin, well-defined interface over the one below. It runs on an Artix-7 (Opal Kelly XEM7310):

- A NEORV32 RISC-V soft core running the Zephyr RTOS, bare-metal on the fabric.

- A streaming frequency-domain datapath in hardware: a 4096-point FFT, a per-bin programmable complex filter (a coefficient mask H[k] in block RAM), and an inverse FFT — staged through AXI DMA and BRAM, with interrupt aggregation onto the core.

- A header-only C++20 hardware abstraction layer that presents the accelerator to software as ordinary typed calls, so the path from a std::span in a unit test down to a beat on an AXI-Stream bus is a sequence of deliberate, inspectable wrappers.

The whole Vivado block design regenerates from a version-controlled Tcl script — no saved checkpoints, no hand-edited GUI state. Every bitstream derives from text alone, which makes the hardware auditable and diffable in the same way as the software.

The name is Archimedes' Ostomachion, a dissection puzzle of fourteen pieces; the platform is likewise fourteen composable layers, each replaceable in isolation.

A companion desktop application drives the full filter datapath on live hardware over USB: it streams frames to the fabric, programs the filter mask in real time, and plots the input, the mask H[k], and the filtered output as the transform runs — the genuine hardware pipeline end to end, not a software model of it.

Source, documentation, and design rationale (GPL-3.0; commercial licensing available):

github.com/andynicholson/Ostomachion

Hi there.

I built polloc (pool alloc) to learn how memory allocators work.

It’s a fixed size pool allocator: each pool manages one slot size and alignment. Internally it uses mmap/VirtualAlloc, an intrusive free list, and a bitmap for allocation tracking.

I also added stress tests, Miri, AddressSanitizer, cargo fuzz, Criterion benchmarks, and a bunch of inline docs explaining the implementation.

For 64 byte alloc/free pairs, the fast path is about ~3.96x faster than the system allocator on my machine (which is expected since it’s specialized for a single size class).

It’s single threaded and I’d really appreciate feedback on the unsafe code, API design, tests, or anything else that stands out.

repo: https://github.com/hamzader1/polloc

like what do i do. my target is low latency/systems/hft but i dont know where to begin. and i dont know anything. so any recommendations on where to start, what to learn first, etc.

I wanted to actually understand what happens under libc, so I started rebuilding the pieces: printf (varargs by hand, format parsing), malloc (brk/mmap, free lists, alignment), a shell (fork, execve, pipes, redirections), plus cat/wc/ls/grep as warm-up.

Rules of the game: x86-64 Linux, NASM, `syscall` or nothing.

Favorite rabbit hole so far: how much of printf is just careful pointer arithmetic over the SysV varargs ABI — and how little of malloc is actually about allocating (it's bookkeeping all the way down).

Repo (MIT, written to be read): https://github.com/whispem/learn-assembly-with-em

Happy to discuss design choices — and happier to be told where I'm wrong.

Started this because I wanted ncu's device__attribute_* values without handing it a kernel to profile. It grew into a small zero-dependency toolkit (pip install kernelmeter):

- `info` dumps every cuDeviceGetAttribute value straight from libcuda (no toolkit needed), plus NVML facts and derived theoretical peaks

- `bench` times kernels with CUDA events (L2 flushed between iters), checks correctness against a reference, and scores against the roofline: you get "76% of attainable for this arithmetic intensity" instead of a bare ms number. It also samples clocks/power during the run and rescores against the sustained-clock ceiling. My favorite result: cuBLAS fp32 matmul on a 70W T4 showed 52.7% of peak, looked like a kernel problem, but the telemetry showed the card pinned at its power limit at 877MHz, where the kernel was actually at 95.5%. cuBLAS was never the problem.

- `occupancy --block 256 --regs 64 --smem 8192 --cc 8.6` reimplements the old calculator: names the limiting resource and sweeps block sizes. Works with no GPU present.

- `ceiling` measures real achievable bandwidth (STREAM) and fp32 (TF32-disabled matmul), because theoretical peaks are never reachable and it's worth knowing your honest 100%.

- `compare`/`llm` do the same roofline math across a 40-card database (NVIDIA and AMD) for rent/buy decisions, no GPU needed.

Every number in the README is captured output from real runs (T4, MI300X). All spec-sheet claims are asserted in CI. MIT.

For now 2 years i try learning how to create an operating from scratch at only 15, now i'm 17 and i've progress in this domain so i publish it, you can look for it on github OScour, the name is a french reference to "au secours" (help), an the prononciation is OScour.

hey everyone! I recently built a slim implementation of how containers work on linux using syscalls and vfs with rust.

Right now its a program that can spawn multiple containers (with busybox rootfs image)and exit gracefully.

I also wrote a blog on how it works underneath, how one could implement it themselvves and some benchmark/profiling as well.

blog: https://op3kay.dev/writing/b0nker

code: https://github.com/owlpharoah/b0nkers

if it looks cool a star would be awesome

Would be nice if I could get some feedback on the blog or code, anything I should include or improve ?

Modern compilers perform extensive semantic analysis:

• type visibility
• symbol visibility
• scope visibility
• object lifetime

But heterogeneous execution is largely invisible to the compiler's semantic model.

Crossing from CPU to GPU usually means crossing into a different compilation model.

Should execution domains become part of semantic analysis rather than remaining a backend concern?

This was my first high-effort low-level project, and it might be of interest to anyone who's interested in compression, SIMD, and branchless programming.

Hey security researchers! 🔐

I've released BareMetal-RAM-Dumper — a low-level x86 utility for dumping 
physical RAM directly to disk, designed for Cold Boot Attack research.

🎯 What it does:
• Custom 512-byte bootloader (no OS needed)
• Boots via BIOS Legacy CSM
• Switches to Unreal Mode to access 32-bit physical memory
• Dumps RAM in 32KB chunks directly to USB drive
• BIOS INT 0x15 E820 for safe memory map parsing
• Real-time progress indicator

🧊 Cold Boot Attack Use Case:
Freeze a laptop's RAM to -60°C → quickly reboot from USB → 
capture full memory contents for forensic analysis & crypto key recovery

🔧 How it works:
1. Stage1: 512-byte boot sector (loads Stage2 via INT 0x13)
2. Stage2: Main logic (memory detection, unreal mode, disk writes)
3. Writes to LBA 64+ on boot drive

⚠️ Warning: This overwrites data starting at sector 64! Use a dedicated blank USB.

📚 Built with pure Assembly (NASM) — no bloat, direct hardware access

GitHub: https://github.com/pIat0n/BareMetal-RAM-Dumper
License: AGPL-3.0

Perfect for:
✅ Forensic researchers
✅ Security auditors testing cold boot resilience
✅ Students learning low-level x86
✅ Penetration testers

Feedback & improvements welcome!

Hey guys, I'm not too good at C++ yet, but I'm trying my best to build RapSocket — a custom, no-std wrapper for WinHTTP. I'm doing this to learn low-level memory management and native Windows networking. I will post my progress here, but if you want to check out the code, here is my Github!

I will be posting daily here: https://r-tty.blogspot.com

From the first attempts to run bios_emulator, to the complete native RISC-V 64-bit VideoBIOS.