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.
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"?
> This system has been merged into OpenBSD base. If you'd like to contribute to openrsync, please mail your patches to tech@openbsd.org. This repository is simply the OpenBSD version plus some glue for portability.
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.
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?
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).
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."
> The only way to stop this is for the original author(s) to release this under a BSD license.
That is likely not possible even if they wanted to - unless all contributors have signed over rights to their contributions.
Even then if the new project is specifically wanting to simplify things, and/or a change in language is important, reimplementation might still be preferable for them.
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:
Ubuntu's rsync is samba rsync. It's not part of the samba project per se, but it is made by the same guy and the official url is https://rsync.samba.org/ so it's entirely fair to call it samba rsync in my opinion.
Might be offtopic, but i think when looking for alternatives the options should be broad, questioning the category of the app, not just clones and forks.
If you are considering migrating away from github, don't just consider gitlab and gitea, consider just git, and so on..
If you are considering migrating away from rsync, consider dd. You need to configure the folders you want to backup as mountable partitions or disks, but it does byte for byte copies instead of 100kloc fuckery.
Since I switched my VPS to OpenBSD (base only), I've been "forced" to handle openrsync and it has been mostly a drop-in. Except a problem where I couldn't mix `--exclude glob` and `--delete` on the client, no problem to report.
> If the source or destination is on a remote server, the client then fork(2)s and starts the server openrsync on the remote host over ssh(1). The client and the server subsequently communicate over socketpair(2) pipes.
How is that supposed to work? I guess they mean something like, the forked child forwards the connection to the parent using a socket pair, or just connects its stdout/stdin to the socketpair "pipe" (socket) and execs ssh.
But that's like saying you're going to Australia by car when you mean you're driving to the airport.
All software anneals into a final form that is incontrovertibly correct. Each of these OpenBSD rewrites feels like the realization of such a final form!
Code is like a math proof:
sketched first on a napkin, then on a blackboard, and then finally typeset in a paper. Each step tidies up the ideas to improve the communication of intent, and the final version should be self evidently stable and/or correct.
In the old days you’d see code stability emerge as the “v2” edition of some piece of software. Mozilla to Phoenix to Firebird/fox. Linux 2.2 to 2.4. Python 2.6 to 3.x. The design patterns are carried over but the implementations are revamped for more stable, more legible, and more
maintainable code.
I don’t mind that vibe coding is the latest form of this phenomenon. We have all been “vibe coding” for decades really. Code like this crap:
T = “hello world”
def foo_2():
FONT = “Perpetua.ttf”
w = text(T, Font)
w2 = w.translate((50,0,0))
w3 = w.translate((0,0,20))
show(w3)
Before, we’d hack a v0, tidy it up sufficiently for it to be worth of review as v1, then, come back much later and rearrange the innards (in a far more sensible way) as v2.
With LLMs — especially in the hands of those who can’t read or won’t read the actual code — we are seeing a lot more version zeroes in the world. Thank you OpenBSD for giving us, albeit surprisingly for rsync, a nice v2.
30 comments
[ 3.3 ms ] story [ 43.5 ms ] thread(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...
- people avoiding systemd like it's the plague
- people avoiding wayland because it is devil's work
- people avoiding rsync because someone used AI on the testcases
- ...
> This system has been merged into OpenBSD base. If you'd like to contribute to openrsync, please mail your patches to tech@openbsd.org. This repository is simply the OpenBSD version plus some glue for portability.
Seems more cathedral than Bazaar to me.
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?
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).
https://github.com/gokrazy/rsync/graphs/contributors
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."
That is likely not possible even if they wanted to - unless all contributors have signed over rights to their contributions.
Even then if the new project is specifically wanting to simplify things, and/or a change in language is important, reimplementation might still be preferable for them.
No, then you get proprietary forks of the BSD codebase.
Apple doesn't like GPLv3, but this is by choice.
Sometimes, inventions by OpenBSD team (often using Open as prefix) become standard, such as OpenSSH and PF.
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/services/services.
Normal directory mirroring as in -av -e ssh /path/to/src/ example.com:/path/to/dst/ works as it does with Samba rsync.
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...
Ubuntu's packaged rsync, is it Samba rsync? Why reimplement it?
I like open bsd but this just seems like burning cash
As an aside I really love the stuff openBSD puts out. If they ever succeed in making a modern journalling filesystem I will probably switch over.
If you are considering migrating away from github, don't just consider gitlab and gitea, consider just git, and so on..
If you are considering migrating away from rsync, consider dd. You need to configure the folders you want to backup as mountable partitions or disks, but it does byte for byte copies instead of 100kloc fuckery.
Thanks for the various vibecoding posts, I wasn't aware of the extent of it. Some prior HN discussion: https://news.ycombinator.com/item?id=48334021
How is that supposed to work? I guess they mean something like, the forked child forwards the connection to the parent using a socket pair, or just connects its stdout/stdin to the socketpair "pipe" (socket) and execs ssh.
But that's like saying you're going to Australia by car when you mean you're driving to the airport.
Code is like a math proof: sketched first on a napkin, then on a blackboard, and then finally typeset in a paper. Each step tidies up the ideas to improve the communication of intent, and the final version should be self evidently stable and/or correct.
In the old days you’d see code stability emerge as the “v2” edition of some piece of software. Mozilla to Phoenix to Firebird/fox. Linux 2.2 to 2.4. Python 2.6 to 3.x. The design patterns are carried over but the implementations are revamped for more stable, more legible, and more maintainable code.
I don’t mind that vibe coding is the latest form of this phenomenon. We have all been “vibe coding” for decades really. Code like this crap:
…gets eventually rewritten, once it works, into: Before, we’d hack a v0, tidy it up sufficiently for it to be worth of review as v1, then, come back much later and rearrange the innards (in a far more sensible way) as v2.With LLMs — especially in the hands of those who can’t read or won’t read the actual code — we are seeing a lot more version zeroes in the world. Thank you OpenBSD for giving us, albeit surprisingly for rsync, a nice v2.