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

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.

I think this is more about the licence, the Rust rewrite just makes it easier to swallow/gain contributors.

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.

Same here. Love Rust. Hate rust rewrites.

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.

The worst thing about rust are the people using it.

My impression is that go developers moved to rust.

I doubt it, as Rust approach to language design is the antithesis of Go's culture.

I would appreciate Go much more otherwise.

> 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.

> 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.

> 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?

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

As I have told the authors privately, I find it quite difficult to take their claim that they "don't care about licensing" seriously. 13/14 of the projects under uutils are relicensing GNU or GPL'd software. The other one, shadow-rs, is totally vibe-coded, and the README mistakenly says the original shadow is GNU software under the GPL, which is neither true. If 14/14 are relicensing, or in that one case, what is thought to be relicensing, the simple explanation is that it is an explicit goal of the project.

Beside the license thing mentioned, rust folks are obsessed with an idea of memory safety to an extent of discarding every other value in programming. To the extent of considering other choices "immoral". This manifests in their disproportionate initiatives of rewriting otherwise fine programs. Of course this doesn't include copious amounts of unsafe in popular libraries because can't leave any benchmarks defeated. But somehow Go is sinful because multiword data races are theoretically memory unsafe (a property which has led to zero (0) CVEs). This may also be the result of jealousy that something plebian like Go became more popular than their perfectly designed language.

Let's not mention other aspects of security, such as the recent supply chain issue, or the old story of the serde maintainer shipping a binary blob just because...

> To the extent of considering other choices "immoral".

This is literally an /r/pcj meme.

What is /r/pcj? In any case, memes start due to real world examples.

Rewrite it in anything that isn't GPL.

With the motivation of then being able to use it in closed or non-GPL products down the line?

I bet you don't know the reason for existence

> last I looked[1] (which was a few years ago)

You weren't kidding: it was exactly 4 years ago ("September 13, 2022").

Neat. I touched this code about 8 months later to avoid the per-block elapsed() call: 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/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