Canonical's Steam snap for ARM64 has been promoted to stable, nearly five months after a call for testing drew feedback from users across a wide range of ARM hardware.
The reason a snap like this exists at all is that Valve's Steam client for Linux is x86-only. To make it run on ARM64, Canonical bundled the x86 Steam binary together with FEX-Emu, a Linux usermode emulator that translates x86 and x86-64 instructions for ARM64 systems at runtime.
Snapcraft lists the stable release of the Steam snap for ARM64 now.
This stable release also introduces FEX's library forwarding feature (thunking) as a user-configurable option. Instead of emulating every graphics API call through FEX, thunking forwards OpenGL and Vulkan calls directly to the host system's native ARM64 libraries, which cuts down on emulation overhead.
Canonical has tested this release across three hardware families, all of which are said to have shown good performance across popular games. These include the NVIDIA DGX Spark and associated GB10 devices, Qualcomm Snapdragon laptops (Lenovo ThinkPad X13s, T14s, and Dell XPS 9345), and the Radxa Orion O6 and O6N.
Switch to stable
If you are already running the snap on candidate or edge and want to move to stable, run:
sudo snap refresh steam --channel=stable
They have also laid out a release cycle for the Steam Snap, with new versions first landing in the edge channel for experimental testing, then moving to candidate after around one to two weeks if no major issues surface. From candidate, they graduate to stable after another one to three weeks.
What's next?
Mitchell Augustin, who announced the stable promotion, wants to eventually rebuild the snap around Valve's native ARM64 Steam client and drop the FEX layer Canonical currently maintains on top of it.
Yeah, that native client is already out there, but quietly. ROCKNIX has already shipped it in their distribution, keeping both ARM64 and x86 launch paths available side by side.
Mitchell said he is keeping a close eye on it but is waiting for Proton 11 to exit beta first before making any moves.
For now, you can use the snap on your ARM64 device, and if you run into any issues or want to contribute to development, then the GitHub tracker for this app is the place to go.
The Linux Foundation has been steadily growing its roster of projects and initiatives, with AI governance becoming an increasingly prominent part of that push.
Their latest push in this direction is a plan to launch the Tokenomics Foundation, a new program focused on open standards, benchmarks, and best practices for the economics of AI token consumption.
It will work in close partnership with the FinOps Foundation, which has been busy with efforts surrounding cloud cost management since 2020.
Why now?
The foundation says that token costs have been moving around. They dropped heavily through 2023 and 2025, then settled down, and new model pricing is climbing again.
Citing a research paper, they pointed out that global token usage is projected to grow 24x between 2026 and 2030, hitting 120 quadrillion tokens per month.
Separately, they also noted industry analyst projections of AI infrastructure investment crossing $1 trillion by 2027, with the inference market going from roughly $106 billion in 2025 to $255 billion by 2030.
None of this spending is easy to measure consistently today. Cached vs. non-cached tokens, input vs. output pricing, on-demand vs. reserved compute. Every provider defines and bills for these differently, with no neutral framework to compare them across vendors.
Having a standardized approach to all of this is precisely the gap the Tokenomics Foundation is looking to fill with its open standards and benchmarks.
What will it do?
The foundation will operate through a Governing Board that sets direction and allocates funding, alongside a Technical Committee responsible for the actual specifications and benchmarks.
The first confirmed deliverable is expanding the FOCUS specification, an open billing format that came out of FinOps, to cover token-based spending models. That would give enterprises a common schema for AI cost data regardless of which provider they are using.
Twelve organizations have thrown their support behind it so far, including Google Cloud, Flexera, KPMG, Accenture, Microsoft, Oracle, Salesforce, SAP, ServiceNow, Booking.com, IBM, and JPMorgan Chase.
The formal launch is at FinOps X in San Diego, from June 8 to 10, where the technical roadmap, initial working groups, partnerships, and upcoming conferences will be announced.
You might remember that the Linux Foundation took a similar approach with the Agentic AI Foundation late last year, pulling MCP, goose, and AGENTS.md under open governance before the agentic AI space had a chance to fragment further.
Microsoft just shipped coreutils for Windows. Yes, you read that right.
ls. grep. cat. cp. find. The same commands that have powered Unix and Linux systems for over 50 years are now available natively on Windows, maintained by Microsoft itself.
In case you are not already familiar, GNU coreutils are the foundational utilities that every Linux and macOS system relies on for basic file operations, text processing, and shell scripting. They are the foundation of Unix computing. Tens of millions of scripts, pipelines, and workflows depend on them every day.
And now Microsoft is shipping and maintaining a build of them for Windows.
This is not WSL. You do not need a Linux subsystem running in the background. These "Linux commands" run natively on Windows, with the exact same flags and behavior as on Linux.
Microsoft's ultimate goal seems to make moving between Linux, macOS, WSL, containers, and Windows completely frictionless. Write a script once. Run it anywhere.
The Rust-based Windows coreutils is a work in progress
The package bundles uutils/coreutils (a modern Rust rewrite of GNU coreutils), findutils, and grep into a single multi-call binary. Every command supports standard flags. Same commands, same pipelines, no translation needed.
The project is still in preview and there are only a handful of commands. Since some commands have the same name in Linux and Windows, there is a possibility of conflict. Some don't fit in Windows environment.
Commands like dir, expand, more, paste, whoami conflict too directly with existing Windows built-ins. kill and timeout are unavailable due to Windows lacking POSIX signals. dd, dircolors, shred, sync, and uname were dropped as not useful on Windows. A longer list of POSIX-only commands like chmod, chown, chroot, mkfifo, id, who, and others are simply not applicable to the Windows environment. Who is surprised? Not me.
So, what commands are available as part of Windows coreutils then? The official GitHub repo does a better job at it:
Notice that there are separate columns for command prompt and PowerShell. Some commands would work in the default command prompt but not in the advanced PowerShell and vice versa.
Clearly, this is a work in progress and there should be more improvement on them in the near future.
Testing Linux commands on Windows
I booted into my Windows partition just to test it out. It's been months since I last logged in to the Windows and thus had to update the system with multiple reboots.
Sob story aside, I downloaded the .exe file for the Coreutils and installed it. Yes, these coreutils are offered in a single .exe file.
You can see a very brief demo of running some Linux commands in Windows command prompt. Some commands result in error as they are not supported yet.
A move for the agentic AI era?
See, the entire point of bringing Coreutils to Windows is to keep developers on the Microsoft platform. If they can use Linux commands and the tools their workflows depend on without leaving Windows, they have fewer reasons to switch to a Linux desktop. That is the same argument I made when WSL 2 was released years ago.
But this move goes beyond WSL, and in my opinion, it is not primarily aimed at developers, at least not in the direct sense.
Microsoft made several announcements at Build 2026 yesterday. One of them was bringing OpenClaw to Windows.
Now, OpenClaw is an open-source AI agent framework that lets autonomous agents run on your own machine. These agents rely on Linux commands, Python scripts, and similar tools to get things done. OpenClaw exploded in popularity earlier this year, so much so that people were buying Mac Minis just to run it locally.
These days, every operating system wants to be AI-ready. Development itself is increasingly happening through AI agents rather than purely by hand.
With OpenClaw coming to Windows, the ability to run Linux commands natively is no longer just a developer convenience, it becomes critical infrastructure for running AI agents.
That is what makes this announcement bigger than it looks. Microsoft is not just courting developers; it is positioning Windows as a serious platform for the agentic AI era.
A Vim fork has arrived, and it exists because of AI. Drew DeVault, the developer behind SourceHut, announced Vim Classic back in March 2026 after becoming unhappy with the direction both Vim and NeoVim were heading.
His gripe was that generative AI had started creeping into their development, and he wanted no part of it.
The NeoVim side of that concern is the project's labeling of AI-assisted pull requests as "AI assisted 🤖," which has now stacked up a fair number of requests, many of which have already been merged.
With Vim, the situation is a bit murky. Drew points to a GitHub issue where community members suspected one contributor of using LLMs, but a Vim maintainer had already pushed back on those accusations.
Drew warns that Vim Classic is meant for early adopters. Not for people looking to daily drive it.
A classic Vim experience
Screenshot of the website because building from source is ☠️.
Based on Vim 8.2.0148, Vim Classic predates the Vim9 script entirely. This was done deliberately to keep the maintenance burden manageable, stopping at the last patch before the script was introduced.
As a result, some Vim plugins that rely on Vim9 Script will not work with Vim Classic.
From that base, select patches have been backported from upstream, mostly addressing CVEs discovered after 8.2, alongside some bug fixes and original patches to keep things building on modern toolchains.
DeVault is also upfront that not every applicable security patch has been confirmed as backported, so some CVEs may have slipped through. The project is currently recommended only for early adopters comfortable with that uncertainty.
In addition, the charityware model carries over from Vim, with this project continuing to support the children of Uganda (albeit via a different charity) that Bram Moolenaar, the creator of Vim, endorsed.
📋
The original ICCF Holland charity was dissolved following his passing, with its mission carried forward by Kuwasha.
The packages
Vim Classic 8.3 is currently available as a source tarball from SourceHut (direct download). You will also find the release tarball and its PGP signature, signed with DeVault's public key, up on the project's refs page.
For the source code, head to the homepage of the SourceHut instance for Vim Classic.
I may hate AI slop but I am not a AI hater. I have found decent use of the AI tools and I try to include these tools in my workflow wherever it makes sense.
While mainstream LLMs like ChatGPT and Perplexity have decent free offering, they leach on the user data. "If you are not paying for the product, you are the product".
Recently, I discovered Jan AI. It is a polished, genuinely usable desktop app that runs entirely on my machine. In fact, I once tried replacing Ollama and llama cpp with Jan AI, but later changed my mind.
I'll explain why I switched back to Ollama in the later sections. First, let's learn about Jan AI.
What is Jan AI?
Jan is a free and open-source desktop application that lets you run various large language models directly on your own hardware. You can think of it as a self-hosted, offline-capable ChatGPT, except the model runs on your CPU or GPU, and no data ever leaves your machine.
The project is developed by the Jan.ai company, and the source code is available on GitHub under the AGPL-3.0 license. It's built on top of llama.cpp under the hood, which means it can run quantized GGUF models efficiently even without a dedicated GPU.
What I found impressive is that Jan's desktop application is built using the Tauri framework instead of Electron JS, which gives it a good performance boost and I think eats less RAM, too.
A quick catch, you still need plenty of RAM for running your local LLM.
The app supports Linux, macOS, and Windows. I used it on my Linux machine.
System requirements
Running a local LLM with Jan AI does require decent hardware. Here's what to realistically expect:
8 GB RAM minimum. It's enough for 7B parameter models at 4-bit quantization (Q4_K_M). You'll notice slowdowns with other applications open. 16 GB RAM is the sweet spot. It can comfortably run 7B models and lets you experiment with 13B models.
GPU acceleration is optional but makes a big difference. Jan supports NVIDIA (via CUDA), AMD (via ROCm), and Intel Arc. If you don't have a compatible GPU, CPU-only mode works, but it's significantly slower.
Disk space models range from around 4 GB (7B, Q4) to 8 GB+ (13B). Download only what you need.
📋
I've been running Jan on a machine with 16 GB RAM and no discrete GPU, and a 7B model gives me response times that feel somewhat usable.
Installing Jan AI on Linux
Jan offers multiple installation formats, including .deb and AppImage, but the AppImage is what I'd recommend for most Linux users. It's a single self-contained file that runs on virtually any distro without touching your system packages or requiring root privileges for the app itself. It requires no dependency hell. It's just made to work.
When you run Jan AI for the first time, you should see an interface like this:
Jan application interface for running local AI models
Downloading models and putting Jan to work
A freshly installed Jan is essentially an empty shell capable, but waiting. The first thing you need to do is grab a model. Think of it like the app is the frame and the model is the brain.
Finding your way to the model hub
Click the Hub in the left sidebar. This is Jan's built-in model library, a curated list of open-source models you can download with a single click.
There are dozens of models with names full of numbers and letters like Q4_K_M or IQ3_XS.
Jan AI application's model hub
Before I recommend which ones to pick, let me quickly demystify that alphabet soup because I spent an embarrassing amount of time confused by it when I first started.
What does Q4_K_M actually mean?
Every model name carries a quantization tag. Quantization is how a model's original full-precision weights get compressed to fit on consumer hardware. Here's a practical breakdown:
Q4: 4-bit quantization. The most common choice. Roughly 4 GB for a 7B model. Fast, memory-efficient, and quality holds up well for everyday tasks.
Q8: 8-bit quantization. Nearly full quality, but needs about twice the RAM. Worth trying if you have 32 GB or more.
K_M: The specific compression method (K-quants, medium variant). Generally, the best balance of speed and quality within the Q4 family.
XS (Extra Small): This is the most aggressive compression. It results in a file size that is slightly smaller than a standard Q4_K_S
💡
If you have 8–16 GB RAM, stick with Q4_K_M. If you have 32 GB+, try Q8_0 for noticeably sharper outputs.
The 3 LLM models I tested
I am using an AMD laptop with an integrated GPU. I settled for CPU interference for local LLM models because enabling RoCm (Radeon Open Compute) is a hectic task, based on my research. It requires 25-30 GB of disk space.
For those of you who aren't familiar with what AMD ROCm is, it's the answer to NVIDIA's CUDA. Basically, when you run a local LLM, the heavy math, such as matrix multiplications across billions of parameters, can be offloaded to a GPU instead of the CPU.
RoCm lets software like Jan AI, PyTorch, or Llama.cpp talks to AMD Radeon GPUs to do that same heavy lifting. Without it, Jan falls back to CPU-only mode, which works but is significantly slower.
For this article, I settled on three models that cover a solid range of use cases. I asked the same question to each model - "What can you do"? Here's what I found:
Gemma 4
I don't lie. The performance wasn't superb, only 5 tokens per second.
Gemma 3
The performance was bad than the Gemma 4 2B model. It was only 3 tokens per second. I think you can use the Gemma 3 2B model variant to achieve comparable performance.
Jan
Yeah! Jan offers its own AI model. I used the Jan-v3-4b model to test. It comes with 262K context length. It can follow up instructions and do some light coding tasks.
Features I liked in Jan AI
Let's see a few features that I liked in this open source AI tool.
Unified Interface for Local and Cloud LLMs
Jan can act as a unified interface for local and cloud LLMs, instead of jumping from Claude to ChatGPT and then Gemini. You get to talk to your favorite LLMs within a single interface.
Though directly interacting with Cloud LLMs takes away your privacy, you can still use Jan AI as a unified interface to interact with any models on HuggingFace, Groq, Gemini, Qwen, Mistral, and Claude with the respective platform's API.
Configuring cloud LLM provider like Groq, Gemini, OpenAI, Mistral and OpenRouter within a single unified interface of Jan
I'm especially in love with the Groq and Cerebras API. These platforms provide fast interference.
If your model provider is not in the list, you can still add OpenAI-compatible models to it.
To add, click on the plus icon next to "MODEL PROVIDERS". It'll ask for a name. Enter the name and then set the BASE_URL and API Key provided by your LLM platform.
Keeps your chats organized
Jan offers the functionality to organize chats per project.
Tailor Jan for Custom Experience
You can edit the system instruction. It's kind of making LLM behave like a specific expert.
Local API Server
It comes with a local API server. You can start the server by going to Settings -> Local API Server.
Use it as a tool to download AI models for Llama.cpp
Models downloaded with Jan AI application are completely compatible with Llama.cpp CLI. You can use Jan as a downloader tool and then run the downloaded AI model with llama-servera command.
Jan CLI
Jan offers a CLI interface to interact with as well.
My honest opinion on using Jan AI vs Ollama
Thanks to the developer involved in building the Jan AI app. It provides a nice GUI interface to interact with LLMs. On the contrary, I see some improvement scope for the application.
Ollama vs Jan AI application
The major one is with the local LLM inference time. I tested the same model, and what I found was that Jan AI provided slow inference time as compared to Ollama on the same hardware. Ollama produced a response at a rate of 6.62 tokens/sec while Jan AI produced a response at around 5 tokens/sec.
On the second test, Ollama reported 7.35 tokens per second while Jan AI responded at 3 tokens per second. Also, I tried Llama.cpp for the same Gemma 5 E2B model with 3.97 tokens/sec.
The secondary issue is Jan application often freezes your system. I agree, running LLM models takes significant RAM memory, but there are a couple of attempts I faced where giving a prompt with the Gemma 4 E2B model freezes my system. I haven't faced any similar issue with Ollama. That's why I kept Ollama and Llama.cpp for my local AI model inference.
Who is Jan AI actually for?
After spending time with it, I'd say Jan AI fits a few kinds of people particularly well. One thing I need to justify here, although in my tests, Jan struggled to give me more than 5 tokens per second in CPU mode, running it on a system with modern GPUs like Radeon GPU, Intel Arc, Nvidia 4050, you may get to see a huge boost in performance, especially with tokens per second. You could achieve around 13-15 tokens per second.
Privacy-conscious users who want AI assistance without feeding their conversations to a corporation. Lawyers, journalists, healthcare workers, and anyone handling sensitive information fall into this category.
Developers who want a local AI backend for their tools. The OpenAI-compatible API makes it drop-in compatible with a surprising number of existing integrations.
Linux enthusiasts who simply prefer FOSS software and want to own their stack. The fact that it's AGPL-licensed and actively developed is a big plus.
People on a budget. It comes with no API costs or subscription. You run it on hardware you already own.
It's not for everyone. If you need GPT-4 level capability for complex reasoning tasks, you'll still feel the quality gap compared to frontier cloud models. But for writing assistance, summarization, brainstorming, and everyday tasks? A well-tuned 7B or 13B model gets the job done.
The bigger picture
Local AI is no longer a hobbyist experiment. The AI models like Gemma 4, Gemma 3, Granite, Jan AI model, and SmolLM2 have gotten small enough that a standard laptop can run something genuinely useful. Tools like Jan have made the setup approachable enough that you don't need to be a machine learning researcher to get started.
Jan AI won't replace cloud services for everyone. But for a growing number of Linux users who care about privacy, cost, and control, it's become a daily-use tool. I'd encourage you to try it. Download it, grab a 7B model, and see how far it gets you.
If you have been following AlmaLinux OS, you know it is one of the more popular free enterprise Linux distributions out there.
Born out of the CentOS chaos, it has steadily grown into a community-governed project with a clear focus on stability and compatibility for production use.
Now, the AlmaLinux OS Foundation is taking things to Los Angeles, with an event squarely aimed at the studios and engineers who keep the entertainment industry running on Linux.
AlmaLinux Day: Los Angeles
Illustration by the AlmaLinux team.
This is a free, one-day gathering with a crowd that is set to be a mix of VFX engineers, sysadmins, cloud and DevOps folks, and open source contributors working in or adjacent to media and entertainment.
The AlmaLinux people have scheduled it a day before SIGGRAPH 2026, the premier annual conference for the computer graphics and VFX world, so that attendees get the technical conversations and networking in before the bigger crowd moves in on Sunday.
Sessions on Saturday will cover GPU driver integration for production use, the economics of running large-scale cloud rendering, and the AlmaLinux 2026/27 roadmap.
Of course the big reveal for the day is the launch of a dedicated AlmaLinux Media & Entertainment edition, which is a purpose-built variant tailored for the needs of studios and creative teams.
All of that is the result of the Media & Entertainment SIG's hard work, a group that has been at this since December 2025, working to get AlmaLinux certified and production-ready for VFX, animation, and post-production studios.
Event Details and Registration
The event takes place on Saturday, July 18, 2026, from 9:00 AM to 8:00 PM (local time) at the E-Central Downtown Los Angeles Hotel.
The venue can be found on OpenStreetMap (listed under the old name 'Luxe Hotel') and Google Maps. It is located at 1020 S Figueroa St., near the LA Convention Center.
Worth noting is that the event room has a hard cap, and the first 100 registrants get a special gift. So registering sooner rather than later is the wise move here.
The hotel is also ADA compliant, so people with nerfs (disabilities) should not face major barriers, though the actual experience on the day will depend on the venue's current setup and staff.
If you want to speak at the event, the call for speakers is open until June 5, 2026. They are particularly interested in topics like render farm architecture, migration stories, and security/CVE response in production.
You might remember that the KDE folks have been busy working on KDE Linux, their own Linux distribution that is still very much in active development. I tried its Alpha build last year and found the experience surprisingly smooth for something so early.
Fast forward to today, and Nate Graham, a well-known KDE name, has put out a progress report covering a pretty busy May for the project, with security fixes, build system changes, and a notable app swap all making the cut.
A lot of work
The most significant infrastructure work this month came from contributor Hadi Chokr, who reworked how KDE software gets built. The old process churned out Arch packages and handed them off to mkosi for installation.
That is now gone, replaced by KDE's own kde-builder tool compiling everything directly.
As a result, there are three major improvements. The build process now works the same way KDE developers build software on their own machines, the project is now more distro-agnostic, and builds are faster because the new setup uses caching more effectively.
Reacting to the many Linux vulnerabilities of last month (e.g., Dirty Frag and Copy Fail), the devs went through KDE Linux's package list looking for anything insecure or unnecessary.
The end result was a slew of cuts that included dropping the Zen kernel, axing several insecure kernel modules, removing a bunch of unused packages, and finally killing off the project's AUR dependency.
It's not all removals though. Nate also added a service that installs newly added pre-installed Flatpak apps on existing KDE Linux systems automatically, while leaving untouched anything the user has already removed on purpose.
There's a swap too; KWalletManager is being retired in favor of KeepSecret, a new, more modern KDE app for managing passwords and credentials.
Another thing to note is that Ark, the graphical file compression/decompression utility, now has .7z file support in its KDE Linux Flatpak packaging, bringing it in line with what the Flathub version already offers.
And, lastly, testing is being improved.
Right now, KDE Linux only checks that each build boots to the desktop, which is not saying much. Work is underway to change that though, with an OpenQA-based testing system in the works that should catch a lot more before a broken build goes out.
