DEV Community: RAKSHANEX TECHNOLOGIES

Hello World Is a Lie — Build a Real Program in RUDRA (Chapter 2)

RAKSHANEX TECHNOLOGIES — Thu, 08 Oct 2026 05:14:40 +0000

Hello world teaches you nothing. It has no state, no decisions, no loops, no bugs. It's a greeting card, not a program.

Chapter 2 is where RUDRA gets real. We build a Number Summarizer: feed it 1..n, it prints each number's even/odd status, totals them up, and classifies the sum. Small enough to fit in your head. Real enough to teach you everything.

The program

fn sum_to(n: int) -> int {
    let mut total = 0;
    for i in 1..(n + 1) {
        total = total + i;
    }
    return total;
}

fn is_even(x: int) -> bool {
    return x % 2 == 0;
}

fn main() {
    let n = 5;
    print("RUDRA number summary");
    for i in 1..(n + 1) {
        if is_even(i) {
            print("{i} is even");
        } else {
            print("{i} is odd");
        }
    }
    let s = sum_to(n);
    print("sum: {s}");
    if is_even(s) {
        print("the sum is even");
    } else {
        print("the sum is odd");
    }
}

The ideas that do all the work

let vs let mut — variables are immutable by default. Reassign a plain let and the compiler stops you with the exact line number. Mutability is opt-in, which means every mutation in your code is a deliberate decision.
Ranges end exclusive — 1..6 means 1 through 5. This WILL bite you exactly once; after that you'll never forget. The idiom for "1 through n" is 1..(n + 1).
The accumulator — total = total + i; inside the loop. (No += in RUDRA's book — the explicit form keeps beginners honest about what's happening.)
Functions with types — fn sum_to(n: int) -> int. Parameters and return types are written out. The compiler checks every call.

The honest workflow

There's no keyboard-input API in the book at this stage — so n lives in the source. Change it and re-run:

rudrac summary.rux --run

Edit → run → read output → repeat. n = 5, 10, 20… each run teaches you something.

The 3 bugs you will definitely write

Debugging method: problem → behavior → reason → fix → retest.

Off-by-one — you write 1..n and n silently vanishes from the sum. Runs fine. Wrong answer. The exclusive end strikes.
Missing mut — you reassign a plain let. Compiler error, exact line given. Add mut, move on.
= vs == — assignment inside a condition. Compiler error; conditions need comparison.

Every one of these has bitten a professional this month. You're in good company.

Refactor like you mean it

Repeated logic becomes a function (is_even, sum_to). Names say what they mean. One idea per function. And the rule that keeps you honest: refactor only with features you've already learned — no cleverness debt.

Proof it works

n	sum	parity
1	1	odd
5	15	odd
10	55	odd
20	210	even

Real runs, real numbers.

Keep going

🎥 Start the course — Chapter 1 video: https://www.youtube.com/watch?v=-adNF7Fi0Pg

📥 Download RUDRA (free): https://github.com/rakshanex/rudra

💬 WhatsApp channel: https://whatsapp.com/channel/0029Vb8hknnGE56kO24pbq47

Next chapters build on this foundation — the course follows the official book, chapter by chapter.

Question: which of the 3 bugs has bitten YOU most recently — off-by-one, missing mut, or = vs ==? Confess in the comments.

Piyush Kumar — Founder & Director, RAKSHANEX TECHNOLOGIES. Cybersecurity specialist (pentesting, red teaming, SOC, DFIR). Builder of RUDRA, OmniCore OS, AgentTrace. Author of "The RUDRA Programming Language" and four cybersecurity books.

Your First 60 Seconds With a Language That Compiles Itself — RUDRA Chapter 1

RAKSHANEX TECHNOLOGIES — Thu, 08 Oct 2026 05:14:00 +0000

Most systems languages make you earn your first "hello world."

Install the compiler. Install the linker. Configure the build system. Sacrifice something to the linker gods. Then — maybe — your program runs.

RUDRA skips all of that. Chapter 1 of the course is about one thing: going from zero to a running native binary as fast as humanly possible.

One archive. That's the whole toolchain.

Download RUDRA from https://github.com/rakshanex/rudra and you get four small tools:

Tool	Job
`rudra`	Everyday driver: `new`, `run`, `build`, `fmt`, `test`
`rudrac`	The compiler: one `.rux` file → native binary
`ruxpkg`	Package manager
`rudra-lsp`	Language server (VS Code extension: `rakshanex.rudra`)

No GCC. No Clang. No assembler. No linker. RUDRA emits x86-64 machine code and writes the executable itself.

Your first program

hello.rux:

fn main() {
    print("Hello, RUDRA!");
}

rudrac hello.rux --run
# ✅ Compiled: build/hello
# Hello, RUDRA!

Three lines. One command. A real native binary — a few kilobytes, starts in about a millisecond.

The project workflow you'll use forever

rudra new myapp && cd myapp
rudra run     # compile + run
rudra build   # native binary
rudra fmt     # format code
rudra test    # run test_* functions

Every project is just a Rux.toml manifest plus src/main.rux. No build scripts, no 400-line config files.

What happens between source and binary

RUDRA's compilation pipeline has 8 stages: lex → parse → resolve imports → type-check → monomorphize generics → emit x86-64 → native ELF executable. You don't need to memorize them — but knowing your language doesn't hide a C compiler under the hood changes how you think about it.

One more trick before you go

print("2 + 2 = {2 + 2}");   // 2 + 2 = 4

String interpolation with {...} — any expression, evaluated inline. You'll use this constantly.

Keep going

🎥 Watch Chapter 1 (full video lesson): https://www.youtube.com/watch?v=-adNF7Fi0Pg

📥 Download RUDRA (free): https://github.com/rakshanex/rudra

💬 WhatsApp channel: https://whatsapp.com/channel/0029Vb8hknnGE56kO24pbq47

Next: Chapter 2 — we build a real Number Summarizer with loops, mutable state, and functions. And we debug it like professionals.

Question: what's the most painful install experience you've ever had with a programming language? Tell me in the comments — I need to feel better about my 2 AM linker story.

I Built My Own Programming Language Because I Was Tired of Fighting C Compilers

RAKSHANEX TECHNOLOGIES — Thu, 08 Oct 2026 05:10:23 +0000

Every programmer has a breaking point.

Mine came at 2 AM, staring at a linker error that had nothing to do with my code. Three hours of "programming" — zero lines written. Just me versus the toolchain. Again.

That night I asked a stupid question: what if the language just... compiled itself? No GCC. No LLVM. No assembler. No linker. One download, one binary, done.

Two years later, that stupid question has a name: RUDRA.

I built it. It works. Here's the proof.

fn main() {
    print("Hello, RUDRA!");
}

rudrac hello.rux --run
# ✅ Compiled: build/hello
# Hello, RUDRA!

That's it. One command. A few kilobytes of native executable. Starts in about a millisecond.

Why another language?

Fair question. The world doesn't need another toy language.

RUDRA isn't a toy — it's a bet. A bet that you don't have to choose between speed, safety, and simplicity:

Memory-safe by default: statically typed, no null, bounds-checked access, immutable by default. Use-after-free? Caught at compile time.
Actually powerful: generics, traits, closures, sum types with exhaustive pattern matching. A real standard library — files, networking, threads, JSON, HTTP.
Simple enough to learn in a weekend: clean Rust-and-Go-flavored syntax. Readable by humans — and by AI.

The decision nobody else made

Here's the part that makes compiler people do a double-take: RUDRA has its own native backend. It emits x86-64 machine code and writes the ELF binary itself.

Most new languages cheat at this step — they lean on LLVM (gigabytes of dependency) or shell out to GCC. RUDRA does neither. The whole toolchain is four small tools:

Tool	Job
`rudra`	Project driver: new, run, build, fmt, test
`rudrac`	The compiler: one .rux file → native binary
`ruxpkg`	Package manager
`rudra-lsp`	Language server (VS Code extension in the marketplace)

The honest part

RUDRA is v1.1.0. Let me tell you what it can't do yet: DNS/hostname resolution and HTTPS/TLS are still on the roadmap. The compiler source is proprietary; the toolchain binaries are free to use.

I'm not claiming it replaces Rust. I'm claiming something better: building it taught me more about compilers, type systems, and language design than a decade of using other people's languages.

Learn it with me — free

I'm teaching all of it on YouTube, chapter by chapter, straight from the official book "The RUDRA Programming Language":

🎥 Chapter 1 — Introduction, Installation & Your First Program: https://www.youtube.com/watch?v=-adNF7Fi0Pg

📥 Download RUDRA (free): https://github.com/rakshanex/rudra

💬 WhatsApp channel: https://whatsapp.com/channel/0029Vb8hknnGE56kO24pbq47

Chapter 2 is next — we build a real Number Summarizer app: loops, mutable state, functions, debugging.

One question for you

What's the first program you'd write in a brand-new systems language?

Drop it in the comments — the best answer might become a chapter in the course.

Piyush Kumar — Founder & Director, RAKSHANEX TECHNOLOGIES. Cybersecurity specialist (pentesting, red teaming, SOC, DFIR). Builder of RUDRA, OmniCore OS, AgentTrace. Author of "The RUDRA Programming Language" and four cybersecurity books.

🇮🇳 Building OmniCore OS: From an Idea to a Working Development Build:

RAKSHANEX TECHNOLOGIES — Sun, 06 Sep 2026 06:44:57 +0000

🇮🇳 Building OmniCore OS: From an Idea to a Working Development Build

A few days ago, I shared the vision behind OmniCore OS.

Today, I want to share the next step in that journey.

The idea is no longer just a concept.

OmniCore OS is now booting as a working development build.

Getting an operating system to boot is only one milestone. The bigger challenge is building a platform where security, integrity, verification, and resilience are considered from the foundation up.

Why OmniCore OS?

Modern computing infrastructure depends on software that organizations need to trust, verify, and control.

Security should not simply be something added after a system has been built.

It should influence the architecture, build process, system configuration, update mechanism, and operational model from the beginning.

That is the direction we're exploring with OmniCore OS.

🛡️ Current Development Build

The current development stage includes:

Custom boot environment
Custom system identity and branding
Desktop environment
Installation environment
Security-focused system architecture
Build and deployment pipeline
System testing and validation
Foundation for future security and forensic capabilities

But the real challenge isn't simply making an OS boot.

The real challenge is building a system that can be trusted.

🔐 The Questions That Matter

Can the system be verified?

Can changes to critical components be detected?

Can updates be securely delivered?

Can the software supply chain be monitored?

What happens if the system is compromised?

Can useful forensic evidence be preserved?

These are the questions driving the engineering process.

BUILD → HARDEN → TEST → BREAK → FIX → VALIDATE

The objective is not to claim that the current build is already secure.

It isn't.

This is an early development build, and many components still need to be implemented, tested, and independently evaluated.

The goal is to continuously identify weaknesses and improve the architecture.

🚀 What Comes Next?

We are currently evaluating the next capabilities to implement, including:

System hardening
Integrity verification
Secure update mechanisms
Software supply-chain security
Security monitoring
Digital-forensics readiness
Offline and isolated deployment
Reproducible and auditable builds
Security-focused system tooling

The architecture will continue to evolve as development and testing progress.

🇮🇳 Building Toward Sovereign Computing

For me, sovereign computing means more than putting an Indian name on a product.

It means developing the capability to understand, control, secure, and continuously improve the technology stack.

Architecture.

Build systems.

Software supply chain.

Security controls.

Verification.

Deployment.

That is the broader direction behind OmniCore OS.

This Is Only the Beginning

The current ISO is a development build, not a final product or production release.

There is still a significant amount of engineering, testing, and validation ahead.

But seeing an idea move through:

Idea → Architecture → Build → Boot → Test → Improve

is an important milestone.

And now the real work begins.

🇮🇳 OMNICORE OS

Secure. Sovereign. Advanced.

Built by RAKSHANEX TECHNOLOGIES

Build the foundation.

Harden the system.

Break it.

Fix it.

Verify it.

I'd genuinely like to hear from developers, security researchers, OS engineers, DFIR professionals, and systems engineers:

What capabilities would you consider essential for a security-focused operating system at the foundation level?

When Your AI Agent Gets Breached, Can You Prove What It Did?

RAKSHANEX TECHNOLOGIES — Tue, 01 Sep 2026 20:36:58 +0000

Introducing AgentTrace — an open-source, offline forensic tool for reconstructing AI-agent security incidents.

AI agents are no longer demos. LLMs wired to tools, memory, retrieval, and other agents are running in production — reading data, calling APIs, moving money, touching customer records. And like everything else that touches production, they get caught up in security incidents.

But investigating an AI-agent incident is not like traditional digital forensics. I kept running into the same wall, so I built a tool for it.

Why AI-agent forensics is genuinely different

Three things break the usual DFIR playbook.

1. The attack vector is natural language. When an attacker plants a malicious instruction in a document an agent will retrieve, that instruction looks identical to a legitimate query in every log most teams collect. There is no binary payload, no CVE signature, no network packet that lights up. The exploit is a sentence.

2. The anomaly is the sequence, not any single event. Every individual tool call the agent makes is authorized and looks normal. "Read a file." "Call an API." "Make an HTTP request." Nothing is wrong on its own. The attack is the order — retrieve poisoned content, then access a secret, then send data out. You cannot see it unless you have the whole chain.

3. The evidence is scattered and short-lived. The pieces live in six or seven different systems: LLM invocation logs, tool execution traces, MCP server logs, vector-store retrieval logs, OAuth records, egress logs. Different teams own each one. Different retention windows delete each one. One documented 2026 incident produced roughly 17,600 agent actions in five days; the team's own postmortem called reconstructing it by hand "impractical."

The key insight: the industry has mostly solved recording agent activity (OpenTelemetry's GenAI conventions, MCP logging, tamper-evident audit logs). What nobody had was an automated way to reconstruct what actually happened from that recorded evidence. That gap is what AgentTrace fills.

What AgentTrace does

AgentTrace is the investigation layer that sits downstream of the recorders. Point it at your evidence, and it:

Ingests 7 evidence sources into one normalized schema.
Verifies integrity + chain of custody — hash-chain verification, gap and witness-anchor detection, HMAC-signed manifests, and a tamper-evident custody ledger.
Reconstructs the causal attack chain across fragmented logs (timeline + provenance-style causal graph).
Detects 6 attack patterns, each mapped to a MITRE ATLAS technique and linked to the exact evidence: prompt injection via retrieval, exfiltration via tool chaining, OAuth/credential-theft chains, sub-agent hijack, memory poisoning, tool-permission escalation.
Builds kill-chain narratives and a 0–100 risk score.
Produces reports in JSON, Markdown, and self-contained offline HTML (with an SVG causal graph), including an EU AI Act Article 12 coverage section.
Exports portable, signed case bundles for air-gapped transfer.

Two design choices I won't compromise on

No AI/ML in the detection path. Every finding is deterministic and traces back to concrete evidence. A forensic tool has to be explainable — a model that says "I think this is an attack" does not survive a review, an audit, or a courtroom.

Local-first, zero dependencies. It runs fully offline on the Python standard library alone. No cloud, no account, no API key.

What it looks like in practice

pip install agentdfir

# What happened? Any known attack patterns?
agenttrace detect logs/*.json logs/*.jsonl

# Is the evidence trustworthy — altered or missing?
agenttrace verify logs/*.jsonl --signing-key "case-key" \
  --case-number "IR-2026-0042" --case-officer "A. Analyst"

# Produce a report for management / legal / a regulator
agenttrace report logs/*.json logs/*.jsonl --html-out report.html

On a synthetic multi-source incident, detect surfaces things like:

[CRITICAL] exfiltration_via_tool_chaining — 25 calls to 'crm_export' in 48s,
           monotonically increasing offsets  (MITRE ATLAS AML.T0057)
[CRITICAL] oauth_credential_theft_chain    — credential access -> rapid egress
[HIGH]     prompt_injection_via_retrieval  — poisoned chunk -> new sensitive tool

Each finding links to the exact events behind it, and the HTML report renders the whole story as a causal graph: poisoned document entered context → agent behavior shifted → credentials accessed → data left the building.

Chain of custody, everywhere

Forensic output is only useful if it holds up. Every stage — acquisition, verification, analysis, reporting, export, transfer — is written to a tamper-evident, hash-chained ledger attributed to a case officer, with tool version and timestamps. Reports and manifests are cryptographically bound to the exact evidence they were built from.

Try it / contribute

PyPI: pip install agentdfir
Repo: https://github.com/piyush295/agenttrace
Apache-2.0, offline, dependency-free.

I'd genuinely value feedback from anyone doing incident response on agentic systems — especially on the detection heuristics and which additional evidence sources are worth supporting next.

Authorized, defensive use only. AgentTrace analyzes evidence you are authorized to investigate; it is not an attack or surveillance tool.