Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dropbox will kill your insane MacBook Air 2013 battery

blog.nicoschuele.com

Post reply on HN
Print view View original

71–80 of 111 posts

Re: Dropbox will kill your insane MacBook Air 2013 battery

#71

Post by timtadh »

jwr wrote: post #64
davedx wrote: post #38

Earlier quoted context omitted.

> And to everyone that says you should not store code in dropbox: a) there are good and legitimate reasons for doing so I'm genuinely curious: why do this, as opposed to using a DVCS like git?

I do use git. But I often develop on two machines: a laptop and a Mac Pro. Which means I am often in the middle of something when I have to just pick up the laptop and go. "In the middle of something" means that just pushing commits over doesn't cut it. I can (and do) rsync stuff over, but that is annoying and very error-prone (it's too easy to sync stuff the other way around and lose work). I guess you could say Dro…

I don't understand. You can easily cut a branch commit. Push the branch. Pull the branch finish it. Commit. (optionally rebase). Delete the temporary branch. Git handles this problem very well.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#73

Post by StavrosK »

jwr wrote: post #64
davedx wrote: post #38

Earlier quoted context omitted.

> And to everyone that says you should not store code in dropbox: a) there are good and legitimate reasons for doing so I'm genuinely curious: why do this, as opposed to using a DVCS like git?

I do use git. But I often develop on two machines: a laptop and a Mac Pro. Which means I am often in the middle of something when I have to just pick up the laptop and go. "In the middle of something" means that just pushing commits over doesn't cut it. I can (and do) rsync stuff over, but that is annoying and very error-prone (it's too easy to sync stuff the other way around and lose work). I guess you could say Dro…

My use case: The "extras" (files not in the DVCS like libraries, dependencies, etc) are just as important for working, but they take too long to transfer/update from one PC to the other, especially for things like GAE which don't have easy ways to manage.

Dropbox could help there, but it does not.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#74

Post by demallien »

nicoschuele wrote: post #41
cnvogel wrote: post #8

That finding might be quite interesting and all... but I'm thoroughly confused about that guy always quoting power consumption in mAh (which is the unit for electrica charge). I'd also check if that guy's dropbox daemon(s) are stuck in an obvious loop. I'm logged on in my private server, and when it's idle there's hardly any activity on the dropbox threads, the main CPU consumer is one servicing what I suspect to be…

Thanks for pointing this out. It's a typo, I meant mA, not mAh. Fixed.

No, that is not a typo. Thos is a typo - an error created during the mechanical act of typing. Yours was just a plain mistake, you got the units wrong. Own it and learn from the error instead of excusing it away.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#75

Post by jasonlotito »

timtadh wrote: post #71
jwr wrote: post #64

Earlier quoted context omitted.

I do use git. But I often develop on two machines: a laptop and a Mac Pro. Which means I am often in the middle of something when I have to just pick up the laptop and go. "In the middle of something" means that just pushing commits over doesn't cut it. I can (and do) rsync stuff over, but that is annoying and very error-prone (it's too easy to sync stuff the other way around and lose work). I guess you could say Dro…

I don't understand. You can easily cut a branch commit. Push the branch. Pull the branch finish it. Commit. (optionally rebase). Delete the temporary branch. Git handles this problem very well.

You don't understand or you didn't spend ti e thinking about that. It's doing all those steps, or doing nothing and achieving the same result. Not sure what you don't understand.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#76

Post by Osmium »

I switched from Dropbox to SpiderOak recently, and they're a bit better, but feels so clunky. I'm just about fed up with all of them. I use CrashPlan for backups and they're at least good for CPU usage because they have a preference -- max CPU (%) when you're at the computer, and max CPU when you're away, which really does help.

Those who are using Dropbox may find something like cpulimit[1] useful. This limits the CPU usage of any process by repeatedly sending SIGSTOP and SIGCONT signals to your process. It's on homebrew for OS X. I think there're some other alternatives available too but can't remember off hand. But if the article's accurate, Dropbox has issues even when it's not indexing heavily.

[1] https://github.com/opsengine/cpulimit

Re: Dropbox will kill your insane MacBook Air 2013 battery

#77

Post by Osmium »

aidos wrote: post #54
andor wrote: post #46

Earlier quoted context omitted.

Every modern operating system has inotify-like capabilities. Mac OS has an integrated desktop search since 2005, which wouldn't be feasible without filesystem events.

Dropbox has its own process though, doesn't it? dbfseventsd. sudo fs_usage -w I've been watching it recently and it seems to touch files that it shouldn't need to. I need to do more investigation. I uninstalled backblaze recently because I discovered that it manually scans the whole filesystem _all the time_.

Thanks for the Backblaze info! That's really good to know. Do you know if CrashPlan is any saner? Resource usage was a big factor when deciding between the two, and I want to know if I've made the right choice :)

Re: Dropbox will kill your insane MacBook Air 2013 battery

#78

Post by hnha »

wslh wrote: post #65
jwr wrote: post #28

Dropbox is terrible with CPU usage. This is something I reported to them several times, but it seems they don't really care. Last I tested, Dropbox consumed CPU for ANY changes ANYWHERE in your filesystem, not just within the Dropbox folder. So its (slow) code processed changes even when you untarred a large set of files somewhere in /tmp. I also stopped using Dropbox for storing my code because of that — it's nearly…

So, we need a per application battery usage indicator? Surely this application exists.

on Linux there is powertop, awesome piece of libre software by Intel

Re: Dropbox will kill your insane MacBook Air 2013 battery

#79

Post by 501 »

SurfScore wrote: post #68
fredoliveira wrote: post #63

Earlier quoted context omitted.

Xcode has built-in git support which you should use.

I'm talking weird glitches like a nib gets corrupted and I've made enough changes to matter but haven't committed anything yet

That sort of glitch sounds like the kind of thing Dropbox does (did?) from time to time because it's not aware of bundles. (For those unaware, on OS X many files are actually folders, eg: http://en.wikipedia.org/wiki/Rich_Text_Format_Directory)

Re: Dropbox will kill your insane MacBook Air 2013 battery

#80

Post by cnvogel »

InclinedPlane wrote: post #14
bherms wrote: post #11

I had this happen in the past too and found it to be the result of two issues: 1) Using dropbox to house a very large git repo with massive changes and tons of branches... Every time I switched branches, the hundreds of files would change and obviously kick off a major sync job. 2) There were a few files in a folder than had the owner set to the wrong owner and Dropbox couldn't get permission to access them. This cau…

Try this: separate out the git directory from the working directory so that the working directory is not in dropbox but the git directory is. That might solve some of your problems. E.g.: git --git-dir=/home/me/dropbox/git/proj --work-tree=/home/me/proj init

(1) you can also use the GIT_DIR environment variable, which might save some typing during development

(2) another solution is to just clone the bare repository in Dropbox to a temp-directory, work there, and push the changes back to the Dropbox'ed repo. Saves you the effort to specify GIT_DIR or --git-dir all the time and is the saner approach if you have to switch back and forth between different repos.

    $ GIT_DIR=~/Dropbox/my_repo git init --bare
    Initialized empty Git repository in /home/chris/Dropbox/my_repo/

    $ git clone ~/Dropbox/my_repo
    Initialized empty Git repository in /home/chris/my_repo/.git/
    warning: You appear to have cloned an empty repository.

    $ cd my_repo ; touch README
    $ git add README ; git commit -m "README" ; git push origin master
    [master (root-commit) ada37ca] README
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 README
    Counting objects: 3, done.
    Writing objects: 100% (3/3), 213 bytes, done.
    Total 3 (delta 0), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    To /home/chris/Dropbox/my_repo
     * [new branch]      master -> master
Post reply on HN