1. 54

  2. 17

    Wait, was this written “just” to avoid the standard, GPL-licensed rsync? Or what’s the story?

    1. 22

      RPKI requires use of rsync protocol. There’s only one implementation of rsync. Internet protocols should not depend on a single implementation.

    2. 4

      Just tested this via rsync over ssh and successfully copied a directory to a remote server. The syntax was almost the same, I used -r instead of -a, like so:

      $ openrsync -rv -e ssh /SRC/ example.com:/DST/

      I then removed one of the remote files and re-ran openrsync. It appears to have re-uploaded all the files, not just the missing one. Like the project description says, it’s “very new and very fast-moving” so surely it will continue progressing. Nice to see pledge and unveil in there also, especially as they’re not present in the rsync package/port.

      I’m impressed! Thank you Kristaps.

      1. 2

        You’re welcome! :)

      2. 3

        Please do not make feature requests: I will simply close out the issue.

        I wonder why.

        1. 15

          I’d probably pull off such a thing as well because there is a huge amount of users confusing OSS Maintainers with Commercial Support, which is really draining.

          1. 3


            1. 2

              I understand but I think it would suck if everyone did that way. Sure we can always fork but one fork per feature sounds like a huge waste of resources.

              1. 8

                I said feature requests. E.g., “can you please support –exclude”. Code is not a feature request.

                1. 8

                  It says you’ll accept their work instead of attempts to get extra work out of you for free. That seems very reasonable. :)

                  1. 2

                    Yeah I was confusing refusing feature requests with refusing pull requests.

                    A feature requests first is a good way to see if the maintainer would accept a PR (and to see if other users wants it) however. Well for the way most of us use Github, I guess we could contact the maintainer instead if his email is on his profile.

                    1. 7

                      In this case, feel free to ask here! (I’m the maintainer.)

                2. 2

                  On the other side, having feature requests open helps newcomers to see what they could help with.

                3. 4

                  If you read the rest of the README you pretty much got the answer.

                  1. 3

                    Because that’s the only way your issue tracker won’t have 3000 open issues and 1000 open PRs in 5 years.

                    1. 1

                      Yeah because you won’t have users because you’re kind of flipping them off.

                    2. 2

                      It might be that the projects goals are purely to reach feature parity/compatibility with rsync, thus feature requests would be redundent/unnecessary.

                      1. 1

                        Probably focusing on just being rsync compatible for now I guess?

                        I find it interesting the dev is still using CVS too.