drewrobb
drewrobb on Hacker News
One aspect you miss in your analogy is that when you include the time dimension, the probability of a collision is proportional to swept volume (and thus speed), rather than static volume. So while the space is really large, really fast objects can have substantially large swept volumes.
Having transaction data hidden from governments isn't the essential feature of decentralization in the original promise of cryptocurrencies. The essential feature is preventing a single party from tampering with transactions or account balances. This is still true for bitcoin and many others.
I'm surprised that the scaling story of k8s/(+etcd?) is still so far behind mesos/zk. There have been mesos clusters at over 10k Nodes for several years now.
I have never personally needed more than a few hundred mesos agents, but these have been added without any noticeable impact on our extremely modestly provisioned (and multi purpose) zk cluster or any other components.
Has anyone used both systems and can speak to any advantages of k8s for these types of workloads?
Also is anyone using some kind of torrent approach as a more reasonable solution to avoid network bottlenecks when distributing big docker images to a large number of nodes?
Also, the area within by that large radius is going to be much bigger than from non-nuclear threats, so the number of people who could have reduced injuries via preparation might be much greater.
Those are just called "market makers". As a market maker you might be exposed to the risk of always ending up on the wrong side of the market over a longer time. For example if BTC is generally moving up, market makers might eventually have sold all their BTC and end up with USD. Sophisticated market makers will thus try to maintain a neutral position to avoid that risk. Some exchanges will even offer market makers a fee rebate to encourage parties to become market makers.
I think that is some kind of rowing/swimming/boating course. It shows up in the running layer because a few people mislabel their activity types. It shows up much stronger in the water layer. Next update to the heatmap I intend to add a activity type classifier to help with these errors.
I think there are two parts:
1) Internal representation for building/serving: For vector, the data would have to be aggregated in some way otherwise it would be way too slow (for example, tiles having 10 million or more lines). How exactly to do that vector aggregation is a real challenge. If there is a good solution I'm not aware of it.
2) End product quality: everything is ultimately rasterized on the viewer's monitor. So if upstream resolution is high enough vector doesn't have any advantage here.
level 16 is as far as it goes.
