GNU Coreutils 9.2 - Now Avoids cp/mv Allocating Too Much Memory

[ultimA]

uutils only exists because they are MIT licensed. That's it.

While that can be seen as an advantage, that's not even the reason why it exists. The project author has publicly stated uutils exists because he wanted to get practice using Rust. That's all. He had no problems with coreutils' performance or security or with whatever aspect, he was just basically bored and interested in getting some practice.

And then fanbois jump in and start recommending it over Coreutils that has been tested and scrutinized for decades, has been working exceptionally well for everybody, and is actively maintained by an experienced group of people. That's Rust-fan logic.

[hax0r]

There is an alternative I switched to a while back: https://github.com/uutils/coreutils

May I recommend Programming Socks to complete your Rust experience.

[caligula]

And no don't mention "safety", because Coreutils is not ridden with vulnerabilities. It only had about 10 CVEs in total in the past 20 years

Still, 0 < 10.

[stormcrow]

1) Oh yeah, and what actual benefits did you experience in practice? Oh right, none. And no don't mention "safety", because Coreutils is not ridden with vulnerabilities. It only had about 10 CVEs in total in the past 20 years (see). And most of them weren't even memory safety bugs and thus would not have benefited from Rust anyway.

2) The article and thus this thread is about the new version and the new capabilities of Coreutils 9.2. Does your alternative already support the same features? If not why are you hijacking this thread to advertise a different project that's not even superior at this point?

Rust is such a cool language, but burdened by its fanatical and non-sensical fanbase.

God you people need to stop it with the irrelevant apologizing for legacy code bases. It only takes one single memory based bug to cause a security incident. Period. ONE. That's literally (in the true and traditional sense of literal) statistically inevitable with C or C++. End of story. Drop the damned mic. People with half a brain and far more credibility than anyone on this forum are recognizing this problem for what it is, rather than sticking their fingers in their ears and trying to shout people down for stating the utterly obvious.

While it's true that Rust does not by itself solve all logic problems, there's an added benefit of taking an old code base and working out the logic to it which can identify flaws others have missed. There are other tools that most programmers don't use, even if they know about them, that helps with logic problems. That's strike two on most software projects, because so few even know how to create a visual program flow chart. It's a learned skill that many discount to their detriment. I don't care how much extra time it takes to verify logic paths. We're long past the time where this step matters. It absolutely does matter in a security sensitive world outside of the insular world of hobbyist programming. It actually matters even if all your doing is writing a small hobby program for an Arduino, but since those bugs usually only affect one person, it's less of a problem to the rest of the world... till that hobbyist thinks he can write something bigger and duplicates those same mistakes in the published software and other people naively copy it (like most hardware sample code).

The Rust UUID project may not be the long term replacement for coreutils, but that doesn't really matter. There does need to be a long term replacement at some point simply because more problems in the legacy coreutils are statistically inevitable. It's a legacy C code base and some of those will be exploitable. Security is about layers. Languages that curtail the most common and often easily exploitable mistakes programmers can make means statistically less problems in the future. As far as resources are concerned, it's far easier to fix problems before they're ever released than to fix them afterwards and hope the patch trickles out where it needs to go (and again, statistically this doesn't actually happen).

[jacob]

Rust is such a cool language, but burdened by its fanatical and non-sensical fanbase.

Stupid fanbois who make grand statements about technology without actually understanding or using it are everywhere, it's not specific to Rust. Those people are not better nor worse than the C fanbois who dissert about "good programmers" etc.

[Rallos Zek]

There is an alternative I switched to a while back: https://github.com/uutils/coreutils

Shame about the license.

[skeevy420]

Shame about the license.

Why? It's the same license that AMDGPU uses, is a preferred license of the Linux kernel, and GNU has stated it's GPL compatible.

[dlq84]

1) Oh yeah, and what actual benefits did you experience in practice? Oh right, none. And no don't mention "safety", because Coreutils is not ridden with vulnerabilities. It only had about 10 CVEs in total in the past 20 years (see). And most of them weren't even memory safety bugs and thus would not have benefited from Rust anyway.

2) The article and thus this thread is about the new version and the new capabilities of Coreutils 9.2. Does your alternative already support the same features? If not why are you hijacking this thread to advertise a different project that's not even superior at this point?

Rust is such a cool language, but burdened by its fanatical and non-sensical fanbase.

He simply said he switched coreutils... You are the one that looks fanatical here...

[ClosedSource]

Still, 0 < 10.

Rust doesn't eliminate algorithm mistakes. It does an excellent job at turning many memory related and data structure issues from runtime to compile time which eliminates a lot of attack surfaces. But don't expect it to bring vulnerabilities anywhere near 0. There will never be any technology that automatically prevents all vulnerabilities, otherwise everyone would blindly use it.

[acobar]

God you people need to stop it with the irrelevant apologizing for legacy code bases. It only takes one single memory based bug to cause a security incident. Period. ONE. That's literally (in the true and traditional sense of literal) statistically inevitable with C or C++. End of story. Drop the damned mic. People with half a brain and far more credibility than anyone on this forum are recognizing this problem for what it is, rather than sticking their fingers in their ears and trying to shout people down for stating the utterly obvious.

While it's true that Rust does not by itself solve all logic problems, there's an added benefit of taking an old code base and working out the logic to it which can identify flaws others have missed. There are other tools that most programmers don't use, even if they know about them, that helps with logic problems. That's strike two on most software projects, because so few even know how to create a visual program flow chart. It's a learned skill that many discount to their detriment. I don't care how much extra time it takes to verify logic paths. We're long past the time where this step matters. It absolutely does matter in a security sensitive world outside of the insular world of hobbyist programming. It actually matters even if all your doing is writing a small hobby program for an Arduino, but since those bugs usually only affect one person, it's less of a problem to the rest of the world... till that hobbyist thinks he can write something bigger and duplicates those same mistakes in the published software and other people naively copy it (like most hardware sample code).

The Rust UUID project may not be the long term replacement for coreutils, but that doesn't really matter. There does need to be a long term replacement at some point simply because more problems in the legacy coreutils are statistically inevitable. It's a legacy C code base and some of those will be exploitable. Security is about layers. Languages that curtail the most common and often easily exploitable mistakes programmers can make means statistically less problems in the future. As far as resources are concerned, it's far easier to fix problems before they're ever released than to fix them afterwards and hope the patch trickles out where it needs to go (and again, statistically this doesn't actually happen).

https://github.com/uutils/coreutils/issues

As it is repeated to the core, there is no magic language that will make your code behaves ... magically. Perhaps, your experience is different from mine, but on projects I was specially interested, they didn't really "examine" the source, they didn't reap the "benefit of taking an old code base and working out the logic to it which can identify flaws others have missed", they took the general ideas, the options used (its interface), and went on to try to reproduce the expected behavior. This is perfectly valid, even more from the developer POV, as it is a very good opportunity to learn the ins and outs of the selected tool, but all this scaremongering about "it is in C so, burn, burn it!" is, being frank, idiotic.

Old, important and of widespread use, source code trees don't survive for nothing, they were tested humongous times, and survived even the change of the creator/maintainer. Were them low quality, no one would step in "as times goes by" or the code would be "refactored". You can see this on really complex computing needs, may you had followed the changes on Fortran code trees (yes, many things on computing are an interface layer for "damn old" Fortran source code trees that kept improving), or C code trees that were under constant maintenance.

Rust is a nice language (even if a bit exotic here and there) and it does have many benefits when compared to C, especially for tasks needing asynchronous and multithreading logic, but you are fooling yourself ignoring what "old and maintained" really means for practical cases.

The beautiful thing about open source projects, is that they let people interested take a look and decide if they are worth their time, even if only to report a bug and submit a single patch. Sometimes, some even adopt the code trees or became contributors. Sometimes, they scrap all and start new projects, because they didn't like what they saw.

In the end, the "better" open source code tree has a greater chance to prevail, or something so, they said to me.