Rendered at 20:42:34 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Panino 1 days ago [-]
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:
The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services. The outcome is exactly the same as if I had run "scp /etc/services example.com:/tmp/services"
The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services/services. The outcome is NOT the same as if I had run "scp /etc/services example.com:/tmp/services"
Please note that "/tmp/services" and "/tmp/services/services" are different.
The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services. The outcome is exactly the same as if I had run "scp /etc/services example.com:/tmp/services"
If you disagree, please state what operating systems you're using and copy/paste the output of the following commands on each side:
uname -a
rsync -V
openrsync -V
I get
$ rsync -V
rsync version 3.4.3 protocol version 32
(snipped)
$ openrsync -V
openrsync 0.1 (protocol version 27)
Then please run the commands I ran above, in particular
And then type "file /tmp/services" on the remote server.
genxy 1 days ago [-]
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.
anyfoo 1 days ago [-]
I hear that a lot, but I familiarized myself with it once and ever since it makes a lot of sense to me.
Source ending in “/“: You want what’s inside. Source not ending in “/“: You want the thing (i.e. directory itself). For the destination, it does not matter whether it ends in “/“ or not, but for consistency I like adding a “/“ anyway (I want to put thing inside the directory).
linsomniac 23 hours ago [-]
Yes, the nice thing about dest having a trailing "/" is that if it exists and is NOT a directory, you are alerted right away.
eichin 1 days ago [-]
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.
Panino 1 days ago [-]
> Was there already a /tmp/services directory on the dest?
No. And just to make sure, I ran a quick 'rm -rf /tmp/services' on the remote host, then re-ran openrsync on the client. Same result. This is OpenBSD 7.9 on both sides.
And I 100% agree about trailing slashes.
hilsdev 1 days ago [-]
If you use a trailing slash on the source it copies from the directory, if you omit the trailing slash it copies the directory itself. AFAIK this is pretty standard across POSIX tools
SoftTalker 24 hours ago [-]
It's not, for example cp -R doesn't change behavior on the basis of a trailing slash on directory names.
m463 6 hours ago [-]
I was implementing something recently and stumbled across that cp difference. ugh.
the trailing slash is pretty convenient.
fsckboy 2 hours ago [-]
that's not a cp difference, cp is the granddaddy here
I think trailing / could be a nice way to indicate some meaningful difference, but since autocomplete always sticks it in, just feels like a bad idea to me. I might like it if directory names always had to have a trailing /, but I am less motivated by "convenience of common cases" and much more by "absolute precision/specificity/unambiguity" belt and suspenders.
(kind of unrelated but along the same lines, I toy with the idea of getting rid of . and .. visible in the filesystem, and make them only part of the syntax of paths. then you could have unambiguous multiple links to a directory: ".. is where you came from" and .. in the root is still the root, so chroot works too)
m463 2 hours ago [-]
I think . and .. are useful. there's also perforce's ... which I find interesting (for example foo/... means everything below directory "foo")
hnarn 1 days ago [-]
> I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.
As someone who has also suffered uncountable years of abuse from rsync, I understand the impulse, but I think it makes a lot more sense (and is a safer default) to create a second ”services”.
If we have a chance to change rsync defaults to something less insane and save future generations from this mess I think we should.
kbenson 1 days ago [-]
We don't, since we're not implementing a UI from scratch, we're matching something else.
Of the two possible worlds where in one this reimplementation matches what some see as annoyances in the interface or in another they mostly match the interface except for a few cases where the purposefully diverge (for no good technical reason), IMO the latter is far worse and causes more enexpected behavior.
At most, add a special flag to opt into different default behavior so nobody is surprised by running the same command on different systems and getting different behavior.
kbenson 17 hours ago [-]
To be absolutely clear, since on reading this later it may come across as me masquerading as part of the OpenBSD project, I am not affiliated with them. My "We don't" was in response to "If we have a chance to change rsync defaults" which we, as the general public and users (and very likely also any reimplementors) don't have that chance, because rsync has a solid UI that people and tools have integrated for over a decade, and that's not something you can just change.
em-bee 17 hours ago [-]
you responded to a comment that states "we should", your comment is a clear response to that. at least i understood it as intended.
trollbridge 21 hours ago [-]
Given the sudden spike in vibe-coded commits to the rsync codebase, and regressions that’s introduced, this is very good news.
port11 14 hours ago [-]
I was prepared to dismiss your comment because rsync has always been rock solid, but indeed upgrading broke my backup script. The latest issue on GitHub documents plenty of bugs introduced in the last 2 patches, including a monstrous ~9k LOC commit that was probably pointless.
LLMs make writing code faster/easier, but the thinking was always the important bit. I’ve no idea why you’d muck up such a long-standing, reliable piece of software.
prmoustache 11 hours ago [-]
When LLM allows you to produce code n% faster, it also allows you to introduce bugs n% faster.
I find it quite strange that people do not seem to be aware of that...I think many started worshipping the tool as if it was some kind of divinity and lost all objctivity. This doesn't bode well for the future if people aren't able to review code anymore.
brianwawok 5 hours ago [-]
Don’t need people to review code, need more LLMs. People aren’t that magical.
port11 31 minutes ago [-]
Maybe one day. Right now I can have Opus carefully draft a plan, Sonnet execute it, and have Opus review the code. It will complain about things that it had dismissed in the plan.
Example: it recently flagged ID derivation from a signing key. Opus itself suggested it! When reminded of that, it did this new 4.8-style “my bad, and here’s why I was right in the first place.”
Humans are still badass.
asdsg 6 hours ago [-]
Yes, I also don't know how license critical distributions like Debian can even ship rsync now because it contains a) laundered code and b) Tridgell cannot claim copyright over the Claude additions.
So rsync should be pinned to an older version and just get security updates.
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?
saidnooneever 1 days ago [-]
Linux has no such features as pledge or unveil, nor capsicum. it has cgroups, namespaces and a mess ofnother things u need to combine to try and do similar things. (it was built iteratively as many systems interacting and being combined to form 'sandboxing' or isolation/limiting of capabilities rather than specific isolation as an entire concept with specific system calls and kernel paths to enable it).
there might be newer stuff in linux land now i see comments about landlock but i assume those will build on the linux primitives rather than whole new ones. - total assumption there but it would seem logical to reuse rather than make new.
part of likely what they mean by 'mess' is that its all over the place. many different ways to try and lock things down. hard to pick what is best etc. without thoroughly diving into the different subsystems entirely. (as opposed to just have 1 or 2 relatively simple system calls)
Sure seccomp has its flaws but it's not unworkable. You could just simply gate execution from running on any newer version of Linux of which you don't have a complete syscall list. Or variations on that theme if you need more flexibility.
thomashabets2 10 hours ago [-]
Well, you'll still need to build unveil/pledge on top of it, because it's not just "the version of Linux". It's all libraries used, directly and indirectly (incl config-based list of libraries, like in PAM), and what they suddenly decide to change even in a security-only patch.
The list of syscalls any code anywhere in the system calls is not a published contract with any guarantees.
> You could just
… is doing some heavy lifting here. "You could just" all but guarantee that your program will break in a couple of years for all users who do the responsible thing?
Sure, if you're building an appliance with a support contract, where you control everything, then that's doable. Servers/desktops/laptops, not so much.
e12e 1 days ago [-]
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.
papercrane 1 days ago [-]
> 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.
e12e 24 hours ago [-]
Apparently someone tried wrapping landlock in unveil:
She's excellent and her stuff has made it to the front page many times. I love seeing her work come up and I imagine many others here feel the same way.
maleldil 1 hours ago [-]
If you're someone who can separate the work from the author, sure. She's a very intelligent person. Many of us can't.
Bender 1 days ago [-]
Ok that makes more sense, thankyou.
justinsaccount 1 days ago [-]
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.
Bender 1 days ago [-]
that quote seems to be a bit of an oversimplification to the point of being completely wrong.
Under Portability [1] I don't have access to update that repo. I deleted my accounts when Microsoft took over.
> 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.
thefilmore 1 days ago [-]
This is the version used in macOS since 15.0.
mrdomino- 1 days ago [-]
Was it 15.0? I seem to recall it coming in one of the minor point releases in the 15.x line - and I remember it breaking some scripts mysteriously.
EDIT: ah, fun: they did include it in 15.0, but they decided to save the breaking change that removed backwards compatibility for 15.4. https://apple.stackexchange.com/a/479297
onedognight 1 days ago [-]
They don’t support any recent rsync protocol, so there’s no 64bit timestamp support, so you can never actually sync metadata across newer filesystems.
gorgoiler 9 hours ago [-]
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.
neves 5 hours ago [-]
Why do they need to reimplement a robust piece of difference as rsync?
WD-42 1 days ago [-]
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"?
alphabeta3r56 49 minutes ago [-]
Also
> 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.
jtickle 1 days ago [-]
OpenBSD folks would consider the GPL to be less open due to the requirement to apply the GPL to any derivative works.
ranger_danger 1 days ago [-]
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.
lelanthran 10 hours ago [-]
> Two different ways of thinking about it I guess
I don't think so; it's two different goals, not two different ways of thinking about it.
The goal of GPL is the interests of users (they can never be locked out of improvements no matter who makes changes).
The goal of BSD is the interests of the developers (A developer can take it, add mods and close of the entire result).
In practice, GPL is pro-user, BSD/MIT is pro-business.
xorcist 9 hours ago [-]
> In practice, GPL is pro-user, BSD/MIT is pro-business.
Yet every time a GPL licensed product competes against a BSD licensed product in an open market, even when inferior the GPL product wins in the long run.
That's because the GPL ecosystem leapfrogs the BSD one every time one of those pro-business businesses sells proprietary add-ons while the former stands on one another's shoulders.
It's almost like free markets composed of multi vendor ecosystems are business friendly?
(Sarcasm aside, the weasel word here is "business". Customers and vendors are both businesses. Monopolies are very business-friendly for the vendor, just not for anyone else.)
It's a rule that's mostly only true for self-contained products though, it hasn't been true for things like codecs and SSL stacks, and components used by proprietary and free products alike.
gblargg 1 days ago [-]
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.
brnt 1 days ago [-]
Since developers are a subset of users, it's actually possible to calculate which is more open.
tardedmeme 6 hours ago [-]
You forgot the shareholders, who are not users but have less freedom under the GPL.
isityettime 1 days ago [-]
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.
thayne 1 days ago [-]
I don't think the FSF would say that. They prefer the GPL, because it prevents someone from making a closed derivative, but I haven't seen them ever claim it is more open than "permissive" licenses.
gilrain 1 days ago [-]
> 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.
datakan 1 days ago [-]
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.
skeledrew 1 days ago [-]
I see this, and the spiritual example that immediately comes to mind is that which is labeled as "crime". Would it be more moral that a murderer must first consent to being judged and sentenced, or that there is a system which automatically comes into play to hopefully deter but also punish it when it happens?
jcelerier 1 days ago [-]
Allowing closed-source to exist is always the less moral choice for many reasons (one example being ecological sustainability)
kennywinker 1 days ago [-]
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.
KZerda 1 days ago [-]
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.
badreligion42 1 days ago [-]
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.
KZerda 1 days ago [-]
The BSD license made forking Valkey easier because it ensures that everyone has equal footing. The GPL, especially with contributor license agreements and the like, makes it much more easy for a single party to control the direction of the product. For another example of this happening, look at MongoDB. It started out under the AGPL, but was rugpulled to a non-free license.
akerl_ 1 days ago [-]
It feels like your actual beef here is with CLAs, which often are designed to allow the current maintainers to relicense.
CLAs are not an attribute of the GPL. They're an agreement that can be applied to contributions to any codebase with any license.
em-bee 1 days ago [-]
The BSD license made forking Valkey easier because it ensures that everyone has equal footing
equal footing on the license is what allowed AWS to crush the original creators of the products they host.
it's a trade off.
the AGPL does not prevent a hosting service. it only prevents creating non-free addons. i see no problem with that. see also my other comment
WD-42 1 days ago [-]
Mongo was already a centralized project. Technically open source agpl but I don’t remember it having a large developer community or really many contributions from outside mongo. When the rug pull happened I think simply most people didn’t care or moved on to equal (or better) alternatives. It’s not beloved software like Redis is.
kennywinker 1 days ago [-]
On top of badreligion42’s point, that both licenses allow forking just as easily - don’t you have the rugpull part backwards?
Afaik BSD licensed stuff can be re-licensed under any more closed licenses at any time, where as to re-license GPL, you need consent from every single contributor.
But i’m not familiar with the redis-valkey story so, maybe there is some nuance i am missing?
KZerda 1 days ago [-]
Redis started off as Free Software, but was switched to a source available license in version 7.4. The community promptly forked to Valkey, which is still under the BSD license. Since then, Redis shifted to AGPL 3, with contributor agreements, to try to ensure that they're the only ones who can attempt to commercialize Redis.
em-bee 1 days ago [-]
AGPL makes commercializing harder only for people who fear the AGPL because they want to keep stuff for themselves. there is no problem commercializing it if you don't mind sharing all your connected code. the only benefit redis has is that they can integrate non-free code in their hosting service, while the rest of us could not. since it is their work, i think it is reasonable that they have an advantage. it does not reduce my freedom as a user. it only hinders AWS and other big players from crushing redis.
tardedmeme 6 hours ago [-]
How would you rugpull a GPL Redis?
ranger_danger 1 days ago [-]
The paradox clears itself up if you look at what tolerance actually is. It's simply not interfering with people's agency over themselves. Given that your right to self-agency doesn't entitle you to restrict others' self-agency, behavior that does try restricting others' agency is automatically not included in "tolerance."
kennywinker 20 hours ago [-]
Sure, yeah - like most “paradoxes”, it’s not actually a paradox unless you only look at it from one specific viewpoint.
bigstrat2003 22 hours ago [-]
> BSD license is unrestricted, it tolerates taking open source and closing it, thus always being at risk of things closing down.
There is no such risk. If someone wishes to make a closed source derivative of the BSD-licensed original, it does not deprive anyone of the original. That remains there, just as open as before.
kennywinker 20 hours ago [-]
It deprive us of their improvements, while they get to build off other people’s work.
With the GPL, if you want to modify, and built on others work, you have to share.
Share and share alike, vs take if you like share if you like.
pjmlp 7 hours ago [-]
It deprives for example the LLVM community to profit from PlayStation compiler optimizations.
ranger_danger 1 days ago [-]
Many projects closely associated with OpenBSD start with "open"... openssh, openbgpd, openntpd, opensmtpd etc.
SoftTalker 1 days ago [-]
Notable exception, OpenSSL already had the Open prefix so the OpenBSD project is called LibreSSL.
DonHopkins 7 hours ago [-]
It's tempting to develop a useful but closed source project called "is" and dare them to make an open version of it.
hamdingers 1 days ago [-]
Not many are reimplementations of existing, much more popular, already open source projects.
throw0101a 1 days ago [-]
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]
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).
hamdingers 1 days ago [-]
Is rsync going closed source? If not, how is that the same thing?
kstrauser 1 days ago [-]
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.
hamdingers 1 days ago [-]
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.
bentley 1 days ago [-]
Nobody ever claimed that “Open” is a prefix used unambiguously by only one group of people ever.
In fact, your insistence that “Open” can only be used by projects that are replacing proprietary software is itself very odd.
OpenBSD itself has had its name for thirty years, and is not named for being an “open source” implementation of a proprietary OS.
hamdingers 1 days ago [-]
The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.
Do not invent arguments that I did not make. I have only said that naming it openrsync when rsync already exists and is "open" in the general sense is confusing.
I find the negative reactions to this observation very confusing, especially yours, but I see that you're an OpenBSD developer so that explains your bias.
Edit: and now these same people are backtracking to agree with me that "open" is ambiguous, this place never ceases to amaze
throw0101a 1 days ago [-]
> The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.
What was said is that the OpenBSD operating system folks chose to use the Open— prefix for all their other projects ("They simply ran with the naming convention."). What was not said was that all Open— prefixed projects were from them.
kstrauser 1 days ago [-]
You’re inventing an argument I didn’t make. OpenBSD doesn’t own “open”. Literally no one is saying that. What I did say is that openrsync is named that because the OpenBSD team names their projects that way. The “open” in this project means that it came from OpenBSD, not that that it’s in contrast to rsync being proprietary (which it isn’t).
bentley 1 days ago [-]
OpenBSD didn’t get its name from NetBSD going closed source.
StayTrue 1 days ago [-]
Historically speaking, it may have meant open to poorly socialized developers.
throw0101a 1 days ago [-]
> Is rsync going closed source? If not, how is that the same thing?
Not closed source, but with rsync 3.0 it changed its license to GPL3, which a lot of folks don't like: BSD/MIT licenses have zero limitations on use and distribution, GPL2 (rsync 1.x, 2.x) forces one to release code, GPL3 (rsync ≥3.x) adds further restrictions.
Some folks want to distribute code with as few restrictions as possible. Other folks have a great good/goal in mind (e.g., 'all software is open source') and so add 'local restrictions' to hopefully achieve greater non-restrictions.
gpvos 1 days ago [-]
Which aren't? It seems all (or most) are.
skeledrew 1 days ago [-]
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.
reaghs 1 days ago [-]
Thanks for the heads-up! I wasn't aware that Tridge is using Claude. I shall use Openrsync from now on.
ranger_danger 1 days ago [-]
I feel bad for people with the real name Claude.
xp84 1 days ago [-]
Yeah, and we thought the most unlucky people were the ones named Alexa.
SoftTalker 1 days ago [-]
Or those named Karen...
janussunaj 1 days ago [-]
Rajesh here
hideout_berlin 1 days ago [-]
ferdinand here
grishka 1 days ago [-]
Or Alisa
queuebert 1 days ago [-]
I don't know, Claude Shannon did okay.
michaelcampbell 9 hours ago [-]
Presumably a bunch of Adolf's did too, prior to, you know, the 1930's.
cozzyd 1 days ago [-]
I think it would be funny to have a grad student named Claude for the hilarious ambiguity it would create.
hideout_berlin 1 days ago [-]
i want to name my new born claude
formerly_proven 1 days ago [-]
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.
kstrauser 1 days ago [-]
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?
homebrewer 1 days ago [-]
It seems to be a widely repeated "fact" which can't be traced to anything particularly authoritative:
Salesforce spent some amount of money to license the name Einstein from his estate/heirs.
1over137 1 days ago [-]
Yeah, especially since most Americans don't know how to properly pronounce Claude.
txru 1 days ago [-]
Hmm, Claude Shannon was an American (the model is ostensibly named after him), so maybe how he pronounced it would be the correct pronunciation.
That said, every language on earth will adapt foreign words into its phonology. The alternative would be to adopt the phonology of every language that loaned a word into your language.
einpoklum 1 days ago [-]
How about the attempt to avoid things that use AI promiscuously and start exhibiting bugs? :-(
skeledrew 1 days ago [-]
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.
13 hours ago [-]
groundzeros2015 1 days ago [-]
> Avoidance helps nobody in the long run
What the hell? That’s the job.
1 days ago [-]
dark-star 22 hours ago [-]
This is a recent trend in open-source though:
- 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
- ...
echelon 1 days ago [-]
Wasting their precious limited time on this planet for performative hand wringing.
AI is only going to get better and better. Eventually manually writing software by hand with programming languages will be thought of as the punch-card phase of software development.
Do these people think we'll be writing software in 200 years time? That anybody will be maintaining rsync, let alone this "moral human hands only" version of it?
The anti-AI lot are trying to make all AI content wear a Scarlett letter. I wish they would wear one themselves so that we could filter them from our timeline.
This "effort" is entirely wasted.
grebc 23 hours ago [-]
Your booster efforts are wasted.
bigstrat2003 22 hours ago [-]
It is not "performative hand wringing" to observe that a tool sucks and to reject its use. You cannot, at present, write quality software with AI tools. At best you get something you could've made yourself, slower than you could've made it yourself. Only a fool insists on using a tool when it has been proven to not work.
skeledrew 20 hours ago [-]
Unsure what you mean by "quality", but I've personally created projects using AI which work to my satisfaction, and which I didn't make "myself" as I considered it to be too much manual work for not enough benefit. Now using it for even greater things. The tool works fine once you've learned how to use it.
gverrilla 9 hours ago [-]
> proven to not work.
what twitter account proved that?
23hartr 1 days ago [-]
[flagged]
LAC-Tech 20 hours ago [-]
A few comments here suggest rsync is undergoing some "churn" which tbh is highly undesirable for a command line utility. Might switch over.
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.
tptacek 1 days ago [-]
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).
cperciva 1 days ago [-]
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 important to make sure that an attacker can't leverage it to transform the breach of one system into the breach of multiple systems.
eikenberry 1 days ago [-]
It is almost universally hooked up using ssh tunneling so ssh takes care of the security boundary and ssh is well trusted.
cperciva 1 days ago [-]
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.
delusional 1 days ago [-]
> almost nobody runs it outside of strict trust boundaries.
I guess you can define "strict" however you want, but from what I saw ~10 years ago, most linux distros handled mirroring with rsync. That's a lot of usage in a pretty core part of the foundational open source ecosystem.
tptacek 1 days ago [-]
OK, I agree, that's bad.
akerl_ 1 days ago [-]
Many distros use rsync for that but also support unencrypted HTTP.
They’re layering on checksums and signing such that they mostly don’t think about the trustworthiness of mirrors or the networks between them.
BoingBoomTschak 14 hours ago [-]
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.
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.
agwa 1 days ago [-]
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.
jmclnx 1 days ago [-]
>Claude assisted code found in external/ibm-public/postfix/dist...
That is from the original post in the thread. Is that really due to LLM ? I do not know since I avoid AI as much as I can.
Right, I read all that and I didn't see anything to indicate that AI is being used to write code - just one person's unsubstantiated claim.
jmclnx 1 days ago [-]
I did not look at details until I saw your post, but I tend to agree with you on this point.
But that is the odd thing, how to tell for sure if a LLM was used :)
Bender 1 days ago [-]
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.
jmclnx 1 days ago [-]
I just tried openrsync(1) on OpenBSD 7.9, --exclude now works.
I have not tried using exclude in openrsync in a while, but I can see it now works on OpenBSD 7.9!
1 days ago [-]
SubiculumCode 1 days ago [-]
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?
tredre3 23 hours ago [-]
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.
eichin 1 days ago [-]
it's tridge rsync; samba is another project by the same guy. (rsync was originally a PhD thesis...)
bombcar 18 hours ago [-]
tridge is mighty in the Linux world, he arguably greatly contributed to Linux as a server (via Samba to save on windows NT client user licenses), rsync, and IIRC reverse-engineering the bitlocker protocol thereby starting the gitstorm.
hideout_berlin 1 days ago [-]
samba is different topic
TZubiri 18 hours ago [-]
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.
+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.
48terry 1 days ago [-]
Yeah, nothing to suggest that here. We went from some commits every so often (because rsync was basically finished software) with a handful of issues a month, to "a bajillion Claude commits then a release" with a pile of issues within weeks, at least one of which is about how the goddamn thing doesn't build.
I can't possibly see a correlation.
Weird how 3.4.2. didn't have a similar deluge of issue reports, though.
triggis 1 days ago [-]
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.
skeledrew 1 days ago [-]
> 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.
stsquad 1 days ago [-]
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.
margalabargala 1 days ago [-]
That's literally what this thread is about.
akerl_ 1 days ago [-]
Openrsync is a project that’s existed for a long time and is a great example of people building what they want.
This thread has people suggesting it’s good or important to go tell open source devs they’re using bad tools.
The former is great. The latter is not.
akerl_ 1 days ago [-]
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.
applfanboysbgon 1 days ago [-]
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 allowance, and that is an allowance any maintainer can instead choose to not bother themselves with if publishing their code for free leads themselves to dealing with entitled internet commenters harassing them with complaints.
teddyh 1 days ago [-]
> Friendly reminder that volunteer maintainers owe you literally not a single goddamn thing.
Technically true. However, I also do not owe them my silence.
1 days ago [-]
throwaway27448 1 days ago [-]
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
somat 1 days ago [-]
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).
throwaway27448 17 hours ago [-]
Why would we explicitly develop code legally available to capital?
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."
yjftsjthsd-h 1 days ago [-]
> The only way to stop this is for the original author(s) to release this under a BSD license.
Would that stop it? My understanding was that at least OpenBSD tended do redo things for technical reasons, not just licensing
chasil 21 hours ago [-]
Jeremy Alliston (assuming that my memory serves me) is the foremost to decide if this should be done.
spauldo 1 days ago [-]
It's really no different than every other BSD utility (and SysV utility, if you're running one of those) being different than the GNU ones. We've coped with it for fifty years at this point.
eikenberry 1 days ago [-]
The only option should not to be to take away user freedoms. BSD licenses are popular with proprietary software writers because they can use it without any of the restrictions that seek to preserve the rights of the end user. Instead you get proprietary software stacks like Apple and Android that seek to lock the users out of anything not granted by the company.
The correct way to stop this is to file bugs against the software for not matching the de-facto standard of the copied software.
qalmakka 1 days ago [-]
Basically like GNU Tar/CPIO and BSD Tar/CPIO. I've largely standardised towards using the bsd variant everywhere (especially since now even Windows ships it and it handles lots of other archive formats using the `tar` command) but it's always a pain to install it everywhere
yjftsjthsd-h 1 days ago [-]
Yeah, I'm leaning towards strongly preferring bsdtar since it's happy to work on e.g. zip files:) Does it have any real downsides?
SoftTalker 24 hours ago [-]
Limits on the length of path and file names in the archive.
Edit: I see that they switched from ustar to pax as the default format in OpenBSD 7.6, so I guess this isn't true any longer.
dspillett 21 hours ago [-]
> 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.
chasil 21 hours ago [-]
Exactly.
Fnoord 17 hours ago [-]
> The only way to stop this is for the original author(s) to release this under a BSD license
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.
asveikau 1 days ago [-]
> Apple and Android will prefer it,
My thought upon reading this is why would Apple or Android bother including rsync? I've noticed that I've needed to install it manually on fresh installs of Debian, FreeBSD...
But then, I just checked a recent Mac that I don't use much and haven't put much on, and it's installed.
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.
> 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...
I think some people may not be reading closely. On Unix, "/etc/services" is a file, not a directory:
Here are two OpenBSD 7.9 endpoints running Samba rsync:rsync -av -e ssh /etc/services example.com:/tmp/services
The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services. The outcome is exactly the same as if I had run "scp /etc/services example.com:/tmp/services"
openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/servicesThe above command creates a mirror of the local file /etc/services in a remote file called /tmp/services/services. The outcome is NOT the same as if I had run "scp /etc/services example.com:/tmp/services"
Please note that "/tmp/services" and "/tmp/services/services" are different.
Here's an OpenBSD 7.9 client and Ubuntu server both running Samba rsync:rsync -av -e ssh /etc/services example.com:/tmp/services
The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services. The outcome is exactly the same as if I had run "scp /etc/services example.com:/tmp/services"
If you disagree, please state what operating systems you're using and copy/paste the output of the following commands on each side:
I get Then please run the commands I ran above, in particularopenrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
And then type "file /tmp/services" on the remote server.
One of the biggest points of confusion with rsync is how directories and trailing slashes are handled.
Source ending in “/“: You want what’s inside. Source not ending in “/“: You want the thing (i.e. directory itself). For the destination, it does not matter whether it ends in “/“ or not, but for consistency I like adding a “/“ anyway (I want to put thing inside the directory).
No. And just to make sure, I ran a quick 'rm -rf /tmp/services' on the remote host, then re-ran openrsync on the client. Same result. This is OpenBSD 7.9 on both sides.
And I 100% agree about trailing slashes.
the trailing slash is pretty convenient.
I think trailing / could be a nice way to indicate some meaningful difference, but since autocomplete always sticks it in, just feels like a bad idea to me. I might like it if directory names always had to have a trailing /, but I am less motivated by "convenience of common cases" and much more by "absolute precision/specificity/unambiguity" belt and suspenders.
(kind of unrelated but along the same lines, I toy with the idea of getting rid of . and .. visible in the filesystem, and make them only part of the syntax of paths. then you could have unambiguous multiple links to a directory: ".. is where you came from" and .. in the root is still the root, so chroot works too)
As someone who has also suffered uncountable years of abuse from rsync, I understand the impulse, but I think it makes a lot more sense (and is a safer default) to create a second ”services”.
If we have a chance to change rsync defaults to something less insane and save future generations from this mess I think we should.
Of the two possible worlds where in one this reimplementation matches what some see as annoyances in the interface or in another they mostly match the interface except for a few cases where the purposefully diverge (for no good technical reason), IMO the latter is far worse and causes more enexpected behavior.
At most, add a special flag to opt into different default behavior so nobody is surprised by running the same command on different systems and getting different behavior.
LLMs make writing code faster/easier, but the thinking was always the important bit. I’ve no idea why you’d muck up such a long-standing, reliable piece of software.
I find it quite strange that people do not seem to be aware of that...I think many started worshipping the tool as if it was some kind of divinity and lost all objctivity. This doesn't bode well for the future if people aren't able to review code anymore.
Example: it recently flagged ID derivation from a signing key. Opus itself suggested it! When reminded of that, it did this new 4.8-style “my bad, and here’s why I was right in the first place.”
Humans are still badass.
So rsync should be pinned to an older version and just get security updates.
https://github.com/gokrazy/rsync/graphs/contributors
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...
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?
there might be newer stuff in linux land now i see comments about landlock but i assume those will build on the linux primitives rather than whole new ones. - total assumption there but it would seem logical to reuse rather than make new.
part of likely what they mean by 'mess' is that its all over the place. many different ways to try and lock things down. hard to pick what is best etc. without thoroughly diving into the different subsystems entirely. (as opposed to just have 1 or 2 relatively simple system calls)
The list of syscalls any code anywhere in the system calls is not a published contract with any guarantees.
> You could just
… is doing some heavy lifting here. "You could just" all but guarantee that your program will break in a couple of years for all users who do the responsible thing?
Sure, if you're building an appliance with a support contract, where you control everything, then that's doable. Servers/desktops/laptops, not so much.
> 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.
There is Landlock now, I believe it would be possible to implement unveil and pledge on top of that.
https://clehaxze.tw/gemlog/2022/04-02-landlock-unveil-experi...
https://github.com/marty1885/landlock-unveil
There was a discussion here about it a few years ago: https://news.ycombinator.com/item?id=32096801
Interesting choice of word
> 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.
Under Portability [1] I don't have access to update that repo. I deleted my accounts when Microsoft took over.
[1] - https://github.com/kristapsdz/openrsync
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.
EDIT: ah, fun: they did include it in 15.0, but they decided to save the breaking change that removed backwards compatibility for 15.4. https://apple.stackexchange.com/a/479297
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.
> 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.
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.
I don't think so; it's two different goals, not two different ways of thinking about it.
The goal of GPL is the interests of users (they can never be locked out of improvements no matter who makes changes).
The goal of BSD is the interests of the developers (A developer can take it, add mods and close of the entire result).
In practice, GPL is pro-user, BSD/MIT is pro-business.
Yet every time a GPL licensed product competes against a BSD licensed product in an open market, even when inferior the GPL product wins in the long run.
That's because the GPL ecosystem leapfrogs the BSD one every time one of those pro-business businesses sells proprietary add-ons while the former stands on one another's shoulders.
It's almost like free markets composed of multi vendor ecosystems are business friendly?
(Sarcasm aside, the weasel word here is "business". Customers and vendors are both businesses. Monopolies are very business-friendly for the vendor, just not for anyone else.)
It's a rule that's mostly only true for self-contained products though, it hasn't been true for things like codecs and SSL stacks, and components used by proprietary and free products alike.
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.
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.
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.
CLAs are not an attribute of the GPL. They're an agreement that can be applied to contributions to any codebase with any license.
equal footing on the license is what allowed AWS to crush the original creators of the products they host.
it's a trade off.
the AGPL does not prevent a hosting service. it only prevents creating non-free addons. i see no problem with that. see also my other comment
Afaik BSD licensed stuff can be re-licensed under any more closed licenses at any time, where as to re-license GPL, you need consent from every single contributor.
But i’m not familiar with the redis-valkey story so, maybe there is some nuance i am missing?
There is no such risk. If someone wishes to make a closed source derivative of the BSD-licensed original, it does not deprive anyone of the original. That remains there, just as open as before.
With the GPL, if you want to modify, and built on others work, you have to share.
Share and share alike, vs take if you like share if you like.
> 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).
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.
In fact, your insistence that “Open” can only be used by projects that are replacing proprietary software is itself very odd.
OpenBSD itself has had its name for thirty years, and is not named for being an “open source” implementation of a proprietary OS.
Do not invent arguments that I did not make. I have only said that naming it openrsync when rsync already exists and is "open" in the general sense is confusing.
I find the negative reactions to this observation very confusing, especially yours, but I see that you're an OpenBSD developer so that explains your bias.
Edit: and now these same people are backtracking to agree with me that "open" is ambiguous, this place never ceases to amaze
What was said is that the OpenBSD operating system folks chose to use the Open— prefix for all their other projects ("They simply ran with the naming convention."). What was not said was that all Open— prefixed projects were from them.
Not closed source, but with rsync 3.0 it changed its license to GPL3, which a lot of folks don't like: BSD/MIT licenses have zero limitations on use and distribution, GPL2 (rsync 1.x, 2.x) forces one to release code, GPL3 (rsync ≥3.x) adds further restrictions.
Some folks want to distribute code with as few restrictions as possible. Other folks have a great good/goal in mind (e.g., 'all software is open source') and so add 'local restrictions' to hopefully achieve greater non-restrictions.
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
That said, every language on earth will adapt foreign words into its phonology. The alternative would be to adopt the phonology of every language that loaned a word into your language.
What the hell? That’s the job.
- 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
- ...
AI is only going to get better and better. Eventually manually writing software by hand with programming languages will be thought of as the punch-card phase of software development.
Do these people think we'll be writing software in 200 years time? That anybody will be maintaining rsync, let alone this "moral human hands only" version of it?
The anti-AI lot are trying to make all AI content wear a Scarlett letter. I wish they would wear one themselves so that we could filter them from our timeline.
This "effort" is entirely wasted.
what twitter account proved that?
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.
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).
I disagree. While rsync is most often used to transfer data between "friendly" systems, it's inherently crossing a security boundary. It's important to make sure that an attacker can't leverage it to transform the breach of one system into the breach of multiple systems.
I guess you can define "strict" however you want, but from what I saw ~10 years ago, most linux distros handled mirroring with rsync. That's a lot of usage in a pretty core part of the foundational open source ecosystem.
They’re layering on checksums and signing such that they mostly don’t think about the trustworthiness of mirrors or the networks between them.
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
(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...
That is from the original post in the thread. Is that really due to LLM ? I do not know since I avoid AI as much as I can.
But the person also posted this link too:
https://github.com/NetBSD/src/commit/f764ddf4062e855f73fe2e3...
But that is the odd thing, how to tell for sure if a LLM was used :)
I have not tried using exclude in openrsync in a while, but I can see it now works on OpenBSD 7.9!
Ubuntu's packaged rsync, is it Samba rsync? Why reimplement it?
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.
I can't possibly see a correlation.
Weird how 3.4.2. didn't have a similar deluge of issue reports, though.
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.
This thread has people suggesting it’s good or important to go tell open source devs they’re using bad tools.
The former is great. The latter is not.
Technically true. However, I also do not owe them my silence.
I like open bsd but this just seems like burning cash
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).
There's some discussion here that might help answer your question: https://en.wikipedia.org/wiki/Open_source#Economics
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."
Would that stop it? My understanding was that at least OpenBSD tended do redo things for technical reasons, not just licensing
The correct way to stop this is to file bugs against the software for not matching the de-facto standard of the copied software.
Edit: I see that they switched from ustar to pax as the default format in OpenBSD 7.6, so I guess this isn't true any longer.
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.
My thought upon reading this is why would Apple or Android bother including rsync? I've noticed that I've needed to install it manually on fresh installs of Debian, FreeBSD...
But then, I just checked a recent Mac that I don't use much and haven't put much on, and it's installed.