What looked like a done deal for Fedora is now very much on hold.
The Fedora AI Developer Desktop Initiative, a proposal to build an official platform for AI and machine learning workloads on Fedora, has been blocked after two Fedora Council members retracted their earlier approval votes.
The initiative was proposed by Red Hat engineer Gordon Messmer, aiming to deliver an Atomic Desktop with accelerated AI workload support, covering developer tools, hardware enablement, and building a community around AI on Fedora.
Why the withdrawal?
As you already know, at the May 6 council meeting, the members unanimously voted to approve this new initiative. After which a short, lazy consensus window was left open until May 8 to accommodate absent members, after which the decision was to be ratified.
But that last bit never happened, as council member Justin Wheeler (Jflory7) was the first person to change their vote to -1. He pointed to the LTS kernel component of the proposal as a "massive structural shift" that had not been cleared with the relevant legal and engineering parties.
He also noted that feedback from Fedora kernel subject-matter experts had not been properly incorporated into the plan and that new developments, particularly the Nova driver work (for NVIDIA GPUs), would introduce technical and legal complexities that need proper vetting.
Following that, fellow council member Miro Hrončok (churchyard) put in his -1, saying that he had originally assumed the proposal was purely additive and therefore uncontroversial.
But seeing the community's response, he realized that he was mistaken about that. As an elected representative, he felt the need to reflect on this major proposal before signing it off.
A community divided
Over 180 replies have piled up in the proposal's discussion thread, with many well-known Fedora contributors pushing back on things like kernel policy, proprietary software, and project identity.
Hans de Goede from the packaging team called out the proposal's emphasis on CUDA support as going against Fedora's foundational commitment to free software, arguing that open alternatives like AMD's ROCm and Intel's oneAPI should be the focus instead.
Another Fedora contributor, Tim Flink, questioned whether the initiative amounted to little more than a mechanism to get CUDA onto a Fedora-adjacent system.
Neal Gompa raised similar concerns, saying Fedora has historically leveraged its stance on proprietary software to push vendors toward open solutions and that this proposal would undercut that effort.
What happens next?
Part of what made this blow up the way it did was a communications gap. Fabio Valentini of the FESCo noted that he only became aware the proposal was being voted on after stumbling across the council meeting on Matrix accidentally.
The initiative is now listed as blocked in the council ticket, with a new escalation deadline of May 22. Gordon (the proposal submitter) has said a revised draft is coming, telling the thread he plans to have a few people look it over before posting it.
For the longest time, I assumed running LLMs locally needed a decent GPU. That’s what most guides implied, and honestly, that’s how the ecosystem felt not too long ago. But after digging into recent tools and actually trying things out on CPU-only setups, that assumption doesn’t really hold anymore.
Newer model formats like GGUF and aggressive quantization (think 4-bit variants) have made these models much smaller and lighter. At the same time, runtimes such as Llama.cpp have become efficient enough that CPUs (yes, even older ones) can run them without completely falling apart.
That said, I quickly realized something more important: just because a model runs doesn’t mean it’s usable.
While testing, I found that the real metric that matters isn’t model size or even RAM usage, it’s actually tokens per second. A model providing a response at 3–5 tokens per second technically works, but it feels painfully slow in practice. On the other hand, once you get into the 15–30 tok/s range, things start to feel responsive enough for everyday use.
So instead of just listing models that can run on CPU, I focused on ones that are actually usable on low-end machines. This list is based on my own experimentation.
If you're working with an older laptop, Raspberry Pi, or basic desktop, this guide would be helpful for running your local AI model successfully and speedily.
What “Runs well on CPU” actually means
CPU performance varies wildly depending on model size and quantization. Formats used by tools like llama.cpp let you run models in reduced precision. Q8 offers better quality but is slower than Q4_K, which is much faster but comes with slightly reduced quality.
I found models ranging from ~40+ tokens/sec for tiny models all the way down to ~4 tokens/sec for larger 4B models. It completely changes how usable a model feels.
I would say, 1B-2B models consistently offer the best balance. They're small enough to fit comfortably within 8 GB RAM (with quantization) and maintain decent token speeds. Additionally, they are capable of handling basic reasoning and producing useful responses.
From my experience, Q4_K_M quantization usually hits the best balance. It provides fast response times, consumes low RAM, and produces acceptable output quality for most tasks. It significantly improves tokens per second, sometimes enough to move a model from painfully slow to actually usable.
My hardware on which I'm performing these tests
I'm performing these tests on an Intel i5-generation CPU laptop with around 12 GB of RAM. I’m not running these tests on a workstation or anything close to “AI-ready” hardware. This is a fairly typical older laptop. It's the kind many Linux users already have lying around.
Though the device comes with an Integrated Intel UHD Graphics 620 GPU, it is irrelevant for LLMs here. While some tools experiment with iGPU acceleration, in practice, all meaningful inference in my tests is CPU-bound.
I deliberately stuck to this machine because it reflects a realistic baseline. If something runs well here, it will likely run on older laptops and low-end desktops without any upgrades.
With around 12 GB RAM, 3B–4B models fit comfortably (especially with Q4 quantization). Anything beyond that requires compromises, including swap, resulting in slower performance.
While testing, I kept asking: Would I actually use this daily on this machine? If a model felt sluggish, I treated it as impractical. Whereas if it responded smoothly, even at smaller sizes, it made the cut.
Quick reality table
Model
Eval Rate
Disk Size
Qwen 3 0.6B
~34–36 tok/s
~500 MB
TinyLlama 1.1B
~25–28 tok/s
~638 MB
Gemma 3 1B
~18.6 tok/s
~815 MB
Gemma 4 E2B
~9.9 tok/s
~7 GB
Granite 4 3B
~8.5–9 tok/s
~2 GB
Phi 4 Mini 3.8B
~6.90 tok/s
~2.5 GB
OpenHermes 7B
~4.1–4.3 tok/s
~4.1 GB
Ministral 3 8B
~3.16 tok/s
~6 GB
8 LLMs that actually make sense on CPU
Let's dive into the LLMs. I used Ollama in this setup.
Qwen 0.6B
I started with Qwen 3 0.6B, mainly to establish a baseline for how fast a tiny model can run on a CPU. Qwen models are known for being efficient, and this 0.6B variant is about as lightweight as it gets while still being usable.
The --verbose flag exposes detailed metrics like token evaluation rate, total duration, and prompt processing speed. I only used it for this initial run to get a clearer picture of performance.
The results were honestly impressive. I consistently saw ~34–36 tokens/sec eval rate. In practical terms, this feels instant. Responses stream smoothly without noticeable delay.
Of course, this comes with tradeoffs. The model is fast, but limited in depth and reasoning. Still, as a baseline, it clearly shows what’s possible on CPU when the model size is kept small.
TinyLlama 1.1B
After establishing a baseline with Qwen 0.6B, I moved to TinyLlama 1.1B to see how much capability you can gain without sacrificing too much speed.
TinyLlama is a 1.1B parameter model trained on the Llama 2 architecture, but heavily optimised for efficiency. It was trained on ~3 trillion tokens, which is unusually high for a model of this size. That large training corpus is what gives it a noticeable edge over most sub-2B models.
Architecturally, it sticks to a decoder-only transformer design, similar to Llama. TinyLlama is not just small but is also efficiently designed to run well on limited hardware.
I run it locally using:
ollama run tinyllama:1.1b --verbose
From the benchmark, it feels slightly slower, but still very responsive as compared to Qwen 0.6B.
What surprised me here is how well TinyLlama holds up despite being just 1.1B. It’s much more coherent than ultra-small models. It also handles basic coding prompts better than expected.
Gemma 3 1B
Next, I tested Gemma 3 1B, which sits in a slightly higher class than sub-1B models like Qwen 0.6B. The expectation here was simple: a bit slower, but noticeably better output quality.
I ran it using:
ollama run gemma3:1b --verbose
Ollama benchmark for Gemma 3 1B
The performance landed at around ~18.6 tokens/sec, which puts it firmly in the “usable” tier. It’s not instant like the smaller Qwen model, but it’s still responsive enough for real interaction. You can feel a slight delay when generating longer responses, but it never becomes frustrating.
What stood out to me was the tradeoff. Compared to 0.6B models, Gemma 1B produces more structured and context-aware responses. It handles prompts more thoughtfully, especially when you ask for explanations or multi-step answers.
So while you give up some speed, you gain a noticeable bump in quality, making this a solid middle ground for CPU-only setups.
Gemma 4 E2B
After testing smaller models, I wanted to see how far I could push things on this CPU-only setup. That’s where Gemma 4 E2B comes in, a significantly larger and more capable model compared to the earlier ones.
I ran it with:
ollama run gemma4:e2b --verbose
The performance drop was immediately noticeable. I was getting around ~9.9 tokens/sec, which places it right on the edge of what I’d call “slow but workable.”
That said, the quality jump is real. Responses are more detailed, better structured, and noticeably stronger for complex prompts, especially coding and multi-step explanations. It feels closer to what you’d expect from a “serious” assistant.
The tradeoff becomes very clear here: you’re exchanging speed for capability. On a low-end CPU, this is about as far as you can reasonably go before the experience starts to feel sluggish for everyday use.
Granite4 3B
Next, I tried Granite 3B, expecting it to land comfortably in the “sweet spot” range like most 3B models. On paper, this size usually delivers a good balance between speed and quality on the CPU.
I ran it using:
ollama run granite4:3b --verbose
In practice, the performance came in at around ~8.5–9 tokens/sec, which was a bit surprising. That puts it closer to the “slow but workable” tier rather than the typical 3B expectation of ~15–20 tok/s.
Responses aren’t painfully slow, but there’s a noticeable delay, especially compared to lighter models like Qwen 0.6B or even Gemma 1B. It feels usable, but not snappy.
Phi4 3.8B
After poking around with various small models, I was curious about Microsoft's entry into the sub-4B space. Phi 4 Mini carries a reputation that punches above its parameter count, particularly for reasoning and structured tasks. Let's see what it actually feels like on a CPU-only setup.
I run this with:
ollama run phi4:3.8b --verbose
Ollama benchmark for Phi4 3.8B running with CPU inference
The prompt eval rate at 20.06 tokens/sec is respectable. The model processes your input quickly. The CPU showing its limits is during generation: 6.90 tokens/sec for 876 tokens means you're waiting just over two minutes for a long, detailed response. That's consistent with what you'd expect from a 3.8B model doing real work on CPU.
Phi 4 Mini comes in at around 2.5 GB on disk, compact enough to sit comfortably on systems with 8 GB RAM. The default pull uses Q4_K_M quantisation, which is the sweet spot most models land on for balancing quality against memory footprint.
If reasoning quality matters more than raw speed for your use case, Phi 4 Mini makes a strong argument for itself in this size class.
Openhermes 7B
OpenHermes is a fine-tuned variant built on top of the Mistral 7B architecture, designed to improve conversational quality and instruction adherence. Instead of focusing purely on raw model capability, it’s trained to produce cleaner, more aligned, and more usable outputs right out of the box. In practice, this means better formatting when you ask for explanations, summaries, or step-by-step answers.
Under the hood, it inherits Mistral’s efficient transformer design, which is already known for performing well relative to its size. The difference here comes from the instruction tuning layer, which makes it feel more like a polished assistant rather than a raw base model.
I run it locally using:
ollama run openhermes:7b-mistral-v2-q4_K_M --verbose
Ollama benchmark for Openhermes 7B in CPU inference mode
From the benchmark, the eval rate consistently stayed around ~4.1–4.3 tokens/sec, with total response times ranging between ~13 and 29 seconds depending on output length. Prompt processing itself was relatively fast, often exceeding ~180–280 tokens/sec, but generation is where the slowdown becomes noticeable.
What makes OpenHermes interesting is its output quality. It provides more structured, better formatted, and easier-to-follow responses.
Ministral 3 8B
After testing smaller models, I wanted to see how far a CPU-only setup can realistically go. That’s where Mistral 3 8B comes in.
Ministral models are well known for delivering strong performance relative to their size, and the 8B variant sits in an interesting spot. It’s significantly more capable than 3B models, but still just about runnable on a 10GB RAM system with quantisation. It feels close to a full-scale general-purpose LLM designed for conversational tasks, coding assistance, and structured reasoning.
This is a big drop compared to smaller models, and that’s expected. In practical use, you’ll notice a delay before responses start, token generation is steady but slow, and longer answers require patience. It’s not unusable, but it’s definitely not “interactive” in the same way as 1B models.
One interesting thing I quickly noticed, with 8.9 billion parameters, ministral-3 comes within a size of around 6 GB disk space, while Gemma 4, with 2B billion parameters, takes around 7 GB.
Upon close inspection, it turned out Ministral 3 is using Q4_K_M quantization.
Conclusion
Model
Params
Eval Rate
Disk Size
Quantization
Speed Tier
Best For
Qwen 3 0.6B
0.6B
~34–36 tok/s
~500 MB
Q4_K_M
⚡ Fastest
Quick lookups, basic tasks
TinyLlama 1.1B
1.1B
~25–28 tok/s
~638 MB
Q4_K_M
Very fast
Coding help, coherent chat
Gemma 3 1B
1B
~18.6 tok/s
~815 MB
Q4_K_M
Fast
Structured explanations
Gemma 4 E2B
2B
~9.9 tok/s
~7 GB
Q4_K_M
Moderate
Complex prompts, coding
Granite 4 3B
3B
~8.5–9 tok/s
~2 GB
Q4_K_M
Moderate
General-purpose use
Phi 4 Mini 3.8B
3.8B
~6.90 tok/s
~2.5 GB
Q4_K_M
Slow
Reasoning, structured tasks
OpenHermes 7B
7B
~4.1–4.3 tok/s
~4.1 GB
Q4_K_M
Slow
Aligned, formatted output
Ministral 3 8B
8.9B
~3.16 tok/s
~6 GB
Q4_K_M
Slowest
Long-form, async tasks
After running all eight models through their paces on the same CPU-only hardware, a few things became clear.
First, the assumption that local LLMs need a GPU is outdated. Tools like Ollama, combined with GGUF quantization, have genuinely changed what's possible on modest hardware.
Second, smaller doesn't mean useless. Qwen 0.6B and TinyLlama 1.1B surprised me consistently. For quick lookups, basic coding help, or conversational tasks, they hold up well and feel genuinely responsive. If raw speed matters most, these are hard to beat.
Third, the 3B–4B range is where things get interesting. Gemma 4 E2B, Granite 3B, and Phi 4 Mini all sit in a space where you're making a conscious trade: slower responses in exchange for noticeably better reasoning and output quality. Whether that trade is worth it depends entirely on your use case.
Beyond 7B, local AI models like OpenHermes and Ministral 3 8B both produce impressive output, but at 3–4 tokens/sec. They're better suited for tasks where you ask a question, step away, and come back, not for back-and-forth conversation.
If I had to pick one model for daily CPU-only use, I'd land on something in the 1B–2B range for speed, or Phi 4 Mini if I needed structured reasoning and could tolerate the wait.
The honest takeaway: local AI on CPU is real, practical, and improving fast. You don't need to wait for a GPU upgrade to start experimenting.
Hot on the heels of Copy Fail comes Dirty Frag, another Linux kernel privilege escalation with a working exploit already public. It chains two flaws, neither of which can work alone.
Seeing the rise of such exploits, there is now a new kernel proposal called killswitch, which would allow system administrators to disable a vulnerable kernel function at runtime.
A few weeks ago, we reported about LVFS turning up the heat on vendors who didn't pay their fair share. Now, Dell and Lenovo have both signed on as Premier sponsors at $100,000 a year each, making them the first vendors to reach that tier.
Ubuntu announced local-first AI plans, and now Fedora has approved its own AI Developer Desktop initiative with a unanimous council vote. Three Atomic Desktop images are planned, two of them CUDA-enabled, and none of them would be phoning home to cloud services.
Fedora has also announced Hummingbird, a distro that ships the entire OS as a bootable OCI image with atomic updates and rollback support.
Debian has made reproducible builds a hard requirement for the Forky cycle. Since May 9, any package that can't be compiled byte-for-byte identically from its source is blocked from entering testing.
Here are other highlights of this edition of FOSS Weekly:
How moving away from OneDrive looks like.
Yazi file browser (that I missed to include last week).
A Ratatui terminal.
And other Linux news, tips, and, of course, memes!
🧠 What We’re Thinking About
My colleague Sourav, a long-time OneDrive user, had to move away from it over fears of Copilot messing around with his photos and videos. Ente Photos was the alternative he went for.
🧮 Linux Tips, Tutorials, and Learnings
Yazi is a Rust-based terminal file manager that does a lot more than ls and cd. You get a three-pane layout, image previews, syntax-highlighted code previews, and archive peeking without extraction.
Most KDE users know Dolphin does split view and tabs. Fewer know it can verify file checksums, restore recently closed tabs with Ctrl+Shift+T, and paste images directly from the browser.
If you have been eyeing a move to Fedora, then our Getting Started with Fedora series is the one for you. This curated resource page covers everything from first boot to enabling RPM Fusion, NVIDIA drivers, Steam setup, and upgrading between versions.
Tired of AI fluff and misinformation in your Google feed? Get real, trusted Linux content. Add It’s FOSS as your preferred source and see our reliable Linux and open-source stories highlighted in your Discover feed and search results.
Terminal can be scary. Terminal can be fun. Terminal can be weird. This week, we came across a new terminal that is amusing, absurd and fun. It shows terminals can have 3D effects.
If you live in the terminal and use Discord, Concord can be a TUI client replacement for it. Keep in mind that it is a relatively new offering, so verify this before installing it on your computer.
In Kate text editor, you can compare two files for differences in content. First, open two files in separate tabs. Then, right-click on the title of the inactive tab and select the "Compare it with Active Document" option.
This will open a new tab, highlighting the differences between the files.
🎋 Fun in the FOSSverse
Do you know all the Apt commands? You can test your knowledge with our package management quiz.
Newbies have a hard choice to make nowadays. 😆
🗓️ Tech Trivia: On May 10, 1954, Texas Instruments engineer Gordon Teal stunned attendees at an IRE conference in Dayton, Ohio, by announcing the first commercially produced silicon transistor, moments after other speakers had declared such a device was still years away.
I like Kitty and I am pretty happy with it. But then I came across a new Rust-based terminal that grabbed my attention.
No, it's not because it's written in Rust. It's because the terminal has a rat as the mouse cursor.
Did you see the rat?
Sounds weird, right? But Ratty shows the unusual capabilities of a terminal.
What is Ratty, again?
Ratty is a modern terminal emulator written in Rust that brings a unique twist to the command line. Unlike traditional terminal environments, Ratty is GPU-rendered.
It supports viewing 3D models directly inside the terminal window, and a lot more!
The design is inspired by TempleOS, giving it a retro look while still maintaining modern performance.
Let's take a look at this cool project and see what makes it stand out in the crowded field of terminal emulators.
Amusing features of Ratty
Ratty stands out by merging traditional terminal functionality with modern graphics rendering. Here are some of the most notable features I noticed in this experimental project.
📋
I know screenshots are easier to glance at, but since most of the features here are animations, I added videos to show them in action.
Customizable 3D Cursor
Ratty uses terminal protocols, Ratatui and the Bevy game engine to create a 3D representation for the cursor. Instead of a traditional block or line, the cursor can be a 3D rat or other customized objects.
Rotating 3D Cursor
When you install Ratty, you get a spinning rat as the cursor by default. This 3D object moves along with your text input, providing a unique visual experience that blends a game engine's rendering capabilities with a standard terminal workflow.
3D Mode
Ratty includes a dedicated 3D Mode that transforms the entire terminal into a canvas within a 3D scene. In this mode, the terminal window is no longer static. You can pull, warp and view your terminal output from different angles!
3D Mode in Ratty
To enter 3D mode, you can use the keyboard shortcut CTRL+ALT+Enter.
Additionally, there is a "Mobius mode" accessible via CTRL+ALT+M. This twists and bends the terminal output to form a continuous Mobius strip, showcasing the project's integration with the Bevy game engine.
Mobius Mode
While you are in 3D Mode, you can press the Super+CTRL+ALT+Up to increase warp and Super+CTRL+ALT+Down to reduce warp.
Increase and decrease warp
Inline 3D Objects
This feature allows developers to register 3D assets and anchor them to specific text cells in the terminal. Because they are anchored to the cells, the 3D models move seamlessly as the text scrolls or changes position.
To make this work, the project uses a dedicated Ratty Graphics Protocol. This protocol handles the communication between the terminal data and the 3D engine to ensure the models stay synced with the text on your screen.
Builtin Image Support
Ratty also supports the Kitty Graphics Protocol, which allows it to display standard images directly in the terminal window.
This compatibility means that tools like fastfetch or yazi can show real images and icons alongside your text. By supporting this established protocol, Ratty ensures that modern terminal utilities work as expected while still offering its own specialized 3D features.
Live 2D to 3D Split Pane Drawing
Ratty includes a 3D drawing demo that showcases its unique rendering capabilities. This feature uses a split-pane workspace where you can draw on a traditional 2D canvas on the left side of the terminal.
As you draw on the flat surface, Ratty instantly generates a live 3D preview of your creation on the right side. The preview rotates in real-time, allowing you to see how your 2D input translates into a 3D object without leaving the terminal environment.
Interactive Document Mode
Ratty also features a document editing mode inspired by TempleOS. This mode allows you to type standard, editable text directly alongside embedded 3D objects.
Because these 3D models are animating in real-time on the same screen as your text, the terminal functions more like a spatial document editor than a simple command prompt. It provides a unique way to interact with data where text and 3D assets coexist in the same workspace.
Installing Ratty
The best way to install Ratty is using Cargo, the Rust package manager. It's a Rust application, after all.
cargo install ratty
For Arch Linux users, there is a package available in the official repositories. You can install it by running:
sudo pacman -S ratty
If you prefer not to compile from source, prebuilt binaries are available for direct download on the GitHub releases page.
It is important to note that Ratty requires a GPU to function properly. If you are trying to run it inside a virtual machine, it will not open unless you have configured GPU passthrough settings.
⚠️ Troubleshoot
I installed Ratty on Arch Linux and noticed it was missing from the application menu. I had to manually create a desktop entry. Here's how you can do the same.
Create a file at ~/.local/share/applications/ratty.desktop with the configuration provided below, the terminal will appear in your app launcher just like any other program.
[Desktop Entry]
Name=Ratty
Comment=A GPU-rendered terminal emulator with inline 3D graphics
Exec=env TERM=xterm-kitty ratty
Icon=utilities-terminal
Type=Application
Terminal=false
Categories=System;TerminalEmulator;
While this manual method worked for me, if you know of an alternate solution or a more official way to handle the menu entry, feel free to mention it in the comments.
Configuring Ratty
Ratty can be configured using a TOML file located at ~/.config/ratty/ratty.toml. If the directory and file do not exist yet, you can create them using the following commands:
mkdir -p ~/.config/ratty
cd ~/.config/ratty
touch ratty.toml
Once you have created the file, you can copy and paste the default configuration template provided by the project. This allows you to customize the behavior and appearance of the terminal to suit your preferences.
You can find the default config file for Ratty here.
Impressive?
Clearly, Ratty is an experimental project focused on pushing the boundaries of terminal development and testing innovative ideas. Because it uses a game engine for rendering, it is currently heavy on system resources.
Orhun, Ratty creator, explicitly notes that it is not intended as a "daily driver" for standard productivity and hopes to optimize the performance in the future.
The use of 3D sprites and game-like graphics inside a terminal may not appeal to everyone. However, it offers unique possibilities for designers and developers who want to see their assets living directly inside source files or within the terminal workspace.
What is your impression of Ratty? Share it in the comments please,
Seeing that we are in a time when new Linux exploits seem to be popping up every few weeks, many projects have had to take preventive measures to tackle the growing threat.
Red Hat looks like the latest to act on this front. Fedora's recent announcement introduces Fedora Hummingbird, a new rolling release distribution that ships the entire OS as an OCI image.
It is built on the security-first pipeline behind Project Hummingbird's existing container catalog, with the foundational project itself being something Red Hat introduced as an early access program for subscribers back in November 2025.
The main idea behind the project is to ship a catalog of minimal, hardened, distroless container images kept at near-zero CVE status. When a vulnerability gets patched upstream, the build pipeline finds it, rebuilds the affected image, and ships it.
Fedora Hummingbird is applying the same logic but to a full-size operating system, using a Konflux-based build pipeline, drawing over 95% of packages from Fedora Rawhide.
Whatever Rawhide doesn't have yet gets pulled from upstream, and any fixes made along the way feed back into Fedora.
Moreover, Red Hat's Product Security team maintains a vulnerability feed for each package, so instead of a generic CVE list, you get a clearer picture of what actually affects your setup.
The kernel powering it is the Always Ready Kernel (ARK) from the CKI project, which follows mainline Linux and already ships in Fedora. And, to wrap up, all updates are atomic with rollback support, the root filesystem is read-only, and writable state stays in /var and /etc.
How's it different from Fedora Atomic?
If you're already running Silverblue, Kinoite, or any of the other Fedora Atomic Desktops, then the "immutable OS" moniker might feel familiar to you. But Hummingbird and those are not the same thing.
Fedora's existing Atomic Desktops are rpm-ostree-based desktop variants built from the standard Fedora package set, released on Fedora's regular six-month cycle.
They are built for end users who want a stable, immutable desktop experience.
Fedora Hummingbird ships no desktop environment and is a rolling release that tracks Fedora Rawhide directly, built through its own dedicated pipeline where every package carries independent CVE tracking and its own lifecycle.
The target here is developers and cloud-native workloads, not the desktop market.
Download Fedora Hummingbird
🚧
This image is currently experimental and not suitable for production use.
The image is available to download for the x86_64 and aarch64 platforms with no subscription or registration required. The project's source code lives on GitLab, and is open for contributions.
The download page also has step-by-step instructions for spinning up a virtual machine.
As a gamer, if you have gamed on Linux with hardware that's seen better days, there's some work happening in the kernel that's worth keeping an eye on.
Linux kernel developer Peter Zijlstra has posted the second version of a patch series called "sched: Flatten the pick," aimed at fixing gaps in how the Linux scheduler handles cgroup scheduling.
Calling it "a pain in the ar*e," he has tracked the issue down to a formula that fragments a task group's total weight across every CPU on the system.
On a 64-core machine, Peter says, a cgroup is already down to roughly a nice 19 task worth of priority per CPU, and at 256 cores, which is not unusual in servers today, the margin gets even tinier.
He breaks the rest of the problem into two parts, where the usual fix for the first is to inflate the group weight by the CPU count, but when all of a group's load lands on a single CPU, that weight balloons well past nice -20 (priority value of the process), and the math starts breaking down.
The second is how the scheduler picks the next task to run. It currently has to step through multiple cgroup levels to get there; the fix collapses all of that into a single level instead.
He ran what he calls a little experiment, using an older configuration with an Intel Core i7-2600K and AMD Radeon RX 580, loading up Shadows: Awakening from GOG through Lutris, using GE-Proton10-34 and Steam Runtime 3 (sniper).
To properly stress the setup, he threw 8 spinner processes at it alongside the game, one per CPU thread, and watched it go from playable to "almost unplayable, as in proper terrible."
He then restarted it with a shorter scheduler time slice set to one-tenth of the default via chrt and recorded both sessions using MangoHud. This is what he got. 👇
Metric
Default slice
Shorter slice
FPS min
3.8
20.6
FPS avg
48.0
57.2
FPS max
87.4
80.3
Frame time min (ms)
9.4
8.4
Frame time avg (ms)
34.5
19.5
Frame time max (ms)
107.4
37.2
Closing the proposal, Peter said that he has not compared to a kernel without flat on, just wanted to run non trivial workloads and play with slice to make sure everything 'works.'
Should you be excited?
If you game on Linux, especially on older hardware, this kind of fix can be beneficial.
The stress test Peter ran is not that far from what happens in normal use. Discord, a web browser with a dozen tabs, a system update running in the background. They all compete for CPU time the same way those spinner processes did.
And while his test rig is old, the scheduler problem is not limited to old hardware. High core counts make the weight fragmentation issue worse, not better. If this lands, modern rigs with 16 or more cores could see gains too.
You should also know that this has not made it into the mainline Linux kernel yet. The patch series still needs review from the concerned kernel maintainers. It will almost certainly go through some revisions before it lands in a kernel release.
Dirty Frag has been the talk of the town (at least in Linux and open source circles) recently. The LPE was inadvertently exposed to the public, catching the Linux project and the various distros off guard.
Thankfully, a proper patch is now out, landing in Linux 7.0.6 and Linux 6.18.29 LTS. Fedora and Pop!_OS have already pushed their own fixes too.
The root cause traces back to a 2019 commit that left two packet types unaccounted for in the rxrpc handling path, ones with pages fed in through splice() and ones with fragment chains attached.
The kernel did not treat either as shared memory, so it skipped making a safe copy and decrypted them in place. That left a window for a local attacker to reach in from userspace and tamper with those pages while decryption was happening, which is enough to get root.
The fix extends the existing check in two rxrpc functions to also catch those two cases, so they get copied to a private buffer before decryption like they should have been all along.
Linus Torvalds merged it on May 10, Linux 7.0.6 was out the following day, and the 6.18.29 LTS kernel got it too.
You can get the tarball for 7.0.6 over at kernel.org. This is intended for those who have the skill to install it manually, and if you are on an Ubuntu-based distro, we have a guide on how to do that.
Just keep in mind that this is a risky process to go through; only do so if you have backed up your data.
Both distros had fixes out before 7.0.6 was officially released.
Fedora
Fedora kernel maintainer Justin Forbes announced earlier that the fix was already being pushed to the stable branch. Fedora 43 and Fedora 44 get it with the 7.0.4 kernel, and Fedora 42 users with 6.19.14-101.
Justin also says that they skipped an update to 7.0.5 for F43 and F44, as the fix was already implemented in their 7.0.4 builds.
To get it on my Fedora Workstation 43 setup, I first ran this command to get a list of any available updates:
sudo dnf update
Getting the patched kernel on Fedora Workstation 43.
After verifying that I was getting the patched x86_64 7.0.4-100.fc43 kernel, I ran the following command to get the upgrade and pressed "Y" when prompted:
sudo dnf upgrade
Pop!_OS
For people running the LTS releases of Pop!_OS, 22.04 and 24.04, System76 has released kernel updates covering both Dirty Frag CVEs. The esp4 and esp6 modules tied to the second CVE were patched and are said to be safe to re-enable.
For rxrpc, they went with disabling the module rather than patching it and are holding off on re-enabling it.
You can get the fixes by running:
sudo apt update && sudo apt upgrade
Remember to reboot after the above is done running with:
sudo reboot
For further reading, our earlier Dirty Frag coverage has the full scoop on the exploit and the temporary workarounds from before the fix was available.
