91–100 of 244 posts
Am I perhaps a genius or is it just not that difficult to know two tools?
Yet another example of why I don't trust any software that markets itself as "modern". In another 20 years, ls will still work perfectly fine.
Which is exactly the reason "ls" is working perfectly fine for you today. The original AT&T UNIX "ls" has been forked over and over again and rewritten from scratch several times. You're using an evolved fork of this "ls" if you're using macOS or BSD, but if you're on Linux you're using a rewrite (GNU coreutils ls), and if you're running BusyBox you're using yet another rewrite.
All of these different rewrites and forks aren't really compatible, and you can't reliably use anything beyond what's in the POSIX standard if you want your scripts to run on multiple OSes.
I'm not dissing "ls" - it's an impressive, if old, piece of software that served us well, but it's not inherently more survivable because it's old. It died (in terms of being "forked by another maintainer") many times over, enough to make exa and eza blush.
ls survied because people need it, and I that most of the highly popular rewrite-in-Rust programs are here to stay for the same reasons. Ripgrep, exa, bat and fd are probably part of the club now. "ls" is probably not going to die either. The POSIX standard is going to keep at least the least common denominator version alive for a long time. But for many people it could go the way that "ed" or "more" have gone.
And here is a good story: "ed" still survived in POSIX as-is, while "vi" died and had to be replaced by stevie and and elvis, and then by vim. Nowadays vim is also been replaced by neovim in many circles. And yet, how many people keep using "ed"? Who cares if it's stable, when vi and its descendants run circles around it?
There's a hint of a belief in this thread - common also in threads about alternative shells and Vim setups - that someone who uses a tool like this will irrevocably lose the knowledge of how to use ls. Am I perhaps a genius or is it just not that difficult to know two tools?
I've been using `exa` for years, and my aliases work regardless if it's installed or not. I just get a better UX if it is.
A nice metaphor when the "modern replacement" for something as basic as a directory listing is deprecated while the original means (the built-in ls) still works fine and isnt. EDIT: ls on linux is apparently an executable part of GNU and not a built-in
And besides, I said in other places: "ls" has been "deprecated by its maintainer" more times than exa, it's just that somebody has always forked it. GNU "ls" (the one in Linux) is a complete rewrite of the original shell, and it is annoyingly incompatible with the macOS fork of BSD ls.
A nice metaphor when the "modern replacement" for something as basic as a directory listing is deprecated while the original means (the built-in ls) still works fine and isnt. EDIT: ls on linux is apparently an executable part of GNU and not a built-in
Yet another example of why I don't trust any software that markets itself as "modern". In another 20 years, ls will still work perfectly fine.
And so will exa, probably. And if it won't, it will be forked. Which is exactly the reason "ls" is working perfectly fine for you today. The original AT&T UNIX "ls" has been forked over and over again and rewritten from scratch several times. You're using an evolved fork of this "ls" if you're using macOS or BSD, but if you're on Linux you're using a rewrite (GNU coreutils ls), and if you're running BusyBox you're us…
However, being "modern" is not a good reason. The gnu authors were not motivated to write the coreutils simply for the sake of modernity. And that is why their fork of ls has much greater staying power than all the "modern" forks.
Earlier quoted context omitted.
And yet, exa is deprecated :-)
Yes but people did not find it daunting to create a fork. But if what the comment I replied to meant by "capable of maintaining them myself" was about having an organizational structure where they could become an official maintainer of the official project rather than needing to fork it if the owner becomes unavailable, then yep, that's a great point about these single-owner projects. But my original interpretation w…
Earlier quoted context omitted.
I wish there was a better way for the community to handle this situation without the original author doing what we see here. Sometimes the original author dies unexpectedly for example and it's very hard to salvage the work into a maintained fork. I wrote about this in 2018: https://kodare.net/2018/06/25/salvaging-abandoned-projects.h...
There is, I created it years ago, but unfortunately it hasn't taken off: https://www.codeshelter.co/ Maybe I'm bad at marketing, it seems like a pity.