Earlier quoted context omitted.
rsync is one of those tools that I use so infrequently that I’d rather have a good GUI than have to relearn the command switches every time I use it.
Yeah. Though rsync is not the most option-rich program ever. What really needs GUI is... ffmpeg! :)
Rsync, GUIs, power, control, design, and decisions
51–60 of 138 posts
Re: Rsync, GUIs, power, control, design, and decisions
#52> Successful UNIX tools (or any tools, for the most part) are the ones with a simple concept manifested very thoroughly, and rsync is certainly that. [...] There are over 100 flags in rsync that you can select to do different things. So, this is what I mean by doing something simple, and doing it very well and very thoroughly. Rsync is certainly not simple. It certainly doesn't do one thing. It's "extraordinarily ver…
I believe rsync can do two of your doesn't do list: > And then it doesn't give you a good progress bar rsync --progress > let you resume interrupted operations rsync --partial ...or enable both at the same time with rsync -P (These features only available on samba.org's original rsync, and not OpenBSD openrsync[1], but I don't think openrsync has seen a widespread use yet, as it's still pretty new) [1]: https://www.o…
If you use rsync --partial it has to rescan the source and destination directories again. All it does is let you resume transfers, and for some of us, transfers are not the slow part.
Re: Rsync, GUIs, power, control, design, and decisions
#53> Successful UNIX tools (or any tools, for the most part) are the ones with a simple concept manifested very thoroughly, and rsync is certainly that. [...] There are over 100 flags in rsync that you can select to do different things. So, this is what I mean by doing something simple, and doing it very well and very thoroughly. Rsync is certainly not simple. It certainly doesn't do one thing. It's "extraordinarily ver…
Adding pv to a tar|ssh pipeline is simpler than just passing -P to rsync? I must disagree.
Re: Rsync, GUIs, power, control, design, and decisions
#54> Successful UNIX tools (or any tools, for the most part) are the ones with a simple concept manifested very thoroughly, and rsync is certainly that. [...] There are over 100 flags in rsync that you can select to do different things. So, this is what I mean by doing something simple, and doing it very well and very thoroughly. Rsync is certainly not simple. It certainly doesn't do one thing. It's "extraordinarily ver…
Your "piped tar" doesn't cover the main use case of rsync, which is (unsurprisingly), remote file hierarchy sync'ing. In particular, when there's a hierarchy on a remote machine that I want to sync to a partially-up-to-date hierarchy on a local machine, the required rsync command is a one-liner and it's very fast because it uses a diff. Incidentally, the "tar" man page is not exactly a model of simplicity itself.
That's exactly my point, isn't it? rsync does several different things, depending on how you invoke it, rather than being a UNIXy tool that does one thing well. Because the single tool does everything, you can't easily swap out different parts of it, and the single tool takes a hundred options.
Re: Rsync, GUIs, power, control, design, and decisions
#55Earlier quoted context omitted.
Adding pv to a tar|ssh pipeline is simpler than just passing -P to rsync? I must disagree.
Maybe I wasn't clear about my complaint. My complaint is that rsync --progress sucks, I'm not complaining that it's hard to use.
Edit: --progress also tells you how many files rsync has been told to sync, and of those, how many are remaining.
2384908 100% 57.52MB/s 0:00:00 (xfr#1, to-chk=7/11)
e.g. transfer #1 out of 11 files or directories to check, with 7 remaining.Re: Rsync, GUIs, power, control, design, and decisions
#56> Successful UNIX tools (or any tools, for the most part) are the ones with a simple concept manifested very thoroughly, and rsync is certainly that. [...] There are over 100 flags in rsync that you can select to do different things. So, this is what I mean by doing something simple, and doing it very well and very thoroughly. Rsync is certainly not simple. It certainly doesn't do one thing. It's "extraordinarily ver…
What is simple in rsync is the idea of synchronising stuff from A to B. That is all it does in all the cases you mentioned. It is hard to emulate what rsync does with archive mode enabled, which speeds up transfers, so tar isn't exactly a replacement for rsync. There are better ways to show progress, for example using the flag `--info=progress2`. It doesn't behave well in automated scripts though
Archive mode is what tar does by default. It is just an alias for -rlptgoD. How does this speed up transfers? Are you thinking of something else?
Re: Rsync, GUIs, power, control, design, and decisions
#57Earlier quoted context omitted.
I would think there maybe a "command-line" version of GUI design: supply limited default buttons for common options, but allow user customization. For example, I would love to have the button from author's design but tune it specifically to my need including running a specific set of "command lines".
Note that even rsync itself has some limited support for "profiles", like --archive.
rsync alias --sync -rpcLDvz --chmod=D0755,F0644
A call "rsync --sync foo@bar:baz/ baz" will expand the command into "rsync -rpcLDvz --chmod=D0755,F0644 ...".The "program alias newopt opt" syntax is actually popt's thing (see Option Aliasing[1]) and it works with everything that uses popt(3) for its command line parsing.
Re: Rsync, GUIs, power, control, design, and decisions
#58Earlier quoted context omitted.
I'm a big fan of this. Probably 90% of the time the tldr summary has my use-case covered.
If the tldr entry exists. Obscure commands don't have one while you're less likely to know these well. Chicken/egg problem.
Re: Rsync, GUIs, power, control, design, and decisions
#59Earlier quoted context omitted.
Maybe I wasn't clear about my complaint. My complaint is that rsync --progress sucks, I'm not complaining that it's hard to use.
I don't like the --no-h change they made to the --progress format (mentioned in another comment) because it broke my parsing once, but otherwise I don't really see a problem with it and I expect most people have never tried to parse it. What's so bad about --progress? Edit: --progress also tells you how many files rsync has been told to sync, and of those, how many are remaining. 2384908 100% 57.52MB/s 0:00:00 (xfr#1…
Re: Rsync, GUIs, power, control, design, and decisions
#60'People complain about Electron a lot, but the primary complaint just seems to be that its bloated – carrying an entire browser engine along with something small. But like, all of our computers are already bloated, and there’s at least a 40% chance that right now I am bloated, and it doesn’t mean you should love me any less, and I think the above points I’ve raised override the lack of svelt-ness of the program. Peop…
I would use apps built more like electron if they simply removed the electron part and replaced the app with a name for a namespace and simply shipped tht js/html/images along with a api service.
Installing would be binding tht app to tht name space and using the browser of choose and navigating to namespace.localhost. In this case rsync.localhost.
The system would be a bit more complex for handling auth and a few things but let's not get bogged down in solvable details.
Then I could access my apps from my phone. Another system (if I chose to expose them publicly).