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

61–70 of 193 posts

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

#61

Post by homebrewer »

kstrauser wrote: post #57
formerly_proven wrote: post #16

Earlier quoted context omitted.

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.

That linkage never occurred to me, or, I suspect, them. Claude use to be a reasonably common name. I have an uncle Claude. Why do you believe they named it after Shannon in particular?

It seems to be a widely repeated "fact" which can't be traced to anything particularly authoritative:

https://archive.is/pt5fQ

https://britannica.com/topic/Claude-AI

Looks like the 2023 NYT article started it, and it uses this as reference:

> depending on which employee you ask, was either a nerdy tribute to the 20th-century mathematician Claude Shannon

Personally I always associated it with the silent protagonist from GTA3.

https://gta.fandom.com/wiki/Claude

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

#62

Post by justinsaccount »

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…

that quote seems to be a bit of an oversimplification to the point of being completely wrong.

> Without them, your system accepts arbitrary data from the public network.

Neither of these features change if you are accepting arbitrary data from the public network. They limit what an exploited process can do. It's explained properly in the 'Security' section, so I'm not sure where this came from.

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

#64

Post by 1over137 »

ranger_danger wrote: post #5
skeledrew wrote: post #4

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.

Yeah, especially since most Americans don't know how to properly pronounce Claude.

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

#65

Post by teddyh »

applfanboysbgon wrote: post #55
triggis wrote: post #12

Earlier quoted context omitted.

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.

Friendly reminder that volunteer maintainers owe you literally not a single goddamn thing. I absolutely want no AI slop in my commercial products that I pay money for, but your feedback is not important to people you are not paying to develop software for you. They gave away not only their software but the source code for free; if you have a problem with it, fork it. Which is something you can do with their generous…

> Friendly reminder that volunteer maintainers owe you literally not a single goddamn thing.

Technically true. However, I also do not owe them my silence.

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

#66

Post by SoftTalker »

ranger_danger wrote: post #10
WD-42 wrote: 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.

Notable exception, OpenSSL already had the Open prefix so the OpenBSD project is called LibreSSL.

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

#67

Post by brnt »

gblargg wrote: post #58
ranger_danger wrote: post #11

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.

It kind of reminds me of the equality of opportunity people versus the equality of outcome people. One sets the starting conditions for developers, the other the ending conditions for users.

Since developers are a subset of users, it's actually possible to calculate which is more open.

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

#69

Post by hamdingers »

kstrauser wrote: post #59
hamdingers wrote: post #56

Earlier quoted context omitted.

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

No. The name only means it’s made by the OpenBSD team, nothing more. If they made their own Python port, it’d be called OpenPython, even though the original is FOSS.

So is OpenSUSE made by the BSD team? OpenOffice? OpenShift? OpenCV? OpenAI?

It is not reasonable to claim this prefix unambiguously refers to the OpenBSD team. I do not understand why so many in this thread are pretending this isn't a confusing choice.

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

#70

Post by chasil »

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 equivalent/identical behavior, study these words carefully: "accepts only a subset of rsync's command-line arguments."

Post reply on HN