upvote

points

by theteapot2 days ago |
comments
upvoteby collinfunk1 days ago|
next
[-]
At the current moment I would be against it. The language and library is changing too fast. Also, Rust has some other things that make it hard to use for coreutils. For example, Rust programs always call signal (SIGPIPE, SIG_IGN) or equivalent code before main(). There is no stable way to get the longstanding behavior of inheriting the signal action from the parent process [1]. This is quite annoying, but not unique to Rust [2].

[1] https://doc.rust-lang.org/beta/unstable-book/compiler-flags/... [2] https://www.pixelbeat.org/programming/sigpipe_handling.html

reply
upvoteby safercplusplus1 days ago|
parent|
[-]
I think the concern is that the writing may be on the wall for (the current memory-unsafe version of) Coreutils. Despite the bugs and incompatibilities, Canonical seems to have decided that the memory safety of uutils is worth it. And those two downsides, the bugs and incompatibilities, will likely attenuate quickly, compelling the other distros to follow suit in adopting uutils before long.

So the continued popularity of Coreutils might, I think, depend on Coreutil's near-term publicly announced and actual memory safety strategy. As I suggested in my other comment, there are (somewhat nascent) options for memory safety that do not require a rewrite of the code base. (For linux x86_64 platforms, depending on your requirements, that might include the "fanatically compatible" Fil-C.) And given the high profile of Coreutils, there are likely people willing to work with the Coreutils team to help in the deployment of those memory safety options.

reply
upvoteby wpollock1 days ago|
prev|
next
[-]
Thomas Jefferson famously said that "A coreutils rewrite every now and again is a good thing". Or something like that.

When I was a beta tester for System Vr2 Unix, I collected as many bug reports as possible from Usenet (I used the name "the shell answer man". Looking back I conclude that arrogance is generally inversely proportional to age) and sent a patch for each one I could verify. Something like 100 patches.

So if this rust rewrite cleans up some issues, it's a good thing.

reply
upvoteby greatgib1 days ago|
prev|
[-]
The rewrite in Rust is mostly vanity and marketing but not based on a real technical need...

So I don't see why they would want to do that.

reply
upvoteby kibwen1 days ago|
parent|
next
[-]
Canonical's usage of uutils is likely for marketing. But the codebase itself was developed for fun, as an excuse for people to have a hands-on way to learn Rust back before Rust was even released, with a minor justification as being cross-platform. From the original README in 2013:

Why?

----

Many GNU, linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to windows. However those projects are either old, abandonned, hosted on CVS, written in platform-specific C, etc.

Rust provides a good platform-agnostic way of writing systems utils that are easy to compile anywhere, and this is as good a way as any to try and learn it.

https://github.com/uutils/coreutils/blob/9653ed81a2fbf393f42...

reply
upvoteby PunchyHamster1 days ago|
parent|
next
[-]
>Canonical's usage of uutils is likely for marketing

Currently their usage is actively worsening the security of their distro

reply
upvoteby Avamander1 days ago|
parent|
next
[-]
These things were caught and basically all of them weren't covered by any test suite (not even GNU coreutils'). It's a bit bold to claim that it's actively worsening it when it's not an LTS.
reply
upvoteby ok1234561 days ago|
parent|
next
[-]
That's generally what you call introducing new semantic bugs.
reply
upvoteby pseudalopex1 days ago|
parent|
prev|
[-]
> It's a bit bold to claim that it's actively worsening it when it's not an LTS.

It is LTS now. And not LTS releases are releases.

reply
upvoteby dapperdrake1 days ago|
parent|
prev|
[-]
Welcome to building something new.
reply
upvoteby ragall1 days ago|
parent|
[-]
New things can be made optional and tested outside production, and should not be rolled out in an LTS edition.
reply
upvoteby thesuperbigfrog19 hours ago|
parent|
[-]
>> should not be rolled out in an LTS edition.

The Rust coreutils were first rolled out in the previous release which was not LTS:

https://canonical.com/blog/canonical-releases-ubuntu-25-10-q...

reply
upvoteby ragall16 hours ago|
parent|
[-]
That was for 6 months only and in an intermediate version that many don't update to, especially in production environments.
reply
upvoteby dapperdrake1 days ago|
parent|
prev|
[-]
Isn't this how Kernighan and late Ritchie (K&R) ended up with unix and C?

Honestly, brilliant guys.

When C got its own standards committee they even rejected Ritchie's proposal to add fat pointers to C before it was too late to add them. Instead, we got the C abstract machine.

reply
upvoteby pxc1 days ago|
parent|
prev|
[-]
I thought it was a learning exercise, and maybe some corporations also like it because it has more permissive licensing.
reply