Live data from Hacker News

Openrsync: An implementation of rsync, by the OpenBSD team

github.com

91–100 of 193 posts

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

#91
post #24

Earlier quoted context omitted.

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.

Openrsync is a project that’s existed for a long time and is a great example of people building what they want.

This thread has people suggesting it’s good or important to go tell open source devs they’re using bad tools.

The former is great. The latter is not.

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

#92
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…

> Apple and Android will prefer it,

My thought upon reading this is why would Apple or Android bother including rsync? I've noticed that I've needed to install it manually on fresh installs of Debian, FreeBSD...

But then, I just checked a recent Mac that I don't use much and haven't put much on, and it's installed.

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

#93
post #74

Earlier quoted context omitted.

Nobody ever claimed that “Open” is a prefix used unambiguously by only one group of people ever. In fact, your insistence that “Open” can only be used by projects that are replacing proprietary software is itself very odd. OpenBSD itself has had its name for thirty years, and is not named for being an “open source” implementation of a proprietary OS.

The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that. Do not invent arguments that I did not make. I have only said that naming it openrsync when rsync already exists and is "open" in the general sense is confusing. I find the negative reactions to this observation very confusing, especially yours, but I see that you're an OpenBSD developer so that explains yo…

You’re inventing an argument I didn’t make. OpenBSD doesn’t own “open”. Literally no one is saying that. What I did say is that openrsync is named that because the OpenBSD team names their projects that way. The “open” in this project means that it came from OpenBSD, not that that it’s in contrast to rsync being proprietary (which it isn’t).

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

#94

Earlier quoted context omitted.

OpenSSH was a 'reaction' to the original SSH(.com) code getting closed source: > OpenSSH originated in 1999 as a fork of Björn Grönvall's OSSH, which derived from Tatu Ylönen's original SSH 1.2.12 release, the last version distributed under a license permitting open-source redistribution before Ylönen's subsequent software became proprietary under SSH Communications Security.[4] * https://en.wikipedia.org/wiki/OpenSS…

Is rsync going closed source? If not, how is that the same thing?

> Is rsync going closed source? If not, how is that the same thing?

Not closed source, but with rsync 3.0 it changed its license to GPL3, which a lot of folks don't like: BSD/MIT licenses have zero limitations on use and distribution, GPL2 (rsync 1.x, 2.x) forces one to release code, GPL3 (rsync ≥3.x) adds further restrictions.

Some folks want to distribute code with as few restrictions as possible. Other folks have a great good/goal in mind (e.g., 'all software is open source') and so add 'local restrictions' to hopefully achieve greater non-restrictions.

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

#95
post #74

Earlier quoted context omitted.

Nobody ever claimed that “Open” is a prefix used unambiguously by only one group of people ever. In fact, your insistence that “Open” can only be used by projects that are replacing proprietary software is itself very odd. OpenBSD itself has had its name for thirty years, and is not named for being an “open source” implementation of a proprietary OS.

The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that. Do not invent arguments that I did not make. I have only said that naming it openrsync when rsync already exists and is "open" in the general sense is confusing. I find the negative reactions to this observation very confusing, especially yours, but I see that you're an OpenBSD developer so that explains yo…

> The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.

What was said is that the OpenBSD operating system folks chose to use the Open— prefix for all their other projects ("They simply ran with the naming convention."). What was not said was that all Open— prefixed projects were from them.

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

#96
post #60

Earlier quoted context omitted.

Is rsync going closed source? If not, how is that the same thing?

OpenBSD didn’t get its name from NetBSD going closed source.

Historically speaking, it may have meant open to poorly socialized developers.

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

#97

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.

Thanks for the heads-up! I wasn't aware that Tridge is using Claude. I shall use Openrsync from now on.

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

#99
post #9

Earlier quoted context omitted.

OpenBSD folks would consider the GPL to be less open due to the requirement to apply the GPL to any derivative works.

And GNU folks would say the GPL is actually the more open choice because it forces the project to stay open. Two different ways of thinking about it I guess... it's nice to have choices and I don't think one is more or less "correct", more a matter of opinion/taste I guess.

I don't think the FSF would say that. They prefer the GPL, because it prevents someone from making a closed derivative, but I haven't seen them ever claim it is more open than "permissive" licenses.
Post reply on HN