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

121–130 of 138 posts

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

#121

Post by adrianratnapala »

gerdesj wrote: post #112
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…

"If ever there was a tool that didnt need a gui its rsync. Idea is to keep two folder structures in sync" rsync is a tool to copy data - it can keep two folder structures in sync but that is not its sole purpose. Unison https://www.cis.upenn.edu/~bcpierce/unison/ is a tool to keep two folder structures in sync - that is its main goal but it can have other uses. Unison happens to have a WIMP style GUI. rsync could hav…

> Unison https://www.cis.upenn.edu/~bcpierce/unison/ is a tool to keep two folder structures in sync - that is its main goal but it can have other uses.

And though I tend to be a GUI hater, Unison is one tool where I find the GUI much more useful than the command line alone. The game is to iteratively come up with a set of rules which Unison will use to into effect on your dataset. The GUI quickly show you the effect of your current rules, and lets you propose the next iteration etc.

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

#123

Post by drieddust »

rjmorris wrote: post #117
WorldMaker wrote: post #109

Earlier quoted context omitted.

> I think I would mind //graphical menus// less than the change to an always in your face ribbon. The ribbon has always been collapsible / "auto-hidable" to just a menu bar (double-click the active tab; admittedly not entirely easily discoverable). It's very much a graphical "pull" menu in the classic sense in that mode and the two-step Alt+ shortcuts might feel a lot more understandable/close-to-home in that context…

> The ribbon has always been collapsible / "auto-hidable" to just a menu bar Sadly, this is no longer true in Outlook, at least in the version recently pushed to my work computer. The only two options now are the "simplified ribbon" and the classic ribbon ( https://support.office.com/en-us/article/use-the-simplified-... ). You can no longer hide the ribbon completely. I assume other Office applications will soon foll…

I have latest outlook and I keep ribbon hidden on laptop so this might be your company admins enforcing some weird policy.

See below

https://support.office.com/en-us/article/show-or-hide-the-ri...

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

#124

Post by kstenerud »

There are reasons why it will be difficult to write a GUI for rsync:

1. The 80% use case for rsync is a carefully crafted pre-set script that runs in a crontab, not as a one-off thing that you select options for and hit "run".

2. There are so many switches and options that you're not going to be able to model them all in a coherent manner without overwhelming the user.

3. The price of failure is data loss, which means that people will either be afraid to use it, or foolishly lose data and then be afraid to use it. A dry-run mode helps, but is not a panacea.

What you need is a multipart system:

1. A set of vetted recipes with good, succinct descriptions of what they do, why they're useful, and where the cliffs are, and a program to apply them for the specific user.

2. A design GUI that helps guide you through the process of building your own recipes.

3. A runner for running your recipes from the command line, so you can crontab it (if the recipe system doesn't generate self-contained executables - scripts or whatever - that you can just call directly).

4. A runner for running or testing your recipes in a GUI environment, for the 5% of times you actually need this.

Trying to mix more than one of these parts into a single program is a UX mistake.

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

#125

Post by rakoo »

LeonB wrote: post #120
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.

>The sort of folk who run rsync is a niche clique. While that may be true, I think: "The sort of folk who would benefit from being able to run rsync" is a much, much broader group. (And even the existing group of rsync users can benefit from a tool to help construct a command line, that they then copy out and use. Usability matters!) Ashley's target market are Archivists. They may or may not use rsync already, but yo…

Absolutely, that was my point: the tool is extremely good but kind of hard to use, a lot of people would definitely benefit from it.

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

#126

Post by rakoo »

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"?

Ask a hundred person in the street if they've ever heard, let alone used, rsync.

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

#127

Post by mbrumlow »

johannes1234321 wrote: post #114
spirodonfl wrote: post #103

Earlier quoted context omitted.

It's not that hard, actually, I've done this with Node. Since you can install Node anywhere, include a binary, or whatever, you can have Node run as a server and it can run with elevated privileges, if needed. You have it scan a directory structure and auto generate a path that you can use in a browser, any browser, to view your newly install app. You can do this with APIs too so you can have internal tools with APIs…

It is easy, till you get into the trouble of local Firewalls, Double use of port numbers and all those details, where the daemon runs unexpectedly or stops without good information to the user etc

In my minds eye we would give one dedicated port to the main service. The apps would pick a random unused port, and report back to the main service to which would then become a reverse proxy from the main services port to the bound port.

So if the rsync app bound to 5392, it would report back to the main service so. And it would ensure all (or some subset of request) to rsync.localhost were reverse proxied back to localhost:5392.

For the most part when I say some request I mean most if not all, but it might be nice to have a system level rsync.localhost/.info uri that would give system level information about the app.

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

#128

Post by yjftsjthsd-h »

mbrumlow wrote: post #127
johannes1234321 wrote: post #114

Earlier quoted context omitted.

It is easy, till you get into the trouble of local Firewalls, Double use of port numbers and all those details, where the daemon runs unexpectedly or stops without good information to the user etc

In my minds eye we would give one dedicated port to the main service. The apps would pick a random unused port, and report back to the main service to which would then become a reverse proxy from the main services port to the bound port. So if the rsync app bound to 5392, it would report back to the main service so. And it would ensure all (or some subset of request) to rsync.localhost were reverse proxied back to lo…

If we're on the local system anyways, why not just use an actual socket in the file system?

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

#129

Post by haggy »

rakoo wrote: post #126
haggy wrote: post #85

Earlier quoted context omitted.

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

Ask a hundred person in the street if they've ever heard, let alone used, rsync.

What kind of crap response is that? Ask any 100 people on the street about any industry specific tooling or terms and you're likely to get nothing. Go ask people 100 people about "liquidated derivatives" and see what happens.

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

#130

Post by zonidjan »

yjftsjthsd-h wrote: post #128
mbrumlow wrote: post #127

Earlier quoted context omitted.

In my minds eye we would give one dedicated port to the main service. The apps would pick a random unused port, and report back to the main service to which would then become a reverse proxy from the main services port to the bound port. So if the rsync app bound to 5392, it would report back to the main service so. And it would ensure all (or some subset of request) to rsync.localhost were reverse proxied back to lo…

If we're on the local system anyways, why not just use an actual socket in the file system?

Indeed; this also solves the problem of access control. Something like /tmp/notelectron.$EUID with umask 0077.
Post reply on HN