Rust-Written Coreutils Replacement uutils 0.0.19 Released

[igxqrrl]

I have seen this argument before. Most modern languages have established default package systems unlike C. I'm curious about what would be the proposed alternative to have external dependencies. In tree copy? Reimplement them every time?

I've worked at big companies and I've worked at small companies, and it's interesting to see the difference in perspective here. The small companies tend to be very willing to pull things from teh internets in their build system, and the large companies are completely unwilling to do so.

Both have their advantages. One of my previous companies had a submodule from some server in the eastern bloc that was down about 0.5% of the time, just often enough to be problematic. That mentality also lends itself to using various APIs from all over.. We had dependencies on cloud CircleCI, TravisCI, and Github CI, along with API dependencies to Jira and elsewhere. It's a miracle system when it works well, and it's a nightmare when something somewhere goes wrong, and the guy who knows how it's all stitched together isn't there. A couple times in the very recent past Github has made on-the-fly changes to their checksum algorithm breaking builds all over the world. If you've got a team of 5 people that's not a big deal.

The big companies will only use FOSS stuff in their builds after legal reviews, technical reviews, etc.. and then will always host locally. Updating to a new version of a package may require a re-review of all that, and will probably take many months. It can be painful when you need a feature or bug fix, but the benefit is stability and some confidence that an audit won't find a hidden dependency with a license that you aren't allowed to use.

As an old, I am impressed by the dynamic approach but I have a strong appreciation for the latter. It creates a stable, reliable environment and when you've got 200 engineers who are blocked when something breaks, it's useful to not be reliant on services and repositories all over the world.

[ZeroPointEnergy]

I have seen this argument before. Most modern languages have established default package systems unlike C. I'm curious about what would be the proposed alternative to have external dependencies. In tree copy? Reimplement them every time?

I don't know what a good solution might look like, and apparent the same goes for everyone else, or we would not see the same issue in every new language. Doesn't invalidate the argument though.

[dremon_nl]

I have some serious reservations when it comes to this rust projects. On one side, it's nice that rust has language features that makes the programs more secure. On the other hand, it basically pull down 80 dependencies which makes it more vulnerable to supply chain attacks. I'm not convinced that is a win.

It' not a feature of the Rust language but of it's package manager (cargo). You can use public crates.io repository, custom repository, local vendored versions of audited dependencies or no dependencies at all.

[darcagn]

It really goes both ways though.

When I compile a Rust utility and it pulls down like 80 dependencies my gut tells me, "Jeez, well, there's no way this author is auditing all of these projects' changes!"
When I compile a C utility with no dependencies and see most of the tree hasn't been updated in years, my gut tells me "Ah, I love the rock solid stability of old C code bases."

But that's just my gut, thinking further about it, how many C programs have authors copy/paste code from random libraries in tree and never update them or audit them ever again? Do they track those code snippets and included files and go back and check against CVEs?

What it comes down to is Rust's Cargo is a more powerful tool. Its power allows the proactive, diligent maintainer update faster to eliminate vulnerabilities; its power allows the careless, lackadaisical maintainer to update faster and introduce attacks from the outside.

Ultimately sharing code as much as possible and giving it as many eyes as possible is the spirit of open source, and Rust's tools better facilitate that; its dependency locks and versioning system should mitigate most of the concerns people have as long as project maintainers don't overrely on dependencies and take auditing them more seriously

[RahulSundaram]

You don't have to pull any dependencies, you can always write and use your own code. It all comes down to whether you trust your own skills more than code that's out there, in the open.
Also, it's not like you pull those dependencies directly in prod. You can (and should) always audit the resulting binaries.

The bigger issue is re-implementing from scratch takes time which often equally money. Even in the C world, if someone wants to say, render a PNG image, they would just either declare a dependency on libpng (which has over two decades of development behind it) and/or bundle it and move on for the most part rather than spend their precious time re-implementing it from scratch regardless of their skills. Having a package manager like Cargo handle that just makes the choices more convenient especially for cross platform development and deployment. If you are worried about supply chain attacks, bundling in C code often lacks any of the metadata that makes it convenient to track upstream origin and local patches if any. So in many cases, it is the worse model.

[krzyzowiec]

When I compile a Rust utility and it pulls down like 80 dependencies my gut tells me, "Jeez, well, there's no way this author is auditing all of these projects' changes!"
When I compile a C utility with no dependencies and see most of the tree hasn't been updated in years, my gut tells me "Ah, I love the rock solid stability of old C code bases."

I don’t understand this mentality. If you use tests in your code, and you are performing validation where required, then what is there to worry about?

If their code changes in a way that could introduce instability in your code, that makes me think that you aren’t programming in an appropriately defensive manner.

I would code either as though I did not trust myself, or as though my tests are some kind of documentation or skeleton for my codebase.

[darcagn]

I don’t understand this mentality. If you use tests in your code, and you are performing validation where required, then what is there to worry about?

If their code changes in a way that could introduce instability in your code, that makes me think that you aren’t programming in an appropriately defensive manner.

I would code either as though I did not trust myself, or as though my tests are some kind of documentation or skeleton for my codebase.

That's just my gut reaction though, as I said. Upon actual reflection, and not just a fast reaction, I agree with you.

[bug77]

The bigger issue is re-implementing from scratch takes time which often equally money. Even in the C world, if someone wants to say, render a PNG image, they would just either declare a dependency on libpng (which has over two decades of development behind it) and/or bundle it and move on for the most part rather than spend their precious time re-implementing it from scratch regardless of their skills. Having a package manager like Cargo handle that just makes the choices more convenient especially for cross platform development and deployment. If you are worried about supply chain attacks, bundling in C code often lacks any of the metadata that makes it convenient to track upstream origin and local patches if any. So in many cases, it is the worse model.

Yeah, you'd think after a few decades people have figured out how dependencies work. Apparently not...

[mathletic]

Big companies are using Rust as an excuse to replace licenses like GPL with licenses they can get away with ...

For binaries like the core utils, GPL is no problem. Like with the Kernel. You don't modify these basic tools and sell them with profit. You don't link to these binaries. MIT and GPL makes no difference.

[RahulSundaram]

For binaries like the core utils, GPL is no problem. Like with the Kernel. You don't modify these basic tools and sell them with profit. You don't link to these binaries. MIT and GPL makes no difference.

I mostly agree with you but companies do prefer permissive licensed tooling even for basic tools. For instance, all the GPL enforcement actions around busybox (a minimal alternative to coreutils for embedded systems), resulted in Android and others moving to permissively licensed toybox instead. This isn't because they were selling busybox patches for profit but GPL enforcement for busybox was anchored for full GPL compliance for everything else that the vendor shipped and vendors did have other features in other components they were selling for a profit and compliance meant that they would lose that feature advantage potentially. Having said that the Rust rewrite in this case seems more like a passion project and nothing to do with organizations which already have plenty of other permissive licensed alternatives already.