DEV Community: Josiah Mbao

How a 2GB Flash Drive Led Me to Rust, Linux Internals and eBPF

Josiah Mbao — Wed, 09 Sep 2026 14:54:52 +0000

A few months ago, my dad gave me his old work laptop.

I was excited. A new machine to call my own.

So naturally, I factory-reset the thing.

Then I did something slightly more drastic: I got rid of Windows.

There was just one problem.

The only flash drive I had was around 2 GB, which wasn't going to be enough to put Windows back on the machine.

So I started wondering:

What operating system is small enough to fit on a 2 GB flash drive?

Enter Arch Linux.

Falling down the Arch Linux rabbit hole

Getting Arch Linux running was not exactly a one-click installation.

It took me about two days to get the ISO, boot from it, partition the disk, install the system, configure everything, and eventually get to something usable.

And by "usable," I mean a purely terminal-based environment.

No desktop environment.

No polished GUI.

Just a shell and a Linux system that I was now responsible for figuring out.

A week later, a friend who had been using Arch longer than I had introduced me to Hyprland.

That opened another rabbit hole.

I started customizing my desktop, configuring the terminal, installing tools, tweaking things, and generally enjoying how much control Linux gave me over my own machine.

Eventually, I wanted to know how the machine itself was doing.

How much CPU was being used?

How much memory?

What processes were running?

So I reached for the obvious tools:

top
htop

They did exactly what I needed.

But then I had another thought:

If Linux is this customizable, could I build my own tool to answer the question of how my machine is doing?

That question eventually became Pulse.

What is Pulse?

Pulse is a Linux observability TUI written in Rust.

It started as a small experiment to learn more about Linux internals and terminal applications.

Instead of simply using existing monitoring tools, I wanted to understand where the information they displayed actually came from.

That led me to /proc.

`/proc`: My first look under the hood

Linux exposes a huge amount of information about the running system through the proc filesystem.

For example:

/proc/
├── stat
├── meminfo
├── loadavg
└── <pid>/
    ├── stat
    ├── status
    └── ...

Pulse reads information from these interfaces and turns the raw data into metrics that can be displayed in the terminal.

[Pulse v0.1 - Early version]

This was the first point where the project became more interesting than simply building another TUI.

I started realizing that a metric like CPU utilization isn't necessarily something you can just ask Linux for.

You might instead get raw counters, understand what those counters represent, take measurements over time, and calculate the value you actually want.

For example, /proc/stat exposes CPU time counters:

cpu  1234 56 789 10234 12 0 34 0 0 0

Pulse can use this information to derive useful metrics about CPU activity.

That meant I wasn't just displaying system information.

I was learning how the system exposes that information in the first place.

Why Rust?

I'll admit something:

I love Rust and will find any excuse to use it.

But in this case, I actually had a pretty good excuse.

Pulse is a Linux observability tool, which puts it fairly close to the systems programming domain.

And guess what else works well in systems programming?

Rust.

I wanted Pulse to teach me more than just Linux. I also wanted to become significantly more comfortable writing Rust, particularly when dealing with lower-level concepts, concurrency, processes, memory, and long-running applications.

Rust's memory-safety guarantees were especially attractive for a tool interacting with a constantly changing system.

Processes can start and disappear.

Files can change between reads.

System state can change while you're rendering it.

The application itself is continuously collecting data and updating the UI.

Rust gives me strong guarantees around memory safety while still allowing me to work fairly close to the system.

More importantly, Rust forced me to think differently about how I structure programs.

Pulse became one of my excuses to go deeper into the language.

From `/proc` to observability

Once Pulse could render system metrics from /proc, I started asking another question:

What else can I monitor?

And then:

Can I do it faster?

The more I looked into Linux internals, the more I realized that there was a much bigger world underneath what tools like top and htop expose.

/proc is incredibly useful for understanding system state.

But I wanted Pulse to eventually understand events happening inside the system.

Processes being created.

System calls being made.

Network activity.

Kernel functions being executed.

And potentially much more.

That's when I stumbled into eBPF.

Enter eBPF

eBPF opened up an entirely different side of Linux observability for me.

At a high level, eBPF lets you run small programs in the Linux kernel to observe and respond to events happening inside the system, without having to modify the kernel's source code.

That means you can attach programs to things like system calls, network events, tracepoints, and other kernel activity, collect information about what's happening, and send that data right back to a user-space application.

Instead of only asking the system:

"What is happening right now?"

I could start asking:

"What just happened, and why?"

Conceptually, Pulse started evolving from something like this:

        Linux
          │
        /proc
          │
      Collect data
          │
        Pulse
          │
         TUI

towards:

                  Linux Kernel
                       │
              ┌────────┴────────┐
              │                 │
            /proc              eBPF
              │                 │
              └────────┬────────┘
                       │
                   Collectors
                       │
                   Pulse Core
                       │
                      TUI

I'm currently only using eBPF for a small subset of Pulse's functionality, but getting those first pieces working changed how I thought about the project.

Pulse wasn't just a system monitor anymore.

It was becoming a playground for learning Linux observability.

What I've learned building Pulse

The biggest lesson hasn't actually been Rust.

It's been realizing how much abstraction exists between what I see on my screen and what the operating system is actually doing.

Before Pulse, I could run:

htop

and see CPU utilization, memory usage, processes, and other information.

Now I have a much better appreciation for the chain of things happening underneath those numbers.

Linux exposes information through interfaces like /proc.

Applications interpret that information.

Metrics often have to be calculated from raw counters.

And with eBPF, you can go even deeper and observe activity directly within the kernel.

Building Pulse has basically been an excuse to keep peeling away those layers.

[Trace Lens - eBPF in action]

Every time I think I've reached the bottom, I find another layer underneath.

What surprised me

One of the things I didn't expect when I started Pulse was how quickly a seemingly simple project could lead into completely different areas of computer science.

I started with:

"How much CPU am I using?"

That led to:

/proc
  ↓
Linux internals
  ↓
Systems programming
  ↓
Rust
  ↓
Observability
  ↓
eBPF
  ↓
Kernel instrumentation

And that's probably my favorite thing about software engineering.

You can start with a small question and keep digging until you find an entirely different layer underneath.

What's next?

Pulse is still very much a work in progress.

I'm particularly interested in expanding its eBPF instrumentation.

Right now I'm only tracking a couple of things through eBPF, but I'm learning that there's a lot more that can be observed.

Networking is one area I'm particularly interested in exploring.

There are also plenty of other kernel-level events and subsystems that could eventually become part of Pulse.

I don't have a final definition of what Pulse is supposed to become yet.

And honestly, I like that.

The project started because I wanted to answer a simple question:

How is my machine doing?

It has gradually turned into a much more interesting question:

What's actually happening inside my machine?

That's the question I want to keep exploring.

Final thoughts

Pulse started as a small /proc-based system monitor I was building to learn more about Linux internals and terminal applications.

It has since become my playground for learning:

Linux systems programming
Rust
observability
eBPF
kernel instrumentation
terminal UI development

And I'm nowhere near done.

The project is open source, and I'll keep building it as I learn more about what's happening underneath the abstractions we normally take for granted.

[Pulse v0.8 - Latest version]

If you're interested in Linux internals, Rust, or observability, the project is here:

josiah-mbao / pulse

Linux observability TUI built in Rust, combining /proc telemetry with real-time eBPF kernel tracing

Pulse

An open-source Linux observability TUI built with Rust.
Combining low-overhead /proc telemetry with real-time eBPF kernel lifecycle tracing.

🌐 Live Website & Documentation

🎭 Visual Evolution

Latest — v0.8 "Kernel Trace"

Original — v0.1

Live terminal recordings generated with asciinema.

🌱 The Origin Story

Pulse started on a whim and a hand-me-down laptop.

After reviving an old machine with Arch Linux and building a custom Hyprland desktop, I found myself constantly reaching for top and htop whenever something felt slow.

Watching thousands of values update in real time sparked a question:

How can these tools continuously observe an entire Linux system without becoming the bottleneck themselves?

Arch Linux encourages understanding your system from the ground up, so I decided to extend that philosophy to application development.

Rather than treating Linux as a black box, I wanted to understand how observability works from the kernel upward—how processes are born…

View on GitHub

Built because I wanted to know what my machine was actually doing.

Building Terminal GPT: How Plugins Turned a Chatbot into an AI Agent

Josiah Mbao — Sat, 24 Jan 2026 18:25:55 +0000

From Simple CLI Chat to the Real Insight: Plugins as the Boundary Between Reasoning and Action

When I first started building Terminal GPT, I envisioned a simple CLI chat interface with an LLM backend. But as I iterated through the architecture, something unexpected happened - the plugin system I built to extend functionality became the most fascinating and powerful part of the entire project.

The key insight: plugins aren't just features - they're the essential boundary between AI reasoning and real-world action. This architectural pattern fundamentally changed how I think about building AI systems.

Why Plugin Architecture Matters

What started as a way to add basic file operations and calculations evolved into a formalized plugin architecture that fundamentally changed how my AI assistant interacts with the world. Instead of being limited to text-based responses, my AI can now:

Read and write files
Perform complex calculations
Access live sports data
Execute system operations
And much more through extensible plugins

The Architecture That Made It Click

The real learning moment came when I realized that plugins aren't just features - they're a fundamental architectural pattern for building AI systems that can actually do things.

Key Design Decisions:

1. Formal Plugin Contracts

class Plugin(ABC):
    name: str
    description: str
    input_model: Type[BaseModel]
    output_model: Type[BaseModel]

    async def run(self, input: BaseModel) -> BaseModel: ...

2. Automatic Registration
Plugins automatically register themselves with the LLM, creating a dynamic tool ecosystem.

3. Structured Input/Output
Pydantic models ensure type safety and clear contracts between the AI and tools.

4. Isolated Execution
Each plugin runs in its own validated environment with error boundaries, ensuring failures are contained and don't crash the entire system.

The Technical Stack

Backend: Python with FastAPI for the REST API
CLI: Rich terminal interface with beautiful formatting
LLM Integration: OpenRouter for flexible model access
Plugin System: Pydantic for contracts, async/await for execution
Architecture: Clean separation with domain-driven design

What I Learned

The plugin architecture taught me that building AI systems isn't just about the model - it's about creating a framework where the AI can leverage external capabilities. This pattern:

Makes the system infinitely extensible
Provides clear boundaries between concerns
Enables graceful failure handling
Creates opportunities for community contributions

Personal Touch: Building My Own AI Agent

What makes this project especially cool for me is that I'm essentially building an AI agent from scratch. As a Houston Rockets and Manchester United fan, I've added sports tools so my AI can answer all my stat-head questions. I've also given the AI some personality - it's got a laid-back, slightly whimsical character that makes our conversations more engaging. It's like having a coding buddy who's also into sports and can actually do things, not just chat!

The Star of the Show

What began as a simple file reader plugin is now a sophisticated system where the AI can reason about which tools to use, chain multiple operations together, and provide structured results back to the conversation.

What's Next?

I'm curious to hear your thoughts on what tools would be valuable in an AI assistant like this. I'm thinking about:

Git operations (status, commits, branches)
Code analysis and refactoring suggestions
System monitoring and diagnostics
Package management (pip, npm, cargo)
API testing and documentation generation

What would you add to make this more useful in your daily development workflow?

Media Assets

Screenshot 1: Terminal Interface

Show the CLI interface with a conversation where the AI has just executed a plugin, displaying the structured results.

Screenshot 2: Plugin Architecture Diagram

The mental model: AI reasons about what to do, then hands off to specialized plugins that safely perform actions and return structured results.

Code Snippet: Simple Plugin Implementation

Here's a clean example of how easy it is to add new capabilities to the system:

from pydantic import BaseModel
from terminal_gpt.domain.plugins import Plugin

class ReadFileInput(BaseModel):
    path: str

class ReadFileOutput(BaseModel):
    content: str

class ReadFilePlugin(Plugin):
    name = "read_file"
    description = "Reads a text file from disk"
    input_model = ReadFileInput
    output_model = ReadFileOutput

    async def run(self, input: ReadFileInput) -> ReadFileOutput:
        content = Path(input.path).read_text()
        return ReadFileOutput(content=content)

I'd love to hear your thoughts on plugin architectures in AI projects. What patterns have you found useful, and what would you add to make systems like this even more powerful?

Shipping CoinPeek: Building a Real-Time Crypto Monitor in Rust

Josiah Mbao — Fri, 09 Jan 2026 21:36:52 +0000

Shipping CoinPeek

A 572KB WASM binary. Zero network requests after initial load. Real-time crypto prices in your terminal.

Why I built it

I was tired of tab-switching to check ETH prices. Every context switch cost me 30 seconds of focus. So I built a terminal dashboard in Rust that shows live market data without leaving my IDE/terminal.

The core TUI (terminal user interface)

Performance Benchmarks

Metric	Value
WASM bundle size	572 KB
Memory footprint	~8 MB (terminal) / ~15 MB (web)
Price update latency	< 100ms (WebSocket)
UI render time	< 16ms (60fps)
Cold start (web)	~300ms
Binary size (macOS)	2.1 MB

Architecture

Terminal app: Ratatui TUI + SQLite for offline persistence
Web app: Yew + WebAssembly (same core logic)
Data layer: WebSocket streaming from Binance (no polling)
Storage: tokio-rusqlite with bundled SQLite (works offline)

The same core logic compiled to WebAssembly and rendered in the browser using Yew.

Lessons Learned

Building CoinPeek reinforced that shipping beats perfection. The first version had hardcoded API calls and no error handling. But it worked — and that momentum carried me through polishing, testing, and CI automation.

What would you add next? A portfolio tracker? Alerts? Sound off in the comments.

Links

Repo: https://github.com/josiah-mbao/coinpeek
Live web: https://josiah-mbao.github.io/coinpeek/

How I Built a Zero-Config CLI That Generates READMEs in 60 Seconds

Josiah Mbao — Fri, 02 Jan 2026 10:34:14 +0000

README files are usually the last thing I write.

Not because they’re unimportant — but because by the time the code works, I just want to ship. Over time I noticed the same pattern: inconsistent sections, missing install steps, or a README that didn’t reflect the project at all.

I didn’t want a smarter template. I wanted less friction.

So I built a small Python CLI that generates a clean, GitHub-ready README with almost no setup.

Design goal: zero configuration

The main constraint I set for myself was:

A developer should be able to try it in under 60 seconds.

That ruled out:
• Config files
• Manual template selection
• Long command flags

If that felt slow or confusing, the tool had failed its goal.

Implementation decisions

Typer for CLI ergonomics

I chose Typer because:
• Type hints double as CLI definitions
• Commands stay readable as the tool grows
• Help output is clean by default

This helped keep the surface area small while still being extensible.

⸻

Jinja2 templates (tested) Templates are easy to add — but easy to break.

Instead of treating them as static files, I:
• Versioned templates
• Added tests to validate output structure
• Enforced required sections per template

This avoids generating a README that looks polished but misses critical sections.

⸻

Smart defaults over questions. Rather than asking everything, the tool:

• Infers project name from the directory
• Suggests sections automatically
• Only prompts when needed

Fewer prompts = faster flow.

⸻

Rich for feedback, not decoration I used Rich sparingly:

• Clear success/failure messages
• Human-readable errors
• No unnecessary animations

CLI tools should feel calm, not flashy. But also not boring.

⸻

What I learned shipping my first PyPI package

One thing I didn’t expect was how different “working locally” is from “working once published.”

In my first release, readmegen init ran — but didn’t actually generate a README.
The issue wasn’t the logic. It was packaging.

I hadn’t bundled my Jinja2 templates in the PyPI distribution, so once installed, the CLI couldn’t find them.

That forced me to learn:
• How Python packaging actually works
• Why MANIFEST.in matters
• How to include non-code files in a distribution
• Semantic versioning and republishing fixes properly

It was frustrating — but also satisfying. Shipping something people can install teaches lessons you don’t get from local scripts.

⸻

What I deliberately didn’t add (yet)

There’s currently a placeholder for AI enhancement.

I could auto-generate descriptions, features, or usage sections — but I’m cautious. Bad AI-generated docs can be worse than no docs at all.

Before adding it, I wanted to understand how developers actually feel about it.

⸻

Where this could go next

Some ideas I’m considering:
• AI-assisted rewriting (opt-in)
• Project structure analysis for smarter sections
• README linting / suggestions instead of generation

But I’m trying to keep the core simple.

Try it (if you want)

pip install readmegen-oss
readmegen init

Repo + docs are here: https://github.com/josiah-mbao/ReadmeGen
Live site: https://josiah-mbao.github.io/readmegen-site/

Question for you

Would you ever let AI write your README files?

I'm genuinely curious before pushing this further.