Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Linux tools

ikrima.dev

Post reply on HN
Print view View original

191–200 of 219 posts

Re: Modern Linux tools

#191

Post by musicale »

0x37 wrote: 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…

> Learn the classic tools, learn them well, and your life will be much easier

not really contradicted by:

> exa: modern replacement for ls/tree, not maintained

Re: Modern Linux tools

#192

Post by VTimofeenko »

samtrack2019 wrote: post #104
kokada wrote: 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?

I've gotten great mileage out of a ttyd-based container that runs bash with nix. Ttyd exposes the shell over web endpoint.

I can just drop it into the environment and pull in tools that I need using nix.

Re: Modern Linux tools

#194

Post by tasuki »

oslem wrote: post #69

I always enjoy these lists. I think most folks out there could probably successfully adopt at least one or two of these tools. For me, that’s ripgrep and jq. The former is a great drop-in replacement for grep and the latter solves a problem I needed solving. I’ll try out a few of the others on this list, too. lsd and dust both appeal to me. I just enjoy seeing others incrementally improve on our collective tool chest…

If I had to choose, my first priority would be fzf, way before rg and jq.

Re: Modern Linux tools

#195

Post by soraminazuki »

BrouteMinou wrote: post #128
tmountain wrote: post #54

Earlier quoted context omitted.

Some are so vastly better that it's worth whatever small inconvenience comes with getting them installed. I know the classic tools very well, but I'll prefer fd and ripgrep every time.

For my part, the day I was confused why "grep" couldn't find some files that were obviously there, only to realize that "ripgrep" is ignoring files in the gitignore, that was the day I removed "ripgrep" of my system. I never asked for such behaviour, and I have no time for pretty "modern" opinions in a base software. Often, when I read "modern", I read "immature". I am not ready to replace my stable base utilities fo…

It's odd how, with every new tool that emerges, some people fixate solely on whether it’s an exact clone of what they already know. They overlook the broader differences and trade-offs, treating anything less than a complete replica down to its quirks as unworthy of anyone's attention. While insults like "immature" are rarely thrown around right away, it's a frustratingly narrow perspective.

Regarding ripgrep: if it's not bug-for-bug compatible with grep, it’s deemed useless. Yet, if it is identical, then why bother using it at all? What kind of logic is that?

Re: Modern Linux tools

#196

Post by soraminazuki »

akho wrote: post #187
qustrolabe wrote: post #151

Earlier quoted context omitted.

You never use fzf? What a tough life in terminal then huh. It's not as useful to run it directly, but pretty much any shell has plugin for fzf support that let's you Ctrl+R to fuzzy search over bash_history (or fish_history or whatever) and Ctrl+T let's you fuzzy search files in current directory.

fish fuzzy matches on Ctrl+R, and on Tab, without fzf.

That's nice, but there's value in a fuzzy finder existing as a standalone tool.

Also if I had to guess, the type of person who criticizes tools like jq, fzf, and ripgrep and struggles to understand some people's need for benchmarking tools like hyperfine would likely disapprove of fish as well.

Re: Modern Linux tools

#197

Post by alextingle »

thiht wrote: post #95
0x37 wrote: 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…

That goes against the UNIX philosophy IMO. Tools doing "one thing and doing it well" also means that tools can and should be replaced when a superior alternative emerges. That's pretty much the whole point of simple utilities. I agree that you should learn the classic tools first as it's a huge investment for a whole career, but you absolutely should learn newer alternatives too. I don't care much for bat or eza, but…

Rust's user unfriendly build paradigm puts me off using a lot of these. Ripgrep is fine when I can install it from a package manager. But if I'm on some weird machine and need to build it then first I have to build rustc, and then it wants to download gigabytes of whatever, just to compile a better 'grep'?

Re: Modern Linux tools

#198

Post by [deleted] »

mprovost wrote: post #49
imcritic wrote: post #39

Earlier quoted context omitted.

IMO this is very stupid: don't let past dictate future. UNIX is history. History is for historians, it should not be the basis that shapes the environment for engineers living in present.

The point is that we always exist at a point on a continuum, not at some fixed time when the current standard is set in stone. I remember setting up Solaris machines in the early 2000s with the painful SysV tools that they came with and the first thing you would do is download a package of GNU coreutils. Now those utils are "standard", unless of course you're using a Mac. And newer tools are appearing (again, finally…

[deleted]

Re: Modern Linux tools

#199

Post by burntsushi »

alextingle wrote: post #197
thiht wrote: post #95

Earlier quoted context omitted.

That goes against the UNIX philosophy IMO. Tools doing "one thing and doing it well" also means that tools can and should be replaced when a superior alternative emerges. That's pretty much the whole point of simple utilities. I agree that you should learn the classic tools first as it's a huge investment for a whole career, but you absolutely should learn newer alternatives too. I don't care much for bat or eza, but…

Rust's user unfriendly build paradigm puts me off using a lot of these. Ripgrep is fine when I can install it from a package manager. But if I'm on some weird machine and need to build it then first I have to build rustc, and then it wants to download gigabytes of whatever, just to compile a better 'grep'?

You don't need to build rustc to build ripgrep. If you are, that's a choice you are making. Cross compilation is a thing. And what weird machine doesn't have a way to install a ripgrep binary anyway? It's pretty much everywhere these days.

Re: Modern Linux tools

#200

Post by leejo »

mprovost wrote: post #143
pjmlp wrote: post #12

Earlier quoted context omitted.

I know well enough my way around vi, because although XEmacs was my editor during the 1990's when working on UNIX systems, when visiting customers there was a very high probability that they only had ed and vi installed on their server systems. Many folks nowadays don't get how lucky they are, not having to do UNIX development on a time-sharing system, although cloud systems kind of replicate the experience.

Ed is the standard text editor.

For those who missed it: https://www.gnu.org/fun/jokes/ed-msg.en.html
Post reply on HN