8 ms·

Modern Linux tools

251 points by randomint64 1y ago

maeln 1y ago
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 the `-x` argument. It allows calling another command on the individual search result, which `find` can also do with `xargs` and co. But `fd` provide a very nice placeholder syntax[0], which remove the need to mess with `basename` and co. to parse the filename and make a new one, and it executes in parallel. For example, it makes converting a batch of image a fast and readable one line : `fd -e jpg -x cjxl {} {.}.jxl` `rg` a.k.a `ripgrep` : Honestly it is just about the speed. It is so much faster than `grep` when searching through a directory, it opens up a lot of possibilities. Like, searching for `isLoading` on my frontend (~3444 files) is instant with rg (less than 0.10s) but takes a few minutes with grep. But there is one other thing that I really like with `ripgrep` and that I think should be a feature of any "modern" CLI tool : It can format its output in JSON. Not that I am a big fan of JSON, but at least it is a well-defined exchange format. "Classic" CLI tool just output in a "human-readable" format which might just happen to be "machine-readable" if you mess with `awk` and `sed` enough. But it makes piping and scripting just that much more annoying and error & bug prone. Being able to output json, `jq` it and feed it to the next tool is so much better and feel like the missing chain of the terminal. The big advantage of the CLI is that it is composable and scriptable by default. But it is missing a common exchange format to pass data, and this is what you have to wrangle with a lot of time when scripting. Having json, never mind all the gripes I have with this format, really join everything together. Also, honorable mention for `zellij` which I find to be a much saner UX-wise alternative to `tmux`, and the `helix` text editor, which for me is neo-vim but with, again, a better UX (especially for beginner) and a lot more battery included feature while remaining faster (IMEX) than nvim with matching plugin for feature-parity. EDIT: I would also add difftastic ( https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic ) which is a syntax aware diff tool. I don't use it much, but it does makes some diff so so much easier to read. [0] https://github.com/sharkdp/fd?tab=readme-ov-file#placeholder-syntax https://github.com/sharkdp/fd?tab=readme-ov-file#placeholder...
- rkomorn 1y ago
  I briefly resisted the notion that fd and ripgrep were useful when a friend suggested them. Then I tried them and it was such a night and day performance difference that they're now immediate installs on any new system I use.
- Izkata 1y ago
  > But the killer feature for me is the `-x` argument. It allows calling another command on the individual search result, which `find` can also do with `xargs` and co. But `fd` provide a very nice placeholder syntax[0], which remove the need to mess with `basename` and co. to parse the filename and make a new one, and it executes in parallel. For example, it makes converting a batch of image a fast and readable one line : `fd -e jpg -x cjxl {} {.}.jxl` That was inherited from find, it has "-exec". Even uses the same placeholder, {}, though I'm not sure about {.}
  - maeln 1y ago
    `find` only support `{}`, it does not support `{/}`, `{//}`, `{.}` etc, which is why you often need to do some parsing magic to replicate basic thing such has "the full path without the extension`, `only the filename without the extension` etc
    - deleted 1y ago
      [deleted]
    - 149765 1y ago
      I think GNU parallel has similar placeholders, but I do prefer to just use `fd`.
      - maeln 1y ago
        I think it does, and tbf, `fd` is bascially `find` + `parallel`, but I do find that it is nice that it is just one tool and I don't need GNU parrallel :)
  - deleted 1y ago
_ZeD_ 1y ago
the second item is exa modern replacement for ls/tree, not maintained "not maintained" doesn't smell "modern" to me...
- arccy 1y ago
  like good open source, it's now forked by a community instead of having only a single maintainer eza: https://github.com/eza-community/eza https://github.com/eza-community/eza
  - abenga 1y ago
    The README has an ad at the top. Yeeeah, nope.
    - CaptainOfCoit 1y ago
      For a cloud-based terminal emulator that heavily focuses on AI none the less. And they have the stomach to call it "for developers".
    - selectnull 1y ago
      The tool itself has no ads. What's wrong with a README having an ad?
      - _ZeD_ 1y ago
        everything.
        selectnull 1y ago
        So much talk about paying open source developers and when someone actually does something about it and try to make some money, it's again not good enough. Damned if you do and damned if you don't.
        esafak 1y ago
        Why don't you sponsor the project so they can take it down?
bieganski 1y ago
i 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.
- oneeyedpigeon 1y ago
  Many of the entries do include this detail — e.g. "with syntax highlighting", "ncurses interface", and "more intuitive". I agree that "written in rust", "modern", and "better" aren't very useful!
  - account42 1y ago
    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.
    - oneeyedpigeon 1y ago
      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.
      - hulitu 1y ago
        Pipe it through vim ? /s
- drob518 1y ago
  “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
Otek 1y ago
This is 2023 article. As with most “modern tools” half of them probably already have some newer, shinier and more trendy replacements
- oneeyedpigeon 1y ago
  There's a lot of tools here. Half still leaves plenty of value.
- antegamisou 1y ago
  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.
  - Johanx64 1y ago
    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 gibberish isn't something that rolls of your tongue either, thus at minimum you'd define truckload of aliases. OR you can use a tool(s) that has marginally "sane defaults" and marginally sane UX out of the box. It really isn't that complicated. This has nothing to do with "rust".
    - esafak 1y ago
      Some people just like torturing themselves with spells like perl -ne 'map{$h{lc$_}++}/(\w+)/g;END{map{print"$h{$_} $_\n"}sort{$h{$b}<=>$h{$a}}keys%h}'
    - antegamisou 1y ago
      Sounds like a skill issue.
    - wpm 1y ago
Scotrix 1y ago
would be good to have an indicator if it’s available with your distro by default or what package you’ll need to install it since all tools are only as useful as available they are…
0x37 1y ago
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 tools, learn them well, and your life will be much easier.
- andai 1y ago
  I wanted to say we should just stick with what Unix shipped forever. But doesn't GNU already violate that idea?
  - drob518 1y ago
    Well, even “Unix” had some differences (BSD switches vs SysV switches). Theoretically, POSIX was supposed to smooth that out, but it never went away. Today, people are more likely to be operating in a GNU Linux environment than anything else (that just a market share fact, not a moral judgement, BSD lovers). Thus, for most people, GNU is the baseline.
  - imcritic 1y ago
    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.
    - mprovost 1y ago
      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) and the folk saying to just stick with the GNU tools because they're everywhere ignore all of the effort that went into making that (mostly) the case. So yes, let's not let the history of the GNU tools dictate how we live in the present.
snide 1y ago
Small note that a lot of these tool makers allow sponsorship on GitHub. I use bat / fd almost every day. Happy to support https://github.com/sponsors/sharkdp#sponsors https://github.com/sponsors/sharkdp#sponsors
fergie 1y ago
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.
- oneeyedpigeon 1y ago
  The core Unix toolset is so good, that you can easily get by with it. Many of these tools are better, but still not necessary, and they certainly aren't widely available by default.
- account42 1y ago
  They tend to be popular with the "rewrite it in rust/go" crowd as far as I can tell. Or in other words, you are no longer part of the cool kids.
  - anthk 1y ago
    I've seen an online radio player in Go which was unusabiily slow on my Atom n270 due to the badly coded ANSI audio visualization FX' using floating math. Meanwhile a with Cava or another visualizer and mpd+mpc I could do the same using 200x less resources.
- maeln 1y ago
  > 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. I basically live in my music library. However, every single pop artist offers songs that I don't like, are not in my library, and mysteriously have many millions of albums sold. I genuinely don't know what is going on here. Joking aside, have you ever tried to use some of these tools ? I use to not understand why people where using vim until I really tried.
  - fergie 1y ago
    > Joking aside, have you ever tried to use some of these tools No. > I use to not understand why people where using vim until I really tried. There's your problem. I respectfully suggest installing Emacs.
anthk 1y ago
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 works the same - jq it's fine, it's a good example on a new Unix tool - micro it's far slower than even vim - instead of nnn, sff https://github.com/sylphenix/sff with soap(1) (xdg-open replacement) from https://2f30.org create a mega fast environment. Add MuPDF and sxiv, and nnn and friends will look really slow compared to these. Yes, you need to set config.h under both sff and soap, but they will run much, much faster than any Rust tool on legacy machines.
- oneeyedpigeon 1y ago
  > bat it's a useless cat. Cat concatenates files. ANSI colour breaks that. It's useless as a cat replacement, I agree. The article really shouldn't call it that, although the program's GitHub page does self-describe it as "a cat clone". It's more of a syntax highlighter combined with a git diff viewer (I do have an issue with that; it should be two separate programs, not one).
  - mcswell 1y ago
    I have two uses for 'cat': 1) Piping the contents of some file into a process. 2) Showing the contents of some short file. Now (1) is better done with redirection (< or >). The only time I use cat is when I'm testing some pipeline where I only want a few lines of input, so I use 'head' or something similar. Once I have the pipeline working right, I edit the command line to replace 'head' with 'cat'. Easier than re-arranging whole words. And it's rare that (2) is the right solution--too often I find that the file was longer than I thought, and I have to use 'more' (actually 'less'). So a replacement for 'cat' that does color coding sounds pretty much useless to me.
    - oneeyedpigeon 1y ago
PaulKeeble 1y ago
duf is pretty good for drive space, has some nice colours and graphs. But its also not as useful for feeding into other tools. btop has been pretty good for watching a machine to get an overview of everything going on, the latest version has cleaned up how the lazy CPU process listing works. zoxide is good for cding around the system to the same places. It remembers directories so you avoid typing full paths.
ed_blackburn 1y ago
I’m on a Mac, and some of the default tooling feels dated: GNU coreutils and friends are often stuck around mid-2000s versions. Rather than replace or fight against the system tools, I supplement them with a few extras. Honestly, most are marginal upgrades over what macOS ships with, except for fzf, which is a huge productivity boost. Fuzzy-finding through my shell history or using interactive autocompletion makes a noticeable difference day to day.
- MontyCarloHall 1y ago
  >some of the default tooling feels dated: GNU coreutils and friends are often stuck around mid-2000s versions That’s because they’re not GNU coreutils, they’re BSD coreutils, which are spartan by design. (FWIW, this is one of my theories for why Linux/GNU dominated BSD: the default user experience of the former is just so much richer, even though the system architecture of the latter is arguably superior.)
demetris 1y ago
Many are available on Windows too. I know I have hyperfine, fd, and eza on my Windows 11, and maybe some more I cannot remember right now. They are super easy to install too, using winget.
foofoo12 1y ago
Make sure to check out f2, the batch renaming CLI tool. It's perfectly honed and lubricated magic: https://github.com/ayoisaiah/f2 https://github.com/ayoisaiah/f2 Got featured here on HN few weeks ago.
sigio 1y ago
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 manage are debian or ubuntu, so they will use mostly the same baseline, and I then add stuff like ack, etckeeper, vim, pv, dstat.
- arminiusreturns 1y ago
  Another reason emacs as an OS (not fully, but you know) is such a great way to get used to things you have on systems. Hence the quote: "GNU is my operating system, linux is just the current kernel". As a greybeard linux admin, I agree with you though. This is why when someone tells me they are learning linux the first thing I tell them is to just type "info" into the terminal and read the whole thing, and that will put them ahead of 90% of admins. What I don't say is why: Because knowing what tooling is available as a built-in you can modularly script around that already has good docs is basically the linux philosophy in practice. Of course, we remember the days where systems only had vi and not even nano was a default, but since these days we do idempotent ci/cd configs, adding a tui-editor of choice should be trivial.
  - e3bc54b2 1y ago
    > we remember the days where systems only had vi and not even nano was a default What are you talking about? I'm still living those days in modern day AWS with latest EC2 machines!
- twic 1y ago
  "servers" is the key word here. Some of the tools listed on that page are just slightly "improved" versions of common sysadmin utilities, and indeed, those are probably not worth it. But some are really development tools, things that you'd install on the small number of machines where you do programming. Those might be. The ones that leap out at me are ripgrep (a genuinely excellent recursive grepper), jq (a JSON processor - there is no alternative to this in the standard unix toolkit), and hyperfine (benchmarking).
oslem 1y ago
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. Even if the new tool isn’t of use to me, I appreciate the work that went into it. They’re wonderful tools in their own right. Often adding a few modern touches to make a great tool just a little bit better. Thank you to those who have put in so much effort. You’re making the community objectively better.
- arminiusreturns 1y ago
  I think many of us linux admins have such a list. Mine in particular is carefully crafted around GPL-izing my stack as much as possible. I really like the format of this ikrima.dev one though! The other stuff is great too, worth a peruse.
- tasuki 1y ago
  If I had to choose, my first priority would be fzf, way before rg and jq.
- atiedebee 1y ago
  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.
Symmetry 1y ago
tldr is an incredible tool and 95% of the time I'll quickly find what I'm looking for there instead of having to search through the man page.
twic 1y ago
I haven't tried delta, but for diffs i swear by difftastic: https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/ It's a huge improvement over purely character-based diffs.
bandrami 1y ago
Isn't baobab almost 30 years old?
oniony 1y ago
qq should be on this list. It's like jq but works with multiple file formats, including JSON, YAML, XML, &c. and has a really cool interactive TUI mode. https://github.com/JFryy/qq https://github.com/JFryy/qq
- mcswell 1y ago
  THAT looks like something worthwhile; I'll be looking into it. I was going to top-post that the Unix/Linux command line tools were designed back in the day when data was pretty much line-oriented, e.g. one database record per line. Since then XML, and more recently JSON, have been invented, and tools like grep and sed just don't work for those formats. But you ninja'd me, sort of.
- esafak 1y ago
  Did you try https://github.com/TomWright/dasel https://github.com/TomWright/dasel ?
roger_ 1y ago
I kinda wish there was a modern *suite* of improved tools, developed by one team with consistent designs (parameters, colors, tables, etc.)
- gxonatano 1y ago
  Nushell.
tomxor 1y ago
btop is a worthy and missing contender. It looks quite fancy but I actually like it more for it's functionality, particularly it's tree view for navigating the processes list. I'm not a big fan of full multicolor in these kinds of tools and so appreciate how easy it is to flip to grey scale mode from the built in colour schemes (even from the TUI settings menu).
seplox 1y ago
I'd like to read this list, but the color scheme is among the least accessible that I've ever come across. Dark, greyish-blue text with dark, bluish-grey highlighting over a dark grey background. Wow. If any fledgling designers are here, then take note and add this to your list of examples to avoid.
h4ch1 1y ago
I personally prefer btop [0] over gtop. Not written in js is kind of a plus. [0] https://github.com/aristocratos/btop https://github.com/aristocratos/btop
commandersaki 1y ago
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.
doktorn 1y ago
`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...).
tracker1 1y ago
Link text in dark mode is really hard to read/see.
stormed 1y ago
Nothing screams modern Linux more than having an unmaintained replacement for ls.
gxonatano 1y ago
While folks were building improved ls, cat, and so on, and jq for manipulating JSON data, Nushell has been happily doing all this in a consistent way and making it easier, to boot. I'm surprised to see Nushell missing from this list.

251 points by randomint64 1y ago

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 the `-x` argument. It allows calling another command on the individual search result, which `find` can also do with `xargs` and co. But `fd` provide a very nice placeholder syntax[0], which remove the need to mess with `basename` and co. to parse the filename and make a new one, and it executes in parallel. For example, it makes converting a batch of image a fast and readable one line : `fd -e jpg -x cjxl {} {.}.jxl` `rg` a.k.a `ripgrep` : Honestly it is just about the speed. It is so much faster than `grep` when searching through a directory, it opens up a lot of possibilities. Like, searching for `isLoading` on my frontend (~3444 files) is instant with rg (less than 0.10s) but takes a few minutes with grep. But there is one other thing that I really like with `ripgrep` and that I think should be a feature of any "modern" CLI tool : It can format its output in JSON. Not that I am a big fan of JSON, but at least it is a well-defined exchange format. "Classic" CLI tool just output in a "human-readable" format which might just happen to be "machine-readable" if you mess with `awk` and `sed` enough. But it makes piping and scripting just that much more annoying and error & bug prone. Being able to output json, `jq` it and feed it to the next tool is so much better and feel like the missing chain of the terminal. The big advantage of the CLI is that it is composable and scriptable by default. But it is missing a common exchange format to pass data, and this is what you have to wrangle with a lot of time when scripting. Having json, never mind all the gripes I have with this format, really join everything together. Also, honorable mention for `zellij` which I find to be a much saner UX-wise alternative to `tmux`, and the `helix` text editor, which for me is neo-vim but with, again, a better UX (especially for beginner) and a lot more battery included feature while remaining faster (IMEX) than nvim with matching plugin for feature-parity. EDIT: I would also add difftastic ( https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic ) which is a syntax aware diff tool. I don't use it much, but it does makes some diff so so much easier to read. [0] https://github.com/sharkdp/fd?tab=readme-ov-file#placeholder-syntax https://github.com/sharkdp/fd?tab=readme-ov-file#placeholder...

rkomorn 1y ago
I briefly resisted the notion that fd and ripgrep were useful when a friend suggested them. Then I tried them and it was such a night and day performance difference that they're now immediate installs on any new system I use.
Izkata 1y ago
> But the killer feature for me is the `-x` argument. It allows calling another command on the individual search result, which `find` can also do with `xargs` and co. But `fd` provide a very nice placeholder syntax[0], which remove the need to mess with `basename` and co. to parse the filename and make a new one, and it executes in parallel. For example, it makes converting a batch of image a fast and readable one line : `fd -e jpg -x cjxl {} {.}.jxl` That was inherited from find, it has "-exec". Even uses the same placeholder, {}, though I'm not sure about {.}
- maeln 1y ago
  `find` only support `{}`, it does not support `{/}`, `{//}`, `{.}` etc, which is why you often need to do some parsing magic to replicate basic thing such has "the full path without the extension`, `only the filename without the extension` etc
  - deleted 1y ago
    [deleted]
  - 149765 1y ago
    I think GNU parallel has similar placeholders, but I do prefer to just use `fd`.
    - maeln 1y ago
      I think it does, and tbf, `fd` is bascially `find` + `parallel`, but I do find that it is nice that it is just one tool and I don't need GNU parrallel :)
- deleted 1y ago

_ZeD_ 1y ago

the second item is exa modern replacement for ls/tree, not maintained "not maintained" doesn't smell "modern" to me...

arccy 1y ago
like good open source, it's now forked by a community instead of having only a single maintainer eza: https://github.com/eza-community/eza https://github.com/eza-community/eza
- abenga 1y ago
  The README has an ad at the top. Yeeeah, nope.
  - CaptainOfCoit 1y ago
    For a cloud-based terminal emulator that heavily focuses on AI none the less. And they have the stomach to call it "for developers".
  - selectnull 1y ago
    The tool itself has no ads. What's wrong with a README having an ad?
    - _ZeD_ 1y ago
      everything.
      - selectnull 1y ago
        So much talk about paying open source developers and when someone actually does something about it and try to make some money, it's again not good enough. Damned if you do and damned if you don't.
      - esafak 1y ago
        Why don't you sponsor the project so they can take it down?

bieganski 1y ago

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

oneeyedpigeon 1y ago
Many of the entries do include this detail — e.g. "with syntax highlighting", "ncurses interface", and "more intuitive". I agree that "written in rust", "modern", and "better" aren't very useful!
- account42 1y ago
  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.
  - oneeyedpigeon 1y ago
    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.
    - hulitu 1y ago
      Pipe it through vim ? /s
drob518 1y ago
“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

Otek 1y ago

This is 2023 article. As with most “modern tools” half of them probably already have some newer, shinier and more trendy replacements

oneeyedpigeon 1y ago
There's a lot of tools here. Half still leaves plenty of value.
antegamisou 1y ago
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.
- Johanx64 1y ago
  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 gibberish isn't something that rolls of your tongue either, thus at minimum you'd define truckload of aliases. OR you can use a tool(s) that has marginally "sane defaults" and marginally sane UX out of the box. It really isn't that complicated. This has nothing to do with "rust".
  - esafak 1y ago
    Some people just like torturing themselves with spells like perl -ne 'map{$h{lc$_}++}/(\w+)/g;END{map{print"$h{$_} $_\n"}sort{$h{$b}<=>$h{$a}}keys%h}'
  - antegamisou 1y ago
    Sounds like a skill issue.
  - wpm 1y ago

Scotrix 1y ago

would be good to have an indicator if it’s available with your distro by default or what package you’ll need to install it since all tools are only as useful as available they are…

0x37 1y ago

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 tools, learn them well, and your life will be much easier.

andai 1y ago
I wanted to say we should just stick with what Unix shipped forever. But doesn't GNU already violate that idea?
- drob518 1y ago
  Well, even “Unix” had some differences (BSD switches vs SysV switches). Theoretically, POSIX was supposed to smooth that out, but it never went away. Today, people are more likely to be operating in a GNU Linux environment than anything else (that just a market share fact, not a moral judgement, BSD lovers). Thus, for most people, GNU is the baseline.
- imcritic 1y ago
  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.
  - mprovost 1y ago
    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) and the folk saying to just stick with the GNU tools because they're everywhere ignore all of the effort that went into making that (mostly) the case. So yes, let's not let the history of the GNU tools dictate how we live in the present.

snide 1y ago

Small note that a lot of these tool makers allow sponsorship on GitHub. I use bat / fd almost every day. Happy to support https://github.com/sponsors/sharkdp#sponsors https://github.com/sponsors/sharkdp#sponsors

fergie 1y ago

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.

oneeyedpigeon 1y ago
The core Unix toolset is so good, that you can easily get by with it. Many of these tools are better, but still not necessary, and they certainly aren't widely available by default.
account42 1y ago
They tend to be popular with the "rewrite it in rust/go" crowd as far as I can tell. Or in other words, you are no longer part of the cool kids.
- anthk 1y ago
  I've seen an online radio player in Go which was unusabiily slow on my Atom n270 due to the badly coded ANSI audio visualization FX' using floating math. Meanwhile a with Cava or another visualizer and mpd+mpc I could do the same using 200x less resources.
maeln 1y ago
> 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. I basically live in my music library. However, every single pop artist offers songs that I don't like, are not in my library, and mysteriously have many millions of albums sold. I genuinely don't know what is going on here. Joking aside, have you ever tried to use some of these tools ? I use to not understand why people where using vim until I really tried.
- fergie 1y ago
  > Joking aside, have you ever tried to use some of these tools No. > I use to not understand why people where using vim until I really tried. There's your problem. I respectfully suggest installing Emacs.

anthk 1y ago

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 works the same - jq it's fine, it's a good example on a new Unix tool - micro it's far slower than even vim - instead of nnn, sff https://github.com/sylphenix/sff with soap(1) (xdg-open replacement) from https://2f30.org create a mega fast environment. Add MuPDF and sxiv, and nnn and friends will look really slow compared to these. Yes, you need to set config.h under both sff and soap, but they will run much, much faster than any Rust tool on legacy machines.

oneeyedpigeon 1y ago
> bat it's a useless cat. Cat concatenates files. ANSI colour breaks that. It's useless as a cat replacement, I agree. The article really shouldn't call it that, although the program's GitHub page does self-describe it as "a cat clone". It's more of a syntax highlighter combined with a git diff viewer (I do have an issue with that; it should be two separate programs, not one).
- mcswell 1y ago
  I have two uses for 'cat': 1) Piping the contents of some file into a process. 2) Showing the contents of some short file. Now (1) is better done with redirection (< or >). The only time I use cat is when I'm testing some pipeline where I only want a few lines of input, so I use 'head' or something similar. Once I have the pipeline working right, I edit the command line to replace 'head' with 'cat'. Easier than re-arranging whole words. And it's rare that (2) is the right solution--too often I find that the file was longer than I thought, and I have to use 'more' (actually 'less'). So a replacement for 'cat' that does color coding sounds pretty much useless to me.
  - oneeyedpigeon 1y ago

PaulKeeble 1y ago

duf is pretty good for drive space, has some nice colours and graphs. But its also not as useful for feeding into other tools. btop has been pretty good for watching a machine to get an overview of everything going on, the latest version has cleaned up how the lazy CPU process listing works. zoxide is good for cding around the system to the same places. It remembers directories so you avoid typing full paths.

ed_blackburn 1y ago

I’m on a Mac, and some of the default tooling feels dated: GNU coreutils and friends are often stuck around mid-2000s versions. Rather than replace or fight against the system tools, I supplement them with a few extras. Honestly, most are marginal upgrades over what macOS ships with, except for fzf, which is a huge productivity boost. Fuzzy-finding through my shell history or using interactive autocompletion makes a noticeable difference day to day.

MontyCarloHall 1y ago
>some of the default tooling feels dated: GNU coreutils and friends are often stuck around mid-2000s versions That’s because they’re not GNU coreutils, they’re BSD coreutils, which are spartan by design. (FWIW, this is one of my theories for why Linux/GNU dominated BSD: the default user experience of the former is just so much richer, even though the system architecture of the latter is arguably superior.)

demetris 1y ago

Many are available on Windows too. I know I have hyperfine, fd, and eza on my Windows 11, and maybe some more I cannot remember right now. They are super easy to install too, using winget.

foofoo12 1y ago

Make sure to check out f2, the batch renaming CLI tool. It's perfectly honed and lubricated magic: https://github.com/ayoisaiah/f2 https://github.com/ayoisaiah/f2 Got featured here on HN few weeks ago.

sigio 1y ago

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 manage are debian or ubuntu, so they will use mostly the same baseline, and I then add stuff like ack, etckeeper, vim, pv, dstat.

arminiusreturns 1y ago
Another reason emacs as an OS (not fully, but you know) is such a great way to get used to things you have on systems. Hence the quote: "GNU is my operating system, linux is just the current kernel". As a greybeard linux admin, I agree with you though. This is why when someone tells me they are learning linux the first thing I tell them is to just type "info" into the terminal and read the whole thing, and that will put them ahead of 90% of admins. What I don't say is why: Because knowing what tooling is available as a built-in you can modularly script around that already has good docs is basically the linux philosophy in practice. Of course, we remember the days where systems only had vi and not even nano was a default, but since these days we do idempotent ci/cd configs, adding a tui-editor of choice should be trivial.
- e3bc54b2 1y ago
  > we remember the days where systems only had vi and not even nano was a default What are you talking about? I'm still living those days in modern day AWS with latest EC2 machines!
twic 1y ago
"servers" is the key word here. Some of the tools listed on that page are just slightly "improved" versions of common sysadmin utilities, and indeed, those are probably not worth it. But some are really development tools, things that you'd install on the small number of machines where you do programming. Those might be. The ones that leap out at me are ripgrep (a genuinely excellent recursive grepper), jq (a JSON processor - there is no alternative to this in the standard unix toolkit), and hyperfine (benchmarking).

oslem 1y ago

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. Even if the new tool isn’t of use to me, I appreciate the work that went into it. They’re wonderful tools in their own right. Often adding a few modern touches to make a great tool just a little bit better. Thank you to those who have put in so much effort. You’re making the community objectively better.

arminiusreturns 1y ago
I think many of us linux admins have such a list. Mine in particular is carefully crafted around GPL-izing my stack as much as possible. I really like the format of this ikrima.dev one though! The other stuff is great too, worth a peruse.
tasuki 1y ago
If I had to choose, my first priority would be fzf, way before rg and jq.
atiedebee 1y ago
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.

Symmetry 1y ago

tldr is an incredible tool and 95% of the time I'll quickly find what I'm looking for there instead of having to search through the man page.

twic 1y ago

I haven't tried delta, but for diffs i swear by difftastic: https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/ It's a huge improvement over purely character-based diffs.

bandrami 1y ago

Isn't baobab almost 30 years old?

oniony 1y ago

qq should be on this list. It's like jq but works with multiple file formats, including JSON, YAML, XML, &c. and has a really cool interactive TUI mode. https://github.com/JFryy/qq https://github.com/JFryy/qq

mcswell 1y ago
THAT looks like something worthwhile; I'll be looking into it. I was going to top-post that the Unix/Linux command line tools were designed back in the day when data was pretty much line-oriented, e.g. one database record per line. Since then XML, and more recently JSON, have been invented, and tools like grep and sed just don't work for those formats. But you ninja'd me, sort of.
esafak 1y ago
Did you try https://github.com/TomWright/dasel https://github.com/TomWright/dasel ?

roger_ 1y ago

I kinda wish there was a modern *suite* of improved tools, developed by one team with consistent designs (parameters, colors, tables, etc.)

gxonatano 1y ago
Nushell.

tomxor 1y ago

btop is a worthy and missing contender. It looks quite fancy but I actually like it more for it's functionality, particularly it's tree view for navigating the processes list. I'm not a big fan of full multicolor in these kinds of tools and so appreciate how easy it is to flip to grey scale mode from the built in colour schemes (even from the TUI settings menu).

seplox 1y ago

I'd like to read this list, but the color scheme is among the least accessible that I've ever come across. Dark, greyish-blue text with dark, bluish-grey highlighting over a dark grey background. Wow. If any fledgling designers are here, then take note and add this to your list of examples to avoid.

h4ch1 1y ago

I personally prefer btop [0] over gtop. Not written in js is kind of a plus. [0] https://github.com/aristocratos/btop https://github.com/aristocratos/btop

commandersaki 1y ago

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.

doktorn 1y ago

`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...).

tracker1 1y ago

Link text in dark mode is really hard to read/see.

stormed 1y ago

Nothing screams modern Linux more than having an unmaintained replacement for ls.

gxonatano 1y ago

While folks were building improved ls, cat, and so on, and jq for manipulating JSON data, Nushell has been happily doing all this in a consistent way and making it easier, to boot. I'm surprised to see Nushell missing from this list.