1/ You can think that Tridge made some mistakes (I do, and he acknowledges them) and disagree with his take on GenAI (I do) but the pitchfork-wielding burn-the-witch mob being led by @davidgerard should show some humility and humanity.
-
@eschwartz @timbray Just a remark:
Fuzzing input to find bugs is not at all the same as fuzzing source code to find working code. In the first case, each "hit" you get is a solid demonstration of some actual bug; in the second, each "hit" is a piece of code which may or may not actually work, depending on how you verify it, and may or may not be maintenable, and extendable, and optimized, and generally manageable.
Those two "fuzzings" are nothing alike.
I think we are basically saying the same thing (possibly without you realizing it)?
As I said, fuzzing to find "valid programs" i.e. working source code is a new idea that "coding agent" salespeople are pushing. This is independent of whether they are correct that it truly exists; they're selling it. I said it's the thing that gets pushback as "slop and trash" in reply to a comment that said "whatever you think of genAI, if it [shills fuzzing input to find security bugs"].
-
I think we are basically saying the same thing (possibly without you realizing it)?
As I said, fuzzing to find "valid programs" i.e. working source code is a new idea that "coding agent" salespeople are pushing. This is independent of whether they are correct that it truly exists; they're selling it. I said it's the thing that gets pushback as "slop and trash" in reply to a comment that said "whatever you think of genAI, if it [shills fuzzing input to find security bugs"].
My goal was to push back on the idea that "fuzzing to find bugs" (a valid goal, that may not be worth the various costs of LLM) is an excuse for *also* using it to fuzz source code for "valid programs".
In particular because I dispute the claim that they are capable of fuzzing for working source code at all. Every example I've seen to date has been more effort to make it work than it would take to write naturally, and the target userbase doesn't know how to put in the work.
-
@timbray The people howling at Tridge over his use of Claude have probably been using Samba and rsync for years, explicitly or otherwise. Thanking Tridge for his service would be a good place to start.
I’m reminded of historic totalitarian regimes where some famous scientist becomes an unperson as a result of perceived sudden ideological impurity.
-
My goal was to push back on the idea that "fuzzing to find bugs" (a valid goal, that may not be worth the various costs of LLM) is an excuse for *also* using it to fuzz source code for "valid programs".
In particular because I dispute the claim that they are capable of fuzzing for working source code at all. Every example I've seen to date has been more effort to make it work than it would take to write naturally, and the target userbase doesn't know how to put in the work.
It is, indeed, a devastatingly tragic, bad use case for the generic concept of fuzzing.
Fuzzing is appealing because it lets computers do a lot of work for you in the background, filtered with "interestingness" tests like "can elicit a compiler ICE" and by definition all results are useful, although not all have equal levels of usefulness. (A compiler should never crash for any reason however unlikely.)
If you have to review for correctness at all then fuzzing doesn't help.
-
@carbsrule_en @timbray @davidgerard what do you mean?
He is doing brilliant work reacting to the torrent of valid AI generated security issues.
@worik @carbsrule_en @timbray @davidgerard "Closed, WONTFIX, fuck off" is also a valid response and doesn't cause regressions in a piece of software that is largely finished.
-
@timbray @davidgerard I've relied on rsync for decades. It's currently how I deploy my static website to a VPS. And now I'm having to deal with figuring out a replacement strategy that isn't a total nightmare across two different package ecosystems (Arch locally, Debian remotely), because the guy betrayed the public trust.
I try not to think about people in simple "good vs evil" terms - sometimes I fail or forget, because I'm human, but I try. I don't want this story to be about that, I don't care about classifying Tridge in those terms. But this *is* a situation where a previously trustworthy person is now creating ecosystem problems, and it needs to be addressed, and it affects a lot of people. At bare minimum, I'm allowed to be upset about being put in this position by a stranger. And I'm sure not going to carry water for that stranger while he's still actively being a problem.
@MaddieM4 @timbray @davidgerard I don't wish to be part of a torches and pitchforks crowd haranguing Tridge but if you're determined to replace rsync with something else take a look at https://github.com/bcpierce00/unison
I've used it on and off over the years and my only issue has been interoperability between different releases built with different OCAML versions (might or might not work, annoying to debug, don't waste time trying).
-
It is, indeed, a devastatingly tragic, bad use case for the generic concept of fuzzing.
Fuzzing is appealing because it lets computers do a lot of work for you in the background, filtered with "interestingness" tests like "can elicit a compiler ICE" and by definition all results are useful, although not all have equal levels of usefulness. (A compiler should never crash for any reason however unlikely.)
If you have to review for correctness at all then fuzzing doesn't help.
On top of that, LLMs are provably good at generating *convincingly wrong* code. Code that compiles, but has subtle bugs a human wouldn't make, because humans are geared towards making entirely different classes of mistakes, and humans are also trained to recognize those different classes of mistakes. Review doesn't *work*.
Then everyone points at the technical correctness of expensively painfully reviewed and corrected LLM code from marketing. "Look, it generates good code!"
-
@MaddieM4 @timbray @davidgerard I don't wish to be part of a torches and pitchforks crowd haranguing Tridge but if you're determined to replace rsync with something else take a look at https://github.com/bcpierce00/unison
I've used it on and off over the years and my only issue has been interoperability between different releases built with different OCAML versions (might or might not work, annoying to debug, don't waste time trying).
@rlonstein @timbray @davidgerard I hadn't even considered Unison, because it was pigeonholed in my brain as "the bidirectional sync thing" and bidirectional sync spooks me. But I bet I can figure out the args to make it do unidirectional sync, and failing that, I think I know how I can abuse git for something even faster. Thanks!
-
@timbray @davidgerard if you're trying to lower the temperature of the discussion I must say you're going about it in an odd way.
My perspective as a user of rsync for decades is that it's a bad thing that I'm now aware of who maintains it and what his development strategy is. That means I no longer trust the package and I'm concerned.
The response by Tridge has been to dismiss all criticism as illegitimate. There's no way forward here.
@mackensen @timbray @davidgerard I'm trying to give Tridge the benefit of the doubt here, but he doesn't seem to acquit himself all that well. The anecdata pours in about LLMs essentially faking test cases they are tasked to write. My own bad experiences with them (I noticed missing imports in Python, includes in C++, hallucinating FreeBSD IPv4 stack APIs, more or less regurgitating manuals. and the infamous-to-me answering macOS questions from Linux source) admonish his assertions pretty hard.
-
3/ And to those who say he should hand it off to one or more younger people who have the resources and skill to take good care of it, I agree and I bet he’d love that. I would prefer actual concrete people rather than an abstract assumption they exist. A good place to start would be, as Tridge asks, sending a few PRs to help restore order. Assuming the people howling for his head know what a PR is or how to build one.
@timbray Just because I can’t design a car from scratch and have no expertise in powertrains doesn’t mean I’m disqualified from criticizing its driving characteristics or creature comforts.
People rely on rsync. And they rely on it because it has a *history* of being solid and reliable. When the author suddenly introduces serious regressions in an update, people are understandably upset, even though they aren’t experts and can’t write PRs on their own.
We can argue whether or not this is fair, but it’s not arguable that an unforced error has been introduced by the project’s author, which caused widespread issues and made extra work for a lot of people. I think people are allowed to be upset about that.
-
@rlonstein @timbray @davidgerard I hadn't even considered Unison, because it was pigeonholed in my brain as "the bidirectional sync thing" and bidirectional sync spooks me. But I bet I can figure out the args to make it do unidirectional sync, and failing that, I think I know how I can abuse git for something even faster. Thanks!
@MaddieM4 @timbray @davidgerard I think it's
-nocreation <localroot> -nodeletion <localroot> -noupdate <localroot>but it's been a while since I used it regularly. -
@mackensen @timbray @davidgerard I'm trying to give Tridge the benefit of the doubt here, but he doesn't seem to acquit himself all that well. The anecdata pours in about LLMs essentially faking test cases they are tasked to write. My own bad experiences with them (I noticed missing imports in Python, includes in C++, hallucinating FreeBSD IPv4 stack APIs, more or less regurgitating manuals. and the infamous-to-me answering macOS questions from Linux source) admonish his assertions pretty hard.
@bms48 @mackensen @timbray @davidgerard "area man steps on rake to see if stepping on rake will result in getting whacked in the face"
-
R relay@relay.infosec.exchange shared this topic
