Sam Santana

Your homelab server’s disk dies. You clone your repo onto the replacement, and everything that took weeks to get right comes back in seconds: every compose file, every bind mount, every pinned image tag. Then you bring up Immich: error while interpolating services.database.environment.POSTGRES_PASSWORD: required variable DB_PASSWORD is missing a value: err The repo has everything except the one file you deliberately kept out of it. If you keep Docker Compose stacks in git, you’ve probably gitignored your .env files, because they hold passwords and API tokens. You might have committed a .env.sample with blank values so you at least know which variables exist. That keeps secrets off GitHub, but it also leaves them out of the one place everything else is backed up. The sample can tell you that DB_PASSWORD exists. It can’t tell you what it was. So a rebuild turns into resetting database passwords and regenerating API keys, one service at a time. ...

If you’re running more than a couple of containers without version control, you’ve probably lived some version of this: you tweak a docker-compose.yaml, it breaks something, so you copy the old one to docker-compose.yaml.bak before trying again. A few edits later you’ve got docker-compose.yaml.bak2 and docker-compose.yaml.old, no idea which one was actually working, and no record of what changed between them. Putting your compose files in git fixes that. Every edit becomes a commit with a message, git diff shows you exactly what changed, and rolling back a bad config is a simple git checkout command. Pair that with a repository that’s kept separate from your container data, shared environment variables to cut down on duplication, and a small script to run everything, and your containers become a lot easier to manage. ...

If you’re here, you’re probably fighting with a Zephyrus G14 trackpad that just stopped responding, maybe right out of the box, maybe after a random Windows update. I went through the exact same thing on my ASUS 2022 GA402R, the AMD 6000 series configuration with an AMD CPU and a dedicated AMD GPU, and it turns out the fix has nothing to do with the physical trackpad itself, but instead a software issue. ...

Welcome! This series walks through installing Arch Linux from scratch with full-disk encryption, BTRFS subvolumes with automatic snapshots, and a complete KDE Plasma desktop, split into four parts you can follow start to finish or jump into individually. What You’ll Build By the end of this series, you’ll have a fully encrypted Arch Linux desktop: LUKS2 full-disk encryption, BTRFS subvolumes with automatic Snapper snapshots, a properly configured package manager with AUR support, working audio, bluetooth, printing, and graphics, and a KDE Plasma desktop on top of it all. ...

Welcome to Part 4 of the Arch Linux installation guide! In Part 1 and Part 2, we built an encrypted, unbreakable file system and got it fully installed and configured. In Part 3, we built the invisible engines that drive our audio, network, and graphics. Now it’s time to have a GUI! We are going to install KDE Plasma, one of the most modern yet fast desktop environments in the Linux world. With the foundation we previously set, this process is going to be incredibly smooth. ...

This is Part 3 of the Arch Linux Install series. With a bootable, networked system from Part 2, we’ll now expand pacman with multilib and the AUR, and bring up the core hardware services (audio, bluetooth, printing, and graphics), everything the desktop in Part 4 will need. Why PipeWire and yay? PipeWire over PulseAudio: PulseAudio has been the default Linux audio server for over a decade, but it only handles audio. Getting professional audio routing meant running JACK alongside it, often fighting over the same devices. PipeWire replaces both: it speaks PulseAudio’s protocol for regular desktop audio and JACK’s protocol for pro-audio and screen-sharing pipelines, all from one daemon. That’s why we install pipewire-pulse instead of pulseaudio itself. It’s a compatibility layer, not a second audio server. ...

This is Part 2 of the Arch Linux Install series. With the drive partitioned and encrypted in Part 1, we’ll now install the base system, get it booting, configure the essentials, and set up automatic snapshots with Snapper. Why systemd-boot and Snapper? systemd-boot over GRUB: GRUB is the safer default when you need to dual-boot Windows or juggle multiple kernels with automatic OS detection, but this is a single-OS UEFI system, and none of that complexity buys us anything. systemd-boot is a fraction of the size, configures itself from a couple of short text files instead of a generated script, and boots straight from EFI without an intermediate stage. For a dedicated Linux install, it’s less to configure and less to break. ...

This is Part 1 of the Arch Linux Install series. In this post, we’ll partition and encrypt the drive with LUKS2, lay out BTRFS subvolumes, and get everything mounted and ready for the base install in Part 2. Why LUKS2 and BTRFS? Arch’s default install guide doesn’t set up encryption or BTRFS. I’m using both here, and it’s worth explaining why before diving in. Full-disk encryption (LUKS2): If this machine is ever lost or stolen, an unencrypted drive means anyone with physical access can read every file on it just by booting from a USB stick. LUKS2 makes the drive unreadable without the passphrase, even if it’s pulled out and connected to another machine directly. ...

I wanted a place to document my projects, things like Kubernetes clusters, Linux setups, and homelab experiments. Somewhere I could reference my own work and maybe help someone else along the way. I’d built personal sites with WordPress before and knew going in that it would mean ongoing maintenance: plugin updates, core updates, and the occasional breakage that had nothing to do with anything I wrote. For a simple technical blog, that overhead wasn’t worth it. ...