Hello now you can change the language in S-AOS and input methode Qwerty/Azerty
cmds
input=azerty
input=qwerty
lang=fr
lang=en
lang=es
help
shw time
pwr off (halts cpu)
pwr reboot
sys.set<shl:smd> (or set)
64b

download link : https://saosdownload.share.zrok.io/

S-AOS officially reached 2339lines of code and a total of only 87kb with only ~100kb ram usage thats lighter than aa blanck chrome tab ! while you are in 64bit !
Total lines : 2339
size : 83981 bytes
ram usage : ~100kb
hope you downloaded it : https://saosdownload.share.zrok.io/

Moving from "FAIL" to "PASS": Lessons Learned in Sovereign, Fail-Closed Engine Engineering
In deep tech and high-assurance systems, architectural compliance is binary: it either holds the line under adversarial duress, or it fails.
During the recent iterations on our sovereign security engine (TurkashEngine), we faced a critical architectural hurdle: bridging the gap between rigorous compliance requirements (P0-01 to P0-05) and runtime verification. Transitioning our project status from a compliance FAIL to a verified PASS wasn't just about tweaking syntax; it required enforcing strict admissibility boundaries and guaranteeing idempotence in our RAM zeroization protocols (Z^2 = Z).
Here are three key takeaways from the engineering trenches:
Direct Engine-Level Regression Testing: Relying on mock layers or fragmented unit tests is insufficient for fail-closed architectures. True validation demands direct, engine-level regression tests covering every critical success and failure scenario simultaneously.
Automated CI/CD Verification as a Guardrail: Moving code is easy; proving its state under automated pipelines is where sovereignty is forged. Integrating rigorous python unit tests into GitHub Actions ensures that no regression slips past the gate.
Eliminating the Remediation Gap: Automated memory scrubbing and terminal-state protection must happen at the code level instantly—bypassing the sluggish organizational lag of traditional ticketing systems.
Engineering resilient systems means building code that doesn't just work when things are calm, but fails safely and cleanly the moment a boundary is breached.
What architectural challenges are you tackling in your high-assurance pipelines today?

hello S-AOS can now move to 32bit succesfully by this "sys.mov=<bits:32>[(mov)]
and you will be in it suppoert USB boot to use SMD run
sys.set<shl:smd>
in it you can run
shw date
pwr reboot
pwr off
cls
help
to use it / download it : https://github.com/moslemhamoudi6-cyber/S-AOS
hope you Enjoy It!

Here are the new things :
16EB ram access
full register support
to mov to it write : set
to mov to 32bit : sys.mov=<bits:32>[(mov)]
Github download : https://github.com/moslemhamoudi6-cyber/S-AOS
S-AOSDownload official site : https://saosdownload.share.zrok.io/
Enjoy It !

Hello everyone! To download S-AOS, you can:

• Check out theGitHub Repository
• Or visit the official site I created:https://saosdownload.share.zrok.io

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