[HN Gopher] Broccoli: Syncing faster by syncing less (2020)
___________________________________________________________________
Broccoli: Syncing faster by syncing less (2020)
Author : KubikPixel
Score : 59 points
Date : 2021-12-12 11:53 UTC (11 hours ago)
(HTM) web link (dropbox.tech)
(TXT) w3m dump (dropbox.tech)
| jeffybefffy519 wrote:
| Why cant you guys enable multiple account sign ins from the one
| dropbox client. So annoying.
| QuadrupleA wrote:
| All this talk of efficiency, yet the Dropbox windows client is
| such a bloated multi-process memory hog of a mess that I ended up
| uninstalling it and rigging my own sync with a command line tool
| (dbxcli), with about 1000x less resource usage.
|
| For all this attention to saving their server's resources they
| sure don't seem to care much about wasting their customers'.
| howdydoo wrote:
| This is classic.
|
| "We spent $x million developing a compression algorithm in Rust
| to slightly speed up a background process in our bloated
| Electron app!"
| FractalHQ wrote:
| With so many Rust engineers, they could get rid of all that
| Electron bloat with the Rust-based electron alternative,
| Tauri.
| hedgehog wrote:
| The Electron app wouldn't be an issue if it didn't churn away
| uselessly even when Dropbox is in the background. The company
| doesn't care though, their advice was to open a topic in the
| support forum, to which their response is "This idea will
| need some more support before we can share it with the team."
| You can lead a horse to water.
| Dangcancer wrote:
| Drop-dropbox.com
|
| If you flag this you deserve to be waterboarded
| [deleted]
| davidjade wrote:
| I really wish this idea had become more widespread. Microsoft
| Research published this 15 years ago. It shipped as part of
| windows but the paper describes it in enough detail to implement
| it I think. I got it running years ago and it seemed to work
| really well.
|
| https://www.microsoft.com/en-us/research/wp-content/uploads/...
| irq-1 wrote:
| Interesting. Looks like Windows does use it the Distributed
| File System Replication (DFSR) service.
|
| https://docs.microsoft.com/en-us/previous-versions/windows/d...
| jsnell wrote:
| Discussion from a year ago:
| https://news.ycombinator.com/item?id=24052002
| donatj wrote:
| > Rolling out the above changes went relatively smoothly until
| one of the curious engineers on our network team found that
| compression was actually a bottleneck on high bandwidth
| connections
|
| Back in the early-to-mid-aughts there was a push to start gzip-
| ing server responses.
|
| It was my general experience at the time that this actually often
| made the browsing experience worse. Whereas without compression
| the page would begin to render as the html began to trickle in
| (very slow internet back then), when compressed you had to wait
| for the entire document to download and be decomposed first.
|
| Uncompressed you could often decide if the page was worth waiting
| for entirely before it finished downloading.
| gampu wrote:
| Not sure how compression was a bottleneck on the high bandwidth
| connections? I understand @donatj's comments about having to
| wait for the entire file to be downloaded before rendering, but
| that would be a user experience issue, not sure how the network
| team sees it as a bottleneck on the network?
| kevinday wrote:
| HTTP requires that the length of the content be sent before
| the content, so that pipelined connections know where the
| data ends and the next headers start. If you're sending a
| file directly off disk you know the size before you've even
| looked at the data so there's no delay. If you're running
| everything through gzip, you have to wait to compress the
| entire file before you know the output length, so the
| critical "time to first byte" metric could get much worse.
| There are similar issues with dynamic content (CGI scripts,
| PHP, etc) where both the server and browser would end up
| buffering large amounts of content before
| compressing/decompressing them, which also affected
| perceptual speed. If the connection bandwidth was high
| enough, skipping all of this and just sending the
| uncompressed file would appear faster to the user, despite
| transferring more.
|
| This was later improved with things like chunked encoding and
| caching the compressed output on the server side, but they
| came later and weren't always supported or desirable.
| tshaddox wrote:
| I assume they meant that the network could move bytes faster
| than the CPU could compress them.
| davidmurdoch wrote:
| Gzip is streamable (windowed), so perhaps it was the extra CPU
| cycles that caused the slow down, misconfigured gzip, or just
| incomplete gzip implementations?
| ChrisArchitect wrote:
| What is new here from the conversation a year ago when this was
| new.
|
| https://news.ycombinator.com/item?id=24052002
| Dangcancer wrote:
| Dropbox is a fascist organization with Condoleeza Rice (a
| torturer and war criminal) on their board. How does anyone work
| there in good conscience?
|
| Drop-dropbox.com
| samhwr wrote:
| This is nothing to do with what the word 'fascist' means.
| 'Imperialist' would at least be intelligible as a descriptor.
| 'War criminal and torturer' I don't necessarily disagree with.
| 'Fascist' has a more specific meaning than 'someone nasty and
| right-wing whom I dislike' (which last descriptor I would
| _also_ agree with).
| gigatexal wrote:
| As long as this makes the client on Mac use less resources than a
| fork bomb I'm all for it.
| Eric_WVGG wrote:
| It doesn't, the client code is still a dumpster file.
|
| Give Mistrael a look. Anecdotally ~7x less RAM, ~10x less disk
| space. https://maestral.app
| rkagerer wrote:
| Is there anything like this for Windows?
___________________________________________________________________
(page generated 2021-12-12 23:01 UTC)