4 ms·

Note GNU coreutils has a good test suite which just calls out to the various tools from shell and perl scripts. It should be easy enough to run this implementat

Note GNU coreutils has a good test suite which just calls out to the various tools from shell and perl scripts. It should be easy enough to run this implementation through it. More effort goes into the coreutils tests than the code. One of the hardest parts of coreutils is keeping it working everywhere, including handling that buggy version of function X in libc Y on distro Z. That's handled for GNU coreutils by gnulib, which currently has nearly 10K files, and so is a significant project in itself. Some stats: coreutils files, lines, commits: 1072, 239474, 27924 gnulib files, lines, commits: 9274, 302513, 17476

3JPLW 12y ago
Would using a GPL test suite with an MIT implementation make the whole GPL? You're not "linking" to it, but it'd worry me somewhat.
- gkya 12y ago
  IANAL, but AFAIK as long as the test suite is not distributed as part of the package, it does not affect the licensing of the package as a whole; whereas if the test suite is distributed with the package, then the whole package can only be distributed under GPL, but the original sources the package authors wrote need not be relicensed. So, the sources will be MIT, the test suite will be GPL, and the whole package, including both the test suite and the sources will have to be GPL.
  - dalke 12y ago
    Nor am I a lawyer, but I'll point out that the GPL is only based in copyright, so if there's no chance of copyright infringement then the GPL terms don't apply. I believe the relevant part of the GPLv3, regarding "whole package" is: > A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
- jnbiche 12y ago
  >Would using a GPL test suite with an MIT implementation make the whole GPL? Absolutely not. MIT is a FSF-approved GPL-compatible license and you're free to use it with whatever GPL-licensed packages you wish[0]. However, if you package and distribute the Rust coreutils with the GPL test suite, then the users of the package are obliged to either use GPL, MIT, or some other FSF-approved OS license. But it's simple enough to package the Rust coreutils without the test suite, which puts the Rust coreutils users under no GPL obligations. GPL2 is all about the distributing of software, not how you use it. I do agree that any use of a GPL package will make some folks using this package in commercial software nervous, given the very few (none?) actual court cases that have decided these issues. 0. https://www.gnu.org/licenses/ https://www.gnu.org/licenses/
  - __david__ 12y ago
    > However, if you package and distribute the Rust coreutils with the GPL test suite, then the users of the package are obliged to either use GPL, MIT, or some other FSF-approved OS license. I don't think this is right. The programs in question are the test suite, and there's can certainly distribute complete programs licensed under the GPL alongside with programs under even non-free licenses (otherwise Mac OS X couldn't ship). Since the test suite doesn't link against the individual utilities, it won't affect them, license-wise. It is well understood that the GPL doesn't cross executable boundaries (again, otherwise Mac OS X is in trouble).
    - jnbiche 12y ago
      You're absolutely right. I was thinking of AGPL, which does cross network boundaries.
      - angersock 12y ago
        And that's why it's to be avoided like the plague. :(
        steveklabnik 12y ago
- u124556 12y ago
  I guess there's no problem if people just use them together and obtain the results without redistributing both together.
- worklogin 12y ago
  From my understanding, no. The tools are not linked by code. I'm free to write a proprietary coreutils test suite and charge $100 for it, so long as it doesn't hook directly into the source of the tools. If it's only interacting with the product, so be it.
viraptor 12y ago
Actually that makes me think this project may be very useful. If gnulib is that needed for compatibility, then rust-coreutils should be a great test-case of system compatibility for rust itself. It could uncover many things that should be done inside rust rather than this coreutils implementation.
Alupis 12y ago
Curious to the benefits of this. Is Rust performant and on par with the native C version of coreutils? Seems the readme makes a big deal about being easy to compile on windows (which has never been a problem for me, I just use Cygwin or something). Also, comments like this make it seem this is not "fully baked" yet and still needs some dev time: > fn parse_date(str: &str) -> u64 { > // This isn't actually compatible with GNU touch, but there doesn't seem to > // be any simple specification for what format this parameter allows and I'm > // not about to implement GNU parse_datetime. > // http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/parse-datetime.y http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plai...
- valarauca1 12y ago
  Rust is still behind C, but I feel that's just a maturity issue. C has had nearly 50 years to get to where it is in performance Rust hasn't had 5.
  - steveklabnik 12y ago
    I am a performance noob, but given that fortran can be faster than C due to increased information about aliasing, and given how much more aliasing information Rust has, I don't see why Rust couldn't eventually even beat C on certain kinds of things. (And obviously, aliasing is only a tiny part of performance, just something that comes to mind.) That said, I am FAR more concerned about shipping a solid 1.0 than on a maximum performance one. It'll be a while, but we'll get there.
    - idbfs 12y ago
      A nitpick: C has been able to achieve the same performance as Fortran since C99 introduced the "restrict" keyword.
      - steveklabnik 12y ago
        I was reading the other day that Windows doesn't really support most of C99, is restrict part of that or not?

3JPLW 12y ago

Would using a GPL test suite with an MIT implementation make the whole GPL? You're not "linking" to it, but it'd worry me somewhat.

gkya 12y ago
IANAL, but AFAIK as long as the test suite is not distributed as part of the package, it does not affect the licensing of the package as a whole; whereas if the test suite is distributed with the package, then the whole package can only be distributed under GPL, but the original sources the package authors wrote need not be relicensed. So, the sources will be MIT, the test suite will be GPL, and the whole package, including both the test suite and the sources will have to be GPL.
- dalke 12y ago
  Nor am I a lawyer, but I'll point out that the GPL is only based in copyright, so if there's no chance of copyright infringement then the GPL terms don't apply. I believe the relevant part of the GPLv3, regarding "whole package" is: > A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
jnbiche 12y ago
>Would using a GPL test suite with an MIT implementation make the whole GPL? Absolutely not. MIT is a FSF-approved GPL-compatible license and you're free to use it with whatever GPL-licensed packages you wish[0]. However, if you package and distribute the Rust coreutils with the GPL test suite, then the users of the package are obliged to either use GPL, MIT, or some other FSF-approved OS license. But it's simple enough to package the Rust coreutils without the test suite, which puts the Rust coreutils users under no GPL obligations. GPL2 is all about the distributing of software, not how you use it. I do agree that any use of a GPL package will make some folks using this package in commercial software nervous, given the very few (none?) actual court cases that have decided these issues. 0. https://www.gnu.org/licenses/ https://www.gnu.org/licenses/
- __david__ 12y ago
  > However, if you package and distribute the Rust coreutils with the GPL test suite, then the users of the package are obliged to either use GPL, MIT, or some other FSF-approved OS license. I don't think this is right. The programs in question are the test suite, and there's can certainly distribute complete programs licensed under the GPL alongside with programs under even non-free licenses (otherwise Mac OS X couldn't ship). Since the test suite doesn't link against the individual utilities, it won't affect them, license-wise. It is well understood that the GPL doesn't cross executable boundaries (again, otherwise Mac OS X is in trouble).
  - jnbiche 12y ago
    You're absolutely right. I was thinking of AGPL, which does cross network boundaries.
    - angersock 12y ago
      And that's why it's to be avoided like the plague. :(
      - steveklabnik 12y ago
u124556 12y ago
I guess there's no problem if people just use them together and obtain the results without redistributing both together.
worklogin 12y ago
From my understanding, no. The tools are not linked by code. I'm free to write a proprietary coreutils test suite and charge $100 for it, so long as it doesn't hook directly into the source of the tools. If it's only interacting with the product, so be it.

viraptor 12y ago

Actually that makes me think this project may be very useful. If gnulib is that needed for compatibility, then rust-coreutils should be a great test-case of system compatibility for rust itself. It could uncover many things that should be done inside rust rather than this coreutils implementation.

Alupis 12y ago

Curious to the benefits of this. Is Rust performant and on par with the native C version of coreutils? Seems the readme makes a big deal about being easy to compile on windows (which has never been a problem for me, I just use Cygwin or something). Also, comments like this make it seem this is not "fully baked" yet and still needs some dev time: > fn parse_date(str: &str) -> u64 { > // This isn't actually compatible with GNU touch, but there doesn't seem to > // be any simple specification for what format this parameter allows and I'm > // not about to implement GNU parse_datetime. > // http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/parse-datetime.y http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plai...

valarauca1 12y ago
Rust is still behind C, but I feel that's just a maturity issue. C has had nearly 50 years to get to where it is in performance Rust hasn't had 5.
- steveklabnik 12y ago
  I am a performance noob, but given that fortran can be faster than C due to increased information about aliasing, and given how much more aliasing information Rust has, I don't see why Rust couldn't eventually even beat C on certain kinds of things. (And obviously, aliasing is only a tiny part of performance, just something that comes to mind.) That said, I am FAR more concerned about shipping a solid 1.0 than on a maximum performance one. It'll be a while, but we'll get there.
  - idbfs 12y ago
    A nitpick: C has been able to achieve the same performance as Fortran since C99 introduced the "restrict" keyword.
    - steveklabnik 12y ago
      I was reading the other day that Windows doesn't really support most of C99, is restrict part of that or not?