Live data from Hacker News

Openrsync: An implementation of rsync, by the OpenBSD team

github.com

101–110 of 193 posts

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#102
post #70

There 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 option should not to be to take away user freedoms. BSD licenses are popular with proprietary software writers because they can use it without any of the restrictions that seek to preserve the rights of the end user. Instead you get proprietary software stacks like Apple and Android that seek to lock the users out of anything not granted by the company.

The correct way to stop this is to file bugs against the software for not matching the de-facto standard of the copied software.

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#103
post #8

Earlier quoted context omitted.

https://social.treehouse.systems/@thesamesam/116662824873341...

+1 to this. Other than people's reflexive anger or fear about AI coming for their code, I don't see anything to suggest that these are bugs that are due to the inclusion of AI vs bugs in a program with a bunch of complex interop with the filesystem and network.

Yeah, nothing to suggest that here. We went from some commits every so often (because rsync was basically finished software) with a handful of issues a month, to "a bajillion Claude commits then a release" with a pile of issues within weeks, at least one of which is about how the goddamn thing doesn't build.

I can't possibly see a correlation.

Weird how 3.4.2. didn't have a similar deluge of issue reports, though.

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#104
post #73

I'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…

If you use a trailing slash on the source it copies from the directory, if you omit the trailing slash it copies the directory itself. AFAIK this is pretty standard across POSIX tools

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#105
post #82
post #73

I'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.

I hear that a lot, but I familiarized myself with it once and ever since it makes a lot of sense to me.

Source ending in “/“: You want what’s inside. Source not ending in “/“: You want the thing (i.e. directory itself). For the destination, it does not matter whether it ends in “/“ or not, but for consistency I like adding a “/“ anyway (I want to put thing inside the directory).

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#107
post #88

Earlier quoted context omitted.

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.

i want to name my new born claude

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#109

This 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.

How about the attempt to avoid things that use AI promiscuously and start exhibiting bugs? :-(

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#110
post #28

rsync has specific running modes for the super-user. It also pumps arbitrary data from the network onto your file-system. openrsync is about 10 000 lines of C code: do you trust me not to make mistakes? No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of…

No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of your rsync is hostile, you probably have bigger problems! I disagree. While rsync is most often used to transfer data between "friendly" systems, it's inherently crossing a security boundary. It's import…

It is almost universally hooked up using ssh tunneling so ssh takes care of the security boundary and ssh is well trusted.
Post reply on HN