TL;DR China’s space programme in 2026 is one of the most consistently executed national space efforts in history. Where Western programmes have lurched between budgets and political cycles, China’s CNSA has shipped roughly what it announced, on roughly the timelines it announced. The Tiangong space station is fully operational, continuously crewed, and has hosted both domestic and international experiments. The Chang’e lunar series has progressed from sample return (Chang’e 5, 6) to the precursors of a crewed lunar landing programme planned before 2030. China has now returned samples from both the near and far sides of the Moon - the only nation to have done so. The lunar plan centres on the International Lunar Research Station (ILRS) - a long-term, China-led, multinational lunar surface base, with crewed landings as a milestone rather than the goal. Mars sample return, deep-space exploration, and a permanent lunar presence are all on a credible timeline. The realistic 2030 picture is two distinct, durable lunar architectures - American and Chinese - running in parallel. Why It Is Worth Looking Carefully It is easy in Western coverage to treat China’s space programme as a backdrop to the Artemis story. That undersells what is actually happening. ...

TL;DR eBPF is the technology that lets you run safe, sandboxed programs inside the Linux kernel without writing kernel modules. In 2026 it is the foundation under most serious observability, networking, and runtime security tools. The interesting story is not the technology itself - it is the wave of products built on top of it: Cilium for networking, Tetragon for runtime security, Pixie, Parca, and Coroot for observability, plus a long tail of vendor offerings using eBPF under the hood. For platform engineers, eBPF is not “a thing you have to learn to write.” It is a thing you have to know about so you can choose tools intelligently and understand what is happening on your nodes when those tools cause problems. The most important shift eBPF has enabled is observability without instrumentation. You can see what is happening on a system without modifying the application, without restarting it, and with low overhead. That is genuinely new. What eBPF Actually Is eBPF stands for “extended Berkeley Packet Filter,” which is historical and confusing because eBPF has long since outgrown packet filtering. The simple version: ...

TL;DR Data pipelines were optimised for human consumers - dashboards, BI tools, analysts. In 2026 a growing share of pipeline output flows directly to language models, agents, and retrieval systems. That changes the design constraints in ways that catch teams off guard. Aggregation matters less. Context fidelity matters more. Freshness behaves differently. Schema moves from rigid to negotiated. Cost shifts from compute to tokens. The biggest mistake is treating an LLM consumer as if it were just another dashboard. It is not. It does not skim, it does not interpret charts, it does not have working memory across rows. It needs to be fed. The new patterns - retrieval-aware partitioning, embedding pipelines, structured-document outputs, prompt-shaped views, evaluation harnesses for data quality - are the actual subject of “AI-native data engineering” in 2026. The Underlying Shift For thirty years the implicit consumer of every data pipeline was a human looking at a screen. Even when the pipeline ended in an API or a CSV, the conceptual end-user was someone who would interpret the output with judgement, context, and skim-reading. ...

TL;DR The open table format war between Apache Iceberg, Delta Lake, and Apache Hudi is effectively over in 2026 - and the outcome is not a single winner but a clear settlement. Iceberg has won the role of the neutral standard that engines and platforms expect to read and write. It is the format you choose when you do not want to be coupled to a single vendor. Delta has won the role of the incumbent default inside the Databricks ecosystem and remains a strong choice if Databricks is your primary engine. Delta UniForm has narrowed the gap by letting Delta tables expose Iceberg metadata. Hudi has not won a category outright. It retains a smaller but loyal user base for streaming-heavy and CDC-heavy workloads, where its design choices still genuinely fit. The interesting battle has moved up the stack to the catalog layer. The format question is mostly settled. The catalog question is the new fight. The Format Wars - A Brief History For most of the early 2020s the lakehouse story was a three-way argument about how to put ACID transactions on top of object storage. ...

TL;DR “Onchain AI agents” became the dominant crypto narrative in 2025 and has cooled meaningfully in 2026 as the picture has gotten clearer. The honest taxonomy has three buckets: agents that hold wallets and trade, agents that automate DeFi operations, and agents that exist primarily as tokens with a chatbot attached. Only the first two are doing real work. Real revenue is concentrated in agent-driven DeFi automation, MEV strategies executed by agents, and onchain payment rails for AI services. Most of the rest is meme economics dressed in technical clothing. The structural question - “do AI agents need crypto rails at all” - has become a genuinely live debate. The answer in 2026 is “yes, but only for a narrow set of jobs, and most of those jobs are not what was being pitched.” If you are evaluating an onchain AI agent project, the test is brutally simple: strip away the token and ask whether the agent does something useful. If the answer is no, the project is a token with extra steps. How We Got Here The phrase “onchain AI agent” started showing up in crypto Twitter in late 2024 and exploded in early 2025. By the middle of last year there were thousands of agent tokens, dozens of agent platforms, and a handful of agents with billion-dollar implied market caps doing things that would have embarrassed a 2010-era chatbot. ...

TL;DR The 2026 agent ecosystem has, while nobody was paying close attention, converged on three protocols that solve different problems and partly overlap: MCP (Model Context Protocol), A2A (Agent-to-Agent), and ACP (Agent Communication Protocol). MCP is the model-to-tool protocol. It standardises how an agent talks to its tools, data sources, and local context. This is the one that has clearly won its layer. A2A is the agent-to-agent protocol. It standardises how separately deployed agents discover each other, exchange tasks, and pass results. Adoption is growing but the picture is less settled. ACP is the orchestration-and-runtime protocol. It standardises how an agent runtime exposes its lifecycle, state, and operations to the systems around it. Newer, more enterprise-focused, and not yet a clear winner. The mental model: MCP for tools, A2A for peers, ACP for the platform. Build with all three in mind even if you only need one today. Why Protocols, Why Now A year ago “agents” was still a debate about whether the things existed. By mid-2026 the debate has shifted. Agents exist. They do useful work. The interesting question is no longer “will this work” but “how do we connect them to everything else.” ...

TL;DR Kubernetes won the orchestration argument years ago. The question is no longer “should we use Kubernetes.” It is “should this particular team, with this particular workload, with this particular budget, pay the operational tax.” For genuinely large, multi-tenant, multi-region platforms with dedicated infrastructure teams, the answer is still mostly yes. The ecosystem maturity is unmatched and the alternatives lose at scale. For mid-sized engineering organisations, the answer in 2026 is probably not, and increasingly not. Managed serverless, container platforms like Fly and Railway, and the new generation of platform-as-a-service offerings are competitive in ways they were not three years ago. For startups and small teams, the answer is almost always no, and stop pretending otherwise. The honest read in 2026: Kubernetes is the right answer to fewer questions than it used to be, and being honest about that is now a competitive advantage rather than a heresy. How We Got Here Kubernetes was the right idea at the right time. By the late 2010s, every serious engineering team needed an answer to “how do we run containers in production.” Kubernetes provided one, it was open, it was backed by a credible foundation, and the cloud providers all blessed it. Within five years it was the default. Within ten years it was the assumption. ...

TL;DR Artemis III is supposed to land two astronauts near the lunar south pole using a stripped-down SpaceX Starship as the Human Landing System (HLS). The architecture is genuinely audacious - it requires a new super-heavy rocket to fly several times before the crewed mission, on-orbit cryogenic propellant transfer at a scale that has never been demonstrated, and a lunar surface stay enabled by a vehicle three times taller than the Saturn V’s lunar module. The technical risk is concentrated in propellant transfer, boil-off management, engine relight reliability, and crew ingress/egress from a 50-metre tower on a sloped, unprepared surface. The schedule risk is concentrated in everything that has to happen before the crewed flight - and most of it has not happened yet. The mission can succeed. The honest read in mid-2026 is that it will succeed late, and the more interesting question is which of these subsystems is actually the long pole. How Artemis III Is Supposed To Work Artemis III’s architecture is not Apollo. Apollo carried everything it needed in one stack on a Saturn V. Artemis III spreads the mission across multiple launches, multiple vehicles, and two distinct propulsion systems, with a crew transfer in lunar orbit. ...

If you’ve spent any time with Pianoteq or the Audio Modeling SWAM instruments, you’ve felt something different. Not the crisp accuracy of a sampled library, not the flexibility of wavetable synthesis - but something that responds like an instrument. Strings that vibrate with sympathetic resonance. Piano keys with wooden resistance. A cello that sings differently when you bow it hard versus soft. This is physical modeling: mathematics as an instrument, not just a sampler or synth engine. ...

A technical reader’s guide to where AI and crypto actually meet - without the hype. TL;DR The AI-token sector has stratified. There is a clear top tier of projects with real engineering, real revenue and visible institutional interest, and a long tail of speculation. The total AI-crypto market just crossed $17B and the measurable-infrastructure share is growing faster than the speculative tail. The five tokens worth understanding in May 2026 are Bittensor (TAO) as the conviction long, Virtuals Protocol (VIRTUAL) as the speculative growth bet, Render (RENDER) as the infrastructure hold, Artificial Superintelligence Alliance (FET / ASI) as the deep value play, and NEAR Protocol (NEAR) as the AI commerce layer. Every name on the list has drawn down 60%+ from its all-time high in the last 18 months. The drawdowns are not theoretical and they will happen again. Position-sizing matters more than picks. Worth flagging without putting them in the main basket - Kite (KITE), Internet Computer (ICP) and The Graph (GRT). Worth avoiding - the long tail of “AI memecoin” launches. Nothing here is investment advice. Prices are snapshots from publicly available data (CoinGecko, CoinMarketCap) as of 4 May 2026 and will be stale within hours. Why The Sector Looks Different In 2026 A year ago the AI-token sector was mostly a betting market on which token had “AI” most prominently in its tagline. In May 2026 the picture has changed character. There is a clear top tier of projects with measurable engineering output, real revenue, and visible institutional interest, and a long tail of names whose only product is a narrative. The total AI-crypto market cap just crossed $17B, and the share of that capital flowing into infrastructure with measurable usage has grown faster than the speculative tail. ...