3 ms·

Has the code quality in that repo gotten to a good point then? I haven't followed it much, but last I looked[1] (which was a few years ago) almost every tool I

by Arcuru 12d ago

Has the code quality in that repo gotten to a good point then? I haven't followed it much, but last I looked[1] (which was a few years ago) almost every tool I looked at in detail had pretty bad performance or correctness issues. [1] https://jackson.dev/post/rust-coreutils-dd/ https://jackson.dev/post/rust-coreutils-dd/

egorfine 12d ago
The reason for existence of uutils is ideological, not technical. Thus code quality is of no use for the objective.
- stouset 12d ago
  I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources. There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs. By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem with extremely amateurish Rust. The threading highlighted in the linked post above seems pretty egregious.
  - egorfine 12d ago
    Same here. Love Rust. Hate rust rewrites.
    - noosphr 11d ago
      The worst thing about rust are the people using it.
      - LtWorf 11d ago
        My impression is that go developers moved to rust.
        pjmlp 11d ago
        I doubt it, as Rust approach to language design is the antithesis of Go's culture. I would appreciate Go much more otherwise.
    - pjmlp 11d ago
      Can vouch for the sentiment, hence why regardless of the ranting, I am quite supportive of whatever helps to improve C and C++ security story. Also for Rust based rewrites, they could start by bootstraping Rust compiler itself, dependent on C++ to start it. They don't do it, because even though LLVM and GCC are written in C++, a pure Rust compiler would not scale to the same level of contributions, and existing capabilities.
  - pantalaimon 11d ago
    I think this is more about the licence, the Rust rewrite just makes it easier to swallow/gain contributors.
  - torginus 11d ago
    Yes, these proclamations of Rust devs that 'the future belongs to us', aren't getting any new fans for the language. Here's my rebuttal: YOU have proclaimed the language to be as fast as C while being safe. YOU need to prove it. Think of this as an OPPORTUNITY to PROVE that Rust can walk the walk, and you can make Rust coreutils as fast as the C one. Think hard about how you can model low level Linux constructs safely. Fix your libs. Fix the compiler. This is the yardstick you need to meet. You are making free software, and the thing about it is users are free to choose otherwise. YOU need to prove that Rust is just as fast and lightweight as C, and once you do, we'll be happy to adopt. Right now, dear Rust devs, what you are doing is the same as AI companies are doing - you're trying to usurp power based on extremely nebulous conjured threats. Nobody likes being threatened.
    - deleted 10d ago
      [deleted]
- tcfhgj 11d ago
  I bet you don't know the reason for existence
- timcobb 11d ago
  > The reason for existence of uutils is ideological, not technical. which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.
  - pessimizer 11d ago
    Rewrite it in anything that isn't GPL.
    - timcobb 11d ago
      With the motivation of then being able to use it in closed or non-GPL products down the line?
  - jeltz 11d ago
    > Are people saying that there's an ideology of pushing rust for things without concern for quality? Yes, there is. There are people who genuinely think quality does not matter as log as it is written in Rust as Rust is memory safe.
    - timcobb 11d ago
      > There are people who genuinely think quality does not matter as log as it is written in Rust as Rust is memory safe. Is this hyperbolic? Such people are in leadership places?
  - steveklabnik 11d ago
    The original authors of uutils do not particularly care about licensing, and the Rust ecosystem defaults to MIT/Apache2. So they chose that. Many people have decided that this decision supposedly specifically about licensing ideology. You can make up your mind about which of the two you believe. See also, for Ubuntu's take on this: https://news.ycombinator.com/item?id=49707948 https://news.ycombinator.com/item?id=49707948
estebank 12d ago
> last I looked[1] (which was a few years ago) You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
Freaky 11d ago
Neat. I touched this code about 8 months later to avoid the per-block elapsed() call: https://github.com/uutils/coreutils/commit/cf7b90bbe7cb87099499876622f413a65a699038 https://github.com/uutils/coreutils/commit/cf7b90bbe7cb87099... Mirrored the way I implemented status=progress in FreeBSD dd, though there the flag was set by a SIGALRM timer: https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751af6c883dce141736542f https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751... It would appear GNU dd 9.9 still does a call for every block. Low-hanging fruit if anyone fancies it: dd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes transferred in 18.644004 secs (2746191200 bytes/sec) target/release/dd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes (51 GB, 48 GiB) copied, 20.8772 s, 2.5 GB/s gdd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes (51 GB, 48 GiB) copied, 23.6744 s, 2.2 GB/s

by Arcuru 12d ago

egorfine 12d ago

The reason for existence of uutils is ideological, not technical. Thus code quality is of no use for the objective.

stouset 12d ago
I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources. There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs. By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem with extremely amateurish Rust. The threading highlighted in the linked post above seems pretty egregious.
- egorfine 12d ago
  Same here. Love Rust. Hate rust rewrites.
  - noosphr 11d ago
    The worst thing about rust are the people using it.
    - LtWorf 11d ago
      My impression is that go developers moved to rust.
      - pjmlp 11d ago
        I doubt it, as Rust approach to language design is the antithesis of Go's culture. I would appreciate Go much more otherwise.
  - pjmlp 11d ago
    Can vouch for the sentiment, hence why regardless of the ranting, I am quite supportive of whatever helps to improve C and C++ security story. Also for Rust based rewrites, they could start by bootstraping Rust compiler itself, dependent on C++ to start it. They don't do it, because even though LLVM and GCC are written in C++, a pure Rust compiler would not scale to the same level of contributions, and existing capabilities.
- pantalaimon 11d ago
  I think this is more about the licence, the Rust rewrite just makes it easier to swallow/gain contributors.
- torginus 11d ago
  Yes, these proclamations of Rust devs that 'the future belongs to us', aren't getting any new fans for the language. Here's my rebuttal: YOU have proclaimed the language to be as fast as C while being safe. YOU need to prove it. Think of this as an OPPORTUNITY to PROVE that Rust can walk the walk, and you can make Rust coreutils as fast as the C one. Think hard about how you can model low level Linux constructs safely. Fix your libs. Fix the compiler. This is the yardstick you need to meet. You are making free software, and the thing about it is users are free to choose otherwise. YOU need to prove that Rust is just as fast and lightweight as C, and once you do, we'll be happy to adopt. Right now, dear Rust devs, what you are doing is the same as AI companies are doing - you're trying to usurp power based on extremely nebulous conjured threats. Nobody likes being threatened.
  - deleted 10d ago
    [deleted]
tcfhgj 11d ago
I bet you don't know the reason for existence
timcobb 11d ago
> The reason for existence of uutils is ideological, not technical. which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.
- pessimizer 11d ago
  Rewrite it in anything that isn't GPL.
  - timcobb 11d ago
    With the motivation of then being able to use it in closed or non-GPL products down the line?
- jeltz 11d ago
  > Are people saying that there's an ideology of pushing rust for things without concern for quality? Yes, there is. There are people who genuinely think quality does not matter as log as it is written in Rust as Rust is memory safe.
  - timcobb 11d ago
    > There are people who genuinely think quality does not matter as log as it is written in Rust as Rust is memory safe. Is this hyperbolic? Such people are in leadership places?
- steveklabnik 11d ago
  The original authors of uutils do not particularly care about licensing, and the Rust ecosystem defaults to MIT/Apache2. So they chose that. Many people have decided that this decision supposedly specifically about licensing ideology. You can make up your mind about which of the two you believe. See also, for Ubuntu's take on this: https://news.ycombinator.com/item?id=49707948 https://news.ycombinator.com/item?id=49707948

estebank 12d ago

> last I looked[1] (which was a few years ago) You weren't kidding: it was exactly 4 years ago ("September 13, 2022").

Freaky 11d ago

Neat. I touched this code about 8 months later to avoid the per-block elapsed() call: https://github.com/uutils/coreutils/commit/cf7b90bbe7cb87099499876622f413a65a699038 https://github.com/uutils/coreutils/commit/cf7b90bbe7cb87099... Mirrored the way I implemented status=progress in FreeBSD dd, though there the flag was set by a SIGALRM timer: https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751af6c883dce141736542f https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751... It would appear GNU dd 9.9 still does a call for every block. Low-hanging fruit if anyone fancies it: dd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes transferred in 18.644004 secs (2746191200 bytes/sec) target/release/dd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes (51 GB, 48 GiB) copied, 20.8772 s, 2.5 GB/s gdd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes (51 GB, 48 GiB) copied, 23.6744 s, 2.2 GB/s