thinxer

For “cloud-native” apps, JuiceFS is not needed.

S3 is not designed for intensive metadata operations, like listing, renaming etc. For these operations, you will need a somewhat POSIX-complaint system. For example, if you want to train on ImageNet dataset, the “canonical” way [1] is to extract the images and organize them into folders, class by class. The whole dataset is discovered by directory listing. This where JuiceFS shines.

Of course, if the dataset is really massive, you will mostly end-up with in-house solutions.

[1]: https://github.com/pytorch/examples/blob/main/imagenet/extra...

For context:

1. https://twitter.com/rus/status/1641908582814830592

2. https://twitter.com/bighuman/status/1641910129384648706

On the first sight I fired up Developer Tools to check the banner is *not* <marquee>.

I expect Photoshop to contain many highly optimized function routines for photo processing. These routines are optimized by hand and usually use architecture-specific features such as SSE/AVX which is not portable.

Unoptimized (more portable) versions of theses routines exists, but I suspect they will perform well even with M1.

This looks like Entity-Component-System[1] in game development. Entities are composed of components, and components are often stored vectorized.

[1]: https://en.wikipedia.org/wiki/Entity_component_system

It is because Google wants a monorepo, then Google choose to use Perforce (and later Piper). It is not that Google uses Perforce and thus are limited to a monorepo.

The core value behind monorepo (and monorepo-like approaches) explained in the book is that dependency management is harder than version control.

For anyone interested in why monorepo works, I'd recommend the book Software Engineering at Google: Lessons Learned from Programming Over Time. It has detailed the reasons for the One Version Rule and Version Control over Dependency Management.

I'm using this: https://github.com/uxbh/ztdns.