Modern Linux Tools Part 1: Why Bother, and How I Tested

I found eza recently, a modern replacement for ls, and it started a question. There is a whole set of newer command-line tools that claim to improve on the classic ones. Are they actually better, or do they just look better in a screenshot?

This series answers it by testing. I installed 18 of these tools on a clean Debian 13 virtual machine, ran each one beside the tool it replaces on the same data, and wrote down what happened, including where the old tool won.

The parts

1. This part: why, and how I tested.
2. Files: eza, fd, bat, dust and duf against ls, find, cat, du and df.
3. Search and replace: ripgrep and sd against grep and sed.
4. Navigation and history: zoxide, fzf and atuin.
5. Network: gping, trippy and xh against ping, mtr and curl.
6. Data and git: jq, gojq, delta, lazygit and tealdeer.
7. The verdict and an install script.

Why bother

The classic tools are everywhere. grep, find and sed are on every Linux machine and in every script, so a replacement has to be better by enough to justify installing it, learning it, and remembering it is not there on the next server.

The newer tools make three promises. They are faster, they have better defaults, and their output is easier to read. All three are testable.

The ground rules

A clean machine. Debian 13 (trixie) on a VM with 2 vCPUs, 2 GB of RAM and kernel 6.12.115, fully updated before I installed anything. It has a firewall that accepts SSH only from my local network, and key-only login.

Packages only. Every tool came from the Debian repositories with apt. No cargo, no curl | sh, no tool binaries from GitHub. If a tool is not packaged, I left it out. That removed bandwhich, doggo, jless and fx from my original list. A packaged tool gets security updates with the rest of the system, and that matters for anything you install on a server. There is one exception, and it is not a tool: atuin needs a small shell helper called bash-preexec that Debian does not package, and Part 4 explains why.

The same data for both tools. The file tools ran on one tree of 105,003 files built from a fixed random seed. The search tools used that tree plus a 105 MB file. Network tools ran against public resolvers, and the HTTP client against a local test server.

Real timings. I used hyperfine, with warm caches and a warm-up run. The VM is small, so read the numbers as ratios and not as absolute speeds. Where a result depends on the file shape or the type of search, I say so, and I do not turn one benchmark into a general claim.

Check the output, not only the clock. A faster tool that returns different results is not faster. In several places the two tools gave different answers because their defaults differ, and I checked each of those until I knew why.

Report the losses. In this series the old tool won several tests. ls beat eza recursively, cat beat bat by a wide margin, grep beat ripgrep on some single-file searches, and curl beat xh on start-up time. The point is to find what is worth using, not to promote a list.

What I did not do

I did not test every option of every tool. I ran what an everyday user would run, then checked whatever looked odd. If you use a feature I did not cover, test it yourself before you rely on it.

I also did not test on other distributions or other shells. Package names, versions and the behaviour of the shell integrations are from Debian 13 and bash.

Start here

If you want the short version, jump to Part 7 for the verdicts and an install script. If you want the evidence, start with Part 2.