41–50 of 138 posts
I'm weary of this "electron" thing though. Do I have to download a 500mb package to run this?
> 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…
I would think there maybe a "command-line" version of GUI design: supply limited default buttons for common options, but allow user customization. For example, I would love to have the button from author's design but tune it specifically to my need including running a specific set of "command lines".
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.
> 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…
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.
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 like using man the best, but there are two other methods that command-line programs can use to provide documentation, GNU's info and built in help (triggered by -h or --help on command-line).
GNU's info works better than man for more complex documentation--its practically a curses based e-book reader. For a taste of using info based documentation, try
info spell
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 features with tools such as configuration management packages (CVS, PRCS, Subversion, BitKeeper, etc.), distributed filesystems (Coda, etc.), uni-directional mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc). However, there are several points where it differs: ...
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.
The real advantage of CLI is that it is a language, not just a UI. It is composable, programable, remote-able and easier to automate.
> 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…
What is simple in rsync is the idea of synchronising stuff from A to B. That is all it does in all the cases you mentioned. It is hard to emulate what rsync does with archive mode enabled, which speeds up transfers, so tar isn't exactly a replacement for rsync. There are better ways to show progress, for example using the flag `--info=progress2`. It doesn't behave well in automated scripts though
Keep in mind however that the format of --progress has changed in the past. Depending on your version of rsync it may or may not insert thousand seperating commas into the number of bytes written, e.g. 2,384,908 vs 2384908. The former can be supressed with --no-h, an option not available on at least some older versions of rsync that default to no commas.
Earlier quoted context omitted.
not super relevant here, but for those interested. There is a cli tool called `tldr` that takes in the name (of a tool) and prints out common usages.
I'm a big fan of this. Probably 90% of the time the tldr summary has my use-case covered.
Assuming all else to be equal (UX, functionality, etc), people will absolutely gravitate towards the [5MB storage, 20MB RAM, 0.5% CPU] combination to electron's [300MB storage, 200MB RAM, 5% CPU], especially when they are running multiple such programs.
But, what electron offers is getting from zero to product across all desktop OS-es in arguably the least time possible. So, the real choice is between [PRODUCT_NO_SHIP] to [300MB storage, 200MB RAM, 5% CPU], and we all know what the world chose.