Qualcomm has put out an early developer preview of Linux for Snapdragon X2 Series laptops, asking kernel developers, distro maintainers, and hardware enablement engineers to get on this hardware and start testing.
They have been laying the groundwork for this since Snapdragon Summit 2025, and the push today is toward getting drivers into mainline rather than shipping out-of-tree patches that only a handful of people can maintain.
The current preview pairs a Debian 13 "Trixie" userspace with a custom kernel, and the initial focus is on readying up the core pieces developers need before they can do any serious work on the hardware.
System boots are handled via systemd-boot acting as the UEFI manager, while Core I/O covers USB, PCIe, and the Qualcomm Universal Peripheral serial engine for UART, I2C, and SPI connections.
Whereas Mesa's open source Qualcomm drivers handle graphics duties, with Freedreno covering OpenGL, Turnip taking care of Vulkan 1.3, and Rusticl handling OpenCL compute.
Work on all three is ongoing, but display output, browser acceleration, and GPU compute workloads are already possible.
The FastRPC driver, Qualcomm's mechanism for routing compute tasks from the CPU to the DSP, is being pushed upstream to open up the Hexagon NPU for local AI inference workloads. Power management and thermal support are part of this series of developments too.
Two build paths
The official documentation for Snapdragon X2 Linux software outlines two paths that developers can follow.
The first is the unregistered path, where you build the Debian OS layer using prebuilt firmware binaries, getting started without a Qualcomm developer account. The second requires an account, giving you full firmware source access to build everything from scratch.
Prebuilt flashable images are also available if you want to skip the build entirely and go straight to flashing.
Host requirements also differ by what you are building. The Debian layer needs an ARM64 machine running Ubuntu 24.04 LTS or later, or Debian Trixie. The firmware build requires an x86_64 host on Ubuntu 22.04 LTS or later.
If you want to see a hands-on demo of Linux unning on Snapdragon X2 hardware, then this year's Snapdragon Summit (ends today) in Maui, Hawaii, is the place to be!
More of this, please
A staged roadmap, a documentation portal, dedicated build scripts in a public repo, and turning to developers for feedback is something other silicon vendors looking to upstream their work should take note of.
In the end, Linux wins. Every driver that lands in mainline is one fewer patch that distributions have to carry, and that is what eventually makes these machines usable beyond early adopters.
openKylin is China's homegrown, open source operating system which is developed by a consortium of companies, research institutes, and individual contributors.
We have covered openKylin in the past but that was more than two years ago. There is a new major release in the form of openKylin 3.0 that brings Linux kernel 7.0, UKUI (desktop environment) 4.24 and deeply integrated AI at the core.
Let's see the highlight of the new release.
AI is at the center of openKylin 3.0
Among the most highlighted changes in the new release is the built-in, all-new KylinBot AI agent framework, along with Xiao K, the AI assistant built on top of it.
Xiao K is basically the graphical interface similar to Hermes Desktop and most other AI tools of this sort. The underlying KylineBot AI agent framework integrates it with the system.
And then it comes with several pre-built system skills like:
Input Devices: Full coverage for keyboard, mouse, and touchpad.
Display Control: Screen brightness and OSD display adjustments.
Network Management: Deep integration with the NetworkManager command-line tool to manage Wi-Fi, Ethernet, and VPNs with a single command.
Peripheral Management: Bluetooth toggle, device discovery, and automatic audio device pairing.
System Controls: Power management, taskbar operations, shortcut navigation, and system app controls
Custom skills to interact with your desktop
This way, you can ask the agent in Xiao K to switch off the bluetooth or switch to a different network, change the input keyboard layout and more. You don't need to go through the command line or click through the system settings. The agent does the job for you.
Seems like overkill, right? But it makes more sense if you use the voice input. People these days use Siri hands-off for calling to specific contacts. So, if you could just talk to your computer and ask it to connect to your bluetooth headphone, why not?
Remember that Ubuntu 26.10 is also working on AI integration. Omarch 4.0 got a sudden surge in popularity for AI (and its looks). So, even if you dislike AI, there is a demand for it. And sooner or later, most desktop operating systems will have built-in AI assistants like this. openKylin is just a few steps ahead of its peers.
There are more skills that can be found on openKylin's repo here. It is in Chinese language and I do hope they start offering these features in English as well to cater a larger global audience.
Like Hermes, OpenClaw and other AI tools, Xiao K doesn't stay to your desktop only. You can communicate with it from messaging tools like WeChat, Feishu, DingTalk etc. Telegram and Discord support is planned.
UKUI version 4.24
The UKUI (Ultimate Kylin User Interface) desktop environment is upgraded to version 4.24. The new version brings the following updates:
Standardized API encapsulation across UKUI modules and integration with KACP (Kylin Agent Control Protocol), enabling KylinBot to invoke underlying desktop capabilities via unified APIs.
The new version also brings accessibility support in the form of a screen reader. It also has air gesture controls, which means you can control some desktop functionality with the movement of the hands instead of touching the screen or using a mouse or keyboard.
This works on Android devices thanks to the proximity sensor in the smartphone. Here, Kylin uses the webcam to capture the hand gestures.
The feature to enable dynamic wallpaper is also added for enhanced eye candy. In other visual changes, "Three-Island" taskbar layout mode is added as an option.
Touchpad gets enhanced multi-finger gesture interactions, supporting multitask view, volume control, and other actions using 3-finger and 4-finger gestures.
Rustification
Since both AI and Rust are in trend these days, openKylin 3 has new Rust-based utilities that replace the older, classic utilities.
kylin-time replaces the legacy time utility, kylin-wget replaces the classic wget and kylin-ki18n replaces the ki18n.
Getting openKylin
If you want to give it a try, you can download openKylin from the official website. The ISO is a little over 7 GB. The size is primarily because the OS comes with pre-installed AI models.
I plan to test openKylin 3.0 on my spare system. It is okay in VM, but since there is a lot of AI integration and I would like to use them to see how effectively they work on a baremetal system. I will share my findings in a review video. Stay tuned for that.
Contrary to what you might expect of a newly launched Linux distribution, Gravity Linux has a long-term goal of not existing as a distro. The project is a Fedora Remix for Apple Silicon Macs that ships with KDE Plasma on Wayland as the default desktop.
Everything in it is built through clean-room reverse engineering, ensuring that no Apple source code, disassembly, or leaked technical information makes its way into the code for this project.
Two developers, Cody Ho and Niklas Sheth, are the main driving forces behind this, forking it from Asahi Linux with a shared goal of bringing Linux to Apple Silicon.
They went down this path due to a difference in contribution policy around LLM use.
Gravity Linux's position is clear from its commit history, where the project's kernel branch carries commits with Assisted-By tags openly crediting AI coding tools alongside the human author.
What its first release delivers
An overview of what's working and what's not.
The first alpha runs on the M4 Mac mini, and both the display controller (DCP) and GPU are working, with OpenGL ES 3.0 and OpenGL 3.3 compliance incorporated, meaning hardware-accelerated graphics is available from the first boot.
Keep in mind that this is a developer-focused alpha release with a few shortcomings that make it unfit for daily use. Suspend does not work, Thunderbolt and USB4 support is nonexistent, and USB-C display output is not supported, though output via HDMI works.
Shutdowns and reboots are described as inconsistent, with the power button recommended as the workaround for getting a predictable experience. Speaker volume is also capped for hardware safety.
Users should also understand that a full reinstall will be needed when the beta arrives sometime later, as the Gravity Linux team does not guarantee an upgrade path from the alpha release.
You can get it for your machine by running this:
curl -fsSL https://install.gravitylinux.org | sh
Distro with an expiry date?
Even though the M4 Mac mini is the first target, it's not the only one. Current plans cover the MacBook Neo and the remaining M4, M4 Pro, and M4 Max lineup, with some new contributors already making progress on several of those devices.
M5 is a different story. On M5 Pro and M5 Max hardware, macOS 27.0 Beta 5 leaves the devices misconfigured at boot, preventing secondary CPU cores from starting. Apple supposedly knows of this issue, but there's no news on when a fix will be delivered.
Gravity Linux also plans to keep the entire M5 lineup on the same firmware version before shipping support, so M5 stays on hold until Apple addresses that issue.
The final goal is to upstream all of its driver work to the Linux kernel and relevant userspace projects while documenting its reverse engineering methods publicly at every step.
The GitHub organization already reflects that direction. Beyond distro-layer scripts, the project maintains forks of the Linux kernel, Mesa, and U-Boot. These are the same upstream projects where this work ultimately needs to land.
Once that upstream work lands, any mainstream Linux distribution would run on supported Apple Silicon hardware without needing a separate remix like this. At that point, Gravity Linux the distro stops being necessary, and that is when the team plans to sunset it.
I mistakenly sent the Local AI Weekly to the subscribers of FOSS Weekly. My bad. A long, tiring day led to this mishap. Won't happen again (hopefully).
Welcome to issue #3. I said weekly last time and here we are, one week later. Small victories.
This issue has a theme, and it's money. I guess I am not the only one who thinks that the generous Claude and Codex subscriptions people are enjoying right now are just to get you addicted to using AI.
And it's quite evident, isn't it? A big credit giveaway comes first. Then the models quietly get dumber. Then your credits start burning faster than they used to. Then the price goes up or the offer just ends.
If you've rebuilt your workflow, or worse, your company, on top of this "generosity", you may find yourself in a tough spot when the token price starts going up. The $20/$200,$2000 a month pricing you're planning today, won't give you the same thing in long run.
Which is exactly why the local AI is going to go big. Not every task needs a frontier model. A lot of them need a small model, running on hardware you already own, wrapped in a harness tuned to your work.
Before we get into it, thanks to Monid for supporting this edition.
Think of Monid as OpenRouter, but for agent tools. One base URL, one key, and an agent can reach 2,000+ tools across 72+ providers. The connector layer went open source under MIT, and because connectors are declarative, adding your own API is a pull request a coding agent can write for you.
I promised you an Unsloth verdict last issue and I owe you that. But I got distracted by Buzz, an open source communication tool built for agents and humans to work together. I actually liked Buzz. There is smartphone app too and thus staying connected in not an issue. It could replace Discord for team It's FOSS.
📥 Agents are getting an inbox
Two biggies independently landed on the same idea at alsmot the same time, and it's a good one. Chat is a bad interface for an agent that works while you're asleep.
Cloudflare open sourced agentic-inbox, a self-hosted email client with an AI agent built in, running entirely on Workers (so it is cloud, not your GPU). Incoming mail arrives through Email Routing, each mailbox lives in its own Durable Object with a SQLite database, and attachments go to R2. The agent reads your inbox, searches conversations, and drafts replies that you approve before they send.
AWS did something similar with Pizza Bot. It's an Apache 2.0, local-first inbox for long-running agents, built on DeepAgents and LangGraph. Finished work shows up as unread threads and anything needing your approval gets flagged.
Unlike agentic-inbox, this one runs on your machine with no telemetry, storing threads, checkpoints, memories and logs as SQLite files in a local folder. You pick the model provider, and Ollama is on that list. So you can run the whole thing locally, even offline.
🔍 Discover AI tools
Two finds this week, and they sit at opposite ends of the "what is AI for" question.
First, OpenPencil, an MIT-licensed, AI-native design editor that opens and writes native Figma .fig files. You can copy nodes between it and Figma. It ships a headless CLI, an MCP server so coding agents can read and edit your designs, and a roughly 7 MB Tauri desktop app that needs no account. Built on Vue 3, Skia for rendering and Yoga for layout. Local model support is on the roadmap.
The second AI tool is kind of anti-AI tool. Sounds weird, I know but hear me out. AI-based auto transcribers are part of almost all meeting tools. Not everyone wants to be heard by AI, specially that sends data to server for further training, probably.
Kalypta runs a small model locally on your device and reshapes your audio in real time so that AI transcribers can't make sense of what you said. The goal is to be inaudible to the note-taking bot in your meeting while staying perfectly clear to the humans. Interesting project to watch out for.
📡 Open Model News
The big one is Qwen-Image-2.1. It's a small text-to-image model and some people are already calling it the Nano Banana alternative. Not available on Ollama yet probably because weights ship under the Qwen Research License, which is non-commercial and requires you to email Qwen for a commercial licence. Another reminder that open weights and open source are not the same thing.
The other release worth your time is small in a different way. You've probably seen Jev everywhere for the past week, TypeSafe AI's "System One" model that doesn't generate text at all. The open source alternative to Jev is laya-mlx, an Apache 2.0 native MLX port of Laya, the typed decision model from Convai Innovations. Available only for Apple Silicon model for now.
👀 Big Tech Watch
Microsoft rewrote the GitHub Copilot agent runtime from TypeScript into more than 800,000 lines of production Rust, and one engineer drove most of it with a fleet of AI agents. It took 128 pull requests over about fourteen and a half weeks, shipped incrementally.
The whole migration cost around $120,000 in tokens. That's 136.3 billion tokens, of which 130.6 billion were cached input reads.
Think about what that means for the rest of us. That project only worked because 96% of the tokens were cache hits billed at roughly a tenth of the normal rate. Remove the caching and the whole thing will be far from a profitable migration. This is the token economics I was talking about earlier.
🗂 AI Jargon: Prompt caching
Since caching reduced the migration bill for Microsoft, let's learn more on it.
Here's the thing. Every time you send a request to a model, it has to read your entire prompt and build an internal representation of it before generating a single token. In a long agent session, that prompt is mostly the same every turn: the system prompt, the tool definitions, then the conversation so far, with a bit of new text on the end.
Prompt caching means the provider saves the intermediate computation for a prefix it has already processed. Send the same prefix again and it reuses that work instead of redoing it. Providers typically bill a cache hit at around a 90% discount, so a million input tokens might cost $2.00 fresh and $0.20 cached.
This is why agent harnesses are built to save on tokens. They keep a long, stable prefix and only ever append to it, because anything that changes the beginning of your prompt invalidates the cache and multiplies your bill by ten.
How does it impact local inference? Well, on your own hardware there's no per-token bill, so the equivalent optimisation is KV cache reuse. So you win on latency instead of money.
⚡ Quick Tip: Check whether Ollama is actually using your GPU
Last issue I told you how to keep models warm. Here's a similar check.
Run ollama ps while a model is loaded. Alongside the model name and size you'll see a PROCESSOR column telling you whether it's on GPU, CPU, or split between the two with a percentage.
If a model doesn't fit in VRAM, Ollama will quietly offload some layers to system RAM and keep working rather than failing. It runs; you get answers, but it will sluggish.
If you see anything other than 100% GPU and you expected it to fit, drop to a smaller quantisation or shorten your context window. A Q4 model fully on the GPU will usually beat a Q8 model that's splitting between CPU and GPU.
In the end...
I am not doomsaying, but I would like you to plan for the future beyond the cheap phase of frontier AI. Build your harness and use local models in your workflow wherever it makes sense. I understand that hardware is not cheap these days but there are smaller models that can fit niche scenarios.
I welcome your feedback and I'll see you next week (because it's a weekly newsletter)..
AI is moving fast. Its jargon is moving even faster. Half of it doesn't mean what you'd guess from the name. After all, tokens are not coins. Terms like harness and quantization are everywhere in local AI conversation, and often people don't even know what these terms mean.
I put together this quiz to test how well you actually know the words you're using. It is a little quiz with just ten questions, one correct (and hopefully funny) description per term.
Guess the term, then check your reasoning against the explanation, in case your answer was a pure guess.
You don't need to be an AI researcher to do well here. If you've spent any time running models locally, on Ollama, llama.cpp, or anything similar, you've probably bumped into most of these already.
🚧
Some browsers block the JavaScript-based quiz units. Disable your ad blocker to enjoy the quizzes and puzzles.
How many did you get right? Drop your score in the comments.
Interested in local AI? Subscribe to our brand new newsletter, Local AI Weekly. The name is self-explanatory, I believe.
If you run a lightweight distro and you do not like the fact that Wayland will probably become the default, PeppermintOS has some news you should know about. It's switching its display server from the soon-to-be-retired Xorg to XLibre for its next round of ISO refreshes.
It may look like a sensible call as it keeps X11 alive and skips Wayland (for now). However, XLibre is one of the divisive projects in the Linux world right now. Choosing XLibre won't sit well with some people, at least.
Moving away from Wayland and Xorg
In a recent blog, PeppermintOS announced it's shifting the display server from xorg-server to XLibre across its upcoming builds.
Reason is simple. Development on the original Xorg has stalled and most distributions have switched to Wayland. XLibre exists with the aim to keep maintaining, modernizing, and cleaning up the codebase for people who still prefer X11.
XLibre is built as a drop-in replacement for xorg, and it aims not to break standard desktop environments, window managers, or older drivers, and PeppermintOS says its testing so far has gone as expected.
PeppermintOS says it has no immediate plans to move to Wayland, pointing to XFCE's roadmap of supporting both Xorg and Wayland natively. Xfce is the default offering from PeppermintOS.
By the way, this is the project's first Debian-based ISO built without Debian's traditional live-build tools, moving instead to mmdebstrap, mirroring what PeppermintOS already did for its Devuan edition.
The important point for existing PeppermintOS users is that the interface and overall experience stay identical to the current stable release. The change is under the hood.
Choosing Xlibre will get some eyerolls
Why? Because critics argue XLibre is more of a political fork than a technical one. Also, Xlibre has been in the news for some not-so-positive reasons.
XLibre is a fork of the X.Org server started in mid-2025 by Enrico Weigelt, who was the top commit contributor to Xorg in 2024. Weigelt was banned from freedesktop.org's GitLab around the time the fork went public.
Artix Linux made XLibre its default X server in April 2026, then reversed course. With its August 2026 release it switched back to Xorg as the default, a decision it says it took after an unusually high volume of XLibre-related bug reports.
Artix then went further and announced it would stop packaging XLibre entirely. They shared that the switchback drew backlash from XLibre, and a veteran Artix developer known as "Artist" was targeted and harassed to the point of resigning. Existing XLibre users on Artix are being moved back to the corresponding Xorg packages.
What next?
XLibre being controversial doesn't make it technically broken. The controversy is about the project's conduct and politics, not whether it draws windows. PerppermintOS is testing it and found to be working well. Let's hope it stays that way and we keep on getting choices on the display server scene.
That's very interesting to see considering OpenSearch began as a fork.
When Elastic relicensed Elasticsearch and Kibana in 2021, AWS built an open alternative, keeping it under the Apache 2.0 license. Three years later, the project moved to neutral governance after the Linux Foundation launched the OpenSearch Software Foundation in September 2024 as its vendor-neutral steward.
Now, reflecting on the journey so far, Linux Foundation Research and the OpenSearch Software Foundation have jointly published The 2026 Open Data Infrastructure Report, examining how organizations are building out data infrastructure and what role OpenSearch plays in that picture.
The survey, conducted in May 2026, covered 294 respondents across diverse categories like IT vendors, end-user organizations, and independent consultants.
The report, briefly
Generative AI and LLM-powered applications lead all AI use cases at 82% of organizations surveyed.
At least 83% of respondents across every region are already running AI workloads or have plans to. Among current OpenSearch users, 62% are already using it in AI workloads, and 44% consider it core AI infrastructure rather than a supporting component.
By 2026, 89% of organizations had heard of OpenSearch, up from 68% two years prior. Production deployments went from 19% to 36% over the same period, with another 36% running tests or assessing adoption.
Cost and vendor independence are what organizations weigh most when picking a data infrastructure platform. Total cost of ownership tops the selection criteria for 80% of organizations, security and compliance for 79%, and vendor independence for 69%.
71% also say running infrastructure outside any single cloud provider's control is a strategic priority for their organization, while average annual data infrastructure spend across the sample sits at around $2.4 million.
Among active users, search and retrieval leads at 91%, followed by log analytics and observability at 83%, real-time analytics at 70%, and AI-related workloads at 62%.
Whereas hybrid search is the go-to approach for 68% of organizations.
What now?
Most current deployments are not yet deeply embedded. Six in ten users say their OpenSearch setup is either experimental or something they could swap out; only 36% call it deeply embedded or mission-critical.
Among non-users, 81% say they are open to evaluating OpenSearch, though only 14% are actively planning to do so.
Alongside the report, the OpenSearch Software Foundation has announced three new members; one of them being Intel, and the other two being the new long-term support vendors.
We asked Bianca Lewis, Executive Director of the OpenSearch Foundation, what she thought about where agentic AI's headed next and how OpenSearch would fit into it:
The technology stack powering agentic AI is shifting rapidly, and with growing uncertainty around AI costs, long-term commitments to proprietary platforms present both a financial and architectural risk. Now, leaders are turning to an open, vendor-neutral platform to strategically mitigate risk.
An open data layer provides cost data and full visibility into which services are being called, giving teams the clarity needed to accurately cost and manage their infrastructure.
This delivers the flexibility to innovate without vendor lock-in, ensuring organizations maintain sovereignty over both their data and their spend as the future of AI takes shape.
