Rust-Written Coreutils Increases GNU Compatibility, Adds NetBSD Support

[ALRBP]

I am wondering where this urge to rewrite a project in Rust comes from, may be from the original desire to write it in C?

Maybe from all theses security issues related to memory management.

[wswartzendruber]

I am wondering where this urge to rewrite a project in Rust comes from, may be from the original desire to write it in C?

Those of us who have had to stay up at night patching operating systems have grown a little impatient with pointer arithmetic and the general insanity proposed by the C language.

[Developer12]

BUG: Not GPL... hence not an Gnu coreutils replacement.

You're right, it's far superior. :P

obvious bait is obvious.

[fitzie]

BUG: Not GPL... hence not an Gnu coreutils replacement.

toybox is pretty good choice. after reading his experience dealing with GPL (he was the busybox maintainer for many years), it's clear that GPL is a dead license now. FSF basically forking it with GPLv3 put the final nail in the coffin.

[Developer12]

BSD world will have orgasms with this, as they hate GPL.

I'm quite surprised there aren't massive contributions from BSD world!

What about findutils? No mention of them.

https://github.com/uutils/findutils

Gee, you make it sound like the whole world (linux, netbsd, etc etc) using the same secure, faster, less 1980's-crusty implementation would be a bad thing.

Did you miss the recent GNU memory bug that handed out root to everyone who asked? https://www.phoronix.com/news/Glibc-LD-Nasty-Root-Bug
How about the recent buffer overrun in curl that overwrote the heap with received data? https://www.phoronix.com/news/Curl-8.4-Coming

Turns out it's true what we knew from the very beginning: C sucks ass when it comes to security, and GNU ain't about to rewrite their 40-year-old crusty stack of shit. Even if they did, anyone running BSD (opensense edge firewalls, anyone?) wouldn't be able to benefit. There's no value in making basic components available to only a select few.

[fitzie]

Maybe from all theses security issues related to memory management.

it was a project born out of trying to learn rust. One of the reasons I don't really care for it is that it pulls in random crates, which is an inappropriate attack surface, especially since it's often used by root user. Spoke to their devs about it and they didn't seem to be worried about that, and argue that it's needed because they want to support all platforms including windows, and don't have the skill/time to write all the crossplatform code themselves.

I'm sure uutils will find some fans, but I really want the coreutils I use to be the more boring project in the world, given it's criticality.

[Developer12]

it was a project born out of trying to learn rust. One of the reasons I don't really care for it is that it pulls in random crates, which is an inappropriate attack surface, especially since it's often used by root user. Spoke to their devs about it and they didn't seem to be worried about that, and argue that it's needed because they want to support all platforms including windows, and don't have the skill/time to write all the crossplatform code themselves.

I'm sure uutils will find some fans, but I really want the coreutils I use to be the more boring project in the world, given it's criticality.

How do you trust any of the contributors to GNU? how do you trust the kernel you're using? Any upstream can have malicious contributions. By having everyone in the entire rust ecosystem pulling from and keeping an eye on the same package for parsing command line options, you have all the eyeballs on one implementation, rather than 20 or so implementations spread across different projects.

When projects "vendor" libraries by copying code directly into their tree it also becomes impossible to keep track of who has made a copy, and of what version. With shared code repositories you know immediately who's using a library which is invaluable when a bug is discovered and you need to get the word out. In all likelihood people will probably get the bugfix automatically when their build system pulls a new version.

You ALSO solve the problem of everyone writing their own shitty parsers and allocators and red-black trees. Everyone automatically ends up using the best implementation available, rather than one that was written by some dude 7 years ago and forgotten about.

The only reason vendoring libraries or writing them yourself is "boring" is because you end up utterly ignorant of their problems.

[skeevy420]

I am wondering where this urge to rewrite a project in Rust comes from, may be from the original desire to write it in C?

It's from all the salt in the C. Just the natural evolution of things.

[jstoik]

One of the reasons I don't really care for it is that it pulls in random crates, which is an inappropriate attack surface, especially since it's often used by root user.

My thoughts exactly. This project has more than 100 third-party build/runtime dependencies, and Rust's various safety and compatibility guarantees simply do not apply to any of them.

They might all be perfect and memory-safe and well-considered and well-authored now and forever more, but I doubt it.

[EphemeralEft]

There's Swift for Apple stuff. AI stuff is happy using mostly Python. And I'm sure there's a place for Go in there, somewhere.
I am actually preparing a presentation about Go these days and at some point I had an epiphany: many (most?) languages are called "general purpose" these days, but while not "single purpose", they are so far off from being "general" anything - each tackles a number of problems better than other, but none tackle everything better.

There are 14 competing languages? Ridiculous! We need to develop one universe language that covers everyone's use cases.