SparkleShare 1.0 released

[Posted December 10, 2012 by corbet]

Version 1.0 of the SparkleShare network-shared folder system has been announced. "SparkleShare uses the version control system Git under the hood, so people collaborating on projects can make use of existing infrastructure, and setting up a host yourself will be easy enough. Using your own host gives you more privacy and control, as well as lots of cheap storage space and higher transfer speeds." LWN last reviewed SparkleShare in 2010.

to post comments

SparkleShare 1.0 released

Posted Dec 10, 2012 15:03 UTC (Mon) by oever (guest, #987) [Link] (2 responses)

The idea of using Git for syncing document is great. For large files, bup could be used.

A quick test shows that dazzle setup needs root access to run. This is quite a hurdle for the average user.

There are no clients for mobile operating systems yet, but I guess this in the works. OwnCloud already has these. In addition, it would be great to be able to hand out URLs to folders or files.

SparkleShare 1.0 released

Posted Dec 10, 2012 15:40 UTC (Mon) by alogghe (subscriber, #6661) [Link] (1 responses)

Actually there is an Android Sparkleshare client.

SparkleShare 1.0 released

Posted Dec 10, 2012 16:25 UTC (Mon) by oever (guest, #987) [Link]

Indeed, there is.

SparkleShare 1.0 released

Posted Dec 10, 2012 15:50 UTC (Mon) by littlesandra88 (guest, #64017) [Link] (4 responses)

If it doesn't get Escrow passphrases, then it can not be used for enterprise.

This is a big problem for OSS full disk encryption. Non have this feature.

SparkleShare 1.0 released

Posted Dec 10, 2012 16:00 UTC (Mon) by cesarb (subscriber, #6266) [Link]

At least LUKS can have multiple keys (cryptsetup luksAddKey). You could use one slot for day-to-day use and another slot for a passphrase kept on a safe somewhere, or you could use one slot per person so multiple people could decrypt the disk without knowing each other's passphrase.

SparkleShare 1.0 released

Posted Dec 10, 2012 16:00 UTC (Mon) by josh (subscriber, #17465) [Link]

Not all enterprises require that "feature"; many use full disk encryption without it.

Also, LUKS has the option of multiple independent passphrases for the same encrypted device, so an enterprise installation of it could easily set a backdoor passphrase in one of the secondary passphrase slots.

SparkleShare 1.0 released

Posted Dec 11, 2012 13:38 UTC (Tue) by ekj (guest, #1524) [Link] (1 responses)

That -entirely- is in the "it depends" category. We use full-disc-encryption primarily for added security in the case of stolen and/or misplaced laptops.

There's no escrow of the passphrases - but this is not show-stopper because we've got unencrypted backups of the content. Yes, this means that a forgotten passphrase is now a problem almost on par with a crashed hard-drive. (I say almost because no replacement hardware is needed)

But all companies are (or should be!) equipped to deal with a broken hard-drive anyway. Why is "hard-drive cannot be read because hardware is broken" acceptable in a company while "hard-drive cannot be read because the passphrase is unknown" unacceptable ? The consequences of the two situations are after all pretty close to identical.

SparkleShare 1.0 released

Posted Dec 11, 2012 14:09 UTC (Tue) by dlang (guest, #313) [Link]

> Why is "hard-drive cannot be read because hardware is broken" acceptable in a company while "hard-drive cannot be read because the passphrase is unknown" unacceptable ? The consequences of the two situations are after all pretty close to identical.

the impact is about the same, but the probability that people will forget their passphrase is higher, so the resulting risk (probability * impact) is significantly higher.

It also turns the 'hit by a bus' scenario into the equivalent of a failed drive, and at that point you cannot ask the person to recreate the data from memory.

Plus you can blame the failed disk on the hardware manufacturer and everyone accepts that such things happen. Having the hardware in perfect shape, but you just can't get at the data is clearly the fault of either the user or the IT staff, and what users are willing to accept the blame for loosing their non-backed up data (local spreadsheets, etc), especially among higher level management.

So higher risk + social aspects make the key escrow option very attractive.

On top of this, in many fields where there are security concerns, one of the concerns is the rogue insider 'doing bad things'. It's very hard to investigate this if you can't access the drive

SparkleShare 1.0 released

Posted Dec 10, 2012 16:25 UTC (Mon) by epa (subscriber, #39769) [Link]

Is there a business offering a paid SparkleShare service, a la Dropbox?

SparkleShare 1.0 released

Posted Dec 10, 2012 16:53 UTC (Mon) by xxiao (guest, #9631) [Link] (3 responses)

Will git ever be able to handle binary files in a saner way? git annex helps, still would prefer git has something built-in for binary files(all sizes).

SparkleShare 1.0 released

Posted Dec 10, 2012 18:00 UTC (Mon) by oever (guest, #987) [Link] (2 responses)

How sane do you want it? You can commit binary files and this was possible from the first version of git. git-annex moves the big files out of the git repository. This simply complicates things, since now your files are spread over two systems. If you are afraid that the repository will grow too large, then you can use a shallow checkout 'git clone --depth 1' or truncate the history of a repository.

The project bup deals with large files more efficiently and uses the same pack format as git with an extension (new blob type) that stores fragments of files instead of whole files. By using a rolling checksum algorithm, there is a lot of overlap in fragments for similar files.

SparkleShare 1.0 released

Posted Dec 11, 2012 17:22 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

> How sane do you want it?

People probably expect it to work properly and 'do the right thing' with no manual intervention.

That is if they accidentally drag-n-drop a 5GB movie file to the sparkle client and don't notice that it took a few hours to upload they should be able to delete it or just leave it there without degradation in performance or git massively inflating the size of the repository to 10 or 15G when moving it around.

SparkleShare 1.0 released

Posted Dec 13, 2012 8:36 UTC (Thu) by oever (guest, #987) [Link]

In the plain git implementation, if you add a 5GB file to git it will take some time to add it as git blob to the .git directory. It will be gzipped but since large files tend to be binary, it will still take up almost 5GB. That means that by simply adding the file to git, the disk usage is doubled. This is the only way which allows a user to restore the file even if the computer is offline.

If the file system implements copy-on-write, then it is possible to keep a spare copy of the file relatively cheaply, however, git does not take advantage of that. On Linux, copy-on-write systems are common yet. Nevertheless, an optimization in git could be to keep large files unaltered in the .git repository with a side-car file.

The git repository will not inflate in size when moving the 5GB file around. But every time the file changes, then the storage requirement will grow by 5GB. Luckily large user files are usually media files and these do not change a lot. Using git for video or audio editing data is not a good idea. I have no idea how e.g. Box or Dropbox will deal with such data.

SparkleShare 1.0 released

Posted Dec 10, 2012 19:44 UTC (Mon) by atai (subscriber, #10977) [Link]

This is written in C#, and uses Mono (at least on GNU/Linux).

Should be possible to port the source to Vala and just requires the basic glib stack?

SparkleShare 1.0 released

Posted Dec 20, 2012 14:09 UTC (Thu) by Velmont (guest, #46433) [Link] (1 responses)

Every Sparkleshare article needs a "that's nice, but people should really take a look at Unison if you want to sync files between computers" comment (I've done most of them on LWN).

So here it is :-)

Unison is much more flexible, and actually made for that purpose. Using git as backend adds a few problems that Unison doesn't have.

"Share" is the important part of SparkleShare, it's more for "many people using the same files", than for moving your own files onto 10 computers and have it all synced up to your main server at all times. So I guess you could quickly use both.

Unison

Posted Dec 20, 2012 17:11 UTC (Thu) by jch (guest, #51929) [Link]

> people should really take a look at Unison

http://www.cis.upenn.edu/~bcpierce/unison/

> Unison is much more flexible, and actually made for that purpose.

Yep. Unison supports arbitrary peer-to-peer synchronisation rather than just the client-server model, which is really nice when the server is down, or when the clients are connected by a fast Ethernet that's behind a slow ADSL. Or when you don't want to setup a server in the first place.

The issue with Unison, however, is that it's an interactive tool rather than a daemon -- having your hosts synchronise automatically requires setting up a cron job. Many people prefer the automated setup of the commercial tools

--jch