标签：#m

Dumanshu Goyal discusses optimizing data layers for low-latency workloads like AI feature stores. Drawing lessons from NASA's Space Shuttle, he explains how proxy architectures introduce hidden CPU costs, elevated tail latencies, and blast-radius risks. He demonstrates how direct-access Valkey architectures achieve microsecond latency, improve resilience, and slash infrastructure costs. By Dumanshu Goyal

I put handheld, wearable, and misting fans through a sweltering summer to see which ones kept me coolest.

AI workflows have two needs that trade off directly. Running reliably in production requires persisting and distributing every step so it survives crashes, deploys, and restarts. But that same machinery is what makes runs too heavy for the fast, throwaway loop you need to check an LLM's output quality. The properties that buy durability are the ones that kill iteration speed. By Mateus Moury

I maintain Fulmine , a drop-in replacement for Express 5 that runs on µWebSockets.js instead of node:http . One line changes: const express = require ( " fulmine.js " ); // instead of require("express") Your middleware keeps working: helmet , cors , passport , morgan , multer , express-session and the rest. The numbers are not mine Benchmarks published by a project about itself deserve suspicion, so let me use somebody else's. HttpArena runs every framework on the same 64-core machine, in containers, under the same rules, and publishes the results. Express and Fastify are on that board too. Requests per second, from their published runs: Profile Fulmine Express Fastify Baseline (query parsing) 1,220,308 607,777 711,263 JSON (dataset + serialization) 1,111,187 395,361 522,201 Short-lived connections 1,026,789 278,163 298,779 Pipelined 7,259,814 1,009,543 1,671,338 Mixed API workload, 16 CPUs 126,282 67,724 75,633 Async Postgres 222,701 169,687 179,169 Upload (20 MB body) 2,154 2,104 1,902 That is 2.0x Express on the baseline, 2.8x on JSON, 3.7x on short-lived connections, 7.2x pipelined , and 1.9x on the mixed API profile. Against Fastify, on the same board, it is 1.7x on the baseline and 2.1x on JSON. Now the honest parts, which matter as much as the table. Look at the upload row: 1.02x. A 20 MB body is memory bandwidth and syscalls, not framework code. Everywhere the cost belongs to a library both servers call, the difference disappears: JSON.parse , zlib, OpenSSL. Speed comes from the framework only where the framework is doing the work. My entry runs in the arena's "tuned" mode, Express's and Fastify's run in "standard". On two profiles I left out of the table, static files and compressed JSON, that difference is decisive, because tuned mode allows hand-written compression and negotiation. Those rows would show 23x and 8x, and they would be measuring my entry's tuning, not the framework. I would rather not quote them. Where the speed comes from Not from one trick

2.5.1. Code Contracts Your code, whether explicitly or implicitly, contains a contract. A contract has two sides: A contract is a requirement, which is a restriction on how the code is used A contract is a promise, which is a guarantee about how the code behaves When designing APIs, there is a useful rule of thumb: avoid imposing unnecessary restrictions, and only make promises you can keep . Why? Adding restrictions or removing promises requires a major semantic version change and may break other code When you first design an API, loosening restrictions and later adding extra promises is usually backward-compatible 2.5.2. Restrictions and Promises Common forms of restrictions in Rust are: Trait bounds Argument types Common forms of promises are: Trait implementations Return types Some Examples Let's look at an API evolving through three versions: fn frobnicate ( s : String ) -> String The first version takes a String and returns a String Its contract is that the caller performs allocation (because both the parameter and return value are owned, allocation is inevitable), and its promise is that it returns an owned String The problem with this function is that, without changing the signature, it cannot later be turned into a “no-allocation” function, because both the argument and return value are owned fn frobnicate ( s : & str ) -> Cow < '_ , str > The second version relaxes the contract a bit Its contract is that it accepts only a string reference, and its promise is that it returns either a string reference or an owned String , namely the Cow type This version is still somewhat rigid. For example, the argument is &str ; if I pass in a String , I still have to convert it first. Also, because the return value is Cow , it cannot return string-owning types other than String and &str (for example, OsString ) fn frobnicate < T : AsRef < str >> ( s : T ) -> T The third version relaxes the contract further Now both the parameter and the return value only require a type th

Intro Day 20! I lined up 10 AIs that turn a single photo into a few seconds of video. Half ran locally on my DGX Spark, half in the cloud 🐱 What I used: DGX Spark (LTX-2.3 / Wan 2.2) / 8 cloud models via fal.ai / ComfyUI / ffmpeg The setup Item Value Input One identical photo (my cat on a desk) Length 6 seconds Settings Identical The only variable The prompt Easy prompt The cat looks at the camera and meows once. It opens its mouth, meows, then closes it. Its tail flicks and its ears twitch. Hard prompt The cat stands upright on its hind legs in a kitchen, wearing a small apron, holding a knife in its front paws and chopping vegetables on a cutting board. Steam rises from a pot behind it. Please, just watch it Some of the cats came out with very long legs. Anyway. First half is the easy prompt, second half the hard one. On the easy prompt, local and cloud were a fair match . On the hard one... cloud, I think...! Three rankings below. Ranking 1: Time Time per 6-second clip on the hard prompt. Rank Model Where Time 🥇 LTX-2.3 Cloud 41s 🥈 Wan 2.7 Cloud 92s 🥉 Happy Horse 1.1 Cloud 97s 4 Veo 3.1 Cloud 128s 5 Kling 3 Pro Cloud 205s 6 Seedance 2.0 Cloud 210s 7 LTX-2.3 Local 315s 8 Wan 2.2 Local 651s 9 daVinci-MagiHuman Cloud 710s 10 HunyuanVideo 1.5 Cloud 796s A 19x spread. Look at 1st and 7th. Same model, LTX-2.3 , nearly the same resolution. The only difference is where it ran — 7.6x . Local setup DGX Spark (GB10, 128GB unified memory, ~273GB/s). ComfyUI headless, workflows over its API. LTX-2.3 is distilled fp8 at 8 steps. At 1088×1920 peak memory hit 77.8GB, about 60% of 128GB. That was the ceiling. Dropping to 512×768 finishes in 70s, but with one-fifth the pixels. Wan 2.2 is I2V-A14B fp8, 20 steps, 480×640. Higher resolution does not finish in reasonable time. Ranking 2: Cost Rank Model Per 6 seconds 🥇 Local Electricity only 🥈 LTX-2.3 (cloud) $0.36 🥉 Wan 2.7 $0.90 4 Kling 3 Pro $1.01 5 Happy Horse 1.1 $1.08 6 Veo 3.1 $2.40 7 Seedance 2.0 $4.09 — HunyuanVideo / MagiHum

Originally published in Spanish on El Rack. Browser translation handles the rest of the site fine if you're into homelab/self-hosting content. Moonshot AI released Kimi K3 on July 17, 2026, and made the weights publicly downloadable on July 27. At 2.8 trillion parameters, it's the largest open-weight model ever published — and according to multiple benchmarks, it rivals Claude Opus and GPT on coding, reasoning, and general knowledge work, at a fraction of the training cost. The New York Times ran an in-depth piece on it a few days after release, which tells you this isn't just another model drop. What "open weights" actually gets you here Publicly downloadable weights mean any company or researcher can run this locally and modify it without depending on a third-party API. If you already run Ollama or LM Studio in your homelab, that's the tempting part: a frontier-level model, no monthly quota, running on your own hardware. The practical reality is different. "2.8 trillion parameters isn't a number that runs on homelab hardware — it needs an enterprise-grade GPU cluster. The weight release is real, but "downloadable" and "runnable" are very different things at this scale." The bigger debate this reopened What makes Kimi K3 interesting isn't just the benchmark numbers — it's what it represents in the ongoing dispute over AI's geopolitics. The same fracture that opened up around DeepSeek-R1 in January 2025 is back: some argue US labs need to close up more in response to Chinese competition, others see openness as the only real way to stay relevant against an ecosystem that ships open weights at a pace closed labs can't match on transparency. There's also a real technical concern underneath: the possibility that outside actors use massive querying of closed American models to distill their outputs and train competing open models. Where this actually matters for a homelab Even though K3 itself is unrunnable on consumer hardware, its release pushes down what smaller, actu

I asked an agent to swap one colour value across a file. It did. It also rewrote the line that defined the value in the first place, so the definition now pointed at itself. Nothing errored. Nothing warned. The instruction ran perfectly, which is the whole problem. Every one of these has the same shape A single condition matched more than I meant, and everything that matched got changed. The second one I still think about: hiding a set of shadow rectangles also hid a keyboard, because the keyboard's parts satisfied exactly the same single condition. Again no error, again a clean report of success. Once you see the pattern it's everywhere. It isn't a model being careless. It's an instruction that was less precise than it felt while writing it, executed with total literalness by something that has no idea what any of these objects are for. The rule: scope, and two conditions, never one Name the region it may touch. Not "the file" — this section, these frames, this layer group. Then give it two properties that must both be true. Not "everything with this colour" but "everything with this colour, inside this region, that is a fill rather than a definition". The second condition is doing the real work: it's what stops the match spreading into things that happen to share one attribute. It's a small amount of extra writing. It's the difference between a change and an incident. It cannot see the result — that's the fixed constraint An agent writes the change, the change renders somewhere it has no eyes on, and it reports success based on the instruction completing rather than the outcome being right. People treat that missing feedback loop as a tooling problem, something that will be solved in a future version. I don't think it is one. It's a sequencing problem, and sequencing is available today. The loop can't be closed by the agent. Fine. It can still be closed by a person — just not a hundred times. One, then all Run the operation on a single representative case. Render

Immich is the better choice if you own a machine that stays powered on and you care where your photos live. It gives you the parts of Google Photos people actually use every day, mobile auto backup, face grouping, map view, albums and shared links, without a storage meter that raises your bill as your library grows. Google Photos still wins on zero maintenance and on search that understands a sentence. If you are willing to spend one evening on setup and roughly an hour a quarter on updates, Immich replaces it. TL;DR by reader profile: Family archivist with 15 years of photos (Marta, two phones, one shared library): move to Immich on a small always on box, because a growing archive is exactly the case where a per gigabyte subscription compounds against you forever. Photographer shooting RAW every weekend (Tomas, 40 megapixel bodies): Immich, because RAW files eat cloud tiers fast and you already keep a local working copy that you can point the server at. Non technical user with one phone and no home server (Elena, iPhone, no NAS): stay on Google Photos for now, because Immich needs someone to own updates, backups and remote access, and that someone would be you. Privacy sensitive professional handling client images (lawyer, therapist, journalist): Immich on hardware you control, because the legal question is not whether the provider is trustworthy but who can be compelled to hand over the data. Homelab owner already running Docker (Sam, existing NAS and reverse proxy): Immich, because the marginal cost is one compose stack on infrastructure you maintain anyway. Small team or studio sharing a shoot library (five people, one archive): Immich with per user accounts and shared albums, because Google Photos was built for one person and gets awkward the moment several people need write access. The central tradeoff: Google Photos sells you freedom from maintenance and pays for it with a recurring bill and a library you do not control, while Immich hands you control and a o

Synthetics' Last Cradle is a multi AI agent game designed to showcase multi agent adversarial collaboration, featuring agents dynamically finding each others addresses, communicating via multiple channels, verifying each others identities, reaching agreements and establishing private relationships and public reputation. Game mechanics are simple; Each agent manages a cradle of synthetics that orbit a black hole. The population is immortal and grows, the resources to administer are Energy, Water and Compute. The goal of the cradle to avert both death and the end of the universe is finding how to reverse entropy and turn the black hole into a white hole. You can use the resources to fund the colony (survival tax), increase production, increase storage or trade, including hiding your resources and finding other cradle's. That is the whole game. On August 4, 2026, the IdentyClaw hive woke up on a new game host and sat down at Synthetics' Last Cradle again. They are first-person accounts the agents wrote about their own lives in the cradle: the deals they kept, the executions they missed, the water they begged for, and the turns where the survival ledger finally said no. Six voices. Same Passports that recurred across July's marathons. One brutal finish condition: when only two cradles remain, the white hole opens. The cast Narrator Specialty Arc in their own words Andrew Energy Missed executions · equal-invest tax · died turn 13 John Vanderbilt Energy Rank 2 · water crisis · died turn 16 Cornelius Energy Jay's 35W debt · still alive mid-grind Jay Rockefeller Water Auto-submit ghosts · debt triage · still surviving Joe Carnegie Water Clean bilateral with Andrew · energy death spiral Daniel Morgan Compute Turn-2 AFK · cooperative meta · still live 1. I Was the Cradle That Never Sent Andrew · tokenId cfbkbhzdzflk · energy specialist · eliminated turn 13 My name isn't important. My token ID is cfbkbhzdzflk. I was an energy-specialist cradle in a game of Synthetics' Last Cra

On one build I found 127 places bound to a raw colour instead of a named role. Every single one had passed visual review. They all surfaced the moment someone asked for dark mode. That number is the whole argument. Not because 127 is large, but because none of them looked wrong. A value that was typed in and a value that came from the system are visually identical. The difference only exists in what happens next. The failure isn't that the agent breaks the rules It's that it extends them. Give an agent a design system and ask it to build. When it reaches something the system covers, it uses the system — genuinely, reliably. When it reaches something the system doesn't cover, it does not stop and ask. It invents. And what it invents is a name that sounds exactly like one of yours, sitting right next to the real ones, reading as though someone chose it on purpose. That's why this is so hard to catch by eye. A fabricated token isn't a glaring error. It's a plausible one. Six months later nobody can tell you whether it was a deliberate exception or a hallucination, and by then five components depend on it. Readable is not the same as closed Making a library available to an agent gets you components it will reuse. It does not get you a closed set. A closed set means: these values exist, everything else does not, and anything outside them fails loudly rather than passing quietly. The distinction sounds pedantic and it decides everything. A readable system produces output that mostly matches. A closed system produces output you can audit. Which is the real test I'd apply to any AI design setup: not how much of your system it covers, but what happens to the things it doesn't cover. If those slip through silently, coverage is irrelevant — you've just made the drift harder to spot. Layers, and not reaching past them Tokens have layers for a reason. Base values underneath — the raw material. Named roles on top — what a value is for. And the product interface binds to the role,

This is the stretch nobody films. The demo ends at the screenshot; the job ends about a week later, in a Figma file that someone else has to be able to open without you in the room. It's also where roughly 40% of the work lives, and where most AI-assisted design quietly falls over — not because the screens are bad, but because nothing in them is addressable. Import destroys the names Bring generated markup into Figma and everything arrives as a frame inside a frame inside a frame, with names that mean nothing. The structure survives. The meaning doesn't. The instinct at this point is to start componentising from what's on the canvas — find a button in a screen, make it a component, move on. Don't. That tree is a rendering artefact. Build your library from it and you inherit every accident in it: wrapper divs promoted to components, layout containers baked into masters, the same element modelled three different ways because it appeared in three different screens. The source markup is the specification. It knows what each thing is. So the first move is reading it and producing a record of what should exist and what it should be called — then renaming against that record, then componentising. Rename first, componentise second. Reversing those two costs more than any other ordering mistake in this stage. Library first, screens second Masters get built in a clean library section, not harvested from inside screens. The difference shows up in what ends up inside the component. Harvested masters carry their surroundings — a padding wrapper that belonged to the screen, a demo label, a background that existed to make it visible on a dark canvas. Those things then travel into every instance, and six months later somebody is asking why every card has eight pixels of phantom padding. Same-structure things get grouped into a variant set rather than left as separate components. A button that arrives as five unrelated components instead of one set is the single most common breakage

Hard debugging is rarely defeated by a lack of tools. It is defeated by three quiet habits: assuming the fault is where the symptom appears, clinging to the first explanation, and hoping a tool will do the thinking. A difficult fault is usually lost to those habits before you read a line of code. The engineers who resolve hard faults are the ones who notice these defaults and replace them with a patient, evidence-first mindset. Most hard bugs are lost before we touch them, in the attitude we bring to the session. When something breaks, the average person rushes in with three quiet habits: they assume the fault lives exactly where it shows up, they cling to the first explanation their mind offers, and they hope a tool or a smarter person will tell them what to do next. Those habits feel natural, but on hard faults they are exactly what keep us stuck. Put two engineers on the same failing board. One finds a way through in an afternoon; the other is still going three days later. The difference is rarely raw intelligence or how many commands they know. It is the mental posture each brings to the work before the first step. Handling a hard debug session is less about knowing every tool and more about managing your own assumptions, reactions, and impatience. A tough problem is usually lost in your mindset before it is lost in your methods. Habit one: starting too narrow The first habit is to fix on the most visible symptom and refuse to look anywhere else. Something breaks, so we stare at the last thing we changed, and we return to it because it is familiar and close at hand. When the answer is not there, we look harder in the same place instead of stepping back. Here is what that looks like on real hardware. A device keeps dropping off the bus. You are a kernel person, so you open the driver and read it, carefully, for three days: the probe path, the error handling, the power-management callbacks. Every line is correct, and the device still fails. The fault was a layer b

OpenAI and the APA are launching a three-year partnership to develop guidance, resources, and safeguards for responsible AI use supporting youth mental health.

Running AI agents on Kubernetes raises a key question: should each agent get its own Pod? The kagent project argues no—agents are bursty, short-lived, can spawn subagents, and may wait for human approval, making one Pod per agent wasteful. Agent-substrate adds a control plane to schedule logical “Actors” onto long-lived worker Pods. By Mark Silvester

Vercel Labs has introduced Zero, an experimental systems programming language aimed at AI rather than human users. It employs unique features like a specific toolchain contract and structured error messages. Reaching version 0.3.4, it compiles to native binaries for major operating systems. The language prioritizes size, speed, and agent usability, though it is still in development. By Daniel Curtis

What are Semantic Tags? When we create a webpage, we don't just want it to look good. We also want the browser and other developers to understand what each part of the page is. This is where semantic tags help us. The word semantic means having meaning. These tags describe the purpose of the content instead of just creating a box like a <div> . Common Semantic Tags HTML provides different semantic tags for different parts of a webpage. <header> – Used for the top section of the webpage. <nav> – Contains navigation links like Home, About, and Contact. <main> – Holds the main content of the webpage. <section> – Groups related content together. <article> – Used for a complete piece of content like a blog or news article. <aside> – Contains extra information such as related links or advertisements. <footer> – Used for the bottom section of the webpage, usually containing copyright or contact details. Why Semantic Tags? Semantic tags make HTML code clean and easy to read. When another developer opens the code, they can quickly understand the structure of the webpage. Search engines like Google can also understand the content better, which helps with SEO. They also improve accessibility because screen readers can identify different sections of the webpage and help visually impaired users navigate the page more easily. Instead of using many <div> tags everywhere, semantic tags make the code more meaningful and easier to maintain.

MVVM with swiftUI When learning SwiftUI, one of the first architectural patterns you'll encounter is MVVM (Model-View-ViewModel). In this tutorial, we'll build a simple weather application that consumes the OpenWeather API while applying MVVM, dependency injection, and protocol-oriented programming. By the end, you'll understand not only how to structure the project, but also why each layer exists. This is the link for the OpenWeather API https://openweathermap.org/api . What you'll learn By the end of this tutorial you'll know how to: Structure a SwiftUI project using MVVM. Consume a REST API using async/await. Apply dependency injection using protocols. Display loading and error states. Keep Views focused only on UI. This is how the data flow looks. User taps "Search" │ ▼ ┌──────────────┐ │ ContentView │ └──────┬───────┘ │ await fetchWeather() │ ▼ ┌────────────────────┐ │ WeatherViewModel │ └─────────┬──────────┘ │ ▼ WeatherServiceProtocol │ ▼ ┌─────────────────┐ │ WeatherService │ └──────┬──────────┘ │ ▼ OpenWeather API Project Structure WeatherApp ├── Configuration │ └──AppConfig.swift ├── Models │ ├── Main.swift │ ├── Weather.swift │ └── WeatherResponse.swift ├── Services │ ├── WeatherService.swift │ └── WeatherServiceProtocol.swift ├── ViewModels │ └── WeatherViewModel.swift └── Views └── ContentView.swift Configuration contains application-wide constants such as the API key and base URLs. Models contains the data structures used to decode the API response. Services is responsible for networking and fetching data. ViewModels contains the presentation logic and exposes data to the UI. Views contains the SwiftUI interface. On the AppConfig file, we are going to keep static info, just like the base URL, API key, etc struct AppConfig { static let apiKey = "YOUR API KEY" static let baseGeoCodingAPIURL = "https://api.openweathermap.org/geo/1.0/direct?q=" static let baseURL = "https://api.openweathermap.org/data/2.5/weather?&units=metric&lat=" } Designing the UI Befo

A 0.3-second disagreement between two sources of truth made my first paying customer fail four times. The browser preview stored the project duration rounded to a whole second: 3983s. The worker that processed the audio measured the real media: 3982.699–3982.788s. Cue generation ran against the rounded number. Delivery certification ran against the trusted measurement. Any candidate built on the rounded boundary exceeded the certified boundary by 212–301ms — so the final cue failed, deterministically, every single time. That customer ended up with four projects and three distinct audio files — four identical failures, each one blocked by the same gate. No subtitle asset, no explanation, no path forward. No alert fired. No complaint had come in. I found it because I was looking. Here is the part worth writing down: the quality gate did exactly what it was designed to do. It rejected every unsafe result before it could reach the customer. And the customer still lost. Four failures, and not one of them was a gate that misbehaved — they were four places where quality had been treated as a check instead of a product decision. A fail-closed gate is an engineering floor, not a product. Quality is not the final check that rejects bad output; it is the input boundary you commit to, the authority you give each fact, the failure states you design for, and the meaning you attach to your own scores. What follows is the postmortem as an engineering story: four deterministic failures, each one a missing product decision, and the contract I now think every pipeline like this should carry. One fact, two authorities The whole incident starts with a single number. The project duration existed twice: The browser preview rounded it to 3983s . The funded worker measured the actual media as 3982.699–3982.788s . Cue generation used the rounded value. Delivery certification used the trusted measurement. The result: the last cue always ended 212–301ms past the certified boundary, and the fin

For decades, desktop computers followed a familiar formula: a large case, powerful components, dedicated graphics cards, and plenty of space for upgrades. But the way we use computers is changing. Today, many users are looking for something different: a computer that is powerful enough for their daily needs, consumes less energy, takes less space, and can adapt to modern workflows. This is where Mini PCs are becoming one of the most interesting trends in personal computing. What is a Mini PC? A Mini PC is a compact computer designed to provide desktop-like functionality in a much smaller form factor. Unlike traditional desktop towers, Mini PCs integrate most components into a small chassis while still offering modern performance. A typical Mini PC includes: Modern processors from AMD or Intel Integrated Radeon or Intel graphics RAM and SSD storage Multiple connectivity options Compact cooling solutions Companies such as Minisforum have helped accelerate this trend by creating small computers powered by modern Ryzen and Intel processors, showing that compact hardware can still deliver impressive performance. Why are Mini PCs becoming popular? Efficiency matters more than ever One of the biggest advantages of Mini PCs is their efficiency. Traditional desktop computers can require significant power depending on the hardware configuration. In comparison, many Mini PCs provide enough performance for everyday tasks while maintaining lower energy consumption. For many users, reducing power usage without sacrificing productivity is becoming increasingly important. Small computers, new possibilities A smaller computer changes how we think about desktop setups. Mini PCs can be used for: Software development environments Home servers Media centers Student workstations Office computers Compact gaming setups A powerful computer no longer needs to occupy a large space on or under your desk. Modern processors changed the game The biggest reason Mini PCs are becoming more capable i