DEV Community: özkan pakdil

Accelerating LLMs on Debian 13: Setting up CUDA for llama.cpp

özkan pakdil — Thu, 19 Mar 2026 22:35:00 +0000

Setting up NVIDIA CUDA on Debian 13 (Trixie/Sid) to run Large Language Models (LLMs) can be a bit of a journey, especially if you’re transitioning from the default open-source drivers to the proprietary stack required for GPGPU workloads.

Over the last few days, I’ve been working on getting llama.cpp to run with CUDA on my laptop to see how much of a difference it makes compared to pure CPU execution.

Initially, I tested a 35B model on macOS , where it was responding in about 17 seconds. When I moved that same 35B model to my old laptop running Debian 13 (on CPU), the response time plummeted to 4 minutes and 30 seconds. This massive gap was my main motivation to try and enable CUDA on the laptop’s GPU.

The Problem: Nouveau vs. Proprietary Drivers

By default, Debian might use the open-source nouveau driver. While great for basic display tasks, it doesn’t support CUDA. To run llama-server with GPU acceleration, you need the official NVIDIA drivers and the CUDA toolkit.

I followed the NVIDIA Tesla Driver Installation Guide for Debian, which is a critical resource for getting the right packages.

One specific hurdle with Secure Boot enabled was the need to trust the DKMS-generated keys:

sudo mokutil --import /var/lib/dkms/mok.pub

After a reboot and enrolling the key in the MOK manager, the driver was finally active and recognized by the system.

Compiling llama.cpp with CUDA Support

Once the drivers and nvcc were ready, I recompiled llama.cpp with CUDA enabled (see the official CUDA build documentation for more details).

The compilation process is quite resource-intensive and took about 15 minutes on my laptop:

export CUDACXX=/usr/local/cuda/bin/nvcc
export CUDA_HOME=/usr/local/cuda
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release

The VRAM Reality Check (OOM Errors)

My laptop has an NVIDIA GeForce MX450 with 2 GB of VRAM. This is quite modest for modern LLMs.

Initially, I tried running that 35B model that was so slow on the CPU:

llama-server -hf unsloth/Qwen3.5-35B-A3B-GGUF --jinja -c 16384 --host 127.0.0.1 --port 8033

It failed with a cudaMalloc failed: out of memory error. Looking at the logs:

Model parameters: ~857 MiB
Context/CLIP buffers: ~899 MiB
Total requested: > 1.7 GB

With the OS and display driver already taking up some of that 2 GB, there just wasn’t enough room. The 35B model was simply too large for this specific hardware’s VRAM. Even though CUDA would have been faster than the CPU-only 4.5 minutes, the hardware limit forced me to pivot.

The Result: 2B Model Benchmark

I switched to a smaller 2B model to stay within the VRAM limits. The results were impressive and clearly showed why we go through this trouble.

Asking Qwen 2B to “write me hello world in rust” :

Setup	Time to Complete
CPU Only	1 minute 32 seconds
CUDA (GPU)	24 seconds

That’s nearly a 4x speed improvement on a entry-level mobile GPU!

Summary

While the setup can be “so complicated” (dealing with drivers, Secure Boot, and compilation), the performance gains are undeniable. Even on a low-end GPU like the MX450, offloading the heavy lifting to CUDA makes the local LLM experience much more interactive.

Bonus: NVIDIA GPU Diagnostic Script

To help troubleshoot my setup, I wrote a small script nvidia_check_and_run.sh to verify the driver, kernel modules, and llama.cpp support.

#!/bin/bash

# Configuration
LLAMA_PATH="/nix/store/wr7vi3957cx751la7q490h9v2m6q71fm-llama-cpp-8255/bin"
LLAMA_SERVER="$LLAMA_PATH/llama-server"
LLAMA_BENCH="$LLAMA_PATH/llama-bench"
LLAMA_CLI="$LLAMA_PATH/llama-cli"

echo "--- NVIDIA GPU Diagnostic ---"

# 1. Check for the NVIDIA device via PCI
echo "[1/4] Checking PCI devices for NVIDIA GPU..."
if lspci | grep -i nvidia; then
    echo " - NVIDIA hardware detected via lspci."
else
    echo " - No NVIDIA hardware found on PCI bus."
fi

# 2. Check for the driver status
echo -e "\n[2/4] Checking NVIDIA driver status..."
if command -v nvidia-smi &> /dev/null; then
    echo " - nvidia-smi found. Running..."
    if ! nvidia-smi; then
        echo " - CRITICAL: nvidia-smi failed. Kernel modules might not be loaded."
        echo " - ACTION: Try running 'sudo modprobe nvidia' and then 'nvidia-smi' again."
    fi
else
    echo " - nvidia-smi NOT found. Driver might not be installed or active."
fi

# 3. Check for the kernel modules
echo -e "\n[3/4] Checking for loaded NVIDIA kernel modules..."
if /sbin/lsmod | grep -i nvidia &> /dev/null; then
    echo " - NVIDIA kernel modules are loaded."
    /sbin/lsmod | grep -i nvidia
else
    echo " - CRITICAL: No NVIDIA kernel modules loaded."
    echo " - ACTION: Run 'sudo modprobe nvidia' to load the driver."
fi

# 4. Check for llama.cpp device support
echo -e "\n[4/4] Checking llama.cpp device support..."
if [-f "$LLAMA_CLI"]; then
    echo " - Checking llama-cli with -ngl flag..."
    "$LLAMA_CLI" -ngl 1 --version
else
    echo " - llama-cli not found at $LLAMA_CLI"
fi

Running this script gave me a clear picture of what was missing:

--- NVIDIA GPU Diagnostic ---
[1/4] Checking PCI devices for NVIDIA GPU...
0000:01:00.0 3D controller: NVIDIA Corporation TU117M [GeForce MX450] (rev a1)
  - NVIDIA hardware detected via lspci.

[2/4] Checking NVIDIA driver status...
  - nvidia-smi found. Running...
Fri Mar 20 01:55:51 2026       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 595.45.04 Driver Version: 595.45.04 CUDA Version: 13.2 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce MX450 On | 00000000:01:00.0 Off | N/A |
| N/A 53C P8 N/A / 5001W | 5MiB / 2048MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

[3/4] Checking for loaded NVIDIA kernel modules...
  - NVIDIA kernel modules are loaded.
...
[4/4] Checking llama.cpp device support...
  - Checking llama-cli with -ngl flag...
warning: no usable GPU found, --gpu-layers option will be ignored
warning: one possible reason is that llama.cpp was compiled without GPU support
...

If you are on Debian 13 and want to try this, make sure you check your VRAM limits before picking a model, and don’t forget that mokutil step if you have Secure Boot enabled!

Tuning Podman on macOS to Match OrbStack Performance

özkan pakdil — Sun, 08 Mar 2026 19:02:00 +0000

Note: These are suggested optimizations I have not personally tried yet. I’m blogging them as I’m planning to test them throughout this week.

OrbStack is highly optimized for macOS, using a proprietary, high-performance networking stack and a custom VirtioFS implementation with aggressive caching. Podman, while being open-source and standard-compliant, can be tuned to significantly bridge the performance gap.

The following plan outlines key areas where Podman’s performance can be improved on macOS:

1. Enable Rosetta 2 for x86_64 Emulation (Apple Silicon only)

If you are on an Apple Silicon (M1/M2/M3/M4) Mac, running x86_64 containers is often much slower than ARM64. Podman supports Apple’s native Rosetta 2 for Linux, which is substantially faster than QEMU-based emulation.

Check if Rosetta is enabled: Run podman machine inspect and look for "Rosetta": true.
Enable Rosetta: When creating a new machine, use the --rosetta flag (if your Podman version and macOS version support it, typically macOS 13+):

podman machine init --rosetta

Note: If you have an existing machine, you may need to recreate it to enable Rosetta.

2. Optimize Volume Mounting (VirtioFS)

Podman uses virtiofs by default on macOS, which is the fastest way to share files between the host and the VM using Apple’s Virtualization.framework. However, file system I/O can still be a bottleneck.

Avoid Deeply Nested Mounts: Minimize the number of files synced by mounting only the necessary sub-directories instead of the entire home directory.
Use Named Volumes: For high-I/O workloads (like database storage or node_modules), use named volumes instead of bind mounts. Named volumes reside within the VM’s disk image and operate at near-native speeds.

podman volume create my-data
podman run -v my-data:/app/data ...

3. Tuning Resource Allocation

Ensure the Podman machine has sufficient resources. The default settings might be conservative for demanding workloads.

Increase CPUs and Memory: Adjust the machine’s resources to match your workload.

podman machine set --cpus 4 --memory 8192

(Requires the machine to be stopped: podman machine stop)

4. Networking Performance (gvproxy)

Podman uses gvproxy for user-mode networking. This is often the primary reason OrbStack feels faster for network-heavy tasks, as OrbStack uses a more direct networking approach.

Reduce Network Hops: If possible, avoid complex port mappings or heavy network traffic through the user-mode proxy.
MTU Tuning: In some environments, increasing the MTU within the container can improve throughput, though this is dependent on the host’s network configuration.

5. Experiment with the `libkrun` Provider

Podman on macOS supports multiple virtualization backends. While applehv (default) is stable, libkrun (based on krun) can sometimes offer better performance for specific workloads, especially those involving GPU acceleration or specialized Virtio devices.

Try libkrun: You can initialize a machine with the libkrun provider:

podman machine init --provider libkrun

6. Summary of Recommended Configuration for Speed

To get the best performance today, use the following initialization command (on Apple Silicon):

# Stop and remove existing machine if necessary
podman machine stop
podman machine rm

# Initialize with optimized settings
podman machine init \
  --cpus 4 \
  --memory 8192 \
  --disk-size 50 \
  --rosetta \
  --rootful=false

By applying these optimizations, Podman’s performance on macOS will be significantly closer to OrbStack, especially for CPU-intensive emulation and file-system heavy development workflows.

Happy containerizing!

Atlassian MCP

özkan pakdil — Sun, 08 Feb 2026 00:00:00 +0000

I have been using Atlassian MCP with internal Confluence and Jira, and it has been wonderful.

Finding internal information is often challenging and time-consuming. To be honest, searching through Jira or Confluence and locating the right information can be really difficult.

Create Jira and Confluence API tokens from your internal site profile page. For example: https://internalconfluence.company.com/profile/personal for Confluence and https://jira.company.com/secure/admin/CreateAPIToken!default.jspa for Jira. These URLs may vary depending on your setup.
Create an mcp.json file in the .vscode folder for Visual Studio Code, or place this MCP configuration in the appropriate folder for your IDE of choice:

{
  "mcpServers": {
    "mcp-atlassian": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://jira.company.com",
        "JIRA_USERNAME": "your.email@company.com",
        "JIRA_API_TOKEN": "your_api_token",
        "CONFLUENCE_URL": "https://internalconfluence.company.com/wiki",
        "CONFLUENCE_USERNAME": "your.email@company.com",
        "CONFLUENCE_API_TOKEN": "your_api_token"
      }
    }
  }
}

Remember to run podman-desktop or docker desktop. Because this MCP works as a docker container.

After that, open GitHub Copilot in your IDE and instruct it to use the Atlassian MCP to search Confluence and Jira. This makes finding internal information incredibly easy—it goes through pages systematically and retrieves all the details you need.

Building a Real-time File I/O Heatmap with eBPF and Java 25

özkan pakdil — Wed, 21 Jan 2026 05:52:00 +0000

Have you ever wondered exactly which files are being hammered by your Linux system in real-time? While tools like iotop or lsof are great, sometimes you want something more visual, custom, and lightweight.

In this post, I’ll walk you through how I built a Real-time File I/O Heatmap using the power of eBPF for data collection and Java 25 for a modern Terminal UI (TUI).

What is eBPF and Why Use It?

eBPF (Extended Berkeley Packet Filter) is a revolutionary technology that allows you to run sandboxed programs in the Linux kernel without changing kernel source code or loading kernel modules.

Think of it as JavaScript for the Kernel. It allows you to:

Observe : Attach to almost any function in the kernel (kprobes) or userspace (uprobes).
Filter : Process data efficiently at the source, inside the kernel.
Perform : It’s extremely fast because it avoids expensive context switches between kernel and userspace for every event.

For this project, we use eBPF to hook into vfs_read and vfs_write, the gatekeepers of all filesystem activity in Linux.

If you want to dive deeper into eBPF, I highly recommend reading Learning eBPF by Liz Rice, it’s an excellent resource.

The Architecture

Our project consists of three main layers:

The eBPF Program (C): Sits in the kernel, intercepts VFS calls, and aggregates stats (reads, writes, bytes) into a BPF Hash Map.
The Java Backend (Java 25 + JNA): Uses libbpf via Java Native Access (JNA) to load the BPF program into the kernel and poll the maps.
The TUI (Lanterna): A Terminal User Interface that renders the data as a color-coded heatmap.

1. The Kernel Side: eBPF in C

We use BPF CO-RE (Compile Once – Run Everywhere) to ensure our program works across different kernel versions without recompilation.

SEC("kprobe/vfs_read")
int BPF_KPROBE(vfs_read, struct file *file, char *buf, size_t count) {
    // Extract filename from the file struct
    // Filter out non-file noise (sockets/pipes)
    // Update the BPF map with bytes read
    return 0;
}

The magic happens in file_heatmap.bpf.c, where we traverse the kernel’s dentry structures to reconstruct partial file paths so we can actually see what is being accessed.

2. The Bridge: JNA and libbpf

Interfacing Java with the kernel might sound scary, but libbpf makes it manageable. We defined a JNA interface to map the C functions:

public interface LibBpf extends Library {
    Pointer bpf_object__open(String path);
    int bpf_object__load(Pointer obj);
    int bpf_map_lookup_elem(int fd, Pointer key, Pointer value);
    // ...
}

This allows our Java app to behave like a first-class Linux observability tool.

3. The Frontend: A Terminal Heatmap

Using the Lanterna library, we created a TUI that updates every 2 seconds. The heatmap effect is achieved by calculating the “intensity” of I/O for each file and mapping it to a color gradient from white to red.

float intensity = (float) currentVal / maxVal;
int green = (int) (255 * (1 - intensity));
int blue = (int) (255 * (1 - intensity));
tg.setBackgroundColor(new TextColor.RGB(255, green, blue));

Challenges Overcome

Building this wasn’t without its hurdles:

SDKMAN & Sudo : BPF requires root privileges, but sudo often strips the environment variables (like JAVA_HOME) set by SDKMAN. I solved this in the Makefile by using absolute paths and passing environment variables explicitly.
BPF Verifier : The kernel is very strict. Reconstructing file paths required careful use of bpf_probe_read_kernel_str and bpf_snprintf to keep the verifier happy.
vmlinux.h Size : The standard vmlinux.h is over 2MB. I optimized this by using bpftool gen min_core_btf to generate a minified header (~2KB) containing only the types we actually use.
Noise Filtering : Initially, the heatmap was flooded with TCP/UDP socket activity. Adding a filter for S_IFREG (regular files) made the output much cleaner.

How to Run It

You can find the full source code for this project on GitHub: ozkanpakdil/java-examples/ebpf-file-heatmap

If you’re on a Linux machine with clang, bpftool, and maven installed, you can try it out:

git clone https://github.com/ozkanpakdil/java-examples.git
cd java-examples/ebpf-file-heatmap
sudo make run

Once it’s running, you can press 1-5 to sort by different metrics (Reads, Writes, Bytes) and watch your system’s I/O come to life!

Conclusion

Combining eBPF’s low-level performance with Java’s high-level productivity (and the latest features in Java 25!) is a powerful way to build Linux tooling. Whether you’re debugging a database or just curious about what your IDE is doing in the background, this heatmap gives you a unique window into your system.

Happy hacking!

Bun Joins the Microservice Framework Benchmark: Surprisingly Fast JavaScript Runtime

özkan pakdil — Sat, 10 Jan 2026 17:00:00 +0000

Introduction

Today I’m excited to announce the addition of Bun to our microservice framework benchmark suite. The results are nothing short of remarkable . Bun has proven to be one of the fastest runtimes in our entire test suite, competing directly with Rust frameworks!

What is Bun?

Bun is a modern JavaScript runtime built from scratch using Zig and JavaScriptCore (the engine that powers Safari). It’s designed to be a drop-in replacement for Node.js with a focus on:

Speed - Native code execution and optimized I/O
TypeScript support - First-class TypeScript without transpilation
All-in-one toolkit - Runtime, bundler, test runner, and package manager

Implementation Details

Bun Version: 1.3.5

The implementation uses Bun’s native HTTP server API, which is incredibly simple and performant:

const port = 8080;

const server = Bun.serve({
    port: port,
    fetch(req) {
        const url = new URL(req.url);

        if (url.pathname === "/hello") {
            const info = {
                name: "bun",
                releaseYear: new Date().getFullYear()
            };
            return new Response(JSON.stringify(info), {
                headers: { "Content-Type": "application/json" }
            });
        }

        return new Response("Not Found", { status: 404 });
    }
});

console.log(`Bun server started on port ${server.port}`);

The build process is straightforward . Bun can compile TypeScript directly to a standalone executable:

bun build --compile ./main.ts --outfile bun-demo

Benchmark Results: The Numbers Speak

Here are the complete benchmark results for Bun:

---- Global Information --------------------------------------------------------
> request count 32000 (OK=32000 KO=0 )
> min response time 0 (OK=0 KO=- )
> max response time 569 (OK=569 KO=- )
> mean response time 157 (OK=157 KO=- )
> std deviation 115 (OK=115 KO=- )
> response time 50th percentile 148 (OK=148 KO=- )
> response time 75th percentile 208 (OK=208 KO=- )
> response time 95th percentile 403 (OK=402 KO=- )
> response time 99th percentile 483 (OK=483 KO=- )
> mean requests/sec 6400 (OK=6400 KO=- )

Key highlights:

157ms mean response time : faster than Golang (227ms), .NET 9 AOT (255ms), and all JVM frameworks
6,400 requests/sec : matching the throughput of Rust frameworks
0 failed requests : 100% success rate under load (unlike Express.js which had 75% failure rate)
569ms max response time : excellent consistency

Performance Comparison

Let’s put Bun’s performance in perspective with the top performers:

Rank	Technology	Mean Response Time (ms)	Requests/sec
1	Rust (Warp)	144	6,400
2	Rust (Actix)	154	6,400
3	Rust (Axum)	154	6,400
4	Bun	157	6,400
5	Rust (Rocket)	238	5,333
6	Golang	227	5,333
7	.NET 9 AOT	255	5,333
8	.NET 7 AOT	284	5,333
9	.NET 8 AOT	285	5,333
10	GraalVM Micronaut	339	5,333

Bun vs Express.js: A JavaScript Runtime Showdown

The comparison between Bun and Express.js (Node.js) is particularly striking:

Metric	Bun	Express.js (Node.js)
Mean Response Time	157ms	815ms (3,247ms for OK requests)
Requests/sec	6,400	667 (successful only)
Failed Requests	0	24,000 (75% failure rate)
Max Response Time	569ms	10,719ms

Bun is approximately 5x faster than Express.js in mean response time and handles ~10x more successful requests per second. Most importantly, Bun maintained 100% stability under load while Express.js struggled significantly.

Why is Bun So Fast?

Several factors contribute to Bun’s impressive performance:

JavaScriptCore Engine : Safari’s JS engine is highly optimized and often outperforms V8 in certain workloads
Zig Implementation : Low-level systems language with minimal overhead
Native HTTP Server : Built-in server implementation bypasses the overhead of frameworks like Express
Optimized I/O : Uses io_uring on Linux for efficient async I/O operations
No Transpilation Overhead : Native TypeScript execution

Updated Performance Tiers

With Bun’s addition, our performance tiers now look like this:

Performance Tiers:

🥇 TIER 1 (< 200ms): Rust frameworks, Bun
   - Native compilation or highly optimized runtimes
   - Minimal overhead, maximum throughput

🥈 TIER 2 (200-300ms): Golang, .NET AOT, GraalVM Native
   - Excellent performance with broader ecosystem

🥉 TIER 3 (300-600ms): GraalVM Java frameworks
   - Native compilation benefits for JVM

🏅 TIER 4 (> 600ms): JVM frameworks, Node.js/Express.js
   - Full-featured but with more overhead

Conclusion

Bun’s benchmark results are genuinely surprising. A JavaScript/TypeScript runtime competing with Rust frameworks was not something I expected to see. Here are the key takeaways:

Bun is production-ready for high-performance workloads : The 157ms mean response time and 0% failure rate prove it can handle serious traffic.
JavaScript doesn’t have to be slow : Bun demonstrates that with the right architecture, JavaScript can achieve near-native performance.
Consider Bun for new projects : If you’re starting a new microservice and your team knows JavaScript/TypeScript, Bun offers an excellent balance of developer experience and performance.
The gap between Bun and Node.js is massive : If you’re currently using Express.js and need better performance, Bun is worth serious consideration.

For the complete benchmark results including all frameworks, GraalVM native builds, and detailed statistics, check out the full benchmark report.

Source code for tests 👈 Rust examples 👈

Eclipse Collections vs JDK Collections: A Performance Deep Dive

özkan pakdil — Mon, 29 Dec 2025 00:00:00 +0000

The Spark

The other day I came across a fascinating post on Substack by Skilled Coder about Java data structure performance. The post showed some eye-opening numbers for 10M operations:

Get operations:

HashMap.get() → ~140 ms
TreeMap.get() → ~420 ms
ArrayList.get(i) → ~40 ms
LinkedList.get(i) → ~2.5 s

Insertion (10M elements):

ArrayList.add() → ~180 ms
HashMap.put() → ~300 ms
LinkedList.add() → ~900 ms

This got me thinking: how do these numbers compare to Eclipse Collections? And more importantly, how can we calculate these numbers ourselves using open source tools?

Why Eclipse Collections?

Eclipse Collections (EC) has an interesting history. It started around 2004 (probably for Java 1.4) because of buggy and slow implementations in the JDK at the time. Goldman Sachs originally developed it as GS Collections before donating it to the Eclipse Foundation.

Today, EC provides drop-in replacements for JDK collections with additional functionality and, as we’ll see, slightly better performance.

The Benchmark Setup

I used JMH (Java Microbenchmark Harness) to run proper benchmarks. You can see the full results on my Java Benchmarks page.

Quick Comparison

Get (avg per operation):

Operation	Time
`ArrayList.get()`	~0.833 ns
`HashMap.get()`	~4.324 ns
`TreeMap.get()`	~272.823 ns
`LinkedList.get()`	~6,036,876.394 ns

Insertion (avg per operation):

Operation	Time
`ArrayList.add()`	~133.370 ns
`HashMap.put()`	~378.101 ns
`TreeMap.put()`	~432.432 ns
`LinkedList.add()`	~408.091 ns

Detailed Comparison: JDK vs Eclipse Collections

Structure	Type	Insertion (ns/op)	Get (ns/op)
ArrayList	JDK	~133.370 ns	~0.833 ns
MutableList (FastList)	EC	~129.426 ns	~0.831 ns
HashMap	JDK	~378.101 ns	~4.324 ns
MutableMap (UnifiedMap)	EC	~371.230 ns	~3.796 ns
TreeMap	JDK	~432.432 ns	~272.823 ns
TreeSortedMap	EC	~480.139 ns	~271.022 ns
LinkedList	JDK	~408.091 ns	~6,036,876.394 ns

Key Takeaways

1. Eclipse Collections is slightly faster overall

For the most commonly used collections (List and Map), EC shows consistent improvements:

FastList beats ArrayList by ~3% on insertion and is essentially equal on get
UnifiedMap beats HashMap by ~2% on insertion and ~12% on get

2. TreeMap vs TreeSortedMap is a wash

TreeSortedMap is slightly slower on insertion (~11%) but marginally faster on get. If you need sorted maps, either choice works well.

3. LinkedList is still terrible for random access

Look at that LinkedList.get() number: ~6 million nanoseconds per operation! This is because LinkedList has O(n) complexity for random access — it must traverse the list from the beginning (or end) to find each element.

As Skilled Coder wisely noted: “Once you know this, you stop misusing LinkedList forever.”

Why These Performance Differences?

Understanding the “why” helps you make better choices:

ArrayList/FastList = contiguous memory, cache-friendly. The CPU can prefetch data efficiently.
HashMap/UnifiedMap = hashing + pointer chasing. UnifiedMap uses a more compact memory layout.
TreeMap/TreeSortedMap = O(log n) + rebalancing. Red-black tree operations.
LinkedList = worst cache locality + pointer traversal. Every access is a cache miss.

When to Use Eclipse Collections

Consider EC when:

You’re doing heavy collection operations and every nanosecond counts
You want additional APIs like select(), reject(), collect(), groupBy()
You need primitive collections (avoiding boxing overhead)
You want immutable collections with a rich API

Running Your Own Benchmarks

Want to reproduce these results? Check out the JMH documentation and my benchmark code at java-benchmarks.

Wrap-up

This was a fun research project! The numbers confirm what the Eclipse Collections team has been saying for years: their implementations are well-optimized and can provide meaningful performance improvements over JDK collections.

For most applications, the difference won’t be noticeable. But if you’re building high-performance systems or processing large datasets, EC is worth considering.

I shared these findings on my Substack — feel free to check it out and share your own benchmark experiences!

References

From PKIX errors to a clean mTLS + Feign + IAM demo

özkan pakdil — Fri, 05 Dec 2025 18:50:00 +0000

Why this post

I started this mini‑project after seeing a common roadblock: PKIX path building failed when calling HTTPS services with OpenFeign. The goal was to create a tiny, runnable example that eliminates guesswork, shows how to configure client certificates and trust properly, and layers basic IAM policies on top.

Reference: https://stackoverflow.com/questions/79835509/unable-to-configure-ssl-context-for-open-feign-client-getting-pkix-error

What’s inside the example

Two Spring Boot apps:
- Server: HTTPS on 8443, requires client certs (mTLS), and recognizes/authorizes callers with Spring Security’s X.509 support.
- Client: Spring Cloud OpenFeign calling the server via Apache HttpClient5 with a custom SSLContext.
A one‑command cert toolchain (local CA → server/client certs → PKCS#12 keystores/truststores).
An automated test script that runs a positive call (expected 200) and a negative call with an unauthorized client (expected 403).

Project (ready to publish here):

github.com/ozkanpakdil/spring-examples/mtls-feignclient-client-server-iam

Why this avoids PKIX

The Feign client explicitly uses a truststore that contains the CA that signed the server certificate.
The client presents its own certificate (keystore) during TLS handshake for mutual auth.
No reliance on default JDK trust settings; the SSLContext is built explicitly and injected into Feign’s HttpClient5.

How to run (quick)

# 1) Generate demo certs
cd certs && chmod +x gen-certs.sh && ./gen-certs.sh

# 2) Start server (terminal A)
cd server && mvn spring-boot:run

# 3) Start client (terminal B)
cd client && mvn spring-boot:run
# Look for: "Received from server: Hello from secure server!"

Or run the end‑to‑end script (boots server, runs client, then negative test with an unauthorized cert → 403 as expected):

chmod +x client/scripts/test-mtls.sh
client/scripts/test-mtls.sh --tail 200

IAM in one paragraph

mTLS answers “who is calling?” at the transport layer using X.509 certificates from a trusted CA. Many systems also need app‑level IAM: mapping that certificate to an application principal and enforcing authorization policies. Here, Spring Security X.509 maps the Subject CN (e.g., demo-client) to a user and requires role CLIENT for /api/hello. Our negative test shows a different CN gets a clean 403 — proving authorization on top of TLS validation.

Key files (direct links)

Top‑level overview (README)
- https://github.com/ozkanpakdil/spring-examples/tree/main/mtls-feignclient-client-server-iam/README.md
Certificate toolchain
- https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/certs/gen-certs.sh
Client (Feign over mTLS)
- SSLContext wiring: https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/client/src/main/java/dev/demo/client/config/SslFeignConfig.java
- Properties: https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/client/src/main/resources/application.yml
Server (mTLS + X.509 security)
- HTTPS/mTLS config: https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/server/src/main/resources/application.yml
- Security (X.509 mapping + authorization): https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/server/src/main/java/dev/demo/server/SecurityConfig.java
- Clean certificate access in controllers:
- Annotation: https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/server/src/main/java/dev/demo/server/security/ClientCert.java
- Resolver: https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/server/src/main/java/dev/demo/server/security/ClientCertArgumentResolver.java
- MVC config: https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/server/src/main/java/dev/demo/server/WebConfig.java
- Example endpoint: https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/server/src/main/java/dev/demo/server/HelloController.java
Automated E2E script (positive + negative):
- https://github.com/ozkanpakdil/spring-examples/blob/main/mtls-feignclient-client-server-iam/client/scripts/test-mtls.sh

Troubleshooting PKIX fast

PKIX path building failed → Your client truststore must include the CA that signed the server cert.
Hostname verification → Ensure SANs cover the hostname you call (e.g., localhost).
Is Feign using your SSLContext? → Provide a Feign Client bean backed by HttpClient5 configured with your keystore and truststore.

Wrap‑up

If you’re battling PKIX with OpenFeign, start from this working baseline. It shows the complete chain — certs → TLS → Feign SSL → X.509 auth → endpoint authorization — plus a negative test to validate policy. The code is intentionally small, and the repository README goes deeper if you need more detail.

Adding Golang and Express.js to the Microservice Framework Benchmark Suite

özkan pakdil — Wed, 03 Dec 2025 21:49:00 +0000

Introduction

Test results for this benchmark run →

Over the last two days, I’ve expanded our microservice framework benchmark suite to include two new contenders: Golang and Express.js. This addition allows us to compare performance across a broader spectrum of technologies, from compiled languages like Rust and Go to JVM-based frameworks and Node.js.

New Additions

Golang (Go 1.24.10)

Go was added using the standard library only - no external frameworks. The implementation uses net/http package which is known for its excellent performance and simplicity.

Implementation Details:

Go Version: 1.24.10
HTTP Server: Standard library net/http
No external dependencies - pure Go implementation
Binary size: ~7.6 MB

package main

import (
    "encoding/json"
    "log"
    "net/http"
    "time"
)

type ApplicationInfo struct {
    Name string `json:"name"`
    ReleaseYear int `json:"releaseYear"`
}

func helloHandler(w http.ResponseWriter, r *http.Request) {
    info := ApplicationInfo{
        Name: "golang",
        ReleaseYear: time.Now().Year(),
    }
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(info)
}

func main() {
    http.HandleFunc("/hello", helloHandler)
    log.Println("Golang server started on port 8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Express.js (Node.js v20.19.6)

Express.js was added using Node.js 20 with the Single Executable Application (SEA) feature, which allows bundling the application into a standalone executable.

Implementation Details:

Express.js Version: 4.21.0
Node.js Version: v20.19.6
Bundler: esbuild 0.24.0
Packaging: Node.js SEA (Single Executable Application) using postject 1.0.0-alpha.6
Binary size: Self-contained executable

const express = require('express');
const app = express();
const port = 8080;

app.get('/hello', (req, res) => {
    const info = {
        name: 'expressjs',
        releaseYear: new Date().getFullYear()
    };
    res.json(info);
});

app.listen(port, () => {
    console.log(`Express.js server started on port ${port}`);
});

Benchmark Results Overview

The results align with expectations based on each technology’s characteristics:

Performance Ranking (by mean response time, lower is better):

Rank	Technology	Mean Response Time (ms)	Requests/sec
1	Rust (Warp)	135	6,400
2	Rust (Axum)	141	6,400
3	Rust (Actix)	171	6,400
4	Rust (Rocket)	191	5,333
5	Golang	212	5,333
6	.NET 8 AOT	261	5,333
7	.NET 9 AOT	285	5,333
8	.NET 7 AOT	353	5,333
9	Java Robaho	474	4,571
10	Express.js *	789	2,667
11	Micronaut	823	3,556
12	Avaje Jex	854	2,133
13	Ktor	920	1,684
14	Vertx	1,019	4,000
15	Quarkus	1,133	3,200
16	Spring Boot Web	1,238	2,909
17	Spring WebFlux	1,279	2,462
18	Kumuluz	1,384	2,667

Key Observations

Golang Performance

Golang delivered excellent results with a 212ms mean response time and 5,333 requests/sec , placing it:

Just behind the Rust frameworks
Ahead of all .NET versions
Significantly faster than all JVM-based frameworks

This performance comes from Go’s efficient runtime, goroutine-based concurrency model, and the highly optimized standard library HTTP server. The fact that we achieved these results with zero external dependencies is impressive.

Express.js Performance and Stability Issues

Express.js showed 789ms overall mean response time , but this number is misleading due to severe stability issues under load.

Critical concern: Express.js had a 75% failure rate - out of 32,000 total requests, 24,000 failed (KO) and only 8,000 succeeded (OK). For successful requests only, the mean response time was actually 3,137ms. This is dramatically worse than all other frameworks in our test suite, which typically show 0 KO (failed) requests. The successful request rate was only 667 requests/sec compared to Golang’s 5,333 requests/sec.

The errors could be attributed to:

Single-threaded nature of Node.js - Under heavy concurrent load, the event loop can become saturated
Connection handling limits - Default configuration may not be optimized for high concurrency
SEA packaging - The experimental Single Executable Application feature might have some performance implications
Memory pressure - Node.js garbage collection under load

Technology Stack Comparison

Performance Tiers:

🥇 TIER 1 (< 250ms): Rust frameworks, Golang
   - Native compilation, minimal runtime overhead

🥈 TIER 2 (250-500ms): .NET AOT, Java Native (Robaho)
   - AOT compilation benefits, optimized runtimes

🥉 TIER 3 (500-1200ms): Micronaut, Ktor, Avaje, Vertx, Express.js, Quarkus
   - JVM frameworks with varying optimizations
   - Node.js with event-driven I/O

🏅 TIER 4 (> 1200ms): Spring Boot, Kumuluz
   - Full-featured frameworks with more overhead

Build and Packaging Details

Golang Build

CGO_ENABLED=0 go build -o golang-demo .

Simple, fast compilation producing a statically linked binary.

Express.js Build (Node.js SEA)

npm install
npx esbuild main.js --bundle --platform=node --outfile=bundle.js
node --experimental-sea-config sea-config.json
cp $(command -v node) expressjs-demo
chmod 755 expressjs-demo
npx postject expressjs-demo NODE_SEA_BLOB sea-prep.blob \
    --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2

Multi-step process to create a self-contained executable from Node.js application.

Conclusion

The addition of Golang and Express.js to our benchmark suite provides valuable insights:

Golang proves to be an excellent choice for high-performance microservices, offering near-Rust performance with a gentler learning curve and excellent developer experience.
Express.js delivers acceptable performance for many use cases but shows stability concerns under heavy load. For high-throughput scenarios, consider alternatives like Fastify or native solutions.
The performance hierarchy is now clearer:

Source code for tests 👈 Rust examples 👈

How to solve macos hdmi sound control problem

özkan pakdil — Fri, 21 Nov 2025 00:00:00 +0000

So I got my Mac Mini M4 from Amazon for £500 and started using it. I had so many problems with the shortcuts I normally use even Ctrl+A wasn’t working, I had to use Win+A, and many other shortcuts were different. One of the biggest problems was using the sound keys on the keyboard. On Linux they worked fine: sound up and down controlled the output volume. But on macOS it didn’t work. Very strange policy Apple has macOS doesn’t allow the user to control end devices connected through HDMI.

The solution is proxy-audio-device, installed via brew. Now the system output sound is controlled over HDMI. This proxy audio device shows itself as a sound output option, and we can control it. The sound configuration looks like this:

As seen in the picture, proxy audio device is selected and you can easily change the sound, and it is open source and working nice, I am feeling happy.

References:

MacOS on debian QEMU KVM

özkan pakdil — Thu, 13 Nov 2025 00:00:00 +0000

From Frustration to Breakthrough: Running macOS on KVM

For years, I chased the dream of running macOS in a virtual machine.

On Windows, I tried VMware and VirtualBox countless times with different tutorials and blogs. Each attempt ended in frustration: crashes, unsupported hardware, endless configuration rabbit holes. It felt like a goal always just out of reach. And finally I found https://github.com/kholia/OSX-KVM it has the readme which explains the steps for setting up.

First couple of attempts failed as usual.

The Breakthrough

After many failed experiments, paired with Github Copilot to help refine the setup. This time, things clicked.

The key changes were subtle but powerful:

Adjusting CPU flags and thread allocation for better compatibility
Increasing RAM and core counts to give macOS breathing room
Adding a no‑reboot option and restructuring QEMU arguments for stability

You can see the details here for the these tweaks.

The Moment of Success

After days of trial and error, I woke up one morning, applied the final tweaks, and it worked. macOS booted smoothly inside my QEMU VM. A moment of triumph after years of effort.

Here’s the screenshot I shared on the Fediverse:

Reflections

Running macOS on KVM isn’t just about virtualization.

For me, it’s proof that with patience, experimentation, and the right guidance, even long‑standing technical goals can be achieved.

Thanks to Debian for the rock‑solid foundation, and Copilot for being the companion that helped me cross the finish line.

I am still thinking to buy a mac mini though, VM is too slow 😄

Paint, a lightweight image editor for quick edits

özkan pakdil — Wed, 12 Nov 2025 00:00:00 +0000

Why I built Paint

Whenever I wanted to make a very small edit on my Debian laptop, crop a screenshot, add a quick arrow, or block out a small area, the system only had GIMP for editing images. Powerful, but heavy and slow for tiny, frequent tasks. I wanted something nimble: quick to open, easy to use, and focused on the common one-off edits people do dozens of times a day.

This project started from that itch and grew into a polished, compact Swing-based application (with GraalVM native builds and platform installers). The goal remains the same: make the small workflows lightning fast.

Short feature summary

Core drawing tools
Editing & image handling
UI & UX
File formats & packaging

Development timeline (high-level commit history)

This timeline is extracted from the project’s git history to tell the story of how Paint evolved.

2025-11-03, initial commit, project foundation and first implementation.
2025-11-04, undo/redo functionality and keyboard shortcuts were added, UI/ribbon alignment improved.
2025-11-05, File→Open added; installer scaffolding and CI release flows introduced (installer dev release commits).
2025-11-05, reachability metadata updates and Linux packaging/icon tweaks for installers.
2025-11-06, FlatLaf integration for modern look & feel; canvas size controls wired into status bar; tests improved.
2025-11-06, OS-specific native-image packaging settings and multi-line app description support for installers.
2025-11-07, reachability metadata and DEB packaging refinements.
2025-11-08, Transparent Highlighter and Drawing Arrows added; crop behavior and image placement refined; open image from CLI arguments.
2025-11-10, CI consolidation: native-image builds and OS packaging unified into a single workflow; Linux/macOS packaging improvements.
2025-11-11, final release staging and small fixes for canvas sizing and GUI status synchronization.

For the exact commit list and messages, see the repository’s git log history.

How it works (implementation notes)

Canvas model: the app uses a persistent BufferedImage as the backing canvas (DrawArea.cache) and a separate transparent highlightLayer for the highlighter tool. This makes highlights non-accumulating and easy to composite.
Drawing: continuous tools (pencil, eraser, highlighter) commit during dragging for a responsive feel; shapes/lines/arrow/bucket commit at mouse release (with an undo snapshot taken appropriately).
Image placement: pasted or opened images are shown as a pending overlay with a dashed border; the user can drag them, press Enter to accept (commits to the backing image), or Esc to cancel (restores any cut area if moving a selection).
Undo/Redo: snapshot-based (base + highlight) with a capped history size to keep memory usage bounded.
Packaging: Maven profiles for native (-Pnative) and installer (-Pinstaller) builds; CI workflows prepare and upload native and installer artifacts automatically.

Try it locally

Requirements: Java (JDK 25+ recommended), Maven 3.6+.

Build and run the JAR:

cd /home/ozkan/projects/paint
mvn -q clean package
java -jar target/paint-1.0.0.jar

Open an image directly from the command line:

java -jar target/paint-1.0.0.jar /path/to/screenshot.png

GraalVM native (optional):

export JAVA_HOME=/path/to/graalvm
export PATH="$JAVA_HOME/bin:$PATH"
gu install native-image # if needed
mvn -Pnative -DskipTests -q clean package
./target/paint

Packaging: there are helper scripts in src/installer/ci/bin/ and a Maven installer profile that uses jpackage to produce platform installers (DEB, DMG, MSI). See the README for details.

Roadmap (next steps)

UX
Features
Distribution
Tests & CI

Notes & credits

This app is intentionally lightweight and focuses on the frequent day-to-day editing tasks where a full image editor is overkill. The project uses FlatLaf for modern theming and includes helper scripts and CI workflows to build native binaries and installers.

Java imperative vs functional in 2025 — revisiting a 2015 microbenchmark

özkan pakdil — Mon, 29 Sep 2025 20:22:00 +0000

Quick numbers (avg; smaller is faster)

I (imperative nested): 3.28 µs
I2 (imperative freq-map): 1.93 µs
F (streams grouping): 127.37 µs
FP (parallel streams grouping): 599.28 µs

Winner: I2 — imperative freq-map

Note: These are sample numbers from the run below on my machine; yours will differ. I/F labels mirror the 2015 post for a simple visual compare.

== 2015-style harness (I:/F: lines) ==

ozkan@ozkan-debian:~/projects/ozkanpakdil.github.io/scripts/compare-2015-25$ ./run.sh
javac 25
I:5372
F:22032373
I:5816
F:186352
F:144816
F:134903
F:107685
I:4919
I:4903
I:4698
I:4147
F:104857

== 2025 benchmark summary (fastest → slowest) ==

javac 25
Java version: 25
CPU cores: 8
Size=12, warmup=5, iters=10

imperativeNested:
avg  = 3.28 µs
p50  = 1.82 µs
p90  = 3.62 µs
p99  = 14.36 µs
raw  = [1769, 1772, 1787, 1788, 1797, 1818, 1827, 2300, 3622, 14357]

imperativeFreqMap:
avg  = 1.93 µs
p50  = 1.77 µs
p90  = 1.98 µs
p99  = 3.18 µs
raw  = [1715, 1716, 1724, 1727, 1762, 1771, 1845, 1900, 1979, 3182]

streamGrouping:
avg  = 127.37 µs
p50  = 127.73 µs
p90  = 164.10 µs
p99  = 176.66 µs
raw  = [88484, 88562, 96348, 121006, 125770, 127731, 138254, 146769, 164102, 176661]

parallelStreamGrouping:
avg  = 599.28 µs
p50  = 576.47 µs
p90  = 927.77 µs
p99  = 931.11 µs
raw  = [365417, 384289, 411498, 519010, 523009, 576465, 580818, 773447, 927771, 931106]

Summary (fastest → slowest):

imperativeFreqMap — avg=1.93 µs (x1.00)
imperativeNested — avg=3.28 µs (x1.70)
streamGrouping — avg=127.37 µs (x65.92)
parallelStreamGrouping — avg=599.28 µs (x310.17) Winner: imperativeFreqMap

Winner (2025 run): Winner: imperativeFreqMap

Tip: You can change SIZE/WARMUP/ITERS:

$ ./run.sh 12 5 10

2015-style run numbers (same format)

If you prefer the exact I:/F: lines from the original 2015 post, run this tiny harness that prints the same format:

./scripts/legacy-2015-run/run.sh

It compiles a small Test2015.java and prints lines like I:12345 and F:67890 (your real numbers will vary by machine/load).

Minimal code (like 2015)

// Imperative (nested loops, 2015-style)
int sum = 0;
for (int j = 0; j < a.length; j++) {
    for (int k = j + 1; k < a.length; k++) {
        if (a[k] == a[j]) sum += a[k];
    }
}

// Functional-ish with Streams (grouping)
int total = java.util.stream.IntStream.of(a).boxed()
    .collect(java.util.stream.Collectors.groupingBy(i -> i))
    .entrySet().stream()
    .filter(e -> e.getValue().size() > 1)
    .mapToInt(e -> e.getValue().stream().mapToInt(Integer::intValue).sum())
    .sum();

Run it yourself (no Maven/JMH)

./scripts/java25-bench/run.sh 12 5 10

Args are: size warmup iters. Try 12, 1000, 100000 to see where Streams catch up or parallel helps.
Prints a ranked summary (fastest → slowest) with real timings from your machine.

Takeaways

Small data + simple work: tight loops are still fastest and allocate less.
Streams improved since 2015 but have overhead on tiny inputs.
Parallel streams: only useful for big inputs or heavy per-element work.

Side-by-side: 2015 vs 2025

Run one command to see both the original 2015-style I:/F: lines and the 2025 ranked summary together:

./scripts/compare-2015-25/run.sh 12 5 10

Args are still: size warmup iters (for the 2025 part). The 2015 harness always uses the original array of 12 elements.
Output shows two blocks: “2015-style harness” and “2025 benchmark summary”, plus a Winner line.

DEV Community: özkan pakdil

Accelerating LLMs on Debian 13: Setting up CUDA for llama.cpp

The Problem: Nouveau vs. Proprietary Drivers

Compiling llama.cpp with CUDA Support

The VRAM Reality Check (OOM Errors)

The Result: 2B Model Benchmark

Summary

Bonus: NVIDIA GPU Diagnostic Script

Tuning Podman on macOS to Match OrbStack Performance

1. Enable Rosetta 2 for x86_64 Emulation (Apple Silicon only)

2. Optimize Volume Mounting (VirtioFS)

3. Tuning Resource Allocation

4. Networking Performance (gvproxy)

5. Experiment with the libkrun Provider

6. Summary of Recommended Configuration for Speed

Atlassian MCP

Building a Real-time File I/O Heatmap with eBPF and Java 25

What is eBPF and Why Use It?

The Architecture

1. The Kernel Side: eBPF in C

2. The Bridge: JNA and libbpf

3. The Frontend: A Terminal Heatmap

Challenges Overcome

How to Run It

Conclusion

Bun Joins the Microservice Framework Benchmark: Surprisingly Fast JavaScript Runtime

Introduction

What is Bun?

Implementation Details

Benchmark Results: The Numbers Speak

Performance Comparison

Bun vs Express.js: A JavaScript Runtime Showdown

Why is Bun So Fast?

Updated Performance Tiers

Conclusion

Eclipse Collections vs JDK Collections: A Performance Deep Dive

The Spark

Why Eclipse Collections?

The Benchmark Setup

Quick Comparison

Detailed Comparison: JDK vs Eclipse Collections

Key Takeaways

Why These Performance Differences?

When to Use Eclipse Collections

Running Your Own Benchmarks

Wrap-up

References

From PKIX errors to a clean mTLS + Feign + IAM demo

Why this post

What’s inside the example

Why this avoids PKIX

How to run (quick)

IAM in one paragraph

Key files (direct links)

Troubleshooting PKIX fast

Wrap‑up

Adding Golang and Express.js to the Microservice Framework Benchmark Suite

Introduction

New Additions

Golang (Go 1.24.10)

Express.js (Node.js v20.19.6)

Benchmark Results Overview

Performance Ranking (by mean response time, lower is better):

Key Observations

Golang Performance

Express.js Performance and Stability Issues

Technology Stack Comparison

Build and Packaging Details

Golang Build

Express.js Build (Node.js SEA)

Conclusion

How to solve macos hdmi sound control problem

MacOS on debian QEMU KVM

From Frustration to Breakthrough: Running macOS on KVM

The Breakthrough

The Moment of Success

Reflections

Paint, a lightweight image editor for quick edits

Why I built Paint

Short feature summary

5. Experiment with the `libkrun` Provider