Linux on Snapdragon X2: what changes for AI in your code

Qualcomm used Snapdragon Summit to announce that Linux is coming to the Snapdragon X2 line. For developers, that matters more than any "agentic PC" slide. Linux on Snapdragon X2 means an ARM laptop with phone-level battery life and a dedicated NPU, running the OS where almost all of our server code lives. On paper, at least.

The original announcement is on the Qualcomm blog. Here I explain why it took so long, what actually changes in your workflow and what I still want to see working before I buy.

Why Linux on Snapdragon X2 is news

The first generation, the Snapdragon X Elite, came out in 2024 with a total focus on Windows. Linux did run, but in the way anyone who has installed a distro on new hardware knows well. Boot works. Keyboard works. Then suspend fails, audio disappears, the GPU has no acceleration and the webcam doesn't exist.

There was a lot of good upstream kernel work, with Linaro and the community helping. Even so, the experience depended on the exact laptop model and a good dose of patience. One Linux-focused manufacturer even shelved its own X Elite laptop because support never got quite right.

The X2 arrives with a new generation Oryon CPU and a Hexagon NPU announced at around 80 TOPS. Strong hardware was never the problem. The problem was the software around it. When Qualcomm itself starts treating Linux as an official target, the message is different: drivers stop being a volunteer hobby and become a product commitment.

Hardware without drivers is just an expensive paperweight.

What the NPU has to do with AI in your code

The pitch at the event is the "agentic PC": AI agents running on your laptop, without sending everything to the cloud. For developers, the practical translation is simpler. It means running a code model locally, local autocomplete, local embeddings to search your repository.

Today, anyone doing this on Linux basically uses the CPU or GPU. Ollama and llama.cpp work well on ARM64 through the CPU. A quick test:

uname -m
# aarch64

ollama run qwen2.5-coder:7b "explain this regex: ^(?=.*\d)[a-z\d]{8,}$"

It works. But it doesn't touch the NPU. And here's the point almost nobody mentions: having 80 TOPS of NPU is useless if the runtime you use can't talk to it. On Windows, Qualcomm pushes its own stack with ONNX Runtime and QNN. On Linux, the question that matters is whether that path will exist in a stable, packaged form, without you compiling a proprietary SDK on a Sunday afternoon.

If the NPU works well on Linux, this is the real gain: a small autocomplete or embeddings model running all day without heating up the machine and without eating the battery. That changes how you use AI in the editor. You stop thinking "I'll call the API" and start having an always-on assistant, free, that doesn't send your private code anywhere.

If the NPU doesn't work, you have a great ARM laptop with Linux. Which is already good, but it's a different conversation.

What changes in your workflow with ARM

This is where the news really hits the full stack dev, with or without AI. An ARM laptop running Linux means your local machine now has the same architecture as a Graviton on AWS or an Ampere on Oracle Cloud. That has a good side and an annoying side.

The good side: local ARM builds without emulation. If you deploy to ARM instances to save money, you finally test on the same target.

The annoying side: anything that assumes x86 will blow up in your face. A few things I'd check on day one:

• Docker images. If the base image only has amd64, Docker will emulate it with QEMU. It works, but it's slow. Publishing multi-arch is worth it:

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t my-api:latest --push .

• Native dependencies in Node. sharp, bcrypt, better-sqlite3, database drivers. Most already ship a linux-arm64 binary, but one abandoned package in the middle of the tree can fall back to node-gyp and ask for a compiler.
• Binaries downloaded in scripts. That curl | tar in the Dockerfile or in CI that downloads a CLI with x86_64 hardcoded in the name. This is the one that shows up most.
• Compiled Bun. If you ship binaries with Bun, you can already target ARM directly:

bun build ./src/cli.ts --compile --target=bun-linux-arm64 --outfile cli

None of this is new for anyone using a Mac with an M chip. The difference is that now the environment is real Linux, without the VM layer Docker Desktop adds on macOS. Your docker run runs natively. For anyone who lives in containers, that's a real gain.

What still needs to be proven in practice

An announcement at an event is a promise. Here's what I'll be watching when the first laptops reach the community:

1. Upstream or fork? If support depends on a custom kernel from the manufacturer, you're stuck with whatever version they maintain. If it's in the mainline kernel, every distro inherits it.
2. Real GPU acceleration. Without a decent GPU driver, the browser suffers, VS Code suffers and you give up within a week.
3. Suspend and resume. Sounds like a detail. It isn't. A laptop that doesn't wake from suspend becomes a desktop with a battery.
4. NPU reachable through an open runtime. I want to see ONNX Runtime or llama.cpp using the NPU on Linux without hacks. This is the item that justifies the whole "AI in your code" angle.
5. Distros with official images. Ubuntu and Fedora booting on the first try, without a device tree downloaded from a forum.

If items 1, 2 and 3 come ready, it's already a good dev laptop. Item 4 is what turns the machine into something different from a MacBook running Linux.

Is it worth replacing your dev laptop now?

My honest answer: not yet. Wait for the first real reports.

Buying hardware in launch week because of promised Linux support is an extreme sport. People who did that with the X Elite found out that "supports Linux" can mean "it boots and the rest is on you". I've been that person with other hardware. I spent more time reading kernel issues than writing code, and my client wasn't paying by the hour for dmesg.

That said, the direction is good and I'm rooting for it. More ARM competition on the Linux desktop forces everyone to publish multi-arch binaries. That improves the ecosystem even for people who stay on x86. And if the NPU becomes accessible, local AI stops being something for people with a 2,000 dollar GPU and becomes a factory default on regular laptops.

In practice, you can start today without buying anything: make sure your project builds for arm64. Run multi-arch buildx in CI. Replace downloads with hardcoded architectures in the name. When the hardware is mature, you just open the lid and get to work.

My bet: the X2 with Linux will be a great dev laptop long before it's a good "agentic PC". And that's fine. A laptop that lasts all day, runs containers natively and doesn't overheat already solves more of my problems than any agent I've seen on stage. If you want to see how I organize builds and deploys in my work, take a look at my projects.

Qualcomm promised Linux on Snapdragon X2. I'm still not buying one.

An ARM laptop with phone-level battery life, an 80 TOPS NPU and the same OS as our servers sounds like a dream for anyone who writes code.

The problem is that hardware without drivers is just an expensive paperweight. And 80 TOPS are worth nothing if your runtime can't use the NPU.

Before I open my wallet, I want to see four things working: mainline kernel support, accelerated GPU, suspend without surprises and an NPU reachable through ONNX Runtime or llama.cpp.

In the meantime, you can get ready without spending a cent: multi-arch builds in CI, arm64 images and no downloads with x86_64 hardcoded in the name.

My bet is that it becomes a great dev laptop long before it becomes a good "agentic PC". In the full article I explain what changes in your workflow.

#Linux #ARM #Snapdragon #AI #SoftwareDevelopment