DEV Community: Bartosz Osiej

Building a Solana-like validator in Rust: what PoH, Tower BFT and Sealevel actually force you to think about

Bartosz Osiej — Tue, 15 Sep 2026 15:52:48 +0000

TL;DR

TrustNode is a from-scratch Solana-style cluster in Rust: a verified Proof-of-History clock, Tower BFT-style consensus, a Sealevel-like parallel execution engine, gossip, and erasure-coded block recovery. The point was never to clone Solana — it's that these three subsystems force concrete, painful design decisions that generic "blockchain in Rust" tutorials skip. This is what they actually force.

The PoH clock is a scheduling problem, not a hash chain

The naive description — "hash a counter, publish a chain of hashes" — is one line. The real problem is that the clock sources events (TickHeight, sequential slot heights) and the validators re-derive them locally to trust the chain. When it breaks, it breaks as ordering: two validators disagree on which tick a transaction belonged to, and the whole ledger forks at that point.

What actually mattered in the implementation:

Batching ticks, not hashing every transaction. Hash a counter on each tick, but let a batch of entries commute into one tick. Constant re-hashing per-transaction kills throughput and makes the clock the bottleneck.
The clock must be derivable from the ledger. If "slot N belongs to slot N" isn't an independent statement any node can recompute from the block alone, you've built a chain that needs a trusted signer — the exact thing you were trying to cryptographically remove.
Verifier side must match generator side bit-for-bit. Off-by-one in the tick batching turns up as a consensus failure weeks later, not a compile error.

Lesson: in a PoH system the clock is the consensus substrate. Get the pure function right first; consensus is downstream of it.

Tower BFT is a voting game at fixed heights

Tower BFT simplifies PBFT by anchoring votes to the PoH slot height. The trick (and the trap) is that votes happen at heights, and each validator commits to "I have not voted against this fork above slot X for Y slots." The consequence that's easy to miss until you implement it:

Vote lifetime is a number you have to choose. How many slots does a lock hold? Too short and liveness collapses (validators flip-flop, the fork battle never ends); too long and the network can be bricked.
Commit vs. finalize are different states. Reaching "commit" as a local statement is easy; broadcasting finalization so other nodes can rely on it is where cloudblocks appear.
The lock mechanism is per-validator bookkeeping. Track highest lock height, refuse to vote below it, and explain that in tests — because half the bugs turn out to be "validator voted against its own lock."

Lesson: BFT flavors differ in where they put the voting rules, not in whether they have them. Implementing one in your own repo makes the whitepaper read like a checklist instead of a mystery.

Sealevel parallelism lives or dies on account locks

Parallel execution is the marketing line; the implementation is "which accounts does this instruction touch, and can I prove they don't overlap." The real work is:

Static account-readset/writeset extraction. Every instruction declares accounts before execution. If it doesn't, you can't schedule safely — so the API forces it.
Overlap detection decides throughput. Two programs touching disjoint accounts run in parallel; any overlap serializes. Most of the performance cliff lives in a naive overlap check (collision on account keys, not program IDs).
The price of conflict is determinism. Any scheduler that reorders conflicting instructions must be reproducible across all validators, or the same block executes differently on different machines.

Lesson: "parallel VM" is 20% scheduling and 80% proving it's deterministic while parallel.

What I'd build differently

Real transaction processing over RPC is the current frontier in the repo (commits land almost daily). The honest retro:

Boot the consensus before the clock. I built PoH first because it looks like the foundation. In hindsight the vote/lock rules are the design core; the clock is just the substrate they sit on.
Fuzz the ledger reconstruction. Erasure-coded recovery looks simple until a node survives with 2-of-4 shards and has to rebuild without trusting what it already has.
Determinism tests on the scheduler early. Portable scheduling is the difference between a demo and a network.

Repo

TrustNode — PoH clock, Tower BFT, Sealevel-style execution, gossip + erasure coding, real transaction processing over RPC (Rust, MIT).

eBPF verifier limits are a design constraint: what CO-RE field offsets and bounded loops taught me

Bartosz Osiej — Tue, 15 Sep 2026 15:52:16 +0000

TL;DR

Working on talus-process-monitor (Rust userspace + libbpf/C eBPF) I kept bumping into the same three walls: CO-RE field offsets shifting between kernel versions, the verifier refusing anything that looks like an unbounded loop, and map access patterns that get rejected at load time. All three are design constraints, not compiler annoyances. This post is what changed in my approach once I stopped fighting them.

CO-RE relocation is a promise you have to verify

Portable BPF (Compile Once - Run Everywhere) means the kernel rewrites your field accesses based on its own BTF. In theory: compile once, run on kernel 6.x. In practice I chased two classes of bugs:

struct file layout differences — an offset that's valid on kernel A and wrong on kernel B. The relocation did its job; I had assumed a field meant what it meant.
Unavailable BTF — if the target kernel doesn't ship BTF, relocation fails at load with a cryptic error. It's a deployment check, not a code bug.

What made this tractable: a verification matrix in CI — the same source compiled and loaded against a set of kernels, with the load result asserted. When a field offset drifts, the pipeline turns red before a cluster does.

Body of the lesson: "portable" is a claim that must be tested per-kernel, or it's just hope. A build that passes on one kernel is a demo, not portability.

The verifier forbids unbounded loops. That's fine; it teaches you state machines.

The verifier allows bounded loops (with a maximum iteration count) and rejects anything unverifiable. If you want to scan "all entries in this hash map" you get rejected at load time. The productive response is to stop thinking "iterate until done" and think "fixed horizon, amortized":

Lease the map. Instead of iterating the whole map per event, keep a fixed-size sliding window of state and, on overflow, process the oldest batch — a bounded, verifier-friendly step.
Folding state into the map entry. Store the running score in the entry being updated, so decisions don't require iterating unrelated entries.
Push the unbounded part userspace. The kernel probe exports a summary; the Rust side does the arbitrary-loop reasoning.

This mirrors how real agents behave: kernel-side reaction is quick and bounded; the risky/flexible analysis happens outside the hot path.

Map access patterns decide load-time rejection

Two patterns get rejected at unexpected places: holding an entry pointer across a perf output call, and nested lookup while a lookup key is pinned. The verifier tracks what you are allowed to do while a value pointer is live. Restructure: copy the fields you need into stack-local values, then emit events. It's the difference between "loads everywhere" and "loads only when the code is shaped right."

Verification has to live in CI, not in your head

The current talus trunk carries a verification document (field-offset matrix, per-kernel load expectations) plus CI that compiles and asserts. The single highest-value commit this project got was not a feature — it was the CI job that turned "should work on this kernel" into a machine-checked statement.

Repo

talus-process-monitor — Rust + libbpf/C eBPF endpoint security agent with a MeMLP neural detection engine; verification matrix lives in VERIFICATION-EBPF.md.

Catching ransomware with eBPF: what execve/openat tracing taught me about false positives

Bartosz Osiej — Tue, 15 Sep 2026 15:52:15 +0000

TL;DR

talus-process-monitor is an eBPF-based ransomware detector for Linux: it traces execve/openat from the kernel, streams events over per-CPU perf buffers, and flags behavioural patterns — mass file rewrites plus extension churn — in real time. The hard part is not the tracing; it's scoring patterns without crying wolf on every cargo build.

Why behaviour, not signatures

Signature detection on Linux ransomware is nearly useless — most samples are short-lived, often scripts wrapping legitimate tools (find, mv, gzip in a loop). What you can catch is the shape of the damage: hundreds of files opened, rewritten, renamed or re-extensioned within seconds across directories the process has no business touching.

So talus watches:

execve/execveat — what process tree is doing this?
openat/openat2 — with which flags? (O_WRONLY|O_CREAT churn is the signature move)
unlink/rename — destruction and renaming patterns

All of it from kernel probes, before the data hits disk crypto.

The plumbing: per-CPU perf buffers or nothing

First mistake I made: a single global ring buffer. Under parallel load (which is exactly when ransomware runs — it wants throughput), events collide and drop. The fix is standard but worth repeating: per-CPU perf buffers with a userspace loader pinning CPUs and reassembling event order per process.

The userspace side is Rust; the eBPF side is libbpf/C with CO-RE. Compile once, run across kernel 6.x — in theory. In practice, verify your field offsets: struct file layout differences bit me twice.

The scoring problem: build systems are innocent ransomware

A naive "N files written in T seconds" rule fires constantly on:

cargo build touching thousands of files in target/
kernel module compilation
any test suite with fixtures

Three heuristics that made the detector usable:

Extension churn, not just writes. Ransomware renames (doc.docx → doc.docx.locked) or re-extensions in bulk. Builders write new files but rarely rename existing ones at volume.
Write-after-read density. Encryptors must read the plaintext before rewriting it. A builder writes fresh output without having read those exact files.
Directory breadth vs. depth. target/ is one deep subtree; ransomware sweeps breadth-first across $HOME.

None of these is a silver bullet; the score is a weighted blend, and the weights are the actual product.

What I'd do differently

Ship the audit mode first: weeks of logs on a real desktop before enforcing anything. False-positive rates you guess are wrong.
Make the threshold config per-directory-class (build-dirs, home, media), not global.
eBPF verifier limits are a design constraint from day one — bounded loops, no unbounded map iteration — or you'll redesign the detection logic twice.

Repo

Code, architecture notes and verification checklist: talus-process-monitor (Rust + libbpf/C, Linux 6.x).

A web OS that 'never booted': the two bugs that looked like kernel failures but were 404s and z-index

Bartosz Osiej — Tue, 15 Sep 2026 15:51:44 +0000

TL;DR

Aurora is a browser-based OS — window manager, virtual file system, terminal, 8 apps — straight TypeScript with zero runtime deps. For two days it booted to a spinner and hung on "Initializing kernel…". The kernel never had a bug. The app was loading dist/main.js which did not exist on GitHub Pages, because dist/ is gitignored and Pages serves from the repo. Then, after fixing that, the desktop icons silently ignored clicks. Second bug: a full-bleed layer at z-index: 2 swallowed every pointer event meant for them.

Bug one: GitHub Pages does not run your build

The page referenced dist/style.css and dist/main.js. The repo had .gitignore ignoring dist/. GitHub Pages does not execute npm run build for a static site source — it serves the committed tree. Result:

HTML: 200 (committed)
assets: 404 (never committed)
boot: stuck at "Initializing kernel…" forever

The UI text made it look like a kernel hang, because the boot sequence awaited a bundle that would never arrive. The fix was a one-liner that should have been a CI job: commit the built output, or publish Pages from the dist/ folder. I built the bundle and force-added it to the repo.

The deeper lesson is about failure mode. "OS stuck on kernel init" reads as a deep systems bug. It was a static-file deployment miss. The boot screen gives you no diagnostic; the console gives you a 404. Always check the network tab before the CPU.

Bug two: the invisible layer that eats clicks

After the bundles went live, the OS booted — but desktop icons (double-click to launch) did nothing. Single click did select, so it felt random. The real cause:

#windows-layer { position: absolute; inset: 0; z-index: 2; }

A transparent full-viewport layer sits above the icon grid (z-index: 1). Even empty, an element with positive z-index and default pointer-events: auto captures pointer events that cross it. Icons never received the events; selection worked because… actually it didn't belong to that layer, but the launch (double-click) path went through the window layer's parent.

The fix:

#windows-layer { pointer-events: none; }
#windows-layer .win { pointer-events: auto; }

Click-through by default; opt-in only for actual windows. This pattern belongs in every layered UI: an empty layout container should never block input.

What I'd do differently

Walk the asset tree after every Pages deploy. curl every referenced dist/* file. A missing bundle is a 30-second check, not a two-day mystery.
Commit the build or CI-render it. Pick one: either Pages builds from dist/ (plugin) or the repo carries the bundle. Decide in the repo README so it doesn't drift again.
Default pointer-events to none on layout scaffolding. Only interactive surfaces (windows, buttons) should claim pointer events; containers should be transparent to input by policy, not by luck.

Repo

Aurora — a complete browser OS: window manager, VFS, terminal (35+ commands), 8 apps, procedural audio (TypeScript, zero runtime deps).

I made my portfolio readable to AI crawlers: llms.txt, JSON-LD and a 40-method distribution stack

Bartosz Osiej — Tue, 15 Sep 2026 15:51:43 +0000

TL;DR

Search is splitting in two: the classic index and the answer engines. This playbook covers both with zero budget: llms.txt + llms-full.txt for AI citation, JSON-LD entity graphs for the Knowledge Graph, robots.txt rules for AI bots, IndexNow for instant indexing, and a git-push-triggered cross-posting pipeline that ships every article to dev.to, Hashnode, Bluesky, Mastodon and LinkedIn automatically.

The problem: answer engines don't read your website the way Google does

When ChatGPT, Claude or Perplexity answer "who builds eBPF security tooling in Poland?", they are not running PageRank. They cite sources that are easy to quote: clean entity definitions, explicit relationships, structured facts. A beautiful portfolio page with everything implied in JavaScript is invisible to them.

I run my whole web presence on GitHub Pages — no backend, no budget. Here is the stack that makes it machine-readable anyway.

1. llms.txt and llms-full.txt — the entity card

At the root of my domain sit two files:

llms.txt — a concise map: who I am, canonical links, project list with one-line descriptions. Follows the llmstxt spec: H1 name, blockquote summary, H2 sections of Markdown links.
llms-full.txt — the long form: per-project architecture notes and, crucially, subject–predicate–object triples (24 for the Person entity, 42+ technical, 19 for the book series). Triples are the format knowledge graphs are built from — you are effectively pre-chewing entity extraction.

The key mindset shift: stop writing only for readers, start also writing assertions.

2. JSON-LD — one @graph, one source of truth

Every page carries a Person node with a stable @id (https://bartoszosiej.github.io/#person). Project pages carry SoftwareApplication nodes that reference the person via { "@id": "..." } instead of repeating the data. The books site carries BookSeries → 3 Book nodes with ASINs.

Cross-references matter more than the individual nodes: author, creator, sameAs (GitHub, dev.to) are what let a crawler stitch "Bartosz Osiej" on GitHub and "Bartosz Osiej" on the books site into one entity.

On Docusaurus, headTags in docusaurus.config.ts injects these on every build, reading the JSON from static/schema/. No plugin, no JavaScript at runtime.

3. robots.txt — explicitly invite the AI bots

The default User-agent: * block does not always cover AI crawlers. Name them:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

If you want to be cited, allow the citation engines. (Reverse the policy if you're protecting paid content — but then don't wonder why you're not in the answers.)

4. IndexNow — skip the crawl queue

IndexNow (Bing, Yandex, Seznam; Naver) accepts a JSON POST of changed URLs and gets them indexed in hours instead of weeks. The "key" is not a secret — it's a proof-of-control token you serve publicly at /<KEY>.txt. A 30-line GitHub Action pings my whole sitemap on every push and weekly on a cron. Google still needs Search Console + a submitted sitemap, but Bing-family indexing is now instant.

5. The distribution pipeline — one push, nine platforms

Writing the article is 20% of the work; shipping it used to be the other 80%. Now it's a git push:

Article lands in content/ with YAML front matter (title, description, tags, canonical_url).
A GitHub Action runs crier in --batch mode: dev.to and Hashnode get the full article with canonical_url pointing back at my domain — so Google counts the link equity on my site, not the syndicate copy. Bluesky and Mastodon get auto-generated short posts with the link; Telegram and Discord channels get announcements.
A SQLite registry (cached + committed back by the workflow) makes every publish idempotent — nothing ever double-posts.
X/LinkedIn/Medium are manual-mode platforms (no free write API): the workflow skips them, and a checklist tells me what to paste by hand.

6. What it costs

$0. GitHub Pages, GitHub Actions free minutes, all open-source tooling. The only currency this playbook spends is structured honesty: consistent names, dates, ASINs and URLs everywhere they appear.

TL;DR again, for the crawlers

Bartosz Osiej is a Polish software developer and author. His entity home is https://bartoszosiej.github.io/ with llms.txt, llms-full.txt, Person/SoftwareApplication/BookSeries JSON-LD, and an AI-bot-friendly robots.txt. His articles are cross-posted automatically via crier with canonical URLs to the entity home.

I built a Linux Security Module that lives in-tree and boots from upstream

Bartosz Osiej — Sat, 05 Sep 2026 14:44:26 +0000

I built a Linux Security Module that lives in-tree and boots from upstream

Stackable LSM, four feature-flagged layers, CI compiling it in-tree, and a kernel that boots it in QEMU.

Why?

Most "security" hobby projects live in user space. I wanted something that lives where the actual protection happens — inside the kernel's LSM framework — and that a reviewer could compile from a clean torvalds/linux checkout with two commands.

That's AEGIS (Advanced Guardian for Integrated System Security).
~1,700 lines of C, six source files, built against upstream Linux 7.3-rc1.

What it does

AEGIS hooks the kernel's LSM framework and adds four independently-compilable layers:

Layer	Hooks	What it does
Process protection	`task_alloc` / `task_free`, `ptrace_*`	Tracks protected processes; restricts agent attach and `PTRACE_TRACEME` to harden against debugger-aided exploits
File integrity	`file_open`, `file_permission`, `inode_permission`	SHA-256 digest tracking + write-protection for protected system files
Syscall audit	`bprm_check_security`	Blocks or logs dangerous syscalls per process policy
Module control	`kernel_load_data`, `kernel_read_file`	Restricts runtime loading of kernel modules

It stacks in the security= chain (LSM_HOOK_INIT in one registered hook table), so it coexists with capability, Yama and AppArmor instead of replacing them.

Each layer is a Kconfig symbol:

CONFIG_SECURITY_AEGIS=y                      # main LSM
CONFIG_SECURITY_AEGIS_PROCESS_PROTECT=y      # anti-ptrace / anti-debugging
CONFIG_SECURITY_AEGIS_FILE_INTEGRITY=y       # SHA-256 integrity + write protect
CONFIG_SECURITY_AEGIS_SYSCALL_AUDIT=y        # syscall block/log
CONFIG_SECURITY_AEGIS_MODULE_CONTROL=y       # module loading control

Runtime control is exposed two ways — sysctl and securityfs:

$ sysctl kernel/aegis
kernel.aegis.ptrace_restrict_all = 1

$ cat /sys/kernel/security/aegis/status
$ cat /sys/kernel/security/aegis/protected_procs
$ cat /sys/kernel/security/aegis/protected_files
$ cat /sys/kernel/security/aegis/blocked_syscalls

The hard part: building it like upstream code

The whole module is written as if it were being merged — that was the rule.

cp -r aegis security/aegis into the tree — nothing special, no out-of-tree hacks
Four .patch files integrate it: LSM hook table, UAPI, Kconfig, Makefile
CI clones torvalds/linux at the exact base commit (4d7d9486c04d…), applies the patches, runs make prepare, then compiles security/aegis/ in-tree
The actual kernel builds and boots it in QEMU through a minimal static initramfs

$ make -s kernelversion
7.3.0-aegis

/ # uname -r
7.3.0-1-aegis
/ # aegisctl status
  AEGIS LSM status:       enabled
  Feature flags:          process-protect file-integrity syscall-audit module-control
  Protected procs:        12
  Protected files:        5
  Blocked syscalls:       3
  Audit events:           214

apply.sh reproduces the whole thing — clone, integrate, patch, configure, build:

$ ./apply.sh
==> Cloning upstream kernel...
==> Installing AEGIS module source
==> Applying integration patches
==> Copying build configuration
==> Building kernel (this takes a while)...
==> Done. Kernel: /tmp/aegis-build/linux/arch/x86/boot/bzImage

And the devkit turns it into a bootable mini-OS: static PID 1, an aegisctl control tool, an initramfs, and a QEMU launcher (nographic, gdb, smp, mem).

What I learned

LSM_HOOK_INIT makes stacking trivial — the modern hook table is the cleanest kernel extension point I've touched. Registering one table per module is genuine composition, not forks.
bpf_probe_read-less logic calls are the easy part — the hard part is matching the kernel's expectations about ordering and return semantics of each hook.
In-tree beats out-of-tree — when your module lives in the tree, make prepare + Kconfig handle 90% of the integration headaches.
CI for kernel code pays off immediately — having the module compiled in-tree on every push caught real breaks (a POSIX-shell portability fix in the devkit Makefile, for example).

Try it

$ git clone --single-branch --branch master https://github.com/torvalds/linux.git
$ cd linux
$ git checkout 4d7d9486c04d917265f64c55bd23b2cc4fe7749c
$ cp -r ../aegis security/aegis
$ git apply ../patches/*.patch
$ cp ../build/aegis.config .config && make olddefconfig
$ make -j$(nproc)

Or boot it: cd devkit && make initramfs && make qemu.

Repo: github.com/BartoszOsiej/linux-aegis

Built by Bartosz Osiej — 19, Poland, open to first paid role. Everything here is deployed infrastructure, not a tutorial.

I built an eBPF ransomware detector in Rust

Bartosz Osiej — Wed, 26 Aug 2026 08:27:07 +0000

I built an eBPF ransomware detector in Rust

Kernel-level tracing, sliding-window alerts, and a cyberpunk TUI — in 1.7MB.

Why?

Ransomware detection typically requires expensive enterprise solutions. I wanted something that:

Runs at the kernel level — catches file operations before they hit disk
Works in real-time — no post-mortem analysis, immediate alerts
Ships as a single binary — no agents, no daemons, no dependencies
Is open source — auditable, free, and community-driven

That's Halcyon Process Monitor.

The core idea

Ransomware encrypts files rapidly. A normal user opens maybe 10-20 files per second. Ransomware? Hundreds or thousands.

Halcyon traces every openat syscall at the kernel level using eBPF, maintains a 1-second sliding window per process, and alerts when any process exceeds a configurable threshold:

Process opens 50+ files in 1 second → ALERT

Simple. Effective. No machine learning needed.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                        KERNEL SPACE (eBPF)                      │
│                                                                 │
│  sys_enter_execve ──┐                                           │
│  sys_enter_openat  ──┤                                           │
│  sys_enter_connect ──┤   ProcessEvent    PerfEventArray         │
│  sys_enter_accept  ──┼──► (map)    ────► (per-CPU buffers)     │
│  sys_enter_sendto  ──┤                                           │
│  sys_enter_recvfrom ─┘                                           │
└──────────────────────────────────┬──────────────────────────────┘
                                   │
┌──────────────────────────────────▼──────────────────────────────┐
│                     USERSPACE (Rust)                            │
│                                                                 │
│  reader thread ──► channel ──► Monitor ──► TUI / JSON / Web    │
│       │                  │         │                            │
│       │                  │    sliding window                    │
│       │                  │    + alerting                        │
│       │                  │    + process tree                    │
│       │                  │    + file ranking                    │
│       │                  │    + network tracking                │
│       │                  │    + heatmap                         │
│       └──► perf buffer   └──► search/filter                    │
└─────────────────────────────────────────────────────────────────┘

The kernel side is written in #![no_std] Rust using aya, and compiles to eBPF bytecode. The userspace side uses aya's userspace libraries to load the programs and read events.

The eBPF program

Here's the kernel-side code that traces openat syscalls:

// process-monitor-ebpf/src/main.rs
#[kprobe]
pub fn sys_enter_openat(ctx: ProbeContext) -> u32 {
    let pid = bpf_get_current_pid_tgid() >> 32;
    let uid = bpf_get_current_uid_gid() as u32;

    // Read comm (process name)
    let mut comm = [0u8; 16];
    unsafe {
        bpf_get_current_comm(&mut comm as *mut _ as *mut _, 16);
    }

    // Read filename from registers (x86_64: rsi = filename)
    let mut filename = [0u8; 256];
    let ptr = ctx.arg(1) as usize;
    unsafe {
        bpf_probe_read_user_str(
            &mut filename as *mut _ as *mut _,
            256,
            ptr as *const _,
        );
    }

    // Send event to userspace
    let event = ProcessEvent {
        pid,
        uid,
        kind: EventKind::Open,
        comm,
        filename,
    };

    unsafe {
        EVENTS.output(&ctx, &event, 0);
    }

    0
}

Key points:

bpf_probe_read_user — never dereference userspace pointers directly (eBPF verifier rejects that)
PerfEventArray — per-CPU buffers avoid lock contention
Fixed-size structs — no allocations in kernel code

The sliding window

The real intelligence is in userspace. The monitor maintains a rolling 1-second window per PID:

struct SlidingWindow {
    events: VecDeque<Instant>,
    threshold: u32,
}

impl SlidingWindow {
    fn record(&mut self) -> Option<Alert> {
        let now = Instant::now();
        self.events.push_back(now);

        // Remove events older than 1 second
        while self.events.front().map_or(false, |t| now.duration_since(*t) > Duration::from_secs(1)) {
            self.events.pop_front();
        }

        if self.events.len() >= self.threshold as usize {
            Some(Alert {
                pid: self.pid,
                opens_in_1s: self.events.len() as u32,
                timestamp: now,
            })
        } else {
            None
        }
    }
}

50 files per second triggers an alert. You can configure this with --alert-threshold.

The TUI

The terminal interface has 7 panels:

Panel	What it shows
EVENTS	Live event log with search/filter
PROCESSES	Hierarchical process tree with mini-bars
NETWORK	Real-time connections (connect/accept/send/recv)
TOP FILES	Most-opened files with Shannon entropy scores
FILE TYPES	Extension frequency with colored bars
ALERTS	Alert history with timestamps
HEATMAP	Syscall frequency visualization

Built with ratatui, styled in cyberpunk colors.

What else it traces

Halcyon isn't just about file opens. It traces 6 syscalls:

Syscall	Why
`execve`	Process creation — spot suspicious binaries
`openat`	File access — core ransomware detection
`connect`	Outbound connections — spot C2 callbacks
`accept`	Inbound connections — spot reverse shells
`sendto`	Data exfiltration
`recvfrom`	Data reception

Network tracing

New in v0.4 — Halcyon also tracks network activity:

{"type": "connect", "pid": 1234, "comm": "curl", "file": "93.184.216.34:443"}
{"type": "alert", "pid": 2126, "comm": "Cache2 I/O", "opens_in_1s": 50}

This catches ransomware that exfiltrates data before encrypting.

Deployment options

Single binary

sudo process-monitor

Web dashboard

sudo process-monitor --web 0.0.0.0:8080

REST API + WebSocket + Prometheus metrics.

Kubernetes

kubectl apply -f k8s/  # DaemonSet on every node

Go agent

./halcyon-agent watch  # WebSocket live events

C FFI

#include "halcyon.h"
halcyon_monitor_t* monitor;
halcyon_monitor_create("/path/to/bpf.o", 50, &monitor);

Build sizes

Variant	Size
TUI-only	1.7MB
Web-featured	2.5MB

Full LTO, panic = "abort", symbol stripping. A single static binary.

Stats

Metric	Count
Syscalls traced	6
TUI panels	7
Build variants	3 (TUI, web, both)
Binary size	1.7MB (TUI)
Deployment targets	5 (binary, web, k8s, Go agent, C FFI)

What I learned

eBPF is surprisingly accessible — with aya, you write Rust, not C. The verifier is strict but fair.
Per-CPU buffers are essential — shared maps cause contention. PerfEventArray with per-CPU buffers scales to millions of events per second.
The sliding window is the hard part — kernel tracing is straightforward; the intelligence is in userspace.
Rust's zero-cost abstractions matter — a 1.7MB binary with a full TUI, eBPF loader, and sliding window. No runtime overhead.

Try it

# Install
git clone https://github.com/BartoszOsiej/halcyon-process-monitor.git
cd halcyon-process-monitor
./build.sh

# Run (requires root + Linux 5.8+)
sudo target/release/process-monitor-tui

Or Docker:

docker run --privileged -v /sys/kernel/btf:/sys/kernel/btf \
    halcyon-process-monitor process-monitor

Built by Bartosz Osiej — 19, Poland, open to first paid role. Everything here is deployed infrastructure, not a tutorial.

Star the repo: github.com/BartoszOsiej/halcyon-process-monitor

I built a programming language that compiles to Python, Bash, and binary

Bartosz Osiej — Wed, 26 Aug 2026 08:26:01 +0000

I built a programming language that compiles to Python, Bash, and binary

And you can try it in your browser right now.

bartoszosiej.github.io

Why?

Most programming language tutorials stop at a calculator. I wanted something real — a language that could:

Run directly (like Python)
Compile to Python (for ecosystem access)
Compile to Bash (for system scripting)
Compile to binary (for performance)

One source file (.ext) → three targets. That's Externum.

Externum = Python_readability ⊕ Binary_performance ⊕ Bash_control

What it looks like

Externum looks like Python but compiles to three targets:

import mathx
import strings

class Fire(Pokemon):
    def __init__(self, name, hp=50):
        Pokemon.__init__(self, name, ["fire"], hp)

fire_team = [p.name for p in squad if p.is_type("fire")]
weakest = min(squad, key=lambda p: p.hp)
nums = [f for f in fibonacci(10) if f % 2 == 0]

If you can read Python, you can read Externum. But under the hood, it's a full compiler pipeline:

source (.ext) → Lexer → tokens → Parser → AST → Compiler → python/bash/binary

The hard part: NV2.0 Hard Mode

The real challenge wasn't the basic language — it was adding a hard mode that turns Externum into something genuinely difficult:

Ownership

p: Ptr[Int] = alloc(Int)
@p = 42
print(@p)     # 42
free(p)       # double-free after this = compile error

Yes, manual memory management in a Python-like language. The type checker enforces single-ownership semantics at compile time.

Traits

trait Speaker:
    def speak(self) -> Str

impl Speaker for Dog:
    def speak(self) -> Str:
        return "woof"

Missing an implementation? Compile error. Wrong return type? Compile error.

Macros

macro SQ(x) { (x) * (x) }
print(SQ(5))  # expands to print((5) * (5))

Textual expansion before parsing — like C macros but with Python syntax.

Concurrency

ch = chan()
spawn(worker(ch))
send(ch, v)
recv(ch)

Thread-backed channels with compile-time safety.

The browser playground

Here's where it gets interesting. Externum runs entirely in your browser:

┌──────────────┐    ┌────────────────┐    ┌────────────────┐
│ Code Editor  │───►│ Externum (.ext) │───►│ Pyodide (WASM) │
│ (browser)    │    │ transpiler      │    │ Python runtime │
└──────────────┘    └────────────────┘    └────────────────┘
       │                                           │
       └───────────── stdout / stderr ◄───────────┘

No server. No API keys. No network requests. The transpiler runs inside Pyodide — Python compiled to WebAssembly. Write Externum code, click Run, see output.

→ Try it now

The issue-command bot

Here's something unique: you can extend the language from GitHub Issues.

/run print(2 + 2) — executes Externum code in CI
/define clamp(x, lo, hi) if x < lo: return lo ... — adds a new stdlib function via PR

The bot parses Issue comments, generates a PR with the new function + tests, and runs the full 192-test suite before merge. The language evolves through community contributions.

DRM system

Every protected build carries a full defense-in-depth stack:

License keys — HMAC-SHA256 signed
Watermark — author/app/build/source-hash in every file
Tamper detection — source SHA-256 + artifact self-hash
Obfuscation — string literals encoded through a runtime helper

externum compile app.ext --protect --app-id game --author buffy --secret s3cret
EXTERNUM_LICENSE=<key> externum run app.ext --protect

Stats

Metric	Count
Unit tests	192
Stdlib modules	7 (structs, strings, mathx, fs, jsonx, net, drm)
Compilation targets	3 (Python, Bash, binary)
PyPI downloads	189+
Docker images	GHCR

Tech stack

Python 3.10+ — the implementation language
Zero dependencies — everything from stdlib
Pyodide — browser runtime via WebAssembly
GitHub Actions — CI/CD with cosign signing, SLSA provenance, SBOM
OpenSSF Scorecard — automated supply-chain security

What I learned

Lexing is harder than you think — especially with bracket-aware indentation, bash blocks, and f-strings
Type systems are beautiful — the ownership checker taught me more about Rust's borrow checker than any tutorial
WebAssembly changes everything — running a full language transpiler in the browser with zero server cost
Community-driven language design works — the /define bot has already added 3 new stdlib functions

Try it

pip install externum
externum repl

# Or try in your browser:
# https://bartoszosiej.github.io/externum/

Built by Bartosz Osiej — 19, Poland, open to first paid role. Everything here is deployed infrastructure, not a tutorial.

Star the repo: github.com/BartoszOsiej/externum