>I had somehow pigeonholed it as "for cloud to local or vice-versa", and never considered it for local transfer, like over my own LAN.
Huh. Exact same thoughts here. I never used rclone because I don't use AWS or similar, just lots of bare metal on and off my LAN that I can ssh to. I am quite comfortable with rsync's quirks and args, so not sure I'll quit using it, but maybe I'll try rclone next time I do a massive transfer. Similarly I've been shown that ddrescue can act as a full dd replacement, but I'm so used to dd I still tend to use it.
The repo it links to presents their reasons for tracking and potentially avoiding LLM-supported projects; are all of those ridiculous? Is the technology's track record so amazing as to make the conclusion ridiculous? Or did you mean tar as a replacement to rsync, specifically?
Isn't a huge part of the point of developing in the open so that people can assess the entire technology, including how its developed, and choose if they want to use it?
Folks using LLMs will have to accept that that will turn people away from using their software ¯\_(ツ)_/¯
His anti-LLM stance isnt unsurprising given the values he's posted about regularly for years, if anything his ability to avoid cargo-cult/hype nonsense is why I (and seemingly others) value his writing so much.
as always: imho (!)
tar is great, and well kown - but not particularly for "incremental backups over the net" ...
this is what rsync is/was for.
idk ... whatever the problem is with rsync, but apparently thats none of my business ;))
you could use, and which usage is very similar to rsync:
rclone
* https://rclone.org/
intro
* https://www.jeffgeerling.com/blog/2025/4x-faster-network-fil...
and additionally its also faster than rsync ...
just my 0.02€
reply