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

131–140 of 193 posts

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

#131

Post by bagxrvxpepzn »

thomashabets2 wrote: post #78
saidnooneever wrote: post #72

Earlier quoted context omitted.

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

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.

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

#132

Post by dark-star »

skeledrew wrote: post #4

This attempt to avoid things that use AI is increasingly looking like some weird kind of reverse whack-a-mole where each targeted hole becomes radioactive after. Just grabbing some popcorn to watch.

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

- ...

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

#133

Post by bigstrat2003 »

echelon wrote: post #122
skeledrew wrote: post #4

This attempt to avoid things that use AI is increasingly looking like some weird kind of reverse whack-a-mole where each targeted hole becomes radioactive after. Just grabbing some popcorn to watch.

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.

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

#134

Post by e12e »

e12e wrote: post #125
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.

Apparently someone tried wrapping landlock in unveil: https://clehaxze.tw/gemlog/2022/04-02-landlock-unveil-experi... https://github.com/marty1885/landlock-unveil

... And looks like cosmopolitan libc wraps landlock for unveil, in addition to implement pledge.

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

#135

Post by bigstrat2003 »

kennywinker wrote: post #17
gilrain wrote: post #13

Earlier quoted context omitted.

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

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.

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

#136

Post by krelas »

wtetzner wrote: post #111
Panino wrote: post #73

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

> The one place in my usage where it doesn't match Samba rsync is with the following: > openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services This appears to match "normal" `rsync` behavior as well. I think you need a trailing slash after `services` to sync only the contents. EDIT: actually my "normal" rsync is openrsync on macOS...

This switch happened in macOS 15.4, it was pretty easy to miss.

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

#138

Post by dspillett »

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.

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.

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

#139

Post by chasil »

dspillett wrote: post #138
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. 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.

Exactly.

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

#140

Post by chasil »

yjftsjthsd-h wrote: post #90
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. Would that stop it? My understanding was that at least OpenBSD tended do redo things for technical reasons, not just licensing

Jeremy Alliston (assuming that my memory serves me) is the foremost to decide if this should be done.
Post reply on HN