<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Wilhelm Maritz</title><link>https://wjmaritz.dev/posts/</link><description>Recent content in Posts on Wilhelm Maritz</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 22 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://wjmaritz.dev/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Running SQLite in production (yes, really)</title><link>https://wjmaritz.dev/posts/sqlite-in-production/</link><pubDate>Wed, 22 Jul 2026 00:00:00 +0000</pubDate><guid>https://wjmaritz.dev/posts/sqlite-in-production/</guid><description>&lt;p>I recently shipped a small Flask app, a scoring platform for a fitness competition, with SQLite as its only database. Not as a stopgap until the real database arrives: the app refuses to start with anything else, because a half-supported second database is worse than none. The conventional advice says this is a mistake. For this class of app, the conventional advice is wrong, but the deployment details will bite you if nobody warns you about them.&lt;/p></description></item><item><title>When RAID1 saved the data but not the state</title><link>https://wjmaritz.dev/posts/zimaboard-raid1-rebuild/</link><pubDate>Mon, 12 Jan 2026 00:00:00 +0000</pubDate><guid>https://wjmaritz.dev/posts/zimaboard-raid1-rebuild/</guid><description>&lt;p>My home server is a ZimaBoard 2 running ZimaOS. The storage that matters is a RAID1 mirror, two 4 TB drives formatted BTRFS, holding a media library, backups, and personal archives, with the Docker application stack running off the same pool. It is a small setup, and for a long time it was a boring one, which is exactly what you want from storage.&lt;/p>
&lt;p>Then a migration went wrong, and it taught me more than a year of everything working ever did.&lt;/p></description></item><item><title>Installing Hugo on WSL</title><link>https://wjmaritz.dev/posts/hugo-on-wsl/</link><pubDate>Wed, 22 Jan 2025 00:00:00 +0000</pubDate><guid>https://wjmaritz.dev/posts/hugo-on-wsl/</guid><description>&lt;p>If you develop on Windows but want a Linux toolchain, Hugo runs happily under WSL. Here is the quick version, plus the one gotcha worth knowing.&lt;/p>
&lt;h2 id="the-quick-way-often-out-of-date">The quick way (often out of date)&lt;/h2>
&lt;p>Update your package list and install from apt:&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-bash" data-lang="bash">&lt;span style="display:flex;">&lt;span>sudo apt update
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>sudo apt install hugo
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>This works, but Ubuntu and Debian package a version of Hugo that usually lags well behind the current release. Themes move quickly, and plenty of them need a newer Hugo than apt will give you. If a theme&amp;rsquo;s build complains about your Hugo version, this is why.&lt;/p></description></item></channel></rss>