Live data from Hacker News

Modern Linux tools

ikrima.dev

171–180 of 219 posts

Re: Modern Linux tools

#171
post #53

Every time such a list is posted, it tends to generate a lot of debate, but I do think there is at least 2 tools that are really a good addition to any terminal : `fd`: first I find that the argument semantic is way better than `find`, but that is more a bonus than a real killer feature. Now, it being much, much faster than `find` on most setup, I would consider a valuable feature. But the killer feature for me is th…

> Like, searching for `isLoading` on my frontend (~3444 files) is instant with rg (less than 0.10s) but takes a few minutes with grep. grep will try to search inside .git. If your project is Javascript, it might be searching inside node_modules, or .venv if Python. ripgrep ignores hidden files, .gitignore and .ignore. You could try using `git grep` instead. ripgrep will still be faster, but the difference won't be as…

While sometimes a plausible explanation for huge differences in search time, there are at least two other possible explanations.

First is parallelism. If you do `grep -r`, most greps (like GNU grep and BSD grep and the one found on macOS) will not use parallelism. ripgrep will. This could easily account for a large perceived difference in search time.

Second is the grep implementation. While GNU grep is generally considered to be quite fast on its own (especially in the POSIX locale), many other grep implementations are not. And indeed, they may be extraordinarily slow. For example, consider this comparison between FreeBSD grep (on macOS) and ripgrep (I clipped the `time` output for the `wc -l` command, which I just used to make the output smaller):

    $ time rg -j1 -uuu -w -g '*.c' '[A-Z]{2}_RESUME' | wc -l
          22

    real    0.769
    user    0.105
    sys     0.662
    maxmem  5104 MB
    faults  0


    $ time LC_ALL=C grep -E -w -r --include '*.c' '[A-Z]{2}_RESUME' | wc -l
          22

    real    15.830
    user    14.576
    sys     1.253
    maxmem  2224 MB
    faults  1

    $ time LC_ALL=C ggrep -E -w -r --include '*.c' '[A-Z]{2}_RESUME' | wc -l
          22

    real    1.148
    user    0.206
    sys     0.767
    maxmem  2784 MB
    faults  1
This is just a straight up comparison that removes things like parallelism and filtering completely. This is purely algorithms. And the difference is an order of magnitude.

Any one of these explanations, on its own, can account for huge differences in perceived performance. It's not really possible to know which one (perhaps even all 3) is relevant from pithy descriptions of ripgrep being so much faster than other tools.

Version info for above commands:

    $ rg --version
    ripgrep 14.1.1 (rev bb88a1ac45)

    features:+pcre2
    simd(compile):+NEON
    simd(runtime):+NEON

    PCRE2 10.45 is available (JIT is available)

    $ grep -V
    grep (BSD grep, GNU compatible) 2.6.0-FreeBSD

    $ ggrep -V
    ggrep (GNU grep) 3.12
    Packaged by Homebrew
    Copyright (C) 2025 Free Software Foundation, Inc.
    [.. snip ..]

Re: Modern Linux tools

#172
post #35

Earlier quoted context omitted.

One of the reasons I really like Nix, my setup works basically everywhere (as long the host OS is either Linux or macOS, but those are the only 2 environments that I care). I don't even need root access to install Nix since there are multiple ways to install Nix rootless. But yes, in the eventual case that I don't have Nix I can very much use the classic tools. It is not a binary choice, you can have both.

are you going to install nix in a random docker container?

That is why I said that I still know how to use basic Unix tools. If I am debugging something so frequently that I feel that I need to install my Nix configuration just to get productive there is something clearly going wrong.

For example, in $CURRENT_JOB we have a bastion host that gives access to the databases (not going to discuss if this is a good idea or not, this is how my company does). 90% of time I can do whatever I need just with what the bastion host offers (that doesn't have Nix), if I need to do further analysis I can copy some files between the bastion host and my computer to do further analysis.

Re: Modern Linux tools

#173

Earlier quoted context omitted.

are you going to install nix in a random docker container?

mise is a good middle ground.

I am not sure how mise would be a "good middle ground" compared to Nix, considering it is really easy to get a static binary version of Nix. Nowadays it even works standalone without creating a `/nix` directory, you can simply run the binary and it will create everything you need in `~/.local/state/nix` if I remember correctly. And of course Nix is way more powerful than mise.

Re: Modern Linux tools

#174
post #15

Modern doesn't always mean better. A better replacement for mplayer was mpv, and in some cases mplayer was faster than mpv (think about legacy machines). - bat it's a useless cat. Cat concatenates files. ANSI colour breaks that. - alias ls='ls -Fh' , problem solved. Now you have * for executables, / for directories and so on. - ncdu it's fine, perfect for what it does - iomenu it's much faster than fzf and it almost…

> bat it's a useless cat I can't see bat as a "useless cat" or a replacement for cat except for reading source code in the terminal. It's more a like a less with syntax highlight or a read-only vim.

Is there a stand-alone syntax highlighting cli tool? It sounds like we need one if one doesn't exist yet. Something that would take an input stream, a language parameter, and maybe an optional color syntax highlighting config or something. It would be something that can be tacked onto any command so the final output has the appropriate syntax highlighting.

Re: Modern Linux tools

#175

Earlier quoted context omitted.

> apt-get/pacman/dnf/brew install If only it were so simple. Not every tool comes from a package with the same name, (delta is git-delta, "z" is zoxide, which I'm not sure I'd remember off the top of my head when installing on a new system). On top of that, you might not like the defaults of every tool, so you'll have config files that you need to copy over or recreate (and hopefully sync between the computers where…

Chezmoi makes this really easy: https://www.chezmoi.io/

I only skimmed through the website, but it looks like it only does dotfiles. So I'd need to maintain a separate script to keep my packages in sync. And a script with install commands wouldn't be enough - maybe I decided to stop using abcxyz, I'd like for the script to remove it. Versioning between the package and the dotfile can also sometimes be an issue.

Re: Modern Linux tools

#176
post #9

These may be objectively superior (I haven't tested), but I have come to realize (like so many others) that if you ever change your OS installation, set up VMs, or SSH anywhere, preferring these is just an uphill battle that never ends. I don't want to have to set these up in every new environment I operate in, or even use a mix of these on my personal computer and the traditional ones elsewhere. Learn the classic to…

Some people spend the vast majority of their time on their own machine. The gains of convenience can be worth it. And they know enough of the classic tools that it's sufficient in the rare cases when working on another server. Not everybody is a sysadmin manually logging into lots of independent, heterogeneous servers throughout the day.

Also that workflow of SSH'ing into a machine is becoming rarer. Nowadays systems are so barren they don't even have SSH.

Re: Modern Linux tools

#177

Earlier quoted context omitted.

Some people spend the vast majority of their time on their own machine. The gains of convenience can be worth it. And they know enough of the classic tools that it's sufficient in the rare cases when working on another server. Not everybody is a sysadmin manually logging into lots of independent, heterogeneous servers throughout the day.

Also that workflow of SSH'ing into a machine is becoming rarer. Nowadays systems are so barren they don't even have SSH.

Someone might have ssh access, just not you :) VPS' will still be VPSing, even though people tend to go for managed Kubernetes or whatever the kids are doing today. But if you're renting instances/"machines", then you're most likely still using ssh.

Re: Modern Linux tools

#178

Earlier quoted context omitted.

Sounds like the problem you have here is that `grep` is aliased to `ripgrep`. ripgrep isn't intended to be a drop-in replacement for POSIX grep, and the subjectively easier usage of ripgrep can never replace grep's matureness and adoption. Note: if you want to make ripgrep not do .gitignore filtering, set `RIPGREP_CONFIG_PATH` to point to a config file that contains `-uu`. Sources: - https://github.com/BurntSushi/rip…

So I stand corrected. I did indeed use ripgrep as a drop-in replacement. That's on me!

I've been playing around with this over the years and this is what I put in my .rgrc:

--smart-case --no-messages --hidden --ignore-vcs

and then point to it with

.zshenv 3:export RIPGREP_CONFIG_PATH="$HOME/.rgrc"

Not perfect and sometimes I reach for good old fashioned escaped \grep but most of the time it's fine.

Re: Modern Linux tools

#179

Earlier quoted context omitted.

Some people spend the vast majority of their time on their own machine. The gains of convenience can be worth it. And they know enough of the classic tools that it's sufficient in the rare cases when working on another server. Not everybody is a sysadmin manually logging into lots of independent, heterogeneous servers throughout the day.

Also that workflow of SSH'ing into a machine is becoming rarer. Nowadays systems are so barren they don't even have SSH.

That's a cute thought not grounded in reality.

The infra may be cattle but debugging via anal probe err SSH is still the norm.

Re: Modern Linux tools

#180

Earlier quoted context omitted.

Ed is the standard text editor.

And not installed by default in many distros. FML.

> And not installed by default in many distros. FML.

ed (pronounced as distinct letters, /ˌiːˈdiː/)[1] is a line editor for Unix and Unix-like operating systems. It was one of the first parts of the Unix operating system that was developed, in August 1969.[2] It remains part of the POSIX and Open Group standards for Unix-based operating systems

so it is a bug in those distros.

Post reply on HN