Linux Journal

by George Whittaker

In June 2025, the Qt team officially rolled out Qt Creator 17, marking a notable milestone for developers who rely on this IDE for cross-platform Qt, C++, QML, and Python work. While there are many changes under the hood, two of the spotlighted improvements are its updated default visual style and significant enhancements in how CMake is supported. Below, we’ll explore these in depth, assess their impact, and offer guidance on how to adopt the new features smoothly.

What's New in Qt Creator 17: A Snapshot

Before zooming into the theme and CMake changes, here are some of the broader enhancements in version 17 to set context:

• The “2024” theme set (light and dark variants) — which first appeared in earlier versions — becomes the foundational appearance for all new installs.

• General polish across the UI: icon refreshes, more consistent spacing, and better contrast.

• Projects now bind run configurations more tightly to the build configurations. That means selecting a build (e.g. Debug vs Release) also constrains which run configurations apply.

• Upgraded C++ tooling (with LLVM 20.1.3), improved QML formatting options, enhanced Python (pyproject.toml) support, and refinements in version control & analysis tools.

With that backdrop, let’s dive into the theme and CMake changes in more detail.

A Refreshed Visual Identity: Default “2024” Themes What Has Changed

Qt Creator 17 makes the “2024” light and dark themes the standard look & feel for new installations. These themes had been available previously (since Qt Creator 15) but in this version become the out-of-the-box configuration.

Other visual adjustments accompany the theme change:

• Icons throughout the IDE have been reviewed and updated so they align better with the new theme style.

• UI consistency is improved: spacing, contrast, and alignment between interface elements have been refined so that the environment feels more cohesive.

Why These Changes Matter

A theme isn't just aesthetics. The look and feel of an IDE affect user comfort, readability, efficiency, and even fatigue. Some benefits include:

• Improved clarity for long coding sessions: better contrast helps in low-ambient light or for users with visual sensitivity.

• Consistency across elements: less jarring visual transitions when switching between parts of the interface or when using external themes/plugins.

• Reduced setup friction: since the “2024” theme is now default, many users won’t need to hunt down or tweak theme settings just to get a modern, usable look.

Go to Full Article

by George Whittaker Introduction

Windows Subsystem for Linux (WSL) has gradually become one of Microsoft’s key bridges for developers, data scientists, and power users who need Linux compatibility without leaving the Windows environment. Over recent versions, WSL2 brought major improvements: a real Linux kernel running in a lightweight virtualized environment, much better filesystem behavior, nearly full system-call compatibility, etc. However, until recently, certain high-performance workloads, GPU computing, video encoding/decoding, and very up-to-date kernel features, were either limited, inefficient, or unavailable.

In Windows 11, Microsoft has taken bold strides to remove many of these bottlenecks. Two of the most significant enhancements are:

1. The ability for WSL to tap into the GPU for acceleration (compute, video hardware offload, etc.), reducing reliance on CPU where the GPU is much more suited.

2. More seamless Linux kernel upgrades, allowing users to run newer kernel versions inside WSL2, bringing performance, driver, and feature improvements faster.

This article walks through each thing in detail: what has changed, why it matters, how to use it, what limitations still exist, and how these developments shift what’s possible with WSL on Windows 11.

What WSL Was, and Where It Needed Improvement

Before diving into recent changes, it helps to understand what WSL (especially WSL2) already provided, and where it lagged.

• WSL1: Early versions translated Linux system calls to Windows equivalents. Good for basic command-line tools, scripts, but limited in compatibility with certain networking, kernel module, filesystem, and performance-sensitive tasks.

• WSL2: Introduced a real Linux kernel inside a lightweight VM (Hyper-V or a similar backend), better system-call compatibility, better performance especially for Linux tools, and much improved behavior for things like Docker, compiling, etc. Still, heavy workloads (e.g. ML training, video encoding, hardware-accelerated graphics) were constrained by CPU support, lack of passthrough of GPU features, older kernels, etc.

So developers were pushing Microsoft to allow more direct access to GPU functionality (CUDA, DirectML, video decoding), and to speed up how kernel updates reach users.

GPU Acceleration in WSL on Windows 11: What It Means

GPU acceleration here refers to WSL’s ability to offload certain computation or video tasks from the CPU to the GPU, enabling faster, more efficient execution. This includes:

• Compute workloads - frameworks like CUDA (for NVIDIA), DirectML, etc., so that things like deep learning, scientific computing, data-parallel tasks run much faster. Microsoft now supports running NVIDIA CUDA inside WSL to accelerate ML libraries like PyTorch, TensorFlow.

Go to Full Article

by George Whittaker Introduction

Imagine a world where every server, application, and network configuration is meticulously orchestrated via Git, where updates, audits, and recoveries happen with a single commit. This is the realm GitOps unlocks, especially potent when paired with the versatility of Linux environments. In this article, we'll dive deep into how Git-driven workflows can transform the way you manage Linux infrastructure, offering clarity, control, and confidence in every change.

GitOps Demystified: A New Infrastructure Paradigm

GitOps isn't just a catchy buzzword, it's a methodical rethink of how infrastructure should be managed.

• It treats Git as the definitive blueprint for your live systems, everything from server settings to application deployments is declared, versioned, and stored in repositories.

• With Git as the single source of truth, every adjustment is tracked, reversible, and auditable, turning ops into a transparent, code-centric process.

• Beyond simple CI/CD, GitOps introduces a continuous reconciliation model: specialized agents continuously compare the actual state of systems against the desired state in Git and correct any discrepancies automatically.

Why Linux and GitOps Are a Natural Pair

Linux stands at the heart of infrastructure, servers, containers, edge systems, you name it. When GitOps is layered onto that:

• You'll leverage Linux’s scripting capabilities (like bash) to craft powerful, domain-specific automation that dovetails perfectly with GitOps agents.

• The transparency of Git coupled with Linux’s flexible architecture simplifies debugging, auditing, and recovery.

• The combination gives infrastructure teams the agility to iterate faster while keeping control rigorous and secure.

Architecting GitOps Pipelines for Linux Environments Structuring Repositories Deliberately

A well-organized Git setup is crucial:

• Use separate repositories or disciplined directory structures for:

  • Infrastructure modules (e.g., Terraform, networking, VMs),

  • Platform components (monitoring, ingress controllers, certificates),

  • Application-level configurations (Helm overrides, container versions).

• This separation helps ensure access controls align with responsibilities and limits risks from misconfiguration or accidental cross-impact.

Go to Full Article

by George Whittaker

This article explores how modern DevOps teams are redefining stability and reproducibility in production environments by embracing truly unchangeable operating systems. It delves into how NixOS’s declarative configuration model and OSTree’s atomic update mechanisms open the door to systems that are both resilient and transparent. We'll explain the advantages, technologies, comparisons, and real-world use cases fueling this shift.

The Paradigm Shift: From Mutable Chaos to Immutable Assurance

• Why the change happened: The traditional model, logging into servers, tweaking packages, and patching in place, has led to unpredictable environments, elusive bugs, “snowflake” systems, and configuration drift as environments diverged over time. Immutable infrastructure treats machines like fungible artifacts: if you need change, you don’t fix the running system, you replace it.

• Key benefits:

  • Reliability at scale: Automated, reproducible deployments, no divergence across servers.

  • Simplified rolling back: If something breaks, spin up the previous, working version.

  • Security by design: Core systems are read-only, reducing the attack surface.

Immutable Foundations in Action NixOS: The Declarative, Version-Controlled Linux

• How it works: System configuration, including packages, services, kernels, is expressed in the Nix language in a config file. Rebuilding produces a new system “generation,” which can be booted or rolled back.

• Why DevOps teams love it:

  • Reproducibility: Exact environments can be rebuilt from config files, promoting parity across development, CI, and production.

  • Speed and consistency gains: In one fintech case, switching to NixOS reduced deployment times by over 50 percent, erased environment-related incidents, shrank container sizes by 70%, and cut onboarding time dramatically.

  • Edge readiness: Ideal for remote systems or stateless servers rebuilt nightly to ensure fleet consistency with easy rollback.

  • Personalization meets immutability: With tools like Home Manager, even user-specific configurations (like dotfiles or shell preferences) can be managed declaratively, and consistently reproduced across machines.

Go to Full Article

by George Whittaker Introduction: Why Lightweight Matters for Kubernetes Devs

When running Kubernetes clusters for development, the operating system’s footprint can make or break performance and agility. Heavy, general-purpose Linux distributions waste memory and CPU cycles on components you’ll never use, while lightweight, container-focused distros keep your nodes lean and optimized. For developers experimenting with k3s, MicroK8s, or full-blown Kubernetes clusters, lightweight Linux offers faster spin-ups, lower overhead, and environments that better simulate production-grade setups.

In this guide, we’ll take a look at the best lightweight Linux options for Kubernetes developers, compare their strengths, and walk through code examples for quick setup. Whether you’re spinning up a local test cluster or building a scalable dev lab, this breakdown will help you pick the right base OS and make the most of your Kubernetes workflow.

Key Considerations for Dev-Focused Kubernetes Nodes

Before diving into individual distros, it’s important to understand what really matters when pairing Linux with Kubernetes:

• Minimal Resource Usage: A slim OS footprint leaves more CPU and RAM for pods and workloads.

• Container Runtime Compatibility: Built-in or easy-to-install support for containerd, CRI-O, or Docker ensures smooth cluster bootstrapping.

• Init System Support: Compatibility with systemd or OpenRC impacts how Kubernetes services are managed.

• Immutable vs. Mutable: Immutable systems like Fedora CoreOS or Talos enhance reliability but restrict tinkering, while Alpine and Ubuntu Core offer more flexibility for on-the-fly customization.

• Developer Friendliness: A distro should integrate seamlessly with kubectl, Helm, CI/CD agents, and debugging workflows.

Go to Full Article

by George Whittaker Introduction

Container technology has matured rapidly, but in 2025, two tools still dominate conversations in developer communities: Docker and Podman. Both tools are built on OCI (Open Container Initiative) standards, meaning they can build, run, and manage the same types of images. However, the way they handle processes, security, and orchestration differs dramatically. This article breaks down everything developers need to know, from architectural design to CLI compatibility, performance, and security, with a focus on the latest changes in both ecosystems.

Architecture: Daemon vs. Daemonless Docker's Daemon-Based Model

Docker uses a persistent background service, dockerd, to manage container lifecycles. The CLI communicates with this daemon, which supervises container creation, networking, and resource allocation. While this centralized approach is convenient, it introduces a single point of failure: if the daemon crashes, every running container goes down with it.

Podman’s Daemonless Approach

Podman flips the script. Instead of a single daemon, every container runs as a child process of the CLI command that started it. This design eliminates the need for a root-level service, which is appealing for environments concerned about attack surfaces. Containers continue to run independently even if the CLI session ends, and they can be supervised with systemd for long-term stability.

Developer Workflow and CLI Familiar Command Structure

Podman was designed as a near drop-in replacement for Docker. Commands like podman run, podman ps, and podman build mirror their Docker equivalents, reducing the learning curve. Developers can often alias docker to podman and keep using their existing scripts.

Run an NGINX container

Docker

docker run -d --name web -p 8080:80 nginx:latest

Podman

podman run -d --name web -p 8080:80 nginx:latest GUI Options

For desktop users, Docker Desktop remains polished and feature-rich. However, Podman Desktop has matured significantly. It now supports Windows and macOS with better integration, faster file sharing, and no licensing restrictions, making it appealing for enterprise environments.

Go to Full Article

by George Whittaker

When Red Hat announced the abrupt end of traditional CentOS in late 2020, the Linux ecosystem was shaken to its core. Developers, sysadmins, and enterprises that relied on CentOS for years suddenly found themselves scrambling for answers. Out of that disruption, two projects, AlmaLinux and Rocky Linux, emerged to carry forward the legacy of CentOS while forging their own identities. This article dives into how these two distributions established themselves as reliable, enterprise-grade options for developers and organizations alike.

The Fall of CentOS: An Industry Shockwave

For over a decade, CentOS was the backbone of countless servers, from small web hosts to enterprise data centers. It provided a stable, free, and RHEL-compatible platform, perfect for developers and administrators building and maintaining critical infrastructure.

That stability came to an end when Red Hat pivoted CentOS to a rolling-release model, CentOS Stream. Instead of offering a downstream, binary-compatible version of RHEL, Stream became a preview of future RHEL updates. This move caused widespread frustration:

• Organizations that built production environments around CentOS suddenly faced shortened support lifecycles.

• Developers who depended on a “set-and-forget” environment now had to deal with the unpredictability of a rolling release.

• Compliance-driven industries were left in limbo, as running on an unsupported OS could trigger security and regulatory risks.

This disruption created a vacuum, and the Linux community quickly stepped up to fill it.

The Birth of AlmaLinux and Rocky Linux AlmaLinux: Community-Driven, Enterprise-Ready

Shortly after the CentOS announcement, CloudLinux, a company with deep experience in server environments, launched AlmaLinux. The first stable release landed in March 2021. True to its name, “alma” meaning “soul”, the project’s mission was clear: to embody the spirit of CentOS while maintaining community governance. The non-profit AlmaLinux OS Foundation now oversees the project, ensuring it remains free and open for everyone.

Rocky Linux: A Tribute and a Promise

At almost the same time, Gregory Kurtzer, one of the original CentOS founders, unveiled Rocky Linux, named in honor of CentOS co-founder Rocky McGaugh. From the beginning, Rocky positioned itself as a 1:1 binary-compatible rebuild of RHEL, mirroring CentOS’s original mission. Its governance structure, managed by the Rocky Enterprise Software Foundation (RESF), ensures that the project remains rooted in community oversight rather than corporate ownership.

Go to Full Article

by George Whittaker A Shift in GNOME’s Core Applications

For over two decades, Eye of GNOME (often shortened to EOG) was the silent workhorse of the GNOME desktop environment. It wasn’t flashy, but it did exactly what most people expected: double-click a picture, and it opened instantly. Yet, with the arrival of GNOME 45 in late 2023, a new name appeared in the lineup of “core” apps: Loupe. From that moment forward, Loupe became the official default image viewer on GNOME desktops, displacing EOG.

This decision wasn’t made lightly. GNOME has been steadily refreshing its default applications in recent years, Gedit was replaced by GNOME Text Editor, and Cheese gave way to Snapshot. Loupe is the continuation of this modernization trend. Eye of GNOME is still available in repositories for those who want it, but the GNOME team has shifted its endorsement to Loupe as the better long-term solution.

What Loupe Brings to the Table

Loupe isn’t just a reskin of EOG. It was built from scratch with today’s hardware, design standards, and security expectations in mind. At first glance, the interface looks minimal, but there’s more happening beneath the hood than many realize.

• Rust-Powered Foundation – Unlike Eye of GNOME’s decades-old C codebase, Loupe is written in Rust. This choice immediately grants it memory safety, helping avoid whole categories of crashes and vulnerabilities. For an app that regularly opens untrusted files, this is an important safeguard.

• GPU-Accelerated Image Handling – Instead of pushing all rendering to the CPU, Loupe leverages the GPU. Panning across a large image or zooming into a 50-megapixel photo feels fluid, even on high-resolution displays.

• Touch-Friendly Navigation – GNOME has been preparing for a future that includes more touch devices. Loupe fits right in, supporting pinch-to-zoom, two-finger swipes to move between images, and smooth transitions that feel natural on both touchscreens and trackpads.

• Streamlined Metadata View – Instead of burying photo information behind a separate dialog, Loupe integrates an optional sidebar. With a click, you can see dimensions, file size, EXIF data, and even location details without leaving the main view.

• Security Through Sandboxing – Image decoding is handled in isolated processes using a new backend called Glycin. If a corrupt or malicious image tries to crash the decoder, it won’t take the entire viewer down with it.

Go to Full Article

by George Whittaker

For decades, the humble terminal has been one of the most unchanging parts of the Linux desktop. Text streams flow in monochrome grids, and while the underlying libraries have evolved, the experience has remained more or less the same. Ubuntu, however, is preparing to rewrite this narrative. The distribution is adopting Ptyxis, a fresh terminal emulator designed for modern computing, and one of its standout qualities is that it leans on the GPU for rendering rather than relying solely on the CPU.

This shift is more than cosmetic. It represents a rethink of how command-line tools should perform in an era of container-heavy development, high-DPI displays, and demanding workloads. Let’s unpack what makes Ptyxis a different breed of terminal, why Ubuntu is betting on it, and what it means for everyday users and power developers alike.

The Origin Story of Ptyxis

Ptyxis is not an accidental side project. It was initially prototyped under the name GNOME Prompt by Christian Hergert, a well-known GNOME contributor also behind GNOME Builder. Early experiments showed there was space for a terminal designed from scratch with today’s GNOME ecosystem and GPU pipelines in mind.

To avoid conflicts with existing software, the project was later rebranded as Ptyxis. The application has since matured rapidly, and major distributions such as Fedora and Ubuntu have committed to it. Ubuntu introduced it in experimental form in 24.10, and by the upcoming Ubuntu 25.10 “Questing Quokka”, it is expected to replace the aging GNOME Terminal as the default choice.

A New Kind of Terminal Experience GPU Acceleration as the Core

Traditional terminals typically rely on CPU-bound rendering stacks, often through libraries like Cairo and Pango. This works fine until you throw thousands of lines of log output or try to run full-screen text-based UIs that push rendering to its limits. Ptyxis sidesteps these bottlenecks by shifting the drawing work to the graphics processor, taking advantage of Vulkan or OpenGL backends supplied by GTK4.

The result is immediately noticeable: smooth scrolling, responsive updates, and consistent performance even with massive amounts of text on screen. It’s not just about speed, either, offloading rendering to the GPU reduces CPU strain, leaving headroom for the processes you’re actually running.

Go to Full Article

by George Whittaker Why this release cycle feels different

For most of the last decade, talk about Wayland on KDE sounded like a promise: stronger security, modern graphics, fewer legacy foot‑guns, once the pieces land. With Plasma 6, those pieces finally clicked into place. Plasma 6.1 delivered two changes that go straight to how frames hit your screen, explicit synchronization and smarter buffering, while 6.2 followed with color‑management and HDR work that makes creators and gamers care. Together, they turn “Wayland someday” into a desktop you can log into today without caveats.

The frame pipeline finally behaves Explicit sync: the missing handshake

On X11/older Wayland setups, graphics drivers and compositors often assumed when work finished (“implicit sync”), which is fine until it isn’t, especially on NVIDIA, where that guesswork frequently produced flicker or glitches. Plasma 6.1’s Wayland session speaks the explicit sync protocol instead. Now the compositor and apps exchange fences that say “this frame is done,” reducing visual artifacts and making delivery predictable. If you run the proprietary NVIDIA driver, this is the change you’ve been waiting for: NVIDIA added explicit‑sync support in the 555 series, and XWayland 24.1 gained matching support so many games and legacy X11 apps benefit as well.

What you’ll notice: fewer one‑off hitches, less tearing in XWayland content, and a general sense that motion is “locked in” rather than tentative, particularly with the 555.58+ drivers.

Dynamic triple buffering: fewer “missed the train” stutters

Traditional double buffering is cruel: miss a vblank by a hair and your framerate can fall in half. KWin 6.1 added triple buffering that only kicks in when the compositor predicts a frame won’t make the next refresh, letting another frame be “in flight” without permanently increasing latency. One of KWin’s core developers outlined how it activates selectively, tries not to add avoidable lag, and works regardless of GPU vendor. It sounds simple; it feels like the end of random judder during heavy scenes.

VRR/Adaptive‑Sync polish

Variable refresh is no longer a roulette wheel. KDE’s devs chased down stutter/flicker under Adaptive‑Sync, and those fixes landed in the same timeframe as Plasma 6.1. If your monitor supports FreeSync/G‑Sync Compatible and the GPU stack is sane, frame pacing is noticeably calmer.

Go to Full Article