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

111–120 of 193 posts

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

#111

Post by wtetzner »

Panino wrote: post #73

I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively. The one place in my usage where it doesn't match Samba rsync is with the following: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/se…

> The one place in my usage where it doesn't match Samba rsync is with the following:

> openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services

This appears to match "normal" `rsync` behavior as well. I think you need a trailing slash after `services` to sync only the contents.

EDIT: actually my "normal" rsync is openrsync on macOS...

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

#112

Post by eichin »

genxy wrote: post #82
Panino wrote: post #73

I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively. The one place in my usage where it doesn't match Samba rsync is with the following: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/se…

Was there already a /tmp/services directory on the dest? One of the biggest points of confusion with rsync is how directories and trailing slashes are handled.

It's a big source of confusion with cp. One of the UI reasons to use rsync (for mundane non-remote copying) is that it doesn't do different things based on what's present on the target.

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

#113

Post by [deleted] »

teddyh wrote: post #65
applfanboysbgon wrote: post #55

Earlier quoted context omitted.

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.

[deleted]

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

#114

Post by skeledrew »

einpoklum wrote: post #109
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.

How about the attempt to avoid things that use AI promiscuously and start exhibiting bugs? :-(

Push for better guardrails and QA structures. Avoidance helps nobody in the long run, and isn't possible anyway without going completely cold turkey. Like literally in a few months every project worth using will directly or indirectly involve AI.

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

#115

Post by eichin »

SubiculumCode wrote: post #98

I'm going to ask a question. I could ask chatgpt. I could Google it. I am asking a question because it is human to do so. Ubuntu's packaged rsync, is it Samba rsync? Why reimplement it?

it's tridge rsync; samba is another project by the same guy. (rsync was originally a PhD thesis...)

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

#116

Post by isityettime »

ranger_danger wrote: post #11
jtickle wrote: 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.

GNU folks would probably not say that.

GNU folks would say that the GPL does more to protect the freedom of end users by guaranteeing their right to access the source code, whereas permissive licenses allow users to receive binaries, the source code corresponding to which is unavailable to them.

I'm not trying to be idly pedantic here, but to emphasize one of things I genuinely admire about the FSF, SFC, etc.: while they do have words, concepts, and terms of art they're attached to, they're actually pretty good at always explicitly tying their positions back to a specific and well-articulated vision of software freedom. They don't usually get caught up in pure terminology ("what is maximally open?", "what is really free?"). They tend to be clear about whose rights they aim to promote and protect and why, and the bigger picture that fits into.

Whether you agree with them or not, I think it's a more defensible position than a shallow terminological squabble.

As someone that is somewhat aligned with those groups, I also want to say this: licenses are just tools for promoting freedom. It's a question of strategy and tactics. All permissively licensed free software is still free software, and the vast majority of it undeniably contributes positively to software freedom on the whole. (The only concrete exceptions I can think of are uses of permissively licensed free software code to implement things like Intel's Management Engine, DRM, maybe some Trusted Computing stuff.) OpenBSD is free software and it's good shit. We should think of licensing questions like this as a friendly dispute among people who have all given generously to support software freedom.

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

#117

Post by isityettime »

papercrane wrote: post #54
e12e wrote: post #29

Earlier quoted context omitted.

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 t…

> I'd love to see pledge/unveil on (upstream) Linux - but I'm not holding my breath There is Landlock now, I believe it would be possible to implement unveil and pledge on top of that.

One of HN's favorite hackers has done that: https://justine.lol/pledge/

There was a discussion here about it a few years ago: https://news.ycombinator.com/item?id=32096801

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

#118

Post by somat »

throwaway27448 wrote: post #101

I'm confused. Isn't rsync already free software? What are we doing here. Why are we trying to cuck ourselves for capital. I like open bsd but this just seems like burning cash

My understanding is that much of the point of openrsync is to create a second implementation of a protocol so the standards bodies don't balk at including it in their standards.

Or to put it more concretely, people working on the rpki standard(who happened to also be openbsd devs) wanted to use rsync to transfer bulk data. The standards body was hesitant, while rsync is ostensibly a documented protocol, there was only one implementation. So in true openbsd fashion they rolled up their sleeves and wrote that second implementation.

On use, there is nothing wrong with openrsync, however it may never hit feature parity with rsync, that is not a goal of the project, they want a specific subset of rsync features to support their rpki needs. If anyone else finds this useful that is great. So I suspect users will be those who want a bsd licensed rsync(apple) or them who are willing to give up features for openbsd quality code(myself).

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

#119

Post by groundzeros2015 »

skeledrew wrote: post #114
einpoklum wrote: post #109

Earlier quoted context omitted.

How about the attempt to avoid things that use AI promiscuously and start exhibiting bugs? :-(

Push for better guardrails and QA structures. Avoidance helps nobody in the long run, and isn't possible anyway without going completely cold turkey. Like literally in a few months every project worth using will directly or indirectly involve AI.

> Avoidance helps nobody in the long run

What the hell? That’s the job.

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

#120

Post by cperciva »

eikenberry wrote: post #110
cperciva wrote: post #39

Earlier quoted context omitted.

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 disagree. While rsync is most often used to transfer data between "friendly" systems, it's inherently crossing a security boundary. It's import…

It is almost universally hooked up using ssh tunneling so ssh takes care of the security boundary and ssh is well trusted.

That solves the traffic tampering problem, but not the "malicious peer" problem. You want to be able to sync files without accidentally sharing root privileges.
Post reply on HN