3 ms·

Probably a dumb question, but is GNU Core utils interested in / planning on doing its own rust rewrite?

greatgib 6mo ago
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.
- kibwen 6mo ago
  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/9653ed81a2fbf393f420d9a8007c574d922018d1/README.md https://github.com/uutils/coreutils/blob/9653ed81a2fbf393f42...
  - PunchyHamster 6mo ago
    >Canonical's usage of uutils is likely for marketing Currently their usage is actively worsening the security of their distro
    - Avamander 6mo ago
      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.
      - ok123456 6mo ago
        That's generally what you call introducing new semantic bugs.
      - pseudalopex 6mo ago
        > 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.
    - dapperdrake 6mo ago
      Welcome to building something new.
      - ragall 6mo ago
        New things can be made optional and tested outside production, and should not be rolled out in an LTS edition.
        thesuperbigfrog 6mo ago
        >> 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-questing-quokka https://canonical.com/blog/canonical-releases-ubuntu-25-10-q...
        ragall 6mo ago
        That was for 6 months only and in an intermediate version that many don't update to, especially in production environments.
  - dapperdrake 6mo ago
    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.
- pxc 6mo ago
  I thought it was a learning exercise, and maybe some corporations also like it because it has more permissive licensing.
wpollock 6mo ago
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.
collinfunk 6mo ago
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/on-broken-pipe.html https://doc.rust-lang.org/beta/unstable-book/compiler-flags/... [2] https://www.pixelbeat.org/programming/sigpipe_handling.html https://www.pixelbeat.org/programming/sigpipe_handling.html
- safercplusplus 6mo ago
  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.

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.

kibwen 6mo ago
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/9653ed81a2fbf393f420d9a8007c574d922018d1/README.md https://github.com/uutils/coreutils/blob/9653ed81a2fbf393f42...
- PunchyHamster 6mo ago
  >Canonical's usage of uutils is likely for marketing Currently their usage is actively worsening the security of their distro
  - Avamander 6mo ago
    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.
    - ok123456 6mo ago
      That's generally what you call introducing new semantic bugs.
    - pseudalopex 6mo ago
      > 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.
  - dapperdrake 6mo ago
    Welcome to building something new.
    - ragall 6mo ago
      New things can be made optional and tested outside production, and should not be rolled out in an LTS edition.
      - thesuperbigfrog 6mo ago
        >> 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-questing-quokka https://canonical.com/blog/canonical-releases-ubuntu-25-10-q...
        ragall 6mo ago
        That was for 6 months only and in an intermediate version that many don't update to, especially in production environments.
- dapperdrake 6mo ago
  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.
pxc 6mo ago
I thought it was a learning exercise, and maybe some corporations also like it because it has more permissive licensing.

wpollock 6mo ago

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.

collinfunk 6mo ago

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/on-broken-pipe.html https://doc.rust-lang.org/beta/unstable-book/compiler-flags/... [2] https://www.pixelbeat.org/programming/sigpipe_handling.html https://www.pixelbeat.org/programming/sigpipe_handling.html

safercplusplus 6mo ago
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.