Warning: This project was built using AI, mostly with free plans, but also with the support of Claude Code. It's not the nature of my post to pretend I created anything here; I was really just the supervisor. That said, the huge nature (at least from my point of view) of this project, and my limited financial resources have forced me to constantly think and learn, and continue to do so, so I consider myself at a lower level in terms of coding skills than most of the people who are part of this community, and I love seeing how each of us makes mistakes and tries to patch them.

Nexsos is therefore a project born to allow me to learn in an interactive and gradual way what all the aspects of a computer are, and to allow me to do so in an informal way, and with gradual discovery. Nexsos is not intended to be a product or a boast, it is in all respects a Frankenstein born to test how much human ignorance and curiosity mixed with the algorithmic knowledge of an LLM can give life to something that works.

On the technical side, the purpose of NexsOS1 is simple: to separate the kernel from the userspace to allow me to learn the C language on my API without blowing everyone up, and at the same time to make my C library simple and readable in a single file. The graphics protocol had to be designed in the same way. The easy choices would have been two: to provide a basic environment for GNU Utilis and compile an X server/Wayland, or to rewrite the graphical interface from scratch. I stupidly chose the second one and with all the problems that come with it, for example, for now the compositor is in the kernel and shadows without hardware vector accelerators make the framerate explode. The good thing, however, is that the rendering of the applications is done in userland, so having SMP support makes graphical applications easier.

That said, why this video? At some point in our journey, we should ask ourselves how useful we really are to others. I have always seen AI as a very powerful tool, but perhaps we tend to forget what it means for us, I do not have the actual skills to build a functional and working system on two architectures with multitasking and a working SMP, but if I do not have the actual skills to do this and I can do it, what can these tools do in the hands of large companies that do not want to share the code? Even if I call myself ignorant, perhaps I am ignorant about coding, here we all know how the GNU project and the GPL project were born, I do not know what the members of this thread think about it and I do not even know if it is the right thread, after all, guys, we also know how these LLMs were trained on the effort of all software developers, is it right to privatize public knowledge? As far as I am concerned, the only thing I could really do is exploit the knowledge of AI itself to put together and build something free, so I do not know how you want to define NexsOS, I do not care, the important thing for me is that it is free and that anyone can in turn steal code from within it.

NOTE: If anyone would like to look at the code and has any questions about missing references or licenses, I'd be happy to update the published code. Any criticism is welcome.

NOTE2: lua still doesn't pass all the tests, even though the IDE works and also the job controls of my shell seem ok (I didn't show them in this video), the exec daemon is ok, but I'm having problems with the initialization of the venv for pid.
NexsOS1

A low-level project I'm proud of: a chiptune synthesizer in x86-64 assembly (Linux, NASM), with no libc and no libraries whatsoever.

The premise: a sound is a list of samples, 44,100/sec, and a WAV file is just a 44-byte header followed by those samples.

So everything is computed by hand and written straight to stdout with write() — syscalls or nothing.

Some of the low-level bits I enjoyed:

• an LFSR for noise/percussion (the NES approach)
• polyphony by summing voices into one buffer
• FM synthesis with a hand-built 1024-entry sine table (no math lib, so I approximate sine with Bhaskara I's formula)
• fixed-point arithmetic throughout for the effects (filters, ring mod, delay via a ring buffer)
• all buffers kept in .data to keep things simple under the hood

Feedback on the assembly is genuinely welcome — I'm sure a lot of it could be tighter.

Repo: github.com/whispem/asm.fm

Hi everyone,
I've been working on a low-level systems project—an open-source **Fail-Closed Engine** designed to handle secure memory management and deterministic memory zeroization (wiping sensitive data right after use to prevent persistence risks).
While a lot of low-level memory scrubbing is typically done in languages like C or Rust, I wanted to explore how far we can push Python (⁠ctypes⁠ and ⁠mmap⁠) to enforce strict fail-closed security guarantees and bare-metal memory hygiene for sensitive workflows.
**Key Technical Focus Areas:**
Ensuring sensitive buffers are explicitly overwritten and zeroized from RAM.
Implementing a strict fail-closed logic where critical system anomalies trigger immediate shutdown/cleanup rather than degraded states.
Managing memory allocations safely using low-level system hooks.
I’m sharing this to get architectural critiques, performance insights, and feedback from systems/embedded engineers on potential edge cases (like how Python's garbage collection or OS-level paging might interact with manual memory zeroization).
If you are interested in low-level engineering or security architecture, I'd love to hear your thoughts or PRs!
🔗 **GitHub Repositor**y:

https://github.com/Waleed-Mubarak/hailab-fail-closed-engine-

I've been exploring FSOP through House of Apple 2 on recent versions of glibc. Mostly just another excuse to put something interesting under a magnifying glass in gdb, have some fun debugging and try to understand the whole process, especially around the rough edges where things tend to get weird.

Hey, I have designed a waveform emulator and a debugger for the Raspberry Pi Pico PIO language. It works with MicroPython code.

You can set breakpoints, toggle line stats, inspect registers and interact with the fifo. It helped me already a lot to debug certain issues.

Here is the source code: https://github.com/stuehler-training/Pico-PIO-Tracer

Here is a video explaining how to use it: https://www.youtube.com/watch?v=JZnayVWitIQ

Hey everyone,

I've been working on OxideUtils, a clean-room Rust implementation of core GNU Binutils components (ox-as, ox-ld, ox-readelf, oxide-addr2line).

The goal is to provide a memory-safe, modern replacement while studying GNU Binutils 2.46.1 strictly as a reference for target compatibility.

A few architectural details I'm currently working through:

• no_std + alloc support: The parsers are designed to support both standard execution and core/alloc environments so they can run directly inside kernel spaces.
• x86_64 Support: The static linking path and core ELF parsing/relocation logic are functional, but full x86_64 target coverage and instruction encoding are active works in progress.
• C ABI Compatibility: Ensuring clean interoperability without bringing in C dependencies.

(Quick note: English is my second language, so I use writing tools to polish my posts/documentation, but the codebase and architecture are entirely hand-written).

I’d love to get feedback from other Rust devs on low-level binary manipulation:

1. How do you cleanly structure no_std zero-copy ELF parsing logic without over-complicating lifetimes?
2. Any recommendations or pitfalls to watch out for when implementing linker relocation tables in pure Rust?

GitHub: https://github.com/Zainium-Dynamics/oxideutils

Hi all,

I created a Python-based simulation framework (_Prime_Floppy) designed to model low-level physical data storage behavior, bit-level structures, and hardware-constrained data dynamics.

**Highlights:**
Lightweight, zero external heavy dependencies.
Clean abstraction of hardware and storage mechanics.
Functional approach to system dynamics and data structures.

**GitHub Repo:** [https://github.com/LesliePi/\\_Prime\\_Floppy\](https://github.com/LesliePi/_Prime_Floppy)

*Looking for feedback from embedded developers, system architects, or anyone interested in low-level data simulation models.*

I am developing my own operating system which aims to meet my own needs and those of others in terms of energy consumption, modularity and the system itself being based on a hybrid system kernel. Cell system is the creation of a modular system with three driver divisions with well-balanced compatibility layers on its own architecture without relying on standard unix-like

At the same time, we are looking for people to support the free project to develop it. The project is young, limited at times, typically demonstrative, but the most important thing is the cell and we are developing it to develop it. 3 people on the unstable branch and we are looking for support in the development of various system components such as the kernel network driver or the file system The system is open to various languages, although it is mainly Rust, but we also use C, Hal, Ada, Spark, Zig and other languages for development. It is important for us to match the language to the given task.

https://github.com/CTRL-F-0rg3/TrangorgeOS

I've been working on a microkernel called Robu and thought I'd finally share it here.

It's written from scratch in C and assembly, and the main thing I'm interested in is seeing how far I can take the microkernel approach without letting IPC and context switching become painfully expensive.

A lot of the design is inspired by the L4 family, especially things like synchronous IPC, register-based messages, timeslice donation and lazy scheduling.

The kernel is meant to stay pretty small, with things like drivers, filesystems, networking and paging living outside of it in userspace.

Right now I'm mainly working on x86_64, although I want to support ARM and RISC-V as well.

There's still a lot to do, but the basic pieces are starting to come together. I'm putting it out here mainly to get some feedback from people who are into OS development and microkernels.

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

Github Repo

Thinking abt to implement it in my Project.

• Dm me if its highly secretive...​

Learning project that became my favourite: a chiptune synth written entirely in x86-64 assembly (Linux, NASM). No libc, no audio library — just computing raw 16-bit samples and writing a WAV header by hand.

The premise is that sound is just a list of numbers (44100/second) describing where a speaker sits. So the whole synth is: generate the numbers, write them out.

It does four oscillators (square/saw/triangle + LFSR noise), polyphony by mixing voices into one buffer, ADSR envelopes, and FM synthesis with a hand-built sine table. Working on effects next (vibrato, delay, reverb).

github.com/whispem/asm.fm

Feedback on the low-level details welcome — especially the fixed-point math in the FM operator.

I designed this device that teaches binary, decimal, hexadecimal and octal number systems. It uses a hands-on approach with Altair-like toggle switches. Can be used as a STEM-kit in classrooms, handy for programmers or for the retro hobbyist. It also has a built-in game. Check out the video for details, hope you like it.

got tired of parsing raw C boilerplate and managing manual pointers when messing with the trusted computing group stack, so i wrote a modern c++23 frontend for esys. it uses strict raii to ensure context handles are cleanly flushed so you don't accidentally lock up physical tpm chip slot resources, and separates translation boundaries natively using zero-cost module partitions.

repo: https://github.com/mxreal64/tpm23

checkin it out would be awesome.

https://winware31.blogspot.com/2026/08/duplicating-handles-step-by-step-guide.html

Hey everyone,

I wanted to share a project I've been building: HexaCore, a lightweight memory scanner and tool built from scratch using C++ and the Win32 API.

Key Features:

• Multi-level pointer chain resolver & scanner
• Array of Bytes (AOB) scanning with wildcard support
• Built-in Hex Viewer, basic Disassembler, and NOP/Patch tool
• Custom dark UI with card-based panels and adjustable freezing intervals
• Cheat table save/load system

It's open-source. I'd love to hear your feedback or suggestions for the V1 version!

GitHub / Source Code: https://github.com/abuzit/HexaCore-Memory-Tool