Rsync, GUIs, power, control, design, and decisions • Hacker News Board

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

#81

Post by huac » Tue, Jul 09, 2019, 7:45 PM UTC

carapace wrote: post #46

Great article. Check out Unison. https://www.cis.upenn.edu/~bcpierce/unison/ > Unison is a file-synchronization tool for OSX, Unix, and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other. > Unison shares a number of featur…

i think the UI for unison is very good, after the initial config and setup, 90% of the UI is just the changelog. you can then relatively easily choose how to sync.

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

#82

Post by noonespecial » Tue, Jul 09, 2019, 7:46 PM UTC

There is a gui for rsync that's quite popular. Its called Dropbox.

A lot of successful projects seem to be of the form 1) Consider old-school unix tool. 2) Aim for one aspect of its functionality that serves a mainstream need. 3) Put friendly face on it so less technical users can reap the benefits.

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

#83

Post by arithma » Tue, Jul 09, 2019, 7:47 PM UTC

pandalicious wrote: post #78

mbrumlow wrote: post #60

Earlier quoted context omitted.

I avoid electron apps because it is almost anti web. 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…

what about local filesystem access, os integration, and all the other things that you expect a desktop app to be able to do (like in this case executing a separate binary) which violate the security models of browsers?

App becomes a local backend server that has privileged access to the machine (with control over what it accesses, maybe give it a specific user), and a web UI to access the app.

Someone in the tree of replies for your parent explained and was contemplating actually going through with it.

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

#84

Post by c-smile » Tue, Jul 09, 2019, 7:47 PM UTC

nixpulvis wrote: post #3

Nothing beats a good CLI with a proper man page in my book. I like having all the power at my fingertips, and a good way to search for what I want to do without using the internet.

That depends.

Applications that have occasionally used UI MUST BE self descriptive. Their functionality MUST BE consumable without need of reading man pages.

Otherwise they will have very few users.

Computer is for human, but not human is for computer. As its configurational appendage.

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

#85

Post by haggy » Tue, Jul 09, 2019, 7:48 PM UTC

rakoo wrote: post #77

lordleft wrote: post #29

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

The sort of folk who run rsync is a niche clique. Maybe this GUI is the perfect occasion to put rsync in the hands of more people ? We all know how powerful it is, there is no reason it should be used only by people who are happy testing the different flags, reading random blog posts about what combination to use, and trying to find salvation in a 3000-line manual page.

Where and how are you coming to the conclusion that rsync is "niche clique"?

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

#86

Post by klingonopera » Tue, Jul 09, 2019, 7:52 PM UTC

writepub wrote: post #68

klingonopera wrote: post #63

Earlier quoted context omitted.

This is actually an issue in app development? I thought with SDL, QT, wxWidgets, et al., writing native apps was basically a covered topic...?

It is a problem. Here's [1] a talk from fossdem on the various issues, and a couple solutions. [1]: https://youtu.be/ANcU1g7ZWdU

It seems to me, that the issue here is mostly web developers who are used to coding for browsers, are slowly moving into the desktop application domain, and instead of them applying the traditional languages used there (C and C++), are circumventing these by creating frameworks that allow them to continue using their web langs in a desktop environment.

If that is the case... they'll never get rid of the megabyte bloats. That's basically just baseline overhead from a browser engine itself.

Crazy idea: Reverse the entire process? Use C for everything, including web tasks, i.e. FastCGI? Correct me if I'm wrong, but with WebAssembly around, is it possible that C programming might make a comeback into web development?

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

#87

Post by grumdan » Tue, Jul 09, 2019, 7:52 PM UTC

lordleft wrote: post #29

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

While disk space may not often be an issue (though small SSDs are commonplace), RAM usage certainly is an issue if every little tool is an electron app.

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

#88

Post by drieddust » Tue, Jul 09, 2019, 7:59 PM UTC

theamk wrote: post #2

> Is it better to make up common rsync “recipes” for people to use, or is it better to let folks have access to ALL of the flags [...] and pick’n’mix what they want? I think both. This is the hard part about GUI design -- it is pretty easy to make a list of 100 command-line options listed alphabetically on the man page, but for GUIs, people expect much more. There should be some sort of logical grouping. One area of…

> There should be some sort of logical grouping. One area of the screen would be options related to what is transferred, a second area is metadata, the third one is speed-only optimizations, fourth is logging and so on. Having "hardlinks" all the way on the left and "symlinks" all the way on the right does not make a good GUI.

This is exactly what Microsoft have done with its ribbon interface[1] which is actually a mix of menus and toolbar with most commonly used functions logically grouped and prominently displayed. These Ribbons also changes as the context changes. Frequently used functionality gets into quick access ribbon displayed. There is also context sensitive popup toolbar available on right click.

[1] https://docs.microsoft.com/en-us/windows/win32/uxguide/cmd-r...

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

#89

Post by oblio » Tue, Jul 09, 2019, 7:59 PM UTC

haggy wrote: post #85

rakoo wrote: post #77

Earlier quoted context omitted.

The sort of folk who run rsync is a niche clique. Maybe this GUI is the perfect occasion to put rsync in the hands of more people ? We all know how powerful it is, there is no reason it should be used only by people who are happy testing the different flags, reading random blog posts about what combination to use, and trying to find salvation in a 3000-line manual page.

Where and how are you coming to the conclusion that rsync is "niche clique"?

If you use any CLI you are already "niche clique".

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

#90

Post by oehpr » Tue, Jul 09, 2019, 8:00 PM UTC

teknopaul wrote: post #80

If ever there was a tool that didnt need a gui its rsync. Idea is to keep two folder structures in sync. Exactly the sort of thing you want to script, or trigger when one side changes, or cron. I've use rsync all my computing life but i've rarely wanted to have to manually push a button to make it work. A good cli interface is clearly the correct interface to rsync. Embeding rsync in an app that does something else m…

I think the foundation of this comment is incorrect. This helps you build up the rsync command and test it. It gives you the rsync command that it runs. You're supposed to take the command it generates and use another tool to automate it. You're not supposed to automate the interface. It fulfills the conditions you expect of it.

And personally, I loath constructing rsync commands. Every 2 months I have to parse that 2300 line rsync man page. And every 2 months google sees another search query "rsync GUI" Because I am sick of building these things.