5 ms·

On one hand, it's a little annoying that openrsync doesn't support some features that rsync does. On the other hand, it's great that there are multiple indepen

On one hand, it's a little annoying that openrsync doesn't support some features that rsync does. On the other hand, it's great that there are multiple independent implementations of rsync now. It means that it's actually being treated as a protocol, not just a piece of software.

chungy 2y ago
The website says "We are still working on it... so please wait." rsync has a lot of features, surely this will take a good amount of time.
varenc 2y ago
I'm exciting about this too. It becoming more like a protocol makes me optimistic we'll see binary diff API points based on the rsync algorithm. fun fact: Dropbox internally used rsync binary diff to quickly upload small changes to large file. I assume they still do. But their public API endpoints don't offer this and a small change to a large file means the whole file must be updated.
- andrewflnr 2y ago
  > binary diff API points based on the rsync algorithm Now that's an idea I never considered. Nice.
  - nine_k 2y ago
    Now consider applying it to git. How about clean semantic diffs to your .xlsx files? To your .PNG files?
    - andrewflnr 2y ago
      ...that's rather a different question, I think. Rsync doesn't claim to use a semantic diff.
- zmj 2y ago
  I implemented rsync's binary diff/patch in .NET several years ago: https://github.com/zmj/rsync-delta https://github.com/zmj/rsync-delta It's a decent protocol, but it has shortcomings. I'd expect most future use cases for that kind of thing to reach for a content-defined chunking algorithm tuned towards their common file formats and sizes.
candiddevmike 2y ago
How does this mean rsync is a protocol?
- bombela 2y ago
  Think ssh, http etc
- somat 2y ago
  it was always a protocol, however it is never good when the protocol is defined by it's only implementation My understanding is that this is the whole reason for the existence of openrsync. The people doing work on the rpki standards wanted to use rsync for one type of transfer, the standards body (IETF?) balked with a concern that the rsync protocol had only one implementation, so the openbsd folk, specifically Kristaps Dzonson stepped up and wrote a second implementation. It does not do everything rsync does but it interoperates enough for the rpki project. https://man.openbsd.org/rpki-client https://man.openbsd.org/rpki-client
  - josephg 2y ago
    > it is never good when the protocol is defined by it's only implementation I don't know that I'd go that far. The benefit of having only one implementation of a protocol is that the protocol can evolve much faster. You don't have to have committee meetings to tweak how it works. And as a first pass, the more iterations you make of something, the better the result. Rsync is mature enough to benefit from multiple implementations. But I'm glad it had some time to iterate on the protocol first.
    - ycombinatrix 2y ago
      e.g. Wireguard
    - throw0101d 2y ago
      > The benefit of having only one implementation of a protocol is that the protocol can evolve much faster. Or you design the protocol to allow non-standard extensions, like with SSH, so you can have foo@example.com implemented by one product (and others can look for it if useful), and bar@example.org by another product. And if enough folks file the feature(s) useful they can be standardize with tweaks that fixed issues that were found though operational experience. Lots of IETF standards have a "x-" prefix mentioned for private / proprietary extensions.
drob518 2y ago
librsync, anyone?
- edoceo 2y ago
  LGPL
  - DrillShopper 2y ago
    Maybe Apple should stop leeching off Free Software then
    - p_ing 2y ago
      BSD license allows/intends for this. The basic netutils in Windows come from BSD.
    - simondotau 2y ago
      I don’t even know what you mean by leeching. Clearly you don’t like it so you should add a clause disallowing it into whatever software you write. If someone else wants to release their software under a more permissive license, that’s none of your damn business.
  - mattl 2y ago
    librsync is distributed under the GNU LGPL v2.1 I can see no reason why Apple wouldn't be fine with that.
secure 2y ago
Indeed! Have a look at http://github.com/stapelberg/rsync-over-grpc/ http://github.com/stapelberg/rsync-over-grpc/, where I demonstrate how to use the rsync protocol (specifically, my https://github.com/gokrazy/rsync https://github.com/gokrazy/rsync implementation) over gRPC. Very handy if SSH+rsync is locked down in your corporate environment, but building services with gRPC isn’t :)

chungy 2y ago

The website says "We are still working on it... so please wait." rsync has a lot of features, surely this will take a good amount of time.

varenc 2y ago

I'm exciting about this too. It becoming more like a protocol makes me optimistic we'll see binary diff API points based on the rsync algorithm. fun fact: Dropbox internally used rsync binary diff to quickly upload small changes to large file. I assume they still do. But their public API endpoints don't offer this and a small change to a large file means the whole file must be updated.

andrewflnr 2y ago
> binary diff API points based on the rsync algorithm Now that's an idea I never considered. Nice.
- nine_k 2y ago
  Now consider applying it to git. How about clean semantic diffs to your .xlsx files? To your .PNG files?
  - andrewflnr 2y ago
    ...that's rather a different question, I think. Rsync doesn't claim to use a semantic diff.
zmj 2y ago
I implemented rsync's binary diff/patch in .NET several years ago: https://github.com/zmj/rsync-delta https://github.com/zmj/rsync-delta It's a decent protocol, but it has shortcomings. I'd expect most future use cases for that kind of thing to reach for a content-defined chunking algorithm tuned towards their common file formats and sizes.

candiddevmike 2y ago

How does this mean rsync is a protocol?

bombela 2y ago
Think ssh, http etc
somat 2y ago
it was always a protocol, however it is never good when the protocol is defined by it's only implementation My understanding is that this is the whole reason for the existence of openrsync. The people doing work on the rpki standards wanted to use rsync for one type of transfer, the standards body (IETF?) balked with a concern that the rsync protocol had only one implementation, so the openbsd folk, specifically Kristaps Dzonson stepped up and wrote a second implementation. It does not do everything rsync does but it interoperates enough for the rpki project. https://man.openbsd.org/rpki-client https://man.openbsd.org/rpki-client
- josephg 2y ago
  > it is never good when the protocol is defined by it's only implementation I don't know that I'd go that far. The benefit of having only one implementation of a protocol is that the protocol can evolve much faster. You don't have to have committee meetings to tweak how it works. And as a first pass, the more iterations you make of something, the better the result. Rsync is mature enough to benefit from multiple implementations. But I'm glad it had some time to iterate on the protocol first.
  - ycombinatrix 2y ago
    e.g. Wireguard
  - throw0101d 2y ago
    > The benefit of having only one implementation of a protocol is that the protocol can evolve much faster. Or you design the protocol to allow non-standard extensions, like with SSH, so you can have foo@example.com implemented by one product (and others can look for it if useful), and bar@example.org by another product. And if enough folks file the feature(s) useful they can be standardize with tweaks that fixed issues that were found though operational experience. Lots of IETF standards have a "x-" prefix mentioned for private / proprietary extensions.

drob518 2y ago

librsync, anyone?

edoceo 2y ago
LGPL
- DrillShopper 2y ago
  Maybe Apple should stop leeching off Free Software then
  - p_ing 2y ago
    BSD license allows/intends for this. The basic netutils in Windows come from BSD.
  - simondotau 2y ago
    I don’t even know what you mean by leeching. Clearly you don’t like it so you should add a clause disallowing it into whatever software you write. If someone else wants to release their software under a more permissive license, that’s none of your damn business.
- mattl 2y ago
  librsync is distributed under the GNU LGPL v2.1 I can see no reason why Apple wouldn't be fine with that.

secure 2y ago

Indeed! Have a look at http://github.com/stapelberg/rsync-over-grpc/ http://github.com/stapelberg/rsync-over-grpc/, where I demonstrate how to use the rsync protocol (specifically, my https://github.com/gokrazy/rsync https://github.com/gokrazy/rsync implementation) over gRPC. Very handy if SSH+rsync is locked down in your corporate environment, but building services with gRPC isn’t :)