[flagged]
Please stop flooding our projects with AI slop to furnish your CV
131–140 of 162 posts
Re: Please stop flooding our projects with AI slop to furnish your CV
#132Earlier quoted context omitted.
AI code review is nice to have an additional pair of eyes but it doesn't substitute to the maintainer eyes. A big part of a review is deciding if you want that change merged in. Not because of the immediate code but what it means to the project to bring this in. AI code review, to my eyes, just reduce the number of bugs, they do not shorten the review time. Otherwise, it means you are compromising on the direction of…
I meant AI to judge whether a PR is trash or not for ban purposes. Not AI to do the thorough code review itself.
In that case yes I think that can be of real value.
Re: Please stop flooding our projects with AI slop to furnish your CV
#133Earlier quoted context omitted.
> it had actually submitted the issue directly to GitHub Did you fix that? Apologize to the people running the repo and all?
Its an actual issue, Claude included all the relevant code and filed a detailed one so I don't see whats wrong with that.
Noted.
Re: Please stop flooding our projects with AI slop to furnish your CV
#134What we need is a single line that can only be written two ways, each of which has a subtle security issue, so AIs can flip-flop it back and forth forever.
Re: Please stop flooding our projects with AI slop to furnish your CV
#135Earlier quoted context omitted.
Discussing the issues, achieving consensus, making sure the fix fits the existing patterns and actually warrants the change, etc. These are and have always been a challenging part of contributing to open source. Typing code in your private fork that satisfies your “idiosyncratic fix” has always existed and been always the easier aspect of such changes. Chances are many of these changes would never be accepted into th…
Certainly, but there was motivation to do that in the past. My patch would probably line up with the rest of the code in the direction that they desired and the cost of fork maintenance would have pushed me to upstream in a way acceptable to maintainers.
I find it hard to believe that this is the main motivation for most who contributors to OSS. Do you have a reference, research or poll that corroborate this?
You’re vastly overestimating the value of these “fixes” that now go to private forks, because maintainers also have access to LLMs and can prompt, probably better than a drive by fix since they have better understanding and context of the codebase.
Therefore I believe, in most cases, keeping those fixes to private forks is not a noticeable loss for the OSS projects.
Re: Please stop flooding our projects with AI slop to furnish your CV
#136One thing that really interests me is declining to issue CVEs. I get a lot of AI submitted security issues and they all want CVEs. But some are simple idor to access information around an age rating on selfhosted software for friends and family.
Does anyone have any advice when to decline CVEs?
Re: Please stop flooding our projects with AI slop to furnish your CV
#137Earlier quoted context omitted.
Originally, yes. Nowadays, it's trivial. Agents can handle this flawlessly.
There can be a point of divergence when even humans can't merge things anymore, so I highly doubt that experience is universal.
No you can't say that! It's the superintelligence. You will be left behind.
Re: Please stop flooding our projects with AI slop to furnish your CV
#138Earlier quoted context omitted.
We do similar in Homebrew by autoclosing opens without the issue template (which implies using the API which often now implies AI). The weird flip side is that the average good AI contribution is better than the average “I used no AI” contribution. Perhaps it’s because Homebrew has so many declarative guardrails and is so easy for agents to test.
Next time I'll have Codex use computer usage to manually fill out the template, lol.
As long as you have it disclose itself: feel free. We're not anti-AI use, we're just anti-low-effort AI use and don't see the need to apply effort to educate people who haven't applied the effort themselves.
Re: Please stop flooding our projects with AI slop to furnish your CV
#139Earlier quoted context omitted.
Why not let them have the status boost? This isn't zero sum.
> This isn't zero sum. True, it is actually negative sum, because fake merit erodes trust in real merit, as it makes it a lot harder to spot the latter.
Why should a maintainer care about keeping PR count as a signal of developer status? A good quality contribution is a good quality contribution. You only have a responsibility to your own users, keeping out bad code from your repo while accepting as much good code as you can without getting overworked. You don't have to look after other people status games.
If you judge first time contributors on accepted PRs that's as dumb as doing it based on their activity. It tells you nothing about quality. You're the stupid one for assuming all maintainers are as strict as you are.
Re: Please stop flooding our projects with AI slop to furnish your CV
#140Earlier quoted context omitted.
I ran through exactly this thought process & LLM based resolution just 8 hours ago with a segfault compiling a project which likely doesn't care about the given platform combo much.
Classic problem. I recall spending a long time trying to get Freespace 2 SCP working on the Via Unichrome onboard GPU I had decades ago. Who could possibly have cared for that? The intersection of the two sets was probably precisely one person. By the way, interesting person to have 512 IPv4s (and two /44s? Aren't those enormous?). Root-level http intentionally user/pass gated on your site? I was curious to see.
:D. Tl;dr: it's actually near minimal to dual stack and do BGP between 2 sites of redundant services with advertisement failover to the internet.
/48 is the smallest accepted IPv6 advertisement and /24 the smallest allowed IPv4 advertisement (on the net at least). IPv6 assignments are done on the nibble (/48, /44, /40, ...). Since I only have two sites I could have gotten away with a /23 and something like a /44 but then the RIR pointed out it'd probably be cleaner to manage to get a /40 and give each site a /44 at the same renewal cost. As to why, I've just always worked in or near the networking field and so it seemed cheaper/easier to run it all myself in the long run.
Through another very long story, the Org ID + ASN + IPv4 space + IPv6 space ended up costing something like ~$1k the first year and then ~$500 in yearly renewals. I'm not legally able to resell these for the massive market rate prices of /24s because of them being leased for $0 specifically to dual stack my core hosted services like DNS with my own public IP, but that's fine as I got them to use :).
The largest assignment I've ever had the pleasure of getting and deploying was a /32 (... of IPv6!) for an extremely large healthcare system. Certainly no great record smasher, but I thought it was cool to work on an IPv6 subnet so big it could have been an IPv4 route nonetheless! That one was still also very sparse of course, but similar kinds of reasoning ended up getting to that being much easier/better to work with than a dense assignment.
I also have a small MAC address range (a classical "OUI" sized range is 24 bits of addresses, I have 12 bits of addresses) for a small run of some hardware I was making for a particular customer use case. With the leftovers I put my laptop on it and get the occasional "how the hell?" when they see Wireshark decode my laptop MAC as "Dan_Smith_xx_xx" while packet capturing to troubleshoot.