Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rsync, GUIs, power, control, design, and decisions

bits.ashleyblewer.com

Post reply on HN
Print view View original

21–30 of 138 posts

Re: Rsync, GUIs, power, control, design, and decisions

#21

Post by erikpukinskis »

F-0X wrote: post #19
fitzroy wrote: post #8

I really wish there were more GUI wrappers that literally wrote the CLI commands out on screen as the GUI was modified, to help with bridging the GUI/CLI gap for people. Also, I miss arRsync.

The problem with this is that it misses the point of most cli programs, which is that they are to be composed with other programs. Besides, when colleagues of mine decided to demystify the command line and learn it proper, they're always surprised how much easier it is than they expected. The GUI/CLI gap, as far as I have seen, is one of willingness to invest some time to learn.

> The problem with this is that it misses the point of most cli programs, which is that they are to be composed with other programs.

That's not true, CLI programs would still exist even if they could not be composed. And I would guess that if you counted how many of our commands include 1, 2, or 3 executables, the 1 column would be the biggest by far.

One of the major headaches of CLI programs is that they're hard to learn interactively because there's no starting point. You have to read the docs. The point of a GUI command builder is that it gives you something interactive to play with to start to learn how the CLI commands work. The point is not to do everything through the builder, the point is to bootstrap people to the point where they no longer need it.

Also, there's no reason a GUI command builder couldn't also show you how to do composition.

Re: Rsync, GUIs, power, control, design, and decisions

#24

Post by gmfawcett »

Wowfunhappy wrote: post #18
floatboth wrote: post #15

Earlier quoted context omitted.

Yeah. Though rsync is not the most option-rich program ever. What really needs GUI is... ffmpeg! :)

There are lots and lots of ffmpeg GUIs, the problem is that IMO, all of them are either (1) not powerful enough or (2) more difficult to use than just the command line. The first problem may, of course, be a non-issue depending on what you need to do.

Someone with a sufficient itch (and some Elisp skills) could probably do for ffmpeg what the Magit team did for Git. Git's another program with a litany of options, and Magit does an outstanding job of covering them with an easy-to-use interface.

https://magit.vc/manual/magit/

Admittedly the ffmpeg bar is probably higher, esp. given that ffmpeg can be configured and built a couple dozen different ways.

Re: Rsync, GUIs, power, control, design, and decisions

#25

Post by rmah »

fitzroy wrote: post #8

I really wish there were more GUI wrappers that literally wrote the CLI commands out on screen as the GUI was modified, to help with bridging the GUI/CLI gap for people. Also, I miss arRsync.

Apple did this with MPW back in the day. I think the feature was called "commando".

You would type the command name, then "..." and up pops a dialog box with all the options and popup help for what different things meant. As you fiddled with the GUI, it would generate the flags as text you could see. And finally, you could execute, or paste the command line text into the console, or both. It was awesome.

Re: Rsync, GUIs, power, control, design, and decisions

#26

Post by klodolph »

> 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 versatile" to the point of madness. Here's what it does:

- Copies files from A to B

- Mirrors directories

- Computes diffs

- Applies patches

- Evaluates filters

- Runs as a daemon

- Runs over various remote shells

- Applies filters to filenames

And then it doesn't give you a good progress bar or let you resume interrupted operations, or gather errors at the end. I think this is a good case where the tool may have grown too large and unwieldy, and it may be better to replace it with an API or a collection of small, UNIX-like tools. For example, if I just want to copy files from point A to B, I can do this:

    tar c . | ssh host tar xv
If I want a progress bar, I can use pv,

    tar c . | pv | ssh host tar xv
Usually I find this easier to use than rsync.

Re: Rsync, GUIs, power, control, design, and decisions

#27

Post by mrpippy »

fitzroy wrote: post #8

I really wish there were more GUI wrappers that literally wrote the CLI commands out on screen as the GUI was modified, to help with bridging the GUI/CLI gap for people. Also, I miss arRsync.

Apple's MPW (Macintosh Programmers Workshop) had exactly this: a tool called Commando which allowed you to graphically put together and run command lines.

http://mirror.informatimago.com/next/developer.apple.com/too...

Re: Rsync, GUIs, power, control, design, and decisions

#28

Post by darkpuma »

klodolph wrote: post #26

> 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

#29

Post by lordleft »

'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. People don’t care that an application is a streamlined 3MB or a big round 200MB boy – they care that it works for them and it makes them feel good about using it.'

I think this is true in some cases, but the sorts of folk who run rsync may be more interested in performant hardware that can run on older machines than average. Then again, they'd probably opt for sticking to the command-line tool. Still a very cool project!

Re: Rsync, GUIs, power, control, design, and decisions

#30

Post by darkpuma »

cyc115 wrote: post #16
jimmaswell wrote: post #11

Earlier quoted context omitted.

I always end up having to google how to do stuff with CLI tools but GUIs let you discover how to do things intuitively. Tried using man pages but they're always slower to find stuff in and a stackoverflow answer is more likely to target the use case I'm going for.

not super relevant here, but for those interested. There is a cli tool called `tldr` that takes in the name (of a tool) and prints out common usages.

I'm a big fan of this. Probably 90% of the time the tldr summary has my use-case covered.
Post reply on HN