content improve 2

infra/index.njk

@@ -36,3 +36,15 @@ sections:
 <p class="site-intro">A peek under the hood of my homelab. Proxmox, Synology, Docker, and how everything is wired together.</p>
 
 {% include "card-grid.njk" %}
+
+<section class="about-expanded">
+  <h2>The setup at a glance</h2>
+  <p>The infrastructure runs on three main machines: a Proxmox VE host (Intel NUC, 64GB RAM) as the primary compute node, a Synology DS918+ NAS for storage and Docker services, and a Xubuntu VM on Proxmox for development. An OpenWrt router handles multi-WAN failover with WiFi and Powerline backhaul, and four Zyxel GS1200-8HP managed switches distribute the network across the flat.</p>
+  <p>The whole stack is monitored via Prometheus and Grafana, with node exporters on every machine, cAdvisor for container metrics, and SNMP exporters for network hardware. Backups follow a 3-2-1 strategy: local snapshots, NAS copies, offsite sync to a Raspberry Pi in a different room, and cloud archive for worst-case scenarios.</p>
+
+  <h2>Why Proxmox</h2>
+  <p>Proxmox VE was chosen over alternatives like ESXi or plain Docker for several reasons. The open-source model means no licensing headaches. LXC containers provide near-native performance for lightweight services without the overhead of full VMs. The web UI makes it easy to manage snapshots, backups, and migrations. And the ZFS support on the underlying Debian system gives us reliable snapshots and send/receive for the backup chain.</p>
+
+  <h2>How services are organized</h2>
+  <p>The general rule: stateful services (databases, media archives, monitoring data) run on the Synology NAS where they benefit from the integrated backup and snapshot system. Stateless services and compute-heavy workloads run on the Proxmox Docker VM. LXC containers handle lightweight always-on services like Pi-hole and MariaDB. This separation makes it easy to tear down and recreate Docker containers without worrying about data loss.</p>
+</section>

infra/monitoring/index.njk

@@ -9,7 +9,9 @@ layout: base.njk
 <div class="detail-content">
 
 <p>Prometheus and Grafana form the central monitoring stack for the whole
-homelab, running as Docker containers on the NAS.</p>
+homelab, running as Docker containers on the NAS. Every machine in the
+flat — Proxmox host, Docker VM, Synology NAS, and Raspberry Pi devices —
+feeds metrics into this central instance.</p>
 
 <h2>What's monitored</h2>
 <ul>
@@ -27,6 +29,23 @@ homelab, running as Docker containers on the NAS.</p>
 <tr><td>Network printer</td><td>Toner level, page count, online/offline status via SNMP</td></tr>
 </table>
 
+<h2>How it's deployed</h2>
+<p>Prometheus runs as a Docker container on the Synology NAS with a
+bind-mounted data directory for persistence. Grafana is deployed as a
+sibling container, connected to Prometheus as its primary datasource.
+Both containers are defined in a single Docker Compose file and managed
+via Portainer. The Prometheus configuration file defines scrape targets,
+scrape intervals (15 seconds for hosts, 60 seconds for network devices),
+and retention policies.</p>
+
+<h2>Alerting</h2>
+<p>Basic alerting is configured through Prometheus Alertmanager, which
+sends notifications to a dedicated Telegram channel for critical events
+like host-down or disk-full conditions. The dead-man's-switch pattern
+ensures that if Prometheus itself stops scraping, an alert fires within
+minutes. More sophisticated alerting rules (disk space prediction,
+temperature thresholds) are planned but not yet implemented.</p>
+
 <h2>Open items</h2>
 <ul>
 <li>Alerting rules are not yet configured for most services.</li>

retro/amiga-hardware-landscape/index.njk

@@ -8,7 +8,7 @@ parent: "/"
 <h1>Running AmigaOS in 2026: MiSTer FPGA vs Amiberry on Pi</h1>
 <div class="detail-content">
 
-<p>AmigaOS 3.2.3 runs beautifully both on FPGA and on modern ARM boards — the question is which trade-offs you're willing to accept.</p>
+<p>AmigaOS 3.2.3 runs beautifully both on FPGA and on modern ARM boards — the question is which trade-offs you're willing to accept. Both approaches have their place, and the choice often comes down to what you're trying to do: run demos at perfect timing, or tinker with software at higher resolutions.</p>
 
 <h2>Two Roads to the Same Workbench</h2>
 <ul>
@@ -18,5 +18,29 @@ parent: "/"
 <li><strong>Picking a monitor</strong> — a 4:3 panel at native 1280×1024 (like an older NEC MultiSync) gives the most period-accurate Workbench experience; anything widescreen needs scaling compromises.</li>
 </ul>
 
+<h2>When to choose MiSTer</h2>
+<p>The MiSTer shines when timing accuracy matters. Demos that rely on
+cycle-exact raster effects, games that use custom hardware tricks, and
+software that depends on precise interrupt timing all benefit from the
+FPGA's hardware-level reproduction. The Minimig-AGA core also provides
+a more authentic floppy drive experience, including the characteristic
+drive sounds and seek times that software sometimes depends on for
+loading screens and copy protection.</p>
+
+<h2>When to choose Amiberry on Pi</h2>
+<p>The Pi is better for productivity and development work. Higher RTG
+resolutions make Workbench usable on modern monitors. The ability to
+easily swap between AmigaOS versions and hard disk images makes it
+ideal for testing software. And the lower cost means you can dedicate
+a Pi to Amiga development without tying up expensive FPGA hardware.</p>
+
+<h2>The compatibility question</h2>
+<p>Most Amiga software works on both platforms, but there are edge cases.
+Some demos use raster tricks that only work on real AGA hardware or the
+MiSTer's FPGA core. Some productivity software depends on specific
+accelerator card features that neither platform emulates perfectly.
+And the perennial question of Kickstart ROM versions — 3.1 for
+compatibility, 3.2 for features — applies equally to both setups.</p>
+
 <p class="redacted-note">Both setups now run side by side without any real winner — MiSTer for authenticity and demos, the Pi for tinkering and RTG resolutions.</p>
 </div>

retro/atari-networking-bbs/index.njk

@@ -18,5 +18,34 @@ parent: "/"
 <li><strong>File transfer the easy way</strong> — a plain FTP client on the Atari talking to a NAS on the local network sidesteps most of the internet-connectivity headaches entirely, especially for moving disk images and software archives back and forth.</li>
 </ul>
 
+<h2>Why connect a 40-year-old computer to the internet</h2>
+<p>The obvious question is "why bother?" — the Atari ST was never designed
+for the internet, and the experience of using it online is objectively
+worse than any modern device. But that's not the point. The real
+satisfaction comes from making old hardware do things it was never
+designed to do, understanding the networking stack at a level that modern
+abstractions hide, and experiencing the dial-up era's BBS culture on
+original hardware.</p>
+
+<h2>The BBS experience</h2>
+<p>Bulletin board systems from the dial-up era are still running today,
+maintained by enthusiasts who keep the old software alive. Connecting to
+one from an original Atari ST — via a Wi-Fi modem emulation — is a
+genuinely nostalgic experience. The ANSI art login screens, the message
+boards, the file sections, the door games — it's all exactly as it was
+in the early 1990s. The main difference: instead of tying up a phone
+line, the connection goes over Wi-Fi to a BBS that's accessible from
+anywhere in the world.</p>
+
+<h2>Lessons learned</h2>
+<p>The biggest lesson: networking on retro hardware is 90% patience and
+10% actual configuration. The STinG stack is well-documented but
+fragile — wrong TCP/IP settings silently break connections without
+useful error messages. The ESP32 Wi-Fi modules are cheap and flexible
+but require careful firmware selection for the specific use case. And
+terminal emulation is a rabbit hole of character sets, escape sequences,
+and display quirks that haven't been relevant for decades but still
+matter when connecting to a BBS that renders ANSI art.</p>
+
 <p class="redacted-note">If you're chasing BBS nostalgia on real hardware: budget far more patience for the networking layer than for the actual computer. The 1980s hardware is the easy part; convincing 2020s Wi-Fi and modern BBS ANSI dialects to cooperate is the real challenge.</p>
 </div>

retro/dos-486-tower/index.njk

@@ -1,20 +1,33 @@
 ---
-title: "The 486 DX2-66 Tower: An Original PC Living Alongside Its FPGA Twin"
+title: "The 486 DX2-66: Rebuilding a DOS Era on MiSTer FPGA"
 section: "retro"
-description: "Keeping an original Colani-design 486 tower running while a MiSTer core covers the same era digitally."
+description: "Recreating a Vobis-Highscreen 486 DX2-66 setup on MiSTer FPGA, down to the original DOS configuration."
 layout: base.njk
 parent: "/"
 ---
-<h1>The 486 DX2-66 Tower: An Original PC Living Alongside Its FPGA Twin</h1>
+<h1>The 486 DX2-66: Rebuilding a DOS Era on MiSTer FPGA</h1>
 <div class="detail-content">
 
-<p>Long before Atari ST and Amiga took over the retro corner, a Vobis-Highscreen 486 DX2-66 in its distinctive Colani-designed tower case was the main PC. Decades later, it's kept around as both a museum piece and a genuine gaming machine, running alongside a MiSTer FPGA equivalent.</p>
+<p>Long before Atari ST and Amiga took over the retro corner, a Vobis-Highscreen 486 DX2-66 in its distinctive Colani-designed tower case was the main PC. The original hardware is long gone, but the entire setup has been recreated 1:1 on MiSTer FPGA — same DOS version, same drivers, same AUTOEXEC.BAT and CONFIG.SYS, same directory structure.</p>
 
-<h2>Original Hardware vs FPGA Twin</h2>
+<h2>The original hardware</h2>
+<p>The Vobis-Highscreen was a premium PC in its day — the Colani design gave it a distinctive curved case that still looks futuristic. Inside it ran an Intel 486 DX2 at 66MHz with 8MB of RAM, a Sound Blaster 16, and a Tseng ET4000 graphics card. A 200MB hard drive and a 3.5" floppy drive completed the setup. The machine was the go-to system for early-90s classics like Doom, Wing Commander, Duke Nukem 3D, and Lemmings.</p>
+
+<h2>The MiSTer recreation</h2>
+<p>The AO486 core on MiSTer FPGA reproduces the original hardware with near-perfect accuracy. The key was not just getting the hardware emulation right, but rebuilding the exact software environment: the same MS-DOS version, the same memory managers (HIMEM.SYS, EMM386), the same Sound Blaster drivers, and the same AUTOEXEC.BAT and CONFIG.SYS tuning that made the original machine run smoothly. Even the directory structure and file names match the original setup.</p>
+
+<h2>Why a 1:1 recreation</h2>
+<p>The point isn't just to play DOS games — it's to preserve the exact computing experience from that era. The way DOS memory management worked, the way sound drivers had to be configured manually, the way batch files chained together to create a usable environment. This level of detail is lost when you just launch a DOS game from a modern frontend. The MiSTer setup recreates the entire boot process, from BIOS POST to the C:\> prompt, just as it was in the mid-90s.</p>
+
+<h2>What's preserved</h2>
 <ul>
-<li><strong>The original tower</strong> — an Intel 486 DX2 @ 66MHz in its iconic Colani case, the go-to machine for early-90s classics like Doom, Wing Commander, Duke Nukem 3D, and Lemmings.</li>
-<li><strong>MiSTer's AO486 core</strong> — a full FPGA-based 486 emulation, configurable across variants from 386SX all the way to 486DX4, using swappable virtual hard disk (VHD) images instead of a physical drive.</li>
-<li><strong>Open project</strong> — DOS-era BBS access is next on the list, likely tackled via the MiSTer core first since its networking path is simpler than wrangling period-correct ISA network cards.</li>
+<li><strong>DOS boot environment</strong> — the exact AUTOEXEC.BAT and CONFIG.SYS from the original machine, including memory manager configuration and Sound Blaster IRQ settings.</li>
+<li><strong>Game installations</strong> — original game installations with their setup utilities, configuration files, and saved games, all in the same directory paths as the original.</li>
+<li><strong>System utilities</strong> — Norton Commander, PKZIP, the usual toolkit of the era, all configured the way they were used daily.</li>
+<li><strong>The quirks</strong> — the specific workarounds and tweaks that were needed to get everything running together, the kind of institutional knowledge that only exists on a well-used personal machine.</li>
 </ul>
 
+<h2>AO486 vs real hardware</h2>
+<p>The MiSTer AO486 core handles the emulation convincingly. Timing accuracy is good enough for games that rely on cycle-sensitive behavior. Sound Blaster emulation covers the standard OPL3 FM synthesis and digital audio. The main trade-off is that some hardware-specific quirks — like the exact timing of the ET4000 graphics card or the behavior of specific ISA bus peripherals — aren't perfectly replicated. But for the purpose of preserving a working DOS environment, it's more than sufficient.</p>
+
 </div>

retro/index.njk

@@ -45,8 +45,8 @@ sections:
         href: "/mini-arcade-handheld-roundup/"
   - heading: "DOS & PC"
     cards:
-      - title: "💻 The 486 DX2-66 Tower"
-        summary: "An original Colani-design 486 tower kept running alongside its MiSTer AO486 FPGA equivalent."
+      - title: "💻 The 486 DX2-66"
+        summary: "A complete DOS environment rebuilt 1:1 on MiSTer FPGA, down to the original AUTOEXEC.BAT."
         href: "/dos-486-tower/"
   - heading: "Overview"
     cards:
@@ -55,6 +55,6 @@ sections:
         href: "/retro-corner-snapshot/"
 
 ---
-<p class="site-intro">Hardware I've collected and kept running over the years. From Atari ST and Amiga to MiSTer FPGA and DOS towers.</p>
+<p class="site-intro">Hardware I've collected and kept running over the years. From Atari ST and Amiga to MiSTer FPGA and DOS environments.</p>
 
 {% include "card-grid.njk" %}

retro/retro-corner-snapshot/index.njk

@@ -18,5 +18,14 @@ parent: "/"
 <li><strong>The focus, unmistakably</strong> — Amiga and Atari ST are the heart of the collection; everything else (DOS, arcade, handhelds) exists to fill in the gaps around those two platforms.</li>
 </ul>
 
+<h2>The office setup in detail</h2>
+<p>The office houses the main retro computing workstation. The three Mega ST 4 machines each have a defined role: one runs GEM-based productivity software, one is set up for MIDI music production with a connected synthesizer, and one serves as the development machine for ST software. The Mega ST 2 is the backup and testing machine. The MiSTer FPGA handles Amiga and DOS emulation with near-perfect timing accuracy, while the MiST provides a dedicated Atari ST experience without the overhead of the MiSTer's larger feature set.</p>
+
+<h2>The living room setup</h2>
+<p>The Batocera box in the living room takes a completely different approach — it's not about hardware authenticity, it's about convenience. A compact PC boots directly into the Batocera frontend, providing a console-like experience for casual retro gaming on the TV. Controllers are wireless, the interface is controller-friendly, and the focus is on games that work well from a couch rather than demos or productivity software that needs a keyboard and mouse.</p>
+
+<h2>How it all connects</h2>
+<p>All machines share the same network infrastructure, with FTP access to the NAS for file transfers. Disk images and software archives are stored centrally and served to individual machines as needed. The MiSTer and MiST both use SD cards for storage, while the original hardware uses CompactFlash adapters or SCSI-to-IDE bridges depending on the machine. The Raspberry Pi 400 accesses the same NFS shares as the other Pis in the flat.</p>
+
 <p class="redacted-note">The honest status update: several open items remain — documenting the exact handheld models, and waiting on the A1200 Mini pre-order. Retro computing, it turns out, is never really "done."</p>
 </div>

retro/the-a1200/index.njk

@@ -42,7 +42,7 @@ no configuration required, at the cost of some flexibility.</p>
 <p>If the A1200 ships on time and delivers on the promised feature set,
 it could become the default entry point for people curious about the
 Amiga. The original hardware is getting harder to find in good condition,
-and the capacitor-bomb主板 issue means that even working units need
+and the capacitor-bomb motherboard issue means that even working units need
 recapping. A modern, reliable reproduction — even if it's software
 emulation — lowers the barrier significantly. The 25 pre-installed games
 give newcomers a curated starting point, and the USB sideloading support

smarthome/balkonpi/index.njk

@@ -11,7 +11,10 @@ layout: base.njk
 <p>A Raspberry Pi Zero W mounted near the balcony acts as a small,
 self-contained smart-balcony controller: light control, an internet
 radio player, sensor readings, and its own backup/monitoring, all on
-very modest hardware.</p>
+very modest hardware. The goal is to make the balcony a more pleasant
+space — light control when it gets dark, background music while sitting
+outside, and temperature readings to know what to expect before stepping
+out.</p>
 
 <h2>What it does</h2>
 <ul>
@@ -21,6 +24,16 @@ very modest hardware.</p>
 <li><strong>Internet radio</strong> via a lightweight command-line audio player, controlled by a small custom tool ported from an earlier bathroom-Pi project.</li>
 </ul>
 
+<h2>Hardware details</h2>
+<p>The Pi Zero W is connected to an ESP32 microcontroller that handles
+the actual light switching via a relay module. Communication happens
+over HTTP — the Pi sends a simple request to toggle the relay, and the
+ESP32 responds with the current light state. The ESP32 also reads a
+DHT22 temperature and humidity sensor, publishing the values to MQTT
+for the home dashboard. This split makes sense: the Pi handles the
+user-facing logic (audio, buttons, internet radio), while the ESP32
+handles the real-time hardware control.</p>
+
 <h2>Monitoring & backup, even on tiny hardware</h2>
 <p>Despite the very limited RAM, this Pi still participates in the same
 Prometheus monitoring pattern as the rest of the fleet — with the metrics
@@ -33,6 +46,7 @@ configuration to the NAS over the internal network.</p>
 <ul>
 <li>Adding a USB webcam stream, mirroring the pattern already used for the 3D printer.</li>
 <li>Migrating onto the planned isolated IoT network segment once that's fully set up.</li>
+<li>Adding weather data from the DHT22 sensor to the LED matrix displays around the flat.</li>
 </ul>
 
 </div>

smarthome/index.njk

@@ -72,3 +72,15 @@ sections:
 <p class="site-intro">The heart of the homelab. Home Assistant, MQTT sensors, dashboards, and automation projects that make everyday life a little more interesting.</p>
 
 {% include "card-grid.njk" %}
+
+<section class="about-expanded">
+  <h2>The stack</h2>
+  <p>Everything connects through MQTT. HomematicIP thermostats report room temperatures via Home Assistant automations, Tasmota smart plugs feed energy data, and various ESP32 and Raspberry Pi devices publish sensor readings. InfluxDB stores the time-series data, and Grafana dashboards visualize it all in real time.</p>
+  <p>The home dashboard runs on multiple touch displays around the flat: an ESP32-S3 WT32-SC01 in the living room and an M5Stack in the study. Both show room temperatures, energy usage, and quick-action buttons for lighting and music control.</p>
+
+  <h2>Automation philosophy</h2>
+  <p>The goal is subtle automation that improves daily life without being intrusive. Lights turn on when someone enters a room, music starts playing in the bathroom when the light switches on, and LED matrix displays show the time, weather, and laundry status. But nothing talks unless spoken to — no voice assistants, no always-on microphones, just simple sensor-driven automation that runs locally without cloud dependencies.</p>
+
+  <h2>Self-hosted services</h2>
+  <p>Beyond hardware automation, several self-hosted services run on the Synology NAS: TubeArchivist for YouTube archiving, OctoPrint for remote 3D printer control, iCloud Contacts Sync for keeping the address book up to date, and a Google Calendar sync for dashboard widgets. Each service is containerized and backed up as part of the NAS backup strategy.</p>
+</section>

smarthome/octoprint/index.njk

@@ -10,7 +10,9 @@ layout: base.njk
 
 <p>A Raspberry Pi 3B runs OctoPrint for remote 3D-printer control, plus a
 live camera stream so print progress can be checked without walking over
-to the printer.</p>
+to the printer. This eliminates the need to stand next to the printer
+watching the first layer — a quality-of-life improvement that's hard to
+go back from once you've experienced it.</p>
 
 <h2>Current setup</h2>
 <ul>
@@ -19,6 +21,14 @@ to the printer.</p>
 <li><strong>Container management</strong> (Portainer, cAdvisor, a node exporter) runs alongside, giving the same monitoring pattern as the rest of the fleet.</li>
 </ul>
 
+<h2>Camera and streaming</h2>
+<p>The camera setup uses a standard USB webcam connected to the Pi. The
+camera-server project provides two streaming modes: MJPEG for the
+OctoPrint dashboard (low latency, works in any browser) and HLS for
+remote viewing over slower connections. The MJPEG stream is the primary
+way to check on prints — it loads quickly and updates in real time in the
+OctoPrint web interface.</p>
+
 <h2>History</h2>
 <p>This Pi originally also had a small status display attached; the
 display was later moved to the backup Pi (which benefits more from local,
@@ -30,6 +40,16 @@ that point to better reflect its now-singular focus on the printer.</p>
 <p>After moving this Pi to a newer OS release, boot configuration files
 moved to a new path — editing the old path silently does nothing, which
 is an easy trap when following older notes or tutorials for the same
-hardware.</p>
+hardware. The lesson: always verify that configuration changes actually
+take effect, especially after OS upgrades on embedded hardware.</p>
+
+<h2>Why Docker on a Pi</h2>
+<p>Running OctoPrint in Docker on a Pi 3B might seem like overkill, but
+it provides consistency with the rest of the fleet. The same Portainer
+interface manages this container alongside the NAS services, the same
+monitoring stack collects its metrics, and the same backup strategy
+covers its configuration. The overhead of Docker on ARM is minimal for a
+single-container setup, and the operational benefits justify the small
+resource cost.</p>
 
 </div>

smarthome/tubearchivist/index.njk

@@ -10,7 +10,9 @@ layout: base.njk
 
 <p>TubeArchivist runs on the Synology NAS via Docker Compose, self-hosting
 a searchable archive of downloaded YouTube content (Elasticsearch +
-Redis + the TubeArchivist app itself).</p>
+Redis + the TubeArchivist app itself). It's used to archive channels
+worth rewatching — tutorials, long-form content, and anything that might
+disappear behind copyright strikes or channel deletions.</p>
 
 <h2>Why this needed real troubleshooting</h2>
 <p>Running Elasticsearch on Synology's DSM kernel isn't fully
@@ -23,8 +25,16 @@ without it, rather than fighting the kernel.</p>
 <ul>
 <li>Synology's Container Manager doesn't always auto-join containers to the same Docker network even when they're defined in one Compose file — an explicit named network avoids silent connectivity failures between the app, Elasticsearch, and Redis.</li>
 <li>A version upgrade of the app itself required a very specific step-by-step path (skipping versions breaks the database migration) rather than jumping straight to the latest release.</li>
+<li>Initial indexing of large channels takes significant time — Elasticsearch needs to build and optimize indices for full-text search across video titles, descriptions, and metadata.</li>
 </ul>
 
+<h2>How it fits into the backup strategy</h2>
+<p>TubeArchivist data is split into two categories with different backup
+priorities. The downloaded media files and Elasticsearch metadata are
+backed up as part of the NAS backup volumes, since they take significant
+time to re-download and re-index. The Redis cache is excluded — it only
+holds session data and can be safely rebuilt on restart.</p>
+
 <h2>What's backed up</h2>
 <table>
 <tr><th>Data</th><th>Included in NAS backup?</th></tr>
@@ -33,4 +43,13 @@ without it, rather than fighting the kernel.</p>
 <tr><td>Redis cache</td><td>No — safe to delete/rebuild, only holds session data</td></tr>
 </table>
 
+<h2>Day-to-day usage</h2>
+<p>Channels are added via the TubeArchivist web interface, which provides
+a YouTube-like browsing experience for the archived content. New videos
+from subscribed channels are automatically downloaded on a schedule. The
+search function indexes titles, descriptions, and metadata, making it
+easy to find specific videos in a large archive. The system runs headless
+on the NAS with no dedicated display — all interaction happens through the
+web interface or the companion mobile app.</p>
+
 </div>