~cartwright's Minimalist Blog

Rolling My Own: Leaving Bashblog for Perl 5.8

Jun 26, 2026

For a while, bashblog did exactly what I needed it to do. It was a single script, it didn't require a database, and it kept things out of the corporate cloud. But eventually, the cracks started to show. The moment you want to fix the markdown formatting issues, change how files are structured, tweak the layout logic, or manage index compilation without losing your mind, hacking away at a massive shell script feels less like minimalism and more like fighting a tool that wasn't built for your specific workflow.

So, I did what anyone would do: I went looking for an alternative.

The state of modern web software is excessively bloated. I spent a couple of hours digging through the current landscape of "lightweight" blogging engines and static site generators. Most of what I found was bloated beyond belief—engines wrapped in heavy JavaScript frameworks, massive Python dependency trees, used overly complex PHP (not that I have anything against PHP on its own) or tools that require pulling down hundreds of megabytes of packages just to compile a few plain text files into HTML. Even the self-proclaimed minimalist options still felt over-engineered for what should be a simple text-processing pipeline.

Nothing was even close. If you want something done cleanly without the extra weight, you usually have to write it yourself.

The final spark came when I was looking through Levi's website repository and saw their newpost.sh script. It’s a beautifully simple, no-nonsense shell utility designed to stream-line making a new entry. It reminded me how straightforward the process should be. But instead of sticking strictly to a shell script pipeline for the entire compiler backend, I wanted a dedicated language built from the ground up for heavy text manipulation.

I decided to roll my own static site compiler in Perl 5.8.

Yes, Perl 5.8. It’s a tool from a different era, but it is absolutely unbeatable. It is blazingly fast, runs natively on virtually any Unix-like box you throw it at, handles regular expressions like second nature, and has zero external runtime dependencies.

My new setup reads basic text files with custom metadata headers, runs them through a simple template block, and compiles the entire site—including the master index and an RSS feed—in just a few milliseconds. No Node modules, no complex database configurations, and no overhead. Just raw text, strict logic, and clean HTML.

It feels good to finally have a setup where I know exactly what every single line of code is doing.

Architectural Analysis: CMR vs. SMR Hard Drive Technologies (I know this is not written in the blog tone)

Jun 25, 2026

A Comprehensive Study on Data Corruption, Power Failures, Copy-on-Write Filesystem Incompatibilities, and the Contemporary Market Landscape

1. Technological Foundations: CMR vs. SMR

Hard disk drive (HDD) architectures rely on magnetic recording techniques to read and write data onto spinning platters. As physical storage demands surpassed theoretical areal density limits, manufacturers shifted from standard Perpendicular Magnetic Recording (PMR) variants to two primary operational models: Conventional Magnetic Recording (CMR) and Shingled Magnetic Recording (SMR).

Conventional Magnetic Recording (CMR): In a CMR drive, physical data tracks are written parallel to one another across the disk surface without any overlap. The write head, which is physically wider than the read head, writes a track size that matches its footprint exactly. Read operations occur directly over the center of these distinct, separated tracks. This guarantees that writing to an individual sector has absolutely zero impact on adjacent blocks, allowing for predictable, sustained random write behaviors.

Shingled Magnetic Recording (SMR): SMR modifies this physical layout to overcome the physical limits of track narrowing. Because read heads are substantially smaller than write heads, SMR overlappingly writes data tracks, mimicking shingles on a residential roof. Each new track partially covers a portion of the previously written track. While this drastically increases areal density (up to 25% or higher per platter), it introduces a critical structural limitation: a track cannot be overwritten individually without corrupting or destroying the data on the adjacent tracks that overlap it.

Core Architecture Comparison

Metric / Feature	Conventional Magnetic Recording (CMR)	Shingled Magnetic Recording (SMR)
Track Structure	Isolated, parallel tracks with guard bands.	Overlapping tracks resembling roof shingles.
Random Write Performance	High and predictable; direct sector overwrite.	Extremely low under sustained loads; requires full zone rewrites.
Internal Architecture	Direct pass-through mapping from OS to physical sectors.	Uses a complex Drive-Managed Translation Layer (similar to SSD FTL).
Best Suited For	NAS, RAID arrays, Databases, Boot drives, High-write environments.	Archival storage, sequential backups, cold data storage.

2. Operational Mechanics & Drive-Managed Architecture

To make SMR drives backwards-compatible with standard computer architectures, manufacturers developed Drive-Managed SMR (DMSMR). The host operating system treats the device as a standard random-access sector block device, unaware of the physical shingling layout. To handle the overwrite limitation, the disk surface is segmented into 'Bands' or 'Zones' (typically 256 MB or higher in size), bounded by non-overlapping isolation guards.

When a single sector within an SMR zone must be modified, the drive cannot simply flip the magnetic orientation of that specific sector. Instead, it must read the entire zone into a cache, alter the targeted sector in volatile memory, and write back the entire zone sequentially from the beginning.

To mitigate the severe latency penalties of this process, DMSMR drives integrate a high-speed volatile RAM cache alongside a physical, non-shingled CMR 'landing zone' on the outer edge of the platters. Incoming write operations are initially routed directly to this fast CMR cache. When the drive is idle, an internal garbage collection algorithm executes background migrations, reading data from the CMR cache, combining it, and writing it sequentially to the shingled zones.

3. Power Failure Vulnerabilities & Internal Data Corruption

The illusion that an SMR drive behaves exactly like a CMR drive is maintained by an internal abstraction layer known as the Drive Translation Layer (DTL) or Device Managed Translation Layer. Similar to the Flash Translation Layer (FTL) in Solid State Drives (SSDs), the DTL translates logical block addresses (LBAs) requested by the operating system into physical addresses on the shingled platters. This architectural dependency creates acute vulnerabilities during sudden power loss events.

Critical Risk: Drive Translation Layer Corruption

A sudden loss of system power during active background garbage collection or zone allocation table flushes can cause a complete mismatch between the DTL lookup table and the physical sectors on the platters, effectively bricking or destroying data readability across healthy portions of the disk.

Specific corruption modes directly tied to SMR power failure profiles include:

Metadata and Allocation Table Desynchronization: SMR drives maintain tracking metrics regarding active zones, clean zones, and CMR cache maps. If a power failure occurs while the drive is writing updated allocation tables from internal RAM to a persistent system track, the DTL can become corrupted. Upon reboot, the drive may fail to initialize, report a RAW filesystem, or register incorrect disk sizes (e.g., 0 bytes), requiring specialized hardware-level physical restoration.
In-Fight Zone Overwrite Destabilization: If power is interrupted while the drive is executing a full-zone rewrite (shingling back modified data), the sequence will cut off mid-zone. Because the track write head partially covers adjacent tracks during operation, an incomplete write compromises not only the specific block intended for modification but also destroys valid downstream user data located in adjacent, overlapping tracks within the same zone.
Volatile Write-Cache Data Loss: SMR drives acknowledge writes to the host operating system immediately upon reaching the volatile RAM cache or the CMR landing zone. In a power loss event where the OS has received a write verification, data that was still residing strictly in volatile RAM, or data queued for migration from the CMR cache to the shingled space, vanishes entirely. This leads to profound metadata inconsistency between the OS filesystem and the physical disk.

4. The Copy-on-Write (CoW) Conflict: ZFS / Btrfs / bcachefs and SMR Drives

The deployment of Drive-Managed SMR drives within Copy-on-Write (CoW) filesystems, such as ZFS, Btrfs, or within software RAID architectures (like mdadm or TrueNAS Core/SCALE), represents a severe operational mismatch. ZFS was fundamentally designed with the assumption that the underlying physical storage medium is a deterministic, fast-response block device that handles random and sequential write commands predictably.

ZFS optimizes write pathways by gathering allocations and committing them via transaction groups (txgs) through a Copy-on-Write methodology. Instead of modifying blocks in-place, ZFS writes modified data to entirely new physical locations on the disk, subsequently modifying pointers up the metadata tree. This architectural design creates a highly destructive cascading performance cliff when paired with SMR technology.

The Resilvering and Timeout Cascade Failure

When a standard drive fails inside a ZFS VDEV (Virtual Device), a replacement drive is added, initiating a process known as resilvering. Resilvering scans the entire pool's metadata and writes the parity-constructed data back to the new drive. Because ZFS traverses metadata trees sequentially by object rather than physical sector order, the resulting write distribution looks highly randomized to the target drive.

When an SMR drive is introduced as a resilver target, the following failure sequence occurs:

Initial streams fill up the SMR drive's on-disk CMR landing zone cache almost instantly (typically within the first tens of gigabytes).
Once the CMR cache is fully saturated, the drive's firmware forces an immediate, non-interruptible garbage collection loop to clear space, trying to read-modify-write data out to shingled zones.
Because the incoming write stream is ongoing and highly fragmented, the drive must continuously execute zone rewrites. Data throughput collapses from ~150 MB/s to single-digit megabytes per second, or stalls completely.
The internal drive controller becomes so overwhelmed with background input/output operations that it ceases responding to external ATA command requests from the operating system host bus adapter (HBA).
The ZFS kernel module waits for a predetermined command timeout threshold (typically 30 seconds). When the SMR drive fails to respond within this window, ZFS assumes the drive has suffered a hardware failure or disconnected completely.
ZFS ejects the drive from the pool, marking it as FAULTED or REMOVED.

Systemic Pool Degradation Danger

If multiple SMR drives are present within a RAIDZ array, the intensive write activity of a single resilver can cause multiple drives to hit the latency timeout threshold simultaneously. This triggers a multi-drive drop out, leading to immediate pool destruction and total data loss.

5. Improper Drive Shutdown Timelines and Host Violations

When a computer operating system initiates a shutdown or unmount sequence, it issues strict architectural commands to all connected storage media. This involves sending an ATA FLUSH CACHE command followed by standby or power-down directives. For a standard CMR drive, processing a flush command is simple: any write commands remaining in the volatile onboard RAM cache are instantly flushed to their permanent, non-overlapping track locations, and the drive heads park safely within milliseconds.

For a Device-Managed SMR drive, a FLUSH CACHE command behaves in a fundamentally different and non-deterministic manner. The drive's internal firmware considers data 'flushed' when it has successfully cleared volatile RAM and moved it into the permanent, non-shingled CMR landing zone cache. It then reports success back to the operating system.

Crucially, the hard work of migrating data from the CMR landing zone into the shingled bands has not yet occurred. The drive firmware requires an extended period of system inactivity (frequently stretching into minutes or hours after data transfer stops) to perform background zone consolidation.

If an operational environment utilizes improper drive shutdown timelines—such as immediately cutting power to external drive enclosures, hard-resetting enterprise servers via IPMI commands, or pulling portable USB-powered drives right after a file copy indicator completes—the drive is abruptly de-powered while its background firmware is actively running. Over time, these interrupted states cumulatively degrade the efficiency of the internal allocation tables, leading to sector tracking errors, read latency anomalies, and progressive file structure degradation.

6. Historical Timeline of SMR Market Integration

The introduction of SMR into the commercial market was characterized by an initial phase of transparent archival targeting, followed by a highly controversial period of unannounced integration into mainstream desktop and NAS product lines.

2013-2014: Initial Introduction – Seagate introduces the first commercial SMR drives under the 'Archive HDD' nomenclature. These drives were clearly designated for cold storage, data preservation, and sequential access profiles. They were explicitly marketed as inappropriate for random write, server, or RAID workloads.
2015-2018: Stealth Integration – As manufacturers hit density limits on standard 1TB and 2TB per platter configurations, they quietly integrated Drive-Managed SMR into standard 2.5-inch mobile notebook drives and lower-tier 3.5-inch consumer desktop drives without explicitly documenting the change on spec sheets.
2018-2019: Expansion into Network Attached Storage (NAS) – Western Digital began substituting CMR configurations with SMR designs inside its highly popular WD Red NAS line (specifically the 2TB through 6TB models, such as the WD40EFAX), completely undocumented.
2020: The Industry Transparency Scandal – System administrators and home server enthusiasts worldwide began noticing catastrophic RAID degradation and resilvering failures when deploying newly purchased WD Red drives. Following intense public backlash, independent hardware investigations, and threatened class-action litigation, Western Digital, Seagate, and Toshiba were forced to publish complete, comprehensive disclosures detailing exactly which drives utilized SMR. Western Digital subsequently re-branded its product stack, keeping SMR in the baseline 'Red' tier, while introducing the 'Red Plus' and 'Red Pro' lines to guarantee CMR availability.

7. Contemporary Market Reference Guide

The following guide highlights the architectural layout of the modern hard drive marketplace. Consumers and enterprise engineers must rigorously parse model numbers to ensure SMR models do not enter high-availability or CoW environments.

Manufacturer	Product Line / Brand	Recording Technology Type	Capacity Thresholds & Notes
Western Digital	WD Blue (Desktop 3.5")	SMR (Majority) CMR (Select models)	Most 2TB, 3TB, 4TB, and 6TB variants are SMR. High-capacity or specific 1TB models remain CMR.
Western Digital	WD Red (Standard NAS)	SMR (All)	Models from 2TB to 6TB (e.g., EFAX series) are strictly SMR. Banned for ZFS usage.
Western Digital	WD Red Plus / Red Pro	CMR (All)	Explicitly designated for RAID/NAS arrays. Guaranteed CMR across all capacities.
Western Digital	WD Black / WD Gold	CMR (All)	Performance and Enterprise lines; exclusively CMR across all capacities.
Seagate	BarraCuda (Compute 3.5")	SMR (Majority)	Mainstream desktop lines (2TB, 4TB, 8TB) are SMR. Explicitly designed for light compute only.
Seagate	IronWolf / IronWolf Pro	CMR (All)	NAS-focused product line. Seagate maintains a strict no-SMR policy for all IronWolf models.
Seagate	Exos (Enterprise)	CMR / HM-SMR	Standard Exos models are pure CMR. Select cloud hyperscale models use Host-Managed SMR (managed by server OS).
Toshiba	P300 (Client Desktop)	SMR / CMR Split	Newer high-capacity iterations (e.g., 4TB, 6TB P300) are SMR. Older or lower capacity models remain CMR.
Toshiba	N300 / MG Series	CMR (All)	NAS and Enterprise Critical lines; exclusively CMR across all production models.

Summary Recommendation for Storage Engineering

For any deployments involving ZFS, RAID configurations, high-frequency database logging, or critical infrastructure, it is absolutely essential to mandate the purchase of drives explicitly validated as CMR (such as WD Red Plus, Seagate IronWolf, or Enterprise lines). SMR drives must remain strictly quarantined to sequential cold-archival write streams or disconnected single-drive consumer backup tasks.

From Claude Code to Micro-Agent: The Rabbit Hole of AI Coding Agents on Vintage Hardware

Jun 23, 2026

Every developer knows the feeling. You see a shiny new tool, your brain sparks with possibilities, and you immediately try to run it on hardware that has no business hosting it(well maybe only me).

This is the story of how a simple desire to try Claude Code led me down a rabbit hole of instruction set failures, API translation layer frustration, context-window blowouts, and ultimately, writing my own lightweight AI coding agent in Ruby.

---

The Catalyst: Fighting with Claude Code

It started innocently enough. I wanted to see what Claude Code could do.

My weapon of choice? An old, trusty Dell laptop powered by an Intel Core 2 Duo P8700 processor. I kicked off the installation, only to watch it pull down a massive package over 280MB in size. For a CLI tool, that felt extremely bloated.

But the real kicker came when I tried to run it:


Illegal Instruction

The harsh reality of legacy hardware hit home. Claude Code (or its underlying Node binaries) compiled down to modern instruction sets requiring AVX and AVX2, extensions that my Core 2 Duo completely lacks. 280MB of bandwidth, gone.

The Pubnix & Proxy Detour

Refusing to give up, I shifted tactics and moved to a pubnix (a public UNIX server). Of course, running an AI agent on a shared public server comes with an obvious caveat: someone could easily sniff your process arguments or environment variables and steal your API key. Worse yet, I didn't actually have a dedicated Anthropic API key on hand. I wondered: How hard could it be to use an Anthropic-to-OpenAI API translator?

I found two translation projects via a quick web search. What followed was a classic developer nightmare: Python version conflicts, NPM dependency hell, and incompatible environments. Frustrated, I sat down and wrote my own custom API translator from scratch.

It finally ran! I hooked up Claude Code to my translator, typed a command, and... absolute silence.

Only the basic /btw command functioned. The moment Claude Code tried to do anything involving actual file editing, it failed completely. As it turns out, Claude Code passes a gargantuan list of tools and system instructions out of the box. This massive payload instantly saturated the OpenAI-compatible endpoint's context limit.

All that work, and the context window choked before the model could even think.

---

The Birth of `Micro Agent`

If you can't use a heavy tool, you build a precise one. I abandoned the bloated frameworks and wrote a lean, custom AI coding agent called Micro Agent, implemented as a lightweight Ruby CLI.

Micro-Agent features a flexible architecture allowing it to pivot between different LLM backends using profile commands. To test it, I decided to give it a classic litmus test: Write a simple program to output "Hello, World!" in amd64 NASM assembly for Linux, along with a Makefile to compile it.

I hooked it up to a local, smaller model profile (gemma4:e2b) to see how an optimized, smaller intelligence would handle low-level engineering tasks. What followed was a glorious, looping comedy of errors.

---

The Battle of the Assembly Code: A Log Summary

While Micro-Agent successfully integrated with system tools, the smaller model architecture struggled immensely with syntax, build systems, and execution guardrails. It took far more prompts and manual intervention to get a "Hello, World" binary compiled than it ever would have taken to write it by hand.

Here is the condensed, sanitized screen dump showing the agent trying to complete the task:

ben@box5:~/Projects/micro-agent/a$ ../micro-agent.rb 💻 Welcome to MicroAgent CLI micro-agent > /api use 0 🎯 Switched active profile targeting to Context ID Engine Node: [0: gemma4:e2b] micro-agent > make a simple program to say "Hello, World!" in amd64 NASM for linux, and make a makefile for it 🤖 Thinking... Writing hello.asm and initial Makefile... ... [15+ Security Gate Permission Prompts Condensed] ... ❌ FAILURE 1: The model generates a flawed Makefile with invalid space indentation. 'make' throws a "missing separator" syntax error. 🤖 Thinking... Correcting Makefile syntax... ❌ FAILURE 2: The model rewrites the Makefile but ruins the dependency logic, blindly repeating strings and breaking standard GNU Make patterns. 🤖 Thinking... Attempting to execute 'make' again... Target fails. ❌ FAILURE 3: The model decides to bypass 'make' entirely and chain commands via the shell: 🛠️ Executing: execute with args: {"command"=>"nasm -f elf64 hello.asm -o hello.o && ld hello.o -o hello"} ⚠️ Execution blocked! The micro-agent core engine explicitly bans command chaining (&&) for security. ❌ FAILURE 4: The model attempts a raw NASM compilation but fails because it used Python/C shell style '#' characters for comments inside hello.asm. micro-agent > nasm does not support using '#' for comments, use ';;' instead. 🤖 Thinking... Rewriting hello.asm with proper ';;' comment syntax... ... [More Permission Prompts] ... micro-agent > run the make command ❌ FAILURE 5: The model panics, completely loses track of the directory state, deletes/overwrites the Makefile with broken targets, and accidentally purges hello.asm. When it tries to recreate hello.asm, the user manually rejects the file write out of sheer exhaustion.

⚠️ [Security Gate] Grant agent permission to 'write_file' on 'hello.asm'? (y/n): n ✅ Objective reached or agent stopped.

Taking Back Control

At this point, the agent hit an environmental wall, forcing me to temporarily suspend the process (^Z) and inspect the damage.

The agent had left behind an absolute mess in the build script (build.sh). It had attempted to use gcc to link a raw entry-point assembly file. When executed, the GNU linker threw a massive fit:


> /usr/bin/ld: hello.o: in function `_start':
> hello.asm:(.text+0x0): multiple definition of `_start';
> (.text+0x17): undefined reference to `main'
> collect2: error: ld returned 1 exit status

Because gcc automatically injects the standard C runtime (crt1.o), it provides its own _start symbol and looks for a developer-defined main function. My assembly file explicitly defined _start and lacked a main.

To fix it, I manually bypassed the broken script and linked it directly using the raw linker:


ben@box5:~/Projects/micro-agent/a$ ld hello.o -o hello
ben@box5:~/Projects/micro-agent/a$ ./hello 
Hello, World!
Segmentation fault

Success... followed immediately by a Segmentation Fault. The agent's code printed the string via system calls but failed to clean up the stack or invoke the proper sys_exit sequence. I had to manually jump into emacs to fix the register placements and structural bugs inside hello.asm myself until it finally executed cleanly.

When I brought Micro-Agent back to the foreground (fg) and asked it to review the modifications, it admitted its own execution blindness, noting that security restrictions prevented it from testing its own output.

---

Lessons Learned

Model Size Dictates Logical Rigor: Small local models like gemma4:e2b are fantastic for text processing or basic scripts, but they break down when navigating multi-step compilation pipelines. They struggle to retain context over strict formatting rules (like Makefile tabs vs spaces) and will loop endlessly when a command fails.
Larger Contexts Shine: When switching Micro-Agent over to heavier, remote configurations—such as openai/gpt-oss-120b—the loops disappear. Higher-parameter models anticipate linking requirements, comment rules, and runtime environments effortlessly.
The Irony of Automation: Sometimes, setting up an autonomous agent to automate a 10-line assembly script takes 10x more time, prompts, and debugging than just pulling up a text editor and typing the assembly code out yourself.

Yet, despite the hiccups, Micro-Agent works. It's ultra-lightweight, it runs on virtually any machine, it doesn't suffer from modern instruction set bloat, and it keeps the developer firmly in control of the security gates. For vintage laptop enthusiasts and minimalist developers alike, building your own agent is a journey well worth taking.

---

How I got started programming

Jun 22, 2026

I decided to write down a bit about how I originally got into computers and coding. It all started when I was 12 years old, when my dad taught me Perl. That was my first real introduction to writing scripts and getting things to run.

After that, I just kept building on it. For the next 12 years, I spent my time diving into different systems and learning a bunch of languages.

The Toolkit

During those 12 years, I heavily focused on learning C, C++, Java, ASM (x86), and Ruby. Working with x86 Assembly and C gave me a good understanding of low-level systems, while Ruby became a great tool for writing clean scripts.

Along the way, I also picked up a little bit of Rust, Python, and Perl 6 (raku). To figure out how the web side of things worked, I learned javascript and some web design stuff, like html, css, and a little bit of xhtml.

Down to the Silicon

As I got deeper into programming, I wanted to know exactly how everything worked under the hood. Over the years, I've learned pretty much everything about computers from the chipset and bootloader level on up.

Instead of treating operating systems like a black box, I've spent hours exploring the NetBSD and Linux source code to see how they handle things at the core. To actually apply that, I've built a simple bootloader from scratch, written my own kernel, and even patched BIOS images to manually unlock hardware virtualization features like VT-x.

New version of searchvista is out!

May 14, 2026

New version features better search results, and faster search times. Next month (June 14th 2026), We will be trying out pagerank.

PageRank

PageRank is an algorithm for measuring a webpage's relative importance or authority based on its link structure. It works by treating links as "votes" where votes from more authoritative pages count more. So like if tilde.club is pointed to my 15 other sites, that means that tilde.club will have a higher score, and the score will be even better if the those 15 sites were pointed to by someone else, the more sites on the tree pointing torwards tilde.club the better score. Not all votes are equal because a site with many links dilutes its own power.

Switching to Window Maker from TWM

April 30, 2026

Much smoother than TWM for normal use.

Another post

April 02, 2026

Another post about nothing.

Switching to TWM from GNOME

January 21, 2026

Switched to TWM from GNOME, because gnome takes nearly 15% CPU while idle, and while playing video about 200% CPU usage.

SearchVista mirror systems upgrade

January 11, 2026

Upgrade went smooth and only 1 minute of down time!

SearchVista mirror systems software upgrades

January 11, 2026

Mirror #1 (https://xuser.publicvm.com) will be down for the max of 48 hours for system upgrades within the next 7 days.

SearchVista index

January 09, 2026

The index update has finished and all mirrors are updated.

SearchVista index update

December 29, 2025

The index will be updated starting from now, until jan-5-2025

Added add url link

December 22, 2025

Added a Add URL links so that regular people can now submit URLs to be indexed. https://sv.tilde.one/add_url.html

The testing of my search engine

December 19, 2025

Have been testing my search engine for the last 2 days, and the search engine gives some pretty good results, only %25-%50 of the results are relevant, but most of the relevant results are interesting. Visit the search engine at: https://sv.tilde.one or mirror #1: https://xuser.publicvm.com

My first blog

December 18, 2025

Just doing some backups to today.