Hey Google. You should compete with Dropbox.
kent.posterous.com
kent.posterous.com
Edit: Dropbox biggest competition seems to be the shift from file systems to apps. A Google acquisition seems most likely. Personally I think Apple should snap them up for deep integration with iTunes/iOS. It could be a perfect marriage, but it doesn't seem like a very Apple thing to do.
Amazon, you pay for what you use, Dropbox you pay (more than S3) for 50Gb, you use less than that Dropbox make money from you. They also aggressively hash data chucks to avoid storing the same data from different people twice - while charging both of you.
None of this is bad - they have a great product - but it's how they do it.
<edit since i can't reply below - it could have been built on something other than s3 - its the user experience that makes Dropbox so compelling>
I think a better analogy is that you pay more for a simpler and friendlier interface to S3...
So, I think Dropbox is safe from hash collision risks at this point.
If one user uploads a large movie and another goes to upload the same large movie, is the upload nearly instant then as a result? Do they sha1 the file, decide it is the same, and then just make an association that this file is now used by two users?
Apple would make it apple only - which is kind of irrelevent to 99% of people.
Microsoft would just do it sooooo badly.
Well, no. You can upload any document you want on google docs now. And they give API to manipulate, there's a company that offers a dropbox like solution based on this. Google it.
they probably have the best and most advanced implementation out there: www.mesh.com
it does exactly what the guy above describes that he wants from Google, except that it is available now and can also be used as a platform for apps
Your claim seems to be "dropbox is profitable, therefore Google should buy it" - Ben and Jerry's is profitable but I don't see it as a potential Google acquisition.
Dropbox is built for a time when the desktop is still relevant. Google are gearing up to overthrow that paradigm. Dropbox doesn't have a clear link to the web at large, or to search, or to the creation and indexing of content. Those are the attributes I associate with "google acquisition fodder". Compare tineye.
If Google do buy dropbox, it'll be as a talent acquisition and/or so they can leverage the userbase into a chrome OS based solution.
Did that happen?
edit: Just read some of your comment history. So why do you think the offer was made?
edit2: I mean, ok, say I'm google and I'm thinking about buying dropbox:
We can index the user's documents and provide a kick-ass search interface as a product feature, as well as pushing existing products like google docs. Indexing will also feed into advertising across the board, if the user's logged in to their Gbox we can make any adverts they see relevant based on the contents of their own files, which will potentially create an awesome relevance to the user thus increasing CTR and revenue.
I guess that's a pretty convincing argument actually...
Of course, dropbox is most likely going to say thanks but no thanks to these early offers, and the big guys will kick themselves down the road.
The first is open source (librsync) and the third is pretty much a garden-variety hierarchical, AJAX-enabled database browser. You'd have to surmise that companies like Google or Amazon, with so much in-house talent, would be much better off writing the proprietary, closed-source portions from scratch than paying a hefty premium for them on the open market.
So Microsoft has made three attempts to do what Dropbox does and has still not succeeded. I think there's more to it than what you're proposing.
Specifically, I think you're missing key ingredient #5, file conflict resolution.
It was the dropbox of its day. The issues began after Microsoft purchased and then neglected it.
This idea is just so obvious and stupid simple that it boggles the mind that nobody has really done it. You can look at all the major players and they actually all have deliberately crippled half-implementations. For example SkyDrive should be a Dropbox killer, but for inexplicable reasons MS has never made it so you could just 'mount it as a drive' and thus it is nearly entirely useless. The trivial work it would require for MS to do that and the wildly useful properties of having that feature can only mean that MS has deliberately decided to cripple it. Gdocs is the same - in theory you can shove anything into your gdocs account and get it out again. But Google, who could so easily do it have never released a utility to mount that space as storage.
I'm really curious about why every player is half doing this and then stopping short. It can't possibly be that they are all too dumb to see how useful it would be - it can only be that they see significant risks or negative consequences in doing so.
The computing industry, as a whole, is undergoing a massive shift, and I'm afraid that really innovative companies like Dropbox have simply provided the template by which the filesystems of the future will operate.
I was thinking today: If persistent Flash memory has RAM-like characteristics, why are we still treating it like it's a spinning disk? Laptops and mobile devices should have a completely different memory hierarchy:
- Registers
- L1 and L2 cache
- Main Memory
- Persistent Memory
- Cloud Memory
Apple is moving in this direction with their new Macbook Airs, which have taken the first step by taking the MLC Flash chips out of the pointless metal box and placed them on a form factor somewhat like a DIMM. They have moved even further with the iPhone/iPod Touch/iPad. Here, we have computers as powerful as workstations of the mid-1990s, but there is almost no notion of a Disk Drive. Instead, files are organized primarily by the Apps that create and manage them.
My prediction is that Apple is moving toward a world (at least for the average user) where there are only Apps and your data magically takes care of itself.
EDIT: Does anyone else also realize that a big reason our lengthy boot-up procedure even exists is because we had to have a spinning disk? Now that we have RAM-like stuff that's cheap enough to use in spinning-disk quantities, we don't really need the kinds of boot-up procedures we have now.
I'm not sure we are (other than low-level details like how the kernel does I/O scheduling and filesystem implementation details). RAM is transient; SSDs and magnetic disk are both persistent. Hence, both SSDs and magnetic disk can serve as stable storage. SSDs and HDs have different performance characteristics, but I'm not so sure that a radical rethinking of the storage hierarchy is actually called for.
a big reason our lengthy boot-up procedure even exists is because we had to have a spinning disk
Offhand, I would guess that a big reason for lengthy bootups is the time required to probe, detect and configure hardware (plus latency stuff like BIOS init). An intelligent OS will be able to arrange the disk I/O that needs to be done on startup so it is mostly sequential; SSDs and HDs are not significantly different with respect to sequential read performance.
Wow, somehow I missed this fact after 30 years of programming!
both SSDs and magnetic disk can serve as stable storage
Yes, but sometimes a quantitative difference can result in a qualitative one. (Like branching and merging and using historical information in Git. The fact that you can do this so quickly from the local Git repository means you can use it in ways that wouldn't be practical in something like Subversion.)
Offhand, I would guess that a big reason for lengthy bootups is the time required to probe, detect and configure hardware
Why doesn't this apply to hibernating laptops? (Or for that matter, the iPad?) In this day and age, to we always have to turn the power 100% off on a regular basis? Also, there are experimental OS like EROS, where there is no boot-up, only a reactivation of certain facilities like network cards.
The lengthy boot-up process is now living on a set of cultural expectations. There is no longer a technical reason for its existing.
Yay for sarcasm. My point is that changing the performance characteristics of the lower levels of the storage hierarchy does not necessarily mean we need to make radical changes.
The lengthy boot-up process is now living on a set of cultural expectations. There is no longer a technical reason for its existing.
Maybe so; my point was just that I don't see how SSDs vs. magnetic disk fundamentally effect the boot-up process. Hibernation vs. power-off is orthogonal to the type of storage used.
If you just treat the Flash as RAM, with volatile RAM as a very large L3 cache, the notion of hard drive can just disappear. Everything just becomes orthogonally persistent.
I'm guessing this is a troll. Most programmers I talk to in person just get this without so much exposition.
http://code.google.com/apis/storage/
It was presented at Google I/O 2010; though perhaps it didn't make as big a splash considering everything else that was discussed there. Here's the session page on it:
http://www.google.com/events/io/2010/sessions/google-storage...
Then again, I might be mis-understanding what the OP is asking for...
Google seems to be aiming this at enterprise customers looking for essentially a private cloud SAN. Their fees otherwise seem quite high.
Lets compare pricing:
Google: .17/G storage .10/G in .15/G out US/EU .30/G asia
AWS <10TB : .14/G storage .10/G in .15/G out US/EU .20/G out asia
AWS =100TB: .14/G storage .10/G in .07/G out US/EU .11/G out asia
Loss leading CDN: as low as .10/G storage - .01/G in - .01/G out US only (new customers only)
Biggest video CDN =250TB: ??/G storage - .10/G in - .10/G out US ??/G out asia
Managed DFW colo =2TB: 250G storage free - .21/G in - .21/G out worldwide
Carrier hotel rack 100mb/s 1yr: ~.10/G storage ~.06/G in ~.06/G out worldwide - ~.02/G out citywide
Google competes with AWS at the low end but once you scale amazon wins by 50%-66% or more. Akamai beats google by 33% with a sizable commit but that gets you on net at ~1000 edges and a great SLA. Google won't even tell you where your content is - except that it's US only.
I think this is only being marketed at applications like b2b sales force hosting, data heavy scientific apps and enterprise offsite backups. You'd get killed trying to use them for a consumer service. I mean $0.30/GB to .au AND high latency?
The irony is that google's real operating costs are probably the lowest out of any of the players at least for US delivery. Their backbone enjoys tremendous scale based on their search & ad traffic and everyone peers with them.
There's a couple of third parties that integrate with Google Docs, but none of them fit the bill from some quick internal tests. Gladinet - unreliable with certain functions. Insync - still very much "beta" mode; no folders, no business plan options.
I'm using Google Apps in an SMB, and it's great for zero-admin, but downloading attachments to a download folder, finding them again by filename, doing 'save as' to avoid filename collisions so you can save changes, is a total pain in the ass. And we still need a network drive. We still use Google Apps in spite of this but handling file attachments seems unnecessarily difficult. And no, Google Docs is not a solution. Not all attachments are .docs, some of us use CAD files.
Dropbox, fully integrated with Google Apps and Chrome's Downloads folder, would mean the end for millions of intranets.
Google has made a habit of entering new markets with products priced at 0, destroying competition. In classical economics this is called "dumping", and the only reason they can afford it is because of the huge cash cow that is online advertising.
I would much rather have a healthy ecosystem with many smaller companies competing with paid services (you know, paid, with terms of use, support, and all that), than yet another free service from google and works except when it does not and there is no one to turn to in case of trouble.
--
Kent asked “Where’s my G-Drive?” where he pondered what it would be like to have your computer dropboxed (verbing the noun). He went on to dream of a time when your computer was essentially just a thin client connecting to a remote server run by Google, and a all your data was stored there. He listed off some really cool use cases, and then went on to explain why they weren’t a possibility yet. Bandwidth, privacy, space, etc.
But he’s thinking small. He’s also not ignoring some fundamental human concepts, and also why Dropbox is successful.
First, let’s look at why Dropbox is successful: automatic syncing. I can be on my computer, move to my iPhone, and still have all the files. Move to my laptop, and the files are there as well. You can even log onto their website into your account and access your files.
None of this is data backup. It’s all syncing. Once you realize why Dropbox is successful, you realize what you are actually looking for. You are looking for a device that intelligently syncs your data across all your devices without needing to sacrifice bandwidth, eliminating privacy concerns, and not requiring massive amounts of storage.
So, let’s move on, and discover what the service will be that takes the throne.
First, it will focus on syncing intelligently. This doesn’t mean syncing everything all the time, but syncing what you use. There are things my iPhone can’t open that I sync via Dropbox. It’s useless to download this. It’s also useless to sync this over the web when my phone and computer are on the same network. So, the idea is to sync, but only when needed. Sync-on-Read. Bandwidth here is an issue, sure. But only in speed, and frankly, when your living in an era when streaming HD movies is a reality and common place, it’s not a big concern. Let’s just say, Sync-on-Read is no more a problem then the current Sync-on-Save model currently in place. Also, once something is synced, it can be stored locally.
Next, since you only sync when you read, that means you need to connect to machine that holds the data. The downside here is that you need to connect to your home machine to access the data, and the machine needs to be powered on. But, I venture to guess that anyone using a system like this would keep their computers on anyways. After all, a computer shut off can’t sync regardless. Of course, you could also ensure that the system will figure out where it can get the file. If I have a file on multiple machines, and the main machine is off, the software can still grab the data.
The benefit to this is you still get to store you data locally. Local storage isn’t going away. People want their data. Sure, they want backups, but if their internet goes down, they don’t want to lose access to the data. And adding more data to the system is easy. Just add another hard drive like you do now. Also, the service provider need not store the data remotely. They just need to keep track of your various machines, and make sure machine A can speak with machine B. This eliminates privacy concerns. Instead of worrying how much disk space to rent, you just handle it yourself.
Essentially, you turn this from a push environment into a pull. You aren’t handed data, you ask for it. The service provider would manage things like figuring out which file is the latest copy, and keep track of local copies in case something changed and you didn’t want.
Kent’s original plan was “Install G-Drive, Tell G-Drive which files to sync, Wait 3 days for the magic to happen, That’s it.” In my plan, the idea can essentially be “Install G-Drive” and that’s it. Take your phone with you, and have access to the file. Technically speaking, it’s not incredibly difficult. It’s making the workflow easy. Dropbox easy.
Who will deliver this? Apple has the best opportunity to do something like this. They have the complete infrastructure, from hardware to software, to handle something like this. Controlling the entire pipeline, it’s really just a willingness on their part that is needed. Consider for a moment that they already have MobileMe which handles a lot of this. Microsoft can do this. Live Mesh and SkyDrive were initial attempts at this field, but still, it’s not a complete end to end solution like what I discussed. Google, if anything, is the one company farthest behind on this. They have various services, like Picasa, that already handle online storage. The problem is syncing everything together across the OS. MS and Apple both have their own operating systems and phone platforms they can use to bring it all together. Google is missing out (and while Android is awesome, it’s missing it’s older cousin, a Google OS that is actively being pushed).
Could Dropbox deliver? Maybe. At the software end, I think they could pivot fast enough and release a product like the one I discussed quickest. Will they? I don’t know. They’d have to charge for the service, and would someone want to pay for this? I would. A couple bucks a month to have all my computers synced like this easily would be nice.
I’d love to leave everything at home, and go, and not worry about forgetting to sync up the pictures this Christmas while I’m at my mother’s. If I want to show her videos, I shouldn’t have to plan that in advance.
Cloud storage is an excellent idea, don’t get me wrong. But I’d much rather have proper syncing first.
--
http://blog.jasonlotito.com/uncategorized/whats-better-then-...
One of the big benefits of Dropbox (and something I forgot to mention) is that they work on a variety of platforms. However, I will take a look at that more when I get home on my Mac. Thanks!
But honestly, I don't thing that's important. Sync-on-Read is what you do now on the web. I click on a video on YouTube, and in seconds, I'm watching an HD video full screen.
I think the only hurdle is upload speeds offered by most ISP's is slower than download speeds. But even still, outside of HD videos, all the files I'd be interested in are quick downloads (pictures, documents, music).
It has an underlying peer-to-peer and data sync service as well.
I mentioned two things that solve for this:
1. Local network syncing. Much of my syncing occurs between my desktop and my laptop. Syncing shouldn't require an outbound connection (send up to dropbox, send down from dropbox).
2. Beyond large media files, most files people want to sync are still fast on high speed internet. Most pictures and documents aren't large enough to be a concern.
Finally, while most people's internet connections might be lousy, then they will suffer with the syncing regardless of the method used.
So yes, I do realize upload speeds are an issue, but it's not a big problem.
Yes, it's a problem. A problem I talked about in the original post. However, it's temporary problem, and only for people that have to suffer with slow internet. For these people, even download speeds are horrible. Steam, for example, as wonderful as it is, is hated in places where download speeds suffer.
However, global internet speeds are increasing.
For me, I can stream my music and videos from my home to work. While I don't for a moment hide behind this problem, I won't pretend it's a road block.
Simply put: it's a problem as much as people without internet wouldn't be able to use it either. Enough people can use it that it would be useful.
So, instead of just trying to point out problems, maybe you could point out a solution? As cool as dropbox is, it doesn't come close to solving the same problems.
I don't know. I think I'd take your post more seriously if it was something more than complaining and actually contributed some thought to the conversation.
And I apologize for mine. It was far too early, pre-coffee, and I should know better.
That being said, they aren't mutually exclusive services, however. And I did mention a push method as well. How this is accomplished could be as simple as a Dropbox method, maybe with a temporary store.
Being able to easily grab any file on one machine from another machine without having to do anything different (open find, browse to directory, open file and have it sync-on-read) and not being reliant on the disk space available on a remote service is key.
I'm not suggesting a dropbox like service would be useless. I can see the value in having an online store you can easily share with friends (something I wouldn't want my service as described handling, or at least, not in the default setting).
Consider the context of the discussion: Dropboxing your entire computer. That's silly. Rather, Dropboxing selected files, and syncing everything else on reading. Together they could work.
Edit: I realize now where the confusion might have arisen from, and why I think I answered it in my original post. I'm a moron. =)
I did, however, answer it in response to a question here: http://news.ycombinator.com/item?id=1911813
The idea of forcing a push was always in my head, but assuming people can read that is pretty poor manners on my part.
Google: Hacker/tinkerers start using their Gmail storage space as a cloud storage utility. Google does nothing. Eventually a 3rd party comes out their own solution with a brilliant additional twist, which becomes massively successful.
If I were Apple, I'd come out with my own Dropbox-like service and call it something like "Warp Drive." (Ansible? Wormhole?) I'd have it sync accounts on different laptop/machines based on about a dozen different "plans" which are never presented as a list to the user, but only suggested, based on their disk use. (Along with one or two options to "downsize" the plan.)
A "plan" for me might go like: store everything on the Mac Mini, because it fits there, and sync everything to the 256GB Air except the Movies directory. (Which will be available anyways through streaming like AirVideo does it.)
Privacy: There will be problems. Enough said.
I've also heard that death valley gets a bit warm in the summer.