Live data from Hacker News

Modern Linux tools

ikrima.dev

181–190 of 219 posts

Re: Modern Linux tools

#181
post #36

Earlier quoted context omitted.

“It’s written in Rust” Actual LOL. Indeed. I was working for a large corporation at one point and a development team was explaining their product. I asked what its differentiators were versus our competitors. The team replied that ours was written in Go. #faceplam

The Rust rewrites can become tiresome, they have become a meme at this point, but there are really good tools there too. An example from my personal experience: I used to think that oxipng was just a faster optipng. I took a closer look recently and saw that it is more than that. See: https://op111.net/posts/2025/09/png-compression-oxipng-optip...

> but there are really good tools there too.

That's the problem. How good they are ? Who can tell ? The basic UNIX tools didn't come in "one day" like most of these "rust tools".

Re: Modern Linux tools

#182
post #99

Earlier quoted context omitted.

What's the relevance of these "as someone who ..." posts? Nobody cares that these tools don't happen to fit into your carefully curated list of tools that you install on remote computers. You can install these on your local computer to reap some benefits.

It's the bean soup theory ("what if I don't like beans") in action.

Which I believe is an effect of main-character-syndrome or just good ol’ classical narcissism

Re: Modern Linux tools

#183

Earlier quoted context omitted.

You can write slow unmaintainable brittle garbage in any language though. So even if your competition is literally written in Bash or whatever you should still say what your implementation actually does better - and if it's performance, back it up with something that lets me know you have actually measured the impact on real world use cases and are not just assuming "we wrote it in $language therefore it must be fast…

> You can write slow unmaintainable brittle garbage in any language though. Sure. You can drive really slowly in a sports car. But if you're looking for travel options for a long distance journey are you going to pick the sports car or the bicycle. Also I have actually yet to find slow unmaintainable brittle garbage written in Go or Rust. I'm sure it's possible but it's vastly less likely.

> Also I have actually yet to find slow unmaintainable brittle garbage written in Go or Rust. I'm sure it's possible but it's vastly less likely.

Citation needed. /s

Re: Modern Linux tools

#184

Earlier quoted context omitted.

Some of this just makes me think that they are compared against the wrong tool though. E.g. > cat clone with syntax highlighting and git integration doesn't make any sense because cat is not really meant for viewing files. You should be comparing your tool with the more/less/most family of tools, some of which can already do syntax highlighting or even more complex transforms.

Yup, I made that same point in another comment. Out of interest, though, how do you get syntax highlighting from any of those pagers? None of them give it to me out of the box.

Pipe it through vim ? /s

Re: Modern Linux tools

#185
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…

> A better replacement for mplayer was mpv

YMMV.

Re: Modern Linux tools

#186
post #14

I 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.

The list includes jq. I’d frankly love to never have a problem that jq solves, but, well, here we are.

ripgrep is something I have installed, but use only via text editor integrations. fzf is nice for building ad-hoc TUIs. fd may make sense (I’m told it’s faster than find), but I already know enough find.

The “next gen ls” family of tools in the article is baffling.

Re: Modern Linux tools

#187
post #14

I 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.

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.

Re: Modern Linux tools

#188

Earlier quoted context omitted.

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.

[deleted]

Re: Modern Linux tools

#189
post #144
post #68

As 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…

Is there any tool or ssh extension that would bring these apps into the remote session? Is something like that possible? Seems like you could conceivablely dump these small file size tools into a temp folder and and use them and that could be automated. Is there a security issue with that? Do any of these tools need more permission than the remote session would have? Maybe the main issue is portability of these apps?…

If you have enough privileges to mount a filesystem on login, that would be one way to do it. If that process requires significant time or extra steps then you probably ought to make that a manual step. I don't think there is a security issue with this approach from the user's perspective, since it is their tools being executed. But if you are an administrator you might have grave objections to allowing random binaries and scripts to be imported into the environment with no audit trail.

Re: Modern Linux tools

#190
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.

[deleted]
Post reply on HN