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

71–80 of 138 posts

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

#71

Post by aidenn0 »

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…

Unison is terrible in that you must have exactly the same version (down to micro version) of unison on both sides. That makes it very hard to use in practice.

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

#72

Post by aidenn0 »

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.

I'd love to just make a GUI for generating ffmpeg filter graphs. The MS SDK had a directshow filter graph editor (graphedit i think it was called?) that was quite pleasant to use back in the day.

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

#73

Post by pjmlp »

mbrumlow wrote: post #60
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…

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…

Same here, just give me a PWA, or if one so insists in using the Web stack for the UI, then deliver the application as a daemon/service that uses whatever is the standard browser.

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

#74

Post by mattnewton »

mbrumlow wrote: post #60
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…

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…

This is more or less how Jupyter notebooks work, and I agree this experience is pretty great. Make it a local web server and the browser becomes your UI.

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

#75

Post by ediardo »

jimmaswell wrote: post #11
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.

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.

And some new CLI programs don't ship with their manpages at all. I've also seen some manpages that don't match the specific version/release of a program installed on the OS.

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

#76

Post by aidenn0 »

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…

For copying files from A to B, I wrote a simple script[1]. rsync is not as universally available on hosts, the tar version is sometimes significantly faster than rsync when just copying, and rsync won't let me triangle-route copies.

https://gist.github.com/jasom/ecdec7767b5f774cd24aebba3c2ba3...

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

#77

Post by rakoo »

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.

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

#78

Post by pandalicious »

mbrumlow wrote: post #60
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…

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?

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

#79

Post by mbrumlow »

mattnewton wrote: post #74
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…

This is more or less how Jupyter notebooks work, and I agree this experience is pretty great. Make it a local web server and the browser becomes your UI.

Like maybe we can build this out. A common daemon for registering with.

The concept would be very simple to build. I might start a github project.

- Global daemon to register apps with. Apps could be installed system wide or per use.

Think plopping a zip/tar/ or directory structure in something like /usr/local/webap.d/(namespace) -- might be abetter directory. Then a manifest file that describes some things about the service, such as how to start the API service, and the default entry point (index.html).

- The global service is responsible for bringing apps on line by way of instance activation on say visiting a name space, or just keep them running.

- Services once launched pick random port from range to bind to and system service acts as a reverse proxy and common auth for validating the local user. Maybe even ensure each of the API services are run per user and jailed to the home directory

IDK, just thinking off the top of my head, I have written bits and pieces of this for various work projects, but never glued the idea into one single system.

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

#80

Post by teknopaul »

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 makes sense, eg edit locally auto push changes, but embeding rsync in an app that does nothing but rsync without any automation or integration options makes no sense to me.

You have to learn a new interface that you cant automate. Its dead end interface. The whole point of cli interfaces is that they are infinitly hackable and pluggable.

Post reply on HN