I used htop for many years because it seemed more accessible to top, until I found that it didn't display kernel threads by default and when troubleshooting a load issue top found exactly what I needed when htop was generally unhelpful. Since then I've returned to top because it has everything I need and really is time tested; the htop/btop/whatever UI in my opinion is just theatrics.
Modern Linux tools
201–210 of 219 posts
Re: Modern Linux tools
#202Earlier quoted context omitted.
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.
This was strictly in reply to the direct parent commenter, who mentioned fish_history and extolled fzf's shell integrations. I often use fzf for mini-TUIs, or pipe to it.
The OP list is significantly cheapened by the various ls alternatives.
Re: Modern Linux tools
#203`jq` is pretty much the only one solving a real problem that no existing tool solves IMHO. Most of the others are rewrites for some opinionated 'better' (faster, syntax highlighting, written in Rust or whatever...).
Re: Modern Linux tools
#204As someone who logs into hundreds of servers in various networks, from various customers/clients, there is so little value in using custom tooling, as they will not be available on 90% of the systems. I have a very limited set of additional tools I tend to install on systems, and they are in my default ansible-config, so will end up on systems quickly, but I try to keep this list short and sweet. 95% of the systems I…
As someone who works back and forth on Windows and Linux all day, its handy to have excellent cross-platform tools like ripgrep.
Re: Modern Linux tools
#205I basically live in the terminal. However, every single one of these tools offers a solution to a problem that I don't have; aren't installed on my system; and mysteriously have many tens of thousands of github stars. I genuinely don't know what is going on here.
Out of curiosity, how would you recursively grep files ignoring (hidden files [e.g., `.git`]), only matching a certain file extension? (E.g., `rg -g '*.foo' bar`.) I use the command line a lot too and this is one of my most common commands, and I don't know of an elegant way to do it with the builtin Unix tools. (And I have basically the same question for finding files matching a regex or glob [ignoring the stuff I o…
`grep bar */.foo~.git/`
Is that a zshism?
Re: Modern Linux tools
#206I 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…
Except that ripgrep isn't actually a drop-in replacement for grep as it behaves differently. It is a nice program don't get me wrong, but it is not interchangeable with grep.
Re: Modern Linux tools
#207Earlier quoted context omitted.
I find the opposite to be true. Most of these are really just reinventing the wheel of foundational GNU tools that are really powerful provided one has spent some time on them.
It's like people dont even know why people use or want these "modern" tools. It's called "sane defaults", and improved UX. Those "foundational GNU tools" just suck, sure, people are familiar with them and they are everywhere, but they just plain suck. For many common operations you'd want to do by default with grep/find and so on, you have to type mountains of random gibberish to get it done. And that random gibberis…
If these improvements are worth it they should just be merged into the coreutils. Last I checked they’re open source.
Re: Modern Linux tools
#208i wish there was an additional column in the table, that says "what problem does it solve". oh, and 'it's written in rust' does not count.
It seems for most of them, the primary goal is improved UX.
Re: Modern Linux tools
#209Link text in dark mode is really hard to read/see.
Re: Modern Linux tools
#210Earlier quoted context omitted.
That is what the post you responding to is saying
I’m still responding to the first sentence. It’s not a differentiator, even to smart engineers who understand the programming language in question (e.g., Go or Rust). Whenever an engineer leads with the programming language, I know that it’s just their favorite. You can write great Python, Ruby, Go or Rust, or you can write crappy Python, Ruby, Go, or Rust. Yes, some languages make more sense for certain environments…
TypeScript is the one true language that will bind them all in servitude.