Just finished this one: an 8-bit CPU built entirely from NAND gates in Digital Logic Sim. 800 kHz, 16-bit addressing with 64K of RAM, and a small OS running four games playable live with the keyboard.

Writing programs in binary by hand got painful fast, so I also wrote my own language and a compiler that outputs the program memory contents directly.

Short video (1:30): https://youtu.be/O8znJoZkAmw

Happy to go into the architecture if anyone’s interested.

Hey all, a few months ago I got curious and wrote an S3 client in Rust. To my own surprise it ended up faster than mc, s5cmd and aws-cli at uploading to the self-hosted backends I tested (MinIO, SeaweedFS and Garage), and about level with mc on downloads. I have written a technical blog here, I am still a newbie when it comes to this stuff so bear with me: https://jaeaeich.com/writing/s3z. Please read or listen to it, the benchmarks were only run locally, so I'm sure there's plenty to poke at, and I'd really value hearing what I got wrong or could have done better.

Hi r/Operatingsystems,

I’ve been working on Veda, a very early-stage experimental operating system built from scratch in Rust.

The main idea I’m exploring is an agentic-native OS architecture. Instead of AI Agents interacting with applications primarily through screenshots, simulated mouse movement, and clicks, I want applications and AI Agents to have a native way to communicate through the operating system itself.

Some of the architectural directions so far:

• Agentic-Native Architecture
• Native App-to-AI Agent Communication
• Microkernel Design
• Capability-Based Security
• Memory-Safe Foundation in Rust

The screenshot shows the current desktop environment and an early AI Agent interface.

This is still very early development. There are plenty of rough edges, unfinished components, architectural decisions that may change, and a lot I still need to learn. I’m definitely not presenting this as a finished or production-ready OS.

I’m sharing it here because I’d really appreciate technical feedback, criticism, ideas, and especially collaboration from people interested in OS development. Contributions are very welcome.

GitHub: https://github.com/vahmoh25/Veda

I’d be particularly interested in hearing thoughts from people who have worked on microkernels, capability systems, or Rust OS development.

The project is licensed under GPLv3. I’d love to build a strong contribution community around Veda with people who see potential in the idea and want to help shape it early.

If you’re interested in experimenting, contributing, reviewing architecture, or simply following the project as it evolves, I’d be very happy to have you involved.

Been working on dtask, a terminal task manager I originally wrote in C. Spent a little over a week porting it to D.

There is a self terminal input and rendering, including mouse controls, drag and drop, and handling Unicode without messing up the layout. Everything is saved locally, and it’s tested on Linux, macOS and FreeBSD (Unix systems support).

github.com/GuestAUser/dtask

Hey everyone!

I’ve been experimenting with low-level software rendering inside standard Linux terminals. I wanted to see how fast I could march 3D Signed Distance Fields (SDF) and render dynamic, illuminated 3D geometry without using any heavy frameworks, Python wrappers, or C/C++ source files in the project.

The engine renders an animated 3D LEGO® Minifigure (walking animation, waving arm, facial details, space emblem) and a Space Rover on a studded baseplate at 160x48 resolution @ ~70 FPS with 24-bit ANSI TrueColor, PBR clearcoat gloss, soft shadows, ambient occlusion, and interactive WSAD camera flight.

After getting it running smoothly, I decided to see how far I could push the footprint optimization without losing a single frame or feature.

📏 File Footprint Breakdown (200 KB →→ 11 KB Total)

Here is how the project breaks down before and after stripping/compression:

textSOURCE CODE (DSL):
  • scene_lego.hray        : 2.4 KB  -->  0.9 KB (Minified DSL scene description)
  • hray_compiler.hydra    : 2.7 KB  -->  1.1 KB (VLIW-8 Hardware Microcode)
  • hray_compiler.hmat3d   : 2.8 KB  -->  1.0 KB (3D Spatial Matrix Definitions)
  --------------------------------------------------------------------------
  Total Source Code Size   : 9.2 KB  -->  ~3.0 KB (Full 3D Scene + Microcode)
COMPILED NATIVE BINARY:
  • Raw Executable Binary  : 27 KB   --> 14 KB (Stripped debug symbols)
  • UPX Compressed Binary  : 14 KB   --> ~7 KB (Self-extracting ELF executable)
COMPLETE REPOSITORY FOOTPRINT:
  • Initial workspace size : ~200 KB (including benchmark builds)
  • Minified total size    : ~11 KB  (Over 94% total footprint reduction!)

🛠️ Key Technical Highlights:

1. Custom Vector Language (DSL): Everything is defined in .hray (geometry/materials), .hydra (instruction stream), and .hmat3d (spatial transformations).
2. SIMD Alignment: Ray packets execute in 8-lane AVX2/FMA3 SIMD vector passes directly on CPU registers.
3. Artifact-Free Precision: Fixed surface penetration gradient collapse (black spots) by enforcing 1.0x conservative stepping precision and camera-vector fallback normals.
4. Zero Overhead: Launches instantly from terminal via a 1.5 KB shell script.

The entire project — source code, microcode, shaders, materials, and executable binary — fits into ~11 KB, which could easily fit on a vintage 5.25" floppy disk with 99% of space to spare.

Happy to answer any questions about the SDF mathematics, SIMD vector alignment, or terminal framebuffer commit optimizations!

Subreddits & Tags

#programming #graphicssoftware #gamedev #CommandLine #linux #LowLevel #SIMD #AVX2 #Raymarching #Lego

How do you reduce recursive directory traversal and file content search across 250,000 files from 410 ms down to 180 ms on a 15W mobile Intel Core i5 processor?

While optimizing high-density filesystem search workflows (Directory Traversal + Content Search), I benchmarked standard POSIX pipelines and modern SIMD CLI utilities against native C engines built directly on low-level Linux primitives:

• hfind – A directory traversal engine built directly on the Linux SYS_getdents64 system call, featuring a page-aligned 32 KB kernel buffer and lock-free parallel recursion using OpenMP tasking.

• hgrep – A memory-mapped scanning engine leveraging 256-bit AVX2 SIMD vectorization, zero-copy mmap (MADV_SEQUENTIAL | MADV_HUGEPAGE), and 4-way unrolled vector loops.

• hsearch – An integrated pipeline combining VFS node filtering and SIMD content scanning in a single pass.

(See benchmark screenshot attached)

🔍 Key Architectural Factors Behind the Speedup:

• Bypassing POSIX libc Allocation Overhead:

Standard opendir() and readdir() abstractions allocate heap memory structures per directory stream. Issuing raw syscall(SYS_getdents64, ...) fetches raw directory record streams directly into L1/L2 cache buffers, eliminating allocator overhead across deeply nested folder hierarchies.

• Vectorized Non-Matching Block Elimination (_mm256_cmpeq_epi8):

Rather than scanning byte-by-byte, 256-bit AVX2 registers process 32 bytes per clock cycle. Bitwise masking evaluates and discards 128-byte chunks of non-matching data in a single operation, bypassing scalar branch loops entirely.

• L1/L2 Cache Locality & Hardware Prefetching:

On power-constrained hardware (Intel Broadwell 15W TDP), memory bus latency is the main bottleneck. Coupling hardware prefetch hints (_MM_HINT_T0) with MADV_WILLNEED page advice keeps the memory bus saturated at maximum bandwidth.

⚙️ Engineering Takeaway:

When handling high-density I/O operations over hundreds of thousands of small objects, bypassing standard runtime abstractions in favor of direct kernel system calls and vector primitives yields a >2x execution speedup on existing hardware without hardware upgrades.

What has been your experience bypassing standard C runtime abstractions for direct kernel system calls in performance-critical paths?

#Linux #SystemProgramming #C #Performance #AVX2 #Optimization #OperatingSystems #Developers