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

131–138 of 138 posts

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

#131

Post by Izkata »

somacert wrote: post #104
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…

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.

That one is badly phrased, it's about resuming a single interrupted large file. By default rsync will create a new temp file and start over, but there are options to make it resumable.

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

#132

Post by WorldMaker »

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…

Both options for the ribbon still support collapse and auto-hide. It may be confusing that the switch between Simplified and Classic Ribbon is a Caret button that looks like it should handle collapse / auto-hide (but that's still the odd boxed arrow icon in the title bar, right click menu options, and double-click the active tab name).

(Interesting to me is that the Simplified Ribbon in Outlook actually feels more useful to me and less space wasting than its Classic version and I switched my preference in Outlook from collapsed to shown because of it.)

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

#133

Post by mbrumlow »

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?

Good point, at least for the main service app communication. I would still want to maybe be able to reach my computers apps from a remote system.

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

#134

Post by rakoo »

haggy wrote: post #129
rakoo wrote: post #126

Earlier quoted context omitted.

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.

> Ask any 100 people on the street about any industry specific tooling or terms and you're likely to get nothing.

That's exactly my point: rsync is a UNIX-specific tooling, which makes it niche among people who use computers.

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

#135

Post by raghava »

mbrumlow wrote: post #79
mattnewton wrote: post #74

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…

Can containers better fit into this? Will it be better to couple it with a service discovery/publishing too (say consul, to make endpoints of multiple apps easily accessible)?

Is there something that does this already, by any chance? (I might not have come across that!)

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

#136

Post by haggy »

rakoo wrote: post #134
haggy wrote: post #129

Earlier quoted context omitted.

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.

> Ask any 100 people on the street about any industry specific tooling or terms and you're likely to get nothing. That's exactly my point: rsync is a UNIX-specific tooling, which makes it niche among people who use computers.

Your "logic" here (which is probably just trolling) is not worth another response

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

#137

Post by johannes1234321 »

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?

Since requirement was "works with any browser"

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

#138

Post by yjftsjthsd-h »

johannes1234321 wrote: post #137
yjftsjthsd-h wrote: post #128

Earlier quoted context omitted.

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

Since requirement was "works with any browser"

Yeah, but we're just communicating with the local proxy, right? So it'd be browser > HTTP over TCP > proxy > socket > application.
Post reply on HN