Linus Torvalds has weighed in on an ongoing debate within the Linux kernel development community about whether documentation should explicitly address AI-generated code contributions, and his position is characteristically blunt: stop making it an issue. The Linux creator was responding to Oracle-affiliated kernel developer Lorenzo Stoakes, who had argued that treating LLMs as "just another tool" ignores the threat they pose to kernel quality. "Thinking LLMs are 'just another tool' is to say effectively that the kernel is immune from this," Stoakes wrote.

Torvalds disagreed sharply. "There is zero point in talking about AI slop," he wrote. "Because the AI slop people aren't going to document their patches as such." He called such discussions "pointless posturing" and said that kernel documentation is "for good actors." The exchange comes as a team led by Intel's Dave Hansen works on guidelines for tool-generated contributions. Stoakes had pushed for language letting maintainers reject suspected AI slop outright, arguing the current draft "tries very hard to say 'NOP.'" Torvalds made clear he doesn't want kernel documentation to become a political statement on AI. "I strongly want this to be that 'just a tool' statement," he wrote.

An anonymous reader shared this report from the Linux news site Linuxiac: Archboot, a guided, user-friendly, menu-driven installer for Arch Linux that automates much of the traditional manual installation process (while still allowing advanced users to intervene when needed), has added the COSMIC desktop environment as a new selectable option. The change is part of Archboot's development cycle leading up to the 2026.01 release and is already available in the latest tagged builds. With COSMIC now integrated, users can boot an Archboot ISO and choose the desktop to either perform a full Arch Linux installation or start a live session for testing and recovery.

Phoronix's Michael Larabel is "reliving some of the best moments for Fedora Linux in 2025" by highlighting the year's most popular news around the distro. Throughout 2025, Fedora continued to lead upstream Linux innovation with bold changes like Wayland-only GNOME, newer kernels, architecture cleanups, and experimental features -- while openly grappling with controversial shifts such as dropping 32-bit support and modernizing long-standing subsystems.

"Fedora Linux this year continued in punctually shipping the very latest upstream Linux innovations from the freshest Wayland components to Linux kernel features and continuing to leverage other improvements in the open-source world," writes Larabel. "Fedora enjoyed the successful Fedora 42 and Fedora 43 releases this year, including going with Wayland-noly GNOME and further phasing of 32-bit packages. Fedora's KDE spin continued improving too and the Red Hat sponsored Linux distribution enjoyed a wealth of other improvements this year."

Phoronix reports on "an exciting post-Christmas patch series out on the Linux kernel mailing list" proposing "a new runtime standby ABI that is similar in nature to the 'Modern Standby' functionality found with Microsoft Windows..." Modern Standby is a low-power mode on Windows 11 for letting systems remain connected to the network and appear "sleeping" but will allow for instant wake-up for notifications, music playback, and other functionality. The display is off, the network remains online, and background tasks can wake-up the system if needed with Microsoft Modern Standby...

"This series introduces a new runtime standby ABI to allow firing Modern Standby firmware notifications that modify hardware appearance from userspace without suspending the kernel," [according to the email about the proposed patch series]. "This allows userspace to set the inactivity state of the device so that it looks like it is asleep (e.g., flashing the power button) while still being able to perform basic computations..."

Those interested can see the RFC patch series for the work in its current form, in particular the documentation patch outlines the proposed /sys/power/standby interface.

NVIDIA has been "gradually dropping support for older videocards," notes Hackaday, "with the Pascal (GTX 10xx) GPUs most recently getting axed."

"What's more surprising is the terrible way that this is being handled by certain Linux distributions, with Arch Linux currently a prime example.?" On these systems, updating the OS with a Pascal, Maxwell or similarly unsupported GPU will result in the new driver failing to load and thus the user getting kicked back to the CLI to try and sort things back out there. This issue is summarized by [Brodie Robertson] in a recent video.
"Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support," explains an announcement on the Arch Linux mailing list. But Hackaday points out that using the legacy option "breaks Steam as it relies on official NVIDIA dependencies, which requires an additional series of hacks to hopefully restore this functionality.

"Fortunately the Arch Wiki provides a starting point on what to do."

Phoronix's Michael Larabel writes: An interesting anecdote from this month's Linux Plumbers Conference in Tokyo is that Meta (Facebook) is using the Linux scheduler originally designed for the needs of Valve's Steam Deck... On Meta Servers. Meta has found that the scheduler can actually adapt and work very well on the hyperscaler's large servers. [...]

The presentation at LPC 2025 by Meta engineers was in fact titled "How do we make a Steam Deck scheduler work on large servers." At Meta they have explored SCX_LAVD as a "default" fleet scheduler for their servers that works for a range of hardware and use-cases for where they don't need any specialized scheduler. They call this scheduler built atop sched_ext as "Meta's New Default Scheduler."

LAVD they found to work well across the growing CPU and memory configurations of their servers, nice load balancing between CCX/LLC boundaries, and more. Those wishing to learn more about Meta's use and research into SCX-LAVD can find the Linux Plumbers Conference presentation embedded below along with the slide deck (PDF).

Linux's share of the desktop market has climbed to as much as 11% by one count, but that figure includes Chromebooks, and the traditional Linux desktop remains hamstrung by the same fragmentation that killed Unix decades ago. Steven J. Vaughan-Nichols, writing in The Register, argues that the proliferation of Linux desktops -- more than a dozen significant interfaces exist today, and DistroWatch lists "upwards of a hundred" -- makes it nearly impossible for ordinary users to know where to start.

Linus Torvalds has long agreed with this hypothesis. "We have way too many desktops," Vaughan-Nichols notes, summarizing Torvalds' position. The deeper issue lies in software delivery: traditional package managers like DEB and RPM "simply don't scale for the desktop," forcing distro builders to constantly rebuild programs for their specific environments. Containerized solutions like Flatpaks, Snaps and AppImages should solve this by bundling dependencies into universal packages, but the Linux community remains divided over which to adopt.

Linux Mint, for instance, refuses Snap because "Canonical has too much control over the Snap store." Hardware support further complicates this challenges, the veteran journalist writes. While Dell sells Ubuntu machines and specialist vendors like System76 and TUXEDO Computers cater to enthusiasts, "none of them make it easy" for mainstream buyers, and no major OEM strongly backs Linux. Torvalds has pointed to Chromebooks and Android as the model: Linux won on smartphones because "there's a single, unified platform with a unified way to install programs."

An anonymous reader shared this report from the site It's FOSS: Linux gives you plenty of ways to install software: native distro packages, Flatpak, Snap, AppImage, source builds, even curl-piped installers. The catch is that each one solves a different problem, yet none of them fully eliminates the "works here, breaks there" reality across all distros. Package Forge (PkgForge) is a new project with a narrower mission: deliver truly distro-independent portable applications that run the same way across systems....

It's not a new packaging format in and of itself, nor is it trying to replace AppImages. Instead, it's an ecosystem that publishes portable packages and static binaries in curated repositories, paired with a package manager designed to install and manage them. One of the ways PkgForge stands out from some portable app efforts on Linux is its focus on accessible documentation and a security-minded distribution model. The project primarily delivers prebuilt binary packages, keeps transparent build logs, and relies on checksum verification. This helps reduce the spread of ad-hoc install scripts and the need for local compilation, which has long been a common pattern when downloading Linux software directly (and still is for many projects today).

To make life easier for the end-user, the project maintains its own frontend, called Soar... which you can use like an additional package manager, and let it handle installation, updates, and system integration. It also allows you to search for apps and utilities without having to dig through the repos online. Alternatively, you can search the PkgForge repos manually, and download and manage individual portable packages on your own. This is preferable if you're building a portable toolkit on a USB drive, testing a single app temporarily, or simply want full control over where files live...

Even if it doesn't replace Flatpak, Snap, or AppImage, it helps give definition to what a more flexible, truly distro-independent future for portable Linux apps could look like.

"Yet another distro is making the move to the KDE Plasma desktop," writes Linux magazine.

"Parrot OS, a security-focused Linux distribution, is migrating from MATE to KDE Plasma, starting with version 7.0, now available in beta." Based on Debian 13, Parrot OS's goal is a shift toward "modernization, focusing on clearing technical debt and future-proofing the system." One big under-the-hood change is that the/tmpdirectory is now automatically mounted astmpfs(in RAM), as opposed to the physical drive. By making this change, Parrot OS enjoys improved performance and reduces wear on SSDs. This shift also means that all data in/tmpis lost during a reboot.
ParrotOS senior systems engineer Dario Camonita explains the change in a blog post, calling it "not only aesthetic, but also in terms of usability and greater consistency with our future goals..."

"While MATE will continue to be supported by us as long as upstream development continues, We have noticed and observed the continuous improvements made by the KDE team..."

And elsewhere Linux Magazine notes two other distros are embracing the desktop Enlightenment: For years, Bodhi Linux was one of the very few distributions that used anything based on Enlightenment. That period of loneliness is officially over, withMX Mokshaand AV Linux 25. MX Moksha doesn't replace the original MX Linux. Instead, it will serve as an "official spin" of the distribution...

The Enlightenment desktop (and subsequently Moksha) was developed with systemd in mind, so MX Moksha uses systemd. If you're not a fan of systemd, MX Moksha is not for you. MX Moksha is lighter than MX Linux, so it will perform better on older machines. It also uses the Liquorix kernel for lower latency. AV Linux has been released with the Xfce and LXDE desktops at different times and has only recently opted to make the switch to Enlightenment.

Longtime Linux developer Greg Kroah-Hartman announced that the Linux kernel has received its first CVE tied to Rust code. Phoronix reports: This first CVE (CVE-2025-68260) for Rust code in the Linux kernel pertains to the Android Binder rewrite in Rust. There is a race condition that can occur due to some noted unsafe Rust code. That code can lead to memory corruption of the previous/next pointers and in turn cause a crash. This CVE for the possible system crash is for Linux 6.18 and newer since the introduction of the Rust Binder driver. At least though it's just a possible system crash and not any more serious system compromise with remote code execution or other more severe issues.

Quilter says its AI designed a complex Linux single-board computer in just one week, booting Debian on first power-up. "Holy crap, it's working," exclaimed one of the engineers. Tom's Hardware reports: LA-based startup Quilter has outlined Project Speedrun, which marks a milestone in computer design by AI. The headlining claims are that Quilter's AI facilitated the design of a new Linux SBC, using 843 parts and dual-PCBs, taking just one week to finish, then successfully booting Debian the first time it was powered up. The Quilter team reckon that the AI-enhanced process it demonstrated could unlock a new generation of computer hardware makers.

Intel has quietly stopped maintaining its open-source user-space driver stack for Gaudi accelerators. Phoronix reports: It turns out earlier this year Intel archived the SynapseAI Core open-source code and is no longer maintained by Intel. The open-source Synapse AI Core GitHub repository was archived in February and README updated with: "This project will no longer be maintained by Intel. Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project. Intel no longer accepts patches to this project. If you have an ongoing need to use this project, are interested in independently developing it, or would like to maintain patches for the open source software community, please create your own fork of this project."

This week System76 launched the first stable release of its Rust-based COSMIC desktop environment. Announced in 2021, it's designed for all GNU/Linux distributions — and it shipping with Pop!_OS 24.04 LTS (based on Ubuntu 24.04 LTS).

An anonymous reader shared this report from 9to5Linux: Previous Pop!_OS releases used a version of the COSMIC desktop that was based on the GNOME desktop environment. However, System76 wanted to create a new desktop environment from scratch while keeping the same familiar interface and user experience built for efficiency and fun. This means that some GNOME apps have been replaced by COSMIC apps, including COSMIC Files instead of Nautilus (Files), COSMIC Terminal instead of GNOME Terminal, COSMIC Text Editor instead of GNOME Text Editor, and COSMIC Media Player instead of Totem (Video Player).

Also, the Pop!_Shop graphical package manager used in previous Pop!_OS releases has now been replaced by a new app called COSMIC Store.
"If you're ambitious enough, or maybe just crazy enough, there eventually comes a time when you realize you've reached the limits of current potential, and must create something completely new if you're to go further..." explains System76 founder/CEO Carl Richell: For twenty years we have shipped Linux computers. For seven years we've built the Pop!_OS Linux distribution. Three years ago it became clear we had reached the limit of our current potential and had to create something new. Today, we break through that limit with the release of Pop!_OS 24.04 LTS with the COSMIC Desktop Environment. Today is special not only in that it's the culmination of over three years of work, but even more so in that System76 has built a complete desktop environment for the open source community... I hope you love what we've built for you. Now go out there and create. Push the limits, make incredible things, and have fun doing it!

Steven J. Vaughan-Nichols files this report from Tokyo: At the invitation-only Linux Kernel Maintainers Summit here, the top Linux maintainers decided, as Jonathan Corbet, Linux kernel developer, put it, "The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the 'experimental' tag will be coming off." As Linux kernel maintainer Steven Rosted told me, "There was zero pushback."

This has been a long time coming. This shift caps five years of sometimes-fierce debate over whether the memory-safe language belonged alongside C at the heart of the world's most widely deployed open source operating system... It all began when Alex Gaynor and Geoffrey Thomas at the 2019 Linux Security Summit said that about two-thirds of Linux kernel vulnerabilities come from memory safety issues. Rust, in theory, could avoid these by using Rust's inherently safer application programming interfaces (API)... In those early days, the plan was not to rewrite Linux in Rust; it still isn't, but to adopt it selectively where it can provide the most security benefit without destabilizing mature C code. In short, new drivers, subsystems, and helper libraries would be the first targets...

Despite the fuss, more and more programs were ported to Rust. By April 2025, the Linux kernel contained about 34 million lines of C code, with only 25 thousand lines written in Rust. At the same time, more and more drivers and higher-level utilities were being written in Rust. For instance, the Debian Linux distro developers announced that going forward, Rust would be a required dependency in its foundational Advanced Package Tool (APT).

This change doesn't mean everyone will need to use Rust. C is not going anywhere. Still, as several maintainers told me, they expect to see many more drivers being written in Rust. In particular, Rust looks especially attractive for "leaf" drivers (network, storage, NVMe, etc.), where the Rust-for-Linux bindings expose safe wrappers over kernel C APIs. Nevertheless, for would-be kernel and systems programmers, Rust's new status in Linux hints at a career path that blends deep understanding of C with fluency in Rust's safety guarantees. This combination may define the next generation of low-level development work.

New submitter emangwiro shares a report: The HDMI Forum, responsible for the HDMI specification, continues to stonewall open source. Valve's Steam Machine theoretically supports HDMI 2.1, but the mini-PC is software-limited to HDMI 2.0. As a result, more than 60 frames per second at 4K resolution are only possible with limitations. In a statement to Ars Technica, a Valve spokesperson confirmed that HDMI 2.1 support is "still a work-in-progress on the software side." "We've been working on trying to unblock things there."

The Steam Machine uses an AMD Ryzen APU with a Radeon graphics unit. Valve strictly adheres to open-source drivers, but the HDMI Forum is unwilling to disclose the 2.1 specification. According to Valve, they have validated the HDMI 2.1 hardware under Windows to ensure basic functionality.