I've seen a million "Omarchy brought my vintage Mac back to life post", which all perfectly illustrate that making it EASY to get going with such a project was the pivotal point. This has been possible for years, but required a lot of fiddling. Now that it's quick, many do 🤘

Va cerrando día 1, pero si no han tenido oportunidad de hablar con @Dropbox , pasen mañana por el booth. No olviden su swag y su refresco. Y también recuerden de participar en el code challenge. Vence mañana a la media noche. #jsconfmx #dropbox

Today Meta announced #Monarch, a new framework for distributed programming that delivers scalability without sacrificing performance. Monarch can be used to drive, or even debug, a large cluster in a notebook. It can also orchestrate large, fault tolerant model pre-training or highly asynchronous and heterogenous reinforcement learning jobs. 🔗 Read the blog from the PyTorch Team at Meta: hubs.la/Q03PC-LP0 Contributors include: @marius, @joespeez #PyTorch #OpenSourceAI #PyTorchCon

Caching is an good way to boost the performance of a web application. But it's not as simple as turning a switch. There are several backend read and write caching strategies. Here is how to pick the right one: 1. Cache aside. The application reads the data directly from the cache. If the data is in the cache, it's returned to the client. Otherwise, the application retrieves the data from the database and then writes it to the cache Pros & Cons: - database and cache can handle different data models - lazy loading prevents the cache from being loaded with unnecessary data - return stale data without a proper expiration time - many initial cache miss 2. Read through. Like read aside, but the application interacts only with the cache. In case of a miss, the cache gets the data from the database, stores it, and return it to the application Pros & Cons: - simplify application code - require a plugin for getting the data 3. Write through. The application writes data to the cache. The cache write immediately the data to the database. Pros & Cons: - data consistency between cache and database - no data loss in case of cache crash - higher latency for write operations 4. Write back. The application writes data to the cache. The cache writes the data to the database asynchronously Pros & Cons: - low latency - less load on the database - tolerant to database failures - data can be lost if the cache crash 5. Write around. The application writes data directly to the database. Only the read data get into the cache. Pros & Cons: - adapt for data written once and read less frequently (the cache store only re-reads data) - reading recently written data gives a miss (high latency) A perfect caching strategy doesn't exist. It all depends on the data and data access patterns. An excellent general-purpose strategy for read-intensive applications is the cache aside. Memcached and Redis are widely used caches to implement this strategy. A write-back strategy is a good choice if you have a write-heavy workload. Write-around could be a good fit if you have data written once and rarely read (i.e., real-time logs. You can read the full article about caching in distributed systems (second part) in the latest issue of @EngPolymathic

Announcing ROMA (Recursive Open Meta Agent): our new multi-agent framework that sets SOTA in reasoning + search. Seal-0: 45.6% FRAMES: 81.7% SimpleQA: 93.9% 🧵 Read more about how recursive coordination lets agents tackle complex queries.