Live data from Hacker News

Openrsync: An implementation of rsync, by the OpenBSD team

github.com

11–20 of 193 posts

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

#11
post #9
post #6

What's the deal with the name? Openrsync implies to me that it's an open source alternative to a closed source program. But the original Rsync is GPL? Is this just the pushover license making it "more open"?

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.

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

#12
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.

In any case, it's important to identify projects that are beginning to actively vibecode and clearly express position on this issue on various platforms so that authors and maintainers receive feedback. Even if this particular bug was not written by LLM in this particular case, it's not a fact that the release does not include other regressions and that subsequent vibecoded versions will not include them & new ones.

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

#13
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.

> more open choice because it forces the project

A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.

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

#14
post #3

I have not checked with OpenBSD 7.9, but as of 7.8 it did not support --exclude or -z. But outside of that openrsync works great. (EDIT: --exclude is now supported on 7.9. Not sure when that was added, nice!) But seems avoiding "slop" is getting very hard. I saw postfix now has a bit of AI code in it. https://mastodon.sdf.org/@mrmasterkeyboard@mastodon.social/1...

Somewhat ironic Postfix has a record of no root/RCE in the default install, where opensmptd hasn't (CVE-2020-7247). Time will tell if it stays that way.

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

#15
post #6

What's the deal with the name? Openrsync implies to me that it's an open source alternative to a closed source program. But the original Rsync is GPL? Is this just the pushover license making it "more open"?

Many projects closely associated with OpenBSD start with "open"... openssh, openbgpd, openntpd, opensmtpd etc.

Not many are reimplementations of existing, much more popular, already open source projects.

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

#16

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.

I feel bad for people with the real name Claude.

It took me quite some time to realize what an utterly presumptuous product name Claude Code actually is, but only because Shannon is rarely mentioned with his first name. It's golden calf levels of hubris, even more so if you consider how incapable it was on release. It's like renaming calc.exe Einstein. Incredibly poor taste, but entirely in line with AI tech bro mentality.

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

#17
post #13

Earlier quoted context omitted.

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.

> more open choice because it forces the project A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.

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.

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

#18
The actual work of porting is matching the security features provided by OpenBSD's pledge(2) and unveil(2). These are critical elements to the functionality of the system. Without them, your system accepts arbitrary data from the public network.

https://justine.lol/pledge/

I am not seeing pledge on Alpine Linux in edge. Have people been testing Pledge on Linux? Did I perhaps misunderstand the risk of using Openrsync without pledge? Or is this article just for OpenBSD users?

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

#19
post #13

Earlier quoted context omitted.

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.

> more open choice because it forces the project A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.

It’s not coercion. You’re free to not use it, or alternatively do what these folks did, write your own. Coercion would be forcing people to use it through some mechanism, which clearly isn’t possible with GPL.

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

#20
post #13

Earlier quoted context omitted.

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.

> more open choice because it forces the project A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.

Allowing closed-source to exist is always the less moral choice for many reasons (one example being ecological sustainability)
Post reply on HN