Well, sometimes you have space constraints. The O(n) extra-space required by mergesort isn't always available. But if you don't have space constraints, mergesort is a very good choice because you can easily write a highly scalable parallel version of the algorithm.
Looks like the algo is more complicated, but surely implementable. In most modern architectures, the key for performance is how one exploits the caching behavior. Quicksort is very cache friendly, as well as the common implementation of merge sort. Not so for heapsort.
No, but mergesort can easily fall back to dumping its sorted contents to disk, for later merging; this disk-based merge sort was invented by van Neumann in the 1940s, and is how the unix utility sort works (dozen-way merge of sorted shards of a file).
I think that probably it will get out of stock quickly. It's a marketing move that gets reported by major news sites, and raises interest among non-tech people. If everything goes smoothly, probably it will get less coverage.
Yes, I'm afraid that it's there marketing strategy. I think it works for Nexus 4 and gain them massive attention with the people. I'm just hoping that they will not do it again because there are more people now that are aware with the Nexus line and waiting. I know some people that are waiting for Nexus 5 but have a deadline for themselves. And if they don't get Nexus 5 immediately, they will just buy a different phone. Looks like a miss customer for Nexus.
To be fair there hasn't been any issues with stock on the new Nexus 7. I think what happened with the Nexus 4 is they underestimated the demand the reduced price would cause. It was the first time they sold a Nexus at such a discount. I think they'll have things more in control this time.
Ah, so then you make lots of stock, but hold it in reserve. Wait for out of stock reporting, and add a waiting list, then start shipping the reserve after a week of out of stock.
Everyone wins: People get their item, and the media gets to report out of stock.
Conflict resolution is not very sofisticated. You can choose to always take server side version (the default) or client side version (see https://github.com/astrada/google-drive-ocamlfuse/wiki/Confi...). My main use case is a single user working on the client or on the server. So the scenario is not of a collaborative app.
Fair enough. I can't imagine that most users will want to pass access tokens through your proxy, despite the hassle it saves. I would suggest making proxied auth /not/ the default or at least divulging the use of the proxy in a more prominent fashion in your documentation. Just a suggestion. People get sensitive when it comes to their personal cloud storage.
In Italy it isn't popular at all, but a couple of friends of mine use OCaml, mostly for hobby projects. And I like the language. It is more advanced than main stream languages I know (C#, Javascript), but, being strict, it is easier (for me) to reason about than Haskell.
