Linux

Introduction

After years of debate and development, bcachefs—a modern copy-on-write filesystem once merged into the Linux kernel—is being removed from mainline. As of kernel 6.17, the in-kernel implementation has been excised, and future use is expected via an out-of-tree DKMS module. This marks a turning point for the bcachefs project, raising questions about its stability, adoption, and relationship with the kernel development community.

In this article, we’ll explore the background of bcachefs, the sequence of events leading to its removal, the technical and community dynamics involved, and implications for users, distributions, and the filesystem’s future.

What Is Bcachefs?

Before diving into the removal, let’s recap what bcachefs is and why it attracted attention.

• Origin & goals: Developed by Kent Overstreet, bcachefs emerged from ideas in the earlier bcache project (a block-device caching layer). It aimed to build a full-featured, general-purpose filesystem combining performance, reliability, and modern features (snapshots, compression, encryption) in a coherent design.

• Mainline inclusion: Bcachefs was merged into the mainline kernel in version 6.7 (released January 2024) after a lengthy review and incubation period.

• “Experimental” classification: Even after being part of the kernel, bcachefs always carried disclaimers about its maturity and stability—they were not necessarily recommends for production use by all users.

Its presence in mainline gave distributions a path to ship it more casually, and users had easier access without building external modules—an important convenience for adoption.

What Led to the Removal

The excision of bcachefs from the kernel was not sudden but the culmination of tension over development practices, patch acceptance timing, and upstream policy norms.

In kernel 6.17’s preparation, maintainers marked bcachefs as “externally maintained.” Though the code remained present, the change signified that upstream would no longer accept new patches or updates within the kernel tree.

This move allowed a transitional period. The code was “frozen” inside the tree to avoid breaking existing systems immediately, while preparation was made for future removal.

Introduction

The Linux Mint team has officially unveiled Linux Mint 22.2, codenamed “Zara”, on September 4, 2025. As a Long-Term Support (LTS) release, Zara will receive updates through 2029, promising users stability, incremental improvements, and a comfortable desktop experience.

This version is not about flashy overhauls; rather, it’s about refinement — applying polish to existing features, smoothing rough edges, weaving in new conveniences (like fingerprint login), and improving compatibility with modern hardware. Below, we’ll delve into what’s new in Zara, what users should know before upgrading, and how it continues Mint’s philosophy of combining usability, reliability, and elegance.

What’s New in Linux Mint 22.2 “Zara”

Here’s a breakdown of key changes, refinements, and enhancements in Zara.

• Ubuntu 24.04 (Noble) base: Zara continues to use Ubuntu 24.04 as its upstream base, ensuring broad package compatibility and long-term security support.

• Kernel 6.14 (HWE): The default kernel for new installations is 6.14, bringing support for newer hardware.

• However — for existing systems upgraded from Mint 22 or 22.1 — the older kernel (6.8 LTS) remains the default, because 6.14’s support window is shorter.

• Zara is an LTS edition, with security updates and maintenance promised through 2029.

Fingerprint Authentication via Fingwit

Zara introduces a first-party tool called Fingwit to manage fingerprint-based authentication. With compatible hardware and support via the libfprint framework, users can:

• Enroll fingerprints

• Use fingerprint login for the screensaver

• Authenticate sudo commands

• Launch administrative tools via pkexec using the fingerprint

• In some cases, bypass password entry at login (unless home directory encryption or keyring constraints force password fallback)

It is important to note that fingerprint login on the actual login screen may be disabled or limited depending on encryption or keyring usage; in those cases, the system falls back to password entry.

UI & Theming Refinements

• Sticky Notes app now sports rounded corners, improved Wayland compatibility, and a companion Android app named StyncyNotes (available via F-Droid) to sync notes across devices.

Introduction

In early September 2025, Ubuntu users globally experienced disruptive delays in installing updates and new packages. What seemed like a fleeting outage—only about 36 minutes of server downtime—triggered a cascade of effects: mirrors lagging, queued requests overflowing, and installations hanging for days. The incident exposed how fragile parts of Ubuntu’s update infrastructure can be under sudden load.

In this article, we’ll walk through what happened, why the fallout was so severe, how Canonical responded, and lessons for users and infrastructure architects alike.

What Happened: Outage & Immediate Impact

On September 5, 2025, Canonical’s archive servers—specifically archive.ubuntu.com and security.ubuntu.com—suffered an unplanned outage. The status page for Canonical showed the incident lasting roughly 36 minutes, after which operations were declared “resolved.”

However, that brief disruption set off a domino effect. Because the archives and security servers serve as the central hubs for Ubuntu’s package ecosystem, any downtime causes massive backlog among mirror servers and client requests. Mirrors found themselves out of sync, processing queues piled up, and users attempting updates or new installs encountered failed downloads, hung operations, or “404 / package not found” errors.

On Ubuntu’s community forums, Canonical acknowledged that while the server outage was short, the upload / processing queue for security and repository updates had become “obscenely” backlogged. Users were urged to be patient, as there was no immediate workaround.

Throughout September 5–7, users continued reporting incomplete or failed updates, slow mirror responses, and installations freezing mid-process. Even newly provisioning systems faced broken repos due to inconsistent mirror states.

By September 8, the situation largely stabilized: mirrors caught up, package availability resumed, and normal update flows returned. But the extended period of degraded service had already left many users frustrated.

Why a Short Outage Turned into Days of Disruption

At first blush, 36 minutes seems trivial. Why did it have such prolonged consequences? Several factors contributed:

1. Centralized repository backplane Ubuntu’s infrastructure is architected around central canonical repositories (archive, security) which then propagate to mirrors worldwide. When the central system is unavailable, mirrors stop receiving updates and become stale.

Introduction

Android has long been focused on running mobile apps, but in recent years, features aimed at developers and power users have begun pushing its boundaries. One exciting frontier: running full Linux graphical (GUI) applications on Android devices. What was once a novelty is now gradually becoming more viable, and recent developments point toward much smoother, GPU-accelerated Linux GUI experiences on Android.

In this article, we’ll trace how Linux apps have run on Android so far, explain the new architecture changes enabling GPU rendering, showcase early demonstrations, discuss remaining hurdles, and look at where this capability is headed.

The State of Linux on Android Today

Google’s Linux Terminal app is the core interface for running Linux environments on Android. It spins up a virtual machine (VM), often booting Debian or similar, and lets users enter a shell, install packages, run command-line tools, etc.

Initially, the app was limited purely to text / terminal-based Linux programs; graphical apps were not supported meaningfully. More recently, Google introduced support for launching GUI Linux applications in experimental channels.

Even now, most GUI Linux apps on Android are rendered in software, that is, all drawing happens on the CPU (via a software renderer) rather than using the device’s GPU. This leads to sluggish UI, high CPU usage, more thermal stress, and shorter battery life.

Because of these limitations, running heavy GUI apps (graphics editors, games, desktop-level toolkits) has been more experimental than practical.

What’s Changing: GPU-Accelerated Rendering

The big leap forward is moving from CPU rendering to GPU-accelerated rendering, letting the device’s graphics hardware do the heavy lifting.

At present, the Linux VM uses Lavapipe (a Mesa software rasterizer) to interpret GPU API calls on the CPU. This works, but is inefficient, especially for complex GUIs or animations.

Google is planning to integrate gfxstream into the Linux Terminal app. gfxstream is a GPU virtualization / forwarding technology: rather than reinterpreting graphics calls in software, it forwards them from the guest (Linux VM) to the host’s GPU directly. This avoids CPU overhead and enables near-native rendering speeds.

Introduction

Fedora’s beta releases offer one of the earliest glimpses into the next major version of the distribution — letting users and developers poke, test, and report issues before the final version ships. With Fedora 43 Beta, released on September 16, 2025, the community begins the final stretch toward the stable Fedora 43.

This beta is largely feature-complete: developers hope it will closely match what the final release looks like (barring last-minute fixes). The goal is to surface regression bugs, UX issues, and compatibility problems before Fedora 43 is broadly adopted.

Release & Availability

The Fedora Project published the beta across multiple editions and media — Workstation, KDE Plasma, Server, IoT, Cloud, and spins/labs where applicable. ISO images are available for download from the official Fedora servers.

Users already running Fedora 42 can upgrade via the DNF system-upgrade mechanism. Some spins (e.g. Mate or i3) are not fully available across all architectures yet.

Because it’s a beta, users should be ready to encounter bugs. Fedora encourages testers to file issues via the QA mailing list or Fedora’s issue tracking infrastructure.

Major New Features & Changes

Fedora 43 Beta brings many updates under the hood — some in visible user features, others in core tooling and system behavior.

• Fedora 43 Beta is built on Linux kernel 6.17.

• The Workstation edition features GNOME 49.

• In a bold shift, Fedora removes GNOME X11 packages for the Workstation, making Wayland-only the default and only session for GNOME. Existing users are migrated to Wayland.

• On KDE, Fedora 43 Beta ships with KDE Plasma 6.4 in the Plasma edition.

• Fedora’s Anaconda installer gets a WebUI by default for all Spins, providing a more unified and modern install experience across desktop variants.

• The installer now uses DNF5 internally, phasing out DNF4 which is now in maintenance mode.

• Auto-updates are enabled by default in Fedora Kinoite, ensuring that systems apply updates seamlessly in the background with minimal user intervention.

• The Python version in Fedora 43 Beta moves to 3.14, an early adoption to catch bugs before the upstream release.

Introduction

Simulating physics is central to robotics: before a robot ever moves in the real world, much of its learning, testing, and control happens in a virtual environment. But traditional simulators often struggle to match real-world physical complexity, especially where contact, friction, deformable materials, and unpredictable surfaces are involved. That discrepancy is known as the sim-to-real gap, and it’s one of the biggest hurdles in robotics and embodied AI.

On September 29th, the Linux Foundation announced that it is contributing Newton, a next-generation, GPU-accelerated physics engine, as a fully open, community-governed project. This move aims to accelerate robotics research, reduce barriers to entry, and ensure long-term sustainability under neutral governance.

In this article, we’ll unpack what Newton is, how its architecture stands out, the role the Linux Foundation will play, early use cases and challenges, and what this could mean for the future of robotics and simulation.

What Is Newton?

Newton is a physics simulation engine designed specifically for roboticists and simulation researchers who want high fidelity, performance, and extensibility. It was conceived through collaboration among Disney Research, Google DeepMind, and NVIDIA. The recent contribution to the Linux Foundation transforms Newton into an open governance project, inviting broader community collaboration.

• GPU-accelerated simulation: Newton leverages NVIDIA Warp as its compute backbone, enabling physics computations on GPUs for much higher throughput than traditional CPU-based simulators.

• Differentiable physics: Newton allows gradients to be propagated through simulation steps, making it possible to integrate physics into learning pipelines (e.g. backpropagation through control parameters).

• Extensible and multi-solver architecture: Users or researchers can plug in custom solvers, mix models (rigid bodies, soft bodies, cloth), and tailor functionality for domain-specific needs.

• Interoperability via OpenUSD: Newton builds on OpenUSD (Universal Scene Description) to allow flexible data modeling of robots and environments, and easier integration with asset pipelines.

• Compatibility with MuJoCo-Warp: As part of the Newton project, the MuJoCo backbone is adapted (MuJoCo-Warp) for high-performance simulation within Newton’s framework.

Introduction

In the life cycle of any kernel branch, patch releases, those minor “.x” updates, play a vital role in refining performance, patching regressions, and ironing out rough edges. Kernel 6.15.4 is one such release: it doesn’t bring headline features, but focuses squarely on stabilizing and optimizing the 6.15 series with targeted fixes in performance and networking.

While version 6.15 already introduced several ambitious changes (filesystem improvements, networking enhancements, Rust driver infrastructure, etc.), the 6.15.4 update doubles down on making those changes more robust and efficient. In this article, we'll walk through the most significant improvements, what they mean for systems running 6.15.*, and how to approach updating.

Release Highlights

The official announcement of Kernel 6.15.4 surfaced around late June 2025. The release includes:

• A full source tarball (linux-6.15.4.tar.xz) and patches.

• Signature verification via PGP for integrity.

• A changelog/diff summary comparing 6.15.3 → 6.15.4.

This update is not a major feature expansion; it’s a refinement release targeting performance regressions, network subsystem reliability, and bug fixes that emerged in prior 6.15.* builds.

Performance Enhancements

Because 6.15 already brought several ambitious changes to memory, I/O, scheduler, and mount semantics, many of the improvements in 6.15.4 are about smoothing interactions, avoiding regressions, and reclaiming performance in corner cases. While not all patches are publicly detailed in summaries, we can infer patterns based on what 6.15 introduced and what “performance patches” generally target.

One often-painful cost in high-performance workloads is flushing translation lookaside buffers (TLBs) too aggressively. Kernel 6.15 had already begun to optimize broadcast TLB invalidation using AMD’s INVLPGB (for remote CPUs) to reduce overhead in multi-CPU environments. In 6.15.4, fixes likely target edge cases or regressions in those mechanisms, ensuring TLB invalidation is more efficient and consistent.

Additionally, various memory management cleanups, object reuse, and page handling improvements tend to appear in patch releases. While not explicitly documented in the public summaries, such fixes help reduce fragmentation, locking contention, and latency in memory allocation.

Introduction

On June 11, 2025, the Python core team released Python 3.13.5, the fifth maintenance update to the 3.13 line. This release is not about flashy new language features, instead, it addresses some pressing regressions and bugs introduced in 3.13.4. The “.5” in the version number signals that this is a corrective, expedited update rather than a feature-driven milestone.

In this article, we’ll explore what motivated 3.13.5, catalog the key fixes, review changes inherited in the 3.13 stream, and discuss whether and how you should upgrade. We’ll also peek at implications for future Python releases.

What Led to 3.13.5 (Release Context)

Python 3.13 — released on October 7, 2024 — introduced several significant enhancements over 3.12, including a revamped interactive shell, experimental support for running without a Global Interpreter Lock (GIL), and preliminary JIT infrastructure.

However, after releasing 3.13.4, the maintainers discovered several serious regressions. Thus, 3.13.5 was accelerated (rather than waiting for the next regular maintenance release) to correct these before they impacted a broader user base. In discussions preceding the release, it was noted the Windows extension module build broke under certain configurations, prompting urgent action.

Because of this, 3.13.5 is a “repair” release — its focus is bug fixes and stability, not new capabilities. Nonetheless, it also inherits and stabilizes many of the improvements introduced earlier in 3.13.

Key Fixes & Corrections

While numerous smaller bugs are resolved in 3.13.5, three corrections stand out as primary drivers for the expedited update:

Under certain build configurations on Windows (for the non-free-threaded build), compiling extension modules failed. This was traced to the pyconfig.h header inadvertently enabling free-threaded builds. The patch restores proper alignment of configuration macros, ensuring extension builds succeed as before.

In 3.13.4, generator expressions stopped raising a TypeError early when given a non-iterable. Instead, the error was deferred to the time of first iteration. 3.13.5 restores the earlier behavior of raising the TypeError at creation time when the supplied input is not iterable. This change avoids subtler runtime surprises for developers.

In the summer of 2025, Denmark’s government put forward a major policy change in its digital infrastructure: moving away from using Microsoft Office 365, and in part, open-source its operations with LibreOffice. Below is an original account of what this entails, why it matters, how it’s being done, and what the risks and opportunities are.

What’s Changing and What’s Not

• The Danish Ministry of Digital Affairs has committed to replacing Microsoft Office 365 with LibreOffice.

• Earlier reports said that Windows would also be entirely swapped-out for Linux, but those reports have since been corrected: Windows will remain in use on many devices for now.

• For LibreOffice, the adoption is being phased: about half of the ministry’s employees will begin using LibreOffice (and possibly Linux in some instances) in the summer months; the rest are expected to transition by autumn.

Why Denmark Is Making This Move

A primary driver is the concern over reliance on large foreign tech companies, especially suppliers based outside Europe. By reducing dependency on proprietary software controlled by corporations abroad, Denmark aims to gain more control over its data, security, and updates.

Proprietary software comes with licensing fees, recurring costs, and often tied contracts. Adopting open-source alternatives like LibreOffice can potentially reduce those long-term expenditures.

Open-source software tends to allow more auditability, quicker patching, and the ability to adapt tools or software behavior to specific local or regulatory requirements.

Implementation Plan & Timeline

“Full” here is understood in the scope of office productivity tools (word processing, spreadsheets, slides, etc.), not necessarily replacing all legacy systems or moving everything off Windows.

Challenges & Concerns

While the vision is ambitious, there are several hurdles: