For those needing context for the development of this package; this project is presently being developed as part of a RPKI validator.
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...
Openrsync: An implementation of rsync, by the OpenBSD team
81–90 of 193 posts
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#82I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively. The one place in my usage where it doesn't match Samba rsync is with the following: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/se…
Was there already a /tmp/services directory on the dest?
One of the biggest points of confusion with rsync is how directories and trailing slashes are handled.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#83I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively. The one place in my usage where it doesn't match Samba rsync is with the following: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/se…
> I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.
As someone who has also suffered uncountable years of abuse from rsync, I understand the impulse, but I think it makes a lot more sense (and is a safer default) to create a second ”services”.
If we have a chance to change rsync defaults to something less insane and save future generations from this mess I think we should.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#84Earlier quoted context omitted.
> more open choice because it forces the project A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.
Is this not the paradox of tolerance restated in different terms? BSD license is unrestricted, it tolerates taking open source and closing it, thus always being at risk of things closing down. GPL license doesn’t tolerate taking from open source and closing it, thus ensuring things stay open.
The paradox clears itself up if you look at what tolerance actually is. It's simply not interfering with people's agency over themselves. Given that your right to self-agency doesn't entitle you to restrict others' self-agency, behavior that does try restricting others' agency is automatically not included in "tolerance."
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#85I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively. The one place in my usage where it doesn't match Samba rsync is with the following: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/se…
> I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services. As someone who has also suffered uncountable years of abuse from rsync, I understand the impulse, but I think it makes a lot more sense (and is a safer default) to create a second ”services”. If we have a chance to change rsync defaults to something less insane and save future generations from this mess I…
We don't, since we're not implementing a UI from scratch, we're matching something else.
Of the two possible worlds where in one this reimplementation matches what some see as annoyances in the interface or in another they mostly match the interface except for a few cases where the purposefully diverge (for no good technical reason), IMO the latter is far worse and causes more enexpected behavior.
At most, add a special flag to opt into different default behavior so nobody is surprised by running the same command on different systems and getting different behavior.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#86Earlier quoted context omitted.
In any case, it's important to identify projects that are beginning to actively vibecode and clearly express position on this issue on various platforms so that authors and maintainers receive feedback. Even if this particular bug was not written by LLM in this particular case, it's not a fact that the release does not include other regressions and that subsequent vibecoded versions will not include them & new ones.
Do not going harassing developers because you think they are doing it wrong. If you can do better and don't want to actually contribute to the upstream you are always free to fork it.
That's literally what this thread is about.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#87I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively. The one place in my usage where it doesn't match Samba rsync is with the following: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/se…
Was there already a /tmp/services directory on the dest? One of the biggest points of confusion with rsync is how directories and trailing slashes are handled.
> Was there already a /tmp/services directory on the dest?
No. And just to make sure, I ran a quick 'rm -rf /tmp/services' on the remote host, then re-ran openrsync on the client. Same result. This is OpenBSD 7.9 on both sides.
And I 100% agree about trailing slashes.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#88This attempt to avoid things that use AI is increasingly looking like some weird kind of reverse whack-a-mole where each targeted hole becomes radioactive after. Just grabbing some popcorn to watch.
I feel bad for people with the real name Claude.
I think it would be funny to have a grad student named Claude for the hilarious ambiguity it would create.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#89There is also a (stub) web page: https://www.openrsync.org/ The problem with this fragmentation of rsync is that Apple and Android will prefer it, but the Linux and greater GPL world will adhere to the original implantation due to inertia. Power users will just have to know the quirks of each version. The only way to stop this is for the original author(s) to release this under a BSD license. Edit: For those assuming…
Basically like GNU Tar/CPIO and BSD Tar/CPIO. I've largely standardised towards using the bsd variant everywhere (especially since now even Windows ships it and it handles lots of other archive formats using the `tar` command) but it's always a pain to install it everywhere
Yeah, I'm leaning towards strongly preferring bsdtar since it's happy to work on e.g. zip files:) Does it have any real downsides?
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#90There is also a (stub) web page: https://www.openrsync.org/ The problem with this fragmentation of rsync is that Apple and Android will prefer it, but the Linux and greater GPL world will adhere to the original implantation due to inertia. Power users will just have to know the quirks of each version. The only way to stop this is for the original author(s) to release this under a BSD license. Edit: For those assuming…
> The only way to stop this is for the original author(s) to release this under a BSD license.
Would that stop it? My understanding was that at least OpenBSD tended do redo things for technical reasons, not just licensing