DEV Community: techaiwire

VS Code 1.136 adds Agent Merge to finish pull requests

techaiwire — Tue, 08 Sep 2026 04:17:25 +0000

Visual Studio Code 1.136 adds a preview feature called Agent Merge. It hands an open pull request to an AI agent, which then answers review comments, fixes failing checks and resolves merge conflicts until the request is ready. Microsoft dated the release notes September 2, 2026.

A pull request is a proposed code change waiting for review. Getting one merged often means a slow loop of comments, edits and re-run tests. Agent Merge aims at that loop, not at writing the code in the first place.

What Agent Merge actually does

Microsoft's release notes describe the feature in one line. "Agent Merge helps you take a pull request across the finish line," they say. "It asks an agent to address review feedback, fix failed checks and merge conflicts, and rerun workflows."

Four separate jobs sit inside that sentence.

Job	What the agent does
Review feedback	Reads reviewer comments and edits the code
Failed checks	Diagnoses a failing test or lint run and fixes it
Merge conflicts	Resolves conflicts against the target branch
Workflows	Re-runs the checks, then repeats the cycle

The agent does not merge anything by itself. Approval stays with a person. The release notes do not say which git hosting providers are supported.

How to turn it on

Agent Merge is off by default. Microsoft gates it behind a setting named chat.agentMerge.enabled.

Switching that setting on does not start anything either. You still enable the feature one session at a time. There are three ways in: the Agent Merge button, the command "Enable Agent Merge for Active Session", or the Agents window.

That per-session design is worth noticing. This is not a background service watching your repository and pushing commits.

The rest of the agent changes in 1.136

Agent Merge arrives alongside several smaller changes to how sessions work.

Multi-root workspace support, marked experimental, for both Copilot and Claude agent sessions
Workspace resolution that lets an agent identify a project by name
A session hierarchy that shows related chats as children of a parent session
Notifications when a session is waiting on your approval
Readable breadcrumbs for files a session created
A redesigned session input with the controls gathered in one place

The chat surface changed too. The release adds experimental chat backgrounds, dictation controls for enterprise administrators, and screen reader improvements.

What this means for developers

The interesting shift here is not code generation. It is that the agent now operates your continuous integration and your pull request queue. Those are shared systems, and the blast radius is wider than an editor buffer.

Watch the conflict resolution most closely. Of the four jobs, it is the one where a wrong answer still compiles and still passes tests. An agent can resolve a conflict by quietly dropping somebody else's change, and nothing downstream will complain. Read those diffs line by line, the way you would read a rebase you did not perform.

Budget is the second thing to check. The loop reruns workflows until checks pass, so a flaky test becomes an agent retrying against a test that fails at random. If your CI bills by the minute, put a cap somewhere before you turn this on. A synthetic worked example, published by Telemetry's creator on DuckDB's discussion board, puts cost per accepted task at $0.75 when failed attempts count and $0.30 when they do not. We covered how GitHub started billing Copilot code review on Azure Repos, and the same question applies to anything that reruns pipelines on your behalf.

Your real controls are unchanged, and they are not in this settings file. Branch protection rules, required reviewers and required status checks still decide what can land. The setting governs whether an agent may push more commits to the branch. It does not govern what your repository accepts.

Treat the preview label seriously for now. Enable it on a branch you own, on a pull request that is already close to green, and read every commit it produces. Research on coding agents found they disagree about which tool to reach for far more often than their marketing suggests. An agent that is confident and wrong about a merge conflict is the failure mode to plan around.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

Sources

Visual Studio Code September 2026 (version 1.136) - Visual Studio Code
vscode release 1.136.1 - GitHub

Kubernetes 1.37 promotes rootless mode to beta

techaiwire — Tue, 08 Sep 2026 04:14:33 +0000

Kubernetes v1.37 promotes the KubeletInUserNamespace feature gate to beta. With it enabled, every node component can run as an ordinary user instead of root. Akihiro Suda of NTT announced the change on the Kubernetes blog on September 4, 2026. The v1.37.0 release itself landed on August 26, 2026.

The point is damage control. If someone escapes a container, they land in an unprivileged account rather than as root on the machine.

What actually runs as non-root

Suda lists four kinds of node component that the feature covers:

the kubelet
CRI and OCI container runtimes
CNI networking plugins
kube-proxy

All of them "can run as a non-root user on the host, using a Linux user namespace," he writes. "This technique is also known as rootless mode."

A user namespace is a Linux kernel feature. It lets a process believe it is root inside its own little world, while the host still treats it as an ordinary user. The privileges are real inside the namespace and absent outside it.

That is the whole security argument. Suda puts the motivation plainly: the node components have "historically had container-breakout vulnerabilities that could compromise full root privileges on the host." His post cites five of them.

CVE-2022-0811
CVE-2023-27561
CVE-2024-10220
CVE-2025-31133
CVE-2026-53488

Under rootless mode, a break out of any of those reaches a normal user account. It does not reach host root.

The distinction people will get wrong

There are two different user-namespace features in Kubernetes, and they are easy to confuse.

Suda draws the line himself. Rootless mode "should not be confused with user namespaces for pods," he writes. That other feature is switched on with hostUsers: false and the UserNamespacesSupport feature gate. It has been generally available since v1.36. It "puts pods in user namespaces but still runs the node components as root."

So one puts your workloads in a namespace. The other puts the machinery in one. They solve different halves of the same problem, and the post says they can be combined.

Seven years from experiment to beta

This feature has moved slowly, and the dates say something about its difficulty.

Stage	When
First experiment	2018
Alpha, as KEP-2033	v1.22, in 2021
Beta	v1.37, in 2026

Five years passed between alpha and beta. Running the kubelet without root touches container runtimes, networking plugins and cgroup management all at once, and each of those had to grow its own support.

A KEP is a Kubernetes Enhancement Proposal, the written design document a change like this has to pass through. It is the same shape of process that GNOME is now drafting for itself.

What this means for developers

Check who runs your kubelet before you plan anything. If you use a managed service such as EKS, GKE or AKS, you do not control that process, and this feature is not yours to switch on. It matters most to people running their own nodes, and to anyone building a test cluster or an edge deployment.

Read the announcement for the requirements before you try it. Rootless mode leans on specific kernel behavior, container runtime versions and cgroup delegation, and Suda's post is where those specifics live. Do not assume your current node image qualifies.

Treat beta as beta. In Kubernetes that means the API shape is fairly settled but the operational edges are not, and feature gates can still change defaults between releases. Run it somewhere you can afford to lose.

The useful takeaway holds even if you never enable it. Ask what a container escape actually reaches on your nodes today. For most clusters the honest answer is host root, and that answer is now a choice rather than a given.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

GNOME drafts an RFC process for big technical decisions

Sources

Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta - Kubernetes Blog
CHANGELOG-1.37.md - GitHub

Go 1.27 adds generic methods and a faster encoding/json

techaiwire — Tue, 08 Sep 2026 04:11:42 +0000

Go 1.27 was released on August 19, 2026, and it changes the language itself. Methods can now declare their own type parameters, which Go has refused since generics arrived. Nicholas Husin announced the release on the Go blog for the Go team.

Two other changes will reach more programs than the language work does. The standard JSON package now runs on a new engine, and the runtime can tell you which goroutines have leaked.

Generic methods, and their one limit

Before this release, a type could be generic but its methods could not add type parameters of their own. Authors wrote one method per concrete type instead.

The release notes point at math/rand/v2.Rand as the example. Its method now reads (*Rand) N[Int intType](Int) Int. One method covers every integer type.

There is a firm restriction. Interface methods may not declare type parameters, so a generic method cannot implement an interface method. That boundary is deliberate and it is not a temporary gap.

Two smaller language changes ship alongside it. A key in a struct literal "may now be any valid field selector for the struct type," which lets you set nested and embedded fields directly. And function type inference "has been generalized to apply in all assignment contexts", including composite literals, conversions and channel sends.

encoding/json now runs on v2

The encoding/json package is now backed by a v2 implementation. The v1 API stays, and the release notes are explicit that it is not deprecated. No migration is required.

The defaults did get stricter, and this is where working code can break. The v2 engine rejects invalid UTF-8 inside JSON strings. It also rejects duplicate names in a JSON object. Both used to pass.

Change	Effect
Invalid UTF-8 in strings	Now rejected
Duplicate object keys	Now rejected
Unmarshal speed	Significantly faster
Marshal speed	About the same
`format` and `unknown` tags	Removed in v2
`inline` tag option	Renamed to `embed`

If something breaks, GOEXPERIMENT=nojsonv2 restores the old implementation at build time. Treat that as a deadline, not a fix. The release notes say the opt-out is expected to be removed in a future release.

Two new packages come with it: encoding/json/v2, which takes variadic options, and encoding/json/jsontext for working at the token level.

Leak profiles, allocation and post-quantum signatures

The goroutine leak profile is now generally available in runtime/pprof, after being experimental in Go 1.26. A leaked goroutine is "a goroutine blocked on some concurrency primitive (channels, sync.Mutex, sync.Cond, etc) that cannot possibly become unblocked".

The runtime finds them using the garbage collector. If a blocked goroutine waits on something no runnable goroutine can still reach, it can never wake. Read it at /debug/pprof/goroutineleak. It has a stated blind spot: leaks on primitives reachable through global variables can be missed.

Allocation got cheaper. The compiler now calls size-specialized allocation routines, cutting the cost of allocations under 80 bytes by up to 30%. The release notes put the whole-program gain at roughly 1% for allocation-heavy code, and the binary grows by about 60 KB.

For security teams, crypto/mldsa implements ML-DSA, the post-quantum signature scheme in FIPS 204. TLS 1.3 gains the MLDSA44, MLDSA65 and MLDSA87 signature schemes, and x509 handles the keys.

What this means for developers

Read the removals before you upgrade, because that is where the breakage is. Go 1.27 now requires macOS 13 Ventura or later. It drops support for the bzr version control system, so modules hosted on bzr can no longer be fetched.

Several GODEBUG escape hatches are gone, and one of them changes behavior. With asynctimerchan removed, channels created by package time are always unbuffered now. If you wrote code around the buffered behavior, that code is running on a different contract.

The JSON change deserves a staging run rather than a reading. Stricter parsing fails on data you already accept, and duplicate keys in particular tend to arrive from other people's systems, not your own tests. Point the new build at real production payloads before you ship it.

Turn on the leak profile even if nothing looks wrong. It is free, it is now stable, and a permanently blocked goroutine holds its stack and everything the stack references. That class of bug rarely shows up as an error, only as memory that never comes back.

One last check for anyone doing clever things with function values. The compiler generates simpler names for closures now, so tests that assert on symbol names may need updating. Code that compares function pointers for equality was always incorrect, and this release exposes it more often.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Sources

Go 1.27 is released - The Go Blog
Go 1.27 Release Notes - go.dev

Asahi Linux now officially supports M3 series Macs

techaiwire — Tue, 08 Sep 2026 04:08:49 +0000

Asahi Linux runs on M3 Macs now, and the project says so out loud. "Asahi Linux now officially supports Macs with an M3 series SoC," the project wrote on September 6, 2026, in a post by James Calligeros. Support covers the M3, M3 Pro and M3 Max, and it is merged into the installer rather than sitting on a branch.

Asahi Linux is the project that ports Linux to Apple's own chips. Apple publishes no documentation for that hardware, so every driver here was written by reverse engineering.

What works on M3 today

The headline claim is continuity. Almost everything supported on the M1 and M2 machines "just works" on M3, according to the announcement.

That list is not small.

Hardware	Status on M3
Wi-Fi and Bluetooth	Working
USB 3, at 10 Gb/s	Working
Webcam	Working
Internal microphones	Working
AV1 video decode, hardware accelerated	Working

Hardware AV1 decoding matters more than it sounds. Without it, playing a modern video stream falls to the CPU, which drains a battery fast on a laptop.

What does not work yet

Three gaps are worth knowing before you wipe a disk.

Sleep does not work. The announcement blames limitations in the firmware framebuffer, which is the simple display path the machine boots with. A laptop that cannot sleep is a laptop you shut down every time you close the lid.

HDMI output is disabled on the MacBooks that have a port. Turning it on waits for full support of the display coprocessor Apple uses, which the project calls DCP.

Graphics are the third gap, and Calligeros is blunt about it. "Do not expect performant or power-efficient 3D acceleration right now," he wrote. The desktop draws, but games and GPU work do not belong here yet.

One machine is excluded entirely. The Mac Studio with an M3 Ultra is not supported.

Installing it right now

You can install today, but through expert mode, which is the path that assumes you already know what you are doing.

The standard installer is expected to accept M3 machines before the Fedora Linux 45 beta, which the project puts a couple of weeks out.

There is a gap between the announcement and the documentation, and it is worth checking before you start. The Fedora Asahi Remix page still describes the distribution as based on Fedora Linux 44, and its device support list still names only the M1 and M2 families. The blog post is ahead of the docs.

What this means for developers

If you have an M3 Mac you were keeping on macOS for lack of options, that calculation just changed, with caveats. A dual-boot machine is now realistic for terminal work, builds and containers. It is not realistic for anything needing the GPU or a closed lid.

If you maintain a package or a distribution, this widens the Apple Silicon test surface again. Working USB 3, Wi-Fi and cameras, but no sleep and no fast 3D, is an unusual configuration. It will find bugs in code that assumes a normal laptop.

If you are shopping, note which machine is missing. The M3 Ultra Mac Studio is exactly the box someone would buy for running large models locally, and it is the one configuration this release does not cover.

And if you are planning to install, wait for the standard installer unless you are comfortable in expert mode. Two weeks is a short time to wait for a path that does not require you to understand partition layout on Apple hardware.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

New Mac mini and Mac Studio put more memory bandwidth behind local AI

Sources

M2: Episode 1 (or, Asahi Linux on M3) - Asahi Linux
Fedora Asahi Remix - Asahi Linux

GPT-6 Astra scores 95% on one robot task, 10% on another

techaiwire — Tue, 08 Sep 2026 04:05:57 +0000

Robocurve has run OpenAI's GPT-6 Astra and Anthropic's Claude Fable 5.1 against physical robot arms, and the results split sharply by task. Astra completed the easy task 19 times out of 20. On the harder task it managed 2 out of 20, exactly matching Fable 5.1. Robocurve published the Astra results on September 4, 2026, and the Fable 5.1 results the day before.

Robocurve is an independent evaluator, not either lab. It describes itself as a Public Benefit Corporation and says it is backed by Y Combinator.

The two tasks and the numbers

Both models drove the same rig: bimanual I2RT YAM arms, six degrees of freedom each, parallel-jaw grippers, three camera views. Each model ran 20 trials per task, scored by human graders on a five-point stage scale.

The first task was picking a red block into a bowl. The second was placing a blue puzzle piece into a matching groove.

Model	Block task	Puzzle task	Cost per run, block
GPT-6 Astra	19/20	2/20	$0.94
Claude Fable 5.1	8/20	2/20	$2.12
Claude Fable 5	1/20	0/20	$2.69

Astra was also quicker. It averaged 2.5 minutes per run on the block task, against 6.8 minutes for Fable 5.1 and 8.2 minutes for Fable 5.

Where the gap disappears

The block numbers look decisive. The puzzle numbers are the interesting ones.

On the puzzle task both current models landed on 2 out of 20. A 95% score and a 40% score collapsed into the same 10%. Whatever separates the models on the easy task stops mattering once the task requires fitting a shape into a slot.

That is a familiar shape. We covered how Astra scores 99.9% or 62.7% on ARC-AGI-3 depending on the harness, and this is the same lesson arriving through a different door. A single headline percentage tells you about the task as much as the model.

Robocurve's Fable 5.1 write-up makes its own narrow claim rather than a broad one. Fable 5.1 "reached later stages of both tasks than Fable 5, completed each task more often, and produced fewer output tokens doing it."

The harness is open source

The evaluation framework, called inspect-robots, is on GitHub under the MIT licence. That matters more than any single score.

The repository holds the task definitions and the scoring code, not just the results. Models plug in through a defined interface, and the framework checks the action space, the observation space and the control rate before a run starts. Each run is recorded with its resolved config, the git revision and package versions.

So the numbers can be re-run and disputed, which is not true of most model comparisons.

What this means for developers

Read the per-task numbers, never the average. If Robocurve had reported one blended figure across both tasks, Astra would look roughly twice as capable as Fable 5.1. On the task that is actually hard, they are identical.

If you are costing an agent that touches the physical world, the cost column deserves as much attention as the success column. Astra ran the block task at $0.94 against $2.12, so it was cheaper and better there. Fable 5.1 cut cache read prices sharply this month, which is the kind of change that moves these figures between one evaluation and the next.

If you are building your own evaluation, clone the harness before writing one. It already handles the parts people get wrong: validating that a policy and an embodiment agree on the action space, and pinning the exact revision a result came from.

And treat 20 trials as what it is. It is enough to separate 19 from 8. It is not enough to separate 2 from 2.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

Sources

GPT-6 Astra - Robocurve
Claude Fable 5.1 - Robocurve
robocurve/inspect-robots - GitHub

A tampered strip binary can backdoor all of NixOS

techaiwire — Tue, 08 Sep 2026 03:31:54 +0000

The trusting-trust attack has always been described as a compiler problem. A paper on arXiv shows it is not. Five researchers built a complete version of the attack around GNU strip, a build tool that never reads or writes source code. They used it to backdoor nearly every binary in a NixOS graphical installer.

The authors are Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli and Théo Zimmermann. The paper went up on July 27, 2026.

What the original attack was

Ken Thompson described the idea in 1984. You tamper with a compiler so it inserts a backdoor into the programs it builds. You also teach it to recognise when it is compiling itself, and to put the same tampering into the new compiler.

After that the malicious source code can be deleted. The backdoor keeps reproducing through every rebuild, and reading the compiler's source tells you nothing.

The defence community treated this as a compiler-specific threat. That assumption is what the paper attacks.

Why strip changes the picture

GNU strip removes debug symbols from compiled files. It never sees source code. It only rewrites finished ELF binaries, which is the standard executable format on Linux.

The researchers put one tampered strip into the NixOS binary seed, the small set of prebuilt binaries a distribution starts from before it can build anything itself. From there the payload copies itself into each new generation of strip.

It then survives into the final standard environment, after the original seed has left the dependency graph entirely. The tampered starting point is gone, and the backdoor remains.

They ran it on a real nixpkgs revision, fef9403a3e4d, with GNU binutils 2.44 on x86_64. The build completed without failures and produced a working graphical installer with almost every binary in it backdoored.

The defences that do not catch it

This is the part worth reading closely, because the standard answers fail in specific ways.

Defence	Why it misses this
Diverse double-compiling	The attack "sits on both sides of the comparison and cancels out"
Reproducible builds	Rebuilding with the same seed reproduces the implant bit for bit
Bootstrappable builds	Helps only in proportion to how small the binary seed is

Diverse double-compiling rebuilds a compiler with a second, independent compiler and checks the results agree. The authors note it "then checks that the two results agree", which is exactly the check a payload present in both paths passes.

Reproducible builds aim to "make every build produce bit-for-bit identical output", with an independent rebuilder confirming a binary matches its source. Identical output is not the same as clean output.

The paper does point at something that helps. "The full-source bootstrap in GNU Guix reduces the binary seed to a few hundred bytes and rebuilds the whole toolchain from auditable source above it," the authors write. A smaller seed means less unauditable material for an implant to hide in.

What this means for developers

Stop treating the trusted computing base as the compiler. Any binary in your bootstrap that transforms other binaries is in scope, and that includes strip, linkers, archivers and installers. Most threat models never listed them.

If you rely on reproducible builds for assurance, understand precisely what they prove. They prove your build is deterministic. They do not prove your inputs were clean, and this attack is deliberately deterministic.

If you run NixOS in production, note what has and has not happened. The attack was demonstrated on a real revision by researchers, with a replication package published. There is no public response from the NixOS project, and no evidence anyone has done this outside the lab.

The practical lever is seed size. Guix's few hundred bytes is a different order of risk from a conventional binary seed. Ask for that number when someone tells you their distribution is bootstrappable. Open-source governance has been busy this year, from Debian's vote on AI-assisted contributions to the Nixpkgs core team disbanding. This is a reminder that the build pipeline needs attention too.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

Sources

Trusting-Trust Attack against an Entire Linux Distribution (via the strip utility) - arXiv
Replication Package - figshare

Debian Code Search drops its last cgo dependency

techaiwire — Tue, 08 Sep 2026 03:29:02 +0000

Debian Code Search now runs without any C code. Michael Stapelberg replaced a seven-year-old C compression library with a pure Go version built on Go's experimental SIMD package, and reports it matches the C original for speed. "I deleted the last cgo dependency in Debian Code Search," he wrote on his blog on September 6, 2026.

Debian Code Search is the service that lets anyone search 130 GiB of source code across every Debian package. It has been running since 2012.

What TurboPFor does and why C was there

The library in question is TurboPFor. It is an integer compression format, used inside an inverted index to store lists of document IDs compactly.

That job is unglamorous and performance-critical. A code search engine spends much of its time decoding those ID lists, so the decoder sets the speed of every query.

Go can call C, through a bridge called cgo. It works, but it costs. Every call crosses a boundary, cross-compiling gets harder, and the build now needs a C toolchain as well as a Go one. Stapelberg had carried that trade for seven years because the C version was faster.

What the Go rewrite achieved

The rewrite leans on simd/archsimd, an experimental package that arrived in Go 1.26. SIMD stands for single instruction, multiple data: one CPU instruction operating on a batch of values at once instead of one at a time.

Two figures from the post stand out. Positional popcount encoding, a bit-counting step in the format, ran about twice as fast with the SIMD path. Full blocks decoded roughly three times faster than the plain scalar Go version.

Measure	Result
Positional popcount encoding	About 2x faster with SIMD
Full-block throughput	About 3x faster than scalar Go
Against the original C library	Parity, encoder and decoder
cgo dependencies remaining	Zero

Parity is the important word. The Go version does not beat C. It draws with it, which is enough to make the C dependency not worth keeping.

The catch: it is still an experiment

This does not work out of the box. The package is gated behind a build flag. Stapelberg quotes the requirement directly. "Go 1.26 introduces a new experimental simd/archsimd package," he writes, "which can be enabled by setting the environment variable GOEXPERIMENT=simd at build time."

An experimental package can change shape between releases, and the API here is deliberately architecture-specific rather than portable. We covered Go 1.27 adding a portable simd package alongside the architecture-specific one, which is the direction this is heading, but neither is stable yet.

What this means for developers

The transferable result is that the cgo escape hatch is narrowing. Plenty of Go projects keep a C dependency for one hot loop, and accept a harder build in exchange. If SIMD in Go can reach parity with hand-written C on integer compression, that trade is worth re-examining in your own code.

Check what you are actually paying for cgo before you start. It is not only speed. It is cross-compilation, build toolchains in CI, static linking, and the debugging that follows a crash across the boundary. Stapelberg's win is a simpler build as much as a faster one.

Do not put GOEXPERIMENT=simd into a production build yet. Experimental means the package can move, and an architecture-specific API means your code is not portable by default. Prototype with it, measure your own numbers, and keep the C path until the API settles.

If you want the implementation rather than the summary, the Go port is published separately as goturbopfor. The service it feeds is open source under the Debian organisation. Reading a real SIMD kernel written in Go is currently a short list, and this is on it.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

Go 1.27 adds generic methods and a faster encoding/json

Sources

Debian Code Search: Fast TurboPFor with Go SIMD - Michael Stapelberg
Debian Code Search - Debian
stapelberg/goturbopfor - GitHub

LLVM debates building ClangIR by default

techaiwire — Tue, 08 Sep 2026 03:26:10 +0000

LLVM developers are debating whether Clang should compile ClangIR into every build. Erich Keane posted an RFC titled "Enable ClangIR Build By Default" on the LLVM Discourse forum on September 6, 2026. It had drawn 34 replies by the time Phoronix reported it the same day.

The proposal is narrower than the headline suggests. Building it in is not the same as using it.

What is actually being proposed

ClangIR is a new intermediate representation for Clang. An intermediate representation is the form a compiler holds your code in between parsing it and emitting machine instructions.

Clang already has one, LLVM IR. ClangIR sits higher up, closer to the source language, and is built on MLIR. Sitting higher means it can keep information that LLVM IR throws away, such as which C++ construct a piece of code came from.

The code is already upstream. It is simply not part of the default build configuration, so most people compiling Clang from source do not get it.

The RFC would change that one thing. Code generation would still go through the existing path unless you pass -fclangir explicitly. Nobody gets ClangIR by accident.

The objections

Three concerns dominate the thread, and none is about whether ClangIR is good work.

Concern	The problem
Build time	Some estimates put build times more than doubling
Platform gaps	Microsoft and Windows targets are not supported
CI cost	Every test machine pays the longer build, on every run

The build-time figure is the one doing the damage. Adding MLIR as a default Clang dependency pulls in a large body of code that everyone compiling Clang would then compile too, including people who will never pass the flag.

That cost is not evenly shared. A distribution maintainer building Clang once absorbs it easily. A contributor rebuilding locally, or a CI fleet rebuilding on every pull request, absorbs it repeatedly.

Why anyone wants it on

The case for building it in is adoption. A feature nobody compiles is a feature nobody tests. Keeping ClangIR out of the default build means bugs surface only for the small group who opt in, and only after the code has already landed.

Turning it on by default makes it a normal part of the tree. Breakage shows up in ordinary CI rather than in a specialised bot, which is how a project stops an experimental component from quietly rotting.

Nothing has been decided. It is an RFC with an active thread, and the discussion is about cost rather than direction.

What this means for developers

If you build Clang from source, watch this thread rather than the outcome. Your build times are the thing being traded away, and the estimates in the thread are estimates. Measuring your own build with MLIR included is a better input to your planning than a number from a forum post.

If you run CI that compiles LLVM, cost this now. A doubling applied to every pull request is a budget line, not an inconvenience, and it arrives on whatever release first carries the change.

If you work on Windows toolchains, the platform gap is your cue to speak up. The RFC names the absence of Microsoft target support as a blocker, and RFC threads are where that gets weighted. Open-source projects have been formalising exactly this kind of decision lately, from GNOME drafting an RFC process to Debian voting on AI-assisted contributions.

And if you just use Clang from a package manager, this changes nothing yet. You would get a slightly larger compiler binary and an extra flag you can ignore.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

Sources

LLVM Developers Discuss Enabling ClangIR Build By Default - Phoronix
RFC: Enable ClangIR Build By Default - LLVM Discourse

TryNix runs any Nix package in a browser tab

techaiwire — Tue, 08 Sep 2026 03:23:18 +0000

You can now run any package from the entire history of nixpkgs without installing anything. Farid Zakaria published TryNix on September 4, 2026. It boots a Linux kernel compiled to WebAssembly inside a browser tab, then runs the package you asked for.

"You can browse the complete history of nixpkgs, over 310,083 package versions, and run any of them in a Linux machine that boots in your tab," Zakaria wrote.

Nixpkgs is the package collection behind Nix and NixOS. Its defining property is that every version ever published stays addressable, which is what makes a claim like this possible.

How it actually works

The pieces are all existing technology, assembled unusually.

A Linux kernel compiled to WebAssembly through QEMU-WASM provides the machine. Ghostty, a terminal emulator, provides the interface. An in-memory Nix store holds the package closure, which is the package plus everything it depends on.

The packages themselves come over plain HTTP from Nix binary caches. That part has one requirement, and Zakaria states it plainly: "The only requirement is that the cache is served with access-control-allow-origin: *."

That header is the whole trick. Nix caches are already public HTTP file servers, so with permissive cross-origin headers a browser can fetch from them directly, with no server in between.

What it costs to start

Cold starts are seconds, not minutes.

Package	First visit	Return visit
hello	4.2s	1.5s
ripgrep	4.3s	1.7s
python3	7.5s	3.5s

The gap between the two columns is browser caching doing its job. A second run of the same package skips most of the download.

The limits are real

Three constraints decide whether this fits your use.

Closure size caps out around 1.5GB, against a hard WebAssembly ceiling of 4GB. Large toolchains and anything dragging in a big language runtime will not fit.

There is a serial console and nothing else, per the repository. No graphical applications, no windowing, no browser inside the browser.

And everything is translated from x86-64 to WebAssembly at runtime, which adds latency. This is a place to try a tool, not to benchmark one.

What this means for developers

The immediate use is reproduction. Zakaria puts it as a slogan worth stealing: "Works on my machine" is a URL now for reproduction. A bug report that includes a link booting the exact package version is a different quality of bug report from one that includes a version string.

For anyone maintaining docs or a teaching repo, this removes the worst step in every tutorial. "Install Nix first" loses readers. A link does not.

Check your own binary cache headers if you want this to work against your packages. The cross-origin header is the requirement, and most private caches will not have it set. That is a one-line change and a security decision worth making deliberately, since it opens the cache to any origin.

Do not plan around it for heavy work. Between the 1.5GB closure ceiling and the translation overhead, this is a demonstration surface, not a development environment. The Nix ecosystem has had a rough few months. The Nixpkgs core team disbanded, and a paper backdoored the NixOS bootstrap through strip. A project making the good part of Nix easier to show is welcome timing.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

Sources

Any Nix package, live in your browser - Farid Zakaria
fzakaria/trynix - GitHub

NetBSD 11 adds 64-bit RISC-V and a 10ms microVM kernel

techaiwire — Tue, 08 Sep 2026 03:09:53 +0000

NetBSD 11.0 is out, and it is the first stable version of the system that runs on 64-bit RISC-V chips. The project announced the release on July 30, 2026. That matters for two reasons. An open chip architecture gains a mature Unix, and a new kernel option boots a virtual machine in about 10 milliseconds.

NetBSD is a free Unix-like operating system, which means it behaves like Unix without using Unix code. The project's stated goal is portability: running one system on many kinds of machine. Version 11.0 is its nineteenth major release.

The project posted the news to its blog on August 1, 2026. "The NetBSD project is pleased to (finally) announce the 11.0 release!" the post said. The word in brackets is the project's own.

The 64-bit RISC-V milestone

RISC-V is an open instruction set, which is the basic vocabulary a processor understands. Anyone can design a chip around it without paying a license fee. That is why it attracts hardware startups, universities and researchers.

Version 11.0 is, in the release notes' words, "the first stable release to include support for 64-bit RISC-V platforms." The first boards supported are built on StarFive's JH71XX chips. Those are the VisionFive 2 and the PINE64 STAR64, both small single-board computers. Phoronix listed the same two boards in its report on August 1, 2026.

The release also adds preliminary support for Qualcomm Snapdragon X Elite devices. Preliminary means the system starts but the work is unfinished. Asahi Linux took a similar step for Apple hardware last week, when it added official M3 Mac support.

A kernel built for fast boots

NetBSD 11.0 ships a new kernel for x86 and amd64 machines called MICROVM. Its purpose is what the release notes describe as "extremely fast virtual machine boot." The figure the project gives is "about 10 ms."

A virtual machine is a whole simulated computer, so it normally takes seconds to start. Cutting that to milliseconds puts it near the speed of a container, which shares the host kernel instead of booting its own. The trade-off matters because a virtual machine isolates code far more strictly than a container does.

What else changed

The rest of the release is spread across the firewall, the Linux compatibility layer and the standards the system targets.

Area	Change in NetBSD 11.0
npf firewall	Adds "layer 2 and user/group filtering"
Linux compatibility	compat_linux(8) gains epoll, POSIX message queues and statx
Standards	Better "compliance with POSIX.1-2024 and C23 programming interface standards"
Platforms	Over 60 supported

The bundled developer tools also moved up.

Component	Version in 11.0
GCC	12.5.0
OpenSSL	3.5.7
GDB	15.1
SSH	10.3

Phoronix also reported SIMD-accelerated optimizations in the release. SIMD lets one instruction act on several pieces of data at once.

Putting it on a 2012 laptop

Five weeks after the release, a developer published a full manual install. The post, "NetBSD 11 from scratch", appeared on September 6, 2026. It uses a 2012 HP Pavilion with an Intel Core i7, 3.79 GB of memory and a 900 GB disk.

The guide sets up full disk encryption with CGD, NetBSD's cryptographic disk driver. It uses the adiantum cipher and derives the key with pkcs5_pbkdf2/sha1. The root partition is 50 GB.

The author gives one non-technical reason for the choice: NetBSD's stance against putting generative AI into the project.

What this means for developers

The MICROVM kernel is the piece worth testing first. If you build sandboxes, CI runners or per-request isolation, a 10 ms boot brings a real virtual machine close to container startup times. Measure it on your own workload before you trust the number, because boot time is only one part of total latency.

If you target RISC-V, NetBSD is now a second mature option beside Linux. A VisionFive 2 or STAR64 board is the cheapest way to try it. Check the drivers you need first, since first-generation support usually covers the basics only.

The compat_linux additions matter if you run Linux binaries on NetBSD. epoll and statx are common in modern server software, so a tool that failed before may work now. Test it rather than assume it.

The C23 and POSIX.1-2024 work also makes NetBSD a useful portability check. Building your C code there tends to expose assumptions that Linux and glibc quietly forgive.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

Asahi Linux now officially supports M3 series Macs

Sources

Announcing NetBSD 11.0 (July 30, 2026) - NetBSD
NetBSD 11.0 Released With RISC-V Support, Enhanced Linux System Call Compatibility - Phoronix
NetBSD 11 from scratch - MeanMicio

AMD Zen 6 makes Linux's SafeRET mitigation unnecessary

techaiwire — Tue, 08 Sep 2026 03:09:50 +0000

AMD's next generation of processors will let Linux stop applying one of its speculation defenses. A kernel patch titled "x86/bugs: Adapt SRSO mitigation to Zen6" landed in the tip tree on September 1, 2026. It matters because the chip now does in hardware what the kernel had been doing in software, and software mitigations run on every affected machine.

The patch was written by Borislav Petkov, a kernel engineer at AMD. He authored it on August 21, 2026 and committed it himself on September 1, 2026.

The attack being defended against

Modern processors guess what code will run next, which is called speculation. The guess keeps the chip busy instead of waiting. When the guess is wrong, the work is thrown away.

The problem is that the discarded work leaves traces. An attacker who can steer those guesses may get the processor to briefly touch data it should not, then read the traces to infer it. SRSO, short for Speculative Return Stack Overflow, is one such flaw. It targets the predictions the chip makes about where a function returns to. Phoronix reports that SRSO affected the Zen 1 through Zen 4 generations.

Linux answered SRSO with a software mitigation called SafeRET. That is the piece Zen 6 makes unnecessary.

What Zen 6 changes in hardware

The branch target buffer is a small cache where the processor keeps its guesses about where a jump in the code will land. If one program's entries can influence another's, those guesses become an attack surface.

Zen 6 separates them. "Zen6 has BTB protection which isolates the different contexts (user/kernel, guest/host) from one another," the commit message says. Phoronix calls the feature BTB CTX isolation, short for branch target buffer context isolation.

Two boundaries are covered by that description. One is between a normal program and the kernel. The other is between a virtual machine guest and the host running it.

What the patch actually does

The change is small and touches three files in the x86 code.

Item	Detail
Commit	"x86/bugs: Adapt SRSO mitigation to Zen6"
Author	Borislav Petkov (AMD)
Written	August 21, 2026
Committed to tip	September 1, 2026
Files changed	3
Target kernel	Linux 7.4, with 7.3 possible as a fix, per Phoronix

The three files are arch/x86/include/asm/cpufeatures.h, arch/x86/kernel/cpu/bugs.c and arch/x86/kernel/cpu/scattered.c. The kernel detects the new hardware behavior and then reports the situation through a new mitigation string.

What software still has to handle

The hardware protection does not cover everything, and the commit is explicit about the gap.

User-to-user and guest-to-guest attacks are still not handled by the chip. Those are cases where two programs at the same privilege level, or two virtual machines, attack each other. For those, the kernel keeps relying on the Spectre v2 mitigation settings to issue an IBPB on a context switch.

IBPB stands for Indirect Branch Predictor Barrier. It tells the processor to discard its accumulated branch guesses, which stops one workload's predictions from carrying into the next.

What this means for developers

Do not read this as "Zen 6 ends speculation mitigations." It removes one specific software fix at two specific boundaries, and it leaves same-privilege isolation to software. If you run untrusted code from different tenants on one host, your Spectre v2 configuration still matters as much as it did.

Check what your kernel reports rather than assuming. The patch adds a new mitigation string. Once you are on a kernel carrying this change, the state your machine is actually in shows up in the kernel's own reporting.

If you track mitigation overhead in your benchmarks, plan to re-baseline. Comparisons taken on Zen 4 with SafeRET active will not describe a Zen 6 machine without it, so old numbers should not be carried forward.

There is also no hardware to test against yet. These sources give no ship date for Zen 6 processors, so treat this as the kernel getting ready rather than a change you can measure this quarter. Kernel protection defaults move in both directions, and it is worth remembering the cost side: Microsoft is switching on Windows 11's memory integrity by default from October 13.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

Windows 11 turns on memory integrity by default from October 13

Sources

Linux Preps For New AMD Zen 6 BTB CTX Isolation Security Feature - Phoronix
x86/bugs: Adapt SRSO mitigation to Zen6 - kernel.googlesource.com