Live data from Hacker News

BitTorrent’s Secure Dropbox Alternative Goes Public

torrentfreak.com

261–270 of 291 posts

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#261
post #252

Earlier quoted context omitted.

For the reasons that you've specified and others, I rolled my own very simple sync system based on Git. The biggest problem I personally have with Dropbbox et. al, is that none of the commercial solutions sync symbolic links opaquely . ("Opaque" syncing of symlinks means to sync the links themselves and not what the symlinks link to.) I use symlinks heavily and so I absolutely require this feature. Most of the commer…

> The biggest problem I personally have with Dropbbox et. al, is that none of the commercial solutions sync symbolic links opaquely The tradeoff is to have all your stuff in one place, with is not a good thing most of the time IMO. A frequent problem I stumble on: there is a work folder where everything is already on svn/git, but I'd want to temporarily sync a few folders to dropbox only when needed, and get them out…

> If dropbox had support for arbitrary multiple folder selection (but the the complexity would go way up?) I'd agree with your stance on symlink, but now this is more of a necessary evil.

I think you already answered your own objection on the right way to handle this need. Other syncing services, including BitTorrent Sync handle your need in precisely this manner. I.e., the right way. Dangerous, frustrating, and incorrect abuse of symlinks is NOT the right way to do this.

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#262
Instead of private (darknet) bittorrenting I'd rather have a solution for all those files with few seeders who are half dead, in the cloud. It's easy to torrent the latest episode. Everyone is in on that. But what about the long tail? We need a different scheme there.

My idea would be to lump together all the files in a huge torrent. That would inevitably attract many peers, so the problem would be solved if users did selective downloading, as the whole would be too large for any one of them.

The system would need to use some disk space and bandwidth from each peer to host some shards of the whole. Not all the data in the mega-torrent would be downloaded, just some sensible section of it, like, say, 5GB. Between 1000 users, we could have 1TB of files. With a million, we could have a huge library. This way we could have enough seeds for any part of the whole. Of course, it would need a way to add new stuff on the fly and balance the replicas.

tl;dr - I'd rather have a solution for rare torrents. I'm worried for all the content that is not "hot enough". We could amass a huge library of rare stuff, in time.

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#263
post #98

Earlier quoted context omitted.

> And consumers are not thinking in terms of encrypted sync, they're just thinking in terms of "I just want to do X, why is it so hard", and so I can't see this (very nice) solution really solving the problems that consumers have, that will make them prioritise security. I have a use case that is pretty common among my peer group and BT Sync has been the best solution I've been able to find. In a nutshell, I need to…

> rsync/duplicity/unison: needs extra logic for detecting file changes Is it so difficult to add a one line configuration item to your inotify cron daemon (incrond) ? /home/my/directory IN_CLOSE_WRITE,IN_CREATE,IN_DELETE /my/unison/sync/script.sh It works.

Not on a mac. There is FSEvent, but it doesn't recurse down directory trees,

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#264
Finally! I was trying to get something like this made 6-7 years ago for distributing CRL's. I'm glad to see it's up and running, now all I need is a buddy to test this out with.

edit: The UX needs a bit of polishing. I don't think my Mom is going to be able to figure this out.

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#265
post #102

Earlier quoted context omitted.

Sharing photos was solved for the 99% by Facebook & Apple & Google. If you're a photographer with gobs of high resolution photos Dropbox is perfect for you, but I imagine that is a niche pain point. What is a much bigger opportunity is a way that easily lets groups share music and movies. This cannot be solved by a centralized service like Dropbox for legal reasons. This is what would concern me if I was Dropbox; BTS…

You can auto-sync high-res photos in Google+, too, but it ounts in the 5 GB free storage you have.

The killer feature for me with Google+ is Google Picasa. The fact that I can choose which of the zillions of photos are my favorites and only sync those to Google+, and then share them with my friends and family is awesome. Dropbox is missing the photo application on the user's computer.

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#266

Earlier quoted context omitted.

It would look like any other encrypted information, but I'm unsure that the traffic patterns themselves wouldn't be distinctive.

Not the point of the use-case. And obviously Tor could be added to the mix.

I'm unsure that Tor networks are viable in the long term for the same reason - they're subject to traffic analysis. Japan's police have been asking for Tor networks to be blocked over there: http://www.bbc.co.uk/news/technology-22248692

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#267
post #244

Earlier quoted context omitted.

No human is looking inside. Files are simply security scanned and assigned a probability of breaking the TOS.

> No human is looking inside Where's the relevance? I asked why is Google , the entity, looking inside of private files? > a probability of breaking the TOS And my question was, if the files are private, why should their content be against the TOS? Also, locking somebody out of their account because of a probability generated by a script, without manual confirmation by a human? OMG. Some people can lose their jobs or…

Seems like it would've been best handled by an advance warning system, i.e., at least a few days or a week's notice that you're violating their TOS and need to take action.

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#268

Earlier quoted context omitted.

> You are right: Dropbox's behavior with regard to symlinks is fundamentally wrong. What's even worse, is that no matter how hard I try, I am not able to convince most people of how wrong this is--even those who claim to be and should be computer savy. E.g., on support forums for other sync services, users are typically clamoring for Dropbox-style syncing of symlinks, and they will not be convinced otherwise, in spit…

Yeah but the real problem, the ones users are trying to solve is the limits on having to move everything into one sync folder. Transparent symlinks are the cheap fix for them so that they can keep their files where they want and still have them sync. The better solution would be to just allow any folder(s) to be synced but none of the major cloud sync providers seem to want to enable that.

> The better solution would be to just allow any folder(s) to be synced but none of the major cloud sync providers seem to want to enable that.

This correct solution is precisely what BitTorrent Sync provides. So that's all the more reason to be thankful that a seemingly excellent sync solution has finally arrived.

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#269

Earlier quoted context omitted.

What does Dropbox do in the case of a symlink circular reference?

I can answer this question since I accidentally created a circular reference the other day. It starts syncing the recursive structure until it runs out of quota.

> It starts syncing the recursive structure until it runs out of quota.

I was curious about this myself, but I never tried it, as I feared that this was precisely the badness that would occur.

Dropbox is so good in so many respects, I just can't understand how they could have made such an utterly terrible and wrong decision on this particular issue.

Re: BitTorrent’s Secure Dropbox Alternative Goes Public

#270

Earlier quoted context omitted.

> I used to use Flickr for photo sharing, but cameras got better, images got bigger, and I have a lot of photos. Why is this a problem with Flickr? I am generally shooting high res full frame, and post to Flickr. I have about a terabyte of images. There's no 100GB storage limit, just an annual flat fee. Family can download full resolution images for printing. My grandmother can have my Flickr Photo Stream as a screen…

> I also enjoy fantastic two way integration with photo management tools, with tagging syncing back. Which photo management tools do you use? I currently have around 45k photos (~200GB) and Picasa is sometimes just too slow. I am planning to get a DSLR soon, so total size is going to be expanding rapidly. What kind of tools would you suggest? I am on Windows mainly, so Mac-only is not an option. Thanks!

> Which photo management tools do you use?

Some detail for you:

I use Aperture for most photos. I use Lightroom for slides. On the PC side, you should use Lightroom. It's just gone into beta for version 5, try it now for free.

I strongly prefer the Aperture workflow, but for slides Aperture won't recognize my 64 bit .DNG files with infrared channel as being part of a JPEG/RAW pair, while Lightroom will.

I manage photos on the latest Mac Mini with the Fusion Drive, but the photo libraries are actually stored on Western Digital MyBook Velociraptor Duo Thunderbolt drives[1] which are insanely fast in RAID0 mode. With Thunderbolt I can attach that to a laptop or the Mac Mini and Aperture is licensed for 5 computers. I had been using the built in Fusion drive for my latest project triage, but the Velociraptor drives in RAID0 are so fast it's not worth the hassle of splitting that out.

I use a nightly rsync to replicate the libraries onto a LaCie 4big via Firewire 800. I never have less than two copies of photos on two devices, because I use a Nexto DI[2] to import the photos from flash while on the go, then I import from that into my libraries, leaving copies on it until I need space. Or, for things like iPhone imports, I import to the LaCie RAID, then import into Aperture's RAID0 library for speed, and again, only delete from the RAIDs when I need space and after I know Aperture's backed up. I also have a Backblaze[5] job backing up everything offsite for their flat fee.

I have three libraries, one for 2000-2010, one for the current decade, and one for international travel. While travel is less frequent, a trip generates more photos, so my domestic and international libraries tend to be similar in size. Each is 50K to 150K photos, and in the 350GB - 750GB range.

I use Aperture's library in the fully imported mode, where photos are stored in the library. This way I'll never accidentally move or delete a photo I want to keep. Of course, the library is just a package folder, you can CTRL-Click it to open it up and get at any of your import sessions original or raw files. Even if the DB is completely destroyed, the photos are safe.

I use the incredible Nik Collection of plugins. They were worth it at $750, and so much more worth it at Google's new price of $149[3]. These plugins work with Lightroom or Photoshop as well.

With over a decade of DSLR photos under management, I recommend you use a folder and image naming scheme like this:

    yyyy
      yyyy-mm-dd event descriptor
        Event Descriptor (nnn).ext
If I'm using generic file system tools rather than a true photo management app, I name the file in a way that lets me search, sort, and reconstruct the original file, regardless of file system capabilities:

        yyyy-mm-dd hh.mm.ss event descriptor nnn (ORIGINAL-FILENAME).ext
Moving images around across file systems will likely eventually lose the date, with this you can use a simple shell script to put back the create time. Or use ExifTool to get the data back from inside the file[4].

---

Links referenced:

1. http://www.storagereview.com/western_digital_my_book_velocir...

2. http://www.amazon.com/Nexto-Digital-Photo-Storage-ND2730/dp/...

3. http://www.niksoftware.com/

4. http://www.sno.phy.queensu.ca/~phil/exiftool/

5. http://www.backblaze.com

Post reply on HN