DEV Community: Zach Massey

Why I Built a C++ Linux System Monitor (And Why You Should Too)

Zach Massey — Fri, 17 Oct 2025 20:23:11 +0000

I've spent the last week and a half building a system monitor tool in C++ for Linux called gshell, and it's been an incredible journey into real systems programming. its also a pretty cool-looking ricing system monitor.

Demo video

The Problem

The Arch Linux community has a wasteland of broken Python tools. When dependencies update, these tools break. Here's my hot take: Python and JS have their use cases, but systems programming isn't one of them.

Both languages offload heavy lifting to C/C++ libraries, creating fragile dependency chains. One pip update later and your monitoring tool is toast.

The Solution

Cut through the noise and the "C/C++ is too hard, just use Python" misconception. Build it in the right language for the job.

Software development means I'm not a "JavaScript developer" or a "Python developer" — I'm a developer. Identifying myself by the tool I use is like a carpenter saying they're a "hammer aficionado."

What I Learned

This project taught me about true concurrency — not high-level abstractions, but manually managing threads that probe the /proc filesystem.

I gained hands-on experience with:

Concurrent file system access and rendering - Multiple threads reading /proc simultaneously
Thread synchronization and resource management - Mutexes, atomic operations, the works
The reality of systems-level programming - No garbage collector to save you

Where This Is Taking Me

Building gshell has sparked a deeper interest in systems programming. I've picked up K&R's "The C Programming Language" and am working toward understanding how C runs the Linux kernel.

One day, I'd like to write Linux drivers—that goal is far off, but this project is the first step.

What Makes gshell Different

Animated GIFs in the terminal while performing concurrent system monitoring (had to throw a Cowboy Bebop gif in because I'm using Arch, after all)
Built with FTXUI for the terminal interface
Leverages Kitty Terminal's image protocol
Fully customizable via .conf file - colors, custom GIFs, layout
Configuration elements stored in hashmaps for O(1) lookup and seamless runtime performance
Written in C++ for performance and reliability
No Python dependency hell

Technical Highlights

// Example: Concurrent /proc reading
std::atomic<bool> running{true};
std::thread memoryThread([&]() {
    while (running) {
        auto memInfo = readProcMeminfo();
        updateDisplay(memInfo);
        std::this_thread::sleep_for(std::chrono::seconds(1));
    }
});

The entire config system uses hashmaps for efficient lookups - no iterating through arrays at runtime. This was a deliberate choice to understand time complexity tradeoffs in real applications.

Coming Soon

I'll be releasing gshell as open source via the Arch User Repository soon. Follow-up post coming when it's live.

The Challenge

If you're comfortable in high-level languages, challenge yourself with a systems project. The learning curve is steep, but the understanding you gain is irreplaceable.

You'll learn:

How your operating system actually works
What "performance" really means
Why certain design decisions matter
Memory management beyond garbage collection

Final Thoughts

Building tools in the language they deserve to be built in matters. Not every problem needs a systems language, but when you're building system utilities, nothing beats C/C++.

What systems-level projects have you built? Drop them in the comments - I'd love to check them out!

Follow me for more posts on:

Systems programming in C/C++
Linux kernel development journey
Building tools the hard way

GitHub: https://github.com/echtoplasm

LinkedIn: https://www.linkedin.com/in/zachary-massey-5b8715259/

Blazer AI: Intelligent Student Handbook and Website Assistant

Zach Massey — Sat, 27 Sep 2025 15:32:40 +0000

This is a submission for the Heroku "Back to School" AI Challenge

Blazer AI: Intelligent Student Handbook Assistant

What I Built

Blazer AI is an AI-powered chatbot designed specifically for AB Tech students and faculty to quickly find information buried within the school's extensive website and student handbook. The application solves the common problem of students and faculty struggling to navigate institutional resources and find answers to academic questions.

Built in just 2 weeks while managing 5 classes, Blazer AI combines vector similarity search with intelligent query routing to provide contextually relevant answers. The system can handle both specific course inquiries (like "Tell me about CSC-151") and general questions (like "What are the graduation requirements?") by automatically detecting query types and routing them through appropriate search mechanisms.

The application transforms traditionally static institutional knowledge into an interactive, conversational experience that's available 24/7 for student and faculty support.

Demo

Live Application: https://blazer-ai-abt.com/
Live Application using heroku url: https://handbooky-frontend-575fce723934.herokuapp.com/

Source Code:

Frontend: https://github.com/echtoplasm/handBooky-frontend
Backend: https://github.com/echtoplasm/handBooky-backend

Screenshots

Homepage before chatting:

Normal questions being asked:

Demo GIF:

GIF showing the React state management and context being passed between two components to ask questions of the chatbot

Key Features Demonstrated

Intelligent query routing between vector and non-vector search
Real-time AI responses with source citations
Mobile-responsive design optimized for student use
Sample questions tailored to common student inquiries

Technical Architecture

Frontend: React application deployed via Heroku Static Buildpack
Backend: Node.js/Express API with PostgreSQL vector database
AI Integration: Claude 3.5 Haiku via Heroku Managed Inference

How I Used Heroku AI

Heroku Managed Inference: Integrated Claude 3.5 Haiku for natural language processing and response generation. The AI agent is configured with a comprehensive system prompt that restricts responses to school-related topics and ensures citations are included.

Heroku Embedding Model API: Used for generating vector embeddings from user queries, enabling semantic similarity search through the knowledge base.

pgvector Integration: Leveraged PostgreSQL with pgvector extension for storing and querying text embeddings, allowing the system to find contextually relevant information even when exact keyword matches aren't available.

Agent Coordination

The system employs intelligent routing logic:

Course Code Detection: Regex pattern matching identifies specific course queries (e.g., "CSC-151") and routes them to direct database lookups
Vector Search: General queries generate embeddings and perform similarity searches through the vector database
Context Assembly: Retrieved information is structured with source metadata and fed to the AI agent for natural language response generation

Technical Implementation

Multi-Agent Architecture

Query Router: Analyzes incoming messages to determine search strategy
Vector Search Agent: Handles semantic similarity searches using embeddings
Course Lookup Agent: Manages direct database queries for specific course codes
Response Generator: Claude 3.5 Haiku processes context and generates student-friendly responses

Key Technologies

PERN Stack: PostgreSQL, Express.js, React, Node.js
Vector Database: PostgreSQL with pgvector for similarity search
AI Integration: Heroku Managed Inference with Claude 3.5 Haiku

Technical Challenges Solved

Intelligent Query Routing: Developed a hybrid approach that combines exact course code matching with semantic vector search, optimizing both accuracy and response time.

Data Processing Pipeline: Built utilities to process PDF documents and website content into structured, searchable chunks with embeddings, handling inconsistent institutional data formats.

Context Optimization: Implemented context assembly that includes source metadata, prerequisites, and corequisites to provide comprehensive responses while staying within token limits.

Responsive Design: Created a mobile-first interface optimized for student use patterns, recognizing that most students access information via smartphones.

Development Timeline: Solo-developed and completed in 2 weeks while maintaining a full course load, demonstrating efficient project management and focused technical implementation.

Data Sources: Integrated AB Tech's student handbook (PDF) and website sitemap data, creating a comprehensive knowledge base covering academic policies, course information, and campus resources.

The application successfully transforms static institutional documentation into an interactive, intelligent assistant that understands student intent and provides relevant, cited information in a conversational format.

Future Implementations

The future implementation of this application would allow users to drag and drop their own sitemap data or handbook PDF data, and the app would parse and embed it for them. This would allow any institution to have an RAG agent implemented and ready to answer any of their questions related to their institution's resources. This was the original vision for this application, but due to time constraints and being a solo developer, I had to scale back the ambition a bit.