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

161–170 of 193 posts

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

#161

Post by prmoustache »

port11 wrote: post #154
trollbridge wrote: post #137

Given the sudden spike in vibe-coded commits to the rsync codebase, and regressions that’s introduced, this is very good news.

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, reli…

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.

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

#162

Post by lelanthran »

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.

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

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

#163

Post by thomashabets2 »

bagxrvxpepzn wrote: post #131
thomashabets2 wrote: post #78

Earlier quoted context omitted.

No, landlock is a separate thing. It's the first of its kind on Linux that doesn't completely suck, like seccomp does ( https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.h... ).

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.

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.

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

#164

Post by xorcist »

lelanthran wrote: post #162
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.

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

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

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

#165

Post by gverrilla »

bigstrat2003 wrote: post #133
echelon wrote: post #122

Earlier quoted context omitted.

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…

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.

> proven to not work.

what twitter account proved that?

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

#166

Post by michaelcampbell »

queuebert wrote: post #124
ranger_danger wrote: post #5

Earlier quoted context omitted.

I feel bad for people with the real name Claude.

I don't know, Claude Shannon did okay.

Presumably a bunch of Adolf's did too, prior to, you know, the 1930's.

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

#167

Post by maleldil »

isityettime wrote: post #117
papercrane wrote: post #54

Earlier quoted context omitted.

> 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

> favorite

Interesting choice of word

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

#168

Post by gorgoiler »

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)
…gets eventually rewritten, once it works, into:

  def render(phrase: str, font: Font) -> Shape:
    return w.text(phrase, font)

  font = Fonts.load(“Perpetua”)
  text = render(“hello world”, font).translate((50, 0, 20))
  show(text)
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.

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

#169

Post by DonHopkins »

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.

It's tempting to develop a useful but closed source project called "is" and dare them to make an open version of it.

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

#170

Post by pjmlp »

bigstrat2003 wrote: post #135
kennywinker wrote: post #17

Earlier quoted context omitted.

Is this not the paradox of tolerance restated in different terms? BSD license is unrestricted, it tolerates taking open source and closing it, thus always being at risk of things closing down. GPL license doesn’t tolerate taking from open source and closing it, thus ensuring things stay open.

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

It deprives for example the LLVM community to profit from PlayStation compiler optimizations.
Post reply on HN