3 ms·

I 100% agree with the "please don't fuck up this stable & reliable workhorse" sentiment. I haven't read this in detail but "Six CVEs are fixed in this release.

• mattbee 4mo ago
  But there's been security fixes in most releases of rsync! Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it. Where is the slop commit here? And why is that commit evidence that tridge has lost his mind to the machine? https://github.com/RsyncProject/rsync/commits/master/ https://github.com/RsyncProject/rsync/commits/master/
  • izacus 4mo ago
    The part you're missing is that those "fixes" broke a lot of existing functionality.
    • androolloyd 4mo ago
      Bugs are bugs and need fixing. How dense can people get.
      • hdgvhicv 4mo ago
        Regressions are bad and need to not happen.
        • deleted 4mo ago
          [deleted]
        • Lerc 4mo ago
          Would you hold off on fixing a security vulnerability if it caused a limited regression? Regressions should be fixed expediently, but if you apply the criteria "need to not happen" they are literally blocking issues. They could then block security fixes.
          • izacus 4mo ago
            Which part of security fixing demands thoughtless generation of code slop without regression testing though? I worked on major OSS projects and we never just blindly pushed out untested poor quality code for security fixes since that adds WORSE security regressions.
            • Lerc 4mo ago
              I am discussing outcomes, not methodology. The methodology describes the effort you may be putting into something, The outcomes are about what results are you prepared to accept. Would you ship an update with a security fix if it had been thoroughly tested was shown to have certain regressions but no worse security regressions? Would you refuse to fix the security issue until you could do so without any degradation? It's clear that people can and do accept regressions for security updates. Spectre mitigations cause performance regressions. SharedArrayBuffer got taken away for a while. Being absolutist about things seldom helps. I agree due care should be taken where possible, but I'm also prepared to accept that mistakes can happen even when people have worked diligently to find issues. Since you have worked on major OSS projects. Have any of them shipped regressions unintentionally? Right now that is the only thing we have to go on, that these things happened. The degree of care taken is an unknown, as is the degree of LLM involvement. We might know more in a week or two. If you want to condemn something based upon what might have happened you can specifically state what you think shouldn't happen, and that will stand regardless of whether or not it applies to the current incident. Obviously "Thoughtless generation of code slop without regression testing" is unacceptable, but that is because the conclusion is written into the statement by saying "thoughtless" "slop" and "without regression testing" If tridge says 'I gave it thought, I don't agree that it is slop, and I did regression testing' then you have nothing further to complain about, because the incident does not fall under the criteria you specified. It's saying 'things that are bad, are bad'. The defence is to say 'well, this isn't bad'
        • krcz 4mo ago
          Regressions are bad and they should be avoided. Still, software engineering is a complex thing and regressions happened long time before coding agents were a thing. Unless one can pinpoint regression to changes that were more sloppy than the human-written rsync commits were I don't think coding agents are to blame.
          • cbm-vic-20 4mo ago
            Seems like that it's not that coding agents are to blame, its that the people who are ultimately responsible for committing and merging the offending code are to blame, regardless of its origin.
            • krcz 4mo ago
              Or no one is to blame, if the mechanism of the regression is complex and non-obvious based just on the patch itself.
              • pishpash 4mo ago
                Or they are to blame because they misplaced responsibility in a tool's universality to not introduce regressions, even complex and non-obvious ones.
                • tpm 4mo ago
                  or they are not to blame because they accepted the possibility of a regression when fixing 6 CVEs
                  • pishpash 4mo ago
                    Or they are to blame because fixing 1000 CVE's doesn't magically absolve one of responsibility for regression bugs, even if one "accepts" them as a psychological salve.
                    • 4mo ago
  • dash2 4mo ago
    Parent is agreeing with you.