Earlier quoted context omitted.
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.
> Your "piped tar" doesn't cover the main use case of rsync, which is (unsurprisingly), remote file hierarchy sync'ing. 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.
Rsync, GUIs, power, control, design, and decisions
111–120 of 138 posts
Re: Rsync, GUIs, power, control, design, and decisions
#112If 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…
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 have a WIMP GUI and a console one. One does not preclude the other. I think you are right that embedding rsync in a more narrowly focused app might be the best option but it is not the only way.
Re: Rsync, GUIs, power, control, design, and decisions
#113Earlier 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.
Re: Rsync, GUIs, power, control, design, and decisions
#114Earlier quoted context omitted.
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…
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…
Re: Rsync, GUIs, power, control, design, and decisions
#115Earlier 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
Re: Rsync, GUIs, power, control, design, and decisions
#116Great 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
#117Earlier quoted context omitted.
I think I would mind //graphical menus// less than the change to an always in your face ribbon. What I loved most about the seriously ancient UIs, way back in the Win 3.x days and forward, was that not only were the options categorized, they also had prominently displayed (right justified instead of left) the keyboard shortcut you could memorize if you knew you were doing it frequently. Yes, that sort of still exists…
> 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…
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 follow suit.
Re: Rsync, GUIs, power, control, design, and decisions
#118Wait, this is a parody, right?
Re: Rsync, GUIs, power, control, design, and decisions
#119Re: Rsync, GUIs, power, control, design, and decisions
#120'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.
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 you can see why they'd all benefit from it.