The title is bs. There is no “push by Canonical”. A random person on the internet wrote Uutils in Rust because it’s easy to write fast code in it. Then Canonical wants to package the software but they aren’t “pushing”, they are just packaging software someone else wrote. Canonical’s goal is memory safety but that’s not the author’s goal because Coreutils haven’t got many vulnerabilities anyways.

The licensing part is sort of sad. The author picked MIT, because he does not care. He also said that he does not want drama. Well he did get the drama. The sad part is that I think that he would be willing to change the license to GPL, had it not been for all the childish drama and “hate”. Communication is difficult for people online, unfortunately.

I posted 2 years ago about the same concerns on /r/StallmanWasRight and the lemmy rust community. Many dismissed it as a conspiracy theory … Not that I agree with the form and language used in this article but ditching GPL coreutils from prominent distros is a turning point and slippery slope for Free Software and Linux.

some untested stuff controlled by proprietary software of Microsoft?

AFAIK, Rust is mainly funded by the Rust Foundation, which not only includes Microsoft, but also includes comrades from Huawei and alike.

The article is clearly mostly manipulative bullshit. The arguments about “incompatibilities” between uutils and coreutils being used as an “extend” strategy is just bonkers, the point of uutils is to be a 1-to-1 compatible toolset, and there’s no reason to doubt the developer’s intention there. Even if they do introduce some extra features, most software projects that actually matter will not be using them, because compatibility with coreutils will remain important for decades to come.

The kernel of truth hiding in there is that Rust’s “preferred” licensing under MIT/Apache is indeed a problem, and it should have been GPL (or at least MPL) everywhere from the beginning, especially for libraries. This is probably the worst aspect of Rust indeed, but not enough to outweigh all the awesome technical parts of it.

Nope. Not reading a Techrights article.

I don’t really buy the “small incompatibilities” argument. The project strives for total compatibility, even down to the most esoteric parameter that nobody has ever heard of. And even that seems like overkill to me - there are alternative implementations of core commands on Linux and other *nix systems like BSD, Solaris etc. where the compatibility is way worse. For example, busybox is used in embedded Linux, and a containerized images like Alpine Linux.

It also seems a bit rich to complain that uutils might get extended. GNU coreutils came into being because of dissatisfaction with the commands that came with the default *nix. Same for bash (vs sh), GNU cc (vs cc), GNU emacs (vs emacs) and so on. Was there somebody back then complaining about devs “spamming commits” that extended functionality?

And other Rust applications won’t only work with uutils. That’s absurd. They’ll test the capabilities of the OS they’re built to run on either at build time with feature flags or at runtime by probing commands. Just like any other high level application.

As for license, MIT is used for plenty other things in a typical Linux dist, e.g. X11.

The biggest point of concern for a Rust rewrite is dependency integrity. Rust uses cargo to manage dependencies and absolutely everything in the Cargo.toml/Cargo.lock files has to be reviewed. The crates.io repository is beginning to support package signing and The Update Framework initiative but every single dependency of uutils would need to be carefully reviewed and signature validated for it to be considered trustworthy. Basically everything needs to get locked down, and wherever possible dependencies expunged altogether.

I’m really not a fan of this whole rust movement. Statically linked binary, no ta.

I’ve started looking for another c/c++ based shell to go back to, now that fish has moved to rust (ideally ones that follow xdg config specs etc). Ysh (oils) is current choice.

Fuck that entirely

Finally, some legitimate critique of Rust, that does not revolve around “DEI bad” or “memory safety bad”!

Both can be criticized within reason. Yes, there’s that infamous Rust dev, who likes to sabotage projects she’s involved with the moment things don’t go the way she wants it, thinks the word “cancer” is somehow a slur, and of course loves to send her followers after people for various reasons, often while purposefully misinterpreting people’s words. All while spreading either the evopsych “extreme female brain theory of borderline personality disorder” nonsense, or the “cluster B abuse” nonsense made up by far-right theologists masquerading as psychologists to explain trans people on the terms of christian fundamentalism and without allowing them to live life as they want. This (nor other similarly bad Rust devs, nor callout culture in general, nor other things like the whole “master” branch fiasco with Github) does not mean we need to throw out the baby with the bathwater, like Brian Lunduke and other far-right adjacent people want us to do, all while pretending their position is the “centist” one, because “real fascists did those things for the sake of pure evil, but we have good reasons to do those very same things, like crime statistics and IQ tests”.

Same with memory safety. We usually get the “skill issue” type of critique, meaning “just write better code”. I personally prefer D’s approach to memory safety with its multi-level solution alongside with the much nicer code for the unsafe stuff. And I guess Rust also have something similar to D’s --noboundscheck compiler flag as a way to disable boundschecks in times it’s needed.

This all creates a situation I’ve first seen unfolding during the whole gamergate culture war fiasco. Thanks to burnt out atheist YouTubers making bad faith critique of Anita Sarkeesian’s videos lead to the rebrand of Morality in Media to NCOSE and the formation of Collective Shout, which ultimately lead to the whole payment processor censorship issue. Thanks to alt-right chuds constantly misgendering and sending death threats to Brianna Wu enabled a racist abuser to hide within our circles. And thanks to chud developers wanting to “give real treatment to gender confused people” and wanting to “gatekeep” software development from newbies, actual critiques of the Rust language, such as a heavily OCaml-influenced language being sold as a C replacement (if not a C++ replacement - all without true built-in OOP support), or the fact a functional programming language is being sold as a general purpose language, all because “you can opt out” (Java also technically allows you to opt-out from most OOP features).

Neigsendoig (my producer) and I are very used to the C-based GNU utilities. Rust is not up our alley, that’s for sure.