I use git command line interface. Not because it is good (it isn't) or because I enjoy suffering (I think I don't), but because it is a standard on all the machines that have, you know, git.
What good is a ls alternative if I need to install it everywhere I need ls? I'd prefer using the standard ls even if it is not ideal. But maybe that's just me.
This is also one of the reasons I write C++ with vim without any auto-completion nor fancy plugins (I do use syntax highlighting though, but I think it comes by default with vim nowadays), as well as using GNU screen -- not every machines install tmux by default, surprisingly. In case I need to login into some random Linux box, I'm sure I'll be almost as productive as I am on my own machine.
You mean, you're almost as unproductive on your development machine as on a random remote system that has no tools. And you somehow regard this as some sort of playing field leveling that generates an advantage.
Imagine a car mechanic that won't use a big hydraulic lift that hoists a car in seconds and lets him walk under it, claiming that by using a manually cranked portable jack, he can be almost as productive when fixing something by the roadside with emergency equipment as he is in his garage.
If you ever meet such a mechanic you can be sure that he programs computers as a hobby.
I assume this is tongue-in-cheek, but I don't think the comparison works at all.
I spend maybe 1% of my working hours (being generous) using `ls` and something like 50% (likely more) using my editor.
If there is some alternative to `ls` that makes my `ls` workflows 2x faster, my productivity increases by 0.5%. If I use a sub-optimal editor that makes my workflow 2x slower, I lose 25% of my productivity.
When I need to login to a remote box, I am also very likely to need to use `ls` since I am less familiar than on my own machine, whereas I am unlikely to do any sort of heavy development work (typically I just need to edit a couple configuration files, or do some git operations).
I did the same thing back in they day.
I developed on SCO (and, later, Unixware) on a PC, all of the clients were running the gamut of Unix OSes: HPUX, DGUX, AIX, SunOS, you name it.
Most of the time was spent on our box in the office, but I was constantly bouncing back and forth to client systems. Either on site, or over the modem. Having to juggle Termcaps and the whole thing. It was polyglot machine/OS world back then.
Just had to learn to get the best out of a baseline set of Unix tools. vi instead of emacs, awk instead of perl. Master those and never be left wanting on a new environment, so I can hit the ground running. No need to "bootstrap" (if the client would even let you, not always). Couldn't even rely on a C compiler.
I’ve been on machines in the last few years that didn’t have screen either. Maybe it was a minimal install or something, but I specifically remember having to install it to get some long running stuff going.
(Thinking it was Ubuntu server, but guessing someone will correct me)
Tmux vs screen is an odd one; it kinda feels like screen was included in the era when people were actually trying to make the default install on servers kind of nice to use with a functional set of assumed programs. And now, it is fairly widespread just due to legacy.
Nowadays, and possibly for the better (every line of code is a potential bug and every bug is a potential vulnerability) it seems like systems don’t want to include this sort of stuff. So, I’m sure if the decision were made today, tmux or screen, tmux would win. Unfortunately, “none” seems like the real future option…
What's the point of suffering everywhere if you don't enjoy it? It's not like using a better alternative prevents you from knowing how to use ls, but only in those cases where there is no better alternative
Ubiquitousness is certainly a major selling point. The GNU coreutils are everywhere. I've made my peace with bash and make because I know they're always gonna be there.
This doesn't mean there's no value in developing one's own tools. Contributing to other projects can be quite difficult and time consuning. GNU projects are even more so.
We shouldn't limit ourselves to POSIX stuff either. Better software and tools can and should be built. Every attempt is valuable. And who knows? It might just turn into a staple of Linux distributions some day.