Linux Café

Why GNOME Terminal can freeze on a 4K Wayland display

When you fire up a heavy background job—think dd, fio, or a long‑running rsync—the terminal can suddenly stop answering. On a 4K laptop running Wayland the culprit is usually the compositor trying to keep the terminal’s output fresh while the CPU is busy elsewhere. The rendering loop stalls, and the window looks frozen even though the shell is still alive. The cure is to separate the terminal’s repainting from the job’s I/O, or to give the compositor a lighter load.

The “find + xargs” combo is a classic for cleaning up old logs, but it can be a double‑edged sword if you’re not careful.

Below is a step‑by‑step guide that shows how to target only the log files you want to delete, keep your home folder safe, and understand the trade‑offs of the different options you’ll see.

Why find and xargs instead of rm -r?

find is the Swiss‑army knife of file searching: you can filter by name, age, size, permissions, and more.
xargs takes the list that find spits out and feeds it to another command, usually rm.
The pair is efficient because it processes files in batches, sidestepping the “argument list too long” error that can bite you if you try to delete thousands of files with a single rm.

Why a “Hello‑World” Container Can Become a Disk‑Hog

When you first dip your toes into Podman, the classic “hello‑world” test is the go‑to command. It’s fast, it’s tiny, and it proves the runtime is up and running:

podman run --rm docker.io/library/hello-world

A single run looks harmless, but if you fire it off repeatedly—say, in a cron job, a CI pipeline, or a home‑lab health‑check script—the logs that Podman keeps for each run can pile up. On a busy homelab, that accumulation can eat up several gigabytes in a matter of days, especially if you’re using the default local log driver that writes to a file on disk.

Why a local reverse proxy is useful

Running a handful of services on a home network—Nextcloud, a media server, a personal blog—usually means each one gets its own internal port. If you want to reach them from the outside, you could open every port on your router and forward it to the correct machine. That works, but it exposes those service ports to the internet and forces you to juggle a bunch of NAT rules. A reverse proxy on a single entry point keeps all those ports hidden and gives you a tidy URL scheme.

Turning a Raspberry Pi into a DIY Caddy Reverse Proxy for Home‑Hosted Services

I’ve run a handful of services on a Pi for years—Plex, Nextcloud, Home Assistant—so the idea of putting a single, tidy entry point on top of them is pretty appealing. Caddy is the go‑to for this because it hands you a working HTTPS server, auto‑issues Let’s Encrypt certs, and runs nicely on ARM. Below is a hands‑on walk‑through that keeps all the commands and links intact, but reads like a coffee‑chat with a fellow sysadmin.

I’ve seen this go wrong when the timer unit is enabled in two places or when Persistent=true is left on a daily job. The result is a backup that starts right after boot and then again at the scheduled hour. It’s annoying, but the fix is usually a few quick edits and a reload. Below is a practical walk‑through that keeps the technical detail but feels like a coffee‑chat with a seasoned sysadmin.

Safely Removing Old Log Files with find and xargs

Log files are the lifeblood of debugging, but they’re also the biggest culprits when a disk starts to feel cramped. If you’re running a home server, a small NAS, or just a personal laptop, you’ll often need a quick way to prune logs older than a set age without accidentally wiping something vital. The classic find … | xargs combo is a battle‑tested, script‑friendly solution that works on almost every Linux box.

I’ve been running a small home‑lab with Docker‑Compose for a few years. My first reverse‑proxy was Traefik because its automatic LetsEncrypt integration and simple docker‑compose.yml seemed perfect for a beginner. Over time, the stack grew: I added a GitLab runner, a Nextcloud instance, a self‑hosted mail server, and a few hobby services that required custom TLS settings. The moment I hit that point, the trade‑offs of Traefik became obvious.

Below is a walk‑through of the decision, the migration steps, and the practical differences I noticed. If you’re still on Traefik and wondering whether to switch, this should give you a clear picture.

I’ve been running a small homelab for a few years now. My setup consists of a handful of services—Nextcloud, Home Assistant, a personal blog, and a few static sites—all exposed through a single reverse proxy on a Raspberry Pi 4. For the first two years I used Nginx because it’s ubiquitous, well‑documented, and I could get it working with a simple proxy_pass block. In 2025 I started to notice a few friction points that made me consider alternatives. By the end of 2025 I had migrated to Caddy, and the switch has paid off in terms of maintenance, security, and ease of use.

502 from Nginx? Let’s Fix the HTTPS Path & Cert Issues

A 502 Bad Gateway is the first thing you’ll see when you expose a service behind Nginx in a home‑lab.
It usually means the proxy can’t talk to the backend – often because the SSL certificate is wrong, the upstream URL is mis‑typed, or the upstream host is unreachable.
Below is a step‑by‑step walk‑through that covers the most common pitfalls, shows how to verify each piece, and explains the trade‑offs you’ll face when choosing a solution.