I find the way that issue was opened incredible obnoxious, but it is baffling that the maintainers seem to have let AI loose on rsync. Like, why? Why try comparatively experimental crap when your fortune and reputation is made and you're the leader of a niche and immune to market pressure and the people love the thing and it does exactly what it's supposed to and works well?
It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling.
And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.
Oh no, not Rsync. I guess that's one good thing about MacOS shipping with an ancient version of rsync. Oh, wait, they ship openrsync now, but the command is still called rsync.
This is the third HN post I read on this topic. Everytime the same tweet (or whatever it's called for mastodon/bluesky/etc). Did anyone actually debug the issue?
Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?
It's called a post, the same as you used for Hacker News.
And yes, I debugged one of the issues. I made the second comment in one of them. Markus Mayer did some debugging, too.
Then I had to deal with something completely unrelated to computers for the rest of that day and several days thereafter, and came back to this.
The problem with compiling code that used new kernel features was a bit poorly done. Anyone with any experience knows that a simple #if defined(__linux__) , which is a platform test, does not cut it for feature testing. M. Mayer went with an autotools test, which is what I'd have done too.
The problem with the on-the-wire protocol is a tricky one, and caused by suddenly being conservative in what rsync accepts apparently without much testing of what out-of-range stuff in-the-wild rsync sends.
Few things can trigger me more then finding a bug/regression and when tracking it down the commit reads like "modernizing the code", replacing all var with let, etc.
I also hate the ai slop but on the flip slide this maintainer has been asking for help for years and dosent receive much in the discord. I also want quality code but don’t jump to demonize a volunteer especially when not many have jumped in to help
You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes.
Why do we need AI here?
And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.
What I have to do now, keep a fork of my entire system's toolkit?
Hacker News: “It’s unfair the burden put on maintainers of the core pillars of open source software. Show some respect for the maintainers, and do your best to contribute.”
… little changes …
Also Hacker News: “I have the right to tell you how to manage the project that you created and have maintained for 30+ years, because I feel very self-righteous about AI and code quality!”
I get the feeling that the GitHub issue space is used to wage some ideological warfare. It’s interesting to see how all this is panning and out how it would look like in the future. This tech is going absolutely nowhere.
Nobody whose software you use for free owes you anything. It is so important not to lose sight of this.
If you feel like they do owe you something, that's only because years of habit -- years of using other people's software for free, and having the good fortune of finding it generally to improve in quality over time -- has caused your baseline to drift from the true state of affairs, which is that nobody whose software you use for free owes you anything.
When commenting, please assume good faith (in other commenters and maintainers).
This is the third thread I've read on HN about the subject and I've sadly seen a lot of closeminded or shallow comments on each thread. Adding the above reminder, as I hope HN can engage in more thoughtful discussion.
72 comments
[ 2.9 ms ] story [ 50.7 ms ] threadWow.
1: https://github.com/RsyncProject/rsync/issues/929#issuecommen...
It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling.
And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.
Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?
And yes, I debugged one of the issues. I made the second comment in one of them. Markus Mayer did some debugging, too.
Then I had to deal with something completely unrelated to computers for the rest of that day and several days thereafter, and came back to this.
The problem with compiling code that used new kernel features was a bit poorly done. Anyone with any experience knows that a simple #if defined(__linux__) , which is a platform test, does not cut it for feature testing. M. Mayer went with an autotools test, which is what I'd have done too.
The problem with the on-the-wire protocol is a tricky one, and caused by suddenly being conservative in what rsync accepts apparently without much testing of what out-of-range stuff in-the-wild rsync sends.
You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes.
Why do we need AI here?
And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.
What I have to do now, keep a fork of my entire system's toolkit?
… little changes …
Also Hacker News: “I have the right to tell you how to manage the project that you created and have maintained for 30+ years, because I feel very self-righteous about AI and code quality!”
If you feel like they do owe you something, that's only because years of habit -- years of using other people's software for free, and having the good fortune of finding it generally to improve in quality over time -- has caused your baseline to drift from the true state of affairs, which is that nobody whose software you use for free owes you anything.
This is the third thread I've read on HN about the subject and I've sadly seen a lot of closeminded or shallow comments on each thread. Adding the above reminder, as I hope HN can engage in more thoughtful discussion.