[coffeecheque]

I'm a big fan of Fastmail, and I'm tentatively excited about this announcement.

Missing CardDAV/CalDav sync ability is sorely missing, so it's good to see the developers talking about it.

I'd also like to see (and would pay for) options where the data is located in other countries, away from the United States. It's really symbolic, but also practical: I'd like my data closer to where I live.

[josteink]

Seconding this.

Currently I'm fine having that live in owncloud, but should fastmail start supporting it, I may want to sync these data-sets.

Not sure I want to move everything into one place and one place only though. If it was one thing my migration from Google Apps taught me, it was that having too much stuff auto-integrated in one place makes it much harder to have control of your own data.

It severely limits your options to mix and mash best of breed services as you see fit.

[da_n]

How do you find Owncloud, is it reliable enough? I have heard it has a lot of bugs, can be very slow and in rare instances deletes data at random which would be unacceptable to me. I am using Baikal for CardDav and CalDav which has been very reliable so far, and BitTorrent Sync for Dropbox replacement which is less reliable and has some bad bugs (one of which is it being closed source).

[josteink]

How do you find Owncloud, is it reliable enough? I have heard it has a lot of bugs, can be very slow and in rare instances deletes data

Good question.

I have mixed impressions of owncloud so far depending on what area of the product you are using.

The good parts: Contact and calendering managament. Just works. Integrates nicely with Android, Thunderbird, etc. Not very good synching back to Google though. I don't really care about that, but now you know.

The not so good parts: I tried running it on my NAS, because that would be the storage-backend for the file-sync service anyway. I quickly discovered that the code is not near efficient enough to be deployed on underpowered devices like this. It needs optimization, or to be put on proper hardware. I chose the latter and redeployed.

On my NAS, with enough data getting synched across clients could take days. So don't even think about putting this on a Raspberry Pi or something silly like that.

The worse: Using owncloud's files-module as a drop-in Dropbox replacement, you will be surprised by how well supported all kinds of platforms are. If you treat it as a Dropbox replacement though, you will encounter issues.

I tried putting my code/project/build-folders under owncloud and hack away, much like I've done with Dropbox. Even with a limited amount of clients, you will quickly encounter at least some bugs. The most annoying thing I encountered was probably getting conflicts when only one of the clients had updated the file.

The client updated the file, called back to owncloud with the changes, and then got a response back that this update cannot be done cleanly.

It then proceeded to the code/build/project files involved in the conflict and rename the local and the "server"-version to $file.conflict345678543 & $file.conflict1234567 or something to that effect. Needless to say that broke my code, my build and needed to be cleaned up.

If you think that sounds annoying, imagine it happening several times during a 30 minute coding session.

So yeah. The owncloud file-service currently suffers and cannot be treated as a drop-in replacement for Dropbox. Hopefully it will get there, but outside coding, I haven't experienced anything like that and it seems to chug along just fine. With a high CPU-usage though.

So yeah. There are good, not so good and directly bad things about it. If it fits your use-case is up to you.

[da_n]

Thanks for your detailed reply. It pretty much mirrors things I've heard elsewhere, it seems file sync is one issue in particular which can be slow and prone to errors, it is a shame as an all in one solution would be great.

Funnily enough I have both Baikal and BitTorrent Sync running on a Raspberry Pi (model B/512) and it is handling it surprisingly well, I even use it as a destination backup server for some VPS's and local computers (using duplicity). I just wish the Pi had more RAM as BTSync is a bit of a memory (and CPU) hog when you start to hae a lot of files involved, it is under strain. My compromise has been to tar a lot of folders I rarely access to cut down the number of individual files it needs to track, not ideal. I was thinking of buying one of the Intel Next Unit of Computing I think it is called, which is more powerful but still power effecient enough to be left on 24/7.

[sigkill]

A question re: BTSync/RPi - I've got around 40-50 gigs synced up between my x86-64 computers (might be on the order of fifty thousand plus files) and the maximum memory it occupies is around 60-70 megs. It idles at 42MB. Since you already have the set up that I am looking into, I think you're the right person to ask, can the RPi handle that much? If not, what are the signs of it slowing down? If it helps, my hypothetical RPi would be connected via wires instead of USB-Wifi dongle.

[da_n]

Looking at it, I have about 10k files and it is only using about 12% memory, perhaps not as bad as I thought. 50k should be absolutely fine I would think. Here is the output of top showing btsync at idle:

    PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
    2993 btsync    19  -1  122m  60m 2988 S  11.9 12.4 610:05.84 btsync

I have noticed that the CPU takes a beating during any sync operations, tends to grab 100%. I limit the CPU for the btsync process to 60% max and also overclocked the Pi up one level (after installing a heatsink kit). Here it is during typical filesync operations:

    PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
    2993 btsync    19  -1  122m  60m 2988 S  63.8 12.4 612:51.33 btsync

To limit the cpu I use cpulimit and put this in my /etc/rc.local

    /usr/bin/cpulimit -e btsync -l 60 -b >> /dev/null