6 ms·

Im okay with this. This is how we find out issues. As long as these are sorted before the LTS release, no problem.

rustdebacletime 11mo ago
[flagged]
StopDisinfo910 11mo ago
You are ok about the core utils being replaced by a rewrite for no obvious reason and said rewrite being so broken that an allegedly stable distribution actually can’t properly update? I mean, all good then.
- perching_aix 11mo ago
  > for no obvious reason One can say a lot about the reason, but that it would not be obvious, is certainly an unlikely one.
- atoav 11mo ago
  My expectation would be that every bug in a Rust replacement is going to receive the brightest spotlight that can be found. If the rest of coreutils is bug free cast the first stone. I do not think reimplementing stuff in Rust is a bad thing. Why? Because reimplementing stuff is a very good way to througly check the original. It is always good to have as many eyeballs om the code as possible.
  - StopDisinfo910 11mo ago
    Replacing battle tested software with untested rewrite is always a bad idea even if the rewrite is written a trendy language, key word being untested. I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler.
    - orangeboats 11mo ago
      > I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Some checks are pretty much impossible to do statically for C programs because of the lack of object lifetime annotations, so no, this statement can't be right. It is true that the borrow checker doesn't prevent ALL bugs though. Furthermore, the "bug" in this case is due to an unimplemented feature causing a flag to be silently ignored... It's not exactly something that any static analyser (or runtime ones for that matter) can prevent, unless an explicit assert/todo is added to the codepath.
      - StopDisinfo910 11mo ago
        Well, you can annotate C code to do a lot more than lifetime annotations today. The tooling for C analysis is best in class. And even without annotations, you can prove safe a lot of constructs by being conservative in your analysis especially if there is no concurrency involved. Note that I wasn't specifically commenting about this specific issue. It's more about my general fatigue regarding people implying that rewrite in Rust are always better or should be done. I like Rust but the trendiness surrounding it is annoying.
        unscaled 11mo ago
        You can do a lot of things. Yes, there are formally verified programs and libraries written in C. But most C programs are not, including the GNU coreutils (although they are battle-tested). It's just the effort involved is higher and the learning curve for verifying C code correctly is staggering. Rust provides a pretty good degree of verification out-of-the-box for free. Like any trendy language, you've got some people exaggerating the powers of the borrow checker, but I believe Rust did generally bring out a lot of good outcomes. If you're writing a new piece of systems software, Rust is pretty much a no-brainer. You could argue for a language like Zig (or Go where you're fine fine with a GC and a bit more boilerplate), but that puts even more spotlight on the fact that C is just not viable choice for most new programs anymore. The Rewrites-in-Rust are more controversial and they are just as much as they are hyped here on HN, but I think many of them brought a lot of good to the table. It's not (just?) because the C versions were insecure, but mostly because a lot of these new Rust tools replaced C programs that had become quite stagnant. Think of ripgrep, exa/eza, sd, nushell, delta and difft, dua/dust, the various top clones. And these are just command line utilities. Rewriting something in Rust is not an inherently bad idea of what you are replacing clearly needs a modern makeover or the component is security critical and the code that you are replacing has a history of security issues. I was always more skeptical about the coreutils rewrite project because the only practical advantage they can bring to the table is more theoretical safety. But I'm not convinced it's enough. The Rust versions are guaranteed to not have memory or concurrency related bugs (unless someone used unverified unsafe code or someone did something very silly like allocating a huge array and creating their own Von Neumann Architecture emulator just to prove you can write unsafe code in Rust). That's great, but they are also more likely to have compatibility bugs with the original tools. The value proposition here is quite mixed. On the other hand, I think that if Ubuntu and other distros persist in trying to integrate these tools the long-term result will be good. We will get a more maintainable codebase for coreutils in the future.
  - misja111 11mo ago
    Yes I also think that bugs in a Rust replacement will receive more attention than other bugs. Why? - the cult-like evangelism from the Rust community that everything written in Rust would be better - the general notion, that rewriting tools should bring clear an tangible benefits. Rewriting something mostly because the new language is safer will provoke irritation and frustration with affected end-users when the end product turns out to introduce new issues
    - pdimitar 11mo ago
      So, reducing CVEs is not a tangible benefit?
      - alextingle 11mo ago
        Rewriting old known good code from scratch is going to create more CVEs. This rewrite project is about corporations escaping from GPL code. It's got nothing to do with security.
        pdimitar 11mo ago
        Somebody linked a comment from an Ubuntu maintainer where they said they want more resilient tools. If license was the only concern then I'd think that they wouldn't switch the programming language? And yeah, obviously using Rust will not eliminate all CVEs. It does eliminate buffer overflows and underflows though. Not a small thing. Also I would not uncritically accept the code of the previous coreutils as good. It got the job done (and has memory safety problems here and there). But is it really good? We can't know for sure.
  - egorfine 11mo ago
    > reimplementing stuff is a very good way to througly check the original Problem is, they unironically want to replace coreutils with their toy. And they just did.
- compiler-devel 11mo ago
  They’re okay with it because the rewrite is in their preferred language.
  - StopDisinfo910 11mo ago
    I have no opinion whatsoever on the rewrite. It might be the best thing since sliced bread for all I know. I have trouble with integrators recklessly shipping untested dependencies however.
    - timeon 11mo ago
      > It might be the best thing since sliced bread Can someone explain to me this analogy? Because I consider sliced bread as decline. But maybe that is cultural thing.
      - JodieBenitez 11mo ago
        There you go: https://time.com/3946461/sliced-bread-history/ https://time.com/3946461/sliced-bread-history/ (yes, I don't really get it either)
      - dgb23 11mo ago
        A knife that both slices and toasts the bread at the same time would be even better!
        fainpul 11mo ago
        https://www.youtube.com/watch?v=kcjGRXTpHGI https://www.youtube.com/watch?v=kcjGRXTpHGI
        danudey 11mo ago
        Knew what absolute disaster of a video this was going to be before clicking. Highly recommend watching Colin's videos, this one included, for the sheer level of "this is clearly a bad idea, let's do it" that he gives off and the things learned along the way.
- gpm 11mo ago
  I have to say I'm rather more worried about the apparent lack of testing that their auto-update mechanism is actually updating anything (given how long it took them to notice that symptom), than that they're replacing some software with a not yet quite complete rewrite in their less-stable non-lts edition.
  - deleted 11mo ago
    [deleted]
  - StopDisinfo910 11mo ago
    There is no such thing as a less-stable-non-lts edition. That’s the stable version. The LTS version is just a stable version which is getting updated for longer. Non LTS absolutely shouldn’t mean unstable.
    - gpm 11mo ago
      It seems less stable in the sense that 1. It literally remains stable for less time. Nine months instead of 5+ years, up to 12 if you pay them. 2. They apparently have a history of testing changes in it. 3. They appear to only sell things like livepatch and extended support for LTS editions, and products you pay for are implicitly more stable than products you do not.
      - Jach 11mo ago
        Historically also, they've pushed things out from a LTS release that could have gone in and made people wait for the next non-LTS release because they were too new or experimental. If it's good, it'll be in the next LTS, but if not, it won't and can be removed from the next non-LTS without impacting too much. Or to use Ubuntu's own terminology: "Interim releases will introduce new capabilities from Canonical and upstream open source projects, they serve as a proving ground for these new capabilities." They also call LTS 'enterprise grade' while interims are merely production-quality. Personally I see these as different levels of stability.
      - close04 11mo ago
- JuniperMesos 11mo ago
  C is a bad language in many respects, and Rust greatly improves on the situation. Replacing code written in C with code written in Rust is good in and of itself, even if there are some costs associated with the transition. I also don't think that Rust itself is the only possible good language to use to write software - someone might invent a language in the future that is even better than Rust, and maybe at some point it will make sense to port rust-coreutils to something written in that yet-undesigned language. It would be good to design software and software deployment ecosystems in such a way that it is simply possible to do rewrites like this, rather than rely so much on the emergent behavior of one C source code collection + build process for correctness that people are afraid to change it. Indeed I would argue that one of the flaws of C, a reason to want to avoid having any code written in it at all, is precisely that the C language and build ecosystem make it unnecessarily difficult to do a rewrite.
  - jjgreen 11mo ago
    [flagged]
    - baq 11mo ago
      'the two things that really drew me to vinyl were the expense and the inconvenience.' https://imgur.com/gallery/vinyl-meme-7jeZtVJ https://imgur.com/gallery/vinyl-meme-7jeZtVJ
    - HighGoldstein 11mo ago
      This is an apt comparison since nobody except fringe enthusiasts came back to vinyl.
    - steveklabnik 11mo ago
      I've been using Rust for 13 years, I'll let you know in two if I go back to C. Given I'm about to turn 40, I do appreciate being referred to as a kid though ;)
      - tracker1 11mo ago
- zigzag312 11mo ago
  > replaced by a rewrite for no obvious reason Obvious reason is to have less bugs in the long run. Temporary increase during transition is expected and is not ideal, but after that there should be less of them. It's not like C version didn't have any bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=oldstable;package=coreutils https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;d...
  - hulitu 11mo ago
    > Obvious reason is to have less bugs in the long run. The highest sounds are hardest to hear. Going forward is a way to retreat. Great talent shows itself late in life. Even a perfect program still has bugs.
- ramon156 11mo ago
  This is a short sighted opinion and riddled with prejudice
  - deleted 11mo ago
    [deleted]
- jorvi 11mo ago
  > Sudo has released a security update to address a critical vulnerability (CVE-2025-32463) in its command-line utility. This vulnerability allows an attacker to leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. People start making sudo more secure by replacing it with sudo-rs You: "why are we rewriting old utilities?"
  - secondcoming 11mo ago
    Rewriting old utilities is fine but they have to be backwards compatible. This is not the same as fixing a bug.
    - tracker1 11mo ago
      The "old" version didn't have a test for the feature... the "new" version started with the tests for the "old" version... it was an easy thing to miss as a result. As other threads have mentioned, a more advanced argument parser and detection of parsed, but unused arguments could have caught this. Of course, there's already complaints about the increase in size for the Rust versions of uutils, mostly offset by a merged binary with separate symlinks. It's a mixed bag. But, I'm sure you'll be reverting back to Xfree86 now.
    - pepoluan 11mo ago
      And how do you define "backwards compatible"? How can you be sure that something is "backwards compatible"? By running tests. And as it happens, the original coreutils did not have a test for this particular edge case. Now that a divergence of behavior has been observed, all parties -- the coreutils devs and the uutils devs -- have agreed that this is an unacceptable regression and created new test cases to prevent the same misbehavior from happening again.
      - pclmulqdq 11mo ago
        A lot of database companies go to great lengths to be bug-for-bug compatible with postures. This does happen. It takes some effort, though, which does not appear to have been applied in the case of this rewrite.
hulitu 11mo ago
> Im okay with this. This is how we find out issues at Microsoft. /s
rob74 11mo ago
Not sure if I (as an unsuspecting Ubuntu user) am really ok with this. I'm not saying they should wait until version 1.0 (currently uutils/coreutils is at 0.2.2), but at least until the green line reaches the blue line in this graph: https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-test-suite-compatibility https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-t... Of course, "exotic" bugs might happen (not sure how exotic the bug that caused this issue was), but can a software really be considered production-ready if it still fails part of the testsuite of the software it should replace? I don't think so... If you look at "date" specifically on https://uutils.github.io/coreutils/docs/test_coverage.html https://uutils.github.io/coreutils/docs/test_coverage.html, it looks much worse than the overall graph suggests: 2 tests passing, 3 tests skipped, 3 with errors. Not really reassuring, right?
- Avamander 11mo ago
  > If you look at "date" specifically on https://uutils.github.io/coreutils/docs/test_coverage.html https://uutils.github.io/coreutils/docs/test_coverage.html, it looks much worse than the overall graph suggests: 2 tests passing, 3 tests skipped, 3 with errors. Not really reassuring, right? That's because they added new tests to catch these cases. I recall seeing someone mention in a comment here that coreutils didn't have a test for this either. So it is reassuring that these things actually get documented and tested.
  - pclmulqdq 11mo ago
    So did they have no tests until people put the code into production and sent bug reports?
    - Avamander 11mo ago
      > So did they have no tests until people put the code into production and sent bug reports? They tested what original coreutils tested. Until other people put uutils into production, neither had a test for this case. https://github.com/coreutils/coreutils/blob/master/tests/date/reference.sh https://github.com/coreutils/coreutils/blob/master/tests/dat...
bayindirh 11mo ago
I'm not, because while operating a fleet of systems, you assume some of the parts are so reliable that you don't look into them when problems arise. These kinds of bugs might not bug end users much, but when it becomes a fleet-wide problem, it becomes crippling. I'm debugging a problem on a platform since this morning. At the end of the day it turned out to be the platform is sending things to somewhere it's explicitly told not to. Result? Everything froze, without any errors. System management is hard to begin with. It becomes really hard when the tools you think you can depend breaks. Also, consider what would be the uproar if the programming language was something else than Rust. The developers would be crucified, burned with flamethrowers, reincarnated, and tortured again until they fed-up and leave computers and start raising chicken at an off-grid location.

[flagged]

You are ok about the core utils being replaced by a rewrite for no obvious reason and said rewrite being so broken that an allegedly stable distribution actually can’t properly update? I mean, all good then.

perching_aix 11mo ago
> for no obvious reason One can say a lot about the reason, but that it would not be obvious, is certainly an unlikely one.
atoav 11mo ago
My expectation would be that every bug in a Rust replacement is going to receive the brightest spotlight that can be found. If the rest of coreutils is bug free cast the first stone. I do not think reimplementing stuff in Rust is a bad thing. Why? Because reimplementing stuff is a very good way to througly check the original. It is always good to have as many eyeballs om the code as possible.
- StopDisinfo910 11mo ago
  Replacing battle tested software with untested rewrite is always a bad idea even if the rewrite is written a trendy language, key word being untested. I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler.
  - orangeboats 11mo ago
    > I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Some checks are pretty much impossible to do statically for C programs because of the lack of object lifetime annotations, so no, this statement can't be right. It is true that the borrow checker doesn't prevent ALL bugs though. Furthermore, the "bug" in this case is due to an unimplemented feature causing a flag to be silently ignored... It's not exactly something that any static analyser (or runtime ones for that matter) can prevent, unless an explicit assert/todo is added to the codepath.
    - StopDisinfo910 11mo ago
      Well, you can annotate C code to do a lot more than lifetime annotations today. The tooling for C analysis is best in class. And even without annotations, you can prove safe a lot of constructs by being conservative in your analysis especially if there is no concurrency involved. Note that I wasn't specifically commenting about this specific issue. It's more about my general fatigue regarding people implying that rewrite in Rust are always better or should be done. I like Rust but the trendiness surrounding it is annoying.
      - unscaled 11mo ago
        You can do a lot of things. Yes, there are formally verified programs and libraries written in C. But most C programs are not, including the GNU coreutils (although they are battle-tested). It's just the effort involved is higher and the learning curve for verifying C code correctly is staggering. Rust provides a pretty good degree of verification out-of-the-box for free. Like any trendy language, you've got some people exaggerating the powers of the borrow checker, but I believe Rust did generally bring out a lot of good outcomes. If you're writing a new piece of systems software, Rust is pretty much a no-brainer. You could argue for a language like Zig (or Go where you're fine fine with a GC and a bit more boilerplate), but that puts even more spotlight on the fact that C is just not viable choice for most new programs anymore. The Rewrites-in-Rust are more controversial and they are just as much as they are hyped here on HN, but I think many of them brought a lot of good to the table. It's not (just?) because the C versions were insecure, but mostly because a lot of these new Rust tools replaced C programs that had become quite stagnant. Think of ripgrep, exa/eza, sd, nushell, delta and difft, dua/dust, the various top clones. And these are just command line utilities. Rewriting something in Rust is not an inherently bad idea of what you are replacing clearly needs a modern makeover or the component is security critical and the code that you are replacing has a history of security issues. I was always more skeptical about the coreutils rewrite project because the only practical advantage they can bring to the table is more theoretical safety. But I'm not convinced it's enough. The Rust versions are guaranteed to not have memory or concurrency related bugs (unless someone used unverified unsafe code or someone did something very silly like allocating a huge array and creating their own Von Neumann Architecture emulator just to prove you can write unsafe code in Rust). That's great, but they are also more likely to have compatibility bugs with the original tools. The value proposition here is quite mixed. On the other hand, I think that if Ubuntu and other distros persist in trying to integrate these tools the long-term result will be good. We will get a more maintainable codebase for coreutils in the future.
- misja111 11mo ago
  Yes I also think that bugs in a Rust replacement will receive more attention than other bugs. Why? - the cult-like evangelism from the Rust community that everything written in Rust would be better - the general notion, that rewriting tools should bring clear an tangible benefits. Rewriting something mostly because the new language is safer will provoke irritation and frustration with affected end-users when the end product turns out to introduce new issues
  - pdimitar 11mo ago
    So, reducing CVEs is not a tangible benefit?
    - alextingle 11mo ago
      Rewriting old known good code from scratch is going to create more CVEs. This rewrite project is about corporations escaping from GPL code. It's got nothing to do with security.
      - pdimitar 11mo ago
        Somebody linked a comment from an Ubuntu maintainer where they said they want more resilient tools. If license was the only concern then I'd think that they wouldn't switch the programming language? And yeah, obviously using Rust will not eliminate all CVEs. It does eliminate buffer overflows and underflows though. Not a small thing. Also I would not uncritically accept the code of the previous coreutils as good. It got the job done (and has memory safety problems here and there). But is it really good? We can't know for sure.
- egorfine 11mo ago
  > reimplementing stuff is a very good way to througly check the original Problem is, they unironically want to replace coreutils with their toy. And they just did.
compiler-devel 11mo ago
They’re okay with it because the rewrite is in their preferred language.
- StopDisinfo910 11mo ago
  I have no opinion whatsoever on the rewrite. It might be the best thing since sliced bread for all I know. I have trouble with integrators recklessly shipping untested dependencies however.
  - timeon 11mo ago
    > It might be the best thing since sliced bread Can someone explain to me this analogy? Because I consider sliced bread as decline. But maybe that is cultural thing.
    - JodieBenitez 11mo ago
      There you go: https://time.com/3946461/sliced-bread-history/ https://time.com/3946461/sliced-bread-history/ (yes, I don't really get it either)
    - dgb23 11mo ago
      A knife that both slices and toasts the bread at the same time would be even better!
      - fainpul 11mo ago
        https://www.youtube.com/watch?v=kcjGRXTpHGI https://www.youtube.com/watch?v=kcjGRXTpHGI
        danudey 11mo ago
        Knew what absolute disaster of a video this was going to be before clicking. Highly recommend watching Colin's videos, this one included, for the sheer level of "this is clearly a bad idea, let's do it" that he gives off and the things learned along the way.
gpm 11mo ago
I have to say I'm rather more worried about the apparent lack of testing that their auto-update mechanism is actually updating anything (given how long it took them to notice that symptom), than that they're replacing some software with a not yet quite complete rewrite in their less-stable non-lts edition.
- deleted 11mo ago
  [deleted]
- StopDisinfo910 11mo ago
  There is no such thing as a less-stable-non-lts edition. That’s the stable version. The LTS version is just a stable version which is getting updated for longer. Non LTS absolutely shouldn’t mean unstable.
  - gpm 11mo ago
    It seems less stable in the sense that 1. It literally remains stable for less time. Nine months instead of 5+ years, up to 12 if you pay them. 2. They apparently have a history of testing changes in it. 3. They appear to only sell things like livepatch and extended support for LTS editions, and products you pay for are implicitly more stable than products you do not.
    - Jach 11mo ago
      Historically also, they've pushed things out from a LTS release that could have gone in and made people wait for the next non-LTS release because they were too new or experimental. If it's good, it'll be in the next LTS, but if not, it won't and can be removed from the next non-LTS without impacting too much. Or to use Ubuntu's own terminology: "Interim releases will introduce new capabilities from Canonical and upstream open source projects, they serve as a proving ground for these new capabilities." They also call LTS 'enterprise grade' while interims are merely production-quality. Personally I see these as different levels of stability.
    - close04 11mo ago
JuniperMesos 11mo ago
C is a bad language in many respects, and Rust greatly improves on the situation. Replacing code written in C with code written in Rust is good in and of itself, even if there are some costs associated with the transition. I also don't think that Rust itself is the only possible good language to use to write software - someone might invent a language in the future that is even better than Rust, and maybe at some point it will make sense to port rust-coreutils to something written in that yet-undesigned language. It would be good to design software and software deployment ecosystems in such a way that it is simply possible to do rewrites like this, rather than rely so much on the emergent behavior of one C source code collection + build process for correctness that people are afraid to change it. Indeed I would argue that one of the flaws of C, a reason to want to avoid having any code written in it at all, is precisely that the C language and build ecosystem make it unnecessarily difficult to do a rewrite.
- jjgreen 11mo ago
  [flagged]
  - baq 11mo ago
    'the two things that really drew me to vinyl were the expense and the inconvenience.' https://imgur.com/gallery/vinyl-meme-7jeZtVJ https://imgur.com/gallery/vinyl-meme-7jeZtVJ
  - HighGoldstein 11mo ago
    This is an apt comparison since nobody except fringe enthusiasts came back to vinyl.
  - steveklabnik 11mo ago
    I've been using Rust for 13 years, I'll let you know in two if I go back to C. Given I'm about to turn 40, I do appreciate being referred to as a kid though ;)
    - tracker1 11mo ago
zigzag312 11mo ago
> replaced by a rewrite for no obvious reason Obvious reason is to have less bugs in the long run. Temporary increase during transition is expected and is not ideal, but after that there should be less of them. It's not like C version didn't have any bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=oldstable;package=coreutils https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;d...
- hulitu 11mo ago
  > Obvious reason is to have less bugs in the long run. The highest sounds are hardest to hear. Going forward is a way to retreat. Great talent shows itself late in life. Even a perfect program still has bugs.
ramon156 11mo ago
This is a short sighted opinion and riddled with prejudice
- deleted 11mo ago
  [deleted]
jorvi 11mo ago
> Sudo has released a security update to address a critical vulnerability (CVE-2025-32463) in its command-line utility. This vulnerability allows an attacker to leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. People start making sudo more secure by replacing it with sudo-rs You: "why are we rewriting old utilities?"
- secondcoming 11mo ago
  Rewriting old utilities is fine but they have to be backwards compatible. This is not the same as fixing a bug.
  - tracker1 11mo ago
    The "old" version didn't have a test for the feature... the "new" version started with the tests for the "old" version... it was an easy thing to miss as a result. As other threads have mentioned, a more advanced argument parser and detection of parsed, but unused arguments could have caught this. Of course, there's already complaints about the increase in size for the Rust versions of uutils, mostly offset by a merged binary with separate symlinks. It's a mixed bag. But, I'm sure you'll be reverting back to Xfree86 now.
  - pepoluan 11mo ago
    And how do you define "backwards compatible"? How can you be sure that something is "backwards compatible"? By running tests. And as it happens, the original coreutils did not have a test for this particular edge case. Now that a divergence of behavior has been observed, all parties -- the coreutils devs and the uutils devs -- have agreed that this is an unacceptable regression and created new test cases to prevent the same misbehavior from happening again.
    - pclmulqdq 11mo ago
      A lot of database companies go to great lengths to be bug-for-bug compatible with postures. This does happen. It takes some effort, though, which does not appear to have been applied in the case of this rewrite.

hulitu 11mo ago

> Im okay with this. This is how we find out issues at Microsoft. /s

rob74 11mo ago

Not sure if I (as an unsuspecting Ubuntu user) am really ok with this. I'm not saying they should wait until version 1.0 (currently uutils/coreutils is at 0.2.2), but at least until the green line reaches the blue line in this graph: https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-test-suite-compatibility https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-t... Of course, "exotic" bugs might happen (not sure how exotic the bug that caused this issue was), but can a software really be considered production-ready if it still fails part of the testsuite of the software it should replace? I don't think so... If you look at "date" specifically on https://uutils.github.io/coreutils/docs/test_coverage.html https://uutils.github.io/coreutils/docs/test_coverage.html, it looks much worse than the overall graph suggests: 2 tests passing, 3 tests skipped, 3 with errors. Not really reassuring, right?

Avamander 11mo ago
> If you look at "date" specifically on https://uutils.github.io/coreutils/docs/test_coverage.html https://uutils.github.io/coreutils/docs/test_coverage.html, it looks much worse than the overall graph suggests: 2 tests passing, 3 tests skipped, 3 with errors. Not really reassuring, right? That's because they added new tests to catch these cases. I recall seeing someone mention in a comment here that coreutils didn't have a test for this either. So it is reassuring that these things actually get documented and tested.
- pclmulqdq 11mo ago
  So did they have no tests until people put the code into production and sent bug reports?
  - Avamander 11mo ago
    > So did they have no tests until people put the code into production and sent bug reports? They tested what original coreutils tested. Until other people put uutils into production, neither had a test for this case. https://github.com/coreutils/coreutils/blob/master/tests/date/reference.sh https://github.com/coreutils/coreutils/blob/master/tests/dat...

bayindirh 11mo ago

I'm not, because while operating a fleet of systems, you assume some of the parts are so reliable that you don't look into them when problems arise. These kinds of bugs might not bug end users much, but when it becomes a fleet-wide problem, it becomes crippling. I'm debugging a problem on a platform since this morning. At the end of the day it turned out to be the platform is sending things to somewhere it's explicitly told not to. Result? Everything froze, without any errors. System management is hard to begin with. It becomes really hard when the tools you think you can depend breaks. Also, consider what would be the uproar if the programming language was something else than Rust. The developers would be crucified, burned with flamethrowers, reincarnated, and tortured again until they fed-up and leave computers and start raising chicken at an off-grid location.