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

21–30 of 193 posts

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

#21

Post by KZerda »

kennywinker wrote: post #17
gilrain wrote: post #13

Earlier quoted context omitted.

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

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.

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

#22

Post by Bender »

jmclnx wrote: 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...

Exclude is very commonly used in automation jobs to avoid duplicating big git repos and other big files. I think that would be a show stopper for a number of people.

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

#23

Post by throw0101a »

hamdingers wrote: post #15
ranger_danger wrote: post #10

Earlier quoted context omitted.

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.

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/OpenSSH

It was probably the second thing with the Open— prefix by this group of developers, OpenBSD itself being the first. They simply ran with the naming convention. OpenBGP/OSPF were developed as alternatives to Quagga (GPL).

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

#24

Post by stsquad »

triggis wrote: post #12
akerl_ wrote: post #8

Earlier quoted context omitted.

+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.

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.

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

#25

Post by agwa »

jmclnx wrote: 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...

Where do you see that about Postfix? I followed the links and the only thing I see is that AI is being used to find bugs, not write code.

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

#26

Post by akerl_ »

triggis wrote: post #12
akerl_ wrote: post #8

Earlier quoted context omitted.

+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.

No. It's not important. It's actually pretty shitty to go around looking for projects and then telling the maintainers you disagree with how they develop.

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

#27

Post by badreligion42 »

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.

And how exactly did the BSD license make creating Valkey easier? GPL and BSD licenses both have the source in the open. Anyone creating a fork, can easily do so for either BSD or GPL licensed projects. Since Redis is a database, which the user won't be using a binary of, even using a fork of a supposedly GPL-licensed Redis would not require you to share your modifications with your user, same as BSD.

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

#28

Post by tptacek »

rsync has specific running modes for the super-user. It also pumps arbitrary data from the network onto your file-system. openrsync is about 10 000 lines of C code: do you trust me not to make mistakes?

No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of your rsync is hostile, you probably have bigger problems!

(I'm not an rpki person so I don't know if there's some part of that problem domain that changes this equation. I'm not dunking on the project, just saying this snagged me in the README).

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

#29

Post by e12e »

Bender wrote: post #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…

From above your quote:

> The only officially-supported operating system is OpenBSD, as this has considerable security features.

And below your quote:

> This is possible (I think?) with FreeBSD's Capsicum, but Linux's security facilities are a mess, and will take an expert hand to properly secure.

It is portable in the sense that it compiles and runs, not in the sense that it has the same security features.

I'd love to see pledge/unveil on (upstream) Linux - but I'm not holding my breath.

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

#30

Post by skeledrew »

triggis wrote: post #12
akerl_ wrote: post #8

Earlier quoted context omitted.

+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.

> it's not a fact that the release does not include other regressions and [...]

Are you listening to yourself? The same exact thing also has applied, applies and will continue to apply to manually written code, in perpetuity. There's nothing new under the sun here; regressions happen when there's change, and the only way to mitigate is to have healthy feedback loops.

Post reply on HN