Linux Journal

by George Whittaker

The openSUSE Project has officially released openSUSE Leap 16.1, introducing a major change to how the distribution can be installed, maintained, and deployed. Released on November 3, 2026, the update brings an integrated Immutable Mode that allows users to install a transactionally updated operating system with a read-only root filesystem, while continuing to offer the traditional Linux installation model.

The new approach also marks the beginning of the end for openSUSE Leap Micro as a separate distribution. Its functionality is now incorporated into Leap 16.1, giving administrators a unified platform for desktops, conventional servers, container hosts, virtual machines, and edge computing environments. Users can select the installation model that best fits their workloads without switching to an entirely different openSUSE product.

Beyond the new installation architecture, Leap 16.1 updates KDE Plasma to version 6.6, retains GNOME 48 with additional maintenance fixes, introduces LXQt 2.4, and continues using the Linux 6.12 long-term support kernel series. The release also expands container tooling, improves system monitoring, updates security components, and introduces changes designed to make enterprise-oriented Linux deployments more predictable.

Immutable Mode Becomes the Defining Feature of Leap 16.1

The most important addition to openSUSE Leap 16.1 is its new Immutable Mode, which allows the operating system to use a read-only root filesystem and transactional updates. Instead of modifying the active operating system directly whenever packages are installed or updated, the immutable configuration prepares changes in a separate filesystem snapshot.

This approach differs from a conventional Linux installation, where package managers typically modify files in the active root filesystem. On a traditional system, an update can replace libraries, executables, and configuration components while applications continue running. Although Linux package managers handle these operations carefully, interrupted updates or incompatible package combinations can sometimes leave a system in an inconsistent state.

Immutable Mode reduces this risk by preparing operating-system changes separately from the currently running environment. Updates become active after a reboot, allowing the system to start using a consistent set of packages and configuration changes. If an update introduces problems, administrators can return to an earlier snapshot rather than manually reversing individual package modifications.

The underlying technology is not entirely new to openSUSE. Similar functionality has been available through Leap Micro, which was designed for lightweight, transactionally updated server and infrastructure deployments. What changes in Leap 16.1 is that this operating model becomes an installation choice within the main Leap distribution.

Go to Full Article

by George Whittaker

The KDE Project has released KDE Plasma 6.8.2, delivering another round of stability improvements for its Wayland-based Linux desktop environment. Released on October 27, 2026, the update arrives one week after Plasma 6.8.1 and two weeks after the anniversary release of Plasma 6.8, which marked 30 years since the KDE project's founding.

This second maintenance release concentrates on correcting regressions discovered after the initial rollout. The largest collection of changes targets KWin, KDE's window manager and Wayland compositor, with fixes involving multi-GPU synchronization, display handling, pointer constraints, color pipelines, and window stacking. Additional improvements address disappearing desktop icons, application launcher behavior, remote desktop sessions, screen recording, accessibility, and system monitoring.

Although Plasma 6.8.2 does not introduce major new desktop features, its corrections are particularly important because Plasma 6.8 completed KDE's transition away from native X11 desktop sessions. With Wayland now serving as Plasma's display foundation, improvements to KWin and its supporting components directly affect the reliability of the entire desktop environment.

KDE Continues Stabilizing Its Anniversary Release

KDE Plasma 6.8 arrived on October 14, 2026, coinciding with the project's 30th anniversary. The release introduced significant desktop changes, including the retirement of native X11 sessions, additional HDR improvements, expanded remote desktop capabilities, NVIDIA graphics optimizations, and further development of KDE's Union theming engine.

The transition represented an important architectural milestone, but major desktop releases frequently expose problems that were not encountered during development or beta testing. Linux desktops must operate across numerous combinations of graphics hardware, display configurations, drivers, input devices, and applications. Even extensive testing cannot always reproduce every environment used by the wider community.

KDE acknowledged this challenge during the development cycle following Plasma 6.8, noting that users had discovered regressions that were not reported during the beta period. Contributors responded with a substantial collection of fixes, many of which have now reached the stable 6.8 branch through its first two maintenance releases.

Plasma 6.8.2 continues that stabilization effort. Rather than changing the desktop's overall direction, it improves the reliability of existing functionality and addresses issues that could affect everyday workflows. The release includes corrections across KWin, Plasma Desktop, Plasma Workspace, Discover, KRDP, KPipeWire, and several other components.

Go to Full Article

by George Whittaker

The RefreshOS project has released RefreshOS 3.1, bringing an updated Debian foundation, a dedicated software repository, improved 32-bit application compatibility, and several refinements to its KDE Plasma desktop experience. Released on October 27, 2026, the update advances the distribution's 3.x "Colorful Cosmos" series while introducing infrastructure that could significantly improve how RefreshOS delivers its own packages and configuration changes.

The new release moves from Debian 13.4 to Debian 13.7 "Trixie", incorporates Linux kernel 6.12.113, and continues using KDE Plasma 6.3.6. However, the most important development is the introduction of an official RefreshOS APT repository with separate Stable, Testing, and Experimental channels. This gives the project a more structured way to distribute customized software while continuing to benefit from Debian's established package ecosystem.

RefreshOS 3.1 also enables i386 architecture support, making it easier to install compatible 32-bit software and dependencies required by applications such as Steam. Additional changes address desktop localization, KDE integration, installer configuration, package permissions, and installation image cleanup. Together, these improvements represent an effort to make RefreshOS easier to maintain while preserving its focus on a ready-to-use Linux desktop.

RefreshOS Builds on Debian's Stable Release Model

RefreshOS is a Debian-based Linux distribution developed by eXybit Technologies, designed to provide a polished desktop environment without requiring users to configure every component manually. The project combines Debian's stable package foundation with KDE Plasma, preinstalled applications, hardware support, multimedia capabilities, and custom desktop styling.

Unlike distributions that emphasize constant adoption of the newest software versions, RefreshOS prioritizes a relatively predictable desktop experience. Its Debian foundation provides access to established security maintenance, package management, and compatibility practices, while RefreshOS adds its own configuration choices to simplify everyday use.

Version 3.1 continues that philosophy by incorporating Debian 13.7, the seventh point release of Debian 13 "Trixie." Debian published this update on September 12, 2026, primarily to consolidate security corrections and fixes for significant software problems. These point releases do not represent entirely new Debian generations. Instead, they refresh installation media and package selections so newly installed systems begin with a more current collection of fixes.

Go to Full Article

by George Whittaker

The Tails project has released Tails 7.15.1, an emergency security update addressing a compromised certificate authority that could allow attackers to impersonate legitimate HTTPS websites. Released on October 23, 2026, the update focuses on protecting users against a potentially serious man-in-the-middle attack involving certificates associated with eMudhra, an authority whose intermediate certificates were compromised.

The emergency release updates Tor Browser to version 15.0.26, addressing CVE-2026-113470, and modifies the distribution's trusted certificate authorities to block all eMudhra certificates. These changes are particularly important for Tails because the operating system routes internet traffic through the Tor network, where malicious exit nodes or other network intermediaries could potentially exploit compromised certificates to impersonate secure websites.

Unlike a conventional maintenance update, Tails 7.15.1 does not introduce major desktop features, new applications, or significant interface changes. Its purpose is to close a security gap that could undermine the authenticity of HTTPS connections. The developers recommend upgrading promptly, especially for users who rely on Tails for sensitive communications, anonymous research, journalism, or other privacy-critical activities.

Why Tails 7.15.1 Was Released as an Emergency Update

Tails, short for The Amnesic Incognito Live System, is a Debian-based Linux distribution designed to help users preserve their privacy and reduce traces of their computing activity. It typically runs from a USB stick and routes internet connections through Tor, making it useful for people who need stronger privacy protections than those provided by a conventional desktop operating system.

The distribution also emphasizes minimizing persistent data. By default, Tails operates as a live environment and does not retain ordinary session activity after shutdown. Users who need to preserve selected files and settings can configure encrypted Persistent Storage on their USB device, allowing them to maintain important information across sessions without changing the operating system's general amnesic behavior.

Because Tails is built around privacy and secure communication, problems involving HTTPS certificate validation deserve particular attention. Tor helps obscure the relationship between a user's network location and the websites they visit, but it does not automatically guarantee that every website encountered through an exit node is authentic. HTTPS provides an additional layer of protection by authenticating websites and encrypting communications between the browser and the destination server.

Go to Full Article

by George Whittaker

The Omarchy project has released Omarchy 4.0.5, introducing a substantial collection of hardware compatibility improvements, desktop performance optimizations, security fixes, and package updates for the Arch Linux-based operating system. Released on October 18, 2026, the update focuses on refining the existing desktop experience while preparing the distribution for its next major feature release.

Among the most important changes are improved NVIDIA hybrid graphics support for laptops, an updated Linux 7.2.8 kernel featuring the BORE scheduler, and compatibility improvements for Qt 6.12. The release also resolves boot-related black screens, fixes audio problems affecting certain Dell and USB speaker configurations, corrects Steam graphics driver selection, and improves the reliability of several desktop utilities.

Although version 4.0.5 is primarily a maintenance release, its improvements extend across many of the components that determine how smoothly a Linux desktop operates. From faster application launches and more responsive desktop panels to stronger security defaults and more reliable hardware detection, the update demonstrates Omarchy's continued emphasis on delivering a preconfigured Linux environment that requires relatively little manual setup.

Omarchy Continues Refining Its Arch Linux Desktop Experience

Omarchy is an opinionated Arch Linux-based distribution designed to provide a ready-to-use development and desktop environment built around the Hyprland Wayland compositor. Rather than presenting users with a minimal installation that requires extensive customization, Omarchy combines a carefully selected collection of applications, themes, keyboard shortcuts, and system configurations into a cohesive desktop experience.

The distribution has attracted attention among developers and experienced Linux users who appreciate keyboard-driven workflows, tiling window management, and the flexibility of Arch Linux without necessarily wanting to configure every component manually. Its desktop environment emphasizes efficient navigation, integrated development tools, and a consistent visual design, while retaining access to Arch's extensive software repositories.

Version 4.0.5 continues that approach by concentrating on problems that can interrupt everyday workflows. The release improves hardware compatibility, corrects regressions introduced by newer software packages, and reduces unnecessary delays in common desktop operations. Rather than introducing a dramatic redesign, the developers have focused on making the existing environment more predictable and responsive.

Go to Full Article

by George Whittaker

The KDE Project has officially released KDE Plasma 6.8, introducing a substantial collection of desktop improvements while celebrating three decades of open-source software development. Released on October 14, 2026, exactly 30 years after Matthias Ettrich announced the original KDE project, this anniversary edition brings significant changes to display management, accessibility, graphics performance, remote desktop functionality, system monitoring, and application theming.

Perhaps the most consequential development is KDE's decision to retire native X11 desktop sessions in Plasma 6.8, completing its transition toward Wayland as the primary display architecture. The release also introduces NVIDIA triple buffering by default, improved HDR support, a more capable remote desktop server, CPU affinity controls in System Monitor, and expanded capabilities for the experimental Union theming engine. These improvements reflect KDE's effort to modernize the Linux desktop while maintaining the customization and flexibility that have defined Plasma for years.

Plasma 6.8 is therefore more than a commemorative release. It represents an important architectural transition for one of Linux's most widely used desktop environments, with changes that affect both everyday users and developers building applications for the next generation of Linux desktops.

KDE Celebrates Three Decades of Open-Source Desktop Development

KDE's history began on October 14, 1996, when Matthias Ettrich proposed creating a consistent graphical desktop environment for Unix-like operating systems. At the time, Linux was becoming increasingly capable as a free operating system, but its graphical experience remained fragmented. Users could choose from several window managers and applications, yet there was no universally integrated desktop environment comparable to the commercial graphical systems available elsewhere.

The original KDE initiative sought to address that limitation by building a cohesive desktop around the Qt application framework. Over the following decades, the project evolved through several major generations, introducing increasingly sophisticated desktop technologies while expanding into applications, development frameworks, mobile interfaces, and other open-source projects.

Plasma 6.8 arrives as KDE marks its 30th anniversary, but its development priorities are focused primarily on the future. Rather than introducing a purely cosmetic anniversary edition, KDE has concentrated on modernizing underlying desktop infrastructure while improving accessibility, usability, and performance. The result is a release that combines immediately visible enhancements with architectural changes intended to support future development.

Go to Full Article

by Emma Clapp

Receiving a transaction notification is only the first step. Production software still has to decide whether that event is safe to turn into application state.

A WebSocket callback can arrive in milliseconds. What happens afterward is harder. The XRP Price may be the public-facing metric most people associate with the asset, but developers integrating the XRP Ledger have a different concern. A long-running service has to detect transactions, determine whether their outcomes are final, and update local application state without acting twice or acting too soon.

When an XRPL Event Actually Means Something

A WebSocket connection can save an application from constantly polling for new activity. On a Linux service, that means keeping the connection open and listening for the XRP Ledger events the application cares about.

The XRP Ledger’s subscribe documentation explains how applications can listen for ledger activity, transactions, and account-related events. The transactions stream reports transactions associated with closed ledgers. The transactions_proposed stream goes further and can include proposed activity that never reaches a validated ledger.

That makes an incoming notification useful, but not necessarily authoritative. A service that treats every notification as an instruction to change business state can act before the ledger has established a final result.

For a payment service, the event is where processing begins.

Validation Comes Before Fulfillment

Transaction notifications can include a validated field. When validated is true, the transaction has been included in a validated ledger and its outcome is final.

A service might see a payment involving an account tied to an order and immediately tell a fulfillment system to release the product. If that payment came from proposed activity and has not reached a validated ledger, the application has acted before it knows the final outcome.

Validation is only the first check. Transaction metadata also includes TransactionResult. A transaction can be final without producing the successful result the application expected, so inclusion in a validated ledger should not be treated as proof that a payment succeeded.

For payments, delivered_amount is the field that shows what actually reached the destination. That can matter when the amount requested and the amount ultimately delivered are not identical.

Before an order changes state, the service needs to know whether the transaction is final, whether it succeeded, and what value actually arrived.

Go to Full Article

by George Whittaker

Linux kernel developers are renewing efforts to retire the x32 application binary interface (ABI), a little-used compatibility feature that attempted to combine the advantages of 64-bit processors with the smaller memory footprint of 32-bit applications. A revised patch series submitted on October 8, 2026, proposes the first steps toward disabling the interface, potentially ending support for an architecture experiment introduced more than 14 years ago.

The latest proposal comes from Sebastian Andrzej Siewior, a Linux kernel developer at Linutronix who has been working on the removal effort throughout 2026. Rather than immediately deleting every component associated with x32, the proposed approach would first prevent the feature from being enabled through normal kernel configuration. This would give remaining users and distribution maintainers an opportunity to respond before the underlying implementation is removed.

The effort reflects a broader challenge in Linux development: maintaining compatibility with older or rarely used technologies while keeping the kernel manageable, secure, and efficient. Although x32 offered theoretical performance and memory advantages, it never achieved widespread adoption. With conventional x86_64 software dominating modern Linux systems, developers are increasingly questioning whether the additional maintenance burden remains justified.

Understanding the Linux x32 ABI

The x32 ABI was introduced with Linux kernel 3.4 in 2012 as an alternative to conventional 32-bit and 64-bit application environments. Its goal was to provide applications with access to the architectural improvements of x86_64 processors while retaining smaller data types and pointers associated with 32-bit software.

Traditional 32-bit x86 applications use the i386 ABI, which operates with a more limited register set and 32-bit execution conventions. Standard x86_64 applications, meanwhile, benefit from additional general-purpose registers, wider registers, and modern calling conventions, but they normally use 64-bit pointers. Those larger pointers can increase memory consumption in applications that maintain large numbers of pointer-heavy data structures.

The x32 ABI attempted to offer a compromise. Applications would execute using the x86_64 instruction set and its larger register file while retaining 32-bit integers, long values, and pointers. This programming model is commonly described as ILP32, meaning that integers, long integers, and pointers are all 32 bits wide.

The distinction can be illustrated by comparing the expected sizes of common C data types:

Go to Full Article

by George Whittaker

Google is exploring a new approach to Linux kernel security that could significantly change how device drivers interact with the operating system. The experimental project, known as Kage, uses compiler-based sandboxing to isolate drivers inside the kernel, potentially limiting the damage caused by memory corruption, programming errors, and exploitable vulnerabilities without requiring drivers to run as separate user-space processes.

The research was presented at the Linux Plumbers Conference 2026, held October 5–7, with Stanford University and Google researcher Zachary Yedidia discussing how LLVM's Lightweight Fault Isolation (LFI) technology can create restricted execution environments for native kernel code. Unlike conventional isolation techniques, which often depend on separate processes or virtual machines, Kage attempts to preserve the performance advantages of kernel-space execution while reducing the amount of memory individual drivers can access.

Early prototypes have already demonstrated the concept using NVMe storage, networking, and Wi-Fi drivers. However, Kage remains an experimental research project rather than a feature available in mainstream Linux distributions. Its developers are still investigating performance, hardware access, and compatibility with more complicated drivers, including graphics hardware.

Why Device Drivers Remain a Major Linux Security Challenge

Linux device drivers are responsible for connecting the operating system to hardware components, including graphics cards, network adapters, storage controllers, USB devices, and wireless chipsets. Most traditional Linux drivers execute in kernel space, giving them privileged access to system resources and the ability to interact directly with hardware. This architecture is one reason Linux can deliver high performance across such a broad range of devices, but it also creates a significant security challenge.

When an ordinary application encounters a memory error, the operating system can often terminate that process without affecting the rest of the system. Kernel drivers operate under different conditions. Because they typically share the kernel's address space and privileges, an invalid memory access or exploitable vulnerability can affect unrelated kernel components, potentially resulting in a system crash, privilege escalation, or complete compromise of the operating system.

The challenge becomes more complicated when considering the enormous number of drivers supported by Linux. Some are maintained by large organizations with extensive testing infrastructure, while others receive contributions from smaller development teams or individual maintainers. Even carefully reviewed drivers can contain bugs, particularly when they interact with complicated hardware, asynchronous operations, and memory-management mechanisms.

Go to Full Article

by George Whittaker

Linux users have long had a pragmatic relationship with text-to-speech. The classic open-source engines have been available for years, wired into accessibility tools and the occasional script, dependable but unmistakably robotic. They do the job where the job is simply to convert text to some kind of speech, but the mechanical output has kept them out of anything where the voice actually matters. The arrival of high-quality speech synthesis delivered over an API changes what is possible, letting Linux users add genuinely natural voices to scripts, services, and applications without hosting a heavyweight model themselves.

The Familiar Trade-Off

Anyone who has used the traditional Linux speech engines knows the trade-off. They are free, local, and scriptable, which fits the Linux ethos perfectly, but the voices are clearly synthetic. For accessibility and for utilitarian tasks where intelligibility is all that counts, that has been acceptable. For anything user-facing where the quality of the voice shapes the experience, it has not.

The alternative of running a modern, high-quality speech model locally is possible but comes with real costs: significant computational requirements, model management, and the ongoing maintenance of a demanding piece of infrastructure. For many use cases, particularly on servers, embedded systems, or ordinary workstations, that overhead is disproportionate to the need. This is the gap that an API-based approach fills, offering the quality of a large modern model without the burden of hosting one.

The API Approach on Linux

Delivering speech synthesis over an API fits naturally into how Linux users already build things. Rather than installing and maintaining a model, you make a request to a service and receive audio back, which you can then play, save, or pipe into whatever comes next. A text to speech api turns text into natural-sounding audio through a simple network call, which means a script or service can produce high-quality speech with nothing more than the ability to make an HTTP request and handle the response.

This composability is what makes it appealing in a Linux context. The request can come from a shell script, a systemd service, a cron job, a Python program, or any application that can talk to a network endpoint. The returned audio slots into the familiar toolchain of files, pipes, and media players. For users accustomed to assembling capabilities from small, cooperating parts, a speech API is just another well-behaved component that happens to produce audio, and it drops into existing workflows without disturbing them.

Go to Full Article

by George Whittaker

The Arch Linux project has released Archinstall 4.5, the latest version of its guided text-based installer, bringing expanded AArch64 support, new real-time Linux kernel options, additional translations, security improvements, and numerous fixes for installation workflows.

Archinstall 4.5 was released on September 29, 2026, roughly three months after Archinstall 4.4. The new version arrives just ahead of Arch Linux's October installation media refresh and has already been packaged as archinstall 4.5-1 for Arch Linux repositories.

While Archinstall remains optional, it provides users with a guided way to configure an Arch Linux installation without manually performing every step described in the Arch installation guide. Version 4.5 concentrates primarily on hardware support, installer reliability, security, and expanding the range of systems that can use the guided installation process.

AArch64 Support Gets a Major Upgrade

One of the biggest changes in Archinstall 4.5 is improved support for AArch64, the 64-bit ARM architecture.

The installer can now handle GRUB and Limine EFI installations on AArch64 systems. It also gains support for the proper AArch64 root partition type GUID.

Previously, parts of Archinstall's bootloader configuration were more heavily oriented toward x86_64 installations. The latest changes make its guided installation workflow more useful on ARM64 hardware.

AArch64 has become increasingly important throughout the Linux ecosystem. The architecture can now be found in cloud servers, development boards, laptops, workstations, and specialized computing platforms.

Supporting both GRUB and Limine EFI installations gives Archinstall more flexibility when preparing these systems.

GRUB Can Now Be Installed on AArch64

GRUB remains one of the most widely used Linux bootloaders, and Archinstall 4.5 extends its installation logic to AArch64 EFI systems.

This allows ARM64 installations to use a bootloader workflow much closer to what Archinstall already provides on conventional x86_64 UEFI computers.

The change doesn't mean every ARM device will automatically become compatible with Arch Linux. ARM hardware can still have highly platform-specific firmware and boot requirements.

It does, however, remove an important Archinstall limitation for AArch64 machines that provide conventional UEFI environments.

Limine EFI Support Expands to ARM64

The same architectural expansion applies to Limine.

Limine is a modern multiprotocol bootloader supported as one of Archinstall's bootloader choices. Archinstall 4.5 extends its EFI installation support to AArch64 as well.

Go to Full Article

by George Whittaker

The systemd project has officially released systemd 262, delivering another substantial update to the system and service manager used by most major Linux distributions. The final release was tagged on September 22, 2026, following three release candidates earlier in the month.

Systemd 262 introduces improvements across service management, containers, virtualization, encrypted storage, TPM security, networking, journal recovery, system updates, and unattended installations. Among the most interesting additions are the ability to build systemd as a single statically linked PID 1 binary, Intel TDX support in systemd-vmspawn, Live Update Orchestrator integration, improved TPM-backed encryption, and new fallback unit files embedded directly into the systemd manager.

The release also contains a rather unusual development safeguard: an AI/LLM canary intended to help identify code contributions generated by AI that haven't been properly reviewed by a human before submission.

systemd 262 Is Officially Available

The final systemd 262 source was tagged by systemd developer Luca Boccassi on September 22.

The upstream tag identifies commit 8cc40e0c5e9234bf45084751ac53b1fbfe70b492 as systemd v262, following release candidates published throughout September.

The release has already begun reaching Linux distribution development repositories.

Debian accepted systemd 262-1 into Debian Unstable on September 22, while Fedora has prepared systemd 262 packages for Fedora 45.

As usual, the speed at which systemd 262 reaches ordinary users will depend on each distribution's update policy.

systemd Can Now Become a Single Static PID 1 Binary

One of the most interesting changes in systemd 262 is support for building systemd as a single statically linked PID 1 and executor binary.

The feature is primarily intended for extremely small container environments.

Normally, systemd depends on a collection of dynamically linked libraries and supporting components. That architecture makes sense for a complete Linux distribution, but containers sometimes need a much smaller runtime environment.

The new static configuration makes it possible to create a more self-contained systemd executable suitable for minimal container images.

These builds avoid dynamically loading optional libraries and use simplified mechanisms for resolving users and groups rather than relying on the complete Name Service Switch infrastructure.

This doesn't mean normal Linux distributions will suddenly replace their standard systemd packages with a giant static executable. The capability is specifically useful for specialized container and minimal-system deployments.

Go to Full Article

by George Whittaker

Ubuntu administrators running containerized workloads have a new Linux kernel security problem to watch closely. Public exploit code is now available for CVE-2026-80521, a Linux kernel use-after-free vulnerability that can allow an unprivileged process inside a container to escape and obtain root privileges on the underlying host.

Security firm DepthFirst published its research and exploit on September 22, 2026, demonstrating the attack against Ubuntu 26.04 LTS. The underlying Linux kernel vulnerability had already been fixed upstream on August 6, but as of September 23, Ubuntu's security tracker still lists the main kernel package in Ubuntu 26.04 LTS as "Vulnerable, work in progress," while Ubuntu 24.04 LTS is also listed as vulnerable.

The situation is particularly important for Docker, Kubernetes, cloud infrastructure, and other environments that run potentially untrusted workloads because the vulnerable kernel functionality can be reached through ordinary operations available inside standard containers.

There is currently no confirmed evidence that CVE-2026-80521 is being actively exploited in real-world attacks, and the vulnerability isn't listed in CISA's Known Exploited Vulnerabilities catalog. The availability of working public exploit code nevertheless makes the patch gap considerably more important.

CVE-2026-80521 Is a Linux Kernel Vulnerability

Although Ubuntu is receiving much of the attention because the newly published exploit specifically targets it, CVE-2026-80521 is fundamentally a Linux kernel vulnerability.

The problem exists in the kernel's AF_UNIX socket subsystem, specifically within its garbage collection mechanism.

AF_UNIX sockets, commonly called Unix-domain sockets, provide local inter-process communication between applications running on the same system.

Unlike conventional network sockets, they don't need to communicate across a network. They are widely used by Linux applications and services for fast communication between local processes.

They also support passing file descriptors between processes through SCM_RIGHTS messages, and it is the kernel's management of these references that creates the conditions for CVE-2026-80521.

A Race Condition Leads to Use-After-Free

At the technical level, CVE-2026-80521 involves a race condition inside the AF_UNIX garbage collector.

The kernel needs to track references between Unix sockets when file descriptors are passed between processes. Circular references can develop, where one socket effectively references another while that socket references something else in the same group.

Linux represents these relationships internally and periodically determines which references can safely be removed.

Go to Full Article

by George Whittaker

The Fedora Project has officially released Fedora Linux 45 Beta, giving users an early look at the technologies expected to form the foundation of the final Fedora 45 release. The beta became available on September 15, 2026, after Fedora's Quality team approved Release Candidate 1.3 for publication.

Fedora 45 Beta brings significant changes throughout the operating system, including Python 3.15, GCC 16.2, glibc 2.44, GNU Binutils 2.47, Go 1.27, LLVM 23, Podman 6, stricter RPM signature verification, improved DNF5 protections, a new userspace virtual console, standardized desktop secret storage, and substantial installer improvements.

The release is available across Fedora Workstation, KDE Plasma Desktop, Server, Cloud, IoT, Atomic Desktops, Spins, and Labs, although a few prerelease images are excluded.

Fedora 45 Beta Is Now Available

Fedora Linux 45 Beta represents the final major public testing milestone before Fedora 45 reaches stable status.

Fedora describes its beta releases as code-complete previews that closely represent what users should expect from the final version. Development isn't finished, however, and bugs or incomplete migrations can still be discovered during real-world testing.

Fedora 45 Beta is currently available in several major editions:

• Fedora Workstation 45 Beta
• Fedora KDE Plasma Desktop 45 Beta
• Fedora Server 45 Beta
• Fedora Cloud 45 Beta
• Fedora IoT 45 Beta
• Fedora Atomic Desktops
• Fedora Spins
• Fedora Labs

Existing Fedora installations can also be upgraded to the beta using Fedora's DNF system-upgrade process.

Fedora's official Workstation download page confirms Beta 1.3 images for both x86_64 and AArch64 systems.

A New Virtual Console with kmscon

One of Fedora 45's more unusual system-level changes is the replacement of the traditional in-kernel console with kmscon.

Fedora describes kmscon as a modern userspace virtual terminal implementation that provides smoother rendering, better internationalization and font handling, improved visual integration, and security improvements compared with the older console infrastructure.

This affects the virtual terminals users encounter outside their normal graphical desktop session.

Most desktop users spend relatively little time interacting directly with these consoles, but they remain important for troubleshooting, system administration, servers, recovery operations, and systems running without a graphical environment.

Moving that functionality into userspace also gives Fedora more flexibility for future development instead of relying entirely on the legacy kernel console implementation.

Go to Full Article

by George Whittaker

The Thunderbird team has officially released Thunderbird 156, bringing another round of new features, security improvements, authentication enhancements, and reliability fixes to the popular open-source email client. Released on September 15, 2026, the update is available for Linux alongside Windows and macOS.

Thunderbird 156 is not a dramatic redesign of the desktop mail client. Instead, it concentrates on improving areas that matter to everyday users and system administrators, including OAuth authentication, OpenPGP, POP3, IMAP, Exchange Web Services, SMTP, attachments, calendars, enterprise policies, and security.

For Linux users in particular, the release delivers several fixes affecting common mail protocols and account configurations while retaining support for Linux environments using GTK+ 3.14 or newer.

Thunderbird 156 Arrives on Linux

Thunderbird 156 follows version 154, which arrived in August with features including optional system tray operation and Microsoft Graph support for Microsoft 365.

Version 156 continues the project's monthly release cycle with a more targeted collection of authentication, security, compatibility, and reliability improvements.

According to Thunderbird's official release notes, version 156 requires:

• Linux: GTK+ 3.14 or newer
• Windows: Windows 10 or newer
• macOS: macOS 10.15 or newer

Thunderbird 156 was officially released on September 15.

Linux distribution availability will vary because distributions can package Thunderbird according to their own schedules. Users receiving Thunderbird through another packaging channel may therefore see version 156 at a different time.

Custom OAuth Support Expands

One of the most significant areas of development in Thunderbird 156 is OAuth authentication.

Thunderbird now supports custom OAuth configurations containing an issuer ID and client secret for IMAP and POP3 accounts. Custom OAuth support has also been extended specifically to POP3.

OAuth has become increasingly important as email providers move away from conventional username-and-password authentication toward token-based authentication.

For Thunderbird, broader custom OAuth support means users and organizations have greater flexibility when connecting the client to mail services that don't fit Thunderbird's predefined provider configurations.

This can be particularly useful in enterprise environments, self-hosted infrastructure, and organizations operating their own identity systems.

Exchange Custom OAuth Setup Fixed

Exchange users receive an important related correction.

Go to Full Article

by George Whittaker

The KDE Project has officially released KDE Plasma 6.7.5, delivering another round of bug fixes and stability improvements for the Plasma 6.7 desktop series. Released on September 8, 2026, the update contains roughly a month of fixes and updated translations contributed since Plasma 6.7.4 arrived in early August.

Unlike a major Plasma release, version 6.7.5 doesn't introduce a large collection of new desktop features. Instead, KDE has focused on fixing problems affecting Discover, KWin, Wayland, networking, System Monitor, Plasma Desktop, RPM-OSTree systems, Snap updates, HDR rendering, and several other components.

For users already running Plasma 6.7, this makes version 6.7.5 primarily a maintenance upgrade intended to make the desktop more dependable ahead of the next major Plasma series.

KDE Plasma 6.7.5 Arrives as the September Bugfix Release

KDE describes Plasma 6.7.5 as its September bugfix release for the Plasma 6 desktop.

The broader Plasma 6.7 series originally arrived in June 2026, followed by a succession of maintenance releases:

• Plasma 6.7.1 on June 23
• Plasma 6.7.2 on June 30
• Plasma 6.7.3 on July 14
• Plasma 6.7.4 on August 4
• Plasma 6.7.5 on September 8

KDE's official download infrastructure confirms that the Plasma 6.7.5 source packages became available on September 8.

This slower maintenance cadence later in a Plasma series is normal. Once the most urgent post-release problems have been addressed, KDE generally shifts more development attention toward the next feature release while continuing to provide important fixes for the current branch.

Discover Receives Several Important Fixes

KDE's Discover software center receives some of the most noticeable improvements in Plasma 6.7.5.

One particularly annoying problem could cause Discover to become stuck while checking for updates when its Snap backend was installed but no Snap applications actually had updates available.

That problem has now been corrected.

Discover also behaves more reliably when fwupd, the Linux firmware update service, is unavailable. Previously, a broken or intentionally masked fwupd service could interfere with Discover's normal operation. Plasma 6.7.5 allows the rest of the application to continue functioning correctly in that situation.

This is useful for systems where firmware updating isn't supported, where administrators intentionally disable the service, or where fwupd encounters a configuration problem.

Firmware Updates No Longer Incorrectly Require Reboots

Another Discover correction addresses a regression involving firmware updates.

Go to Full Article

by George Whittaker

One of Linux's oldest surviving distributions is moving closer to its next major release. Slackware 16 Alpha 1 became available on September 5, 2026, marking the first formal alpha milestone on the road toward Slackware Linux 16. The release follows a major rebuild of Slackware-current using a substantially newer GNU toolchain and brings together several upgrades that have accumulated since Slackware 15.0 arrived more than four years ago.

The alpha combines Linux 6.18 LTS, GCC 16.2.0, glibc 2.44, GNU Binutils 2.47, KDE Plasma 6, and numerous updated user-space packages while retaining much of the deliberately traditional architecture that has distinguished Slackware for decades.

For longtime Slackware users, Alpha 1 is particularly significant because it provides the clearest indication yet that the lengthy Slackware 16 development cycle is moving toward an eventual stable release.

Slackware 16 Finally Reaches Alpha

Slackware doesn't operate according to the predictable six-month or annual release schedules used by many other Linux distributions.

Instead, development takes place continuously through the Slackware-current branch. Patrick Volkerding and other contributors update that development tree until it reaches a state considered suitable for a stable release.

The previous major version, Slackware 15.0, was released in February 2022. More than four and a half years later, Slackware-current has now officially reached the first alpha milestone for version 16.

Volkerding marked the milestone following a complete rebuild of the distribution with its newly upgraded compiler, C library, and binary utilities.

The short changelog announcement even suggested there might finally be "a light at the end of the tunnel," a promising indication for Slackware users waiting for version 16.

The Entire Distribution Was Rebuilt

One of the most consequential changes behind Alpha 1 is a complete package rebuild.

Slackware's development toolchain has moved to:

• GCC 16.2.0
• glibc 2.44
• GNU Binutils 2.47

After introducing those components, Slackware rebuilt the distribution's packages against the updated environment.

A full rebuild is much more significant than simply replacing three packages.

GCC is responsible for compiling much of the software distributed with Slackware, glibc provides fundamental C library functionality used throughout Linux user space, and Binutils supplies essential development utilities including the GNU assembler and linker.

Rebuilding the distribution against these versions gives Slackware 16 a considerably newer foundation than its predecessor.

Go to Full Article

by Malana VanTyler

These platforms help teams monitor how technical content appears in AI-generated answers, from brand mentions and citations to accuracy and referral traffic.

Search is splitting into two experiences: one built around ranked pages and another around generated answers. As AI platforms summarize Linux tutorials, open-source project documentation, API references and technical guidance, teams need ways to measure whether their content is mentioned, cited and accurately represented.

An AEO platform provides that visibility. They help writers, maintainers, developers, and content teams examine how pages appear in generated answers, which sources receive citations, and whether AI platforms send traffic to the intended documentation.

Top AEO Tools for Technical Content

AEO and AI visibility platforms vary greatly. Some are mostly about tracking mentions, while others combine AI visibility with citations, referral traffic, competitor data or content recommendations. Below is a selection of tools, both popular and niche, that can be used by technical and content teams responsible for developer portals, Linux resources and open-source projects.

1. Similarweb AI Search Intelligence

Best for: Measuring AI visibility, citations and resulting website traffic in one platform.

Similarweb AI Search Intelligence gives teams a broad view of how brands and websites appear across AI-generated search experiences. It can be used to monitor brand mentions, citation frequency, prompt-level visibility and share of voice while comparing results with competitors. Similarweb also connects those measurements with its wider web and traffic intelligence, helping teams examine whether visibility and citations are producing visits to particular pages.

For technical content teams, this combination can make it easier to trace the path from an AI answer to its cited source and then to referral traffic. Teams can identify prompts where documentation is absent, determine which domains are being cited instead, and investigate whether AI-referred visitors reach the intended technical

pages. For example, an open-source project could examine whether prompts about installation on Ubuntu, package dependencies or command-line configuration lead users to its current documentation rather than an outdated forum post.

Standout feature: Similarweb combines AI visibility, citation analysis and traffic intelligence, reducing the need to examine those signals in separate platforms.

2. Rankscale.ai

Best for: Tracking technical content across a wide selection of AI engines.

Go to Full Article

by Malana VanTyler

AI security means hardening everything around the model, not just the model itself.

AI workloads have moved out of the research sandbox and into production, which means they now carry the same operational weight as any other critical service. If you want to understand what is AI security in practical terms, start here. It's not a 

separate discipline bolted onto your existing stack. It's an extension of it. The systems around a model matter as much as the model itself, and for teams running Linux and open-source infrastructure, that means applying familiar discipline to some new risks.

AI Security Is Becoming Part of the Linux Infrastructure

Treat AI workloads like production infrastructure, not side projects. A model doesn't run in isolation. It depends on an operating system, a container runtime, storage, APIs, identity systems, and a pile of dependencies. If any of those layers are weak, prompt filtering or output moderation won’t be enough.

Security teams that only look at the model may miss much of the actual attack surface. The work starts with the same questions you'd ask about any service. What's exposed? Who can reach it? What happens if it's compromised? 

The AI Attack Surface Extends Beyond the Model 

Model-serving APIs, embeddings, retrieval systems, vector databases, plugins, and CI/CD pipelines all now sit inside the perimeter. A vector database that holds proprietary documents is a data store like any other and needs the same access controls. An inference endpoint that accepts arbitrary text input is a public-facing service, and it needs rate limits and authentication like any other. Plugins and tool integrations expand what a model can touch, which also expands what an attacker can touch. It’s the same threat modeling you’d apply to a web application. 

Go to Full Article

by George Whittaker

Why security buyers are rethinking what matters most.

Security teams typically don’t struggle to find vulnerabilities as much as they have in the past. The harder part usually begins after the report arrives, once dozens of findings land in front of engineering teams already juggling patch schedules, production deadlines, and internal disagreements about urgency. Platforms like XBOW, OffSec, and Cobalt have entered that environment as organizations started rethinking what they actually need from pentesting vendors beyond annual compliance exercises.

A vulnerability may look severe inside a dashboard, while no one internally agrees whether it creates meaningful exposure or simply adds another item to an already crowded queue. Infrastructure also changes too quickly for static testing cycles to answer every operational question.

APIs update mid-quarter, contractors receive temporary access that lingers longer than expected, and cloud permissions change quietly during routine development work. Buyers evaluating vendors now spend more time asking whether testing accurately reflects the systems employees use every day.

Pentesting Vendors Now Face Different Expectations

Long reports stopped carrying the same weight years ago. Security teams already know modern environments contain weaknesses. What many organizations want now is clearer evidence showing which findings deserve immediate attention and which ones can wait without creating major operational exposure. That distinction became harder to ignore as remediation timelines stretched across larger environments.

Go to Full Article