3 ms·

There is problem with nice modern Linux tools - they are not available on the generic servers and embedded boxes with you will likely use, or in the image someo

by Yizahi 3y ago

There is problem with nice modern Linux tools - they are not available on the generic servers and embedded boxes with you will likely use, or in the image someone else has given you etc. Therefore it is pointless (sorry for the strong term) to learn them, because they simply won't be available for when they are most needed. And learning new tools is not a free process, there are costs, mental and time.

burntsushi 3y ago
I think you need to caveat the word "pointless" heavily. If 95% of the commands I type are in my local dev environment where I can install a variety of tools, then I don't see how it's pointless to learn different tools for the common case. Otherwise, you're just needlessly limiting yourself to a constrained set of tooling with zero opportunity for any kind of progress or improvement. Even though I'm the author of ripgrep, believe it or not, I still use grep in those 5% of cases without any kind of fuss.
topaz0 3y ago
This is probably a good default position for a random new tool that floats across hacker news, but there are plenty of situations where the benefits of having a tool (even if only in your local environment) outweigh the effort of learning it and getting it.
kstrauser 3y ago
I reject that heartily. I spend 90% of my shell time on my own machine, and I want it to be comfortable. Here “at home” I use nice editors, and Fish shell, and ripgrep/fzf/etc., because they make my daily life more pleasant and productive. Some remote servers are minimal to the point that they only have Bourne shell and plain vi available, and when I’m working on them, that’s what I use. But darned if I want to handcuff myself to the greatest common denominator in my daily work. I promise, you can learn both grep and ripgrep at the same time.
- librasteve 3y ago
  and Rak too ;-)
  - kstrauser 3y ago
    And Rak, too. :)
cedws 3y ago
This is why I'm also skeptical of the "modern" replacements, like Just for example. The majority of developers already have Make on their system and Make works well enough. When you use Just instead, you're adding friction to the build process for some portion of people who want to work on your code. You have to context switch to go and install it. Brew decides it wants to upgrade everything. Aaaand you've wasted 15 minutes because you went to get a coffee in the meantime.
sgarland 3y ago
If you control the servers you’ll be working on, you can install the tooling you’d like. If you don’t, you can lobby for it to be installed. Some Postgres servers I work on have massive log files, and due to DDOG indexing retention being short, sometimes it’s required to go sleuthing on the host. While LC_ALL=C speeds up grep quite a bit, it’s still an order of magnitude slower than ripgrep. Luckily, I can add tooling to these servers if there is a valid need, and “massively speeds up searches when speed is of the essence” is very much an accepted case.
- Yizahi 3y ago
  Our test servers are upgraded weekly/daily, and embedded devices we are testing are upgraded daily/hourly. It's just not feasible. And embedded devices has an additional constraint for space and/or bureaucracy. I'm still waiting for the feature complete "less" to be added there after like half a year (we have a weird distro with busybox bolted on top). I understand that my case is maybe an outlier, but I've resigned that I only learn what's available in the busybox and basic Debian. I wish that distributives maintainers would enforce inclusion of the modern tools like Rak in the default install, then they would become the norm across whole industry. Like for example MS includes Powershell regardless of the opinion of people who dislike it. And now you can expect that powershell is available in any modern Win install. In latest Win11 new Terminal is now a permanent feature in every install and you can expect to have it everywhere on Win11. Etc.
  - sgarland 3y ago
    Embedded notwithstanding (I admit that’s a special case where most norms go out the window), you could put the tooling and configs into Ansible plays and run them with the upgrades, or use Puppet to push them continuously. Regarding distro maintainers, specifically Debian, ripgrep is in Bookworm [0]. [0]: https://packages.debian.org/bookworm/ripgrep https://packages.debian.org/bookworm/ripgrep

by Yizahi 3y ago

burntsushi 3y ago

I think you need to caveat the word "pointless" heavily. If 95% of the commands I type are in my local dev environment where I can install a variety of tools, then I don't see how it's pointless to learn different tools for the common case. Otherwise, you're just needlessly limiting yourself to a constrained set of tooling with zero opportunity for any kind of progress or improvement. Even though I'm the author of ripgrep, believe it or not, I still use grep in those 5% of cases without any kind of fuss.

topaz0 3y ago

This is probably a good default position for a random new tool that floats across hacker news, but there are plenty of situations where the benefits of having a tool (even if only in your local environment) outweigh the effort of learning it and getting it.

kstrauser 3y ago

I reject that heartily. I spend 90% of my shell time on my own machine, and I want it to be comfortable. Here “at home” I use nice editors, and Fish shell, and ripgrep/fzf/etc., because they make my daily life more pleasant and productive. Some remote servers are minimal to the point that they only have Bourne shell and plain vi available, and when I’m working on them, that’s what I use. But darned if I want to handcuff myself to the greatest common denominator in my daily work. I promise, you can learn both grep and ripgrep at the same time.

librasteve 3y ago
and Rak too ;-)
- kstrauser 3y ago
  And Rak, too. :)

cedws 3y ago

This is why I'm also skeptical of the "modern" replacements, like Just for example. The majority of developers already have Make on their system and Make works well enough. When you use Just instead, you're adding friction to the build process for some portion of people who want to work on your code. You have to context switch to go and install it. Brew decides it wants to upgrade everything. Aaaand you've wasted 15 minutes because you went to get a coffee in the meantime.

sgarland 3y ago

If you control the servers you’ll be working on, you can install the tooling you’d like. If you don’t, you can lobby for it to be installed. Some Postgres servers I work on have massive log files, and due to DDOG indexing retention being short, sometimes it’s required to go sleuthing on the host. While LC_ALL=C speeds up grep quite a bit, it’s still an order of magnitude slower than ripgrep. Luckily, I can add tooling to these servers if there is a valid need, and “massively speeds up searches when speed is of the essence” is very much an accepted case.

Yizahi 3y ago
Our test servers are upgraded weekly/daily, and embedded devices we are testing are upgraded daily/hourly. It's just not feasible. And embedded devices has an additional constraint for space and/or bureaucracy. I'm still waiting for the feature complete "less" to be added there after like half a year (we have a weird distro with busybox bolted on top). I understand that my case is maybe an outlier, but I've resigned that I only learn what's available in the busybox and basic Debian. I wish that distributives maintainers would enforce inclusion of the modern tools like Rak in the default install, then they would become the norm across whole industry. Like for example MS includes Powershell regardless of the opinion of people who dislike it. And now you can expect that powershell is available in any modern Win install. In latest Win11 new Terminal is now a permanent feature in every install and you can expect to have it everywhere on Win11. Etc.
- sgarland 3y ago
  Embedded notwithstanding (I admit that’s a special case where most norms go out the window), you could put the tooling and configs into Ansible plays and run them with the upgrades, or use Puppet to push them continuously. Regarding distro maintainers, specifically Debian, ripgrep is in Bookworm [0]. [0]: https://packages.debian.org/bookworm/ripgrep https://packages.debian.org/bookworm/ripgrep