5 ms·
If a Rust rewrite of Coreutils is not backward compatible, it is not a replacement and the current GNU Coreutils would still be needed for backward compatibilit
by thesuperbigfrog 6y ago
If a Rust rewrite of Coreutils is not backward compatible, it is not a replacement and the current GNU Coreutils would still be needed for backward compatibility.
There is a long history of newer, better tools supporting backward compatibility to be a replacement for their predecessors:
- bash and zsh support backward compatibility to be replacements for sh.
- vim has compatibility mode to be a replacement for vi.
If the Rust implementation is not backward compatible, it should not be called "Coreutils".
- GoblinSlayer 6y agoWhat you call "Coreutils" should be called GNU/Coreutils.
- thesuperbigfrog 6y agoThe Rust implementation that we are discussing is MIT licensed and as far as I know not part of GNU. I do not believe that "Coreutils" is trademarked by GNU. There are other projects that use the name "Coreutils" that are not part of GNU: https://github.com/DiegoMagdaleno/BSDCoreUtils https://github.com/DiegoMagdaleno/BSDCoreUtils
- entropicdrifter 6y agoI think the person you're replying to was just memeing on the Richard Stallman essay that has the line, "What you call Linux should really be called GNU/Linux"
- audience_mem 6y agoI was sad to find out that rms apparently didn't even say it.
- GoblinSlayer 6y ago>I do not believe that "Coreutils" is trademarked by GNU. That's exactly why GNU sort of coreutils should be called GNU/Coreutils. The comment said that GNU/Coreutils are equivalent to Coreutils, I said they aren't.
- anand-bala 6y agoThe Rust rewrite of Coreutils (this post essentially) _is_ meant to be a drop in replacement for GNU/Coreutils. OTOH, ripgrep and fd are not "drop-in replacements". Rather, they are "replacements" that devs can use if they want to.