Adam Gradzki's Personal Website

Adding DeepFilterNet Noise Reduction to Easy Effects on Arch Linux

2025-11-07T00:00:00-05:00

Introduction

Easy Effects (formerly PulseEffects) is a powerful audio equalizer and effects system for Linux that provides studio-quality audio processing right from your desktop. While the basic installation through most Linux distributions includes a comprehensive suite of audio effects, one crucial component is often missing: the neural network-based noise reduction plugin from DeepFilterNet.

DeepFilterNet is a state-of-the-art speech enhancement framework that uses deep learning to remove background noise from audio in real-time. Unlike traditional noise gates or spectral subtraction methods, DeepFilterNet leverages advanced neural networks trained on thousands of hours of audio to distinguish between speech and background noise with remarkable accuracy. This makes it particularly effective for removing complex, dynamic background sounds like keyboard typing, fan noise, or ambient chatter while preserving the clarity and natural quality of human speech.

Unfortunately, many Linux distributions, including Arch Linux, don't package the DeepFilterNet LADSPA plugin alongside Easy Effects due to licensing restrictions, file size considerations, or simply packaging oversights. This leaves users with a powerful audio processing suite but missing one of its most impressive capabilities.

In this guide, we'll walk through the process of manually installing the DeepFilterNet plugin to complete your Easy Effects setup, enabling professional-grade noise reduction for podcasts, voice calls, recordings, and any other audio application where clean speech matters.

Understanding the Components

Before diving into the installation process, it's helpful to understand what we're working with:

Easy Effects provides the framework and user interface for audio processing. It acts as a host for various LADSPA (Linux Audio Developer's Simple Plugin API) plugins, managing the audio routing and providing an intuitive GUI for controlling the effects.

DeepFilterNet is the neural network engine that performs the actual noise reduction. It processes audio in real-time, analyzing the frequency spectrum and using machine learning models to identify and suppress background noise while preserving speech components.

LADSPA Plugin serves as the bridge between Easy Effects and DeepFilterNet. This plugin follows the LADSPA standard, allowing Easy Effects to load and control the DeepFilterNet processing engine as if it were any other audio effect.

Prerequisites

Before proceeding with the installation, ensure you have:

Easy Effects installed: Available through your distribution's package manager
Basic command-line knowledge: Comfortable with terminal commands and file operations
Sudo/root access: Required for system-level file operations
Internet connection: To download the DeepFilterNet plugin

On Arch Linux, you can install Easy Effects using:

sudo pacman -S easyeffects

The Installation Process

Step 1: Identify Your System Architecture

First, determine whether you're running a 64-bit system (most common) or need a different architecture. You can check this using:

uname -m

For most modern systems, this will return x86_64, indicating a 64-bit architecture.

Step 2: Download the DeepFilterNet Plugin

The DeepFilterNet project provides pre-compiled LADSPA plugins through their GitHub releases. Visit the official releases page to find the appropriate version for your system:

GitHub Releases URL: https://github.com/Rikorose/DeepFilterNet/releases

Look for the latest stable release and download the appropriate LADSPA plugin file. For 64-bit systems, you'll typically want a file named something like: - libdeep_filter_ladspa-0.5.6-x86_64-unknown-linux-gnu.so

You can download this file directly using wget or curl:

# Example downloading version 0.5.6 for x86_64
curl -LO https://github.com/Rikorose/DeepFilterNet/releases/download/v0.5.6/libdeep_filter_ladspa-0.5.6-x86_64-unknown-linux-gnu.so

Alternatively, you can use your web browser to download the file from the releases page.

Step 3: Install the Plugin to the System LADSPA Directory

Linux audio applications typically look for LADSPA plugins in standard system directories. The most common location is /usr/lib64/ladspa/ on 64-bit systems. We'll move the downloaded plugin to this location and give it a simpler name that Easy Effects can easily recognize.

# Move the plugin to the system LADSPA directory and rename it
sudo mv -v libdeep_filter_ladspa-0.5.6-x86_64-unknown-linux-gnu.so /usr/lib64/ladspa/libdeep_filter_ladspa.so

The -v flag provides verbose output, confirming the move operation. The command should output something like:

renamed '/path/to/downloaded/libdeep_filter_ladspa-0.5.6-x86_64-unknown-linux-gnu.so' -> '/usr/lib64/ladspa/libdeep_filter_ladspa.so'

Why rename the file? The version-specific naming in the downloaded file helps with package management, but Easy Effects typically looks for plugins with simpler, standardized names. Renaming to libdeep_filter_ladspa.so makes it easier for the application to discover and load the plugin.

Step 4: Verify the Installation

After installing the plugin, you can verify that it's properly placed and accessible:

# Check that the file exists and has appropriate permissions
ls -la /usr/lib64/ladspa/libdeep_filter_ladspa.so

This should show the plugin file with read permissions for all users and appropriate ownership (typically root:root).

Step 5: Configure Easy Effects

Now that the plugin is installed, it's time to configure it in Easy Effects:

Launch Easy Effects: Start the application from your application menu or using the command line: easyeffects
Select Input Device: In the Easy Effects window, make sure you're working with the correct input device (your microphone).
Add DeepFilterNet Plugin:
Click on the "Add effect" or "+" button in the input effects section
Look for "DeepFilterNet" in the list of available plugins
Select it to add to your effects chain
Configure the Plugin:
Noise Reduction Level: Start with a moderate setting (around 50-70%)
Aggressiveness: Higher settings remove more noise but may affect speech quality
Voice Preservation: Balance between noise removal and natural speech quality
Test the Configuration:
Speak into your microphone while playing some background noise
Adjust the settings in real-time to find the optimal balance
Use the bypass toggle to compare the processed and unprocessed audio

Important Configuration Steps

Configure Easy Effects to Launch on Startup

To ensure your noise reduction settings are persistent and always active when you need them, you should configure Easy Effects to launch automatically when you log in:

Option 1: Use Easy Effects Built-in Startup Setting (Recommended)

Open Easy Effects
Click the menu button (☰) in the top-right corner
Select Preferences
In the General tab, look for "Launch Easy Effects at startup" or "Start on login"
Enable this toggle option

Option 2: System-level Startup Configuration

If you prefer system-level configuration or the built-in option isn't available:

For systems with GNOME Desktop:

Open Settings → Applications → Startup Applications
Click Add and browse to Easy Effects
Alternatively, run this command to add it to startup:

cp /usr/share/applications/com.github.wwmm.easyeffects.desktop ~/.config/autostart/

For systems with KDE Plasma:

Open System Settings → Startup and Shutdown → Autostart
Click Add Application and select Easy Effects

Why is this important? Easy Effects needs to be running to process audio through the DeepFilterNet plugin. Without it configured to launch on startup, you'll need to manually start the application each time you log in, and your noise reduction settings won't be automatically applied.

Configure Applications to Use the Correct Audio Input

This is a crucial step that many users miss: applications must use the "Easy Effects Source" virtual input device, not your standard microphone input.

When Easy Effects is running, it creates a virtual input source called "Easy Effects Source" (or similar depending on your system configuration). This virtual device captures your raw microphone input, processes it through DeepFilterNet and any other effects you've configured, and then outputs the filtered audio.

How to configure your applications:

For audio recording software (Audacity, etc.):

Go to recording preferences
Select "Easy Effects Source" or "Monitor of Easy Effects" as the input device
Do NOT select your physical microphone directly

For video conferencing applications:

Zoom: In Settings → Audio, select "Easy Effects Source" as the microphone
Discord: In Voice & Video settings, select "Easy Effects Source" as the input device
Teams/Google Meet: Check application settings to select the virtual input device

For system-wide configuration:

In your desktop environment's sound settings, you can often set the default input device to "Easy Effects Source"
This ensures all applications automatically use the filtered audio

⚠️ Important Warning: If applications use your standard microphone input instead of "Easy Effects Source," they will bypass all audio processing entirely. This means DeepFilterNet noise reduction (and any other effects) will not be applied, and you'll wonder why the noise reduction isn't working despite everything being correctly configured in Easy Effects.

To verify it's working:

Start Easy Effects with DeepFilterNet enabled
Open your system sound settings or pavucontrol
Look at the input devices - you should see both your physical microphone and "Easy Effects Source"
Configure your recording/conferencing app to use "Easy Effects Source"
Test by recording audio or joining a call - the noise reduction should now be active

Troubleshooting Common Issues

Plugin Not Appearing in Easy Effects

If DeepFilterNet doesn't appear in your list of available plugins:

Restart Easy Effects: Completely close and restart the application
Check file permissions: Ensure the plugin is readable by all users: sudo chmod 644 /usr/lib64/ladspa/libdeep_filter_ladspa.so
Verify LADSPA path: Some systems may use different paths. Check if plugins are loaded from:
/usr/lib/ladspa/
/usr/local/lib/ladspa/
~/.ladspa/

Audio Quality Issues

If you experience poor audio quality or distortion:

Reduce noise reduction intensity: Lower the settings to preserve more natural speech
Check input levels: Ensure your microphone isn't clipping or too quiet
Update audio drivers: Outdated audio drivers can cause compatibility issues

Performance Issues

If you experience high CPU usage or audio stuttering:

Close other applications: Neural network processing can be CPU-intensive
Adjust buffer sizes: In Easy Effects settings, increase the buffer size if available
Check system resources: Monitor CPU usage during processing

Advanced Configuration

For users wanting more control over the noise reduction process:

Multiple Microphone Setup

If you use multiple microphones, you can:

Configure separate instances of DeepFilterNet for each input
Use different settings depending on the microphone's characteristics and use case
Create preset configurations for different scenarios (podcasting, voice calls, recording)

Integration with Other Effects

DeepFilterNet works well in combination with other audio effects:

Compressor: Apply after noise reduction to even out volume levels
Equalizer: Fine-tune the frequency response after noise processing
Limiter: Prevent audio clipping after processing

Automation and Scripts

For advanced users, you can automate the noise reduction setup:

Use command-line tools to enable/disable the effect
Create scripts that switch between different noise reduction profiles
Integrate with recording software for automatic noise reduction

Performance Considerations

DeepFilterNet represents a significant advancement in noise reduction technology, but it's important to understand its resource requirements:

CPU Usage: The neural network processing requires more CPU power than traditional noise reduction methods. On modern systems, this is typically not an issue, but older hardware may struggle.
Latency: There's minimal processing delay, but it's slightly higher than simpler noise gates. For most applications (voice calls, recording), this is imperceptible.
Memory Usage: The neural network models require some RAM to load, but the overhead is reasonable for the quality improvement provided.

Alternative Solutions

While DeepFilterNet is excellent, it's worth knowing about other noise reduction options:

Traditional Noise Gates: Simpler, less resource-intensive but less effective for complex noise
Spectral Subtraction: Good for constant background noise but can create artifacts
Commercial Solutions: Professional audio software with advanced noise reduction capabilities

Conclusion

Installing DeepFilterNet for Easy Effects transforms your Linux audio setup from good to professional-grade. The neural network-based noise reduction can dramatically improve audio quality for voice recordings, podcasts, video calls, and any application where clear speech communication is essential.

While the manual installation process might seem intimidating at first, it's actually quite straightforward and provides access to one of the most advanced noise reduction technologies available in open-source audio processing. The ability to remove complex background noise while preserving natural speech quality makes this setup particularly valuable for content creators, remote workers, and anyone who needs clear audio in less-than-ideal environments.

Take the time to experiment with different settings and find the configuration that works best for your specific use case and environment. The results can be truly impressive, turning noisy, unusable audio into clear, professional-quality sound.

Integrating JIRA with Claude Code: A Complete Setup Guide

2025-10-03T16:00:00-04:00

Introduction

Managing JIRA tickets while coding can be a context-switching nightmare. Constantly jumping between your IDE, terminal, and browser disrupts your flow and wastes valuable development time. Enter the MCP Atlassian integration for Claude Code, a powerful solution that brings JIRA functionality directly into your command-line workflow.

This guide will walk you through setting up the MCP (Model Context Protocol) Atlassian server with Claude Code, enabling you to interact with JIRA issues, update tickets, and manage your workflow without leaving your terminal.

How to Use MCP Tools in Claude

A Natural Conversation Approach

You've just discovered that Claude has access to powerful integrations through the Model Context Protocol (MCP). Maybe you opened the MCP dialog and saw a list of 42 Jira tools staring back at you. You tried typing a slash command. It didn't work. You're wondering: "How am I supposed to use this tool?"

If this sounds familiar, you're not alone. The interface can be deceiving, making it seem like you need special commands or technical syntax to access these capabilities. But here's the truth that will change how you work with Claude: you don't need commands at all.

What Are MCP Tools?

Before we dive into the "how," let's quickly understand the "what." MCP (Model Context Protocol) tools are integrations that give Claude direct access to your external systems and services. In the example we're discussing, we're looking at Jira integration, which includes tools like getting user profiles, searching for issues, retrieving project details, and much more.

These aren't just theoretical capabilities. When properly configured, Claude can actually query your Jira instance, pull real data, and help you manage your work without you ever leaving the conversation.

The Paradigm Shift: Natural Language Is the Interface

Here's the revolutionary part that many users miss: the interface is conversation itself. You don't interact with these tools through commands, menus, or special syntax. You simply talk to Claude the way you would talk to a knowledgeable colleague who has access to your systems.

When you see that MCP dialog showing dozens of available tools, it's not a menu you need to navigate. It's simply showing you what's possible behind the scenes. Think of it like seeing the engine compartment of a car. You're glad to know what's under the hood, but you don't need to touch any of those components directly to drive.

How It Actually Works

Let me walk you through the magic of how this actually functions in practice. When you type a message to Claude, it analyzes what you're asking for. If your request involves information that it can retrieve using an available tool, it automatically calls that tool, get the results, and incorporate them into the response.

You might say something as simple as "Show me my Jira profile." Behind the scenes, it recognize that you're asking for Jira user profile information. It automatically invoke the jira_get_user_profile tool, retrieve your data, and present it to you in a readable format. You never see the tool being called. You just see the answer to your question.

The same principle applies to more complex requests. If you ask "Find all high-priority bugs assigned to me in the Q4 project," it understands that this requires searching Jira with specific filters. I'll automatically use the appropriate search tool with the right parameters, even though you never specified which tool to use or how to structure the query.

Practical Examples: From Questions to Results

Let's look at some real-world examples of how you might interact with these tools through natural conversation.

Getting Your Profile Information: You could simply say "What's in my Jira profile?" or "Show me my Jira user info." I'll fetch your profile details and present them in a clear, readable way.

Finding Specific Issues: Try asking "Get details about issue ABC-123" or "What's the status of ticket XYZ-456?" I'll retrieve the complete issue information including description, status, assignee, comments, and other relevant details.

Searching Across Projects: You might ask "Search for bugs in the Mobile App project" or "Find all open issues assigned to me." I'll construct the appropriate search query and return the results in a format that's easy to scan and understand.

Exploring Project Contents: Questions like "What issues are in the Engineering project?" or "Show me all the stories in our current sprint" will trigger the right tools to fetch and display that project-specific information.

The key insight is that none of these examples require you to know which specific tool does what. You're just asking for what you need in plain English.

What About Those Slash Commands?

You might be wondering about the slash commands you tried to use. In Claude's interface, slash commands do exist for certain built-in features, but they're not how you access MCP tools. The slash commands are for interface-level actions, not for invoking external integrations.

When you type something like "/jira" and get an "Unknown slash command" error, that's the interface telling you that this isn't the right approach. The MCP tools aren't activated through slash commands because they're designed to be more intuitive than that.

The Technical Magic You Don't Need to Understand

Here's what's happening behind the curtain, in case you're curious. When MCP tools are configured for your Claude instance, they register themselves as available capabilities. Each tool comes with a description of what it does and what parameters it accepts. When you send it a message, it evaluate whether any of the available tools can help answer your question. If they can, it automatically formulates the appropriate tool call, execute it, receives the results, and incorporate them into the response.

This happens in milliseconds, and from your perspective, it just looks like I'm giving you well-informed answers. You don't need to understand this process to benefit from it. That's the whole point.

Best Practices for Getting the Most Value

While you don't need special syntax, there are some conversational approaches that work particularly well with MCP tools.

Be specific when it matters. If you're looking for a particular issue, include its key identifier. If you're searching for items with specific criteria, mention those filters. The more context you provide, the better it can target tool usage.

Ask follow-up questions naturally. Once I've retrieved some information, you can dig deeper with questions like "Tell me more about that first issue" or "What are the comments on that bug?" it maintains context from our conversation and can make subsequent tool calls as needed.

Don't worry about tool names. You never need to say "Use the jira_search tool to find..." Just say "Find issues that..." and let it handle the technical implementation.

Combine requests freely. You can ask complex questions that might require multiple tool calls, like "Compare the number of open issues across all our active projects." I'll orchestrate whatever tools are needed to get you a complete answer.

When Things Don't Work as Expected

Sometimes you might ask for something and not get the results you hoped for. This usually isn't about using the wrong syntax since there's no special syntax required. Instead, it might be that the tools aren't configured yet, you don't have the right permissions in the external system, or the tool doesn't support that specific operation.

If it can't fulfill a request, I'll let you know why. Maybe the Jira integration isn't set up yet, or perhaps your Jira permissions don't allow access to certain projects. The conversation itself becomes the debugging interface.

The Broader Implication

What we're really talking about here extends beyond just Jira tools. The Model Context Protocol can connect Claude to all sorts of systems: databases, project management tools, customer relationship platforms, code repositories, and more. The principle remains the same across all of them: natural language is your interface.

This represents a fundamental shift in how we interact with software. Instead of learning each tool's specific command syntax, navigation structure, or API endpoints, you simply describe what you need. The complexity is abstracted away behind conversational interaction.

Stop Typing Commands, Start Having Conversations

If you take away one thing from this guide, let it be this: stop looking for the command syntax. There isn't one. The MCP dialog showing you available tools is informative, not prescriptive. It's telling you what's possible, not dictating how you must ask for it.

The next time you want to interact with your Jira instance, your database, or any other MCP-connected system through Claude, just ask your question as if you were talking to a colleague. "What issues am I working on?" "Find that bug we discussed last week." "Show me the project timeline."

That's it. That's the whole secret. The future of software interaction isn't about memorizing commands; it's about having natural conversations. And with MCP tools in Claude, that future is already here.

Prerequisites

Before you begin, ensure you have the following installed and configured:

Docker: The MCP Atlassian server runs as a Docker container
Claude Code: Anthropic's command-line tool for agentic coding
JIRA Access: Valid Atlassian credentials with appropriate permissions
Basic Command-Line Knowledge: Familiarity with terminal commands and environment variables

Step-by-Step Setup

Step 1: Pull the MCP Atlassian Docker Image

First, download the official MCP Atlassian Docker image from GitHub Container Registry:

docker pull ghcr.io/sooperset/mcp-atlassian:latest

This command fetches the latest version of the MCP Atlassian server, which acts as a bridge between Claude Code and your JIRA instance.

Step 2: Download the Configuration Template

Retrieve the example environment configuration file and save it to your system:

curl -L 'https://raw.githubusercontent.com/sooperset/mcp-atlassian/refs/heads/main/.env.example' -o ~/.config/mcp-atlassian.env

This creates a configuration file at ~/.config/mcp-atlassian.env that you'll customize with your JIRA credentials.

Step 3: Configure Your JIRA Credentials

Open the configuration file in your preferred text editor:

vim ~/.config/mcp-atlassian.env

You'll need to configure it based on the instructions within.

Security Note: Never commit this file to version control. Consider using proper secrets management for production environments.

Step 4: Add the MCP Server to Claude Code

claude mcp add mcp-atlassian --scope user -- docker run --rm -i --env-file $(realpath ~/.config/mcp-atlassian.env) ghcr.io/sooperset/mcp-atlassian:latest

Let's break down this command:

claude mcp add mcp-atlassian: Registers a new MCP server named "mcp-atlassian"
--scope user: Makes this configuration available at the user level
docker run --rm -i: Runs the Docker container interactively and removes it when done
--env-file $(realpath ~/.config/mcp-atlassian.env): Loads your configuration file
ghcr.io/sooperset/mcp-atlassian:latest: Specifies the Docker image to use

Step 5: Restart Claude Code

For the changes to take effect, restart your Claude Code session:

# Exit any active Claude Code session, then restart
claude

Step 6: Verify the Connection

Confirm that the MCP Atlassian server is properly connected by listing all active MCP servers:

claude mcp list

You should see mcp-atlassian in the list of available servers with a status indicating it's connected.

Step 7: Test the Integration

Within an active Claude Code session, you can verify MCP functionality by using the /mcp command:

/mcp

This will display all available MCP tools and servers, including your newly configured JIRA integration.

Common Use Cases

Once configured, you can use Claude Code to:

Query JIRA issues: Search for tickets by JQL, project, or status
Create new issues: Generate JIRA tickets directly from your terminal
Update ticket status: Transition issues through your workflow
Add comments: Document progress without opening a browser
View issue details: Get comprehensive information about specific tickets
Link commits to issues: Maintain traceability between code and tasks

Troubleshooting

Connection Issues

If the MCP server fails to connect:

Verify your Docker daemon is running: docker ps
Check that your API token is valid and hasn't expired
Ensure your JIRA URL is correct (including https://)
Confirm your user account has appropriate JIRA permissions

Configuration Not Loading

If environment variables aren't being recognized:

Verify the .env file path is correct
Check file permissions: chmod 600 ~/.config/mcp-atlassian.env
Ensure there are no syntax errors in your configuration file

Docker Pull Failures

If you can't pull the Docker image:

Check your internet connection
Verify you have sufficient disk space
Ensure Docker has permissions to pull from GitHub Container Registry

Best Practices

Keep Your API Token Secure: Treat it like a password and rotate it regularly
Use Project-Specific Configuration: Consider separate configurations for different projects
Leverage JQL: Learn JIRA Query Language to make powerful searches from Claude Code
Document Your Workflow: Create aliases or scripts for common JIRA operations
Regular Updates: Periodically update the Docker image to get latest features and security patches

Jira & Confluence Tools Overview

Core Operations

Operation	Jira	Confluence
Search	`jira_search`	`confluence_search`
	`jira_search_fields`	`confluence_search_user`
Create	`jira_create_issue`	`confluence_create_page`
	`jira_batch_create_issues`
Read/Get	`jira_get_issue`	`confluence_get_page`
	`jira_get_all_projects`	`confluence_get_page_children`
	`jira_get_project_issues`
Update	`jira_update_issue`	`confluence_update_page`
Delete	`jira_delete_issue`	`confluence_delete_page`

Comments & Labels

Feature	Jira	Confluence
Comments	`jira_add_comment`	`confluence_add_comment`
		`confluence_get_comments`
Labels		`confluence_add_label`
		`confluence_get_labels`

Jira-Specific: Agile & Sprint Management

Feature	Tools
Boards	`jira_get_agile_boards`
	`jira_get_board_issues`
Sprints	`jira_get_sprints_from_board`
	`jira_get_sprint_issues`
	`jira_create_sprint`
	`jira_update_sprint`

Jira-Specific: Workflow & Tracking

Feature	Tools
Transitions	`jira_get_transitions`
	`jira_transition_issue`
Worklogs	`jira_get_worklog`
	`jira_add_worklog`
Links	`jira_get_issue_link_types`
	`jira_create_issue_link`
	`jira_remove_issue_link`
	`jira_link_to_epic`
Versions	`jira_get_project_versions`
	`jira_create_version`
	`jira_batch_create_versions`

Additional Features

Feature	Jira	Confluence
User Profile	`jira_get_user_profile`	`confluence_search_user`
Attachments	`jira_download_attachments`
History	`jira_batch_get_changelogs`*

*Tool only available on Jira Cloud

Integrating JIRA with Claude Code streamlines your development workflow by eliminating context switching and bringing project management capabilities directly into your terminal. With this setup complete, you can focus on coding while maintaining seamless communication with your issue tracking system.

The MCP architecture opens possibilities for integrating other tools and services with Claude Code, making it a powerful hub for your entire development workflow.

Additional Resources

Lightweight Development Sandboxes with systemd-nspawn on Linux

2025-09-26T00:00:00-04:00

Why systemd-nspawn for Development Containers?

If you've ever wanted to let an AI code agent or experimental script run wild without worrying about it wreaking havoc on your system, you need isolation. While Docker is the go-to solution for many, systemd-nspawn offers a compelling alternative that's built right into systemd-based Linux distributions.

What Makes systemd-nspawn Different?

systemd-nspawn is a lightweight container manager that comes pre-installed with systemd. Think of it as "chroot on steroids" - it provides OS-level virtualization without the overhead of full virtual machines or even Docker's daemon architecture. Here's why it's particularly suited for development sandboxes:

Advantages:

Ultra-lightweight: Minimal overhead compared to VMs or Docker
Native integration: Uses systemd's built-in features, no extra daemon required
Fast startup: Containers boot in seconds
Full system containers: Run complete init systems, perfect for testing systemd services
No layered filesystem complexity: Direct filesystem access makes debugging easier
Resource efficient: Multiple containers share the host kernel with minimal memory overhead

Perfect Use Cases:

Testing destructive scripts or untrusted code
Giving AI code agents (like Cursor, Opencode, Copilot, or Claude Code) a safe playground
Development environments that mirror production
Testing system-level changes without risking your host
Learning system administration in isolation
Building and testing packages in clean environments

This guide demonstrates the setup on Arch Linux, but the concepts apply to any systemd-based distribution (Ubuntu, Debian, Fedora, etc.) with minor command adjustments.

Prerequisites

Before starting, ensure you have:

A Linux system running systemd (most modern distributions)
Root or sudo access
The arch-install-scripts package (provides pacstrap)
Basic understanding of Linux command line
At least 1-2 GB free disk space per container

Install prerequisites on Arch Linux:

sudo pacman -S arch-install-scripts

Step-by-Step Setup Guide

Step 1: Create Container Directory Structure

We'll create the container in your home directory for easy access, then symlink it to the standard systemd-nspawn location:

mkdir -p ~/containers/mycontainer
sudo ln -s ~/containers/mycontainer /var/lib/machines/mycontainer

Why this approach?

Keeps containers in your home directory (easier backups, user control)
The symlink to /var/lib/machines/ lets systemd's machinectl tools discover and manage it
You can create multiple containers by repeating with different names

Directory Structure Explained:

~/containers/ - Your personal container storage
mycontainer - The root filesystem of your container (change this name as needed)
/var/lib/machines/ - Standard location where systemd looks for containers

Step 2: Install Base System with pacstrap

Bootstrap a minimal Arch Linux installation into the container:

sudo pacstrap -K -c ~/containers/mycontainer base openssh

Command breakdown:

pacstrap - Arch's tool for installing packages to a new root
-K - Initialize an empty pacman keyring in the container
-c - Use the host's package cache (faster, saves bandwidth)
base - Minimal Arch Linux base system
openssh - SSH server for remote access

What's being installed? This creates a minimal bootable Linux system (~150-200 MB) with:

Core utilities (coreutils, bash, systemd)
Package manager (pacman)
SSH server for remote access
Basic networking tools

Time estimate: 2-5 minutes depending on your internet speed.

Step 3: Set Root Password

Enter the container and set a root password for SSH access:

sudo systemd-nspawn -D ~/containers/mycontainer
passwd
logout

What's happening here:

systemd-nspawn -D spawns a shell in the container (like chroot but better)
-D specifies the directory (root filesystem) of the container
passwd sets the root password inside the container
logout exits back to your host system

Security note: You're setting a password inside the container, not on your host. This isolation is key to the security model.

Step 4: Enable SSH and Networking in Container

Boot the container with a full init system to properly enable services:

sudo systemd-nspawn -bD ~/containers/mycontainer

Command breakdown:

-b (boot) - Starts systemd inside the container as PID 1 (full boot sequence)
Without -b, you just get a shell; with -b, you get a complete system

After it boots, log in as root with your password, then run:

systemctl enable sshd
systemctl enable systemd-networkd
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
poweroff

What each command does:

systemctl enable sshd - Start SSH server automatically on boot
systemctl enable systemd-networkd - Enable networking on boot (for DHCP)
The sed command modifies SSH config to allow root login (needed for initial access)
poweroff cleanly shuts down the container

Networking Architecture: The container will get a virtual network interface (host0) that connects to a virtual Ethernet pair on the host. This provides network isolation while still allowing internet access via NAT.

Step 5: Configure Static Network on Host

The host needs systemd-networkd to provide network connectivity for containers. First enable systemd-networkd:

sudo systemctl enable --now systemd-networkd

Then create a static network configuration for the container's virtual interface:

sudo vim /etc/systemd/network/50-ve-mycontainer.network

Add the following configuration:

[Match]
Name=ve-mycontainer
Driver=veth

[Network]
Address=192.168.200.1/24
LinkLocalAddressing=yes
DHCPServer=no
IPMasquerade=yes
LLDP=yes
EmitLLDP=customer-bridge

Restart the networking service to apply the configuration:

sudo systemctl restart systemd-networkd

What this configuration does:

[Match] section targets the virtual Ethernet interface for your container (ve-mycontainer)
[Network] section configures the host-side interface with a static IP 192.168.200.1/24
IPMasquerade=yes enables NAT so the container can access the internet through the host
DHCPServer=no disables DHCP since we'll use static addressing
LinkLocalAddressing=yes enables link-local addressing for fallback connectivity

Step 6: Start Container with machinectl

Now use systemd's container management tool to start your container:

sudo machinectl start mycontainer

About machinectl: machinectl is systemd's high-level tool for managing containers and VMs. It handles: - Starting/stopping containers - Network setup (creates virtual Ethernet pairs) - Integration with systemd's journal (logging) - Resource limits and cgroups

What's happening behind the scenes: 1. systemd creates a virtual Ethernet pair (veth) 2. One end goes into the container (host0), one stays on host (ve-mycontainer) 3. The container boots with systemd as init 4. The host interface gets configured with static IP 192.168.200.1/24 5. SSH server starts automatically 6. We'll configure the container with static IP 192.168.200.200/24 in the next step

Step 7: Configure Container Static Network

Shell into the container and configure the static network:

sudo machinectl shell mycontainer

Create the static network config inside the container:

cat > /etc/systemd/network/80-container-host0.network << 'EOF'
[Match]
Name=host0

[Network]
DHCP=no
Address=192.168.200.200/24
Gateway=192.168.200.1
DNS=192.168.200.1

[Link]
RequiredForOnline=yes
EOF

Restart networking inside the container:

systemctl restart systemd-networkd

Check the result:

ip -4 addr show host0

Expected output:

2: host0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.200.200/24 brd 192.168.200.255 scope host0

Exit the container:

exit

Reboot the container to ensure all services start properly:

sudo machinectl reboot mycontainer

Step 8: SSH into Your Container

Connect to the container via SSH from your host using the static IP:

ssh root@192.168.200.200

What you can do now:

Full isolated Linux environment
Install packages (pacman -S ...)
Run experiments, destructive scripts, untrusted code
Test system configurations
Give AI agents unrestricted access without risk

Example use case - AI code agent:

# From your host, give an AI agent access to the container
ssh root@192.168.200.200 "cd /workspace && ai-agent-run --dangerous-mode"

If something breaks, just destroy and recreate the container in seconds!

Container Management Commands

Here's your complete toolkit for managing containers:

# Start a container (if stopped)
sudo machinectl start mycontainer

# Stop a running container (graceful shutdown)
sudo machinectl stop mycontainer

# Restart a container
sudo machinectl restart mycontainer

# Enable container to start at boot
sudo machinectl enable mycontainer

# Disable auto-start
sudo machinectl disable mycontainer

# Check container status and IP address
sudo machinectl status mycontainer

# Get an interactive shell (without SSH)
sudo machinectl shell mycontainer

# Login to console (like physical machine access)
sudo machinectl login mycontainer

# Execute a single command in container
sudo machinectl shell mycontainer /usr/bin/command

# List all containers
sudo machinectl list

# Show container properties
sudo machinectl show mycontainer

# Power off immediately (hard stop)
sudo machinectl poweroff mycontainer

# Remove/unregister a container (doesn't delete files)
sudo machinectl remove mycontainer

# Copy files to container
sudo machinectl copy-to mycontainer /local/file /container/path

# Copy files from container
sudo machinectl copy-from mycontainer /container/file /local/path

Advanced Tips and Troubleshooting

Resource Limits

Limit container resources using systemd slices:

# Limit CPU (50%)
sudo systemctl set-property systemd-nspawn@mycontainer.service CPUQuota=50%

# Limit RAM (1GB)
sudo systemctl set-property systemd-nspawn@mycontainer.service MemoryMax=8G

# Limit I/O
sudo systemctl set-property systemd-nspawn@mycontainer.service IOWeight=100

How it works:

When machinectl start mycontainer runs, systemd creates a systemd-nspawn@mycontainer.service unit

The @ syntax indicates it's an instantiated service template

systemd-nspawn@ is the template, mycontainer is the instance name

You can verify the service name with:

sudo systemctl status systemd-nspawn@mycontainer.service

Persistent Storage

Mount host directories into containers:

# Start with bind mount
sudo systemd-nspawn -bD ~/containers/mycontainer \
  --bind=/home/user/projects:/workspace

Or configure in /etc/systemd/nspawn/mycontainer.nspawn:

[Files]
Bind=/home/user/projects:/workspace

Creating Multiple Containers

Easily spin up multiple isolated environments:

# Create second container
mkdir -p ~/containers/testbox
sudo ln -s ~/containers/testbox /var/lib/machines/testbox
sudo pacstrap -K -c ~/containers/testbox base openssh
# Repeat configuration steps...

Cleanup and Reset

Destroy a container completely:

# Stop container
sudo machinectl stop mycontainer

# Remove from systemd
sudo machinectl disable mycontainer

# Delete filesystem
sudo rm -rf ~/containers/mycontainer
sudo rm /var/lib/machines/mycontainer

Then recreate from Step 1 for a fresh start!

Common Issues

Container won't start:

Check logs: sudo journalctl -u systemd-nspawn@mycontainer.service
Verify symlink: ls -la /var/lib/machines/

No network in container:

Verify systemd-networkd: systemctl status systemd-networkd
Check host network config: cat /etc/systemd/network/50-ve-mycontainer.network
Check container network config: sudo machinectl shell mycontainer cat /etc/systemd/network/80-container-host0.network
Restart networkd: sudo systemctl restart systemd-networkd
Verify container IP: sudo machinectl shell mycontainer ip -4 addr show host0

SSH connection refused:

Verify sshd is running in container: sudo machinectl shell mycontainer systemctl status sshd
Check SSH config: sudo machinectl shell mycontainer cat /etc/ssh/sshd_config | grep PermitRootLogin
Try direct shell first: sudo machinectl login mycontainer

Security Considerations

Isolation Level:

systemd-nspawn provides OS-level virtualization, not full VM isolation
Containers share the host kernel (like Docker)
Not suitable for hostile/untrusted multi-tenant scenarios
Perfect for development sandboxing and testing

Hardening Options:

# Start with additional security
sudo systemd-nspawn -bD ~/containers/mycontainer \
  --private-network \    # No network access
  --read-only \          # Read-only root filesystem
  --drop-capability=all  # Drop all Linux capabilities

Best Practices:

Use non-root users inside containers when possible
Keep containers updated: sudo machinectl shell mycontainer pacman -Syu
Use --ephemeral flag for truly disposable environments
Consider SELinux/AppArmor for additional isolation

Choose systemd-nspawn when:

You need full OS containers for testing
You want minimal dependencies (systemd only)
You're testing systemd services specifically
You want direct filesystem access for debugging

Choose Docker when:

You need portable, reproducible builds
You're deploying applications to production
You want a rich ecosystem of pre-built images
You need orchestration (Kubernetes, Swarm)

Conclusion

systemd-nspawn provides a lightweight, powerful way to create isolated development environments without the complexity of full virtualization or container orchestration platforms. It's ideal for:

Safe experimentation with code that might be destructive
AI code agent sandboxing where you want to give tools unrestricted access
System-level testing of services and configurations
Development environments that mirror production systems
Learning Linux without fear of breaking your main system

The tight integration with systemd means you get enterprise-grade container management with tools you already have installed. Start simple, experiment freely, and destroy/recreate at will!

CPU specific optimized Python on AWS

2022-11-30T00:00:00-05:00

Recently there has been a need to more efficiently host our software services on AWS. As of publication this is most readily achievable for general purpose Python code with (AWS Graviton instances)[https://aws.amazon.com/ec2/graviton/]

Starting from a Debian 11 ARM EC2 t4g instance, the following commands are able to create a Python build from source optimized for the CPU architecture running on AWS. Note, LTO is enabled in the build script and it uses a huge amount of RAM, so make sure you have enough RAM or use a swapfile as I demonstrate below since I chose a t4g.small instance.

sudo apt update -y
sudo apt upgrade -y
sudo apt install -y \
    git \
    build-essential \
    gdb \
    lcov \
    libbz2-dev \
    libffi-dev \
    libgdbm-dev \
    liblzma-dev \
    libncurses5-dev \
    libreadline6-dev \
    libsqlite3-dev \
    libssl-dev \
    lzma \
    lzma-dev \
    tk-dev \
    uuid-dev \
    libxml2-dev \
    libxml2 \
    libxslt1-dev \
    libxslt1.1 \
    xvfb \
    zlib1g-dev
apt build-dep python3 -y
curl https://pyenv.run | bash

# If you have less than 8 GB RAM, create a swapfile and enable it
# Don't put the swapfile on EBS.
# It should be on your instance root volume for performance.
sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

################################################
# Append the following to the end of ~/.bashrc #
################################################

export PYENV_ROOT="$HOME/.pyenv"
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

# Restart your shell for the changes to take effect.

# Load pyenv-virtualenv automatically by adding
# the following to ~/.bashrc:

eval "$(pyenv virtualenv-init -)"

################################################
#        Restart your shell to continue        #
################################################

CFLAGS="-march=native -mtune=native" CONFIGURE_OPTS="--enable-optimizations --with-lto=full" pyenv install 3.11.1 --verbose
pyenv virtualenv 3.11.1 MY_VIRTUAL_ENVIRONMENT_NAME

Pronounce foreign words with an open source speech therapist

2022-03-01T00:00:00-05:00

Learning to pronounce words without a tutor is so much easier thanks to the open source software espeak-ng. Link to usage examples.

I can get sound and the IPA spelling of any word easily directly from a free offline program installed on my laptop. For example, the following command gives the German pronounciation of the word "meine" with the fifth female robotic voice actor, further slowed down to a crawl so I can hear it better with the "-s 80" flag:

$ espeak-ng -v de+f5 --ipa "meine" -s 80
mˈaɪnə

It is also possible to upgrade the speech engine by installing MBROLA voices for improved synthesis

Golang for loops and the range-for

2020-06-17T00:00:00-04:00

I was unable to find a find a clear answer online to what are the performance implications of using a standard for loop (e.g., for i := 0; i < len(arr); i++ {}) vs range-for (e.g., for idx, val := range arr {}) in Golang. By analyzing the assembler output I determined that as of Go 1.14 they produce similar CPU instructions for common 64-bit Intel/AMD CPUs.

The range-for loop produces two additional assembly instructions:

        movq    "".arr+8(SP), AX
        pcdata  $0, $0

This brings the total instruction count for function count2 to 13 compared to 11 for function count1.

I used https://go.godbolt.org/ at the suggestion of dominikh on Freenode IRC #golang to map the Golang functions with the corresponding assembler output.

My code for an apples-to-apples comparison between the two:

package main

func count1(arr []int) {
    for i := 0; i < len(arr); i++ {
        _ = i; _ = arr[i]
    }    
}

func count2(arr []int) {
    for i, v := range arr {
        _ = i; _ = v
    }
}

func main() {
    arr := make([]int, 100)
    for i := 0; i < len(arr); i++ {
        arr[i] = i
    }
    count1(arr)
    count2(arr)
}

count1() produces:

        pcdata  $0, $0
        pcdata  $1, $1
        movq    "".arr+16(SP), AX
        xorl    CX, CX
        jmp     count1_pc12
count1_pc9:
        incq    CX
count1_pc12:
        cmpq    CX, AX
        jlt     count1_pc9
        pcdata  $0, $-1
        pcdata  $1, $-1
        ret

count2() produces:

        pcdata  $0, $1
        pcdata  $1, $1
        movq    "".arr+8(SP), AX
        pcdata  $0, $0
        movq    8(AX), AX
        xorl    CX, CX
        jmp     count2_pc16
count2_pc13:
        incq    CX
count2_pc16:
        cmpq    CX, AX
        jlt     count2_pc13
        pcdata  $0, $-1
        pcdata  $1, $-1
        ret

count2 produces more assembler instructions which may suggest it is slower code. However, this is not always the case. To understand the real performance implications of these instructions benchmarks need to be conducted in a future article.

Faster Virtual Machines on Linux Hosts with GPU Acceleration

2020-04-06T00:00:00-04:00

Table of Contents

Overview
Introduction
GPU command architectures
Hypervisors
Conclusion

Overview

Open source virtualization technologies widely available in the Linux software ecosystem lack the ease of use of graphical performance enhancements available in commercial virtualization technologies such as VMWare Workstation or VMWare vSphere/ESXi. Intel GVT-g is a virtual graphics acceleration technology which can be accessed with the QEMU virtualization system. QEMU serves as an open-source alternative to technologies such as VMWare Workstation or VMWare vSphere/ESXi. Intel GVT-g was configured on a Thinkpad X1 Generation 6 laptop containing Intel integrated graphics resulting in successful GPU acceleration on a UEFI Windows 10 64-bit guest without relying on proprietary software aside from the guest operating system itself. Substantially improved virtualization performance is possible due to working Intel GVT-g GPU acceleration on Linux hosts.

Introduction

Computer users rely on software written for many different operating systems. Virtual machines allow computer users to simultaneously run different operating systems and switch between them easily. Virtualization has benefits such as being able to migrate installed systems to other physical machines with lower downtime, the ability to contain untrusted code in a sandbox that is difficult to escape from, maintain operation of legacy systems that are difficult to keep running on obsolete hardware, or simply running a Windows-only program on a Linux host.

Virtual machines with graphical user interfaces typically suffer from input lag and stuttering, both of which lead to a degraded user experience. Additionally, software which relies on heavy computation such as photo editing or engineering is dependent on efficient GPU access to speed up calculations by an order of magnitude or more over the host machine CPU to finish calculations in a reasonable time period. Unfortunately, not all virtualization solutions are able to leverage the physical chips on the host machine in an efficient manner, regardless of cost.

GPU command architectures

VGA Emulation (VE)
- Universally available on all virtualization platforms
API forwarding (AF)
- Intel GVT-s
- VMWare Virtual Shared Graphics Acceleration (vSGA)
- Oracle VirtualBox 3D Acceleration
Direct Pass-Through (DPT)
- Intel GVT-d
- VMWare Virtual Dedicated Graphics Acceleration (vDGA)
- Not available in VMWare Workstation
Full GPU Virtualization (FGV)
- Intel GVT-g
- VMWare Virtual Shared Pass-Through Graphics Acceleration (vGPU or MxGPU)
- Not available in VMWare Workstation

VGA Emulation (VE)

The most primitive graphics display for any virtual machine is VGA Emulation (VE). This mode is also the most inefficient. QEMU emulates a Cirrus Logic GD5446 Video card. All Windows versions starting from Windows 95 should recognize and use this graphic card.

Most hypervisors which advertise some form of "hardware acceleration" use API Forwarding (AF), which is a high performance proxy service that requires specialized drivers on both the host and guest to create a high performance instruction pipeline.

API forwarding (AF)

API Forwarding (AF) works by:

intercepting the GPU command requested by a piece of software
proxying the GPU command to the host hypervisor
executing the captured GPU command on the host from the hypervisor
bubbling the response back up to the virtual machine

This mode is very useful when many virtual machines are competing for resources of a single GPU and Full GPU Virtualization (FGV) is not possible. The hypervisor queues graphics card operations from one or more virtual machine and schedules virtual execution and memory slots for each virtual machine on a single physical GPU resource. Each virtual machine sees its own graphics card while the hypervisor splits the single physical resource up. A key drawback of AF is that usually only OpenGL and DirectX interfaces are supported by the GPU instruction proxy.

The process by which API Forwarding (AF) works is known as paravirtualization.

Direct Pass-Through (DPT)

Direct Pass-Through (DPT) is a system which exposes the GPU as a PCI device which is directly addressable by the virtual machine. Nothing besides the virtual machine can reference any resources on the GPU and it cannot be shared with the physical machine or any other virtual machines. Many devices have only one graphics card installed and using this system would mean making the graphical user interface inoperable. This method is most useful when:

the physical graphics card does not support Full GPU Virtualization (FGV)
two or more graphics cards are attached to a system
paravirtualized drivers are not available or do not work with the installed physical GPU, host hypervisor, or guest operating system

Full GPU Virtualization (FGV)

Sharing a GPU natively among multiple virtual machines is possible with Full GPU Virtualization (FGV) solutions such as Intel GVT-g. This process is also known as Hardware Assisted Virtualization (HVM), not to be confused with Paravirtualization (PV). In this mode the IOMMU hardware exposes a GPU memory interface to each virtual machine while it internally handles the memory address mappings between what it exposes to virtual machines and the actual physical memory on the GPU.

In "IOMMU and Virtualization," Susanta Nanda writes:

IOMMU provides two main functionalities: virtual-to-physical address translation and access protection on the memory ranges that an I/O device is trying to operate on.

Peak media workload performance is 95% of the native host alone when running one virtual machine and the average performance is 85% of the native host alone on media workloads according to Intel engineer Zhenyu Wang in XDC2017 presentation "Full GPU virtualization in mediated pass-through way"

Hypervisors

The hypervisors I use are software systems that enable multiple virtual machines to run simultaneously on a single physical machine. Linux users have many hypervisor options. A longer list is available here. These are a sample of some Linux hypervisors:

Oracle VirtualBox
VMWare vSphere/ESXi (technically runs beneath Linux)
VMWare Workstation
QEMU

Oracle VirtualBox

Possibly the most widely-used hypervisor is VirtualBox by Oracle. VirtualBox is open source software with the exception of the optional extension pack.

The Oracle VirtualBox extension pack provides many features which are not available in the free version. The PCI passthrough module was shipped as a Oracle VM VirtualBox extension package until the feature was scrapped.

These features are available gratis for personal and non-commerical use only.

Possession of the VirtualBox Extension Pack without a license can be problematic:

Got an email today informing me (Urgent Virtual Box Licensing Information for Company X) that there have been TWELVE (12!) downloads of the VirtualBox Extension Pack at my employer in the past year. And since the extensions are licensed differently than the base product, they'd love for us to call them and talk about how much money we owe them. Their report attached to email listed source IPs and AS number, as well as date/product/version. Out of the twelve (12!), there were always two on the same day of the same version, so really six (6!) downloads. We'll probably end up giving them $150, and I'll make sure they never get any business from places I work, because fuck Oracle. I wouldn't piss on Larry Ellison if he was on fire.

VirtualBox Linux hosts do not support GPU DPT (Direct Pass-Through) at all. All of the preliminary PCI pass-through work for Linux hosts which is needed for GPU DPT was completely stripped out on December 5th, 2019 with this message:

Linux host: Drop PCI passthrough, the current code is too incomplete (cannot handle PCIe devices at all), i.e. not useful enough

VirtualBox 2D and 3D acceleration both work according to the same principle: API forwarding (AF)

Oracle VM VirtualBox implements 3D acceleration by installing an additional hardware 3D driver inside the guest when the Guest Additions are installed. This driver acts as a hardware 3D driver and reports to the guest operating system that the virtual hardware is capable of 3D hardware acceleration. When an application in the guest then requests hardware acceleration through the OpenGL or Direct3D programming interfaces, these are sent to the host through a special communication tunnel implemented by Oracle VM VirtualBox. The host then performs the requested 3D operation using the host's programming interfaces.

VMWare vSphere/ESXi

VMWare vSphere/ESXi is a bare metal hypervisor which runs beneath any end-user operating systems. This property makes it a Type 1 Hypervisor. It supports all GPU acceleration technologies.

Virtual Shared Graphics Acceleration (vSGA) is a form of API forwarding (AF).
Virtual Dedicated Graphics Acceleration (vDGA) technology is a form of Direct Pass-Through (DPT).
VMWare Virtual Shared Pass-Through Graphics Acceleration (vGPU or MxGPU) is a form of Full GPU Virtualization (FGV).

The main limitation of VMWare vSphere/ESXi GPU acceleration is the graphics card selection. GPU passthrough is possible only with a small set of GPUs because NVIDIA drivers disable consumer-market GPUs such as the GeForce series when the drivers detect that they are running in a virtual environment. Comprehensive list of all supported graphics cards for any hardware acceleration purposes.

VMWare Workstation

VMWare Workstation only provides Virtual Shared Graphics Acceleration (vSGA), a form of API forwarding (AF). In this regard, the GPU acceleration story is identical to Oracle VirtualBox.

QEMU

QEMU is an open source virtual machine platform that is also capable of translating instructions between wholly unrelated computer architectures. It is widely available in most Linux distributions and is used extensively in industry.

After enabling GVT-g in QEMU you must also recompile QEMU with the 60 fps fix to get smooth video as of the publication date of this article.

Conclusion

QEMU eclipses VirtualBox in features and exceeds VMWare capabilities. VirtualBox is limited to API forwarding (AF) since it is not able to allow virtual machines to address graphics hardware directly in any way. VMWare solutions support all types of GPU addressing but most graphic cards made by NVIDIA disable themselves when they detect being called in Direct Pass-Through (DPT) or Full GPU Virtualization (FGV) modes. QEMU exceeds the features and provides hardware use flexibility beyond that of VMWare to bring near-native graphics performance to guest operating systems such as Windows 10 with truly minimal driver support required in the guest operating system. I recommend using QEMU on Linux when high graphics performance and low operational costs are prioritized for deploying a virtual machine environment.

Thinkpad X1 Carbon GPU Undervolting in Arch Linux

2020-04-03T00:00:00-04:00

After successfully installing Arch Linux on my Thinkpad X1 Carbon Generation 6 I began experimenting with laptop component undervolting to reduce heat and improve performance. Unfortunately it seems that the set points are being ignored to some extent.

Indeed, Francesco Palmarini reported on Github:

It is kind of impossible that your GPU can work at -1V offset voltage. On XTU I get an instant reboot on -500mV

However, despite the apparent physical impossibility of applying such a large voltage offset, there seems to be a real effect on performance. Applying a -500 mV voltage offset resulted in approximately 2 watts lower peak power consumption as measured by throttled monitoring.

I benchmarked GPU performance at different voltage offsets to see if they are ignored after a certain point. The result shows diminishing returns beyond 300 millivolt undervoltage. Still, it is not clear whether the larger undervoltage settings are actually being set correctly because it should not be possible for the CPU to operate when undervolted 900 mV.

# config.toml

[voltage]
start = 0
stop = -1000
step = -100

# test.py

import toml
from subprocess import run
from multiprocessing import Process
from tempfile import NamedTemporaryFile
from jinja2 import Template
from tqdm import tqdm

def undervolt_gpu(voltage):
    log = f"undervolt___{voltage}.log"
    print(f"undervolt_gpu: saving to {log}")
    with open("lenovo_fix.conf") as fd:
        tpl = Template(fd.read()).render(voltage=voltage)
    with NamedTemporaryFile(mode="w") as ntf:
        ntf.write(tpl)
        ntf.flush()
        cmd = f"sudo /usr/lib/throttled/lenovo_fix.py --monitor --log {log} --config {ntf.name}"
        print("voltage", voltage, "cmd", cmd)
        run(cmd, check=True, shell=True)

if __name__ == "__main__":
    cfg = toml.load("config.toml")
    voltages = list(range(cfg["voltage"]["start"], cfg["voltage"]["stop"], cfg["voltage"]["step"]))
    print(voltages)
    for voltage in tqdm(voltages):
        p = Process(target=undervolt_gpu, args=(voltage,))
        p.start()
        cmd = f"glmark2 -b :duration=2.0 --fullscreen | tee glmark___{voltage}.log"
        print("process launched")
        run(cmd, check=True, shell=True)
        print("process terminating")
        p.terminate()
        print("process terminated")

I generated a CSV report by regex parsing the data logged from glmark2 and lenovo_fix.py:

# report.py

import re
import os.path
import toml
import csv

cfg = toml.load("config.toml")
voltages = list(range(cfg["voltage"]["start"], cfg["voltage"]["stop"], cfg["voltage"]["step"]))

with open('undervolting.csv', 'w', newline='') as csvfile:
    fieldnames = ['glmark', 'voltage', 'package_watts', 'graphics_watts', 'dram_watts']
    writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
    writer.writeheader()
    for voltage in voltages:
        glmark_p = f"glmark___{voltage}.log"
        undervolt_p = f"undervolt___{voltage}.log"
        try:
            with open(glmark_p) as fd:
                try:
                    glmark_s = re.search("(?:glmark2 Score: )(\d+)", fd.read()).group(1)
                except AttributeError:
                    continue
        except FileNotFoundError:
            continue
        try:
            with open(undervolt_p) as fd:
                for line in fd:
                    package, graphics, dram = getattr(re.search(
                        "(?:Package: )(\d*\.?\d+)(?: W - Graphics: )(\d*\.?\d+)(?: W - DRAM: )(\d*\.?\d+)", line
                    ), "groups", lambda: ("0", "0", "0",))()
                    writer.writerow(dict(
                        glmark=glmark_s,
                        voltage=voltage,
                        package_watts=package,
                        graphics_watts=graphics,
                        dram_watts=dram))
        except FileNotFoundError:
            continue

throttled GPU voltage offset adjustment has some effect on GPU performance, but it is unclear to what extent this is meaningful with the Linux implementation. GPU voltage offset adjustment parameters are not on the same scale as those within the Windows-based Intel XTU utility. The relationship between throttled GPU voltage offset and Intel XTU voltage offset warrants further research to fully unlock the battery life and calculation performance potential of our machines.

To set your GPU voltage offset to -400 mV, edit lenovo_fix.conf which is located at /etc/lenovo_fix.conf on Arch Linux if you installed throttled from the throttled package.

Adam Gradzki's Personal Website

Adding DeepFilterNet Noise Reduction to Easy Effects on Arch Linux

Introduction

Understanding the Components

Prerequisites

The Installation Process

Step 1: Identify Your System Architecture

Step 2: Download the DeepFilterNet Plugin

Step 3: Install the Plugin to the System LADSPA Directory

Step 4: Verify the Installation

Step 5: Configure Easy Effects

Important Configuration Steps

Configure Easy Effects to Launch on Startup

Configure Applications to Use the Correct Audio Input

Troubleshooting Common Issues

Plugin Not Appearing in Easy Effects

Audio Quality Issues

Performance Issues

Advanced Configuration

Multiple Microphone Setup

Integration with Other Effects

Automation and Scripts

Performance Considerations

Alternative Solutions

Conclusion

Further Reading

Integrating JIRA with Claude Code: A Complete Setup Guide

Introduction

How to Use MCP Tools in Claude

A Natural Conversation Approach

What Are MCP Tools?

The Paradigm Shift: Natural Language Is the Interface

How It Actually Works

Practical Examples: From Questions to Results

What About Those Slash Commands?

The Technical Magic You Don't Need to Understand

Best Practices for Getting the Most Value

When Things Don't Work as Expected

The Broader Implication

Stop Typing Commands, Start Having Conversations

Prerequisites

Step-by-Step Setup

Step 1: Pull the MCP Atlassian Docker Image

Step 2: Download the Configuration Template

Step 3: Configure Your JIRA Credentials

Step 4: Add the MCP Server to Claude Code

Step 5: Restart Claude Code

Step 6: Verify the Connection

Step 7: Test the Integration

Common Use Cases

Troubleshooting

Connection Issues

Configuration Not Loading

Docker Pull Failures

Best Practices

Jira & Confluence Tools Overview

Core Operations

Comments & Labels

Jira-Specific: Agile & Sprint Management

Jira-Specific: Workflow & Tracking

Additional Features

Additional Resources

Lightweight Development Sandboxes with systemd-nspawn on Linux

Why systemd-nspawn for Development Containers?

What Makes systemd-nspawn Different?

Prerequisites

Step-by-Step Setup Guide

Step 1: Create Container Directory Structure

Step 2: Install Base System with pacstrap

Step 3: Set Root Password

Step 4: Enable SSH and Networking in Container

Step 5: Configure Static Network on Host

Step 6: Start Container with machinectl

Step 7: Configure Container Static Network

Step 8: SSH into Your Container

Container Management Commands

Advanced Tips and Troubleshooting

Resource Limits

How it works:

Persistent Storage