Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Openrsync: An implementation of rsync, by the OpenBSD team

github.com

Post reply on HN
Print view View original

171–180 of 193 posts

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

#171

Post by Panino »

dcrazy wrote: post #151
wtetzner wrote: post #111

Earlier quoted context omitted.

> 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 This appears to match "normal" `rsync` behavior as well. I think you need a trailing slash after `services` to sync only the contents. EDIT: actually my "normal" rsync is openrsync on macOS...

Nonetheless, this matches vanilla rsync.

No, it doesn't.

I think some people may not be reading closely. On Unix, "/etc/services" is a file, not a directory:

  $ file /etc/services                                                                                                                         
  /etc/services: ASCII text
Here are two OpenBSD 7.9 endpoints running Samba rsync:

rsync -av -e ssh /etc/services example.com:/tmp/services

The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services. The outcome is exactly the same as if I had run "scp /etc/services example.com:/tmp/services"

  client$ sha256 -q /etc/services                                                                                                                    
  469d28e72ed0e0994d31b555cc1bed7bc95a23fd1beeb30062affb64db0dd44a

  server$ sha256 -q /tmp/services                                                                                                          
  469d28e72ed0e0994d31b555cc1bed7bc95a23fd1beeb30062affb64db0dd44a
openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services

The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services/services. The outcome is NOT the same as if I had run "scp /etc/services example.com:/tmp/services"

Please note that "/tmp/services" and "/tmp/services/services" are different.

  client$ sha256 -q /etc/services                                                                
  469d28e72ed0e0994d31b555cc1bed7bc95a23fd1beeb30062affb64db0dd44a

  server$ sha256 -q /tmp/services  
  sha256: /tmp/services: read error: Is a directory
  server$ sha256 -q /tmp/services/services                                                                                                 
  469d28e72ed0e0994d31b555cc1bed7bc95a23fd1beeb30062affb64db0dd44a
Here's an OpenBSD 7.9 client and Ubuntu server both running Samba rsync:

rsync -av -e ssh /etc/services example.com:/tmp/services

The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services. The outcome is exactly the same as if I had run "scp /etc/services example.com:/tmp/services"

If you disagree, please state what operating systems you're using and copy/paste the output of the following commands on each side:

  uname -a
  rsync -V
  openrsync -V
I get

  $ rsync -V
  rsync  version 3.4.3  protocol version 32
  (snipped)

  $ openrsync -V
  openrsync 0.1 (protocol version 27)
Then please run the commands I ran above, in particular

openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services

And then type "file /tmp/services" on the remote server.

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

#172

Post by tardedmeme »

brnt wrote: post #67
gblargg wrote: post #58

Earlier quoted context omitted.

It kind of reminds me of the equality of opportunity people versus the equality of outcome people. One sets the starting conditions for developers, the other the ending conditions for users.

Since developers are a subset of users, it's actually possible to calculate which is more open.

You forgot the shareholders, who are not users but have less freedom under the GPL.

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

#173

Post by tardedmeme »

KZerda wrote: post #21
kennywinker wrote: post #17

Earlier quoted context omitted.

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 BSD license is why we have Valkey and not a purely closed-source Redis. It would have been much easier to perform the rugpull if Redis had initially been GPLed.

How would you rugpull a GPL Redis?

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

#174

Post by m463 »

SoftTalker wrote: post #126
hilsdev wrote: post #104

Earlier quoted context omitted.

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

It's not, for example cp -R doesn't change behavior on the basis of a trailing slash on directory names.

I was implementing something recently and stumbled across that cp difference. ugh.

the trailing slash is pretty convenient.

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

#175

Post by denysvitali »

mtlynch wrote: post #143
denysvitali wrote: post #50

There's also a Go implementation by Michael Stapelberg / the Gokrazy team: https://github.com/gokrazy/rsync

The gokrazy team being Michael Stapelberg : ) https://github.com/gokrazy/rsync/graphs/contributors

I mean, yes, mostly him (and he gave multiple presentations about this topic, very interesting!). - but there are other contributors too :)

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

#176

Post by asdsg »

trollbridge wrote: post #137

Given the sudden spike in vibe-coded commits to the rsync codebase, and regressions that’s introduced, this is very good news.

Yes, I also don't know how license critical distributions like Debian can even ship rsync now because it contains a) laundered code and b) Tridgell cannot claim copyright over the Claude additions.

So rsync should be pinned to an older version and just get security updates.

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

#178

Post by brianwawok »

prmoustache wrote: post #161
port11 wrote: post #154

Earlier quoted context omitted.

I was prepared to dismiss your comment because rsync has always been rock solid, but indeed upgrading broke my backup script. The latest issue on GitHub documents plenty of bugs introduced in the last 2 patches, including a monstrous ~9k LOC commit that was probably pointless. LLMs make writing code faster/easier, but the thinking was always the important bit. I’ve no idea why you’d muck up such a long-standing, reli…

When LLM allows you to produce code n% faster, it also allows you to introduce bugs n% faster. I find it quite strange that people do not seem to be aware of that...I think many started worshipping the tool as if it was some kind of divinity and lost all objctivity. This doesn't bode well for the future if people aren't able to review code anymore.

Don’t need people to review code, need more LLMs. People aren’t that magical.

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

#179

Post by wpm »

sudoshred wrote: post #155
krelas wrote: post #136

Earlier quoted context omitted.

This switch happened in macOS 15.4, it was pretty easy to miss.

sounds like a compliment to the implementation

Or more likely that prior to 15.4, macOS was using an ancient version of rsync because Apple wants to avoid the GPL 3.0. rsync went GPL 3.0 in 2007.

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

#180

Post by isityettime »

maleldil wrote: post #167
isityettime wrote: post #117

Earlier quoted context omitted.

One of HN's favorite hackers has done that: https://justine.lol/pledge/ There was a discussion here about it a few years ago: https://news.ycombinator.com/item?id=32096801

> favorite Interesting choice of word

She's excellent and her stuff has made it to the front page many times. I love seeing her work come up and I imagine many others here feel the same way.
Post reply on HN