camuel

Exactly!

Some are role playing forensic investigators here. The guy admitted that he got overexcited and submitted unfinished work which he doesn't even remembers which build it was exactly and he published his current source code as OSS which scores even better and fixes all the accusations.

It's the exact opposite.

The bitter lesson is that simply scaling training on more games—including self-play—trumps any hand-crafted human input, whether that's fine-tuning on human commentary or clever engineering tricks.

Current models are just high-dimensional interpolation engines. The denser the data sampling, the more accurate the interpolation gets. Given a choice between denser sampling and anything else, denser sampling always wins. That is the bitter lesson.

Computer chess is the canonical example of this.

Will be super cool to see SlateDB instead RocksDB

Perhaps we just need an S3 implementation specifically built from the ground up for the data-intensive workloads? Such implementation might use conventional S3 underneath for cost and reliability advantages. Such implementation can also deliver a lot of additional functionality which will also be uniform across cloud vendors like enforcing Iceberg conventions on the server-side rather than on the client side and those pre-conditions uniformly implemented or even a full blown transactions but without breaking S3 semantics? Metering and billing can be also made friendly to those data intensive workloads. The question is: if the overhead of such indirection level, right on the data path, can be made reasonable? This is what we are trying to figure out at Embucket.com

So what is exactly Azure or Amazon offering for "AutoML Tables" or for "End-to-end AI Platform that runs ALSO on premises"?

How does this compare to KubeFlow?

It is claimed to be also an open-source project and meritocracy is common with open-source projects and github has the required automatic infrastructure for this "keeping track".

I think by "something" he means "phenomenon" and by "re-creating" he means "observing". So I think he is saying: if it is claimed that phenomenon X exists but there is no way to ever observe it for entity Y then X doesn't exists for Y.

But I'm not sure, it's my interpretation. The write-up resonates with me but I can see it as a bit ambiguous and inviting many incompatible interpretations.

Proper treatment of the subject in a book format would be great.

Google is very different from Intel on these fronts at least: 1. Google's open framework TensorFlow is exploding in popularity effectively moving the common interface up from CUDA. 2. Google has a huge need for internal AI/DeepLearning 3. Google has cloud and AI/DeepLearning as a service business 4. Google doesn't sells hardware

However, Intel dominance is not to be underestimated, they definitely can make industry wide impact quickly. Just saying you can not easily draw parallels here

we are heads down coding and haven't got time yet to update ZeroVM website. If you want to contribute contact us now please, if you to use ZeroVM hypervisor stay tuned...

but instance store is transient! You may argue if you do triple replicated in different availability zones then you are ok. Well, in this case it would be very costly as you will end up with constantly spinning EC2 cluster. Even if you don't do any computation you must keep it all spinning. And see what happened to elasticity... you end up paying inflated cloud prices for constantly spinning fixed size EC2 cluster! Instead of being able to rapidly roll out large cluster, make the computation and fold it back and pay only for what you have used - isn't it the true promise of cloud?