by George Whittaker 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.

Base, Support & Kernel Stack

• 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.

Major Features & Enhancements 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.

Go to Full Article

by George Whittaker 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.

Go to Full Article

by George Whittaker 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 The Linux Terminal App

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.

Limitations: Rendering & Performance

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.

Lavapipe (Current Baseline)

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.

Introducing gfxstream

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.

Go to Full Article

by George Whittaker 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.

Kernel, Desktop & Session Updates

• 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.

Installer & Package Management

• 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.

Programming & Core Tooling Updates

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

Go to Full Article

by George Whittaker 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.

Design Goals & Key Features

• 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.

Go to Full Article