DEV Community: Jeremy Nobel

From KRON to KLS: Evolution, Technical Failures, and the Art of Reinventing the Wheel in Linux

Jeremy Nobel — Sat, 27 Jun 2026 02:01:57 +0000

On March 23rd, I updated KRON for the last time. Today, the project not only has a new name, but a completely refined vision.

Initially, KRON was conceived as a toolkit of basic Linux utilities modified with a strict focus on security and auditing. While I have kept that security core, the idea of building a massive toolkit is gone. I chose instead to embrace the old Unix philosophy: Do one thing, and do it well.

That is how KRON transformed into KLS, a listener (in the style of the ls command) focused exclusively on directory auditing.
The Current Focus and the Performance Headache

Currently, KLS is responsible for scanning directories to detect file alerts with SUID/SGID permissions and Linux Capabilities. It is 100% designed for Linux (I am not ruling out a Windows adaptation in the future, but it is not the priority right now).

My current plan splits into two fronts: improving the tool's professional viability and optimizing its performance. The latter has been, without a doubt, the most expensive and difficult part. Making the tool useful in terms of information is one thing; making it fast is a whole different beast.

In my quest for optimal performance, I went through several stages and experiments:

Classic Single-Threaded Model: Way too slow for massive file systems.
Direct getdents64: I tried gathering entries directly into a buffer using the native syscall to bypass the overhead of higher-level C/C++ standard library functions.
A Failed Attempt with io_uring: This was a catastrophic failure. I was exploring advanced asynchronous concepts in a way I had never programmed before. I made the mistake of copying code and trying to guess what the AI was doing without truly understanding it. I broke my own rule of understanding every single line.

After the stumble with io_uring, I decided to step back into a territory I actually master: a multithreaded Producer-Consumer model. Performance improved significantly, though I admit it is still far from where I want it to be.

Next Step: Viability and Clean Code

Before I continue obsessing over micro-optimization, I have decided to shift my strategy. My immediate goal is to make KLS an attractive, observable option for the real world—so that a security auditor looks at it and thinks: "This is actually useful for my day-to-day work." To achieve this, I am focusing on cleaning, refactoring, and documenting the codebase, ensuring it is clear enough for the community to understand and contribute to.

A Reflection on University and Curiosity

Building this project has taught me more than I have learned in three years of university. I am not discounting academia, but university only gives you the general foundation; it is personal curiosity and the hunger to tackle genuinely challenging projects that actually make you an engineer.

Developing KLS has been a mental catalyst. In fact, while I fight with threads and Linux capabilities, my mind keeps racing with new ideas...

The Tech Corner: Squeezing Performance out of Linux (And seeking advice)

Since I know there are true systems experts on dev.to, I want to open up a discussion and ask for advice in two areas I am currently focusing on to take KLS to the next level:

1. Tips for Optimizing Directory Entry Retrieval (I/O)

Right now, the bottleneck is the file system traversal. While the Producer-Consumer model helped, disk contention or syscall overhead when calling stat / getxattr for capabilities is still costing me dearly.

Is it worth structuring a thread pool where a master thread only lists directories and worker threads process the metadata, or is it better for each thread to autonomously own specific subtrees?

2. Looking for Literature: What books do you recommend to master real async and low-level programming?

My failure with io_uring made it clear that I don't want to use abstractions I don't understand. I want to build the proper theoretical foundations. What books do you recommend for mastering async programming, advanced concurrency, and Linux Kernel internals?

I currently have my eyes on classics like:

The Linux Programming Interface (Michael Kerrisk)
Linux System Programming (Robert Love).

What other books do you consider indispensable for truly understanding concurrency patterns, the Linux I/O subsystem, or modern low-level async frameworks?

I'd love to read your thoughts in the comments! If you want to take a look at the code (and constructively tear it apart), here is the repository: https://github.com/NobelC/kls

Kron Devlog #2: copy is done — threads, syscalls and a performance problem I haven't solved yet

Jeremy Nobel — Mon, 23 Mar 2026 01:52:19 +0000

Compared to previous commands, copy was relatively straightforward to build. The options — recursive, force, dry-run, verbose, skip-existing, no-overwrite, pattern filtering — all came together without major friction. Testing was clean. No dramatic bugs this time.

The real challenge was the threading model.
The original implementation had a fundamental flaw: threads would exit their loop as soon as the work queue was empty, even if other threads were still discovering new directories to process. In practice, almost everything was running on a single thread. The fix required rethinking the entire approach — instead of threads dying prematurely, they now wait intelligently using condition variables and notifications. They only exit when there's genuinely nothing left to do. A whole new layer of complexity, but the right kind.

The bigger unsolved problem is performance on large directories. Unlike list or inspect, copy can't cache anything — every file operation requires constant syscalls, and syscalls are expensive. The more files, the more it hurts. I have some ideas for specific cases, but I'm not interested in point solutions. I want something more fundamental before I consider the problem addressed.

--preserve is intentionally not implemented yet. Preserving metadata means more syscalls, and adding that on top of an already expensive operation didn't make sense until I find a way to reduce that cost first.

Kron is still being built from the void.
github.com/TheNobelVoid/kron

Kron Devlog #1: A Simple Flag Bug, a New Command, and a Performance Problem

Jeremy Nobel — Sat, 21 Mar 2026 00:57:00 +0000

There's a certain kind of bug that doesn't make you feel stupid because it's complex. It makes you feel stupid precisely because it isn't.
That was my day today.

I'm building Kron — a multifunctional CLI tool for file inspection and manipulation, written in C++20 with zero external dependencies. I'm currently working on a new command: copy. But before I could write a single line of it, I had to deal with the global --version and --help flags first.

The flag bug
The logic was simple: --version and --help need to be handled before any command is dispatched. If someone runs kron --version alone, the program should print the version and exit — not throw an error because no command was provided.

I overcomplicated it at first, trying to figure out the right place to intercept these flags in the pipeline. Eventually I found it: right after options are normalized, before command processing begins. That way the flow gets cut early and nothing downstream runs.

--help was similar, with one extra condition: if a command is provided alongside --help, it should print that command's help and stop execution. Clean, simple.

Then I spent way too long debugging why a command with no options wasn't executing at all. The culprit? A stray else in the dispatch logic that should have been removed. It was blocking execution entirely for commands called without options. Classic.

The copy command
The core data extraction logic in copy is similar to what inspect already uses, which made the foundation straightforward. The standard functionality is all there — recursive copy, force overwrite, skip existing files, preserve metadata, dry run, verbose output.

But I want copy to do something the traditional tool doesn't: filter what gets copied. By extension, by file size, by date, by permissions. So instead of blindly copying everything, you can tell Kron exactly what you want moved and what should stay behind. More control, less cleanup.

The performance problem
list and inspect already use multithreading for data collection, and the filtering logic is as optimized as my current knowledge allows. Both commands handle simple workloads well.

The bottleneck is printing. When dealing with large volumes of data, output slows down noticeably. I haven't solved this yet — but it's on the table. If anyone has dealt with high-volume terminal output in C++ and has ideas, I'm genuinely open to them. Drop a comment or open issue #3 on GitHub.

Hoping to have copy ready before the end of the week.
github.com/TheNobelVoid/kron

Why I Build CLI Tools with Zero External Dependencies

Jeremy Nobel — Fri, 20 Mar 2026 02:56:45 +0000

For a long time I wasn't really programming. My university degree covered a lot of things — but actual building wasn't one of them. Professors mentioned AI, algorithms, low-level concepts. They'd describe what something did, roughly how it worked underneath. But nobody told you the truth: building it isn't just calling a couple of functions and moving on.
There was always something deeper below.

At some point I decided to stop waiting and start digging.
I want to be clear about something: this isn't about dismissing other languages or tools. If I'm working on a company project or something with deadlines and other people depending on it, I'll adapt. I'll use whatever makes sense. But when the project is mine — when nobody is waiting, when the only requirement is that I understand every single line — I build from scratch.

Everything. My own tokenizer. My own CLI parser. My own command executor. Not because libraries don't exist. They do, and some of them are excellent. But because there's a difference between using a tool and understanding what the tool is made of.

I do make one exception: the C++ STL. And honestly, if I followed my own logic all the way down I'd end up punching cards or writing assembly. There's a floor somewhere. The STL is mine.

The real reason I build this way has nothing to do with efficiency or philosophy. It's simpler than that.

Kron — my CLI tool for file inspection and manipulation — made me suffer. It kept me awake. I'd lie down and instead of sleeping I'd be running solutions in my head, thinking about architecture, about what I'd broken, about what I could do better. It gave me something that years of coursework never did: the feeling that I was actually building something.

It brought me back to programming.
Kron is just the beginning.

Do you build from scratch or prefer existing tools? What made you choose your approach?