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

#cpp #archlinux #opensource #linux

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: