This guy is already retired, he wants to spend his days sailing and here we are bitching about rsync not being good enough while we all use if for free
Most of us won’t be able to help code, fine.
But most of us could help with translations
Many of us could help with documentation
Some of us could contribute regularly with small financial donations
Some of us might have enough knowledge and expertise and experience to help code
Others could come up with other tasks that could be done.
The point is: rsync need more resources. Either we get him more resources or we STFU about the retired dev using AI. We can’t have it both ways.
This whole debacle is making me extremely black pilled about open software in general. Just like cheap computing has died in recent years, I suspect non corporate free software is about to meet the same end to the acclaim of people who think they’re doing a good thing for the world.
Do you mind describing what black pill means in this context? I’m familiar with the red/blue pill references, but could only find the incel context of black pill online. Is it just a “harsh truth” kinda thing?
This article is pretty shoddy. It acknowledges that “red/blue pill” comes from the Matrix but then acts like incels were the only ones using it and pushing its evolution as a suffix. When in reality it developed across the whole internet, not just within incel communities. Oldass encyclopedia being out of touch.
“Blackpilled” specifically basically just means pessimistic, doomer, etc. I see it used in this context on a regular basis with no association to incel, rightwing, or misogynist ideologies.
It certainly has its own unique meaning within those communities, but it’s very clear that’s not how OP was using it. To argue they were misusing the term you’d have to prove that most people here associate “x-pill” terminology with incels, rather than directly with The Matrix and/or how the terminology is commonly used on social media by regular people.
I can’t argue the current usage as I’m not terminally online enough anymore to have that knowledge but the original online usage of red-pill and ‘redpilling’ somebody was absolutely intrinsically connected to far-right and incel online spaces.
When you say it “developed across the whole internet, not just within incel communities” this is evidentially wrong. Early use was based around 4chan and manosphere/MRA ‘gender-truths’ and then increasingly co-opted by the alt-right pipeline to invoke a rejection of what they saw as the liberal status quo. Redpilling in its early use was basically slowly radicalising somebody to extreme alt-right viewpoints.
It’s one of the phenomena of linguistic appropriation (matrix redpill & trans-identity notions -> right-wing appropriation, gender standards and conservative values -> wide-spread normalization also outside strictly political contexts) by the right that words like woke, privileged also went through.
I think you misread my comment. I’m depressed that people are harassing open source devs, not that open source devs use LLMs.
I don’t give a shit whether a maintainer like Tridge uses AI, because i trust them to review the AI’s code like they’ve reviewed human contributions since forever.
I think it’s unreasonable to complain that the guy is not working enough for free.
I think it’s reasonable to alert people that rsync is not being properly maintained anymore and to seek alternatives.
I would prefer the maintainer to announce publicly that he can’t maintain the project anymore and is looking for help/someone to take over instead of breaking the project silently.
But where will the maintainers for these alternatives come from, when barely anybody has stepped up in the 30 years of rsync’s existence? Your comment implies that tridge didn’t call for help before, which is far from the truth.
This is thankless maintenance on critical software, not some *-arr toy project for hobbyist self-hosters.
Universal Healthcare would increase the pool of willing developers by an order of magnitude here.
I’m not so sure. The problem is not a lack of developers. The problem is a lack of developers interested in working on rsync, or on any other specific project you can name. Most developers would rather work on their own projects.
I would also question whether or not universal healthcare (though unquestionably a good thing) would actually result in such an increase in available developers. The following study looked at the geographical distribution of OSS developers in 2021, via Github contributions, and found that the US had a similar number of OSS developers per capita compared to similar countries that do have universal healthcare (see table 2):
Github and the whole culture that it came out of it used to (it feels sooooo good to say that in the past tense) be globally hinged on Silicon Valley, why would you not expect to see a anomalously high number of US developers on it?
That’s definitely a possibility, along with the possibility that countries with worse English language skills might be underrepresented on GitHub, despite having universal healthcare. Conversely, if the US is over-represented on GitHub, then the pool of US developers who are not already active on GitHub may also be depleted compared to other countries. However, that is not something we can read out of the available evidence.
The most we can conclude is probably that the US getting universal healthcare might result in an increase in available OSS developers, depending on which assumptions turn out to be correct, but suggesting that it would lead to an order of magnitude increase is surely premature
suggesting that it would lead to an order of magnitude increase is surely premature
The US is continuing to worsen in performance on meaures of small business entrepreneurship in essentially all industries in the US, software and software adjacent industries are no different especially if you don’t get distracted by the AI bubble inflating that value of a bunch of illusions claiming to be businesses.
It is easy to see how the inability of the average person to try a new idea, or risk taking on a project that may not pay off immediately translates directly to a lack of available developers for open source software projects.
The impact of Universal Healthcare would be huge for open source development in the US, the amount of programmers that would be pushed over the line from “just making ends meet while having a work life balance” to “ok maybe I could devote some time to open source development”.
Don’t get me wrong though, I think we need to normalize straight up paying developers for Open Source Development. Just because it is open source doesn’t mean it doesn’t take labor, that is not the argument I am making.
The thing with old, critical software is that after some time people don’t really want to dig through decades of C code and prefer to write something new using modern tools. Those projects get plenty of support because people actually do want to work on them. If no one wants to work on rsync than what the maintainer is doing now is just prolong it’s agony a couple of years. I would say he should do the minimum work, announce end of life date and move on. People that need tools like rsync will develop something.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
I’m sorry to say 90% of the internet’s load bearing infrastructure is in this situation. It’s just how the story goes, everybody wants to build low-stakes toy projects, nobody wants to do high-effort low-reward infrastructure work.
“Writing something new using modern tools” is all fun and sparkles, but then you run into the same issues as rsync except without the experience. Then you get attention from attackers, you get security issues, which you have to patch with defensive code which is not appealing to read and zero fun to write. Before you know it your project is “decades of Rust/Zig/Lisp” which nobody wants to touch and you’re back at square one. All you’ve accomplished is give the attackers a few years of low hanging fruit and easy exploits.
There’s a reason why we get a million shiny toys a year but solutions like rsync stay entrenched for decades.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Here are the percent of commits from the top committer in each repository you mentioned, as well as rsync, over the last 3 months:
rsync: 99.0%
restic: 93.2%
rclone: 87.5%
union: 82.9%
syncthing: 74.4%
As you can see, each of this projects depends heavily on a single person, though to a lesser degree than rsync. That’s just the nature of most open-source software.
Note that I excluded dependabot commits from the calculations and counted Claude commits as the lead developer for rsync
People that rely on rsync start looking for alternatives
They try to switch and figure out what functionality is missing
They contribute to some of the alternative to fill the gaps
For example, I’m about to setup some syncing for my homelab and I will not use rsync for that. That’s why talking about the state of rsync is important. As I said, it’s not about attacking the dev for not working hard enough. It’s about long term planning.
I remember when the maintainer for discord.py stepped down. He eventually stepped back in because no one wanted took over the project and he didn’t want to see it die. This was before the current AI era, all someone had to do was continue to develop it.
I think almost everyone will do step 2 and 3 but not step 4.
The fact that open source exist and functions so well for decades shows that people do step 4. If no one wants to step in it usually means the project is not important.
I think what you’re missing is that the number of people doing step 4 has been going downhill steadily since the 2000s. People start open source projects yes, which for 99% of them don’t bring in any users and barely get maintained over the long run, but the pool of people willing to contribute to large established projects is so small it is becoming problematic.
Even Wikipedia is having its own editor crisis, where most of the power editors are greying out and barely anyone is stepping up to replace them.
And this is happening exactly because most people, like you, think that the free infrastructure around us is a fait accompli which doesn’t require us to personally get involved in their maintenance, and that we can even afford to scare away those that do contribute.
I don’t know the degree to that, but bugs do happen occasionally either way as long as there are changes. In the article, they explain why the changes are necessary. Prioritizing security over no-change-stability seems reasonable and warranted.
yes, there were regressions in some use cases of rsync in the 3.4.3 release. I quite deliberately tried to err on the side of fixing security issues for that release, and there were some valid (but unusual) use cases that got caught up in the changes.
So as I said, I don’t think it’s fair to scream at him to work harder. I do think it’s fair to worn people that rsync is having issues with stability. The author claims he knows what he’s doing and it’s all on purpose. You are free to trust him and ignore the whole affair. Other people may prefer to look for alternatives.
I doubly agree to this. The moment you are deciding the license of your fucking software please think carefully. It is a public service and the dev(s) ow you nothing. Not even an apology. What you own to the devs is much greater and very high on value. They made the software that runs on your own paid electricity, that you granted to them.
Either we get him more resources or we STFU about the retired dev using AI. We can’t have it both ways.
Of course we can do both. I don’t have those resources to grant
and I get to point out that Tridge, despite his well earned reputation from the huge contribution of creating rsync and bringing it to the point where it’s effectively complete as an essential piece of internet infrastructure, was massively arrogant in abdicating his responsibility by shovelling LLM slop into that same piece of infrastructure.
In your eyes, is all AI-produced text and code slop? Or did you check on the Python tests they designed and implemented with the help of AI, and after analysis of that, you came to the conclusion that it’s slop (as in nonsensical, incoherent, faulty, or similar)?
I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:
So, look. One shot rewriting the whole test suite in another language is probably not great to do, but what happened here is so much worse than you are expecting.
https://github.com/RsyncProject/rsync/pull/903/
This does not “translate tests into pytest” or a unit testing framework, it writes its own testing framework where tests are whole python scripts that redefine basic test functions in every script. Surely there would be a single way to “run rsync and get the results” - nope, well, there is, but then every test file will randomly redefine its own _run_and_capture function. So like now rsync needs a test suite for its test suite.
If instead of telling an LLM to “rewrite the tests in python” you just searched “python testing” you would find the pytest docs. And then you would find examples. And then you could write fixtures to deduplicate all the prior shell script setup and teardown stuff, and so on. But since it was just “rewrite the tests in python” its now worse than before, and the odds of the rewrite actually being a 100% faithful translation are close to 0.
Yes right - and after reading about a dozen of the test scripts I can definitely see why using pytest would be useful here to consolidate some of the behavior that was repetitive and ad-hoc in the original testing scripts. Like the tests need to do repetitive things like set up test directories with different names and structures, run and capture results, setup and teardown a server, parameterize over a range of values. Done right, a pytest suite would have made perfect sense and improved both the existing tests by making them more systematic and uniform, but also made it easier to add new tests over time. However that is not what happened, and what did happen is much worse because it did the opposite of almost all those desirable qualities.
You should read the whole thread, the author goes into more detail, as to why you cannot trust the software any more after the rewrite of the unittests and why you should avoid any new release of rsync since then.
tridge’s blog post makes it clear that this was not “one-shotted” at all.
You should read the whole thread
I regret reading it; I’ll assume in good faith that it wasn’t LLM generated but it is ironically as confidently wrong as if it were.
It almost (and should have) lost me when it started by quote-agreeing with someone else saying “rsync was basically done until the maintainer discovered vibecoding” - no, pay attention, it was not “basically done”, there were/are a mountain of CVEs!
But then this got my interest:
This does not “translate tests into pytest” or a unit testing framework, it writes its own testing framework where tests are whole python scripts that redefine basic test functions in every script. Surely there would be a single way to “run rsync and get the results” - nope, well, there is, but then every test file will randomly redefine its own _run_and_capture function.
tridge says he has used pytest on other projects and had good reasons not to use it here; I’m inclined to believe him.
But the notion of every test defining its own way to invoke rsync sounded like a valid criticism, and an easy one to verify, so I checked: It turns out that there is in fact a common run_rsync function which is used by the majority of the tests. One test defines its own _run_and_capture function (which differs in that it writes the output to a file, for reasons I didn’t investigate), and it looks like a few others invoke rsync other ways, but the majority of them use the common function.
So, that rambling thread’s sole concrete criticism of rsync’s new python tests turns out to be false.
I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:
They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.
The author also greatly exaggerates the amount of code duplication: They claim that “tests are whole python scripts that redefine basic test functions in every script”, but in reality it is less than half of the tests that even define their own functions.
Most basic functions are imported from a shared module (rsyncfns.py), and when they aren’t it’s mostly because the code needs to do something different. From what I can see, there is some code duplication that could be moved to the shared module, and some code that could be refactored, but it’s a modest amount
Repost of my reply elsewhere:
This guy is already retired, he wants to spend his days sailing and here we are bitching about rsync not being good enough while we all use if for free
Most of us won’t be able to help code, fine.
But most of us could help with translations
Many of us could help with documentation
Some of us could contribute regularly with small financial donations
Some of us might have enough knowledge and expertise and experience to help code
Others could come up with other tasks that could be done.
The point is: rsync need more resources. Either we get him more resources or we STFU about the retired dev using AI. We can’t have it both ways.
This whole debacle is making me extremely black pilled about open software in general. Just like cheap computing has died in recent years, I suspect non corporate free software is about to meet the same end to the acclaim of people who think they’re doing a good thing for the world.
Do you mind describing what black pill means in this context? I’m familiar with the red/blue pill references, but could only find the incel context of black pill online. Is it just a “harsh truth” kinda thing?
Sorry for bringing terminally online slang to the table haha
In my head yeah it’s the pill that teaches you a bleak and depressing truth but shows you no way out of it. I may be misusing the term.
You most certainly are, use a different metaphor/descriptor.
I most certainly won’t lol
Ok then, you are labelling yourself as a pathetic loser.
https://www.britannica.com/topic/What-does-black-pill-refer-to
Lol
This article is pretty shoddy. It acknowledges that “red/blue pill” comes from the Matrix but then acts like incels were the only ones using it and pushing its evolution as a suffix. When in reality it developed across the whole internet, not just within incel communities. Oldass encyclopedia being out of touch.
“Blackpilled” specifically basically just means pessimistic, doomer, etc. I see it used in this context on a regular basis with no association to incel, rightwing, or misogynist ideologies.
It certainly has its own unique meaning within those communities, but it’s very clear that’s not how OP was using it. To argue they were misusing the term you’d have to prove that most people here associate “x-pill” terminology with incels, rather than directly with The Matrix and/or how the terminology is commonly used on social media by regular people.
I can’t argue the current usage as I’m not terminally online enough anymore to have that knowledge but the original online usage of red-pill and ‘redpilling’ somebody was absolutely intrinsically connected to far-right and incel online spaces.
When you say it “developed across the whole internet, not just within incel communities” this is evidentially wrong. Early use was based around 4chan and manosphere/MRA ‘gender-truths’ and then increasingly co-opted by the alt-right pipeline to invoke a rejection of what they saw as the liberal status quo. Redpilling in its early use was basically slowly radicalising somebody to extreme alt-right viewpoints.
It’s one of the phenomena of linguistic appropriation (matrix redpill & trans-identity notions -> right-wing appropriation, gender standards and conservative values -> wide-spread normalization also outside strictly political contexts) by the right that words like woke, privileged also went through.
ain’t that a spicy squirrel…
He’s using it correctly
You gotta get up on ai start using it yourself, good or bad it is what it is and people will be left behind.
I think you misread my comment. I’m depressed that people are harassing open source devs, not that open source devs use LLMs.
I don’t give a shit whether a maintainer like Tridge uses AI, because i trust them to review the AI’s code like they’ve reviewed human contributions since forever.
I think it’s unreasonable to complain that the guy is not working enough for free.
I think it’s reasonable to alert people that rsync is not being properly maintained anymore and to seek alternatives.
I would prefer the maintainer to announce publicly that he can’t maintain the project anymore and is looking for help/someone to take over instead of breaking the project silently.
But where will the maintainers for these alternatives come from, when barely anybody has stepped up in the 30 years of rsync’s existence? Your comment implies that tridge didn’t call for help before, which is far from the truth.
This is thankless maintenance on critical software, not some *-arr toy project for hobbyist self-hosters.
Universal Healthcare would increase the pool of willing developers by an order of magnitude here.
No disagreement here but I’m not sure that’s on the menu right now
Either Universal Healthcare is on the menu or society falls apart, pick one.
Oh man I’m like super agreeing with you. Also I’m in a place that actually has universal healthcare, so it’s not like it’s unworkable
I’m not so sure. The problem is not a lack of developers. The problem is a lack of developers interested in working on rsync, or on any other specific project you can name. Most developers would rather work on their own projects.
I would also question whether or not universal healthcare (though unquestionably a good thing) would actually result in such an increase in available developers. The following study looked at the geographical distribution of OSS developers in 2021, via Github contributions, and found that the US had a similar number of OSS developers per capita compared to similar countries that do have universal healthcare (see table 2):
https://www.sciencedirect.com/science/article/pii/S0040162522000105
Github and the whole culture that it came out of it used to (it feels sooooo good to say that in the past tense) be globally hinged on Silicon Valley, why would you not expect to see a anomalously high number of US developers on it?
That’s definitely a possibility, along with the possibility that countries with worse English language skills might be underrepresented on GitHub, despite having universal healthcare. Conversely, if the US is over-represented on GitHub, then the pool of US developers who are not already active on GitHub may also be depleted compared to other countries. However, that is not something we can read out of the available evidence.
The most we can conclude is probably that the US getting universal healthcare might result in an increase in available OSS developers, depending on which assumptions turn out to be correct, but suggesting that it would lead to an order of magnitude increase is surely premature
The US is continuing to worsen in performance on meaures of small business entrepreneurship in essentially all industries in the US, software and software adjacent industries are no different especially if you don’t get distracted by the AI bubble inflating that value of a bunch of illusions claiming to be businesses.
It is easy to see how the inability of the average person to try a new idea, or risk taking on a project that may not pay off immediately translates directly to a lack of available developers for open source software projects.
The impact of Universal Healthcare would be huge for open source development in the US, the amount of programmers that would be pushed over the line from “just making ends meet while having a work life balance” to “ok maybe I could devote some time to open source development”.
Don’t get me wrong though, I think we need to normalize straight up paying developers for Open Source Development. Just because it is open source doesn’t mean it doesn’t take labor, that is not the argument I am making.
https://www.commonwealthfund.org/publications/issue-briefs/2018/oct/affordable-care-act-impact-small-business
https://github.com/rclone/rclone
https://github.com/restic/restic
https://github.com/bcpierce00/unison
https://syncthing.net/
The thing with old, critical software is that after some time people don’t really want to dig through decades of C code and prefer to write something new using modern tools. Those projects get plenty of support because people actually do want to work on them. If no one wants to work on rsync than what the maintainer is doing now is just prolong it’s agony a couple of years. I would say he should do the minimum work, announce end of life date and move on. People that need tools like rsync will develop something.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
I’m sorry to say 90% of the internet’s load bearing infrastructure is in this situation. It’s just how the story goes, everybody wants to build low-stakes toy projects, nobody wants to do high-effort low-reward infrastructure work.
“Writing something new using modern tools” is all fun and sparkles, but then you run into the same issues as rsync except without the experience. Then you get attention from attackers, you get security issues, which you have to patch with defensive code which is not appealing to read and zero fun to write. Before you know it your project is “decades of Rust/Zig/Lisp” which nobody wants to touch and you’re back at square one. All you’ve accomplished is give the attackers a few years of low hanging fruit and easy exploits.
There’s a reason why we get a million shiny toys a year but solutions like rsync stay entrenched for decades.
Here are the percent of commits from the top committer in each repository you mentioned, as well as rsync, over the last 3 months:
As you can see, each of this projects depends heavily on a single person, though to a lesser degree than rsync. That’s just the nature of most open-source software.
Note that I excluded dependabot commits from the calculations and counted Claude commits as the lead developer for rsync
How I imagine this:
For example, I’m about to setup some syncing for my homelab and I will not use rsync for that. That’s why talking about the state of rsync is important. As I said, it’s not about attacking the dev for not working hard enough. It’s about long term planning.
I remember when the maintainer for discord.py stepped down. He eventually stepped back in because no one wanted took over the project and he didn’t want to see it die. This was before the current AI era, all someone had to do was continue to develop it.
I think almost everyone will do step 2 and 3 but not step 4.
The fact that open source exist and functions so well for decades shows that people do step 4. If no one wants to step in it usually means the project is not important.
I think what you’re missing is that the number of people doing step 4 has been going downhill steadily since the 2000s. People start open source projects yes, which for 99% of them don’t bring in any users and barely get maintained over the long run, but the pool of people willing to contribute to large established projects is so small it is becoming problematic.
Even Wikipedia is having its own editor crisis, where most of the power editors are greying out and barely anyone is stepping up to replace them.
And this is happening exactly because most people, like you, think that the free infrastructure around us is a fait accompli which doesn’t require us to personally get involved in their maintenance, and that we can even afford to scare away those that do contribute.
The trouble with some of those projects (e.g. unison and sun thing) is that they don’t solve the same problem, not really.
A rewrite with modern tooling would be better done if it was incremental.
He’s been asking for help but nobody took him up on it.
Is that your assumption given that they’re using AI? Because it’s not at all what I have taken away from their article.
Is “not properly maintained anymore” your interpretation of them using AI? Or what do you base that on?
The whole story started because rsync stopped working for some users. That’s “not properly maintained” in my books.
I don’t know the degree to that, but bugs do happen occasionally either way as long as there are changes. In the article, they explain why the changes are necessary. Prioritizing security over no-change-stability seems reasonable and warranted.
The author said:
So as I said, I don’t think it’s fair to scream at him to work harder. I do think it’s fair to worn people that rsync is having issues with stability. The author claims he knows what he’s doing and it’s all on purpose. You are free to trust him and ignore the whole affair. Other people may prefer to look for alternatives.
I doubly agree to this. The moment you are deciding the license of your fucking software please think carefully. It is a public service and the dev(s) ow you nothing. Not even an apology. What you own to the devs is much greater and very high on value. They made the software that runs on your own paid electricity, that you granted to them.
Of course we can do both. I don’t have those resources to grant
and I get to point out that Tridge, despite his well earned reputation from the huge contribution of creating rsync and bringing it to the point where it’s effectively complete as an essential piece of internet infrastructure, was massively arrogant in abdicating his responsibility by shovelling LLM slop into that same piece of infrastructure.
Okay then you’re just bitching at a dev with nothing to help him might as well yell at the wind.
In your eyes, is all AI-produced text and code slop? Or did you check on the Python tests they designed and implemented with the help of AI, and after analysis of that, you came to the conclusion that it’s slop (as in nonsensical, incoherent, faulty, or similar)?
I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:
https://neuromatch.social/@jonny/116666900898570791
https://neuromatch.social/@jonny/116671260017373441
You should read the whole thread, the author goes into more detail, as to why you cannot trust the software any more after the rewrite of the unittests and why you should avoid any new release of rsync since then.
tridge’s blog post makes it clear that this was not “one-shotted” at all.
I regret reading it; I’ll assume in good faith that it wasn’t LLM generated but it is ironically as confidently wrong as if it were.
It almost (and should have) lost me when it started by quote-agreeing with someone else saying “rsync was basically done until the maintainer discovered vibecoding” - no, pay attention, it was not “basically done”, there were/are a mountain of CVEs!
But then this got my interest:
tridge says he has used pytest on other projects and had good reasons not to use it here; I’m inclined to believe him.
But the notion of every test defining its own way to invoke rsync sounded like a valid criticism, and an easy one to verify, so I checked: It turns out that there is in fact a common
run_rsyncfunction which is used by the majority of the tests. One test defines its own_run_and_capturefunction (which differs in that it writes the output to a file, for reasons I didn’t investigate), and it looks like a few others invoke rsync other ways, but the majority of them use the common function.So, that rambling thread’s sole concrete criticism of rsync’s new python tests turns out to be false.
They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.
The author also greatly exaggerates the amount of code duplication: They claim that “tests are whole python scripts that redefine basic test functions in every script”, but in reality it is less than half of the tests that even define their own functions.
Most basic functions are imported from a shared module (
rsyncfns.py), and when they aren’t it’s mostly because the code needs to do something different. From what I can see, there is some code duplication that could be moved to the shared module, and some code that could be refactored, but it’s a modest amountThen go ahead and write your own version you can trust. Hell you can fork the last version without AI usage if you’re convinced that’s the problem.