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

141–150 of 193 posts

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

#141

Post by skeledrew »

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.

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.

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

#142

Post by kennywinker »

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

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

#144

Post by kennywinker »

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

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

Sure, yeah - like most “paradoxes”, it’s not actually a paradox unless you only look at it from one specific viewpoint.

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

#145

Post by LAC-Tech »

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.

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

#146

Post by bombcar »

eichin wrote: post #115
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...)

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.

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

#147

Post by bombcar »

formerly_proven wrote: post #16
ranger_danger wrote: post #5

Earlier quoted context omitted.

I feel bad for people with the real name Claude.

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.

Salesforce spent some amount of money to license the name Einstein from his estate/heirs.

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

#148

Post by TZubiri »

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.

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

#149

Post by kbenson »

kbenson wrote: post #85
hnarn wrote: post #83

Earlier quoted context omitted.

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

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

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.

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

#150

Post by Fnoord »

chasil wrote: post #70

There is also a (stub) web page: https://www.openrsync.org/ The problem with this fragmentation of rsync is that Apple and Android will prefer it, but the Linux and greater GPL world will adhere to the original implantation due to inertia. Power users will just have to know the quirks of each version. The only way to stop this is for the original author(s) to release this under a BSD license. Edit: For those assuming…

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

Post reply on HN