Rust Coreutils 0.1.0 Release(github.com)
github.com
Rust Coreutils 0.1.0 Release
https://github.com/uutils/coreutils/releases/tag/0.1.0
18 comments
That just highlights the major flaw in semver where marketing version and compatibility signal are in a single number. And their guidance on 42 is bad as well, which compounds the fear.
semver is very open about not having, or being, a "marketing version". It is its entire reason for being.
That’s a FAQ section, not the spec itself, so it’s not really in contradiction to the spec.
Yeah I feel you. So many projects do this nonsense.
They should relicense to the GPL, MIT doesn't preserve user rights. Seriously, I don't get what Rust projects' issue with Free Software is, providing free work that corporations can take and mangle into proprietary garbage is short-sighted.
MIT licensed software is also Free Software, as it follows the definition.
I find it so strange to see words like "preserve user rights" when advocating for a license that adds more restrictions over you.
The rust coreutils author said that he doesn't care about the license/rights of users. He just did it for the technical challenges.
> The rust coreutils author said that he doesn't care about the license/rights of users.
Cite?
Cite?
They won't. They deliberately made it permissive. How else are manufacturers like John Deere going to withhold the source from the farmers? Can't have them undoing those software locks, now!
> uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.
Is there a similarly comprehensive project that instead treats various bad api designs as bugs instead of preserving them for the future generations?
Is there a similarly comprehensive project that instead treats various bad api designs as bugs instead of preserving them for the future generations?
sbase and ubase from https://core.suckless.org maybe?
In a wider context maybe Plan 9 from user-space https://9fans.github.io/plan9port
In an even wider context the stuff https://chimera-linux.org does.
Also https://landley.net/toybox/status.html
In a wider context maybe Plan 9 from user-space https://9fans.github.io/plan9port
In an even wider context the stuff https://chimera-linux.org does.
Also https://landley.net/toybox/status.html
There's a far more powerful "yes" command written in Rust: https://github.com/jedisct1/yes-rs
It feels like we are on the cusp of finally having secure software after decades of C and C++ failing at every step.
I for one welcome our new blazingly fast coreutils and wait expecting a blazingly fast kernel to go right along with the fish shell.
I for one welcome our new blazingly fast coreutils and wait expecting a blazingly fast kernel to go right along with the fish shell.
What do you mean blazingly fast? I would assume Rust and C have roughly the same performance coming down to LLVM. I'm not convinced that coreutils need much security since they're almost never exposed and with the exception of sudo, shouldn't hold any extra privileges the user doesn't already have. I do welcome new implementations though, competition is always good
One part of the answer is rust's borrowing provided assurances that make it possible to clone less. The type system guarantees immutability in a lot of cases.
For small scale examples this doesn't mean much, but larger software gains a few percents for free.
This argument is cultural, not technical. I presume it is possible to write e.g. C++ classes with similar guarantees. But it is work you get for free in rust, so in practice it almost only happens there at scale.
For small scale examples this doesn't mean much, but larger software gains a few percents for free.
This argument is cultural, not technical. I presume it is possible to write e.g. C++ classes with similar guarantees. But it is work you get for free in rust, so in practice it almost only happens there at scale.
It’s a bit of a joke, everything rust does is “blazingly fast” and has almost become a meme at this point. Though it does seem to trend towards well performing programs on the whole.
I meant the rest though in a more serious manner.
I meant the rest though in a more serious manner.
Those coreutils are being included in Ubuntu, call them 1.0! It's fine, you still have a countable infinity of version numbers if you need to make changes, even incompatible ones!
[1]: https://semver.org/#how-do-i-know-when-to-release-100
> If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.