Comment by 0x37

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.

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.

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.

> that if you ever change your OS installation

apt-get/pacman/dnf/brew install <everything that you need>

You'll need install those and other tools (your favorite browser, you favorite text editor, etc) anyway if you're changing your OS.

> or SSH anywhere

When you connect through SSH you don't have GUI and that's not a reason for avoiding using GUI tools, for example.

> even use a mix of these on my personal computer and the traditional ones elsewhere

I can't see the problem, really. I use some of those tools and they are convenient, but it doesn't matter that I can't work without that. For example, bat: it doesn't replace cat, it only outputs data with syntax highlight, makes my life easier but if I don't have it, ok.

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 some alternatives like fd (find alt) or sd (sed alt) are absolute time savers.

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

Agreed, but that doesn't stop you from using/learning alternatives. Just use your preferred option, based on what's available. I realise this could be too much to apply to something like a programming language (despite this, many of us know more than one) or a graphics application, but for something like a pager, it should be trivial to switch back and forth.

I do prefer some of these tools, due to a much better UX, but the only one I do install in every unix box is ripgrep.

I wanted to say we should just stick with what Unix shipped forever. But doesn't GNU already violate that idea?

I tend to use some of these "modern" tools if they are a drop-in replacement for existing tools.

E.g. I have ls set up aliased to eza as part of my custom set of configuration scripts. eza pretty much works as ls in most scenarios.

If I'm in an environment which I control and is all configured as I like it, then I get a shinier ls with some nice defaults.

If I'm in another environment then ls still works without any extra thought, and the muscle memory is the same, and I haven't lost anything.

If there's a tool which works very differently to the standard suite, then it really has to be pulling its weight before I consider using it.

> 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

When I got my first Unix account [1] I was in a Gnu emacs culture and used emacs from 1989 to 2005 or so. I made the decision to switch to vi for three reasons: (1) less clash with a culture where I mostly use GUI editors that use ^S for something very different than what emacs does, (2) vim doesn't put in continuation characters that break cut-and-paste, (3) often I would help somebody out with a busted machine where emacs wasn't installed, the package database was corrupted, etc and being able to count on an editor that is already installed to resolve any emergency is helpful.

[1] Not like the time one of my friends "wardialed" every number in my local calling area and posted the list to a BBS and I found that some of them could be logged into with "uucp/uucp" and the like. I think Bell security knew he rang everybody's phone in the area but decided to let billing handle the problem because his parents had measured service.

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.

I started a new job and spent maybe a day setting up the tools and dotfiles on my development machine in the cloud. I'm going to keep it throughout my employment so it's worth the investment. And I install most of the tools via nix package manager so I don't have to compile things or figure out how to install them on a particular Linux distribution. L

i learned ansible and i run 1 command and wait 10 minutes and configure new linux machine with all the stuff i want

This is how I feel as well. Spend some time "optimizing" my CLI with oh my zshell etc. when I was young.

Only to feel totally handicapped when logging in into a busybox environment.

I'm glad I learned how to use vi, grep, sed..

My only change to an environment is the keyboard layout. I learned Colemak when I was young. Still enjoying it every day.

Not a comment on these particular tools, but I keep non-standard utilities that I use in my ~/bin/ directory, and they go with me when I move to a different system. The tools mentioned here could be handled the same way, making the uphill a little less steep.

I have some of these tools, they are not "objectively superior". A lot of them make things prettier with colors, bargraphs, etc... It is nice on a well-configured terminal, not so much in a pipeline. Some of them are full TUIs, essentially graphical tools that run in a terminal rather than traditional command line tools.

Some of them are smart but sometimes I want dumb, for example, ripgrep respects gitignore, and often, I don't want that. Though in this case, there is an option to turn it off (-uuu). That's a common theme with these tools too, they are trying to be smart by default and you need option to make them dumb.

So no, these tools are not "objectively superior", they are generally more advanced, but it is not always what you need. They complement classic tools, but in no way replace them.

Never will I ever set up tools and home environment directly on the distro. Only in a rootfs that I can proot/toolbx/bwrap into. Not only I don't want to set up again on different computer, distro upgrade has nuked "fancy" tools enough times to be not worth it.

Agreed, but some are nice enough that I'll make sure I get them installed where I can. 'ag' is my go to fast grep, and I get it installed on anything I use a lot.

For some people the "uphill battle" is the fun part

How hard is it to set up your tooling?

I have a chef cookbook that sets up all the tools I like to have on my VMs. When I bootstrap a VM it includes all the stuff I want like fish shell and other things that aren’t standard. The chef cookbook also manages my SSH keys and settings.

I indeed would not want to feel stranded with a bespoke toolkit. But I also don't think shying away from good tools is the answer. Generally I think using better tools is the way to go.

Often there are plenty of of paths open to getting a decent environment as you go:

Mostly, I rely on ansible scripts to install and configure the tools I use.

One fallback I haven't seen mentioned, that can get a lot of mileage from it: use sshfs to mount the target system locally. This allows you to use local tool & setup effectively against another machine!

Along those lines, Dvorak layouts are more efficent, but I use qwerty because it works pretty much everywhere (are small changes like AZERTY still a thing? Certainly our French office is an "international" layout, and generally the main pain internationally are "@" being in the wrong place, and \ not working -- for the latter you can use user@domain when logging into a windows machine, rather than domain\user)

I do it at least for ripgrep.

"I don't want to be a product of my environment. I want my environment to be a product of me."

so right.