5 ms·

This is a sad state of affairs. The world does not become a better place by rewriting working copylefted code into permissive licenses. Especially when the ma

This is a sad state of affairs. The world does not become a better place by rewriting working copylefted code into permissive licenses. Especially when the main goal of the rewrite is to ease corporate "theft" of these codes. We are walking several steps backwards with these rewrites (as much as I love the concept of rewriting common tools in a safer language). EDIT: I'm actually outraged by this. I want to love the rust rewrite of coreutils, but I don't understand why they had to taint this beautiful work with stupid license politics.

flomo 6y ago
Coreutils is mostly UNIX/POSIX standard utilities which have been implemented under many closed and open source licenses for decades now. This is not where you build the GNU/Moat.
- scaladev 6y ago
  But GNU coreutils are ahead of all proprietary alternatives in both speed and features, are they not? I've personally not had the opportunity to work on AIX, or Solaris, or whatever (there are no machines like that where I live), but that's what I always read: "we got a new AIX/HP-UX/Solaris/whatever server and the first thing I did was to build GNU coreutils and replace the stock crap with it".
  - stonemetal12 6y ago
    >...first thing I did... How do you know if the platform tools are faster\slower more featureful or less if the first thing you did is replace them? GNU coreutils won on portability of knowledge, no need to learn how the platform's tools work when I can just roll with GNU. Which is great when you are dealing with multiple different varieties of Unix that are all slightly different. In general the base os tools where like all software that competes in the same space, it did somethings better and somethings worse.
    - Mediterraneo10 6y ago
      People know that GNU tools were faster simply because the GNU versions' developers had famously optimized the hell out of them (many research papers written about this back in the day), while preexisting Unix tools didn't have that much optimization.
Thiez 6y ago
Are you also outraged by the existence of clang, as it has a permissive license and competes with GCC? From where I'm standing it looks like you are the one introducing the stupid license politics. The Rust Coreutils developers have chosen a license that they like, and you are the one making arguments about how terrible this is for the world and how they are tainting the GNU Coreutils.
- enriquto 6y ago
  > Are you also outraged by the existence of clang If clang wast named "Rust GNU Compiler Collection rewrite" I would certainly be!
- konjin 6y ago
  >Are you also outraged by the existence of clang, as it has a permissive license and competes with GCC? Yes.
  - dralley 6y ago
    Maybe you should be outraged by GCC's deliberate sandbagging and less deliberate stagnation that allowed LLVM to swoop in and be a legitimately more useful (if not "better") compiler. Stallman himself was largely responsible for GCC not exposing intermediate representation for analysis. https://www.reddit.com/r/programming/comments/2rtumb/current_emacs_maintainer_disagrees_with_rms_id_be/ https://www.reddit.com/r/programming/comments/2rtumb/current... There is a world in which rustc might have been built on gcc instead - a world where GCC was interested in being a platfom rather than a Maginot line trying to prevent any possible theoretical use by proprietary software even if it means preventing free software from doing the same.
    - enriquto 6y ago
      > Stallman himself was largely responsible for GCC not exposing intermediate representation for analysis. This is wildly offtopic for this thread, but it is not clear that Stallman's stance on this issue was an error. The wide existence of LLVM-based compilers for proprietary architectures is, for many of us, a tragedy that Stallman correctly anticipated. His insightful and courageous steering of the GCC development was a crucial step in avoiding this problem for GCC.
jka 6y ago
It's disappointing but it's not worth assuming any malice or continuing flamewars. There's been some discussion on the project's GitHub page in the past about licensing. What's worthwhile is to share and talk about why the license selection may result in proprietary and bloated applications built upon the stack, and the resulting inefficiencies and security issues that could occur years in the future as a result. Perhaps it'd even be possible to speculate about what incentives create and support the conditions for those. If enough people agree and understand the situation, perhaps we'll see change. If they don't, we'll continue on for a number of years and maybe those hypothetical problems will occur, or maybe they won't and the concerns will have been unjustified.
- jka 6y ago
  (and FWIW: I also think it's excellent to see core utilities rewritten in rust)
layoutIfNeeded 6y ago
>I don't understand why they had to taint this beautiful work with stupid license politics It's pretty simple reasoning: Rust evangelists want to maximize Rust usage. Period. Replacing GPL-licensed tools with alternatives written in Rust is an easy way to bootstrap this. Compare with: paperclip maximizer (https://www.lesswrong.com/tag/paperclip-maximizer https://www.lesswrong.com/tag/paperclip-maximizer)

flomo 6y ago

Coreutils is mostly UNIX/POSIX standard utilities which have been implemented under many closed and open source licenses for decades now. This is not where you build the GNU/Moat.

scaladev 6y ago
But GNU coreutils are ahead of all proprietary alternatives in both speed and features, are they not? I've personally not had the opportunity to work on AIX, or Solaris, or whatever (there are no machines like that where I live), but that's what I always read: "we got a new AIX/HP-UX/Solaris/whatever server and the first thing I did was to build GNU coreutils and replace the stock crap with it".
- stonemetal12 6y ago
  >...first thing I did... How do you know if the platform tools are faster\slower more featureful or less if the first thing you did is replace them? GNU coreutils won on portability of knowledge, no need to learn how the platform's tools work when I can just roll with GNU. Which is great when you are dealing with multiple different varieties of Unix that are all slightly different. In general the base os tools where like all software that competes in the same space, it did somethings better and somethings worse.
  - Mediterraneo10 6y ago
    People know that GNU tools were faster simply because the GNU versions' developers had famously optimized the hell out of them (many research papers written about this back in the day), while preexisting Unix tools didn't have that much optimization.

Thiez 6y ago

Are you also outraged by the existence of clang, as it has a permissive license and competes with GCC? From where I'm standing it looks like you are the one introducing the stupid license politics. The Rust Coreutils developers have chosen a license that they like, and you are the one making arguments about how terrible this is for the world and how they are tainting the GNU Coreutils.

enriquto 6y ago
> Are you also outraged by the existence of clang If clang wast named "Rust GNU Compiler Collection rewrite" I would certainly be!
konjin 6y ago
>Are you also outraged by the existence of clang, as it has a permissive license and competes with GCC? Yes.
- dralley 6y ago
  Maybe you should be outraged by GCC's deliberate sandbagging and less deliberate stagnation that allowed LLVM to swoop in and be a legitimately more useful (if not "better") compiler. Stallman himself was largely responsible for GCC not exposing intermediate representation for analysis. https://www.reddit.com/r/programming/comments/2rtumb/current_emacs_maintainer_disagrees_with_rms_id_be/ https://www.reddit.com/r/programming/comments/2rtumb/current... There is a world in which rustc might have been built on gcc instead - a world where GCC was interested in being a platfom rather than a Maginot line trying to prevent any possible theoretical use by proprietary software even if it means preventing free software from doing the same.
  - enriquto 6y ago
    > Stallman himself was largely responsible for GCC not exposing intermediate representation for analysis. This is wildly offtopic for this thread, but it is not clear that Stallman's stance on this issue was an error. The wide existence of LLVM-based compilers for proprietary architectures is, for many of us, a tragedy that Stallman correctly anticipated. His insightful and courageous steering of the GCC development was a crucial step in avoiding this problem for GCC.

jka 6y ago

It's disappointing but it's not worth assuming any malice or continuing flamewars. There's been some discussion on the project's GitHub page in the past about licensing. What's worthwhile is to share and talk about why the license selection may result in proprietary and bloated applications built upon the stack, and the resulting inefficiencies and security issues that could occur years in the future as a result. Perhaps it'd even be possible to speculate about what incentives create and support the conditions for those. If enough people agree and understand the situation, perhaps we'll see change. If they don't, we'll continue on for a number of years and maybe those hypothetical problems will occur, or maybe they won't and the concerns will have been unjustified.

jka 6y ago
(and FWIW: I also think it's excellent to see core utilities rewritten in rust)

layoutIfNeeded 6y ago

>I don't understand why they had to taint this beautiful work with stupid license politics It's pretty simple reasoning: Rust evangelists want to maximize Rust usage. Period. Replacing GPL-licensed tools with alternatives written in Rust is an easy way to bootstrap this. Compare with: paperclip maximizer (https://www.lesswrong.com/tag/paperclip-maximizer https://www.lesswrong.com/tag/paperclip-maximizer)