Live data from Hacker News

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

bits.ashleyblewer.com

101–110 of 138 posts

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

#101

Earlier quoted context omitted.

In my experience the coverage is shockingly good. And if you find a case where there is no tldr, you're back where you're started having lost not more than five seconds. The failure case is graceful, so it was easy to put tldr into my workflow.

I wonder if tldr returns a meaningful exit value that you could write an alias/function for something like tldr $term || man $term

Definitely; tldr returns 0 on success, 1 on failure.

    tldr_or_man() { tldr $1 || man $1 }

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

#102

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

You can already use node + Carlo if you want something without the browser piece. Of course, then you need to worry about multiple versions of node and the browser, and distribution becomes more of an issue.

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

#103

Earlier quoted context omitted.

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…

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 via a Node server that do all kinds of things.

Some simple port forwarding rules (ymmv) make this available to your LAN or to the WWW. Add a DNS layer on top and you have something really cool.

I do this for all kinds of stuff, mostly PWAs, but it lets me have my own notes, todo, systems management and more.

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

#104

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

The "Does not resume interrupted operations" gripe confuses me because that is the main reason I reach for rsync, I have a large tree of files I need to be somewhere else and if the transfer fails I would like it to not transfer files already transferred.

So I use rsync, which offers, as a core feature, resuming interrupted operation.

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

#105
post #65

Earlier quoted context omitted.

--progress gives you only the progress of individual file transfers.

--info=progress2 actually gives you the progress of the whole transfer (but I don't think you can do both). You can use --info=name0,progress2 if you don't care about individual files scrolling the terminal.

Seems like this user-hostile interface could have been averted if they gave rsync a "porcelain" mode, since --progress is frozen so it doesn't break scripts.

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

#106

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

You can't break out of the sandbox to run shell commands et al from a browser. That's where electron & friends come in.

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

#107

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…

One of the main audiences for this GUI are people who maybe only ever use the CLI once a month/quarter and can’t even remember how to edit mid-line in the terminal. For them this GUI is a great idea.

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

#108
post #65

Earlier quoted context omitted.

--info=progress2 actually gives you the progress of the whole transfer (but I don't think you can do both). You can use --info=name0,progress2 if you don't care about individual files scrolling the terminal.

Seems like this user-hostile interface could have been averted if they gave rsync a "porcelain" mode, since --progress is frozen so it doesn't break scripts.

I think you're really exaggerating the severity of what is fundamentally just a minor matter of personal taste.

(I say this as somebody who's written a GUI wrapper around rsync to, among other things, implement my own progress bar. So I agree with the general principle of writing porcelain around rsync.) (Incidentally --progress has actually changed in a way that breaks (my) scripts in the past; the version that ships with MacOS and the latest version exhibit different behavior by default. It would be nice if there was a better way. If rsync followed the ffmpeg model of foremost being a library with a standard command line interface, I think that could be ideal.)

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

#109
post #99

Earlier quoted context omitted.

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

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, as it is just like menu bars have always worked (Alt+E,C or Alt,E,C for Edit > Copy as opposed to Alt+H,C or Alt,H,C for Home > Copy; and in Office the old menu shortcuts still work to this day if you have muscle memory of them, you just don't get visual feedback).

> 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, but you have to go out of your way to do something extra to see it: these days you have to tap a modifier key while in the focus area of the menu.

In addition to the Alt bubble pop ups, hovering every ribbon command has always provided a tooltip with command name and description and in that tooltip has always shown the most direct shortcut key in bold if there is one. Maybe silly to use the mouse to discover the fastest shortcut, but it's roughly the same discovery process as classic menus. (For instance, Format Painter shows Ctrl+Shift+C and Ctrl+Shift+V as opposed to Alt+H,F,P.)

(Not to mention, Windows stopped showing Menu keys by default way back in Windows 95, and even stopped showing some menus entirely unless Alt was pushed over the years. So the Windows 3.x days where everything always had underlines and macOS-like right-justified keyboard keys were relatively fewer than the many years of push Alt to see keyboard stuff on Windows. The ribbon wasn't a big shift in that department.)

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

#110

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…

Making a GUI around a CLI is like translating a russian, experimental,supposedly untranslatable novel. Sure, it's hard, but there's still people out there wanting to read the book and who could enjoy the result, no matter how imperfect.
Post reply on HN