Rust-Written Coreutils Replacement uutils 0.0.19 Released

[jacob]

You're correct as long as you only talk about the code itself and its qualities.

But it can become a nightmare when you need to confirm the legalities of all involved licenses. That's something commercial companies need to do. I see rust moving to a similar direction like JavaScript where a single function call can pull in over 20'000 legal dependencies.

You ALWAYS must do that, regardless of the language and regardless of whether you are a commercial entity or a hobbyist. But it's a fair point and it would in fact be a good feature if you would specify in cargo.toml the licences you accept for your dependencies.

[Quackdoc]

You're correct as long as you only talk about the code itself and its qualities.

But it can become a nightmare when you need to confirm the legalities of all involved licenses. That's something commercial companies need to do. I see rust moving to a similar direction like JavaScript where a single function call can pull in over 20'000 legal dependencies.

cargo-deny can handle dependancy licences, it's a great and lovely tool

[NobodyXu]

But it can become a nightmare when you need to confirm the legalities of all involved licenses.

cargo-deny can be used to deny any non-conforming license, ban certain crates and check advisories for CVEs.

https://github.com/EmbarkStudios/cargo-deny

I see rust moving to a similar direction like JavaScript where a single function call can pull in over 20'000 legal dependencies.

I don't see that, crates I use never pull in that many dependencies.
For http client like reqwest, they do have >20 dependencies with many being optional, including an optional dns resolver.

`getaddrinfo` from C can be used instead of that optional dns resolver, but given that how broken it is and it isn't even async, I'd like to stay away from it.

Plus, Rust unifies dependencies with the same major version (compatible ones) so it won't pull in many different minor versions of the same crate.

[Nth_man]

> > > [...] the Rust rewrite in this case seems more like a passion project and nothing to do with organizations.

> > seems.. mmm... Redox is written in Rust and received an "anonymous" (who is interested in paying that?) $400,000 donation

> Redox is unrelated to the topic. I specifically said, in this case ie) uutils.

Bringing up random crypo donations for an unrelated project is not evidence of any organization involvement in uutils or anywhere else for that matter.

It's not an unrelated project, we can read "Some suggest donating it to the folks responsible for Rust language, and some suggest using the money to sponsor learning rust and OS development.", and it's an example of "Rust rewrite in this case seems more like a passion project and nothing to do with organizations" not being that way.

And $400,000 is a random donation? I will stop now reading this pointless thread. So instead of losing time, we all can end up with the ability to do something productive. OK!

[NobodyXu]

Nth_man You seem like onto something.

Linux kernel and other open source projects get donation all the time and you don't seem to take an issue with it.
Why do you suddenly care so much about donation to Rust related open source projects?

You have a little bit merit regarding the lack of static analyzers in Rust prevent it from being used in certain scenarios, but now you are now just obsessed with conspiracies like "evil corp using Rust as an excuse to destroy GPL communities" while the commercials have embraced non-GPL open source license long before Rust is even created.

And not to mention, the static analyzers you listed is **not open-source** and cost a lot to use it.
I haven't heard any open source project using it, plus it will still require maintainers to rent a server to run it since it might take too long for Astree to run on GitHub Action and get cancelled by GitHub.

Plus, it would not be able to verify use of every external syscall or assembly to be "safe", just like Rust cannot do it.
That requires a lot more domain knowledge plus, many filesystem operations cannot be verified by static analyzer to be "safe", as it has no knowledge of the layout of the filesystem.

Astree claims to be the **fastest** static analyzer out there, so I can imagine all the other (open source) static analyzer to be even slower.

[EphemeralEft]

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.

There are an infinite number of situations where code could be executed; arbitrary user input, but also environment variables, system load, CPU micro-architecture, etc.

Unless you manually audit every single line of code, you’ll have no idea whether there’s a bug lurking in one of the infinite situations that you didn’t test for.

[mether]

It's not an unrelated project

You haven't show any relationship between uutils and Redox at all and none of Redox donations have gone into uutils. You are just bringing it up in a weak attempt to tie together unrelated projects just because they are written in the same language.

And $400,000 is a random donation?

Correct. It has nothing to do with uutils.

[mether]

There are an infinite number of situations where code could be executed; arbitrary user input, but also environment variables, system load, CPU micro-architecture, etc.

Unless you manually audit every single line of code, you’ll have no idea whether there’s a bug lurking in one of the infinite situations that you didn’t test for.

Realistically nobody does that in any language and underlying dependencies change all that time. Even if your code is mostly self contained, you are still likely depending on behavior from things like libc and the kernel. Unless you are never ever upgrading, the common solution is to protect yourself against things like arbitrary user input using defensive programming techniques and move on. Unless you are dealing with things like medical devices, the expectation is going to be far more reasonable than complete perfection. There is nothing language specific about any of this.

[EphemeralEft]

Realistically nobody does that in any language and underlying dependencies change all that time. Even if your code is mostly self contained, you are still likely depending on behavior from things like libc and the kernel. Unless you are never ever upgrading, the common solution is to protect yourself against things like arbitrary user input using defensive programming techniques and move on. Unless you are dealing with things like medical devices, the expectation is going to be far more reasonable than complete perfection. There is nothing language specific about any of this.

The person I responded to was defending the use of 80+ dependencies by saying that unit tests solved the inherent risks. I was refuting that specific argument.

[mether]

The person I responded to was defending the use of 80+ dependencies by saying that unit tests solved the inherent risks. I was refuting that specific argument.

The key factors in mitigating such risks isn't dependent on the number of dependencies. Cargo (and other language package managers) create a lock file that pins the dependency list so you are in control of the changes and have to own it as a whole.