Linux

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:

Introduction

Steam’s monthly Hardware & Software Survey, published by Valve, offers a window into what operating systems, hardware, and software choices its user base is making. It has become a key barometer for understanding trends in PC gaming, especially for less dominant platforms like Linux. The newest data shows that Linux usage among Steam users has edged downward subtly. While the drop is small, it raises interesting questions about momentum, hardware preferences, and what might lie ahead for Linux gaming.

This article dives into the latest numbers, explores what may be pushing them to abandon Steam, and considers what it means for Linux users, developers, and Valve itself.

Recent Figures: What the Data Shows

• June 2025 Survey Outcome: In June, Linux’s slice of Steam’s user base stood at 2.57%, down from approximately 2.69% in May — a decrease of 0.12 percentage points.

• Year-Over-Year Comparison: Looking back to June 2024, the Linux share was around 2.08%, so even with this recent slip, there’s still an upward trend compared to a year ago.

• Distribution Among Linux Users: A significant portion of Linux gamers are using Valve’s own SteamOS Holo (currying sizable usage numbers via Steam Deck and similar devices). In June, roughly one-third of the Linux user group was on SteamOS Holo.

• Hardware Insights:

  • Among Linux users, AMD CPUs dominate: about 69% of Linux gamers use AMD in June.

  • Contrast that with the Windows-only survey, where Intel still has about 60% CPU share to AMD’s 39%.

Interpreting the Slip: What Might Be Behind the Dip

Though the drop is modest, a number of factors likely combine to produce it. Here are possible causes:

1. Statistical Noise & Normal Fluctuation Monthly survey results tend to vary a bit, especially for smaller share percentages. A 0.12% decrease could simply be part of the normal ebb and flow.

2. Sampling and Survey Methodology

   • Survey participation may shift by region, language, hardware type, or time of year. If fewer Linux users participated in a given month, the percentage would drop even if absolute numbers stayed flat.

   • Language shifts in Steam’s usage have shown up before; changes in how many users set certain settings or respond could affect results.

   • Latency or delays in uploading or processing survey data might also contribute to anomalies.

3. External Hardware & Platform Trends