Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

If we replace GNU coreutils[1] with this, could we finally call it "Linux" instead of "GNU/Linux"?

[1] And gcc with clang when bootstrapping



view as:

Is getting rid of GNU that important?

About as important as keeping GNU, empirically.

I think the point of this project is less about getting rid of GNU, and more about promoting Rust.

There's nothing wrong with GNU coreutils.


https://www.cvedetails.com/vulnerability-list.php?vendor_id=.... 4 vulns in the past decade that rust wouldn't have had.

It would be nice to have a totally memory safe userland, but it's at least worth noting that most of cureutils is generally not going to be working with attacker controlled data in a way that really matters.

Again, would be nice, just not where I'd start. But kudos to anyone doing the work.


4 vulnerabilities in 10 years sounds like a fantastic record, considering that the coreutils as a singular package has been around for 20 years (and the original tools for far, far longer). That's twice as long as Rust has been around.

Not to mention that memory safety is just one aspect of security. Rust's ownership model might have prevented those 4 vulnerabilities, but that doesn't mean that a whole host of others couldn't have slipped through.


If 4 vulns in 10 years for 1 package is acceptable, you are accepting that your OS will constantly have bugs. Sure there are other security problems than memory safety, but of the exploitable bugs, buffer overflows of some sort account for a majority.

My OS does constantly have bugs. It would be pretty unreasonable to say that my OS should never have bugs because of the practical impossibility of delivering perfectly bug-free software. So if people, after 10 years of trying, only found 4 critical vulnerabilities in all of coreutils, then that seems pretty good to me.

Rust itself has had 9 CVEs relating to memory safety in 2021 alone[0], which you can justify because Rust's development is highly active.

https://www.cvedetails.com/vulnerability-list/vendor_id-1902...


Recently there's been some folks "backfilling" CVEs. For example, the last one on that list was filed in 2021, but was fixed in 2015. The second to last one was filed in 2021, but was fixed in 2020.

What would motivate someone to do that? Sounds misleading to file a bunch of CVEs years after the fact.

The idea is, a lot of tooling relies on the CVE system to determine if a system is vulnerable, and so making sure that there is an actual CVE filed for every security bug is a good idea for the robustness of said tooling.

At least, that's my understanding.


From a performance standpoint I love love trying them and eagerly seeing if I can replace the GNU tools. Its like using musl over glibc.

What kind of performance issues are you running into with GNU tools?

I installed rust implementations and they’re all just much faster

I’m not sure if this answers the “how important” question, but: a large part of the GNU ecosystem is functionally unmaintained. The various tools under binutils receive so few patches that they’ve been the standard punching bag for academic fuzzing research for the last 20 years, and the coreutils aren’t much better.

Most distros still use GNU libc but I guess you could build a distro with Musl and alt coreutils.

Yes:) In fact, if you're into that, I'd argue that Alpine is already not GNU/Linux, since it uses busybox and musl.

You’d have to call it “Rust/Linux”

Legal | privacy