13 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.
- 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.
    - timeon 11mo ago
      Is it really battle tested?
    - atoav 11mo ago
      If you read my comment with a little care, you may realize that I said nothing about replacing the software, I only spoke about writing it. In my own Distro I wouldn't replace coreutils with a Rust rewrite either at this point. On the borrow checker: It doesn't prevent logic errors as is commonly understood. These errors are what careful use of Rusts type system could potentially prevent in many cases, but you can write Rust without leveraging it successfully. The Rust compiler is an impressive problem-avoidance tool, but there are classes of problems even it can't prevent from happening. BLet us not fall into the trap of thinking thst just because the Rust compiler fails to prevent all issues, we should therefore abandon it. We shouldn't forget our shared history of mistakes rustc would have prevented (excerpt): - CVE-2025-5278, sort: heap buffer under-read in begfield(), Out-of-bounds heap read in traditional key syntax - CVE-2024-0684, split: heap overflow in line_bytes_split(), Out-of-bounds heap write due to unchecked buffer handling - CVE-2015-4042, sort: integer overflow in keycompare_mb(), Overflow leading to potential out-of-bounds and DoS If we were civil engineers with multiple bridge collapses in our past and then, we finally had developed a tool that reliably prevents a certain especially dangerous and common type of bridge collapse, we would be in the wrong profession if we scoffed at the use of the tool. Whether it is Ruet or some C checker isn't really the point here. The point is building stable, secure and performant software others can rely on. Any new method to achieve this more reliably has to be tested. Ideally in an environment where harm is low.
      - delamon 11mo ago
        It is worth noting, that all three CVEs could be prevented by simple bounds checking at runtime. Preventing them does not require borrow checker or any other Rust fancy features.
        pdimitar 11mo ago
        It is also worth noting that theoreticals don't help such discussions either. Yes, C programmers can do much more checks. The reality on the ground is -- they do not. Forcing checks by the compiler seems to be the only historically proven method of making programmers pay more attention. If you can go out there and make _all_ C code utilize best-in-class static checkers, by all means, go and do so. The world would be a much better place.
    - mrkeen 11mo ago
      > I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. It shouldn't be magic. It should be routine and boring, like no-nulls, pure functions, static typing and unit tests.
      - StopDisinfo910 11mo ago
        From my point of view, no, it shouldn’t be routine. Lifetime annotations and borrow checking are pretty far from the sweet spot of easy to deploy, useful and get out of the way when it comes to static analysis. Honestly, Ada is a far better choice than Rust when it comes to the safety/usability ratio and you can even add Spark on top which Rust has no equivalent of. But somehow we are saddled with the oversold fashion machine even when it makes no sense. I mean, look at the discussion. It’s full of people who don’t even know what static analysis is but come explaining to me that I am a C zealot stuck in the past and ignorant of the magnificence of our lord and saviour Rust. I don’t even use C. I don’t care that people rewrite stuff become they want to be cool. If they maintain them, it’s their responsibility and their time. I do care about distribution replacing things with untested things to sound cool however. That’s shoddy work. I also deeply disagree that pure functions should be the norm as an Ocaml programmer. They have their place but are no panacea either. That’s the Haskell hype instead of Rust hype this time.
    - awalGarg 11mo ago
      > I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. I'd be very interested in reading more about this. Could you please explain what are these checks and how they are qualitatively and quantitatively better than the default rustc checks? Please note that this is about checks on the codebase itself - not system/integration tests which are of course already applicable against alternative implementations.
    - pdimitar 11mo ago
      Claiming without evidence that something is battle-tested while also claiming the competition is "trendy" does not help any argument you might be attempting to make. I am trying to read your comments charitably but I am mostly seeing generalizations which makes it difficult to extract useful info from your commentary. We can start by dropping dismissive language like "trendy" and "magic", "fashion" and "Rust kids". We can also continue by saying that "believing the borrow checker is some kind of magic" is not an interesting thing to say as it does not present any facts or advance any discussion. What you "assure" us of is also inconsequential. One fact remains: there are a multitude of CVEs that, if the program was written in Rust, would not happen. I don't think anyone serious ever claimed that logic bugs are prevented by Rust. People are simply saying: "Can we just have less possible bugs by the virtue of the program compiling, please?" -- and Rust gives them that. What's your objection to that? And let us leave aside your seeming personal annoyance of whatever imaginary fandom you might be seeing. Let us stick to technical facts.
      - danudey 11mo ago
        The objections I see against Rust and Rust rewrites of things remind me a lot of the objections I saw against Linux and Linux users by Windows users, and against macOS and macOS users by Linux users. Dismissive language and denegrating comments without any technical backing; assertions of self-superiority. "It's a toy", "it's not mature", "it's a worse version of blah blah", "my thing does stuff it doesn't do and that's important, but it does things my thing doesn't do and that's irrelevant". Honestly it's at the point where I see someone complaining about a Rust rewrite and I just go ahead and assume that they're mouthing off about something because they think it's trendy and they think it's cool to hate things people like. I hate being prejudicial about comments but I don't have the energy to spend trying to figure out if someone is debating in good faith or not when it seems to so rarely be the case.
        pdimitar 11mo ago
        My impression is exactly the same. For multiple years now I keep seeing grandiose claims about "Rust fandom" and all I ever see in those threads are... the C people who complain about that Rust fandom that I cannot for the life of me find in a 300+ comments thread. It's really weird, at one point I started asking myself if many comments are just hidden from me. Then I just shrugged it off and concluded that it's plain old human bias and "mine is good, yours is bad" tribe mentality and figured it's indeed not worth my time and energy to do further analysis on tribal instinctive behaviour that's been well-explained in literature for like a century at this point. I have no super strong feelings for or against Rust, by the way. I have used it to crushing success exactly where it shines and for that it got my approval. But I also work a lot with Elixir and I would rarely try to make a web app with Rust; multiple PLs have the frameworks that make this much better and faster and more pleasant to do. But it does make me wonder: what stake do these people have in the whole thing? Why do they keep mouthing off about some imaginary zealots that are nowhere to be found?
    - hulitu 11mo ago
      > key word being untested. That's why they (still) have users. If it works so well for Microsoft, why wouldn't work for Ubuntu ?
    - steveklabnik 11mo ago
      > I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Yet, this effort has still found bugs in the upstream project! No codebase is perfect.
    - tracker1 11mo ago
      This bug was missed because there wasn't a test case in the original.
  - 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.
- 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.
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.

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.
  - timeon 11mo ago
    Is it really battle tested?
  - atoav 11mo ago
    If you read my comment with a little care, you may realize that I said nothing about replacing the software, I only spoke about writing it. In my own Distro I wouldn't replace coreutils with a Rust rewrite either at this point. On the borrow checker: It doesn't prevent logic errors as is commonly understood. These errors are what careful use of Rusts type system could potentially prevent in many cases, but you can write Rust without leveraging it successfully. The Rust compiler is an impressive problem-avoidance tool, but there are classes of problems even it can't prevent from happening. BLet us not fall into the trap of thinking thst just because the Rust compiler fails to prevent all issues, we should therefore abandon it. We shouldn't forget our shared history of mistakes rustc would have prevented (excerpt): - CVE-2025-5278, sort: heap buffer under-read in begfield(), Out-of-bounds heap read in traditional key syntax - CVE-2024-0684, split: heap overflow in line_bytes_split(), Out-of-bounds heap write due to unchecked buffer handling - CVE-2015-4042, sort: integer overflow in keycompare_mb(), Overflow leading to potential out-of-bounds and DoS If we were civil engineers with multiple bridge collapses in our past and then, we finally had developed a tool that reliably prevents a certain especially dangerous and common type of bridge collapse, we would be in the wrong profession if we scoffed at the use of the tool. Whether it is Ruet or some C checker isn't really the point here. The point is building stable, secure and performant software others can rely on. Any new method to achieve this more reliably has to be tested. Ideally in an environment where harm is low.
    - delamon 11mo ago
      It is worth noting, that all three CVEs could be prevented by simple bounds checking at runtime. Preventing them does not require borrow checker or any other Rust fancy features.
      - pdimitar 11mo ago
        It is also worth noting that theoreticals don't help such discussions either. Yes, C programmers can do much more checks. The reality on the ground is -- they do not. Forcing checks by the compiler seems to be the only historically proven method of making programmers pay more attention. If you can go out there and make _all_ C code utilize best-in-class static checkers, by all means, go and do so. The world would be a much better place.
  - mrkeen 11mo ago
    > I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. It shouldn't be magic. It should be routine and boring, like no-nulls, pure functions, static typing and unit tests.
    - StopDisinfo910 11mo ago
      From my point of view, no, it shouldn’t be routine. Lifetime annotations and borrow checking are pretty far from the sweet spot of easy to deploy, useful and get out of the way when it comes to static analysis. Honestly, Ada is a far better choice than Rust when it comes to the safety/usability ratio and you can even add Spark on top which Rust has no equivalent of. But somehow we are saddled with the oversold fashion machine even when it makes no sense. I mean, look at the discussion. It’s full of people who don’t even know what static analysis is but come explaining to me that I am a C zealot stuck in the past and ignorant of the magnificence of our lord and saviour Rust. I don’t even use C. I don’t care that people rewrite stuff become they want to be cool. If they maintain them, it’s their responsibility and their time. I do care about distribution replacing things with untested things to sound cool however. That’s shoddy work. I also deeply disagree that pure functions should be the norm as an Ocaml programmer. They have their place but are no panacea either. That’s the Haskell hype instead of Rust hype this time.
  - awalGarg 11mo ago
    > I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. I'd be very interested in reading more about this. Could you please explain what are these checks and how they are qualitatively and quantitatively better than the default rustc checks? Please note that this is about checks on the codebase itself - not system/integration tests which are of course already applicable against alternative implementations.
  - pdimitar 11mo ago
    Claiming without evidence that something is battle-tested while also claiming the competition is "trendy" does not help any argument you might be attempting to make. I am trying to read your comments charitably but I am mostly seeing generalizations which makes it difficult to extract useful info from your commentary. We can start by dropping dismissive language like "trendy" and "magic", "fashion" and "Rust kids". We can also continue by saying that "believing the borrow checker is some kind of magic" is not an interesting thing to say as it does not present any facts or advance any discussion. What you "assure" us of is also inconsequential. One fact remains: there are a multitude of CVEs that, if the program was written in Rust, would not happen. I don't think anyone serious ever claimed that logic bugs are prevented by Rust. People are simply saying: "Can we just have less possible bugs by the virtue of the program compiling, please?" -- and Rust gives them that. What's your objection to that? And let us leave aside your seeming personal annoyance of whatever imaginary fandom you might be seeing. Let us stick to technical facts.
    - danudey 11mo ago
      The objections I see against Rust and Rust rewrites of things remind me a lot of the objections I saw against Linux and Linux users by Windows users, and against macOS and macOS users by Linux users. Dismissive language and denegrating comments without any technical backing; assertions of self-superiority. "It's a toy", "it's not mature", "it's a worse version of blah blah", "my thing does stuff it doesn't do and that's important, but it does things my thing doesn't do and that's irrelevant". Honestly it's at the point where I see someone complaining about a Rust rewrite and I just go ahead and assume that they're mouthing off about something because they think it's trendy and they think it's cool to hate things people like. I hate being prejudicial about comments but I don't have the energy to spend trying to figure out if someone is debating in good faith or not when it seems to so rarely be the case.
      - pdimitar 11mo ago
        My impression is exactly the same. For multiple years now I keep seeing grandiose claims about "Rust fandom" and all I ever see in those threads are... the C people who complain about that Rust fandom that I cannot for the life of me find in a 300+ comments thread. It's really weird, at one point I started asking myself if many comments are just hidden from me. Then I just shrugged it off and concluded that it's plain old human bias and "mine is good, yours is bad" tribe mentality and figured it's indeed not worth my time and energy to do further analysis on tribal instinctive behaviour that's been well-explained in literature for like a century at this point. I have no super strong feelings for or against Rust, by the way. I have used it to crushing success exactly where it shines and for that it got my approval. But I also work a lot with Elixir and I would rarely try to make a web app with Rust; multiple PLs have the frameworks that make this much better and faster and more pleasant to do. But it does make me wonder: what stake do these people have in the whole thing? Why do they keep mouthing off about some imaginary zealots that are nowhere to be found?
  - hulitu 11mo ago
    > key word being untested. That's why they (still) have users. If it works so well for Microsoft, why wouldn't work for Ubuntu ?
  - steveklabnik 11mo ago
    > I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Yet, this effort has still found bugs in the upstream project! No codebase is perfect.
  - tracker1 11mo ago
    This bug was missed because there wasn't a test case in the original.
- 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.
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.

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.