Earlier quoted context omitted.
I feel bad for people with the real name Claude.
Yeah, and we thought the most unlucky people were the ones named Alexa.
Openrsync: An implementation of rsync, by the OpenBSD team
121–130 of 193 posts
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#122This 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.
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.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#123This 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…
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#124This 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.
I feel bad for people with the real name Claude.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#125Earlier quoted context omitted.
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 t…
> 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...
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#126I'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…
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
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#127Earlier quoted context omitted.
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
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?
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.
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#128This 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…
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#129I'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?
Re: Openrsync: An implementation of rsync, by the OpenBSD team
#130Earlier quoted context omitted.
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.
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).