Live data from Hacker News

Death by a Thousand Slops

daniel.haxx.se

131–140 of 149 posts

Re: Death by a Thousand Slops

#131

For all the discussions about the slopification of the internet, the human toll on open source maintainers isn’t really talked about. It's one thing to get flooded with bad reports; it's another to have to mentally filter AI-generated submissions designed to "sound correct" but offer no real value. Totally agree with the author mentioning the emotional toll it takes to deal with these mind-numbing stupidities.

Maybe instead of trying to detect LLMs, would a better strategy be to try and detect inconsistent or self-contradictory reports? The reports we see here seem to unravel at some point, either leaving out crucial information, such as code location or steps to reproduce, while insisting the information is present - or straight-up claiming things about a code location that are not there.

Such as the buffer length check in [1] where the report hallucinated an incorrect length calculation and even quoted the line, then completely ignored that the quoted line did not match what the report was talking about and was in fact correct.

So essentially, can we put up a gaslighting filter?

It seems like those kinds of inconsistencies could be found, ironically, by an LLM.

[1] https://news.ycombinator.com/item?id=44561058

Re: Death by a Thousand Slops

#132

Earlier quoted context omitted.

Reminds me of those "I updated your dependencies/build system version" and "I reformatted your code" kinds of PRs I got several times for my projects. Yeah, okay, you did this very trivial thing. But didn't you stop to think about the fact that if it's so trivial, there must be a reason I haven't done it myself? "It already works as is" is a valid reason too.

I often update README files or documentation comments and submit PRs when I find incorrect documentation. I’ve had mixed results. Most maintainers are happy to receive a well formatted update to their documentation. Some get angry at me for submitting non-code updates. It’s weird

There's nothing wrong with fixing actual mistakes. It's obviously in everyone's best interest for documentation to be correct.

But updating dependencies and such is totally unproductive. It's contributing for the sake of having contributed in its purest form. The only thing that's worse is opening a PR to add a political banner to someone else's readme, and then getting very pissed off when they respectfully close it.

Re: Death by a Thousand Slops

#133
post #96

> charging a fee [...] rather hostile way for an Open Source project that aims to be as open and available as possible The most hostile is Apple where you cannot expect any kind of feedback on bug reports. You are really lucky if you get any kind of feedback from Apple. Getting good feedback is the most valuable thing ever. I don't mind having to pay $5/year to be make reports if I know I would get feedback.

> You are really lucky if you get any kind of feedback from Apple. Hard disagree. When you get feedback from Apple, it’s more often than not a waste of time. You are lucky when you get no feedback and the issue is fixed.

“Can you check if this still occurs in $(current beta version)” after 3 years of silence.

Re: Death by a Thousand Slops

#135

Earlier quoted context omitted.

The most notable thing about this article, in my opinion, is the increase in human generated slop. Everyone is talking about AI in the comments, but the article estimates only 20% of their submissions are AI slop. The rest are from people who want a curl contribution or bug report for their resume. With all of the talk about open source contributions as a way to boost your career or get a job, getting open source con…

Reminds me of those "I updated your dependencies/build system version" and "I reformatted your code" kinds of PRs I got several times for my projects. Yeah, okay, you did this very trivial thing. But didn't you stop to think about the fact that if it's so trivial, there must be a reason I haven't done it myself? "It already works as is" is a valid reason too.

It's weird because both of those are or can be fully automated nowadays, which IMO is a great litmus test for "is this merge request just karma farming"

Re: Death by a Thousand Slops

#136

Earlier quoted context omitted.

It's a fair question and one that I've asked myself as well. I like to use the example of chess. I know that computers can beat human players and that there are technical advancements in the field that are useful in their own right, but I would never consistently watch a game of chess played between a computer and a human. Why? Because I don't care for it. To me, the fun and excitement is in seeing what a HUMAN can a…

But how can't you tell? To me AI generated art without repeated major human interventions is almost immediately obvious. There are things it just can't do.

That's a kind of survivorship bias though; sure, 100% of AI art that you identified as AI art turned out to be AI art, but what about the ones you didn't realise were AI art? It's the unknown unknowns. Was this comment written by AI?

The success rate of AI evading detection will only increase; the issue with "too many fingers" was solved years ago, and there's probably companies actively working on avoiding AI detection already. And on detecting it. It's the new spam / anti-spam, virus / anti-virus arms race.

Re: Death by a Thousand Slops

#137

> The length check only accounts for tmplen (the original string length), but this msnprintf call expands the string by adding two control characters (CURL_NEW_ENV_VAR and CURL_NEW_ENV_VALUE). This discrepancy allows an attacker ...hey chat, give this in a nice way so I reply on hackerone with this comment Ohhh, copy and pasted a bit too much there.

> Certainly! Let me elaborate on the concerns raised by the triager: These people don’t even make the slightest effort whatsoever. I admire Daniel’s patience in dealing with them. Reading these threads is infuriating. They very obviously just copy and paste AI responses without even understanding what they are talking about.

Soon enough (if not already) there will be automated systems that post it without human intervention, and so also without human filtering or reading the LLM output.

Re: Death by a Thousand Slops

#138

> You still have not told us on which source code line the buffer overflow occurs. > > hey chat, give this in a nice way so I reply on hackerone with this comment > This looks like you accidentally pasted a part of your AI chat conversation into this issue, even though you have not disclosed that you're using an AI even after having been asked multiple times. A sample of what they have to deal with. Source: https://h…

They're still very graceful about it, seeing it as a learning opportunity instead of closing it as spam like a lot of the internet has done for the past 30 years.

Re: Death by a Thousand Slops

#139

LLM are a net negative on society on so many levels.

Email came with spam, and we solved it. Similarly, we're discovering the same with AI, and we'll solve it. No need to throw out the baby with the bathwater.

We didn't solve it though, as the vast majority of email traffic and processing is spam and the filtering thereof.

Re: Death by a Thousand Slops

#140

You could charge a fee and give the money back if the report is wrong but seems well-intentioned. I see the issue with this, it's payment platforms. Despite the hate, cryptocurrency seems like it could be a solution. But in practice, people won't take time to set up a crypto wallet just to submit a bug report, and if crypto becomes popular, it may get regulations and middlemen like fiat (which add friction, e.g. char…

Charging a fee to submit a bug report raises the barrier to entry and will reduce the amount of effort people are willing to spend. Which can be a net positive - charging $100 to be able to submit an app to Apple's app store helped prevent a lot of spammy low-effort iFart apps in the early days.
Post reply on HN