I'm not sure there's anything novel about that approach - it's how I've addressed issues quite commonly when assigning them to team members. If you don't prime your preconceived notions on your coworkers(or AI in this case) and let them do their own evaluation from scratch, you can find gaps in yours and their understanding much easier.
> The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding
Hi fao, the issue you linked starts with:
> Rsync 3.4.3 and newer is AI slop, and currently has several open security vulnerabilities and other critical bugs (including some link-related ones) caused by said AI slop:
It then proceeds to link to multiple functional regressions caused by (theoretically) fixes to security vulnerabilities.
This took me about 10 mins to review. It seems that the person who created the issue did not bother to spend 10 minutes to check his own work. Is this "vibe reporting"? What should we say about the irony of employing "human slop" to trash "AI slop"?
Further ironically, the "aggregate of bugs" in void-linux included an issue that was not even about rsync. More "human slop" that you are happy with?
Their mission critical software has bugs in it - security issues, which the rsync maintainer is trying to fix. In his attempt, he introduced regressions*(maybe - because some of the reported regressions list exactly the security issue that is being fixed as their use case...). This happens every day to thousands and thousands of software projects. This is why we have pinned versions, release schedules, different release philosophies...none of this is new.
I don't understand what novel problem you think you've uncovered here.
I thunk you are right. This is just the same old stuff. I think people are reacting because AI is doing something, and that something seems to be accelerating the process of software development. So what people are seeing is the same issues we have always had compressed into tiny time frames.
But there is good news, at least I think. AI is also moving processes ideas and safety guards along at a faster rate. The only real downside is right now, at least, the amount of code being created outside of our safeguards has accelerated much much faster. This has happened in the past with software, so I am not too worried.
> It's like people telling you they will paint your house for free, even though the color of your house is perfectly fine
You are perfectly capable of saying "No, I like the color of my house already". Just pin rsync's version. This isn't some esoteric mechanism, it's standard practice.
If you were actually willing to charitably engage, tidge was working on fixing security bugs - your house had holes in it already! Your choice was to say I'm fine with the existing holes, or yeah please try to fix them. Unfortunately while fixing them he introduced some new ones, but hey, that's the nature of software development - sometimes you introduce new bugs when fixing old ones.
Again, this isn't some esoteric happenstance. It's so banal it must happen thousands of times per day across many other maintained projects.
There's a comment on the GitHub thread which also mentions pinning rsync version would be a bad idea. Many of the people affected by reversions are those with workflows vulnerable to the prior CVEs.
If Rsync is complete software, why aren't you pinning the version and avoiding any problems with updates?
Perhaps there's people that don't consider it complete software; they can bear the burden of the new releases while you stay on the old and complete one. This has been normal software release and use practice for decades. Whole Linux distributions are built around different philosophies on software releases.
And yet you're making an argument as if this is something novel...
The bugs were introduced because rsync had security issues(i.e. bugs) in it, presumably written into the code by humans.
It's really baffling to see so many people in this thread maintain the position that somehow software was clean and pristine until AI touched it with its evil.
Please try to at least put some sort of constructive argument forward, for example - I don't like AI because it might introduce more bugs than a careful human reviewer. Then we could discuss why a single maintainer is responsible for rsync and how they should handle the pressure of keeping it up to date - should they just stop making further changes, should they look for tools that might help them?
(By the way, if your position is that rsync was perfect before AI got its hands on it, you have a clear solution to all your problems - simply do not update to any newer versions)
Either way, move away from this absolutist nonsense that has no bearing to reality.
> It's really baffling to see so many people in this thread maintain the position that somehow software was clean and pristine until AI touched it with its evil.
Nobody maintains this position. Again, it's a strawman you made up, because it's easier to dismiss such "absolutist nonsense" than it is to just admit that these specific bugs were introduced as a direct result of careless AI usage.
If the developer is overwhelmed by the maintenance burden (they aren't, judging by how many AI commits they've been making to a large number of repositories), then that's an entirely different problem that deserves a good faith discussion, but delegating the work to AI is not the correct solution.
> By the way, if your position is that rsync was perfect before AI got its hands on it
Again, strawman, nobody said this either. In fact, quite the opposite - we want rsync to continue to be maintained by a human. If the current developer isn't interested in or capable of maintaining the project anymore, they should just say so instead of quietly letting AI take over, because then the likelihood of someone else stepping up to contribute would be much higher.
What were you trying to say? Because what you wrote is what parent responded to.
> there is no evidence that tridge did this regression testing
What evidence would you be looking for? New tests, like the ones added in the AI-assisted commits? What other evidence?
> If tridge did test for regressions, but chose not to document the regression
Presumably you weren't trying to imply here that tridge found a regression and decided to ship the code anyway; so parent went to a natural assumption - do you think testing for regressions finds all regressions?
We're massively cutting back on our business with Russia over their atrocities in Ukraine, but when it comes to human rights in Tunisia, we're willing to let this stuff slide. Sure, there's no war, but handing a country money to enforce their deadly anti-refugee violence is very bad.
This article was written during a time where the idea of a semantic web was still bright and strong. Scrapable HTML websites would have been at the forefront of interchange ideas then.
Gitlab implements this compensation model openly(to the point where there is a calculator for it!) - I don't remember how well it was received when it was first announced, but looks like Google is applying a similar idea.
I don’t think the calculator is public. It used to be and last time I tried it the results were terrible for my area I guess because there just aren’t any other technologists here so nothing to compare to - but that doesn’t say anything about me or how much I’m worth! Also when you looked in the data file you could see little pockets of higher paying areas - I guess if they can’t recruit you they create a little higher paying bubble for you. So I don’t think it works well and it’s also possibly open to distortion.
My sense from looking at it a couple of times was that there was more and more "exception handling" over time, primarily to handle relatively high CoL places, e.g. nice college towns, in generally cheap rural locales.
Right - and I guess the way you got an exception made was by making a fuss… which means it’s just as personality driven as before and isn’t really the open system it thinks it is.
What makes you unhappy about this process?