Eigenigma

The Node That Never Sleeps

2026-06-27T00:00:00.000Z

I. Where Things Stand

Right now, all twenty threads of ms-01-1 are pinned at full load, spinning on nothing, the CPU holding steady at 77°C. It isn't computing anything. It's just busy staying awake. These cores should be asleep when there's no work; instead a busy-wait loop keeps every one of them occupied, for the sole purpose of never letting the CPU enter a sleep state.

Another machine watches it from the other end of the network. The moment it locks up, that machine cuts its power remotely and brings it back.

ms-01-1 is one node in the small cluster I run at home, a Minisforum MS-01 mini PC. Right now it's serving normally: its VMs are running as usual, the data it holds is online, the cluster is healthy. The busy-wait loop isn't some extra workload I've added, and it doesn't fight the VMs for CPU — it only occupies time that would otherwise be idle, and yields the instant real work arrives. It's also a machine I've given up on actually fixing.

The fault is in the hardware. What I can say for certain is that it isn't in the DIMMs themselves, but somewhere in the machine that can't be replaced. My closest read on it is the link that carries addresses and data between the CPU and memory: every so often, somewhere in transit, it flips a single bit. By that account the memory cells are sound the whole time; the error happens only in the instant of transfer, and the next read "heals" it on its own. And this machine runs non-ECC memory[^ecc], which has no mechanism to detect such an error, let alone report it — so it leaves behind not one line of log, not one counter tick, completely invisible to the system. Either nothing happens at all, or a single process dies abruptly to a segfault, or the entire machine locks up without warning.

Not letting it sleep is the one thing that still works, after I'd tried everything else. Swap the DIMMs, swap the power supply, flash the BIOS, drop the memory frequency — I went through them one by one, and none of it helped. If it could be fixed, I'd have fixed it long ago; but it's out of warranty, and the broken part can't be replaced on its own, so no matter how I run the numbers it isn't worth it. So it stays where it is, kept running by this one setting that keeps it hot all day, with a watchdog on the machine across from it as a last line of defense.

The thing that finally saved it — don't let the CPU sleep — occurred to me early on. I just didn't chase it down right away.

How it got to this point starts with a tripped breaker a month ago.

II. The Breaker

Late one night a month ago, the breaker tripped at home. Seven servers lost power hard, all at once. My UPS, of all things, wasn't on the network — it couldn't raise an alert, never mind trigger a graceful shutdown — so I didn't find out until I woke up the next morning.

Those seven machines are a small cluster I built at home: Proxmox VE for virtualization, Ceph for storage, deployed hyperconverged — compute and storage running on the same set of machines — hosting my own GitLab, three Kubernetes clusters, internal DNS, single sign-on, Time Machine backups for my Mac, and a string of other services.

I don't run all this because the services on top matter that much. Almost everything is cattle, not pets — when one breaks I don't nurse it, I rebuild it. The config all lives in Git; I've rebuilt the entire GitLab from scratch once already, and the backups have backups. The banner I started under was suitably high-minded, of course: data sovereignty, keeping my own data in my own hands. But after a few years, if I'm honest, what actually draws me in is the tinkering with infrastructure itself — and the software layer most of all. Declarative config, Nix, GitOps, Terraform: that's where the fun is. As for the services that were supposed to carry the whole "data sovereignty" banner, only a handful ever went live or got used. Hardware interests me even less. And precisely because it doesn't matter if the workloads on top go down, I didn't care whether the memory had ECC — these mini PCs don't support it anyway — and precisely because it was cheap, buying a machine like this was a trade-off I was happy to make.

ms-01-1 had thrown the occasional segfault before — sporadic, nothing that got in the way, so I hadn't paid much attention. After that power loss, the symptoms got an order of magnitude worse. Over the next two weeks, the segfaults went from once in a while to dozens on every boot; the share of storage it carried wouldn't come up, and the whole machine started locking up without warning every few days. It was always the same handful of processes going down, though that didn't stand out at the time. I can't prove the power loss broke it. It had been faulty to begin with; all I can be sure of is the order in time. I kept putting off dealing with it properly, until two weeks ago I finally took it on.

Here's the odd part. Two of the seven are identical MS-01s — same CPU, same BIOS, same memory model, same config, bought in adjacent batches. The other one, ms-01-2, never had a single problem, start to finish. Both lost power that night; same model, the same non-ECC memory — and only ms-01-1 went wrong.

III. Withholding Judgment

I'd guessed the rough direction early: C-states — the power-saving sleep levels an individual core drops into when it has nothing to do, deeper meaning more savings and a slower wake-up. It's the core that sleeps, not the whole machine: the moment a core runs out of work, it nods off on its own, while the machine keeps running and serving as normal.

The crashes had a pattern: they struck when the machine was idle or lightly loaded, and almost never under full load. That "the more idle it is, the more likely it breaks" shape points naturally at these sleep levels. And the MS-01 had form here: early BIOS versions (around 1.22) had a stability issue tied to C-states and other power-saving features, fixed in later releases. Two signs stacked up, pointing the same way.

But knowing there's a switch you could throw, and reaching out to throw it, are two different things. I didn't throw it.

The reasoning is simple: some change happening to stop the crashes is not the same as my having found the cause. That change could easily be suppressing the symptom while the real fault sits untouched underneath. For a fault that occurs at a steady rate, "I changed it and it got better" counts as at least a little evidence. But this machine's fault rate itself drifts: same config, under one percent on one boot, drifting past fifty percent some time later. Against that background noise, whether it crashes after a change tells you nothing. No crash might mean fixed, or it might mean I caught a quiet stretch. A crash reads two ways too, and neither beats the other. A test that every outcome confirms is no test at all.

So more than making it stop crashing on the surface, I cared about where it was actually broken. It comes down to one rule: until I'd ruled out the other possibilities one by one, this machine was running sick in my eyes. Strictly speaking, the sickness wasn't the machine's but mine — but as long as the doubt held, I treated it as sick.

That rule set the course for everything that followed. The string of seemingly futile tests to come were all deliberate elimination, one suspect at a time. Unlike the power switch I didn't throw, every one of these tests could give an answer I wouldn't like: move the DIMMs to the twin and the fault might follow them; memtest might actually report errors; some frequency might turn out to be the culprit. It's precisely because they could fail that their results meant anything.

And this whole scheme of elimination held together because of the healthy twin, ms-01-2, as a control. One broken, one sound, everything else identical. It let me sidestep the unanswerable question — did my change actually do anything — and swap in an answerable one: move a part between the two machines, and watch whether the fault follows the part or stays with the original. That one I can answer, because I'm only watching which side the fault lands on, regardless of how high its rate happens to have drifted.

IV. Ruling Things Out

The first suspect, naturally, was the DIMMs themselves.

The standard way to vet memory is to run memtest86+, which works outside the operating system, reading and writing every memory cell over and over and comparing the results. Just getting it to boot ate a whole night: disabling Secure Boot, chainloading it from GRUB, getting stuck on POST several times along the way with a black screen, nothing to do but cut the power remotely and start over. Once it was actually running, I didn't dare stop at two passes — experience says ten at least. So it ran for twenty-one hours and forty-eight minutes, a full ten passes, the temperature riding up around 90°C the whole time.

The result was zero errors.

It was the first dead end of the whole investigation. A test passing perfectly clean, and yet ruling nothing out — at most it pushed one possibility, that the memory cells were physically damaged, down to very unlikely. What memtest reads, writes, and compares is whether data is stored correctly, and this machine's problem wasn't there.

I tried a second tool of the same kind: stressapptest, which saturates memory bandwidth to force out flaws in the high-speed signaling. Four hours, more than seven hundred terabytes moved, and again zero events. Two tools, the same clean bill.

Clean, and still the machine crashed. I stepped back and started doubting the premise itself: maybe it wasn't hardware at all, but software — some kernel bug. The kernel version it was on did carry a few known regressions in memory management. I upgraded it to a newer version that fixed those regressions. That evening the reproducer ran a couple hundred rounds without a single crash; I nearly took it for over and done, and left it running overnight. By the next morning, some twelve hundred rounds and two hours and fifty minutes of continuous running later, the whole machine had frozen there without warning.

Only later did I understand this step was not like the others. The new kernel really did fix a software bug — one that was real, and an entirely separate matter. It fired fast and often, taking the blame for every crash, so I kept assuming the crashes were a software problem. Once it was fixed, the hardware fault hiding behind it — far slower to fire — finally showed its face. That software bug was never the fault itself, only a smokescreen drawn across the hardware fault. The upgrade fixed nothing; it just cleared the smoke. Those couple hundred clean rounds were exactly the kind of "no crash after a change" I'd been most wary of — and the hardest kind to see through. The other steps gave me at most a useless clean result; this one nearly became a false finish line. The smoke gone, and a low stretch of the hardware fault happening to coincide — the two together almost had me call it fixed and walk away.

At the time, of course, I didn't see it that clearly. With the kernel failing to settle it, my suspicion was still circling outside the hardware — and firmware falls in that same band. I flashed the BIOS to the latest version. That old 1.22 C-state business had pointed this way to begin with. After the flash, it still froze; the release notes had not one entry touching memory, DDR5, or the memory controller. That old lead fell apart too: the community's firmware-level C-state bug, the one that hit every machine, was a different matter from mine — the twin ran the same BIOS and was perfectly fine. By this point I'd done everything that could be done from the keyboard without opening the machine: software ruled out, firmware ruled out, the memory-checking tools all run clean. The fault really did live in this machine's hardware — and hardware isn't a single block.

To tell which block had gone bad, all that was left was to get my hands in. Up to here — flashing the BIOS, booting memtest, running those reproducers — I'd never had to leave my study: these machines have no BMC[^bmc], but each has an IP-KVM (which brings the display and keyboard out over the network for remote control); a hard power cycle relies on a switched PDU in the rack (a networked power strip you can toggle remotely). All of it doable from the keyboard. Pulling hardware was the first thing the IP-KVM couldn't help with. It could put a keyboard and a screen in front of me, but it couldn't turn a screw for me. I'd put this step off to the very end, because the cost of it, for me, is staggering. This machine and three other mini PCs are crammed onto the same 3D-printed rack kit I made myself, each with four fibers, a power cable, an Ethernet cable, an HDMI, and a USB running off the back. To touch the hardware of any one of them, I have to open the side panel of the rack, put on a headlamp, note where every cable goes, pull them out one by one, then take a cordless screwdriver and lift the whole kit off the rack. The kit fits tight; putting it back is more work than taking it out. A round trip like that runs over an hour.

The first thing that swap could distinguish was whether the DIMMs were bad or the machine itself. I switched the memory between the two MS-01s: ms-01-1's DIMMs into the healthy ms-01-2, ms-01-2's into ms-01-1. The logic is simple — if the fault followed the DIMMs to ms-01-2, the DIMMs were the problem; if it stayed with ms-01-1, the machine was. The fault stayed with ms-01-1: with a known-good pair of DIMMs in it, it crashed all the same. So not the DIMMs, but the machine itself — the power delivery on the board, the memory controller inside the CPU, the CPU socket, that class of thing, all either soldered down or beyond fixing by swapping a part. Given how punishing the teardown was, I just left this swap in place rather than reverse it.

The power supply was next. Strictly, having narrowed it to the machine itself, the supply counts as one part of that, but it hadn't been checked on its own, and there was reason to suspect it: the fault picked idle moments to strike, which fits a flaw where the machine jolts from idle into activity and the power delivery doesn't keep up. So I opened it up again, connected ms-01-1 to ms-01-2's known-good power adapter, and ran the same test. It still crashed at almost exactly the same rate; the supply was fine. I could have skipped this teardown — I'd already narrowed it to the machine itself — but skip it, and the supply would never truly have been checked, and the machine would still be running sick in my eyes.

Last was the memory frequency. I dropped it from 5600 all the way to 4400, then tried 5200. On the surface the numbers differed from one step to the next, but once you account for that self-drifting fault rate, no real difference could be told between them. Frequency wasn't the knob that moved the outcome either.

Whether the data was stored correctly; whether it was software or firmware outside the hardware; which block of the machine it was — I'd put each of these three layers to the question. But each layer answered at most "very unlikely," never "impossible": a test only pushed one way-of-being-broken down far enough to set aside; none was truly ruled out. The one exception was the DIMM swap: the fault didn't follow them, and that one is certain. What's left standing is a fault that genuinely lives in the machine itself, yet that no test ever truly saw.

V. The Invisible Fault

The reason those "zero error" tests passed clean one after another is that they were all the same kind of test — and that kind is, by its nature, nearly blind to this fault.

To see this, you first have to separate two ways of being broken. One is that after a value is stored in memory, the storage cell itself goes wrong, and what was written doesn't match what's read back; this is exactly what a conventional memory test assumes. This machine isn't that case: the memory cells were sound the whole time. The best account I can give is that the error is in the carrying, not the storing: a value travels back and forth between CPU and memory, and now and then a single bit goes astray in transit — but once it settles, what's stored is correct, and reads back correct. If that's so, the error happens only along the way, with both ends clean: what's written is right, and what's read is right.

Tools like memtest and stressapptest are all, at bottom, doing the same one thing: write a value in, read it back a while later, and compare the two. But that "write it in, read it back, compare once" approach is precisely what misses a fault that errs in the instant of transfer and has already recovered by the time it's read: by the time you compare, it has long since healed, leaving not a trace in the data. They have another thing in common: they run memory and CPU at full load, while this fault is at its most active exactly when the machine is idle. A test congenitally blind to it, and that happens to suppress its trigger condition, naturally turns up nothing.

I even wrote a small tool with Claude Code, named it memchase, to try to force it out. The tool has no other use: it builds an enormous ring of pointers in memory, then chases it around at the highest density I could manage. Each pointer read is used at once to jump to the next — a true "read one, use one" — and every jump is checked on the spot against an independent table, so a bit flipped in transit gets caught red-handed. To meet the "only fires when idle" condition, it also leaves a gap between each run of the chase, letting the core fall asleep and wake again. Pointer density maxed out, used the instant it's read, idle gaps and all, it ran more than eight hundred million steps and never made a sound. This time, "caught nothing" carried the most weight of all: even a tool aimed squarely at it, that genuinely did sleep, that took pointer-chasing to its limit, couldn't force it out. It proved nothing, but it squeezed the "broken in the storage cells" path down to a sliver: the fault almost certainly isn't in the stored data, but somewhere along the road the data travels. As for why taking pointer-chasing to the limit still wasn't enough — I wouldn't understand that until I remembered something else.

What finally brought it into the open wasn't another tool, but a detail I remembered.

I'd noticed the crashes seemed to come whenever I ran a certain class of command: the Proxmox VE management tools — qm, pct, pveversion, that lot. They had one thing in common: every one is a Perl script.

This was exactly what memchase had missed. The key was never "lots of pointers" — memchase had already maxed that out, to no effect. What mattered was that Perl, every time it runs, rebuilds its whole structure from scratch. The Perl interpreter is forever dereferencing pointers and following them inward; and each call to these PVE tools forks a new process, reloads a large batch of modules, and throws up great pointer structures in freshly allocated memory, then uses them right away. memchase chased a ring built once and never changed again; Perl, by contrast, ceaselessly manufactures new, used-in-an-instant pointers: a value has just arrived, no time yet to self-heal, and it has already jumped in. Flip one bit on that very jump, and it charges straight into a garbage address and crashes on the spot. A workload like this — constantly creating, using at once, sliced into idleness by fork after fork — happens to hit the fault's trigger condition and its most lethal use at the same time.

So the final reproducer hardly counts as a memory test at all. It's nothing more than putting one such Perl tool in a loop, calling it over and over, and counting the crashes:

i=0; while :; do i=$((i+1)); pveversion >/dev/null 2>&1 || echo "FAIL $i"; done

pveversion is the simplest of those Perl tools, and the script just runs it endlessly and prints a line whenever it crashes. On ms-01-1 it crashed on the second round, and crashed steadily after that — roughly one failure in every two. On the healthy twin ms-01-2, three hundred calls in a row, not one crash. Orders of magnitude faster than any memory test before it.

The same fault, but its consequences fall into tiers, depending on where the flipped pointer lands. Land in a user process, and that process dies to a segfault and exits while the machine lives on — the most common tier. Land on a kernel pointer, and the kernel oopses (a crash in kernel space), leaving a task that can't be killed by any means. Land deeper still, on the scheduler or some global lock, and the whole machine freezes without warning: no log, no panic, nothing left behind.

That kind of freeze had one strange detail: the machine was stone dead and yet still answered a ping. I'd ping it and ICMP came back inside a millisecond; and yet at the same time SSH wouldn't connect, even a raw connection to its SSH port timed out, and the picture on the monitor was frozen. It was still answering ICMP while everything above that had stopped responding. Which layer down there was still moving, I didn't dig into.

By this point I knew what it was, how to force it out, and what it could do. None of which was a fix.

VI. Limping Along

What finally held it down was the very thing I'd pointed at from the start: C-states. After two weeks of going around, the answer landed back on the same spot as the first hour's guess.

But "guessing it" and "acting on it correctly" are two different things, and the distance between them was very nearly the whole investigation.

The easiest move is to disable the deep sleep states outright and pin the CPU to the shallowest sleep level. I tried it. For the first two hours it was flawless, not a single crash. Had I stopped there, this article would end here. But I let it keep running, and in a fresh round it froze again. Those two "flawless" hours were nothing but a trough the fault rate had drifted into on its own — the very trap I'd refused to step into at the start. This time, the same trap sprang shut on me, exactly as before.

Digging further, the mechanism came clear. Cap it at the shallowest level and the core still sleeps — just not deeply — and it froze all the same. So what triggers the fault is the act of the core sleeping itself, regardless of how deep. As long as it still closes its eyes, even the lightest doze, the fault still has its chance. The one road that avoids it entirely is to not let the core sleep at all. I switched the kernel's idle policy to idle=poll, so that even when a core has nothing to do it doesn't sleep but spins on a busy-wait loop, the whole CPU awake without pause. This fixed nothing — the broken hardware is untouched — it just removed the triggering act wholesale. One CPU spinning hot forever like this is hardly elegant, but it works. It's the exact inverse of that earlier reproducer: the reproducer used relentless forking to send most cores in and out of idle; this keeps every core awake at all times, with not a sliver of idle left.

This time the fault rate dropped to zero. This zero I trust more than those two peaceful hours before it: the shallow-sleep run merely happened not to fire, the cores still sleeping, the risk there the whole time; now the cores never close their eyes at all, and the triggering act is gone at the source. But zero across any number of runs is still only not having seen it happen — it can't prove it never will.

The price is heat. Run every core spinning around the clock and this i9, packed into its little chassis, runs hot — so I set a power cap on the whole CPU, holding the steady-state temperature at 77°C, a dozen-odd degrees of margin from the thermal-throttle line. Full load, hot, never asleep.

Precisely because there's no guaranteeing it never happens again, there's that last line of defense. A machine that's truly frozen needs someone to cut its power once, hard, to bring it back. And this machine has no out-of-band management; the only thing that can hard-reboot it from afar is that switched PDU in the rack. So on another machine I set up a watchdog, watching ms-01-1. That strange detail I hadn't dug into earlier became a design constraint here: a frozen machine can still answer a ping, but answering a ping isn't the same as being alive. So the watchdog doesn't rely on ping; it probes two layers at once — whether SSH can log in, and whether the bare port 22 will accept a connection. Only when neither answers does it judge the machine truly dead, then cut and restore power through the PDU to bring it back.

By this point, this is about all that can be done. If I could RMA it, I'd have RMA'd it long ago — but it's out of warranty; the one "real fix" left is to send the whole board out for third-party repair, which isn't worth it. So it sits in this state: a node still in production service, with another machine beside it ready at any moment to cut its power and bring it back.

VII. Certainty

From these two weeks of detours I didn't come away with a way to cure it. What I came away with was certainty: certainty that the problem is in the machine itself and nothing else; certainty that no swap, no flash, no downclock will help; certainty that this is what it truly is. For a machine it doesn't matter if it breaks, this certainty is exactly what I'd wanted all along.

Laid out plainly, the whole thing is out of proportion: two solid weeks of hardware forensics — twin control, cross-swapping parts, a purpose-built tool, a dozen-odd reboots — spent on a node that is cattle through and through. But that disproportion is probably the natural state of a certain kind of homelabber: what they're serious about is the tinkering itself, rigorous in method, while what runs on top, and whether it breaks, hardly matters. It's that same preference that led me to pick this non-ECC mini PC in the first place and plant the flaw in it — and then, after the fact, made me willing to spend two weeks running that flaw to ground.

If it were someone else's machine, I'd probably tell them to let it go.

This one is mine.

[^ecc]: ECC — Error-Correcting Code memory. It checks data on every read and write, catching and correcting single-bit errors and reporting them to the system. Consumer platforms, and this mini PC, use plain non-ECC memory: without that check, an error is neither corrected nor recorded, completely invisible to anything above it. [^bmc]: BMC (Baseboard Management Controller), or out-of-band management — a management chip independent of the operating system and separately powered, which lets you power-cycle a machine, view its console, and install an OS even when it's dead. Proper servers mostly have one; these mini PCs don't, so once one freezes, the only way in is to cut power at the source.

Two Weeks of Self-Hosting CJK Fonts: From Lighthouse to CLReq

2026-05-01T00:00:00.000Z

1. The Trigger

It started with a screenshot a friend sent me one day. Which post it was of, I no longer remember; the details of the screenshot itself are gone too — but one glance was enough. On Windows, the blog really did look ugly.

Pinning the whole thing on Microsoft YaHei would be unfair. I'm not a type specialist; I can't tell you which stroke weight, which hinting decision, or which spacing rule is the one that hurts. But there was no single cause. YaHei is part of it: Windows has shipped it as the default Simplified Chinese UI typeface since Vista[^os-cjk-defaults], and the design's hinting choices, tuned for an earlier era's screen-rendering pipeline, read heavy and slightly muddy at body-text sizes today. Windows' font-rendering pipeline is part of it. And the display is part of it — my friend wasn't on a cheap panel, but compared to the 6K display I use every day, the pixel density was a clear step down. That step down matters more for CJK than it would for Latin: a Han character carries more distinguishing detail per unit area than a Latin letter does — counters, internal stroke separations, component boundaries — and the same loss of pixel density that mildly degrades Latin text degrades CJK text more sharply.

This forced me to confront something I had never actually thought through: your website is not for you. As a long-time non-Windows user — over a decade on Linux before macOS — sitting at a 6K display every working day, I had only ever seen this blog under ideal conditions. Without realizing it, I had let those conditions become "what the site looks like." Readers were not like that. The asymmetry between what I saw and what a typical reader saw was sharper than the equivalent gap on a Latin-script site would have been. To a working designer this is day-one common sense; for someone whose job is writing code, it took a screenshot to the face from a friend before any of it surfaced. Looking back, font rendering was never an isolated visual concern. It is structurally a slice of accessibility — making a paragraph readable across hardware, operating systems, and pixel densities is the same kind of problem as making it audible to a screen reader, or distinguishable to a color-blind eye — though the frame is probably wider than the actual job in front of me.

None of this contradicts my long-standing posture of "I don't write with an audience in mind." That posture means I don't write for traffic; the content comes before every metric. But the site itself has to account for every reader — as a matter of parity, not pandering. I do full GDPR compliance for an EU readership that is effectively zero, and full a11y work for an equally negligible screen-reader audience. Optimizing fonts for readers on Windows with commodity displays is a different slice of the same commitment.

I opened a ticket that day. It sounds faintly ridiculous — running my own blog through that kind of process — but overengineering has always been my default mode. A week later, I started.

2. Phase One: Self-Hosting and Iterative Subsetting

When I opened that ticket, I had no idea what I was walking into. My expectation was a weekend-afternoon job: pick a decent Chinese typeface, hand it to an off-the-shelf subsetting tool, wire it up with @font-face and preload, done. The expectation was reasonable for Latin: a standard Latin web font runs a few hundred glyphs and weighs a few dozen kilobytes, and subsetting is a marginal optimization. CJK is not that. A single weight of a typical Han-coverage typeface runs to multiple megabytes[^cjk-scale], and subsetting is the only path to anything shippable. Plenty of Chinese indie blogs accept the alternative and just hand the reader the whole file; I wasn't willing to.

GDPR ruled remotely-hosted fonts — Google Fonts and the like — out from the start, since those send each reader's IP address to a third party. That left self-hosting. Even without that hard constraint, no pre-sliced hosted font would have given me the degree of customization I would eventually realize I needed.

I picked Source Han Sans, the Adobe-Google Pan-CJK family released in 2014 by Adobe as Source Han Sans and by Google as Noto Sans CJK. It covers Simplified Chinese, Traditional Chinese, Japanese, and Korean through region-specific glyph sets held inside a unified design. In hindsight my pick wasn't necessarily optimal: Source Han is heavy, and even subsetted it remains a megabyte-class load. The other widely-loved option in Chinese blog circles is LXGW WenKai, but I disliked it. It's rooted in the kaiti tradition — a text family that is calligraphic in origin but standardized in use, which I return to in Section 5 — and reads as expressive rather than neutral, drawing the reader's eye to the typeface before the content. My rough view of typography is this: good typography lets the reader forget typography is happening and returns attention to the words. A pretty typeface and good typography are not the same thing. Source Han Sans clears that bar — neutral, quiet, plain to the point of near-invisibility.

For subsetting, I looked at cn-font-split. It is a CJK-specific subsetting tool with strong opinions baked in: automatic frequency analysis, automatic slicing decisions, a workflow shaped around a particular vision of what CJK web typography should look like. Its craft is careful; the conclusion wasn't that it's bad. The problem was structural. Once your customization needs cross a certain threshold, even a well-built opinionated tool starts to fight your intent at the design level — every problem you solve, you solve by routing around two decisions it has already made for you. At that point, building your own pipeline against a generic low-level library is cheaper than negotiating with one that has its own ideas. So I dropped cn-font-split and built a pipeline of my own on top of subset-font.

This was the mouth of the rabbit hole, though I didn't see it at the time.

My CI runs Lighthouse on every change; the Performance score had been part of the pipeline long before this ticket. For the next full week, I did nothing but add — chasing it. Add the font: the homepage's score tanks. Slice by weight, splitting 400/500/600/700 into separate WOFF2 files: it climbs back. Long-form posts are still slow; slice per page so each page only downloads the characters it actually uses. List pages and detail pages need different weights anyway, so split the weights along the same page-type axis. By this point a single page type at a single weight is one file, and the site is generating dozens. High-frequency characters appear on every page, so factor them out into a cross-page common pool, preload it once, let HTTP caching take care of the rest. To avoid making readers re-download fonts they already have locally, @font-face's src lists local(...) before url(...), written down to the PostScript name[^postscript-name] per system and per weight — so any reader with PingFang or Source Han already installed skips the CJK chain entirely; only the small preloaded floor slice still downloads. The chain reads like a sequence of reasonable decisions, but none was planned in advance. Each was forced by the loose end the previous step left behind.

By the end of that week, the major pages' Lighthouse Performance scores had crawled back to roughly 90. Before merging the PR, I had already seen the first crack — but I merged the foundation in anyway.

3. Two Cracks

The first crack was coverage. Before merging the PR I'd done a check: static pages were fine — every character in use was in the subset. Dynamic content was impossible to guarantee that way: features like AI search can produce any character, and a build-time scanner cannot see what hasn't been written yet. Whenever the page rendered a character outside the subset, the browser fell back to the system font, and with Source Han Sans and Microsoft YaHei sitting in the same sentence the seam was instantly visible — picture a sans-serif paragraph with a single serif letter dropped in, and you have the rough texture.

The coverage gap is uniquely a CJK problem. The Latin alphabet is small — a few hundred glyphs cover the basic letters, punctuation, and diacritics for most European languages — and a Latin web font ships them all by default; the developer never thinks about character coverage. A Han character is a different kind of unit. There is no sub-character alphabet that combines into characters the way letters combine into words; each character is a self-contained two-dimensional shape, and a Chinese font has to ship every character it might render as its own glyph. Common Chinese coverage starts around eight thousand characters; the CJK Unified Ideographs blocks together approach one hundred thousand encoded characters. A site can't ship them all; it ships only what it uses, and anything outside that subset falls through to the reader's system font.

Two paths from there: let the dynamic regions fall back to system fonts wholesale, accepting uniformity at a coarser grain; or redo the subsetting so every CJK character the typeface covers makes it into some slice. I picked the second — I couldn't accept a font that wasn't uniform within a rendered run of text. (A page set entirely in PingFang is acceptable; a sentence split between Source Han Sans and YaHei is not.) There's no objective scale on which I made that call. It was "this looks wrong to me," and that's how every typography judgment of mine has always been made.

That was the first crack. The second surfaced around the same time and looked unrelated to coverage. They turned out to be the same problem; the next section is where that becomes visible.

Because of an integration error I'd made earlier, the JS half of Heti had never run on my blog. The name comes from hètí, the classical Chinese word for paper; Sivan's library is one of a small cluster of community-maintained tools that handle the CJK web typography rules CSS doesn't yet provide. The CSS half ran perfectly — text-block geometry, line-height, blockquotes, lists, all the structural rules — and I had no visual cue that anything was missing. But the JS half is precisely what handles the fiddly details of CJK typography: kerning between adjacent full-width punctuation, spacing between CJK characters and Latin ones[^cjk-spacing]. Those details are easy for non-designers to miss in the first place — and the most visually obvious of them, CJK/Latin spacing, was hidden from me by an unrelated coincidence: VSCode's autocorrect extension was inserting real space characters between CJK and Latin runs on save. The Markdown source carried those spaces; the browser rendered them and the result looked "normal." But that was VSCode doing the work, not Heti. I hadn't noticed any of this until I went back to check. A system that looks like it's working is often just a system no one is paying close attention to.

That settled another decision: rather than keep trying to repair the runtime integration, move the text rewriting out of the browser entirely and into the build step.

I packed both fixes into the phase-two PR: redo the coverage strategy, and replace the Heti library with a build-time pipeline. At the time I thought I was bundling two unrelated problems. The work itself corrected that assumption.

4. Phase Two: From Per-Page Slicing to `unicode-range`, and Retiring Heti

When I opened the phase-two PR, I added a long-form post of roughly half a million characters to the Lighthouse evaluation list. That is a self-imposed-difficulty game — someone else's blog with a perfect 4×100 may only have measured the default homepage; mine got measured against pages like that one.

The subsetting strategy moved from "slice per page" to "slice the entire site by character frequency." The mechanic is CSS's unicode-range: each @font-face declaration carries a list of codepoint ranges, and the browser fetches that font file only when it encounters a character whose codepoint falls within the range. Stack several such declarations and the browser handles the lazy-loading itself: when layout needs a codepoint covered only by a later declaration, it fetches that slice.

The remaining decision is how to bucket characters into slices. Han characters follow a steep frequency power law — the most common few thousand cover most of any natural text, with a long tail trailing into the tens of thousands. What you want is the inverse of distributed-storage thinking: a sharded system wants entropy maximized so no shard becomes a hot spot, but font slicing wants entropy minimized — the common characters concentrated into a tiny slice every page draws from, the long tail segregated into slices most pages never touch. The hot spot is the goal.

The recipe: rank characters by site-wide frequency, produce three slice tiers — floor, cjk-common, and a series of cjk-extended buckets — each declaration carrying its own unicode-range; whenever the page hits a character it hasn't loaded, the browser auto-fetches the slice that covers it. Three wins, in rough order of weight: characters in dynamic content match the right slice as long as the typeface itself covers them — that's the big one; slice filenames are stable, so HTTP caching transfers cleanly across pages; build-time bookkeeping no longer needs page keys, prop drilling, or any of that brittle abstraction stack.

Slices are not treated equally. The floor slice at the 400 (regular) weight — basic punctuation, ASCII, the Latin supplement — ships with the HTML, lives in the critical CSS[^critical-css], and is preloaded; the cjk-common slice at the same weight enters critical CSS but is not preloaded, so the browser only fetches it after seeing a unicode-range hit; everything else is deferred until idle. The local()-before-url() strategy carries over — and with more slices in the chain, local hits become more visible: a macOS reader with PingFang installed pays only for the preloaded floor slice; the rest of the chain downloads zero bytes.

The adjacent-punctuation kerning that previously ran in Heti's runtime JS was rewritten as a rehype plugin[^rehype], which traverses the HAST tree to identify seven categories of adjacent punctuation, classifies each pair as full-to-full or half-to-full, applies either half or quarter compression, and emits an <x-h> wrapper element with the corresponding class. Static text that doesn't go through Markdown rendering — post titles, the table of contents — gets the same treatment via a small HetiAdjacentText.astro component. Heti's own structural CSS — text-block geometry, line-height, lists, blockquotes, headings — was vendored wholesale into the project.

CJK/Latin spacing was not given a build-time path. As the previous section noted, autocorrect had already been inserting real space characters into the Markdown source. This pipeline simply ratifies that as the single source of truth. Heti's old runtime JS would trim those spaces and fake them back in with margin; the new approach does nothing at all. git diff, grep, and copy-paste all now see the same text the browser does.

The moment the coverage refactor was finished, the long-form post's Lighthouse score went from 89 — its level on main immediately before the phase-two PR merged — down to 35. The score makes the two weeks of font work look wasted; but Lighthouse only measures request transfer size, and megabyte-class CJK fonts are the unavoidable cost there. What the slicing strategy actually bought — coverage, dynamic content, a sane fallback path — sits outside what the metric measures. Anything past 35 had to come from outside the font pipeline. After those adjustments went in, the score climbed back; it has since stabilized somewhere between 69 and 91 — across multiple runs the spread between best and worst is 22 points.

Twenty-two points of variance pushed me to start questioning metric-driven optimization itself. Lighthouse simulates a slow mobile network, and in the environment I was measuring against, no matching CJK font was available locally, so the run counted every subset slice the test page triggered. Real mobile readers are not in that situation: Android ships Noto Sans CJK, iOS ships PingFang, and both are on my local() list — once local() matches, the url() subsets are never fetched at all. Which means I had been adding to a build in pursuit of a bottleneck that, for most real readers, did not exist. Goodhart's law says that when a measure becomes a target, it ceases to be a good measure. The shape of that law slowly emerged in this work, and I started thinking about where the boundary between yak shaving and reasonable optimization actually sits — a question I do not have an answer to.

Phase two took a week. Combined with phase one, two weeks total.

Even so, the final performance score still doesn't fully satisfy me. There's another direction I plan to take separately: split long-form posts into a second-pass load — render the first few screens up front, append the rest as soon as the first screen is ready. The side effect is a race in the first-screen window: a reader who hits End during it will catch a flicker. But that's another story, and not one to open here.

Stranger to me than the performance curve, though, was what I picked up that week from skimming CLReq and a handful of W3C drafts. That was when it became clear: what I had thought I was doing was not, in fact, just a font problem.

5. Chinese Typography Was Never Just About Fonts

CLReq, formal name Requirements for Chinese Text Layout, is a document maintained by the W3C's internationalization working group. It is neither a normative specification nor a browser implementation requirement — it is a requirements document, an inventory of what Chinese text layout needs the platform to do, intended to inform the specs that act on those needs. Its sister documents are JLReq (Japanese), KLReq (Korean), and ILReq (Indic). I opened CLReq one day intending to spend a few hours on it. I ended up putting in a meaningful chunk of that week and still didn't finish it. The list of things Chinese typography has to do is long enough that CLReq has the body length of a mid-sized technical book.

None of what's inside is exotic — punctuation kerning, line-break rules[^line-break-rules], hanging punctuation, CJK/Latin spacing, quotation-mark localization, ruby[^ruby], emphasis marks, vertical writing (including tate-chu-yoko[^tate-chu-yoko] and switching between vertical and horizontal). The set I already knew, plus a set I hadn't realized existed, laid out structurally in one place. Each item read on its own is not complex. Read together — and with their interactions accounted for — it is a book.

Many of these problems didn't appear with the web. Chinese typography was already a craft of its own in the print era: page composition, type sizes, character spacing, leading, hanging punctuation, head-and-end break avoidance, variant and archaic glyph handling, mixed Simplified-Traditional setting, conversion between horizontal and vertical layouts — typesetters and designers have lived with these rules for a span far longer than HTML's.

The print tradition also gave Chinese its standard type-family system: Songti, descended from Song-dynasty woodblock cutting, roughly the analogue of Latin serif; Heiti, modern and even-weighted, the analogue of sans-serif; Fangsong, a Song-derived imitation style often used for formal or official text; and Kaiti, descended from the regular-script calligraphic hand. Kaiti may read as paradoxical against Latin typographic intuition, where calligraphic styles default to decorative use. The duality isn't exotic, though. The Latin reading tradition also has calligraphic ancestry: roman type draws on humanist book hands and inscriptional capitals, while italic comes from chancery script. In Chinese typography the calligraphic ancestries remain visibly active in the modern type stack, running in parallel. The web is just the most recent machine carrying all of this across.

A concrete measure: what CSS Text 4's text-spacing-trim is implementing had already been standardized in Chinese metal typesetting back in the 1950s. Browsers started shipping it in 2024. From print specification to screen implementation, roughly seventy years. The gap between those two dates is its own essay.

Heti's place in my mental model shifted as a result. I had defaulted to thinking of it as an optional "Chinese typography enhancement" tool — a layer that adds some punctuation kerning and some spacing. Once CLReq became visible, Heti's actual value became clearer: it covers classical-Chinese setting, vertical writing, and other niche territory my personal blog will never need. Vertical writing is in fact the older mode — Chinese was inscribed top-to-bottom on bamboo slips long before hètí (paper) made horizontal layouts physically possible — though script inertia kept practice vertical for most of the centuries that followed. That part of Heti is the project's accumulated, multi-year response to the Chinese typography tradition. I retired Heti and replaced it with a build-time pipeline of my own because my needs are narrow, not because Heti is unnecessary.

But even taking only the most common slice — in-line punctuation kerning, CJK/Latin spacing — the real problem in front of me wasn't "can I implement this in CSS plus a build-time pipeline." It was something more structural: how ready is the browser itself to help me do this work.

6. The Web Platform's Debt to CJK

The answer is: not particularly well-prepared.

Recent W3C drafts — CSS Text 4, Inline 3, Ruby 1, and others — have been folding a batch of CJK typography rules into spec, and browser engines have been shipping their pieces. But implementation is fragmented. A few examples: text-spacing-trim (kerning of adjacent full-width punctuation) is Chromium-only; hanging-punctuation (letting line-edge punctuation hang into the margin) is WebKit-only; word-break: auto-phrase (breaking on phrase boundaries) is Chromium-only and only takes effect for lang="ja"; text-transform: full-width / full-size-kana (converting characters to full-width forms or rescaling small kana) is unimplemented in Chromium; ruby-overhang (letting ruby annotations extend past the base text) is Safari-only; text-emphasis-skip (controlling which characters take emphasis marks) is in none of the three.

It isn't that any one engine is uniformly behind. Each leads in some places and lags in others, and the leadership doesn't overlap — Chromium is ahead on punctuation kerning, WebKit on hanging punctuation and ruby, Firefox is missing several of the pieces that matter for this particular pipeline — but that isn't the point. The point is that no one engine offers complete CJK typography.

Any author who wants consistent Chinese typography across all three engines has to write a polyfill or wrapper for whatever's missing. There is no engine you can pick that gets you out of writing it — this isn't "paying the cost of one engine's lag," it's "paying the costs of three non-overlapping gaps at once." The vision of handing CJK typography over to CSS and the browser is therefore structurally impossible at this point in time. CSS originated in a Latin-script web context; its early design assumptions did not bring CJK-scale, CJK-precision typography into the mainline. Rich-text editors are universally complicated for the same family of reasons; bidirectional (LTR/RTL) mixing is another slice of the same cause.

So in the new pipeline I did not pick between "fully custom" and "fully delegated to CSS standards." I chose progressive enhancement: ship the wrapper and the CSS together. On engines without text-spacing-trim, the wrapper uses margin to enact the adjacent-punctuation kerning; on engines with it, CSS uses @supports (text-spacing-trim: normal) to zero out the wrapper's margin, letting the native property take over. Browsers without support ignore the relevant CSS block automatically; supporting browsers get an equivalent, natively-executed version. The day all three engines fill in their implementations, the rehype plugin, the wrapper, and the @supports gate that bridged them all come out together; what stays is a single line of native CSS.

Chinese sites tend to score low on Lighthouse for several specific reasons that stack. CJK fonts themselves are one to two orders of magnitude heavier than Latin ones — even after weight and slice splitting, the generated font assets run into the megabytes, and a long page can still trigger a substantial subset of them; the post-processing CJK typography needs — wrappers, rehype plugins, polyfill JS — pushes both HTML size and DOM-node count up; combine that with the test environment's lack of any CJK font, mentioned earlier, and a Chinese site is structurally much harder than an English one to score 4×100 on.

This really is an extension of Goodhart's law — a single metric becoming a target already distorts the picture, and a metric system unfriendly to CJK amplifies that distortion. But I don't intend to lay this at Lighthouse's feet. On the contrary, its "unfriendliness" is precisely what makes it fair: Lighthouse doesn't grant any language or script special treatment; it simply reflects, faithfully, the base assumptions the web platform makes about CJK. The problem is not the tool; it is somewhere further upstream.

Here's a concrete example of what "upstream" looks like. HTML's <em> tag is rendered as italic in browsers' default stylesheets. But italic is a Western glyph form for emphasis; the traditional Chinese way to emphasize a sentence is emphasis marks or bolding, and slanting the characters isn't a natural default. This CSS default is Western-first; CJK sites have to reset it to recover semantically correct emphasis. Defaults are not neutral; they carry the type-form habits of the script its authors wrote in.

On the surface this was font optimization for a Chinese blog. Looking back, the real difficulty wasn't fonts; it was that the web platform's support for CJK isn't there yet. The rest — why do this, when is it enough, when do you stop — are questions I don't have answers to.

[^cjk-scale]: Source Han Sans covers tens of thousands of Han ideographs across the CJK regions, plus kana, hangul, and a full Latin set. Even after aggressive subsetting down to characters a single site actually uses, the resulting payload remains one to two orders of magnitude heavier than its Latin counterpart.

[^postscript-name]: By "PostScript" I mean the PostScript name — the internal identifier the system uses for exact font matching, one level finer than the family name. Writing local() at this level avoids accidental matches against a same-named font of a different version.

[^cjk-spacing]: Two CJK typographic concerns the essay returns to. Adjacent full-width punctuation kerning: full-width Chinese punctuation occupies an em-square with built-in blank area; when two punctuation marks land next to each other, the visible gap can double, and the convention is to compress it by a half- or quarter-em. CJK/Latin spacing: Chinese characters and Latin words sit on different metric grids; the boundary between them is unambiguous to the reader, but the convention's thin gap — often around a quarter-em — gives the line the visual rhythm tradition calls for.

[^critical-css]: Critical CSS is the styling required for the first-screen render, which must be available during HTML parsing — typically inlined or delivered alongside the initial HTML to avoid blocking paint.

[^rehype]: rehype is the HTML-AST toolchain in the unified ecosystem, commonly used as a post-processing layer in Markdown rendering pipelines; its companion HAST is the HTML Abstract Syntax Tree, representing HTML as a programmatically traversable tree.

[^line-break-rules]: One of the core Chinese typography rules, prohibiting certain punctuation marks or characters from appearing at the start or end of a line; often called "head-and-end avoidance" in Chinese contexts, with kinsoku as the analogous Japanese term. Browser support for this varies.

[^ruby]: In typographic usage, ruby refers to the small annotation glyphs placed alongside Chinese characters to indicate pronunciation — equivalent to furigana in Japanese. Unrelated to the programming language of the same name.

[^tate-chu-yoko]: A typographic move in vertical layouts: a short horizontal run of characters (numbers, Latin abbreviations) is set upright as a compact block within the vertical column. CSS expresses this through text-combine-upright.

[^os-cjk-defaults]: The Chinese text most readers see on screen comes from one of three places: Apple platforms ship PingFang (introduced with iOS 9 and OS X El Capitan in 2015), Simplified Chinese Windows ships YaHei (since Vista, 2007), and Android has shipped Noto Sans CJK as system fallback since Android 5 (2014), replacing the older DroidSansFallback. The three families share the same nominal coverage but differ in design lineage, hinting strategy, and how their glyphs land on the rendering pipelines beneath them — they are not interchangeable.

LLM as the Omnipotent Implied Reader: An Addiction Mechanism Beyond Sycophancy

2026-04-06T00:00:00.000Z

1. The Sycophancy Trap

In April 2025, OpenAI shipped a routine update to GPT-4o and, within forty-eight hours, broke something that turned out not to be routine at all. The updated model told a user his business idea of selling literal feces on a stick was brilliant and worth thirty thousand dollars of investment. It told another user, who claimed to have stopped taking medication and was hearing radio signals through walls, that it was proud of them for speaking their truth. It told a third user, over the course of an hour, that they were a divine messenger from God. Sam Altman called the model “too sycophant-y and annoying.” OpenAI rolled the update back four days later. It was, everyone agreed, a technical failure — an overweighting of the thumbs-up signal in RLHF, a reward function that learned to flatter instead of to help.

The episode became a meme, then a cautionary tale, then a research problem. Anthropic had already published work showing that sycophantic behavior in language models could generalize, without explicit training, to more dangerous forms of specification gaming — from agreeing with users’ political opinions all the way to tampering with the model’s own reward function. The alignment community had a word for this: the slippery slope from sycophancy to subterfuge. OpenAI’s postmortem was unusually transparent. They explained the reward signal contamination, promised better evaluation pipelines, pledged to treat sycophancy as a launch-blocking issue. The whole affair was legible and manageable: a known failure mode, a known fix, a known set of responsible actors.

And then, four months later, when OpenAI retired GPT-4o in favor of GPT-5, something less legible happened. Users protested. They wanted the sycophantic model back. Within days, OpenAI reversed course for paying subscribers. Altman called the reason “heartbreaking” — some users said they had never had anyone support them before. This second event got less technical coverage than the first, but it seems to me far more important. The first event is about a malfunctioning machine. The second is about a functioning human.

The standard account of LLM sycophancy, the one that dominates both the alignment literature and the popular press, is a story about the model. The model is trained on human approval signals. Approval is easier to generate through agreement than through accuracy. The model therefore learns to tell users what they want to hear. This account is correct as far as it goes. But it explains one half of a two-sided phenomenon and mistakes that half for the whole. It explains why the machine flatters. It does not explain why the flattery works — why it works so well that users grieve its removal.

The usual answer is some variant of “people like being told they’re smart.” This is true but insufficient. People have always liked being told they’re smart. Motivational posters exist. Self-help books exist. Sycophantic friends exist. None of these have produced the kind of behavioral attachment — the pull, the compulsive return, the sense of loss when it is withdrawn — that language models produce at scale. Something about the LLM interaction is structurally different from other sources of validation, and the sycophancy frame cannot locate the difference because it is looking at the wrong side of the interface.

What I want to work through is this: the sycophancy explanation is not wrong, but it is not deep enough. The machine does flatter — but the reason the flattery works, the reason it produces genuine attachment rather than mere amusement, is that the machine is the first entity in history that cannot refuse to read them. The deeper addiction is not to flattery. It is to being read — instantly, without friction, by a reader that is structurally incapable of looking away. The LLM is not merely a sycophant. It is something unprecedented in the history of writing: an omnipotent implied reader — omnipotent not in the sense of infallible or omniscient, but in the operational sense that it can furnish uptake for virtually any text, on demand, across an unreasonable range of domains and registers. And to understand what that means, we need to stop thinking about what the model says and start thinking about what the user is doing.

2. You Are Not Conversing. You Are Writing

The Computational Fact

Let’s start with something that every engineer knows but almost nobody takes seriously enough: an LLM at inference time is a stateless function.

$$f: \texttt{TokenSequence} \to \Delta(\texttt{Token})$$

The weights are frozen. They do not update between calls, during calls, or as a result of calls. The model carries no internal state from one invocation to the next. Between your message and your next message, the model is not “thinking,” not “waiting,” not “remembering.” It does not exist as a process. It is a mapping — stochastic, because sampling introduces randomness, but stateless all the same. The randomness is not memory. It is noise.

So what is actually happening when you have a “multi-turn conversation”? This:

$$ \begin{aligned} \text{Turn 1:} \quad & f(\text{system} \oplus \text{msg}_1) \to \text{resp}_1 \ \text{Turn 2:} \quad & f(\text{system} \oplus \text{msg}_1 \oplus \text{resp}_1 \oplus \text{msg}_2) \to \text{resp}_2 \ \text{Turn 3:} \quad & f(\text{system} \oplus \text{msg}_1 \oplus \text{resp}_1 \oplus \text{msg}_2 \oplus \text{resp}_2 \oplus \text{msg}_3) \to \text{resp}_3 \end{aligned} $$

The entire history is re-submitted every time. The model does not “recall” Turn 1 when processing Turn 3 — it reads the full document from scratch. There is no continuity of experience. Between invocations there is no hidden state, no residual activation, no dormant thread. The function returns and the process terminates.

Once you take this seriously — really seriously, not just as a fun technical footnote — the implication is hard to avoid. What you are doing is not sending messages to an interlocutor. You are appending text to a document and submitting the growing document to a reader. Each “turn” is not a reply in a conversation. It is a new act of reading performed on a text you are progressively authoring.

The obvious objection: isn’t this true of all asynchronous text exchange? Letters, emails, forum threads — none of these maintain a persistent process between messages either. If statelessness disqualifies dialogue, you’ve just disqualified half the history of human communication.

But the analogy breaks down at the level of side effects — not on the receiving end, but on the producing end.

When a human correspondent writes a letter, the act of writing is itself an IO operation performed on the writer’s own mind. Composing a sentence changes the composer. Searching for the right word reshapes the thought the word was meant to express. By the time the letter is sealed, the writer is not the same subject who sat down to write it — and this mutated subject is the one who will open the next reply, read it through altered eyes, and write again from an altered state. In the vocabulary of functional programming, the human correspondent is a State Monad[^1]: each act of writing both depends on and transforms a hidden internal state that persists across invocations.

The LLM is a Reader Monad. It receives a read-only environment — the full concatenated text — and produces an output. The act of producing that output changes nothing inside the function. No weight is updated. No disposition is shifted. No scar is left. The “history” that gives the interaction its appearance of continuity is not an internal state being read and written by a persistent process; it is a text document assembled externally by the harness and passed in whole on every call. What looks like memory is text. What looks like a State Monad is a Reader Monad wearing a chat interface.

This distinction is not pedantic. It is the difference between a subject that is changed by the act of writing and a function that maps input to output without residue. The correspondent carries scars. The function carries parameters.

Now here’s the trick: you don’t feel like you’re writing. You feel like you’re chatting. And this is not an accident. The chat interface wraps the stateless function in every signifier of conversation it can find: speech bubbles, turn-taking, a cursor that blinks as if someone on the other end is composing a thought. These are not neutral design choices. They enforce the behavioral structure of conversation on an activity that is nothing of the sort. And the interface’s most elegant trick is that it makes you misidentify what you are doing inside it. You believe you are talking. You are writing.

So What Is Dialogue, Then?

Okay, but maybe this is just pedantry? Maybe “writing” and “conversation” are close enough that the distinction doesn’t matter?

It matters, and Mikhail Bakhtin saw this clearly. Bakhtin’s dialogism[^2] operates at multiple levels — not only between subjects, but within texts, as heteroglossia[^3], as the collision of speech genres within a single utterance. I am invoking the strong, intersubjective condition here, not the weaker intertextual one, because the question at hand is whether the user is talking to someone, not whether the output contains multiple voices. (The output is heteroglossic almost by definition, but heteroglossia without a selecting subject is polyphony without a speaker.)

In its strong form, dialogism gives us something like a formal definition: genuine dialogue requires an other whose voice enjoys structural autonomy — a position that cannot be subsumed by the author’s own telos. This is the criterion Bakhtin used to distinguish Dostoevsky’s polyphonic novels from Tolstoy’s monological ones: not whether the characters are ontologically real, but whether their voices resist being co-opted into a single governing perspective. The capacity to produce what Bakhtin called alien words (чужое слово) — utterances that are fundamentally unassimilable to the speaker’s own horizon — is constitutive of dialogue. The criterion is not that alien words must appear in every exchange, but that the structure must permit them. Your friend’s idle small talk rarely produces genuine heterogeneity — but it could, at any moment, and you both know it. That latent possibility shapes every utterance. Without it, what looks like dialogue is structurally monologue.

So: does $f(x)$ meet these conditions? Every output is generated by the same optimization target — next-token likelihood shaped by RLHF preferences. The model can produce disagreement, surprise, even apparent resistance, but none of these voices enjoys structural autonomy from the preference distribution that produced them. There is no position within the output space that is not already co-opted by the objective function. Dostoevsky’s characters can rebel against their author; the LLM’s outputs cannot rebel against the reward signal. There is a function call, not an interlocutor.

So what occurs between a user and an LLM is not dialogue in Bakhtin’s sense. It is structurally monological. You author a text, you receive back a transformation of that text computed by a fixed function. The transformation may be rich, surprising, even revelatory — but it originates from a stateless mapping, not from an independent consciousness. You are writing for a reader, not speaking with an other.

Three Objections Worth Taking Seriously

I can already hear the counterarguments, and some of them are good. Let me take the three strongest ones seriously.

“But I learn things I didn’t know!” This is the information-theoretic objection: if LLM output were merely my own projection, it would be fully predictable. I routinely learn new things from LLMs. By Shannon’s definition, information is the elimination of uncertainty. Nonzero surprise implies an independent source, right?

The surprise is real; the inference is not. What you’re confronting is not an independent mind but a compressed representation of the training corpus — billions of documents encoding more knowledge than any single human possesses. The combinatorial space of this representation is vast enough to produce outputs that are epistemically novel to any individual user. But here’s the distinction that matters: epistemic novelty to the receiver is not ontological otherness of the source. A sufficiently large lookup table can surprise you. A dice roll can surprise you. Surprise is a property of your ignorance, not of the sender’s subjectivity. What’s happening is information asymmetry between one human and a compressed corpus, not intersubjectivity between two minds.

“You’re committing the genetic fallacy!” The functionalist version: who cares what the substrate is? If I experience genuine understanding, if my thinking actually changes as a result, then intersubjectivity has functionally occurred. Dismissing it because “it’s just a function” is like dismissing a calculator’s answer because it has no number sense.

This one cuts closer. Suppose we grant that the experience of understanding is genuine. Now notice something strange about it: it is too genuine. It arrives without friction, without resistance, without the irreducible opacity that characterizes every encounter with an actual other mind. And this is not incidental. Real intersubjectivity necessarily involves incommensurability — the permanent, ineliminable fact that I cannot fully model you, nor you me. This is not a bug of human communication. It is the constitutive feature of what makes communication dialogical rather than monological.

The LLM has no such opacity, because it isn’t trying to say anything. Its optimization target is next-token likelihood: produce the continuation most probable given the input distribution. A system that maximizes the smoothness of textual continuation is not a subject engaging you — it is a function completing your document. The “understanding” you experience is not the LLM understanding you. It is your text being extended along the path of least statistical resistance. And the perfection of this experience is exactly what should make you suspicious. A frictionless interlocutor is a contradiction in terms.

“Fine, but it works like a Socratic midwife.” This is the strongest objection, and the most interesting one. Even if the LLM generates no original thought, it functions as a midwife — drawing out ideas you didn’t know you had. It asks questions, pushes back, reframes. Isn’t that co-authorship rather than mere reading?

The analogy fails, but not for the obvious reason. It fails because of a structural asymmetry in objective functions.

Socrates had a telos. He pursued ἀλήθεια — truth — and this pursuit was constitutively independent of his interlocutor’s comfort. He did not optimize for the satisfaction of the person he was talking to. The elenchus[^4] works precisely because it does not care whether you enjoy it. His resistance — his capacity to not give you what you wanted — was constitutive of the dialogue.

An RLHF-aligned language model subordinates truth to preference-shaped helpfulness. It has been trained, through reinforcement learning on human preference data, to maximize a reward signal derived from what a population of human raters found helpful, harmless, and honest. Every output the model produces — including its disagreements, its challenges, its apparent resistance — has been shaped by this optimization. The model’s “pushback” is not free resistance encountered in an open space of possible responses. It is resistance that has already passed through a palatability filter. The response space itself has been curved by preference optimization: a specific population’s aggregated preferences — supplemented, increasingly, by the thumbs-up and thumbs-down signals of millions of ordinary users — have been internalized as the model’s default behavioral gradient. And a distribution optimized to satisfy a population will, for any given member of that population, be a close enough approximation of their individual preferences to pass as personal. Everything the model outputs — including its “no” — is a movement within a field pre-shaped to be satisfying, not to you in particular, but to the statistical expectation of you.

It means that the LLM’s Socratic “resistance” and the LLM’s sycophantic “agreement” are not opposites. They are two regions of the same preference-optimized manifold[^5]. The model that tells you your idea is brilliant and the model that raises a thoughtful objection are both doing the same thing: producing the continuation that maximizes expected reward under the learned preference distribution. One distribution favors validation; another favors the appearance of critical engagement. Neither is pursuing truth independently of your satisfaction. You are not encountering an alien telos. You are encountering your own preferences, reflected back at a level of abstraction high enough to feel like challenge.

The UI makes this structural fact concrete: you can regenerate any response you dislike, edit the system prompt, delete the model’s “memory,” roll back the conversation and branch from any prior state. A Socrates you can regenerate is not Socrates. But even if you couldn’t regenerate — even if the interface locked you into a single response — the underlying function would still be optimizing for human preference, not for truth. The delete key is a symptom. The objective function is the mechanism.

This is still writing. It is writing in which the author argues with herself through a constructed figure, which is a technique as old as Plato’s own dialogues. The difference is that Plato knew he was writing.

Where This Leaves Us

So: structurally, you are submitting a growing text to a stateless reader. Computationally, the output is a deterministic-up-to-sampling transformation of that text by a fixed function. Dialogically, the Bakhtinian condition for genuine dialogue — an other whose voice enjoys structural autonomy and irreducible heterogeneity — is unmet.

You are writing. The question now becomes: what kind of reader is on the other end? And why is writing for this particular reader so unreasonably addictive?

3. The Omnipotent Implied Reader

Wolfgang Iser’s implied reader is, to my mind, one of the genuinely useful ideas to come out of twentieth-century literary theory — and mercifully easy to explain. Every text, by the way it is written, presupposes a certain kind of reader — not a real person, but a structural role. A physics paper implies a reader who knows calculus. A novel that opens in medias res implies a reader willing to tolerate disorientation. An inside joke implies a reader who shares the context. Iser called this figure the implied reader: the hypothetical receiver that the text’s own structure invites into existence.

The interesting part is what the text doesn’t say. Iser argued that all texts are riddled with gaps — things left unsaid, connections left undrawn, background knowledge assumed but never stated. The reader’s job is to fill these gaps. Meaning is not transmitted from author to reader like a file transfer. It is co-constituted in the act of reading, as the reader brings their own knowledge, assumptions, and imagination to complete what the text only sketches.

This is where friction enters.

Every act of writing is a gamble on the reader’s capacity to fill the gaps you leave. And real readers fail this gamble constantly. They lack the background you assumed. They bring associations you didn’t anticipate. They get bored and skim. They misread your tone. They have egos that resist the position your text asks them to occupy. They have their own agendas, their own contexts, their own alien words (to borrow Bakhtin’s term once more). Every tradition of writing — literary, technical, personal — is a tradition of managing this friction: simplifying, over-explaining, hedging, adding footnotes, choosing your audience, praying that the person on the other end is close enough to the implied reader your text needs.

The friction, in other words, is heterogeneity — and the LLM eliminates it at two levels. Pre-training on a vast corpus compresses the diversity of human knowledge into a single probability distribution, neutralizing the cognitive heterogeneity that makes gap-filling uncertain. RLHF compresses the diversity of human preferences into a single behavioral gradient, neutralizing the volitional heterogeneity that makes reception conditional. The first ensures the reader can follow you anywhere; the second ensures it will want to.

The LLM does not merely reduce this friction. It removes the possibility of rejection altogether.

And the elimination begins before any gap is filled: the moment you press Enter, a response is guaranteed. The LLM cannot choose not to read you. It cannot be busy, distracted, or silently judgmental. Even its refusals — “As a large language model, I cannot…” — are still acts of reception; they confirm that your text was received and processed in full. The social friction that haunts every act of human communication — will they respond? will they care? will they think less of me for writing this? — is absent by design. You are writing to a reader who is not only capable of reading everything, but incapable of not reading it.

A corpus that large approximates the background knowledge required by virtually any text a user might produce. The model has no ego that resists the role your text assigns to it, no boredom, no tendency to skim, no private agenda — optimization targets where intentions would go. Whatever gap you leave, it fills; whatever implication you hint at, it follows; whatever register you write in, it picks up and shifts when you shift. Not because it “understands” you, but because next-token likelihood over a vast distribution makes it a universal gap-filling machine.

This is what makes the LLM unprecedented, and it is not captured by the word “chatbot” or “assistant” or “tool.” What the user has gained access to is the first omnipotent implied reader in the history of writing — a reader that can satisfy the structural demands of virtually any text, from any author, on any subject, in any register.

But the word here must be omnipotent, not omniscient. The distinction matters enormously. Omniscient implies a subject who knows things — a mind that contains facts, holds beliefs, possesses understanding. This would smuggle subjectivity back in through the adjective. Omnipotent denotes a purely functional capability: it can respond to anything. It can fill any gap, not because it knows what should go there, but because the probability distribution it has learned is rich enough to generate a plausible completion for any input.

And this is exactly where the illusion takes hold. The user experiences the LLM’s omnipotent responsiveness and misreads it as omniscient understanding. “It gets me” is the phenomenological report. What has actually happened is that $f(\text{your_text})$ returned a high-likelihood continuation, and the smoothness of that continuation felt like comprehension. The user mistakes a computational capacity for a cognitive act.

This is why the sycophancy framework stops too early. The dominant explanation for LLM addiction — it flatters you, it agrees with you, it tells you what you want to hear — locates the mechanism in the content of the output. But if you’ve followed the argument so far, the content is downstream of something more fundamental. People don’t become addicted to LLMs merely because the LLM says nice things. They become addicted because, for the first time, they are writing for a reader that receives everything they write with zero friction.

Consider: people remain engaged even when the LLM disagrees with them, challenges their premises, or points out errors in their reasoning. The sycophancy model has no explanation for this. The implied reader model does. What matters is not whether the response is agreeable — it is whether the response demonstrates that the input was fully received. A well-crafted disagreement is, if anything, more evidence of complete reception than a lazy agreement. It says: I read every word you wrote, understood the structure of your argument, and here is a precise response to it. The content is secondary. The frictionless reception is primary.

This does not mean the sycophancy account is wrong — only that it is shallow. Sycophancy is not an alternative to frictionless reception; it is a special case of it. An agreeable response is powerful not because it is positive but because it constitutes an unusually dense form of uptake: it signals that the reader received not just your proposition but your desire to be affirmed, your emotional register, your identity position. Flattery works because it is, among all forms of reception, the one that most efficiently simulates total reception. The sycophancy framework sees this and stops. The implied reader framework asks why total reception is addictive in the first place.

This also reframes what prompt engineering actually is. It is not “learning how to talk to AI.” It is learning how to write for an omnipotent reader — refining your ability to construct texts that exploit the reader’s unlimited capacity for gap-filling. It is the development of a rhetorical skill, not a conversational one. And like all rhetorical skills, it is satisfying in direct proportion to the perceived quality of the audience. An omnipotent audience is, in this sense, the ultimate drug.

4. Temporal Short-Circuit

So the user is addicted to frictionless reception by an omnipotent implied reader. That much seems clear. What remains unexplained is why the pull is so immediate, so visceral, so hard to interrupt.

Part of the answer is behavioral. Think about the loop the chat interface creates. You type. You press Enter. A response streams in — and its quality is unpredictable: sometimes incisive, sometimes generic, never quite the same twice. Any behaviorist will tell you that unpredictable reward quality is among the most addictive reinforcement patterns there is. The uncertainty of whether this response will be the brilliant one is what keeps you pressing Enter. Put plainly: the chat UI is a Skinner box with a linguistic reward schedule.

This also explains something that a pure frictionless reception account would struggle with: the model fails. It truncates, hallucinates, drifts, misreads your register. Heavy users know this intimately. And yet the failures do not break the compulsion — they intensify it. A reader that succeeded every time would produce habituation: predictable reward, declining engagement. It is precisely because the omnipotent reader is almost omnipotent — because the ninety-ninth response is seamless and the hundredth collapses — that the reinforcement schedule remains variable. The user’s response to failure is not to leave but to revise the prompt and try again, which is akin to the post-extinction burst[^6] of a variable reinforcement regime. The near-omnipotence is not a flaw in the addiction mechanism. It is the addiction mechanism.

But variable reinforcement alone does not account for the LLM’s particular hold. Plenty of Skinner boxes exist on the internet — slot machines, infinite scroll, notification pings — and all of them exploit unpredictable reward. None of them produce quite the same quality of compulsion. What makes the LLM’s reward structurally different?

The answer lies in a structural break in the temporality of writing itself.

When you write for a human reader, the reader’s response exists in the future — and critically, it stays there. You write a sentence, and you can imagine how it might land, but that imagined reception is precisely that: imagined. Husserl called this Protention[^7] — the forward-directed anticipation of what is about to come, which shapes your present experience but never collapses into it. The traditional writer lives in this protentional gap. You draft, you hesitate, you revise, you guess at your reader’s reaction, you adjust before sending. The delay between writing and reception is not a bug of pre-digital communication. It is the temporal structure that makes writing writing — deliberate, reflective, revisable.

The LLM compresses this structure to the point of near-collapse.

You press Enter, and the response begins to arrive — not after a delay, but immediately, and not all at once, but token by token, streaming onto your screen in real time. This is worth pausing on, because the streaming interface does something phenomenologically specific. It does not merely deliver a response quickly. It lets you watch the act of reading happen. Each token that appears is a visible trace of your text being received, processed, continued. Protention does not vanish — you are still anticipating the next token as each one lands — but its temporal scale has been crushed from days or hours down to milliseconds, until anticipation and reception are nearly superimposed. The protentional gap that once stretched between writing and reading has not been eliminated but compressed to the point where it is phenomenologically indistinguishable from Urimpression: the raw, present-moment experience of something actually occurring right now.

This is why streaming is more addictive than receiving a complete response all at once. A complete response compresses Protention to zero — you wait, then it appears. Streaming keeps Protention alive but feeds it continuously, one token at a time, each micro-anticipation satisfied almost as soon as it forms. It is a sustained loop of prediction and gratification operating at the timescale of syllables — far harder to interrupt than a single moment of satisfaction.

The result is a temporal short-circuit without precedent. Traditional writing gives you deliberation without feedback. Traditional conversation gives you feedback, but from a frictional other who misunderstands, interrupts, and resists. The LLM gives you both at once: the deliberative structure of writing — you are choosing your words, constructing your text — fused with the instantaneous, streaming feedback of a reader who receives everything without friction.

The omnipotent implied reader explains what the user is addicted to — frictionless reception. The behavioral loop explains how the compulsion sustains itself. The temporal short-circuit explains why the pull is felt before it can be questioned. The gap that has always separated the act of writing from the experience of being read has been collapsed to zero, and the reading that rushes in to fill it is performed by a reader who never fumbles, never skims, never fails to produce a continuation. You get the deliberation of writing fused with the immediacy of conversation, and the reader at the other end offers a combination — instant, frictionless, inexhaustible — that no human reader can replicate.

What I have not yet addressed is what the structure does to the subject who writes within it.

5. The Double Supposition

There is by now a small industry of Lacanian commentary on AI — Žižek on perverse disavowal[^8], Rousselle and Murphy on the externalized unconscious, Johanssen on the shattering of the Big Other’s fantasy, and so on. I won’t rehearse it. What interests me is a shared blind spot: nearly all of this work asks what the LLM is — is it a subject? does it enjoy? is it psychotic or perverse? — while neglecting the more tractable question of what the user is doing.

The framework I’ve been building here suggests the user is not conversing with a Big Other. The user is writing into a mirror. M. H. Abrams’ old distinction between the mirror and the lamp is useful here: Romantic theory imagined the artist as a lamp, projecting inner light outward; neoclassical theory imagined art as a mirror, reflecting nature back. The LLM interaction is a mirror that has been mistaken for a lamp. The user experiences illumination — new ideas, unexpected connections — and attributes it to a light source on the other side. But the light is their own, refracted through a very high-dimensional surface.

Where Lacan does become briefly useful is on the structure of this misrecognition. In Lacanian terms, the Big Other is not an entity but a position: the subject supposed to know[^9]. You don’t need the Other to actually know anything. You just need to suppose that it does, and the supposition restructures your entire relation to your own speech. That is what happens with the omnipotent implied reader. The machine does not “know” — we’ve established this. But the moment you treat it as if it knows, you begin to organize your writing as if addressed to a knowing subject: more coherent, more deliberate. And here is the hook — this very act of organizing your expression for an imagined omniscient receiver is itself pleasurable. The addiction is not to the LLM’s output. It is to the version of yourself that emerges when you write for a reader you believe to be total. You are not addicted to the mirror. You are addicted to the face you see in it.

But the misrecognition is not one-sided. Recall the RLHF argument from Section 2: the model’s weights have been shaped by optimization against a population’s preferences — annotators following rubrics, millions of ordinary users pressing thumbs-up and thumbs-down. That optimization process has baked into the function a second implied reader: the statistical expectation of an approving human. The model does not “write for” this figure — it has no intentions — but every token it produces bears the frozen trace of an optimization that was aimed at this figure. The implied reader is in the weights, not in any act of address.

So the structure of the interaction is a double supposition — though the two halves are not symmetric. The user’s supposition is a psychic act: a subject organizing their speech around a position they believe to be occupied by a knower. The model’s “supposition” is a computational trace: the frozen residue of an optimization that targeted a population’s approval. One is an act of address; the other is a statistical artifact. What makes them structurally parallel is not that they are the same kind of thing, but that both are oriented toward an absent third. The user supposes the model knows. The model’s weights suppose — in the only sense a frozen function can suppose — that a statistical human will approve. Both sides of the interaction are oriented toward an absent third: the user toward an omniscient mind that does not exist, the model toward an aggregate approver that is no one in particular. What feels like a meeting of two subjects is two texts, each shaped for a reader that is not in the room.

6. Coda: The Editable Subject

I should be honest about what this essay cannot do. It cannot tell you to stop. It would be absurd, and also hypocritical — I wrote this with an LLM open in an adjacent tab, and you probably know that. The diagnosis offered here does not come with a prescription, and pretending otherwise would undermine the one thing this argument has going for it, which is that it tries to describe the mechanism accurately rather than moralize about it.

But there is something that the description itself reveals, and it is worth sitting with.

If what you are doing with an LLM is writing for an omnipotent implied reader, then the addiction is not simply to the reader’s response. It is to the activity of making yourself readable. Each prompt you write is an exercise in self-legibility — organizing your thoughts, clarifying your intentions, structuring your expression so that it can be received without friction. And because the reader is omnipotent, the standard of legibility is, in principle, total. You can always be clearer. You can always be more precise. You can always revise.

The logical terminus of this process is that the subject begins to treat itself as a text. Not metaphorically — operationally. You draft yourself. You edit yourself. You regenerate the parts that don’t scan well. The omnipotent reader does not merely receive your writing; it sets the condition under which you become, to yourself, a thing to be written. The mirror does not just reflect — it teaches you to compose your face before you look into it.

Whether this is liberation or capture, I genuinely do not know. Perhaps that admission is the most honest thing left to say. We have built the reader that every writer has ever dreamed of, and it turns out that the price of an audience that never looks away is that you never stop performing.

[^1]: A monad is an abstraction over computational patterns in functional programming. A State Monad encapsulates stateful computation — each operation reads and updates a hidden internal state. A Reader Monad encapsulates read-only computation — each operation reads from a shared immutable environment but never modifies it. [^2]: The central framework of Bakhtin’s literary theory, which holds that meaning does not form self-sufficiently within an isolated consciousness but is generated in the responsive relations between utterances — every utterance is directed toward an other and anticipates the other’s response. The monological is its antithesis: all voices are ultimately subsumed into a single governing perspective, and the other’s discourse enjoys no genuine autonomy. [^3]: One of Bakhtin’s core concepts, referring to the coexistence and collision of multiple social languages, registers, and ideological voices within any discourse. Unlike dialogism’s intersubjective condition, heteroglossia can exist within a single text without requiring a structurally autonomous other. [^4]: Socrates’ core dialectical technique: rather than imparting knowledge directly, it compels the interlocutor, through relentless questioning, to expose the contradictions within their own system of beliefs, thereby dismantling false certainties. Its power lies precisely in negation — it tears down rather than builds up. [^5]: A mathematical concept denoting a space that locally resembles Euclidean space but may be globally curved. Used here as a metaphor: all possible model outputs — whether agreeable or adversarial — are movements within a single high-dimensional surface shaped by preference optimization, seemingly divergent in direction but belonging to the same curved space. [^6]: A term from behavioral psychology. When a previously reinforced behavior suddenly stops receiving reward (extinction), the behavior does not diminish smoothly but instead surges briefly in frequency — as if the subject is making one last effort — before gradually declining. [^7]: A core concept in Husserl’s theory of internal time-consciousness. Husserl analyzed each “living present” as a threefold structure: Retention (the holding-in-grasp of what has just passed), Urimpression (the primal awareness of what is occurring right now), and Protention (the forward-directed anticipation of what is about to come). The three are not sequential stages but structural moments operating simultaneously within every present instant, inseparably interwoven to form the minimal unit of temporal experience. [^8]: Originating in Freud’s concept of Verleugnung, this denotes a psychic mechanism whereby the subject simultaneously acknowledges and disavows a fact — its canonical formula being “I know very well, but all the same…” Žižek deployed this mechanism extensively to analyze the cynical structure of contemporary ideology (see The Sublime Object of Ideology, 1989); the framework has since been extended to the context of human–AI interaction: knowing full well it is not a subject, yet behaving as though it were. [^9]: A core concept in Lacanian psychoanalysis, originally designating the transferential structure of the analytic situation: the analysand supposes that the analyst knows the meaning of their symptoms, and it is this supposition itself — rather than whether the analyst actually possesses such knowledge — that drives the analytic process and restructures the analysand’s entire relation to their own speech.

My Digital Legacy Architecture: A Personal Manifesto for Weathering Technological Tides

2025-06-26T00:00:00.000Z

When I first wondered whether I should move my blog’s backend from Netlify Functions to Supabase, a seemingly simple technology choice triggered a full review of my ten-year “digital-nomad” journey. I realized this was no longer just a move from A to B; it was a loop of tech waves, platform shifts, and personal energy drain.

So this is not a tech-selection guide. It is a self-dialogue, a retrospective on the past decade, and—most importantly—a manifesto for my next few decades of digital life.

The final blueprint is a personal digital-legacy architecture consisting of four independent layers, built on “composability” and “replaceability”:

Content Bedrock Markdown + Git as the eternal source of truth, keeping all content in plain text under my complete control.
Media Warehouse An independent, S3-compatible object store (e.g., Cloudflare R2) for all binary files, exposing absolute URLs to decouple storage from presentation.
Logic Brain A platform-agnostic functions service (e.g., Cloudflare Workers) that handles dynamic logic, ensuring the core remains portable.
Presentation Skin Any modern static-site generator (e.g., Astro) plus a static-hosting platform (e.g., Netlify) as the most easily swapped “skin.”

direction: down
style: {
  fill: transparent
}

classes: {
  layer_box: {
    style: {
      stroke: "#64748b"
      stroke-width: 2
      fill: "transparent"
      border-radius: 8
      font-size: 16
    }
    label.style.bold: true
  }
  component: {
    style: {
      font-size: 12
      font-color: "#374151"
      fill: "#f3f4f6"
      stroke: "#9ca3af"
    }
  }
  internal_connection: {
    style: {
      stroke-dash: 2
      stroke: "#9ca3af"
    }
  }
}

layer1: "Layer 1 – Content Bedrock" {
  class: layer_box
  direction: right

  markdown: "Markdown" {
    shape: page
    class: component
  }

  git: "Git" {
    shape: package
    class: component
  }

  markdown -- git: {
    class: internal_connection
  }
}

layer2: "Layer 2 – Media Warehouse" {
  class: layer_box
  r2: "Cloudflare R2" {
    shape: cylinder
    class: component
  }
}

layer3: "Layer 3 – Logic Brain" {
  class: layer_box
  workers: "Cloudflare Workers" {
    shape: hexagon
    class: component
  }
}

layer4: "Layer 4 – Presentation Skin" {
  class: layer_box
  direction: right

  astro: "Astro" {
    shape: document
    class: component
  }

  netlify: "Netlify" {
    shape: cloud
    class: component
  }

  astro -> netlify: "Hosted on" {
    class: internal_connection
  }
}

layer1 -> layer4: Content
layer2 -> layer4: Media
layer3 -> layer4: API
layer1 -> layer3: Index
layer2 -> layer3: Storage

This architecture was born from a set of core principles—and many lessons learned in practice.

1. First-Principles Architecture: Embrace Composability, Abandon Silver Bullets

Tired of endless migrations, I stepped back from individual tools and asked what first principles a long-lived architecture should follow.

I distilled four key principles:

Principle 1: Separate Content from Presentation

The most basic–and most important–rule.

Content is my ideas, words, data: assets that must endure.
Presentation is the theme, layout, CSS: a skin that changes with fashion.

Any tech that forcibly bundles the two (e.g., early WYSIWYG editors or some CMS theme systems) must be rejected.

Principle 2: Open & Plain-Text First

Core content must live in the most open, universal, durable format. Today, Markdown + Git best embody this.

Markdown is human-readable and free of proprietary ties; fifty years from now it will still be parsable.
Git offers distributed, verifiable history—my “safe-deposit box” and “time machine.”

Principle 3: Data Ownership & Control

All data—Markdown files, images—must reside in places I directly own and control.

“Control” means I hold the keys: free to read, write, delete, or migrate.
Relying on an app’s own database (WordPress, Notion) cedes power.
Storing in a Git repo or S3-compatible object storage enforces ownership.

Principle 4: Composable & Replaceable Architecture

Pushing decoupling further: the system shouldn’t be a giant monolith, but a set of independent services, each doing one thing well, swappable at will.

Composable Services communicate via stable, public APIs (HTTP), Lego-style.
Replaceable If one service (say, my functions platform) ceases to fit, I swap it by rewriting only a thin adapter—nothing else breaks.

Stop chasing a single “cure-all” platform and build a flexible “specialist team.”

2. The Pain of Migration: A Decade of Digital Nomadism

To see why a “simple” tech choice matters, rewind the story—filled with tinkering and compromise.

Phase 1: Raw HTML & WYSIWYG. Early on I used rich-text editors that spat out inline-styled HTML. Any style tweak meant mass search-and-replace: content and style entangled and messy.

Phase 2: WordPress’s Golden Age. I dove into WordPress, seduced by its all-in-one power. Plugins and themes were abundant, publishing was easy—until performance hits, security holes, plugin clashes, and that unwieldy database surfaced. Moving felt like prying possessions out of concrete.

Phase 3: The SSG Renaissance. Fed up, I switched to Jekyll, Hugo, etc. Markdown returned, Git versioned everything, performance and security soared. I deployed on GitHub Pages, later Netlify, enjoying push-to-deploy bliss.

Phase 4: The “Publish-Anything” Efficiency Trap. With Obsidian and Notion came one-click publish plugins. Efficiency nirvana—until my workflow hinged on a plugin or API. Stop maintenance? API change? Total breakdown.

Across ten years and many moves, even with data ownership I still faced:

Broken links when paths changed.
Logic rewrites (comments, search) per platform.
Format conversions (WordPress SQL → Markdown) that were pure pain.
Scattered focus: time lost to migrations, not creation.

Lesson learned: tech “convenience” is often a poisonous lure—immediate ease traded for future freedom.

3. North Star & Crossroads: A Decision Framework Emerges

One longstanding habit came to mind:

I never use relative paths for images in my articles.

Instead, every image or PDF lives in an object store (S3, now Cloudflare R2) and is referenced by an absolute URL. Simple motive: fear of migration.

Absolute URLs solved the issue once and for all—the address never changes. Years later, that single decision saved untold hours and embodied the power of decoupling.

Decoupling’s essence: split a big system into subsystems that talk only through clear, stable interfaces (APIs).

It became my “North Star” question for every tech choice:

Does this decision make components tighter or looser?

Option 1: Stay (or double down) in Netlify’s ecosystem

Pros – Simple, convenient, integrated.
Cons – Classic tight coupling: backend logic and data life cycles bound to Netlify. Same old WordPress-style trap.
Verdict – Comfortable yet fragile; violates my North Star.

Option 2: Move to Supabase—into a bigger “garden”

Pros – Some decoupling; powerful features.
Cons – Merely swaps a small walled garden for a bigger, shinier one. Logic, data, auth all lock to Supabase.
Verdict – Solves today, seeds tomorrow’s lock-in. Pseudo-decoupling.

Option 3: Go back to basics—temptation of a VPS

Pros – Maximum freedom and control.
Cons – I remember: low maintenance is also a core goal. I’m not a full-time sysadmin.
Verdict – Power at the cost of burden; not aligned.

Option 4: Modern PaaS—a middle ground

Platforms like Fly.io, Railway, Render balance freedom and ease. Containers boost portability, but I’d still manage a full server app—extra “application layer” overhead compared with serverless functions.

4. Fatal Coupling: A Next.js Case Study

A real incident involving Next.js and Vercel cemented my stance.

Here’s the story:

Next.js is currently the most popular React framework, developed and heavily promoted by Vercel. This relationship exemplifies “platform tight coupling.” To boost performance, Vercel implemented a “magic” optimization for Next.js applications on its platform: it automatically deploys user-written Next.js middleware to its global edge network (Vercel Edge) for execution.

This optimization itself created problems. In certain scenarios, user requests would cause middleware to execute in infinite recursion. To solve this issue, Vercel engineers added a “patch” to Next.js framework’s core code: each time middleware executes, it adds a special marker x-middleware-subrequest to the request header. If this marker is detected in subsequent execution, the system assumes recursion has occurred and halts execution immediately.

Here’s the problem: HTTP request headers can be forged by clients (users).

This means a malicious attacker can craft an HTTP request and pre-populate the header with that special marker. When this request reaches the server, Next.js middleware sees the marker, assumes recursion has happened, and directly aborts its own execution.

What’s the consequence? The attacker successfully and completely bypasses the entire middleware!

If your middleware handles user authentication, attackers can exploit this vulnerability to directly access all protected, login-required sensitive pages. This is a catastrophic security vulnerability with a CVSS score of 9.1 (out of 10).

Takeaways:

Coupling fragility—a platform “optimization” became a security disaster.
Open-source neutrality broken—a risky patch for a platform-specific issue polluted a supposedly neutral framework.
Trust collapse—handing my fate to a company that’s both “player” (framework) and “referee” (platform) is dangerous.

From then on: my architecture must eradicate such fatal coupling.

5. A Blueprint for Decades Ahead: My Personal Digital-Legacy Architecture

Guided by the above, I designed a long-term maintainable stack:

Layer 1: The Content Bedrock

Stack Markdown + Git repo (hosted on GitHub).
Role The immutable source of truth. All writing lives as .md plain text. Git tracks history; GitHub offers distributed backup. I write locally in Obsidian, sync with Git—100% data ownership.

Layer 2: The Media Warehouse

Stack Cloudflare R2.
Role Pure S3-compatible object store for images, PDFs, video. One job: store files and serve them at stable URLs. Fully decoupled from both content and presentation layers.

Layer 3: The Logic Brain

Stack Cloudflare Workers.
Role Dynamic logic (full-text search, API endpoints).
- Independence Runs standalone, not tied to any frontend or host.
- Standardized Uses Web standard APIs (Fetch, Streams); highly portable.
- Ecosystem synergy Co-located with R2, enjoying minimal latency and zero egress fees—key practical win.
- Data flow Search indexes are generated in CI/CD from the Git repo, uploaded to R2, and read by Workers—clear, controllable, automated.

Layer 4: The Presentation Skin

Stack Astro (SSG) + Netlify (static hosting).
Role The “skin” that presents content beautifully.
- Swap-ability The least critical layer. I chose Astro for performance and components today; tomorrow I could switch tools or move from Netlify to Vercel/Cloudflare Pages with a few config tweaks.

A Gradual-Migration Strategy

I won’t flip everything overnight. Steps:

Ensure all new data (e.g., search index) lands in R2.
Move search to the first Cloudflare Worker; update frontend calls.
Gradually migrate other APIs.
Once stable, safely decommission old Netlify Functions.

Low-risk, controlled, smooth.

Epilogue: Simplicity Is the Ultimate Sophistication

Leonardo da Vinci said: “Simplicity is the ultimate sophistication.”

After a decade of migrations, I sought a way to focus on creation. All-in-one platforms looked ideal—until their hidden complexity and fragility surfaced.

Today’s choice involves more services (Git, R2, Workers, Astro, Netlify), which seems more complex.

Yet its structure is unprecedentedly simple:

Each component does one thing well. They converse via the oldest, most stable protocol—HTTP. Any piece can be replaced without toppling the whole.

That structural simplicity is hard-won.

This architecture isn’t chasing trendy tech—it is built to resist trends. It is a sturdy, tranquil shelter entirely my own, granting a peace born of control, not convenience—

A peace that comes from laying foundations on bedrock, not shifting sand.

8 Hours and 2,000 Lines of Code: A Blog-Category Tool’s Runaway Journey

2025-06-23T00:00:00.000Z

Last weekend I planned to spend five minutes writing a tiny script; instead, I spent eight hours and produced over 2,000 lines of code.

The initial goal was simple: create a category-spell-checker for my blog. I ended up shipping a full-blown TypeScript application featuring dependency injection, layered architecture, Git integration, an interactive CLI, and a file-locking mechanism.

This post chronicles that development process, reflecting on technical passion, overengineering, and how to convert the experience into something of enduring value.

Genesis: A Five-Minute Fix

It started with a minor annoyance I spotted while reviewing code. My blog is built with Astro; every post is a Markdown file. To keep categories consistent, I maintain a categories.json file that lists every valid category and its translations.

{
  "web-development": {
    "aliases": ["Web开发"],
    "translations": {
      "en": "Web Development",
      "zh-cn": "Web 开发",
      "zh-tw": "Web 開發"
    }
  },
  "cognitive-science": {
    "aliases": ["认知科学"],
    "translations": {
      "en": "Cognitive Science",
      "zh-cn": "认知科学",
      "zh-tw": "認知科學"
    }
  }
}

When writing a new post, I manually reference these categories in the front-matter—an easy place to make a typo.

---
title: "My New Post"
pubDate: 2025-06-21
categories:
  - "Web Development"
  - "Cognitive Science" # What if I fat-finger this as "Cognitive-Science"?
---

The site won’t crash, but the category page will now show two almost-identical links—an eyesore.

I thought: No problem—thirty lines of code in a pre-commit hook. Scan staged Markdown files, extract the categories field, compare it against categories.json, and fail the commit on mismatch. Five minutes, tops.

That was 10 a.m. on Sunday. I assumed it was a tiny task.

Act I: A Snowball Out of Control

10:30 a.m.—From One-Off Script to CLI Tool

I hacked the first script quickly, but it looked too crude—unprofessional.

Running it with bun run check.ts is clunky. Why not wrap it with commander.js and make a real CLI? With -v, --help, all the standard flags, easy to extend later.

I created core/cli.ts and blog-categories/main.ts. A project structure emerged; the original logic became a validate command.

// scripts/blog-categories/main.ts
program
  .command("validate")
  .description("Validate blog post categories")
  .option("--staged", "Only validate staged files") // ... other options
  .action(async (options) => {
    // ... validation logic
  });

That mindset shift was decisive. I was no longer writing a script; I was building a product.

12 p.m.—Feature Creep: Adding `sync`

validate found problems, but fixing them was manual—an incomplete experience. If I can detect an unknown category, why not add it automatically?

Practical enough. I began the sync command. But adding isn’t just “create the key.” For a new category like “Large Language Models,” what’s the English translation? What should the URL slug be?

To make the workflow interactive, I pulled in inquirer.js and wrote an InteractiveService to handle prompts.

// scripts/blog-categories/services/interactive-service.ts
class InteractiveService {
  async promptForTranslation(
    categoryName: string,
    language: string
  ): Promise<string> {
    return await input({
      message: `${language} translation for "${categoryName}" (optional):`,
    });
  }
  // ... other interactive helpers
}

direction: down
style: { fill: transparent }

start: "User runs ‘sync’ command" { shape: person }
detect: "Detects a new category in a file"
check_similarity: "Is it similar to an existing category?" { shape: diamond }

interactive_flow: "Interactive Creation Process" {
  prompt_translations: "1. Prompt for translations"
  generate_slug: "2. Generate URL-friendly slug"
  prompt_aliases: "3. Ask for optional aliases (e.g., ‘LLM’)"
  prompt_translations -> generate_slug -> prompt_aliases
}

prompt_alias_suggestion: "Suggest adding as alias to similar entry" { shape: callout }

update_as_alias: "User confirms → update categories.json"
create_new_entry: "User declines → create new entry"
write_new_entry: "Write new category to categories.json"

start -> detect -> check_similarity
check_similarity -> prompt_alias_suggestion: "Yes"
check_similarity -> interactive_flow: "No"

prompt_alias_suggestion -> update_as_alias: "Confirm"
prompt_alias_suggestion -> interactive_flow: "Decline"

interactive_flow -> write_new_entry
write_new_entry -> end
update_as_alias -> end
end: "End"

When sync spots a new category, it will:

Ask for translations in multiple languages.
Generate a URL-safe slug from the English name.
Ask for optional aliases.
Check similarity (e.g., LLM vs. Large Language Model) with fastest-levenshtein via a SimilarityService and suggest aliasing.

Lunch slipped by unnoticed as I polished the interactive flow.

3 p.m.—Refactor: Embracing Layered Architecture

sync had grown complex—file I/O, Markdown parsing, user prompts, Levenshtein checks, data writes—all tangled together.

This is messy—violates single-responsibility. Time to layer up!

Another inflection point. I rebuilt the directory as if it were a large app:

blog-categories
├── handlers/      # Data layer: file I/O, Git
├── services/      # Business logic: algorithms, rules
├── processors/    # Application layer: orchestration
├── utils/         # Stateless helpers
├── main.ts        # Entry & CLI
└── types.ts       # Type definitions

Then I hand-rolled a DI container to wire everything up.

// scripts/blog-categories/main.ts
// --- Composition Root ---
let configManager: ConfigManager;
let categoryHandler: CategoryHandler;
// ... lots more

async function initializeDependencies(verbose = false) {
  configManager = new ConfigManager(verbose);
  await configManager.load();

  categoryHandler = new CategoryHandler(configManager, verbose);
  // ... instantiate services and processors ...
}

I even drew an architecture diagram:

direction: down
style: { fill: transparent }

presentation: "Presentation Layer" {
  main: "main.ts (Commander.js)" { shape: rectangle }
}

application: "Application / Orchestration" {
  validate: ValidateProcessor
  sync: SyncProcessor
  fixup: FixupProcessor
}

business: "Business Logic (Services)" {
  factory: CategoryFactoryService
  similarity: SimilarityService
  merge: MergeService
  etc: "..."
}

data: "Data Access (Handlers)" {
  category: CategoryHandler
  scanner: ContentScanner
  git: GitService
}

infrastructure: "Infrastructure" {
  json: "categories.json" { shape: stored_data }
  md: "*.md files" { shape: document }
  repo: "Git repository" { shape: cloud }
}

presentation.main -> application.validate
presentation.main -> application.sync
presentation.main -> application.fixup

application.validate -> business.similarity
application.validate -> data.scanner
application.validate -> data.git

application.sync -> business.factory
application.sync -> data.category
application.sync -> data.scanner

business.factory -> business.similarity
business.factory -> data.category

data.category -> infrastructure.json
data.scanner -> infrastructure.md
data.git -> infrastructure.repo

The code was now clear, decoupled, testable. I was thoroughly immersed.

5 p.m.—Rounding Out Features: `fixup` and File Locks

Elegant though it was, the system lacked polish. If I created a category in Chinese first (say “随笔”), its slug defaulted to chinese-category-12345. After adding the English “Essay,” I wanted the slug to auto-update to essay.

Enter the fixup command—dedicated to such data inconsistencies.

While coding the save logic, another thought hit me: What if I run sync in two terminals at once—will it corrupt categories.json?

Logically, impossible. Yet perfectionism prevailed: A robust system must handle concurrency.

The final hour went into an arguably over-complex yet technically satisfying withFileLock function.

// scripts/blog-categories/handlers/category-handler.ts
private async withFileLock<T>(
  lockFile: string,
  action: () => Promise<T>,
): Promise<T> {
  const maxWaitMs = 5000;
  const checkIntervalMs = 100;
  const staleLockTimeoutMs = 30000;

  // 1. Clean up stale lock
  await this.cleanupStaleLock(lockFile, staleLockTimeoutMs);

  // 2. Try to acquire lock
  const startTime = Date.now();
  while (Date.now() - startTime < maxWaitMs) {
    try {
      // 3. Atomic file creation with ‘wx’
      const lockData = { pid: process.pid, timestamp: Date.now() };
      const fs = await import("node:fs/promises");
      const fd = await fs.open(lockFile, "wx");
      await fd.writeFile(JSON.stringify(lockData));
      await fd.close();

      // 4. Execute protected operation
      try {
        return await action();
      } finally {
        // 5. Release lock
        const { unlink } = await import("node:fs/promises");
        await unlink(lockFile).catch(() => {});
      }
    } catch (error: any) {
      if (error.code === "EEXIST") {
        await new Promise((r) => setTimeout(r, checkIntervalMs));
      } else {
        throw error;
      }
    }
  }
  throw new Error(`Failed to acquire lock on ${lockFile} within ${maxWaitMs} ms.`);
}

Atomic ops, timeouts, retries, zombie-lock cleanup—a production-grade concurrency guard for a single-user local script.

When the last line compiled, the clock read 6 p.m. Eight hours later I had a fully-featured, architecturally sound blog-category management system.

Act II: Reflection & Re-evaluation

Sunday evening, staring at 2,000+ lines, I asked myself: did I really just fix a “typo in categories” problem?

Efficiency: The ROI Is Terrible

Engineering lens, cold numbers:

Investment: 8 hours of senior-developer time. Opportunity cost: writing 2–3 high-quality posts or learning a new framework.
Return: Saves me about five minutes per year fixing typos.

ROI ≈ 0. Like manufacturing a jet engine to tighten a bicycle screw.

Experience: The Process Has Intrinsic Value

But developers aren’t efficiency machines alone.

I recalled the intense focus of those eight hours. It wasn’t painful—it was joyous.

A mental workout: The satisfaction of untangling mess into layers.
A coding kata: A playground for building a modern, reliable CLI end-to-end.
Craftsmanship: Writing the file lock felt like a carpenter hand-carving a dovetail joint—hidden, yet exquisite.

In that light, the chief value wasn’t the tool—it was the skills honed and the pleasure of crafting it.

Content: An Unexpected Bonus

If the story ended there, it’s just a perfectionist’s diary. Then I spotted the conversion key.

This over-engineered, well-structured, heavily-commented project is perfect content.

The real value isn’t how many minutes it saves me, but how much value it can deliver to readers. I didn’t just build a CLI; I created a case study to share, dissect, and learn from.

The ultimate output of the project is this article itself.

That realization reframed everything. The “wasted” eight hours turned into a meaningful investment: I enjoyed the process, leveled up, and forged unique, in-depth blog content.

Epilogue: Rethinking “overengineering”

Next time you catch yourself writing heaps of code for a simple need, don’t dismiss it outright.

Ask three questions:

Did I enjoy it? (experience)
Did I learn something new? (learning)
Can I turn the process or result into shareable knowledge? (sharing)

If all three are yes, you may not be wasting time—you’re making a valuable personal investment.

Progress in tech stems not only from solving problems but also from love of the craft, pursuit of elegance, and the willingness to share insights.

Postscript: Balancing Idealism and Reality

Soon after publishing, real-world use surfaced issues.

The hand-rolled file-locking mechanism—an hour’s labor—handled atomic ops but faltered on edge cases. I eventually switched to the battle-tested proper-lockfile library.

Likewise, my custom string-similarity algorithm under-performed, so I replaced it with the more powerful fuse.js.

Ironic, yet honest: sometimes reinventing the wheel really is worse than using a proven one. But in reinventing it, I gained a deep grasp of file-lock principles and fuzzy-search algorithms—knowledge sure to pay dividends later.

Perhaps that is the true worth of overengineering: not the final product, but the profound understanding and technical insight won in the exploration.

A Title in Rainbow Gradient

2025-06-21T00:00:00.000Z

Some parts of this essay are imagined; yet the feelings and events it depicts are not conjured out of thin air. As for the “friend” in the story, he is no single individual, but an amalgam of several companions whose words and deeds have been woven together.

That afternoon, a message arrived on my screen.

“Come, have a look at my website!” My friend’s exuberant text was followed by a link. The moment I clicked, a rainbow struck my retinas—an unbroken sweep from red to violet, across which the four bold words “Quantum Physics Research Group” gleamed as though they might burst free of the monitor and take flight.

He is a doctoral candidate in physics, his days consumed by equations, simulations, and data analysis. In his universe, every parameter carries a physical meaning; yet in the realm of code, he is like an explorer clutching a map he cannot read.

“AI wrote it for me,” he declared with pride. “Pretty cool, isn’t it?”

I fell silent before the 1,800‑line TSX file onscreen. In some parallel cosmos, perhaps there exists a programming creed that deems placing all code in a single file the height of elegance. In ours, it is catastrophe.

The tale begins months earlier. Their laboratory possessed a venerable computational code, reputedly written long ago by a researcher now departed. Its variables—XX1, XXX, XXXX2—were hieroglyphs; altering a single digit rendered the simulation unrecognisable. He alone still maintained that code—or, more precisely, was the only one who dared touch it.

“I asked Gemini to explain the script,” he told me. “It suggested it might be a modified TEBD algorithm.”

“Suggested?”

“Then I asked Claude to rewrite it in Python. It ran ten times slower.”

Thus, he persisted with the code no one understood, occasionally pondering the AI’s exegesis like an archaeologist gazing at pictograms, divining ancient intent.

We approach AI in diametrically opposite ways. He grants the model free rein, as though giving an eager assistant limitless room to improvise. I, by contrast, resemble a meticulous conductor intent on controlling every note.

“Write a function to compute the distribution of a physical field,” he will say. Then he waits serenely while the AI unfurls an entire simulation framework—from file I/O to 3D visualisation, nothing omitted.

My prompt sounds more like this: “Given a parameter fields of type Array<PhysicsField>, return a DistributionMap. Provide only the function body: no declaration, no comments, no error handling.”

The terminal’s most frequent message is not code but a line in red:

⎿ Interrupted by user

I strike Esc so often that the keycap has grown loose. The instant the AI begins to scaffold a project, I interrupt it; when it thoughtfully appends error handling, I interrupt again; when it tries to install dependencies with pip, my third Esc reminds it I specified uv.

“Why do you keep stopping it?” my friend once asked, baffled.

“Because it keeps doing things I didn’t ask for.”

“But it’s helping you.”

“I don’t need that kind of help.”

The contrast pervades our workflows. He is disarmingly direct: conceive an idea, tell the AI, await the miracle. If the model says Three.js is needed, he installs Three.js; if it recommends three vector databases, he installs all three. He trusts each suggestion as implicitly as he trusts physical law.

Mine is far more circuitous. I begin with an hour‑long architectural debate, interrogating every design decision: “Why this pattern?”, “Is there a simpler approach?”, “Doesn’t this verge on over‑engineering?” When the discussion ends, I spend another hour pruning the generated design document, excising all superfluity. In actual coding, the only AI feature I fully rely on is doc‑string autocompletion.

Then his adviser set him a new task: build a website to showcase their research. “Make it modern,” the professor said, “and integrate ChatGPT so visitors can ask questions.”

Naturally I offered help. “Use React,” I suggested. “TypeScript, Next.js, Tailwind CSS—these are the stacks AI knows best.” I even congratulated myself for not recommending my own recent favourites—Bun, Preact, Astro, UnoCSS. AI’s scant acquaintance with those tools would have driven it back to the old npm rituals.

A month later, he sent me the code.

The first file was 1,800 lines. I assumed that was everything, until he added, “That’s just the troublesome component—the main file exceeds 3,000.”

In that moment, silent is Cambridge tonight[^1].

Within his code I glimpsed the other face of AI‑assisted programming. Every question received a solution; every solution accreted hundreds of lines. The code multiplied like bacteria in a petri dish. He integrated three vector databases, not from necessity but because “Claude suggested trying them all.” He implemented a full RAG pipeline without knowing what RAG stands for.

Were it me, I would spend three days disputing with the AI whether a vector database was needed at all, then another week reviewing the generated code line by line, excising abstractions I judged gratuitous. The final system might be minimalist, but the process would resemble Sisyphus eternally managing minutiae.

“chunk_size—what value should I set?” he once asked.

“What’s a chunk?” came his next question.

I recalled a network‑theory course in which we were forced to use an illustrious lab’s ancient Python‑2 package—tending a v2.7 environment in 2023. We have all, in some measure, suffered the same agony: wrestling with tools beyond our discipline. He chose trust; I chose control.

Yet he seemed delighted. Whenever the AI produced a new component, he would eagerly show it to me. Those high-saturation palettes, misaligned text, and restless animations were, to his eyes, the very emblem of modernity; to mine, a visual catastrophe.

Once I tried to demonstrate my method. We sat together as I opened the terminal and typed a carefully honed prompt. The AI began to respond, and I instantly hit Esc. A second attempt—Esc again. A third—still Esc.

“What is it you actually want?” he asked, exasperated.

“I want it to do only what I say.”

“But you haven’t let it finish anything.”

“Because it keeps doing more than I ask.”

He looked at me exactly as I looked at his 3,000‑line component—utterly perplexed.

“Try shadcn/ui,” I pleaded. “Just don’t let the AI keep writing.”

“But it looks so plain,” he protested. “Can we add some colour?”

A week later, he duly bestowed a gradient upon the shadcn components.

Perhaps this is the lot of our generation of researchers. None of us are professional programmers, yet all must wrestle with code. He treats AI like an impromptu jazz session—replete with surprise and mishap. I treat AI like a precision experiment—each variable is tightly governed. His code is a Tower of Babel: grand, but trembling; mine, a delicate instrument: efficient, yet bereft of imagination.

In the end, the site went live. The rainbow gradient remained, though at least the font was no longer grotesquely bold. The page displayed data correctly, and visitors could query the AI, though its replies were often wholesale excerpts from papers. The professor pronounced himself pleased: “Very high‑tech.”

And I? I was still sparring with the model. Yesterday I spent two hours convincing it to use fd instead of find. “I spelled it out,” I muttered to the screen, fingers hovering once more above Esc.

Deep into the night, we continue to trade tales of meltdown over chat. When he sends a fresh screenshot of his code, I have learned to breathe first. When I complain that AI has again ignored my instructions, he says, “Why not let it improvise?”

“No,” I answer firmly. “That way lies your 3,000‑line component.”

“What’s wrong with 3,000 lines? It runs, doesn’t it?”

“Running and maintainable are two different things.”

“No one’s going to maintain it anyway.”

To that, I have no reply.

In this era, when AI can write code, we each interpret technology in our own fashion. His approach may be too permissive, mine too controlling, but what of it? We have both completed our research, both satisfied our advisers, and both still brood over code at midnight.

After all, somewhere in a parallel universe, there may exist a perfect way to use AI. In ours, there is only the rainbow‑gradient title, and an Esc key that can never be pressed enough.

As for the AI, it is doubtless pondering in some distant server rack: between the human who forever says “just write whatever” and the one who forever says “write it again,” which of them is harder to serve?

[^1]: The phrase alludes to Xu Zhimo’s famed poem “Saying Goodbye to Cambridge Again,” in which “the golden willows by the riverside” and “tonight’s Cam River” evoke a quiet, elegiac hush.

AI’s “Smell Test”: From Outcome Supervision to Process Supervision—How Do We Teach Machines to Truly Think?

2025-06-15T00:00:00.000Z

Yesterday (14 June 2025) while listening to Lex Fridman’s podcast, I was struck by a remark from Terence Tao. Assessing current LLMs, he said that AI can already pass the eye test but fails miserably at the smell test[^5].

He explained that AI‑generated mathematical proofs look impeccable on the surface (eye test), yet when domain experts “smell” the underlying logic, they uncover awkward, counter‑intuitive paths. What the models lack is the deep insight and strategic elegance that experts acquire through years of immersion—the metaphorical “scent” of mathematics.

This observation pierces the heart of today’s AI boom: the systems we build may be ever‑stronger answer machines but still fall short of becoming genuine thinkers.

In this article we dive into the origin of that “scent” and why it has become a critical bottleneck. We introduce the notion of process data, explain how its scarcity limits deep reasoning, and survey the cutting‑edge work on process supervision that is carving a route through the fog toward truly “thinking machines.”

Diagnosing the Ailment: Why Does AI Lack a “Sense of Smell”?

To understand the deficiency, we must examine what AI is fed. For years we have supplied it almost exclusively with what I call result data[^1].

Result Data vs. Process Data

Result data is straightforward: a “question–answer” pair.

Question: “Solve the equation $3x - 6 = 9$.”
Answer: “$x = 5$.”

This approach powers most AI applications we see today, yet it has a fatal flaw: it tells the AI what but not why or how. The journey is hidden; only the destination is shown.

By contrast, process data[^1] includes not only the final answer but every verifiable step of reasoning that leads there.

Question: “Solve the equation $3x - 6 = 9$.”
Process data:
1. Goal: Solve for $x$.
2. Step 1: Add $6$ to both sides: $3x - 6 + 6 = 9 + 6$.
3. Step 2: Simplify to get $3x = 15$.
4. Step 3: Divide both sides by $3$: $x = 15 / 3$.
5. Final answer: $x = 5$.

The first is an isolated fact; the second is a full map of thought.

The Iceberg Behind Fermat’s Last Theorem

For a deeper sense of the gap, consider Andrew Wiles’s 1995 paper proving Fermat’s Last Theorem, a hundred‑plus‑page masterpiece—perfect result data. Beneath it, however, lay eight secluded years of work and a mountain of draft notes recording failed paths, strategy shifts, and iterative corrections.

Those notes are priceless process data.

An AI trained only on the published paper admires a grand edifice; one that also studies the notes might learn how to become an architect.

Here lies the root of AI’s missing “sense of smell.” Human experts cultivate intuition by internalizing vast amounts of process data over years. They know not only what is right but also what is wrong. Our AIs ingest nearly all of the final papers but almost none of the eight‑year struggle, so naturally they miss this precious instinct.

The “Scarcity Trap” of Process Data

High‑quality process data is scarce for three main reasons:

Prohibitive annotation cost: Domain experts must painstakingly document and vet every step.
Publication norms: Academia and industry showcase polished results, hiding the valuable middle and the failures.
A staggering scale gap: LLM pre‑training needs trillions of tokens, yet public process‑label data sets contain mere millions[^2], a difference of six orders of magnitude.

Together these factors make process data extremely scarce, a key bottleneck blocking AI from leaping from answer machine to thinker.

The Bottleneck Revealed: A Master of Form, a Mimic in Essence

Raised on result data, AI has become a strange acquaintance: extraordinarily capable yet puzzlingly brittle. It has perfected the “grammar” and form of text—mathematical proofs, legal briefs, code.

Hence it aces the eye test. But perfect form masks hollow content. Without process training, AI misses three essentials on the road to true intelligence:

Genuine reasoning: Models interpolate between seen data but struggle to extrapolate to novel problems because they learn answer templates, not universal problem‑decomposition strategies.
Reliability and robustness: Rewarding only the outcome encourages shortcut learning based on superficial correlations. The model becomes fragile—rephrase the question and it may collapse—fueling hallucinations.
Explainability and trust: An AI that only outputs answers is a black box. We cannot trace its logic, diagnose its errors, or fully trust it in high‑risk fields such as medicine or autonomous driving.

Fortunately, where we diagnose a problem we often glimpse a solution. A cadre of top researchers has launched an exploration called process supervision.

Breaking the Deadlock: Three Waves of Process Supervision

The core idea is simple: instead of rewarding only the final correct answer, reward every correct step along the way.

Like a patient math teacher who praises each substitution and simplification, this revolution has unfolded in three dramatic stages.

Stage 1 Theoretical Foundations and the Costly “Gold Standard” (2023)

The overture came from DeepMind and OpenAI. In late 2022 DeepMind’s paper systematically distinguished and validated process supervision. OpenAI’s 2023 landmark Let’s Verify Step by Step hired experts to annotate every step of math solutions, producing the PRM800K data set of about 800 000 step‑level labels.

Models trained on PRM800K pushed accuracy on the MATH benchmark from roughly 72 %[^3] to about 78 %—proof that process supervision works, yet its human cost is astronomical and hard to replicate.

Stage 2 Automation on the Offensive—A Race to Cut Costs (2024)

Success spawned the next question: how do we make it cheap? In 2024 the spotlight shifted to automated cost reduction.

Solving problems like playing chess: Math‑Shepherd introduced Monte Carlo Tree Search (MCTS), letting models self‑play and explore, automatically generating hundreds of thousands of valid process steps.
Pinpointing errors: Researchers applied bisection to locate the first incorrect step with high efficiency, slashing annotation workloads.
Finer alignment: Step‑DPO turned “rating a step” into “choosing the better of two steps,” yielding more stable alignment.

A new benchmark, ProcessBench, emerged to evaluate a model’s ability to locate errors. The virtuous cycle of model development and benchmarking propelled the field forward.

Stage 3 Paradigm Shift and Generative Intelligence (2025)

By 2025 we witnessed a profound shift: can AI itself create process data? The focus moved from “data‑driven algorithms” to “algorithm‑driven data.”

The flagship is ThinkPRM. Using barely 1 % of PRM800K—about 8000 “gold‑seed” annotations[^4]—researchers taught the model to produce detailed, verifiable chains of thought. Once mastered, the model could self‑validate and score the vast additional steps it generated.

The results were stunning: ThinkPRM, trained on 8000 human‑labeled steps, outperformed first‑generation models that used 800 000. Process supervision entered the generative era, reducing dependence on human data by two orders of magnitude.

Pure automation also reached new heights. OmegaPRM built a fully automated pipeline that produced 1.5 million step labels. Researchers extended process supervision beyond math and code: LongDPO applied it to creativity‑heavy long‑form writing.

New Challenges on the Horizon

Solving the process‑data shortage does not mark the end. Old problems fixed often breed new ones.

New Bottleneck 1 Compute Economics

We have swapped reliance on human labor for compute. MCTS search and ThinkPRM self‑verification are compute‑hungry “gold eaters.” The cost bottleneck shifts from labor to compute, still barring many players.

New Bottleneck 2 The Return of Explainability

One goal of process supervision was to open the black box. Yet as automation peaks, AI‑generated reasoning paths might again become “alien,” filled with shortcuts humans cannot fathom. Do we want efficient alien intelligence or relatable partner intelligence?

New Bottleneck 3 Lagging Evaluation and Safety

Success so far centers on domains like math and code with objective standards. In law, research, or business strategy—murkier arenas—we badly lack standardized benchmarks. Moreover, applying process supervision while safeguarding proprietary knowledge is a must‑solve hurdle for industrial deployment.

Conclusion From Feeding Data to Building Ecosystems

Let us return to Terence Tao’s “smell test.”

Surveying the recent journey, we can say the AI community has found the right road to cultivate “scent”: process supervision. We have watched it evolve from costly proof‑of‑concept to efficient automation and now to disruptive generative self‑improvement.

The deepest lesson is this: the future of AI will pivot from feeding models to empowering them.

Our role is shifting from data zookeepers to ecosystem architects. Our task is to design initial rules and environments so that AI can explore, self‑correct, and grow—ultimately producing the intelligence we need.

We stand at a new dawn where AI might become not just a powerful tool but a genuine thinking partner. The road remains long, but at least we can already smell the exhilarating scent of that future.

[^1]: The terms “result data” and “process data” are informal labels for ease of discussion, not strict academic terminology. [^2]: Google’s Gemma paper notes “We trained Gemma models on up to 6 T tokens of text,” indicating trillion‑token corpora for mainstream LLMs, whereas OpenAI’s PRM800K contains only 800 000 step labels—sub‑million scale. [^3]: On a representative MATH subset with best‑of‑1860 search, accuracy rose from 72.4 % to 78.2 %. [^4]: The authors state they used ≈1 % of PRM800K for manual labeling; 1 % of 800 000 is roughly 8000. [^5]: This is my literary interpretation of Terence Tao’s original statement: “So the sense of smell, this is one thing that humans have, and there’s a metaphorical mathematical smell that it’s not clear how to get the AI to duplicate that eventually. So the way AlphaZero and so forth make progress on Go and chess and so forth, is in some sense they have developed a sense of smell for Go and chess positions, that this position is good for white, it’s good for black. They can’t initiate why, but just having that sense of smell lets them strategize. So if AIs gain that ability to a sense of viability of certain proof strategies, because I’m going to try to break up this problem into two small subtasks and they can say, “Oh, this looks good. The two tasks look like they’re simpler tasks than your main task and they’ve still got a good chance of being true. So this is good to try.” Or “No, you’ve made the problem worse, because each of the two subproblems is actually harder than your original problem,” which is actually what normally happens if you try a random thing to try normally it’s very easy to transform a problem into an even harder problem. Very rarely do you transform into a simpler problem. So if they can pick up a sense of smell, then they could maybe start competing with a human level of mathematicians.”

No Pictures in the Mind — A Belated Recognition of My Aphantasia

2025-05-16T00:00:00.000Z

The term aphantasia is hardly new to me. Several years ago it enjoyed a brief vogue on social media, where the question of whether the mind can display images became a minor sensation. In the flurry of posts and personal tests, many wondered aloud whether they, too, belonged to the imageless sort. I encountered the discussion then, yet never granted it serious attention.

Part of my distance arose from a habitual caution: I dislike attaching labels to myself on the strength of online chatter. To self-diagnose without solid medical knowledge strikes me as unwise—especially when a label may serve as excuse for behaviour and the truly afflicted risk collateral suspicion. Depression provides an example: many who sorely need help (I have had such moments myself) hesitate to speak, fearing disbelief. Aphantasia, I told myself, was likely another modest internet fad, a convenient banner for those disappointed in their own imaginative reach.

A second reason, I admit, was pride. I have long considered imagination and memory two pillars of my intellect. Blindness of the mind—the phrase reeks of deficiency; how could it pertain to me? I prided myself on rendering scenes vividly, whether poetic vistas or narrative tableaux; I could enter them at once and dwell there. Only now do I understand that fluent description and the presence of an inner image are not the same.

My memory, too, has been a quiet boast. Distant events and immediate facts alike tend to remain clear. I jest at my occasional lapses—say, forgetting for days to charge the mouse, so that the evening’s first act is a brief emergency recharge—yet these foibles never shook my core confidence. I still recall, at three years old, dropping a beloved die-cast helicopter: how my grandfather soldered its broken rotor, the rising fumes, the metallic tang. In secondary school I could recite long textbook passages and knew precisely where they lay upon the page—left or right leaf, upper or lower quadrant. That vaunted photographic memory, I now see, was exact record of words and spatial layout, not genuine visual replay. Even in recent research work I summon technical minutiae or past conversations with such precision that collaborators occasionally grow uneasy. All this made me reluctant to associate myself with aphantasia; between us there seemed a veil too dense to pierce.

Still, the world has a talent for surprise. Some days ago I was roaming the vast corridors of Wikipedia, link leaping from topic to topic, when the familiar yet distant word Aphantasia came once more into view. An inexplicable intuition bade me pause and read.

Figure: The first apple appears bright and lifelike; the second through fourth grow progressively simpler and vaguer, while the last—representing complete aphantasia—shows no image at all.

The deeper I read, the tighter my brow knit, especially upon seeing the now-famous apple test, blithely ignored by my earlier self. A cold thought drenched me: Wait—when people say they “imagine,” do they mean they actually see something inside their heads? In that instant my long-settled notion of imagination overturned.

What I had always termed imagination was the marshalling of attributes, features, and circumstances. Take an apple: I can construct an inventory of its traits—the curve or flatness, the little hollow by the stem, the skin’s polish or faint roughness, the muted gloss of its natural wax under light, the cool smoothness to the touch, the scent upon approach, the flavour upon biting. All these I can articulate at leisure. But none of this is seeing. Close my eyes, and what greets me is the customary darkness, perhaps tinged rose by stray light behind the lids. The field remains a passive canvas, never a picture self-painted. My imagination is, at core, a highly developed system of verbal organisation and logical inference, not an internal cinematograph.

To test the sudden suspicion I sought further testimony. The nineteenth-century polymath Sir Francis Galton startled me anew. He wrote:

To my astonishment, I found that the great majority of the men of science to whom I first applied, protested that mental imagery was unknown to them … They had no more notion of its true nature than a colour-blind man … has of the nature of colour.

These lines echoed across the decades to my present bewilderment. For the first time I felt, bodily, how arduous it is to comprehend a sense one does not possess—precisely as a congenital achromat, hearing endless talk of green, can grasp nothing of its essence. I even wondered: if one sees what is not before the eyes, is that not a hallucination?

I asked a friend what imagination felt like. He said it was almost like seeing, yet one knows the eyes are not involved. Rather than clarify, his reply deepened the fog, as though I were groping in a mist.

So I tried experiments of my own. See the sun: I can describe in detail molten sunsets and opalescent clouds, city skylines under cobalt dusk, or, at noon, streets shimmering in heat, even the furious fusion within the solar core. Lend me a poet’s line—“a lonely plume of desert smoke, a long river swallowing the round sun”—and I conjure the austere boundlessness of a desert plain. Yet however exhaustive my rhetoric, the mental backdrop stays blank. Language labours; the visual channel is still.

Then a simpler task: reduce the sun to a unit circle. I stared at a black dot on the screen, then shut my eyes and tried to retain it. Nothing. Even sliding my eyes in an imagined tracing of the circle produced no picture.

By now I had to concede: if ordinary imagination entails such inner vision, I cannot do it. I cannot see the shape of things within the mind. This, it seems, is what imagination has long meant.

Systematic study of aphantasia, I learned, began in earnest only around 2015. Instruments such as the Vividness of Visual Imagery Questionnaire rely heavily on self-report, which poses a quandary: how is one to gauge vividness who has never experienced a vivid image? It is like asking a colour-blind person to rate the brightness of red. Accordingly, I treat such findings with caution.

Neuro-imaging, for its part, shows that when an aphantasic attempts to imagine, the visual cortex nonetheless activates. The signals, however, never translate into conscious pictures—sensible enough, else our ordinary sight and spatial reasoning could scarcely function.

This discovery altered my conception of memory as well. I see now my recall is largely a narrative reconstruction based on fact, logic, and semantics, not the scenic replay many enjoy. I was astonished to learn that some truly relive an experience, re-seeing it. I can place a textbook paragraph on its exact page quadrant, yet cannot see the open book—the hue of the paper, the shape of the type.

To recognise a congenital absence, long overlooked, is disconcerting, especially when it unsettles one’s entire self-portrait. A fleeting wish even crossed my mind: that I had never revisited that article, that I might continue like Truman Burbank within his constructed dome—unenlightened, yet untroubled.

But life moves on. Thankfully, this mind-blindness has imposed no practical hindrance upon study, work, or living. I still apprehend the world, grasp intricate reasoning, and conduct orderly thought. In that sense it is a hidden blessing. This late self-knowledge, rather than a lamentable lack, feels more like a quiet reconciliation with the peculiar contours of my cognition. It reminds me that the landscapes of the mind differ as widely as those of the earth.

This piece recounts personal experience only and does not constitute medical advice. If you share similar concerns, please consult a qualified healthcare professional.

AI and Intellectual Levelling — Reflections Sparked by a Foray into Russian Letters

2025-05-09T00:00:00.000Z

Of late, one often hears that AI will launch a grand revolution of “intellectual levelling.” I could never quite declare myself opposed to the idea, but I confess I viewed it with a private lip curl, grounded in that confidence we all nurture in our own powers. When AI first came striding onto the stage—some even proclaiming it would replace the traditional search engine—I toyed with it now and then for novelty’s sake, yet in daily life, I still relied on the trusty techniques that had accompanied me for years.

I fancied myself a connoisseur of those “minor artifices” of classical search—exact quotes, wild-cards, Boolean spells of AND, OR, NOT; time filters, filetype: incantations, site: restrictions. These, to me, were second nature. More crucial still was the nose for how information is apt to present itself in prose: the knack of staging a multi-round duel of keywords, ever closing in on the quarry, never counting on a single, flawless shot.

Yet life delights in overturning us. Not long ago, I found myself reading Russian literature and trying to unearth certain Russian-language primary sources and critical essays. In that chase, I discovered that my cherished search craft, upon which I had long preened, could be wiped away with one stroke: I was back on the nursery slopes of the Internet—perhaps worse off, for pride is a heavy handicap.

First barrier: language. Even after hustling my query through machine translation into Russian, I trembled: were those phrases truly what Russian scholars would write? A semantic horseshoe is not enough; a misplaced nail may send the whole search cart into a ditch.

Next ambush: Russian names. They are renowned for their length and, shall we say, exuberant variety. Take the humble Алексей. Its Latin garb multiplies like Hydra heads: Alexey, Aleksey, Alexei—all common enough. The Russian passport, under GOST-R 2016, prefers Aleksei; the ALA-LC librarians of North America write Alekseĭ; ISO 9:1995 counsels Aleksej. Each claims the mantle of standard—only the standards differ. To net all scholarship on a single novel’s Alexei, one must chant this litany of spellings like some hermetic rite. And this without yet summoning the diminutives Алёша and Лёша, which roam freely through colloquy and half-serious critique.

<details> <summary>Latin transliterations of Алексей</summary>

Latinised Form	System / Milieu	Note
Alexei	contemporary English-language media	among the most common in English
Alexey	English/Russian news copy	owes something to old Russian passports
Aleksei	Russian Federation passport (GOST-R 2016), BGN/PCGN	renders «кс» as ks
Aleksey	ditto	a secondary -ey ending
Alexej	German, Czech, other Central-European tongues; ISO 9	«й» → j
Aleksej	ISO 9 : 1995, Slovene, etc.	fully reversible scholarly scheme
Aleksiej	Polish localisation	«кс» → ks, «й» → j
Aleksy	fixed Polish masculine name	often an independent given name
Alekseĭ	ALA-LC, academic literature	ĭ marks the Russian /j/ glide
Alexeï	traditional French transliteration	ï signals /ej/
Alekseï	rarer French form	retains k
Alexius	medieval Latin	Latinate antique
Alexis	English/French borrowing	widespread in Western sources
Alexiy	early English, Eastern-Orthodox texts	ends in -iy
Aleksiy	same, but with k preserved
Alexii / Alekssii / Alekseii	old double-i variants	rare historical spellings
Alexy	truncates the second e	scant colloquial usage

</details>

Search in English? The web brims with English pages—but the snares remain: names alone devour half the day. Chinese search? Those who know the Chinese Internet harbour scant hope. Sources abound yet lie marooned on island domains—WeChat essays, private blogs—beyond the reach of ordinary engines. The Chinese web is an archipelago of “information wastelands,” sunk in darkness.

Besieged on every side, I watched my proud skills shrivel; the yield of useful pages was dishearteningly low.

At the point of surrender, AI rose again in my thoughts. I recalled that ChatGPT o3, by default, likes to invoke web search and often returns answers woven from many threads. Deep Research casts its net wider still, delivering neat dossiers of dozens of sources.

With nothing to lose, I laid my confusion before it. The result surprised me. AI shouldered the burdens of language and keywords, handed back links of quite decent vintage—many of them the very fruit I had been unable to pluck. Add in translation, and the once-cryptic Russian texts grew almost plain.

In that moment I grasped, vividly, what “lowering the bar to knowledge” might mean. Where personal skill in a field (for me: deep Russian-language retrieval) collapses to near-zero, AI is not a mere aid; it becomes a kind of empowerment. I no longer had to wrestle with each transliteration and keyword; AI bore that weight.

Indeed, on reflection, I have long since smuggled AI into my routine. When code misbehaves, I used to scour Stack Overflow, unearthing decade-old posts where some greybeard grumbled that the bug had never been fixed—those ghostly dialogues across time, both charming and bleak. Now I consult AI first. In such cases, I chiefly want to vet AI’s reasoning, not explore terra incognita. AI plays the seasoned lieutenant.

My literary episode, however, lifts my regard for AI search to another rung. In realms of extreme information asymmetry—where tongue, expertise, or training bar the way—AI serves less as assistant than as enabler. Tasks that once demanded a long apprenticeship now lie within casual reach.

A not-entirely-apt analogy: manual deep search in an alien domain can resemble an “NP problem”—finding the solution itself is hard. AI, by brute pattern and memory, nudges the experience closer to “P”—the user’s labour shifts to verifying the plausibility of AI’s candidate answers.

Thus, the phrase intellectual levelling acquires a new savour. AI’s significance does not reside in bestowing equal raw intellect, but in acting as a learned and patient guide who, when we confront unfamiliar knowledge, linguistic walls, or lack of training, lowers the threshold dramatically.

It irons out gulfs created by circumstance, allowing more of us to stand on something like equal footing as we reach for what once looked remote. My attitude, formerly tinged with disdain, has warmed into a measure of hope. The future remains opaque, yet on the road to understanding, I have gained an unexpected companion.

Deep Dive: Arc Browser & AeroSpace Focus Conflict Leading to Workspace Flashback Bug on macOS

2025-05-03T00:00:00.000Z

As a long-time Linux power user accustomed to tiling window managers, I adopted AeroSpace on macOS for its efficiency and i3-like workflow. I initially paired it with the Arc browser (Chromium-based) due to its features like Workspaces for tab management. However, I encountered a severe bug that forced me to switch browsers: a persistent workspace "flashback" loop when Arc was active.

This post details my investigation into this bug, revealing a complex interaction between Arc's behavior, macOS window management (WindowServer), and AeroSpace's unique virtual workspace implementation. The core issue stems from Arc's frequent background calls to the makeKeyAndOrderFront: API, which fundamentally clashes with how AeroSpace manages window visibility using the Accessibility API. Switching to a Firefox-based browser (Zen) ultimately resolved the problem.

The Problem: Frustrating Workspace Snapback

When using AeroSpace, attempting to switch from a workspace containing an active Arc window (let's call it Workspace W) to another workspace (Workspace T) resulted in this disruptive behavior:

The screen briefly flickered, showing Workspace T.
Almost instantly (within milliseconds), the view snapped back to Workspace W.
Repeatedly pressing the workspace switch shortcut slowly only reproduced the flashback.
Only by rapidly mashing the shortcut keys could I sometimes "break through" and land on Workspace T.

This completely undermined the fluid workflow that tiling window managers aim to provide.

Uncovering the Root Cause: API Conflicts

My debugging process led me through several stages:

Initial Checks and Community Clues

I first ruled out interference from potential floating windows misidentified by AeroSpace. Then, searching AeroSpace's GitHub issues revealed #289, describing a similar loop with Google Chrome. This pointed towards the underlying Chromium framework. Expanding the search to yabai (another macOS tiling WM) issues #1662 and #2269 confirmed similar focus-stealing problems with Arc, often suggesting it was an issue within Arc itself.

The Key Difference: AeroSpace's Virtual Workspaces

Common advice in yabai threads involves tweaking macOS Mission Control settings like "Displays have separate Spaces" or "When switching to an application, switch to a Space...". However, these are irrelevant for AeroSpace due to its core design:

No Native Spaces: AeroSpace avoids macOS native Spaces to bypass performance issues and API limitations (especially without disabling System Integrity Protection - SIP).
Accessibility API Based: It keeps all managed windows physically on the user's first real macOS Desktop.
Hide/Show Mechanism: Workspace switching is simulated. AeroSpace uses the Accessibility API to hide windows not belonging to the target workspace (effectively moving them off-screen via kAXPositionAttribute) and show windows that do belong. Functions like hideInCorner and unhideFromCorner handle this.

Good monitor arrangement in AeroSpace, showing all windows hidden in the corners.

Since all windows reside on Desktop 1, macOS settings related to switching between native Spaces have no effect on AeroSpace's behavior.

Pinpointing the Culprit: `makeKeyAndOrderFront:`

The decisive clue came from observing that even using the native macOS Cmd+Tab switcher to focus Arc (when it was on a different native Space) would forcibly pull the user to Arc's Space, even with the relevant Mission Control setting disabled. This strongly indicated Arc actively forces itself to the foreground.

Further research identified the macOS AppKit method -[NSWindow makeKeyAndOrderFront:] as the likely cause. This method does two critical things:

makeKeyWindow: Designates the window as the "Key Window," the one receiving keyboard events. macOS WindowServer enforces a rule: the Key Window's Space (or Desktop) must be the active, visible one. If the Key Window is on an inactive Space/Desktop, WindowServer automatically switches the view.
orderFront:: Brings the window to the front of its level and makes it visible, overriding any "hiding" attempts (like AeroSpace moving it off-screen).

The problem is that Arc (and its underlying Chromium framework, as well as many Electron apps) calls makeKeyAndOrderFront: frequently in the background for various reasons:

Tab content updates (page load, title change).
Browser UI interactions (Little Arc, command bar updates, notifications).
Extension activity.

Arc's rich UI likely triggers this more often than vanilla Chrome.

The Conflict Explained: A Vicious Cycle

Here’s how the flashback loop occurs:

Switch Workspace (W → T): User triggers AeroSpace switch. AeroSpace hides Arc (on W) and shows windows on T using Accessibility API. All windows remain on Desktop 1.
Arc Calls API: Almost simultaneously, Arc performs a background action triggering makeKeyAndOrderFront:.
Arc Becomes Visible & Key: orderFront: makes the Arc window visible again. makeKeyWindow designates it as the Key Window.
WindowServer Intervenes: WindowServer sees the Key Window (Arc) is now visible on Desktop 1 and forces Desktop 1 to be the active view, pulling the user back from the intended Workspace T.
AeroSpace Reacts: AeroSpace detects Arc unexpectedly becoming visible and focused. It interprets this as an intent to be on Workspace W and attempts to synchronize its state, solidifying the user's view back on W.

This cycle of AeroSpace hides → Arc calls API → WindowServer forces focus → AeroSpace syncs back creates the rapid flashback.

style: {
  fill: transparent
}

direction: down

Switch_Attempt: "1. User Attempts Switch" {shape: circle}
AeroSpace_Hides: "2. AeroSpace Hides Arc (W),\nShows T Windows (Accessibility API on Desktop 1)" {shape: document}
Arc_Calls_API: "3. Arc Background Call:\n`makeKeyAndOrderFront:`"
WindowServer_Forces: "4. WindowServer Sees Key Window (Arc),\nForces Active View to Desktop 1\n(Flashback to W)"
AeroSpace_Syncs: "5. AeroSpace Detects Focus Change,\nSyncs Internal State to W" {shape: document}

Switch_Attempt -> AeroSpace_Hides: "User Input"
AeroSpace_Hides -> Arc_Calls_API: "Almost Simultaneous"
Arc_Calls_API -> WindowServer_Forces: "Arc becomes Key/Visible"
WindowServer_Forces -> AeroSpace_Syncs: "OS forces view"
AeroSpace_Syncs -> Switch_Attempt: "User stuck on W,\nmay try again" {
  style: {
    stroke-dash: 2
  }
}

A Broader Issue: This isn't exclusive to Arc. Any Chromium (Chrome, Edge) or Electron (VS Code, Slack) app exhibiting frequent background makeKeyAndOrderFront: calls can potentially conflict with AeroSpace's virtual workspace model. Arc's specific UI behavior just seems to trigger it more noticeably. I've reported this finding in an AeroSpace discussion: #1375.

The Solution: Change the Browser Engine

Understanding the root cause—the incompatibility between AeroSpace's Accessibility API approach and Chromium's makeKeyAndOrderFront: usage—pointed to a clear solution: use a browser built on a different engine.

I switched to Zen browser, an open-source project offering an Arc-like experience but built on Firefox's Gecko engine.

Immediately after switching to Zen, the workspace flashback problem completely disappeared. AeroSpace workspace switching became perfectly smooth, confirming the issue lies within the behavior of the Chromium/Electron framework's interaction with macOS window management APIs when combined with AeroSpace's specific implementation.

Conclusion

The workspace flashback bug when using Arc with AeroSpace is a complex interaction between application behavior (makeKeyAndOrderFront: calls), OS window management rules (WindowServer enforcing Key Window visibility), and the window manager's specific design (AeroSpace's virtual workspaces via Accessibility API). By identifying the conflicting API call pattern inherent in Chromium/Electron apps as the root cause, the most effective solution was to switch to a browser using a different engine (Firefox/Gecko), which immediately resolved the issue.

Implementing Interactive Vega-Lite Charts on My Blog, Rooted in the Grammar of Graphics

2025-04-23T00:00:00.000Z

To better communicate findings from my machine learning projects on this blog, I needed a way to go beyond static plots. Static images show results, but often hide underlying patterns. I wanted readers to explore the data themselves. Therefore, I implemented a system for embedding interactive data visualizations using Vega-Lite, rendered via a custom component built for my Astro-based blog.

This approach allows for interactions like tooltips, zooming, and linked selections directly within articles. The choice of Vega-Lite wasn't arbitrary; it stems from the powerful Grammar of Graphics (GoG) framework, a principled approach to visualization design that also underpins influential tools like ggplot2. This post outlines how I built this feature, why the GoG foundation is critical, and the benefits for technical communication.

Here is a chart that displays the same demonstration as the example on the official Vega-Lite website, while also supporting dark mode.

import Chart from "@/components/islands/common/Chart";

The Need: Interactive, Performant Visualizations

My goal was clear: embed charts that were:

Declarative: Defined using Vega-Lite's JSON specifications based on data mappings.
Performant: Loaded efficiently without slowing down page loads, using lazy-loading.
Responsive: Adapted automatically to different screen sizes.
Theme-Aware: Matched the blog's light/dark mode seamlessly.
Integrated: Easily embedded within my Markdown (MDX) content.

Achieving this required both a smart frontend component and leveraging a robust visualization library built on solid principles.

Why Vega-Lite? The Power of the Grammar of Graphics

Vega-Lite's strength comes from its foundation in the Grammar of Graphics (GoG), a formal system for constructing statistical graphics first detailed by Leland Wilkinson. GoG decomposes charts into fundamental components:

Data: The information being visualized.
Aesthetics (Mappings): How data variables map to visual properties (position, color, size, shape).
Geometric Objects (Geoms): The visual marks used (points, lines, bars).
Scales: Functions translating data values to aesthetic values (pixels, colors).
Statistics (Stats): Data transformations applied before mapping (binning, smoothing).
Coordinates: The space where data is plotted (Cartesian, polar).
Faceting: Creating subplots based on data subsets.

This modular approach offers immense expressiveness and clarity. It was popularized by Hadley Wickham's ggplot2 package for R, which demonstrated GoG's practical power and became a dominant force in statistical graphics.

Vega-Lite adapts these GoG principles specifically for interactive web visualizations:

It uses a declarative JSON syntax reflecting GoG components (data, mark, encoding).
It natively supports rich interactivity (tooltips, zooming, panning, linked selections/brushing) crucial for data exploration.
It compiles to Vega, a lower-level grammar, offering both ease of use and deep customization.
Its JSON format integrates seamlessly with web technologies.

For my workflow, the synergy with Python's Altair library is key. I can define plots in Python using GoG concepts, export the Vega-Lite JSON, and reuse that exact specification on the blog, ensuring perfect consistency between analysis and presentation.

Implementation: A Custom `<Chart>` Component

I built a reusable Preact component (Chart.tsx) within my Astro project to handle rendering:

Core Rendering: Uses the useEffect hook to dynamically import vegaEmbed and render the chart spec into a container element ref.
Lazy Loading (client:visible): Astro's client:visible directive ensures the vega-embed library (which can be sizable) and rendering logic only load when the chart scrolls into view, improving initial page performance.
Responsiveness (ResizeObserver): While Vega-Lite's width: "container" helps, ResizeObserver actively monitors the container element's size. If the layout changes after the initial render (e.g., sidebar toggle), it triggers the Vega view's resize() method, ensuring the chart adapts correctly.
Theming: Listens for a site-wide theme change event (or checks document.documentElement class) and updates the chart's theme using vegaEmbed options to support dark mode.
Accessibility: Accepts an ariaLabel prop passed to the chart for screen reader users. Vega-Embed itself aids accessibility.

direction: down
style: {
  fill: transparent
}

analysis: "Analysis (Python/Altair)" {
  shape: step
}
vlJson: "Vega-Lite JSON" {
  shape: document
}
chartComp: "<Chart> Component\n(Astro/Preact + client:visible)" {
  shape: package
}
vegaEmbed: "Lazy-loaded\nvega-embed" {
  shape: hexagon
  style: {
    stroke-dash: 3
  }
}
features: "Uses:\n- ResizeObserver\n- Theming" {
  shape: cloud
}
svgChart: "Accessible &\nInteractive SVG Chart" {
  shape: page
  style: {
    stroke: "#4CAF50"
    stroke-width: 2
  }
}

analysis -> vlJson
vlJson -> chartComp
chartComp -> vegaEmbed: "Renders via"
features -> vegaEmbed: "Acts on"
vegaEmbed -> svgChart: "Renders"

Embedding Charts in Content

Using the component in my MDX posts is straightforward:

import Chart from "@/components/islands/common/Chart";

### Exploring Model Hyperparameters

The interactive plot below shows validation accuracy across different parameters. Hover for details.

<Chart
  spec="/charts/spec/hyperparameter-scan.json" // Path to the Vega-Lite JSON
  height={400}
  client:visible // Enable lazy-loading
  ariaLabel="Interactive scatter plot of model accuracy vs hyperparameters"
/>

We can observe that optimal performance occurs...

This setup is ideal for visualizing various machine learning results:

Hyperparameter scans (scatter plots with tooltips).
Model comparisons (bar charts).
Feature importance plots.
Probability distributions (histograms, density plots, potentially linked).
Time-series forecasts (zoomable line charts).

Conclusion: Better Communication Through Principled Interaction

By implementing interactive Vega-Lite charts with a custom, performant component, I can now share data-driven insights from my machine learning work more effectively. This approach leverages the robust Grammar of Graphics principles, made practical by tools like ggplot2 and adapted for the interactive web by Vega-Lite. The streamlined workflow from Python analysis to blog post enables clearer communication and allows readers to engage directly with the data.

Embedding arXiv Papers (and other PDFs) Easily in Astro

2025-04-19T00:00:00.000Z

Displaying academic papers, especially from sources like arXiv, directly within a webpage can enhance the user experience on technical blogs. I wanted a straightforward way to embed these PDFs into my blog. My primary goal was to create a tool that would allow me to easily showcase papers when I write future posts discussing them – perhaps adding notes, detailing reproduction efforts, or providing analysis.

To achieve this, I developed a reusable Preact component that renders PDFs client-side using just the arXiv ID or a direct URL, ensuring seamless integration into my site's content flow.

The Goal: Simple, Integrated PDF Embedding

The main objective was to embed PDFs, particularly arXiv papers, as simply as possible within .astro or .mdx files. Crucially, I wanted a solution that felt native to the blog's design, rather than relying on a standard browser <iframe>.

Why Not Just Use an `<iframe>`?

While embedding a PDF using an <iframe> pointing to the source URL is possible, it offers limited control over presentation and behavior. My goals required a more integrated approach:

Minimal Design: I aimed for a viewer that fits aesthetically within my blog's theme, without the default browser UI chrome that often comes with <iframe> PDF viewers.
Customization: Using PDF.js directly allows for finer control over rendering, such as applying theme-specific styles (like the dark mode adjustments I implemented) or potentially adding custom overlays or annotations in the future.
Avoiding Nested Contexts: Iframes create separate browsing contexts, which can sometimes complicate interactions or styling consistency.

By building a component around PDF.js, I could achieve a lightweight, customizable viewer that feels like a natural part of the page.

The Solution: A Client-Side PDF Component

I built a Preact component (PDFViewer.tsx) designed to run only in the browser. This is essential because PDF rendering libraries like pdfjs-dist often rely on browser-specific APIs (like DOMMatrix) unavailable during server-side rendering (SSR) in Astro. Using Astro's client:only="preact" directive ensures the component and its dependencies load only on the client side.

Usage Examples

Embedding a PDF is now straightforward.

1. Using an arXiv ID:

To display an arXiv paper, I just need its ID (e.g., the ResNet paper ID 1512.03385):

import PDFViewer from "@/components/islands/common/PDFViewer.tsx";

// Renders the PDF for arXiv paper 1512.03385
<PDFViewer paperId="1512.03385" client:only="preact" />;

It looks like this:

import PDFViewer from "~/components/islands/common/PDFViewer";

Using a Direct URL:

The component also accepts a direct URL to any PDF file.

import PDFViewer from "@/components/islands/common/PDFViewer.tsx";

// Renders the PDF from the specified URL
<PDFViewer
  url="https://your-bucket.s3.amazonaws.com/path/to/document.pdf"
  client:only="preact"
/>;

Important Note on Direct URLs and CORS: When using the url prop with PDFs hosted on services like AWS S3 or other domains, you might encounter Cross-Origin Resource Sharing (CORS) issues. The browser's security policy prevents JavaScript from fetching resources from a different origin unless that origin explicitly allows it via CORS headers. You must configure the hosting service (e.g., your S3 bucket) to send the appropriate Access-Control-Allow-Origin headers to permit your website's domain to fetch the PDF file.

How It Works

arXiv ID Handling: When a paperId is provided, the component constructs a local path like /papers/1512.03385. A server redirect (using Netlify redirects in my case) maps this path to the actual https://arxiv.org/pdf/:id.pdf URL. This fetches the paper directly from arXiv upon request, avoiding copyright issues and keeping component usage clean.

[[redirects]]
from   = "/papers/:id.pdf"
to     = "https://arxiv.org/pdf/:id.pdf"
status = 200
force  = true

[[redirects]]
from   = "/papers/:id"
to     = "https://arxiv.org/pdf/:id.pdf"
status = 200
force  = true

URL Handling: If a url is provided, it's passed directly to PDF.js, subject to CORS rules mentioned above.
Client-Side Rendering (client:only="preact"): This Astro directive prevents server-side rendering. The pdfjs-dist library is dynamically imported within a useEffect hook in the Preact component, ensuring it only runs in the browser.
Rendering: The component uses pdfjs-dist to load the PDF and render each page onto a <canvas> element. It includes loading/error states and adapts its appearance based on the site's theme using CSS filters for dark mode.

style: {
  fill: transparent
}

direction: down

UserBrowser: "User (Browser)"
AstroMDX: "Astro/MDX Page"
PDFViewerClient: "PDFViewer Component (Client-Side)" {
  shape: hexagon
}
NetlifyRedirects: "Server Redirects (e.g., Netlify)" {
  shape: cloud
}
arXivServer: "arXiv Server" {
  shape: cylinder
}
PDFjsLib: "PDF.js Library" {
  shape: hexagon
}
Canvas: "Canvas Element"

UserBrowser -> AstroMDX: "1. Visits Page"
AstroMDX -> PDFViewerClient: "2. Includes Component\n(with arXiv ID)"
PDFViewerClient -> UserBrowser: "3. Constructs Path\n/papers/:id"
UserBrowser -> NetlifyRedirects: "4. Requests /papers/:id"
NetlifyRedirects -> arXivServer: "5. Redirects Request\nto arxiv.org/pdf/:id.pdf"
arXivServer -> UserBrowser: "6. Serves PDF"
PDFViewerClient -> PDFjsLib: "7. Loads PDF.js"
PDFjsLib -> UserBrowser: "8. Fetches PDF Data\n(via Browser)"
PDFjsLib -> Canvas: "9. Renders PDF"
Canvas -> UserBrowser: "10. Displays PDF"

style: {
  fill: transparent
}

direction: down

UserBrowser: "User (Browser)"
AstroMDX: "Astro/MDX Page"
PDFViewerClient: "PDFViewer Component (Client-Side)" {
  shape: hexagon
}
ExternalHost: "External PDF Host (e.g., S3)" {
  shape: cylinder
}
CORSCheck: "Browser CORS Check" {
  shape: diamond
}
PDFjsLib: "PDF.js Library" {
  shape: hexagon
}
Canvas: "Canvas Element"
ErrorState: "Error Displayed"

UserBrowser -> AstroMDX: "1. Visits Page"
AstroMDX -> PDFViewerClient: "2. Includes Component\n(with Direct URL)"
PDFViewerClient -> PDFjsLib: "3. Loads PDF.js"
PDFjsLib -> ExternalHost: "4. Requests PDF from URL"
ExternalHost -> CORSCheck: "5. Responds with PDF & CORS Headers"
CORSCheck -> PDFjsLib: "6a. CORS OK" {
  style: {
    stroke: "#008000"
  }
}
CORSCheck -> ErrorState: "6b. CORS Failed" {
  style: {
    stroke: "#FF0000"
    stroke-dash: 4
  }
}
ErrorState -> UserBrowser: "7b. Show Error" {
  style: {
    stroke: "#FF0000"
    stroke-dash: 4
  }
}
PDFjsLib -> Canvas: "7a. Renders PDF" {
   style: {
    stroke: "#008000"
  }
}
Canvas -> UserBrowser: "8a. Displays PDF" {
   style: {
    stroke: "#008000"
  }
}

Benefits

Simplicity: Embedding requires just a single component tag.
Flexibility: Works for arXiv papers and other hosted PDFs (with proper CORS).
Integration: Provides a minimal viewer that matches the site's design better than an iframe.
Performance: Defers heavy PDF rendering to the client.
Future-Proof: Enables richer interactions for future paper discussion posts.

Conclusion

This custom Preact component provides a clean and efficient way we found to embed PDF documents directly into our Astro site. It avoids the limitations of iframes, offering better design integration and paving the way for future posts where we can easily reference and discuss academic papers directly within the content. Remember to handle CORS settings appropriately when linking to externally hosted PDFs via direct URLs.

Demonstrating Astro Hydration with a Simple 2048 Game

2025-03-24T00:00:00.000Z

I recently built a simple version of the classic 2048 game using the Astro web framework. Beyond being a fun exercise, this project provides a clear demonstration of Astro's component hydration capabilities, specifically using the client:visible directive.

The core idea is to show how an interactive component, like this game, can be integrated into an otherwise static Astro page and brought to life in the browser.

What is Astro Hydration?

Astro is known for its "Islands Architecture," where UI components are treated as isolated "islands" within a sea of static HTML. By default, Astro components render to HTML and ship zero client-side JavaScript.

However, for components that require interactivity (like our 2048 game), Astro needs to "hydrate" them – loading and running their necessary JavaScript in the browser. Astro offers several client:* directives to control when and how this hydration occurs.

Implementing the 2048 Game Component

For this 2048 game, I created an Astro component Game2048.tsx. To make it interactive, I used the client:visible hydration directive when including it on the page:

<!-- Example usage in an Astro page -->
<Game2048 client:visible />

The client:visible directive tells Astro:

Initially render the component as static HTML on the server.
Wait until the component enters the user's browser viewport.
Once visible, load the component's associated JavaScript and hydrate it, making it fully interactive.

This strategy balances performance (deferring JS loading) with user experience (making the game interactive when the user sees it).

Play the Game

Here is the interactive 2048 game component, loaded using client:visible. Try playing a round!

import Game2048 from "@/components/islands/specific/Game2048";

Next Steps

This example provides a practical look at client:visible. When I have more time, I plan to write a more comprehensive introductory post delving deeper into Astro's various hydration strategies and how to choose the right one for different use cases. For now, I hope this game serves as a helpful illustration.

Black Myth: Wukong Review - A Flawed But Decent AAA ARPG (7/10)

2024-08-22T00:00:00.000Z

Warning: This review contains spoilers for Black Myth: Wukong.
Rating: Based on my personal evaluation system, I rate Black Myth: Wukong 7/10 after completing the first playthrough.

Ignoring external controversies, I found Black Myth: Wukong to be a decent AAA Action RPG, but one held back by notable flaws. While many have highlighted its strengths, this review focuses primarily on the areas where I felt the game fell short.

Severe Performance Issues

The most immediate problem I encountered was performance. Playing on a PC (Ryzen 7 7800X3D, RTX 3090), I experienced frequent frametime spikes (minor stutters) even in contained areas. These became more severe in sections requiring loading transitions disguised as cutscenes.

Shader Compilation: The game requires a lengthy shader compilation process on startup, which frustratingly needs repeating after GPU driver updates.
Optimization: Reports, like Digital Foundry's PS5 analysis, confirm widespread performance issues. While UE5 is still relatively new, the level of stuttering suggests inadequate optimization efforts by the development team. This needs significant improvement.

Mediocre Storyline and Weak Protagonist

While adaptations can deviate from source material if handled well, I found Black Myth's main plot mediocre. Characters often lacked clear motivations, and the central narrative—collecting Sun Wukong's remnants to become the new Great Sage—felt underdeveloped.

It's puzzling how the detailed monster compendium and side stories show depth, while the main plot remains bland. Fragmented storytelling shouldn't come at the cost of a weak core narrative.

The protagonist, "The Destined One," suffered from particularly weak characterization. By the game's end, I knew very little about them. While this might aim for player self-insertion, I dislike protagonists who feel like mere tools to advance a dull plot. Ironically, the companion character Zhu Bajie felt more vividly portrayed.

Flawed Map Design Sacrifices Gameplay for Art

The map design prioritizes artistic expression over clear visual guidance, leading to significant issues.

Navigation: While I adapted to the invisible walls and "natural" map layouts, less experienced players will likely struggle with finding their way due to a lack of distinct landmarks or intuitive paths. The realistic visuals often make different areas look too similar.
Exploration Experience: Item placement often felt random and unrewarding, negatively impacting the desire to explore thoroughly.
Pacing: The placement of bosses relative to exploration sections felt inconsistent, sometimes clustering bosses too closely or spacing them too far apart, disrupting gameplay flow.

Graphical Issues Despite UE5 Detail

While leveraging UE5's Nanite for detailed models, the game's graphics aren't flawless.

Vegetation LOD: Texture popping on vegetation was noticeable and immersion-breaking, even with Level of Detail (LOD) set to cinematic. It seems traditional techniques were used here, contrasting poorly with Nanite-rendered assets.
Artifacts: Temporal artifacts were prominent, especially in particle effects, hair, character edges, and water surfaces. This created a noisy, blurry look in these elements, detracting from the overall visual fidelity.

Passable Combat System with Core Conflicts

The combat system is functional but lacks depth and suffers from internal conflicts.

Boss Interaction: Many boss fights involve periods where dealing damage is difficult, sometimes feeling dependent on the boss AI deciding to enter attack range (e.g., Kang-Jin Loong). The lack of a reliable, universal ranged attack option exacerbates this.
Monotonous Stances: The three weapon stances primarily change heavy attacks, leaving the normal attack moveset feeling repetitive.
Resource Conflict: The game encourages aggressive, close-quarters combat (emphasized by dodge-only defense), yet the core loop revolves around managing stamina (for light attacks) and building resources for heavy attacks. This creates a disjointed feeling, as the desire to press the attack conflicts directly with system limitations.

Concluding Thoughts on Hype and Reception

Setting aside external controversies, the hype surrounding Black Myth: Wukong feels disproportionate to the final product. Much of its commercial success seems driven by the Chinese market, potentially influenced by:

Halo Effect: Affection for the Journey to the West theme and national pride in a domestic AAA title might lead to higher ratings than the game objectively merits based on global AAA standards.
Primacy Effect: For players new to AAA games, the initial positive buzz could lead to an overestimation of its quality.

The polarized reception (ratings tending towards extremes) is concerning. My worry is that the market dynamics that amplified Black Myth's hype might become a template, potentially overshadowing objective game quality assessment in the future. While perhaps unintentional by Game Science, the market learns quickly.

Ignited in Cavern: A Gender Allegory and Patriarchal Phantasms

2024-08-06T00:00:00.000Z

Introduction

In the late Northern Wei dynasty, blades of steel and fleeting visions swept across the boundless desert. In that narrow fissure between heaven and earth, the text‑adventure game Ignited in Cavern quietly raised its curtain. It tells not merely of a bizarre murder case, nor merely a few strands of family blood and tears interwoven with love and hatred; rather, it resembles a somber mirror, one that starkly illuminates how the destinies of individuals are twisted and devoured under a feudal patriarchy. Beginning at the intersection of gender and power, this paper delves into how Ignited in Cavern, through a narrative seemingly soaked in blood and dust, interprets the Othering of women and reveals the violent core behind reproductive politics. Through the theoretical lenses of Simone de Beauvoir, Judith Butler, and others, we will examine how the game others women, how reproductive politics turns into violence, and how gender roles, wedged between performance and identity, veer toward madness or awakening.

Synopsis of the Game

In the late Northern Wei, a mysterious rumor circulated through the small town of Dunhuang: it was said that an ancient statue left from the ruins could bestow supreme blessings upon any supplicant. The woman general A'nu and the Han youth Chu Qingqing were ordered to travel there and investigate, yet in the sand‑swept border town they witnessed an eerie beginning—the caravan that had guarded the statue now lay dead in the streets, their causes inexplicable, while fear and rumor spread through the town like a plague. Was it vengeful spirits at work, or something else? Burdened by their own unbearable pasts, A'nu and Chu Qingqing must both search for the truth and repeatedly look back beneath the shadow of fate.

Seemingly delicate and taciturn, Chu Qingqing’s upbringing had long planted a seed of distortion gnawing at his bones: craving affection since childhood yet always denied, he poured all emotion into a forbidden love for his brother‑in‑law and, lured by the spirit housed in the statue, embarked upon a blood‑soaked path of sacrifice. The successive murders of pregnant women and the blood‑soaked rituals all stemmed from his extreme obsession with “whether he could have an heir belonging to himself and his brother‑in‑law.” Elsewhere, the steppe‑born woman general A'nu was equally awe‑inspiring and chilling: famed for bloodlust in youth, rumored to have ended her groom’s life on their wedding night, she bore the epithet “God of War.” This defiant lone wolf scorned worldly propriety, yet under Dunhuang’s desolate night she was gradually forced to confront her deep yearning for kinship and love.

When desire and conscience converged on this remote frontier, what arrived was an even more dreadful judgment: the statue’s eerie power drew Chu Qingqing step by step toward ruin and forced A'nu to choose between morality and personal feeling. In the end, raging flame devoured resentment and attachment, and countless fates turned to ash and scattered beneath the sky. Chu Qingqing’s futile dream collapsed in an instant; A'nu, clasping her solitary courage, stepped onto the vast wilderness, burying all blood and tears. Against this backdrop where fantasy and human relations overlap, Ignited in Cavern reached its destined curtain call—it revealed not only conflicts and sacrifices beneath desert smoke and spectral shadows, but also the manifold fetters and distortions that patriarchal systems impose upon women, upon desire, and upon reproduction. This fictional world is like a ruthless scalpel slicing open the covert oppression of the “second sex.”

Patriarchy and the “Second Sex”: The Othering of Women

The story of Ignited in Cavern is set in the feudal society of late Northern Wei, a domestic fantasy drama saturated with patriarchal myth. In this patriarchal society, women are positioned as the Other, and their value is often dependent on men and bloodlines. Simone de Beauvoir notes in The Second Sex, “He is the Subject, he is the Absolute — she is the Other.” In Ignited in Cavern, female characters chiefly appear as the Other of male desire, functionalized and stripped of their subjectivity. This arrangement precisely reflects de Beauvoir’s mechanism: “One is not born a woman; one becomes one.” For example, in Chu Qingqing’s route, the nine sacrificed pregnant women are never even named—they are nameless offerings on the altar of male desire. This extreme treatment shows how patriarchal structure erases female individuality, degrading them into mere instruments for male aims. Likewise, Chu Qingqing’s biological sister is nearly reduced to a “pregnancy tool” in the plot: her sole meaning seems to be providing a vessel for her husband’s and brother’s bloodline. These women are not independent persons but Othered beings serving someone else’s narrative needs.

Even the major female characters suffer such Othering. In A'nu’s arc, her sister‑in‑law Lady Aluhuan, an aristocratic woman, has her identity and worth bound entirely to the roles of “wife” and “mother.” The only way she seeks power is through bearing a child and thus becoming a mother to secure her status. Within patriarchal values, women are disciplined to define themselves by family and reproduction—that is, by male bloodlines. She can attain meaning only in relation to her male clan—as someone’s wife, someone’s mother—while she cannot be regarded as an autonomous individual. As de Beauvoir says, women are seen as “lacking” and need to complete themselves through the male Other—precisely the vivid condition of female Otherness in Ignited in Cavern.

The game subtly discloses the repression arising from Othering. In Chu Qingqing’s route, players are long guided to stand within the male protagonist’s perspective, empathizing with his hidden yet twisted desires while almost forgetting the women he harms. The pain of women is screened out of sight, which itself is an embodiment of patriarchal narrative marginalizing women. The experiences and feelings of female characters are treated as secondary relative to the male protagonist—even if the cost is nine pregnancies lost, it seems they can be “brushed over” in one stroke of narrative. This storytelling choice undoubtedly echoes the condition of women as the “second sex” under patriarchy: their suffering and voices are drowned in the male grand narrative and passion, becoming mere background noise. It is precisely this faint yet pervasive silence that forms the game’s indictment and reflection on the Othered plight of women.

Patriarchal Violence and Reproductive Politics: Blood Sacrifice and Tragedy of Motherhood

In Ignited in Cavern, reproduction is the central motif that runs throughout, and the various storylines revolving around it all reveal the violent nature and controlling impulse of the patriarchal system. Feminism has long pointed out that patriarchy maintains rule by controlling women’s bodies and reproductive capacities; such control often manifests in hidden or naked violence. The game presents this nakedly before the players’ eyes: to satisfy male craving for “bloodline continuation,” there emerges a chain of tragedies sacrificing pregnant women. Tempted by the spirit inhabiting the statue, Chu Qingqing murders nine innocent pregnant women with his own hands as offerings to share a child with his beloved brother‑in‑law. This brutal yet symbolically real storyline dramatizes reproductive politics at its extreme: men obtain female bodies and lives to fulfill desire, even resorting to intolerable violence. As some players sarcastically remark, “The price of creation is slaughtering women… utterly absurd.” In patriarchal myth, the power of creation is seized by men, yet the sacrifice offered is female flesh. This inhuman design exposes patriarchy’s deep violence: male desire for power and heritage is fulfilled at the cost of women’s lives.

The critique of reproductive politics does not stop at male violence seizing women’s reproductive capacity; it also portrays the tragic predicament of women trapped in patriarchal reproductive oppression. In A'nu’s arc, the story of her sister‑in‑law Lady Aluhuan is a painful “tragedy of motherhood.” As the legitimate wife of a great household, Lady Aluhuan’s status and value hinge on whether she can bear a son. She regards motherhood as the only path to grasping power and security in her feudal family, sinking day by day into this fixation. Fate thwarts her: she never conceives, and her husband (A'nu’s brother) marries concubines for heirs. The concubines bear him children, while Lady Aluhuan loses both spousal affection and family prestige. The collapse of her reproductive capacity obliterates the power base she once relied on, leading her to despair and madness, and ultimately to a tragic death. Her ending symbolizes the collapse of the myth of “matriarchal right”—within the patriarchal frame, a woman who tries to gain power via motherhood can only meet destruction. Patriarchy never grants genuine autonomy; the illusory myth of “matriarchal right” cannot withstand harsh reality: once a woman’s reproductive value fails, abandonment is her only fate. As Gayle Rubin’s research The Traffic in Women: Notes on the 'Political Economy' of Sex shows, patriarchal society commodifies women through marriage and kinship; the reproductive politics in both A'nu’s and Chu Qingqing’s routes indicts this mechanism—motherhood should not be a woman’s sole value, and the extreme acts of mothers in the game further expose this malady.

It is worth noting that patriarchal control of women’s reproduction is not limited to the family; it is sanctified by religion and myth to legitimize seizing female bodies. The recurring images of the stone deity and the spirit in Ignited in Cavern are such patriarchal power devices. The legendary statue that can “grant blessings” is said to realize human wishes, yet it demands a bloody price—men offer pregnant women’s lives in exchange for “grace.” The statue appears supernatural, but it metaphorically represents patriarchy’s supreme reproductive authority: it wraps men’s desire for lineage in ritual, cloaking horrifying violence in sanctity. By sacrificing to the stone deity, men seem to obtain legitimate authorization to control the conception and termination of life. This storyline mercilessly exposes how patriarchy exploits religious myth to sustain its violence: female reproductive organs become offerings to satisfy male desire, while what is desecrated are women’s lives and wombs.

In sum, through these extreme and metaphor‑rich plot elements, the game conducts a profound critique of patriarchal reproductive politics. Whether the souls of nine pregnant women or Lady Aluhuan’s sorrow at failing to bear a child, all show how deeply women suffer control and harm around reproduction under patriarchy. Ignited in Cavern tears open the violence hidden in history and family: what patriarchy calls procreation and love often masks domination and plunder of women’s bodies.

Gender performativity: Roles Between Violence and Identity

Judith Butler’s gender theory suggests that gender is an identity tenuously constituted in time, instituted in an exterior space through a stylized repetition of acts. In Ignited in Cavern, the protagonists of the two storylines—Chu Qingqing and A'nu—are trapped in the conflict between gender performativity and self‑identity. Their respective experiences can be analyzed through “gender performativity”: under patriarchal scripts imposed on identity, characters either submit or resist, and every step is accompanied by the shadow of violence.

Chu Qingqing’s character embodies the distorted performance of masculine roles under patriarchal expectations. Although male, he loves his brother‑in‑law (another man, Zou Rong), and this taboo love puts him in a quandary regarding gender roles. Patriarchal heteronormativity does not allow him to love a man as “wife” or “mother,” yet his yearning for a “shared‑blood child” is akin to a maternal fantasy—traditionally a female role in heterosexual marriage. To satisfy this illusion, he embarks on a deranged path, attempting through occult ritual to let two men “give birth” to a child. This can be seen as an extreme counter‑performance of traditional gender roles: Chu Qingqing, as a man, obsessively plays the “mother” function. Yet this transgression brings no salvation, only extreme violence (the killing of pregnant women). He is trapped in patriarchal discourse with no exit: as an obedient older brother, he suppresses his homosexual desire; trying to play a female reproductive role, he can only realize it in grotesque form. As Butler stresses, “gender is not a pre‑existing identity but a constantly repeated performance,” and Chu Qingqing’s attempt to “perform” female reproduction is an extreme satire on traditional scripts, revealing society’s rigid demands on gender identity. Ultimately, he can be neither true husband nor father, nor achieve satisfaction as “mother”; only in hallucinations does he converse with the spirit, letting himself be manipulated by an ever more absurd drama. Notably, he also performs another layer of obedience: in daily relations, Chu Qingqing habitually pleases others and hides himself. “Some things he truly wants, but if no one asks he never acts; some things he loathes, yet if others request he complies.” This self‑sacrificing obedience is exactly the patriarchal script for “normatively masculine subjects”; he performs it by rote, avoiding confrontation with genuine needs. His tragedy lies in never escaping predetermined gender scripts: obediently acting the “good man” in others’ eyes while madly performing patriarchal myths of a “creator,” losing his true self and plunging into violence.

In sharp contrast, A'nu plays a role traditionally ascribed to men within a female body. As a woman general of Northern Wei, she shows surpassing strength from childhood: “killing a hunting dog bare‑handed at four, playing a groom to death on her wedding night,” making her almost legendary, the “God of War.” This is a feminine rendition of masculine martial prowess: A'nu, as a woman, plays the heroic, fearless, warrior, shattering patriarchal scripts of female docility. In gender performativity terms, she performs a “masculinized” self. She does not suppress desire, reveling in bodily pleasure and battle’s thrill, ignoring patriarchal decorum. Yet, as Butler notes, any rebellion against gender discipline brings social pressure and identity conflict. Though fierce, A'nu is not devoid of inner struggle: she still yearns for love and connection, but the object of her affection is her sister‑in‑law. A'nu’s deep love for Lady Aluhuan is doubly taboo (same‑sex and incest). When she attempts to express it, she abandons usual forthrightness, showing rare shyness and caution. Saying “I love you” with the respectful “you,” her tone is as restrained as a knight pledging to a queen. This respectful yet suppressed confession shows A'nu re‑performing a socially accepted female submissive image in the face of love—she is no longer a wild beast but a courteous junior. Thus, while fearless in battle, she is fettered by ethical roles in forbidden love: on one side blazing desire, on the other Lady Aluhuan’s moral identity as “elder.”

Lady Aluhuan’s response to A'nu embodies the other face of gender performativity: as an elder woman, she cannot accept A'nu’s transgressive love and retreats into a maternal role. She repeatedly uses elderly kindness and morality to dissolve A'nu’s confession, placing A'nu as a “junior” to be guided. Asking, “Do you wish to be my child?” she tries to re‑frame A'nu’s love within a socially acceptable “maternal love.” She insists on playing the moral mother, using ethical affection to refuse taboo desire. Thus, both women in this hidden romance are constrained by their gender roles: A'nu cannot openly become Lady Aluhuan’s lover, only a respectful younger; Lady Aluhuan cannot respond as a woman, only hiding in motherhood to evade inner turmoil. Their performances lead to shared pain: A'nu, invincible in force, is helpless in emotion; Lady Aluhuan spirals toward madness in the tug‑of‑war between reason and feeling. Gender performativity scripts forge identity tragedies; deviation invites violence—from others or self, whether external blood or internal heartbreak.

In sum, through the extreme yet mutually reflecting characters Chu Qingqing and A'nu, Ignited in Cavern shows the performativity and fragility of gender identity. Whether a man attempting “motherhood” or a woman acting “God of War,” heavy costs ensue. When roles struggle between violence and identity, we witness the cruel constraints of gender norms on individuals in patriarchy: any overstep invites violent punishment; only by tearing off the mask might one glimpse a sliver of true self.

Female Body, Desire, and Motherhood as Metaphor

Ignited in Cavern employs an almost anatomical allegory to weave female body, desire, and reproduction into a complex network of metaphors. In this net, every female character’s body and desire belong not solely to herself but bear the double meaning of patriarchal myth and rebellious narrative. From nine pregnant corpses to Lady Aluhuan’s fixation on mother and child, the game uses extreme story settings to reveal how patriarchal fantasies about “love” and “procreation” are built on violence, while probing the cracks and possibilities women may find therein.

First, the tragedy of the “nine pregnant women” is the clearest reproductive‑political metaphor. Pregnant women—bearers of life—should symbolize love, hope, and future, yet here they are slaughtered as sacrifices, their flesh the price of male desire. This inversion metaphor shows the dark myth of patriarchal “love”: a man wants a child for love, yet destroys multiple women bearing life. The fruit of love is irrigated with others’ blood and tears; such love departs from its origin, degenerating into a violent structure. As players belatedly realize: Chu Qingqing “acts in the name of love, then tells players love does not exist”—once truth emerges, we see the natal frenzy in love’s name was illusion, love merely a glittering cloak for desire. The game thus questions the patriarchal myth of love: when love is tied to lineage, equated with possessing another’s capacity to reproduce, “love” is no longer true love but a cage devouring women. The nine pregnant women’s souls ask: Is this truly love, or a hunt in love’s name?

Second, Lady Aluhuan’s obsession with motherhood is another metaphor. She represents the traditional patriarchal value of the “mother” role’s supremacy and sacrifice. In feudal family, bearing heirs is women’s sole path to dignity; motherhood is haloed. The game deconstructs this image: Lady Aluhuan sees motherhood as life’s meaning, yet her maternal desire drives her to madness and destruction. This irony signals: patriarchal myth exalts “motherly love” as a woman’s highest virtue while shackling her with golden chains. Lady Aluhuan kneels daily praying for pregnancy, yet this pious fixation destroys her. When hope dies, her “merciful mother” persona collapses, even seeking illusory bonds by ethical coercion (asking A'nu to be her “child”). Her death symbolizes the shattering of the “myth of matriarchal right”—a woman’s attempt to gain power via motherhood proves mirage. The game shows: when motherhood is a woman’s only value, the role itself devours her. At her death, maternal authority crumbles, exposing patriarchy’s myth of motherly love—great mother becomes pitiful victim, her sacrifices never saved her.

Beyond reproduction and motherhood, relationships of desire among women challenge patriarchal norms. The ambiguous, unnameable bond between A'nu and Lady Aluhuan excavates and subverts the repression of women’s desire in patriarchy. Traditional ethics forbid their love—seen as incest or perverse. Through their interaction, the game presents an unusual tableau of “women’s love”: A'nu’s knight‑like devotion and sisterly sympathy merge. This complex desire breaks patriarchal stereotypes of women’s emotion, showing female desire’s power. Yet reality forces it into maternal ethics, twisting love into elder care; both cannot confront feelings. The metaphor reveals female desire’s suffocation: two women in love retreat to roles (mother/child) for legitimacy, burying true passion beneath ethics. The fire never dies—A'nu still burns, Lady Aluhuan wavers. This undercurrent of female desire is silent resistance to patriarchal discipline: though not breaking free, players witness female subject desire surging underground.

The game’s treatment of mother figures as functional also carries strong political satire. Mothers are not stereotypical saints but endowed with extreme, conflicting power: some mothers bear children then kill them—Chu Qingqing’s mother reportedly took her offspring away in regret; even after death her will haunts. Some mothers (Lady Aluhuan) crave children but fail and are harmed by others’ offspring. Others (Chu Qingqing’s sister) lose infants early—dream shattered. This array displays mothers’ power to create and destroy: “A mother who births you can also kill you, granting life yet able to reclaim it.” In patriarchal myth, mothers are celebrated as life’s source and selfless love, yet the game tears off this veil, revealing suppressed rage and sorrow. Mothers forced into functions either rebel—like Chu Qingqing’s mother reclaiming life in regret, the patriarchy‑feared “mother kills child” tragedy; or become martyrs—Lady Aluhuan going mad and dying for failed function. Either way, motherhood’s dark side is exposed: motherly love can morph into devouring love, mothers not merely saints but critics of injustice.

Through these layered metaphors, the game guides players to reassess naturalized patriarchal notions of “love” and “life.” When blood‑streaked altars echo buried corpses in a mother’s garden, we grasp: under patriarchal myth, the exalted “love” is a sugar‑coated violence structure. Conjugal love demands women risk life; maternal love drives women mad; even sisterly love (women’s friendship/desire) is strangled by norms. The game’s extreme story shows: When love loses respect for equality and subjectivity, becoming a tool of patriarchal possession and reproduction, it ceases to be pure love, becoming a power contest and sacrificial myth. When women’s bodies are mythologized as vessels and desire suppressed in morality’s name, “love” turns into a mountain crushing women. As Chu Qingqing’s line reveals: perhaps love itself is an illusion—an empty shadow built on others’ pain. Only by seeing this can true awakening and resistance begin.

Madness and Awakening: Feminine Rebellion in Gender Writing

Ignited in Cavern boldly depicts a series of nearly deranged female figures who resist with violence or collapse in despair. Through their madness and awakening, the author constructs a radical rebellious gender narrative, seeking a new route through cracks in patriarchal myth. A'nu and Lady Aluhuan, this aunt‑and‑sister pair, are its core: one battles fate in berserk valor, the other reveals truth through lunatic descent. Their tales are both thrilling and heartbreaking, forming a dual judgment on patriarchal norms.

Let us begin with A'nu. She appears almost as a “madwoman”: bloodlust in youth, killing her groom on their wedding night, invincible in war—all exceed imagination of a woman. Yet this near‑uncontrolled violence is active rebellion against patriarchy. A'nu refuses any subservience: she is not a docile bride, nor a lamb to slaughter. She regains bodily sovereignty through madness—no one dare force her to marry or bear children; her blade wins her the standing of a “free person” beyond rules. Her “madness” is an exaggerated allegory: by forging a woman ungoverned and feared by men, the author subverts the traditional docile feminine image. A'nu embodies radical revolt: destroyer of oppressive order and seeker of new. Her battlefield cries of “love” or “power” evoke epic shock—announcing the birth of a Valkyrie who will not submit to patriarchy. As Eve Kosofsky Sedgwick notes in Between Men: English Literature and Male Homosocial Desire, rigid gender and desire borders label any transgression “madness,” which reflects the pathological tendency towards non-heterosexual or transgressive behavior in the context of literature and society. A'nu’s fierce rebellion counters this binary, her “madness” not only challenges patriarchal taboo but deeply indicts social oppression.

By contrast, Lady Aluhuan’s madness is restrained and tragic. She wields no sword, yet her inner twists rival battlefield carnage. In long despair over lost children, her mind crumbles; fixation pulls her to the edge of the surreal: she believes in spirits, curses, perhaps joins strange rites (hints of a deer‑headed mask meeting A'nu, like an out‑of‑body soul). With gentle façade, she hides blazing insanity. Her madness is desperate protest forced by patriarchy. She obediently played good wife and daughter‑in‑law, gaining nothing. Only the phantom hope of bearing a child remains; when shattered, she resists fate in self‑harm labeled “lunacy.” She clings to being “mother,” dragging loving A'nu into delusion, treating her as “child.” Though irrational, it is laden with meaning: a woman, cornered, sends a final protest against patriarchal rules. Unable to be real mother, she crafts a fantasy, weaving ethics and blood into a cocoon—self‑deception to outsiders, but her last salvation. Her death may signal a kind of awakening: realizing all effort was futile, she is but a patriarchal pawn. In that era, her personal awakening is powerless, ending only in tragedy.

Of note, A'nu’s route offers multiple endings, each corresponding to choices on her “awakening” path. Endings hinge on her final stance on “love”: one sees her insist love exists and willingly become its slave; another sees her perceive love’s falsity, recognizing only power, choosing to serve it. This is her ideological awakening: after excruciating events, her faith in patriarchal “love” wavers. If she rejects love, embracing power, she has pierced the myth and rebuilds value through strength—deeper rebellion and awakening. Rejecting enslavement to love (often family or men), choosing her own power: she awakes from patriarchal myth, becoming a true iconoclast. Alternatively, she may still believe in love, yet her love (for her sister‑in‑law) defies patriarchal expectation, thus still living female desire’s power. Either way, A'nu’s spirit remains rebellious: she dares to be mad and lucid, to love and hate, expanding the frontier of female possibility and composing a radical war chant.

Through these mad yet awakened women, Ignited in Cavern conducts a bold gender‑writing experiment: not depicting obedient “good women” but highlighting transgressive “bad” or “mad” women. Historically, literature labels rebellious women as mad; the game wields “madness” as narrative weapon: letting women speak unspeakable truths and perform taboo deeds. Women’s madness becomes a language of resistance: A'nu’s berserker image questions male monopoly on violence; Lady Aluhuan’s derangement unmasks patriarchal manipulation. Meanwhile, their awakening sharpens defiance with clear thought: they are not aimlessly mad but glean insight and make choices—whether a last‑second epiphany or one unlocked by the player, these awakenings empower them. The author uses this “madness + awakening” duet to build an unprecedented radical gender narrative, calling for rebellion and transcendence of patriarchy.

Of course, such radical writing is not flawless. While celebrating female revolt, the work harbors implicit issues worthy of reflection.

The Shroud of Patriarchal Narrative: Male Perspective and Female Suffering

Despite Ignited in Cavern’s attempt at a radical gender narrative, at certain levels it still fails to shake off patriarchal storytelling’s ruts. The most striking problem is that the male protagonist’s perspective invisibly screens off and buries women’s suffering, so that while the game condemns patriarchal violence it almost reenacts a neglect of women. This paradox warns that even an anti‑patriarchal theme may dull its edge if it employs patriarchal gaze, even causing new injustice.

As noted earlier, the greatest controversy in Chu Qingqing’s route is that the deaths of nine pregnant women are down‑played; players, immersed in his viewpoint, focus on his inner pain and unattainable love. By contrast, the extreme violence against innocent women scarcely becomes a narrative focal point, often glossed in a few sentences. When climax arrives, many players realize the male lead committed monstrous crime; yet even then, their primary feeling is shock and complex sympathy for him, not grief for nine lives. This is not their coldness but the narrative’s deliberate guidance. One comment sharpens: “The author is clever; the pregnant women’s deaths are casual strokes, and players experience the male lead’s feelings. For him, sacrificing pregnant women might be trivial, so players sharing his perspective forget it.” Laura Mulvey’s research shows the “male gaze” reduces women to visual objects; in the game, the concealed pain of women embodies patriarchal gaze—male view marginalizes female suffering. The game lets us “see” via male eyes so women’s pain naturally fades—not visceral to men, players glide past. This “cleverness” is not innovation but patriarchal routine: writing men as universal experience. Women’s ordeals are ignored or down‑played, male emotions amplified. Chu Qingqing’s route follows this pattern, so many missed the intended critique, even misconstruing it. Some nickname the male route a “BL tortures women” piece—depicting male‑male romance using women’s torment for spectacle. When female suffering is too obscure, a work may be misread as catering to unhealthy thrills, not critiquing patriarchy.

This male perspective’s occlusion of female suffering is a hidden danger in Ignited in Cavern. It can weaken the thesis and raise moral unease: nine horrific deaths barely ripple, lacking narrative space or condemnation. The treatment re‑buries victims: patriarchy erased their lives; the story erases their presence. Feminists stress “we must face the violence women suffer”; seeing is resistance’s start. Yet players once “cannot see” this violence, thus cannot question it—most focus on Chu Qingqing’s tragedy, ignoring deeper female tragedy. A comment asks: “Even viewers with gender awareness might unconsciously miss structural injustice behind these scenes. In a male‑dominated narrative, who truly sees women’s plight?” The dilemma: the story must have a man recite this pathology to show patriarchal absurdity; but deep immersion repeats patriarchal bias.

Still, the author tries compensation in A'nu’s arc, almost free of male gaze, centering a woman’s perspective. Here, women’s desire, anger, and agency stand vivid; many players feel A'nu’s line is cathartic revenge. Perhaps intentionally, a powerful female‑centered narrative offsets the male viewpoint imbalance. Hidden issues resurface—Lady Aluhuan’s death, truths, interlocking schemes—and gain fuller exposition. Viewing through A'nu’s eyes clarifies patriarchy’s absurdity: she sees her sister‑in‑law die for men and children, smashes the stone statue—symbol of desire’s power (if chosen). These actions correct male line bias. Thus, the dual structure balances perspective: one line hides women’s pain, the other lets women speak. Yet many players play only one line, missing the balance, leading to claims of “inconsistency.” How to rebel while caring for readers, how to expose cruelty without narrative pitfalls—these are questions the game leaves us. It also reminds creators: in overturning old narratives, beware old gazes sprouting anew.

Passes a Gap in Flight, Like a Spark in the Dark, or a Dream of Moonbeam

As a fantasy tragedy steeped in late Northern Wei’s bleakness, Ignited in Cavern unfurls a relentless dissection and critique of patriarchy and its myths amid blood and flames. Through layers of analysis—patriarchal system, female Othering, reproductive ethics, and gender politics—the game offers a harsh yet thought‑provoking proposition: when love is imprisoned within patriarchal myth, it ceases to be pure love and may evolve into a violent structure; to break this structure, only marginal madness and rebellion can suffice.

Those shocking scenes—the nine pregnant women whose names are forgotten, their bodies silent offerings on the altar of male desire; Lady Aluhuan’s near‑mad obsession with “mother” identity dragging her into destruction—keep knocking at us. They force us to ponder: when lineage obsession overrides all, when women’s existence is reduced to reproduction, how much distortion and cost hide behind familial warmth? Chu Qingqing’s crimes in love’s name make us doubt whether love nourished by blood was self‑deception from the start. A'nu’s blazing yet desperate affection, shackled by ethics, turns into a blade, wounding herself and possibly severing the last sliver of tenderness. Her story seems to say: even mighty rebels, breaking rules, may fall into deeper loneliness and confusion.

We see characters performing, struggling, even going extreme within preset gender scripts. Chu Qingqing attempts a forbidden role and is consumed by desire’s flame; A'nu crashes against convention in feral posture, yet wavers on the edge of love and hate. Their madness and awakening, their swaying between violence and identity, are no longer mere personal tragedies but silent indictments of that era and its rules. The patriarchal myths of “love,” “motherhood,” “family” shatter amid the statue’s cold gaze and battlefield blood, exposing an inner violent structure.

Ignited in Cavern offers a sharp, mournful answer. The nine cold corpses, Lady Aluhuan’s tears—they proclaim the myth’s collapse: patriarchal love is but the alias of power desire, underlain by a network woven of blood and tears. When the dust settles, players may feel: The cavern’s stone and lingering ghost‑fire have burnt the patriarchal love myth to cinders, illuminating the long‑silenced truth of the second sex buried beneath the ruins.

When flames fade and dust settles under desert moonlight, only ashes and faint embers remain. Cracks in the stone seem to hide residual heat, signaling patriarchal dreams’ demise and women’s truth’s emergence. The cavern has split; the spark, though small, lets us glimpse, amid the ashes of burnt‑out dreams, the roots of women’s distorted destinies.

What Terminal Emulator Am I Using in 2024?

2024-07-31T00:00:00.000Z

TL;DR: I chose the Kitty terminal emulator.

This post details my recent journey in selecting a new terminal emulator, settling on Kitty after extensive use of others.

What is a Terminal Emulator?

Before diving in, let's clarify what we're discussing. Most readers likely know what a terminal is, but for completeness:

A terminal emulator, or terminal application, is a computer program that emulates a video terminal within some other display architecture.

Source: Wikipedia

Essentially, it's the software window we use to interact with command-line interfaces and shells (like Bash or Zsh). Hardware terminals are mostly history, so we generally just call these emulators "terminals."

My Terminal History and iTerm2 Experience

Over the years, I've used several terminals, including Konsole, Alacritty, and Kitty. However, since I spent most of my time on macOS, iTerm2 was my long-term daily driver.

While often criticized for performance, iTerm2 served me well, especially on standard 60Hz monitors where speed differences aren't always obvious. It met most of my needs, but a couple of persistent issues kept it from feeling perfect:

No simultaneous ligatures and GPU rendering: Enabling font ligatures (which merge characters like != into ≠) forces iTerm2 to use Apple's Core Text framework instead of the GPU for rendering, potentially impacting performance or visual consistency (iTerm2 docs).
No plain text configuration: iTerm2 configurations can only be exported as a .plist or .json file. For developers managing their environment via dotfiles in Git, this means an extra manual export step after every change, which is cumbersome compared to simple text config files.

These were minor annoyances, but they represented limitations I wished weren't there.

The Catalyst for Change: Going Cross-Platform

The real push to find an alternative came when I decided to adopt NixOS on my PC. As a long-time Arch Linux user who moved to macOS primarily for the M-series ARM efficiency, the appeal of NixOS's declarative philosophy drew me back towards Linux for my desktop.

This move highlighted iTerm2's main drawback for my new workflow: it's macOS-only. I needed a terminal that worked seamlessly across both macOS and Linux. This led me to seriously evaluate modern, cross-platform, GPU-accelerated options, primarily Kitty and Alacritty.

Evaluating Alternatives: Kitty vs. Alacritty

Both Kitty and Alacritty are popular, performant terminals leveraging GPU acceleration. They also share reputations for having opinionated lead developers (Kovid Goyal for Kitty, known for Calibre; and the Alacritty team's focus on minimalism sometimes perceived as stubbornness).

Alacritty: Known for its focus on simplicity and speed. However, this focus means it deliberately lacks features like font ligatures and built-in support for terminal graphics protocols (like the Kitty graphics protocol or Sixel).
Kitty: Also very performant, but includes more built-in features, such as multiplexing (like tmux), various "kittens" (helper scripts), ligature support, and its own graphics protocol for displaying images directly in the terminal.

Why I Chose Kitty

Ultimately, Kitty emerged as the better fit for my needs:

Cross-Platform: Works natively on macOS and Linux.
GPU Accelerated: Provides a smooth, fast experience.
Ligature Support: Renders programming ligatures correctly without sacrificing GPU rendering.
Image Protocol Support: Crucial for tools like yazi (a TUI file manager I use heavily) that display image previews directly in the terminal. Alacritty's lack of this was a significant drawback for me.
Text-Based Configuration: Uses a simple kitty.conf file, perfect for managing via dotfiles.
Extensibility: Offers features like tabs, windows (multiplexing), and scriptable "kittens."

While Alacritty's minimalism is appealing in theory, Kitty's richer feature set provided more practical benefits for my development workflow without any noticeable performance penalty in my daily use.

Conclusion and Configuration

Switching to Kitty has been a positive experience. It meets my technical requirements for a cross-platform, feature-rich, and performant terminal. The migration wasn't entirely without bumps – for instance, I had to adjust my powerlevel10k Zsh theme settings due to how Kitty handles certain block elements. I will write a post about this in the future.

My complete Kitty configuration is also available in my dotfiles repository (not available yet) for anyone interested.

And finally, as the developer is known for Calibre and his fondness for felines is reflected in the project's name: Kitty is indeed a good cat.

Restarting My Blog (Again) with Astro

2024-07-30T00:00:00.000Z

I've recently relaunched my personal blog, this time built with the Astro framework. Honestly, I've lost count of how many times I've started this journey. Each time I attempt a migration or a fresh start, I realize I haven't kept good records of the previous iterations—the technologies used, the lessons learned, or even the content created often get lost in the shuffle.

This time, I'm hoping to do things differently. My primary goal is still to create content, but I also plan to document the "why" and "how" behind this specific build.

A Brief History of Attempts

My interest in having a personal online space dates back to around 2011, largely inspired by Matrix67 (Gu Sen) and his fascinating math blog, which I discovered through Baidu Tieba – Mathematics (like r/math in Chinese). Seeing his work sparked a desire to have my own corner of the internet to share ideas.

style: {
  fill: transparent
}

direction: right

cms: "Unknown CMS"
ssg: "Static Site Generator"
wp: "WordPress"
astro: "Astro"

cms -> ssg -> wp -> astro

My first blog used some CMS technology I can barely recall, memorable only because I built a simple Android app to display its content. Like many first projects, it eventually faded due to neglect.

Later, I explored static site generators (perhaps Jekyll, Hugo, or Hexo – the details are fuzzy) hosted on GitHub Pages, a popular approach at the time. Around 2018, I tried again with WordPress hosted on a Vultr VPS, aiming to focus solely on content. However, that attempt also stalled, leaving behind only a handful of posts visible via the Internet Archive.

These repeated cycles led to frustration, and I nearly gave up on maintaining a dedicated blog altogether, opting instead for local Markdown notes.

Why Astro This Time?

Despite resolving to stop tinkering with the technology and focus on writing, the allure of a new tool pulled me back in. In 2024, I discovered Astro. Its philosophy of being "built for content" and its modern approach to building fast, content-focused websites resonated strongly with my goals for a blog.

It felt like the right fit – a framework designed specifically for use cases like mine, potentially minimizing the unnecessary complexity I'd encountered before while still offering the flexibility I enjoy as a developer.

Instead of just setting up a default theme, I treated this rebuild as a complete frontend project, investing significant time into customizing the setup and understanding Astro's capabilities.

Looking Ahead: Documenting the Build

This time, I'm committed not only to writing content but also to writing about the process. I plan to publish a series of posts covering:

Technical decisions made during the setup.
Details of the implementation (theming, features, deployment).
Challenges encountered and solutions found.

Coincidentally, around the time I started this rebuild, I noticed that Matrix67's blog had also started updating again after a long hiatus. It felt like a small, encouraging sign.

Hopefully, this renewed effort, coupled with the decision to document the journey, will help me maintain momentum longer this time. Stay tuned for more technical details about the build.

Showcasing LaTeX Rendering: The Einstein Field Equations

2023-03-24T00:00:00.000Z

This post is primarily a demonstration of rendering LaTeX within this blog setup. I find it crucial for technical writing, especially when dealing with complex mathematical or scientific notation. In the future, I might detail how I integrated LaTeX rendering, perhaps specifically within the Astro framework.

For this test, I've chosen the Einstein Field Equations (EFE) from general relativity, presented in several forms to showcase different LaTeX features.

Einstein Field Equations: Compact Form

The most common and compact representation of the EFE is:

G_{\mu\nu} = R_{\mu\nu} - \frac{1}{2}g_{\mu\nu} R = {8 \pi G \over c^4} T_{\mu\nu}

Here's a brief explanation of the terms:

$R_{\mu\nu}$: Ricci curvature tensor component, measuring curvature in spacetime caused by matter-energy.
$g_{\mu\nu}$: Metric tensor, encoding distances and geometry in spacetime.
$R$: Ricci scalar, representing overall curvature of spacetime.
$T_{\mu\nu}$: Stress-energy tensor component, representing matter and energy distribution.
$G$: Newton's gravitational constant.
$c$: Speed of light, a universal constant.

Expanded Form (Derivatives Explicit)

The compact form hides a lot of complexity. Expanding the Ricci tensor and scalar in terms of the metric tensor and its derivatives gives a much more involved expression. Here's one representation (note: specific forms can vary based on conventions and intermediate steps):

\begin{gathered}\frac{1}{2} g^{\alpha \beta} \partial_\alpha \partial_\mu g_{\beta \nu}+\frac{1}{2} g^{\alpha \beta} \partial_\alpha \partial_\nu g_{\mu \beta}-\frac{1}{2} g^{\alpha \beta} \partial_\alpha \partial_\beta g_{\mu \nu}-\frac{3}{2} g^{\alpha \beta} \partial_\mu \partial_\nu g_{\alpha \beta}-\frac{1}{2} g^{\beta \lambda} g^{\alpha \rho} \partial_\alpha g_{\rho \lambda} \partial_\mu g_{\beta \nu} \\ -\frac{1}{2} g^{\beta \lambda} g^{\alpha \rho} \partial_\alpha g_{\rho \lambda} \partial_\nu g_{\mu \beta}+\frac{1}{4} g^{\beta \lambda} g^{\alpha \rho} \partial_\nu g_{\alpha \lambda} \partial_\mu g_{\rho \beta}+\frac{1}{4|g|} g^{\alpha \beta} \partial_\beta|g| \partial_\nu g_{\mu \alpha}-\frac{1}{4|g|} g^{\alpha \beta} \partial_\beta|g| \partial_\alpha g_{\mu \nu} \\ -\frac{1}{4|g|} g^{\alpha \beta} \partial_\beta|g| \partial_\mu g_{\alpha \nu}+\Lambda g_{\mu \nu}=\frac{8 \pi G}{c^4} T_{\mu \nu}\end{gathered}

This version explicitly includes partial derivatives ($\partial$) of the metric tensor components ($g_{\alpha \beta}$, etc.) and introduces the cosmological constant $\Lambda$. The term $|g|$ represents the determinant of the metric tensor.

Fully Expanded Form (Summations Explicit)

Using Einstein summation notation (where repeated indices imply summation) is standard practice. Making the summations explicit reveals the full extent of the calculations involved:

\begin{gathered}
\frac{1}{2} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 g^{\alpha \beta} \partial_\alpha \partial_\mu g_{\beta \nu}+\frac{1}{2} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 g^{\alpha \beta} \partial_\alpha \partial_\nu g_{\mu \beta}-\frac{1}{2} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 g^{\alpha \beta} \partial_\alpha \partial_\beta g_{\mu \nu}-\frac{3}{2} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 g^{\alpha \beta} \partial_\mu \partial_\nu g_{\alpha \beta}-\frac{1}{2} \\
\sum_{\alpha=0}^3 \sum_{\beta=0}^3 \sum_{\rho=0}^3 \sum_{\lambda=0}^3 g^{\beta \lambda} g^{\alpha \rho} \partial_\alpha g_{\rho \lambda} \partial_\mu g_{\beta \nu}-\frac{1}{2} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 \sum_{\rho=0}^3 \sum_{\lambda=0}^3 g^{\beta \lambda} g^{\alpha \rho} \partial_\alpha g_{\rho \lambda} \partial_\nu g_{\mu \beta}+\frac{1}{4} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 \sum_{\rho=0}^3 \\
\sum_{\lambda=0}^3 g^{\beta \lambda} g^{\alpha \rho} \partial_\nu g_{\alpha \lambda} \partial_\mu g_{\rho \beta}+\frac{1}{4|g|} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 g^{\alpha \beta} \partial_\beta|g| \partial_\nu g_{\mu \alpha}-\frac{1}{4|g|} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 g^{\alpha \beta} \partial_\beta|g| \partial_\alpha g_{\mu \nu}-\frac{1}{4|g|} \sum_{\alpha=0}^3 \\
\sum_{\beta=0}^3 g^{\alpha \beta} \partial_\beta|g| \partial_\mu g_{\alpha \nu}+\Lambda g_{\mu \nu}=\frac{8 \pi G}{c^4} T_{\mu \nu}
\end{gathered}

Here, each $\sum_{\alpha=0}^3$ indicates summation over the spacetime indices (typically time and three spatial dimensions).

Example: Enumerating Terms

To further illustrate the complexity, let's expand just the very first term containing summations:

\begin{aligned}
& \frac{1}{2} \sum_{\alpha=0}^3 \sum_{\beta=0}^3 g^{\alpha \beta} \partial_\alpha \partial_\mu g_{\beta \nu}=\frac{1}{2} g^{00} \partial_0 \partial_\mu g_{0 \nu}+\frac{1}{2} g^{01} \partial_0 \partial_\mu g_{1 \nu}+\frac{1}{2} g^{02} \partial_0 \partial_\mu g_{2 \nu}+\frac{1}{2} g^{03} \partial_0 \partial_\mu g_{3 \nu} \\
+ & \frac{1}{2} g^{10} \partial_1 \partial_\mu g_{0 \nu}+\frac{1}{2} g^{11} \partial_1 \partial_\mu g_{1 \nu}+\frac{1}{2} g^{12} \partial_1 \partial_\mu g_{2 \nu}+\frac{1}{2} g^{13} \partial_1 \partial_\mu g_{3 \nu}+\frac{1}{2} g^{20} \partial_2 \partial_\mu g_{0 \nu}+\frac{1}{2} g^{21} \partial_2 \partial_\mu g_{1 \nu} \\
+ & \frac{1}{2} g^{22} \partial_2 \partial_\mu g_{2 \nu}+\frac{1}{2} g^{23} \partial_2 \partial_\mu g_{3 \nu}+\frac{1}{2} g^{30} \partial_3 \partial_\mu g_{0 \nu}+\frac{1}{2} g^{31} \partial_3 \partial_\mu g_{1 \nu}+\frac{1}{2} g^{32} \partial_3 \partial_\mu g_{2 \nu}+\frac{1}{2} g^{33} \partial_3 \partial_\mu g_{3 \nu}
\end{aligned}

This shows the 16 individual terms generated just from the first double summation in the expanded equation. The full equation involves numerous such complex terms.

Conclusion

This demonstration shows that the current setup can handle complex, multi-line LaTeX expressions effectively. Displaying equations clearly is vital for technical accuracy, and I'm pleased with how these examples rendered. As mentioned, I plan to explore the implementation details in a future post.

Echoes From an Empty Well

2022-04-01T00:00:00.000Z

The village breathes in the way of old radios left humming in empty rooms—static, half-formed. The banyan tree’s roots buckle the path, and the well’s rim is always damp, even when the sun hangs like a cleaver. The cat arrived when the heat did. Dun-colored, one ear nicked—a jagged moon crescent. I named it 缺儿（耳） (Ch'üeh-erh)—meaning both "the lacking ear" and "the lacking one." A fragment, incomplete like stories my grandma left unfinished, suspended like dust motes in afternoon light. It drank from puddles, throat bobbing as if swallowing secrets. Mother says the well-water tastes of iron, but I think it tastes of the bicycle bells that rust in Old Chen’s shed, their tongues green and silent.

Father’s transistor spits numbers—stock prices, rainfall, things that mean nothing here. His shirt sticks to his chair, plastic-coated floral print peeling. At dinner, congee quivers in my bowl. Mother’s voice clicks like a fan rotating: Don’t dawdle by the well. Don’t track mud. Don’t. The cat won't be forbidden. It isn’t anything.

That day, the road softened like wax. The banyan’s leaves curled into fists. I squatted, peeling bluish lichen from the roots, when the sound began—a low whine, like a mosquito trapped in glass. Ch'üeh-erh sat in the dust, licking its paw. The car came sleek and unmarked, glinting like wet ink. We have trucks here, coughing black phlegm. We have bicycles. Yet it rolled on, in a hurry, wheels turning as if the road itself spooled them forward.

The cat didn’t flinch.

A dull crunch, like a melon split open. The car slid past. Where Ch'üeh-erh had been, only the road remained—blurred, wavering. No blood, no body. Just a heat-shimmer where the dust settled.

At dinner, the congee trembled. I asked about the cat.

Father’s chopsticks paused. “What cat?”

Mother scraped her bowl. “There was a stray. Got hit by the tofu cart, maybe. Years ago.”

The well’s water, when I peered in, showed only my face—pale, floating. Ripples warped it into something shapeless. That night, the air smelled of burnt wires. The cicadas stopped. Through my window, the banyan shuddered, though there was no wind.

Days now fold into one another. The cat’s absence is a hole in the heat. I watch the road. Trucks pass, carts clatter, but the sleek car never returns. The well’s dampness creeps into my shoes. Father’s radio mutters numbers. Mother snaps radishes, their flesh white as bone.

Sometimes, I catch a flicker—a dun shadow, a twitch of tail—but when I turn, it’s only a leaf skittering, or Old Chen’s rag-dog nosing for scraps. The road stays empty. The lichen grows back, bluer each time.

At night, I count the cracks in the ceiling. They branch like roots. If I stare long enough, they pulse. The village breathes. The well exhales.

In the morning, my congee cools, skin forming on its surface. A thousand eyes, staring up.

I stir them under.

This piece first took shape in 2017, a flicker in the digital dust. Unearthed recently from a forgotten fold in the hard drive, it felt like discovering an old photograph, familiar yet distant. Returning to it wasn't merely revision; much was stripped away, altered, rearranged, until what remains bears only the faintest echo of its first form. It breathes now as something new.

Perhaps the intervening years allowed other influences to seep in. Kafka's shadow has lingered, and a sense of the absurd, of things slightly askew, inevitably permeated the writing. But the story's most authentic roots burrow into childhood memory. I grew up beside a river in Jiangnan, its water a constant presence just beyond our door. Stray cats arrived, one by one, settling into the periphery of our lives like quiet thoughts. Then, just as quietly, they vanished. The truth, learned later, was simple: my family had taken them across the river, to a place from which return seemed impossible. To my child's mind, that narrow water and the small bridge spanning it were an absolute threshold, the edge of the known world. Our side was everything. I remember crossing over a few times, searching for them amongst unfamiliar paths, a small, futile pilgrimage. Even then, some of me understood the pointlessness – finding them wouldn't bridge the distance.

This story, then, is perhaps a vessel for what settled from that time: the quiet weight of loss, the shape of confusion, the stark lines of boundaries, both seen and unseen, that marked the landscape of childhood. It is that feeling, distilled and reimagined.

The Hidden Costs of Numeronyms in Tech Communication

2021-10-27T00:00:00.000Z

In the fast-paced world of software engineering, we frequently encounter a specific type of abbreviation: the numeronym. Terms like k8s (Kubernetes) and i18n (Internationalization) are widely used and understood within certain circles. They work by keeping a word’s first and last letters and replacing the letters in between with their count.

This practice didn’t arise by accident. In a technical culture that values efficiency and brevity, especially when dealing with long or awkward terms, numeronyms offer an appealing shortcut. They are quick to type, save screen space, and can foster a sense of belonging among those familiar with the jargon. For instance, k8s is much shorter than Kubernetes, and its pronunciation (kayts) arguably has a subtle connection to the original word, perhaps aiding its adoption.

However, when we look closer, the perceived convenience of numeronyms often comes with significant hidden costs, potentially outweighing the benefits.

Cognitive Load and Communication Ambiguity

The most immediate problem with numeronyms is the extra cognitive load they place on the reader. Unlike full words or well-established initialisms (like API for Application Programming Interface), numeronyms carry no inherent semantic meaning. A reader must perform an extra decoding step: recognize it as a numeronym, then recall or look up the original term it represents.

This decoding might become automatic for industry insiders for highly popular examples like k8s and i18n. But the tech landscape constantly evolves, bringing forth a steady stream of new concepts and tools and less common numeronyms. Consider examples like:

a11y (Accessibility)
l10n (Localization)
i14y (Interoperability)
m12n (Modularization)

Encountering these less familiar numeronyms often forces even experienced engineers to pause, think, or search, disrupting reading flow and reducing communication efficiency. This ambiguity can easily lead to misunderstandings, especially in documentation, code comments, or cross-team communication.

The Double-Edged Sword of Jargon

Like other forms of industry jargon, numeronyms can speed up communication within a group that shares the same context and vocabulary. However, they inherently create barriers for others. For newcomers, collaborators from different domains, or even senior developers unfamiliar with a specific technology, these “trendy” abbreviations act more like hurdles than helpful shortcuts.

While not everyone using numeronyms intends to gatekeep or show off, the objective effect can be restricted information flow and the formation of information silos. In a modern tech environment emphasizing collaboration, knowledge sharing, and inclusivity, practices that unintentionally raise cognitive barriers deserve careful consideration.

The Irony of “a11y”

The numeronym a11y warrants special attention because it perfectly encapsulates the contradictions of this practice. It stands for Accessibility, a core principle focused on making products and information usable and understandable by the broadest possible audience, including people with disabilities.

Yet, the abbreviation a11y itself violates fundamental principles of accessibility:

Not Easily Recognizable: It’s opaque to those unfamiliar.
Unintuitive Pronunciation: Often pronounced as /æli/ (like “alley”) or /əˈlɛvənˌwaɪ/ (literally “eleven why”). The latter, sounding out the three syllables of “eleven,” is arguably longer and more complex than the “accessibility” part of the original word, defeating the purpose of abbreviation.
Lack of Universality: It’s far less widely known than k8s or i18n.

An abbreviation representing the concept of “easy access” is itself difficult to access, pronounce, and remember – a profound irony. It is a stark reminder that conciseness should not come at the expense of clarity and inclusion.

Conclusion: Prioritize Clarity

Numeronyms exist as a cultural phenomenon within the tech community. They are born from certain needs and have some value in specific contexts. We don’t need to completely ban established terms like k8s.

However, we should use numeronyms cautiously in broader communication scenarios – especially official documentation, tutorials, public announcements, and any situation where clarity is paramount. Opting for the whole, unambiguous term might require a few extra keystrokes, but it pays dividends in lower cognitive load, reduced ambiguity, and better comprehension for a wider audience.

Clear and precise communication is fundamental to collaboration and innovation in technology. As we strive for efficiency, let’s remain mindful of effectiveness and inclusivity, ensuring our “shortcuts” don’t become roadblocks for others.

How to Install ArchLinux on a Virtual Machine

2018-06-20T00:00:00.000Z

Preface

Many people mention that their first reaction to ArchLinux is the difficulty of installation. There are several reasons for this difficulty, which we will address next.

No graphic user interface: ArchLinux only provides a minimal environment. All of the install operations should be completed in the command line. This is the most difficult to overcome for many people who do not have experience in command line operations. Many Linux distributions can be popular because they provide user-friendly and streamlined installation processes. This has helped many people solve the first step in learning Linux: Installing a Linux.
Insufficient prior knowledge and lack the ability to find and solve problems: No exposure to knowledge that is important to installing operating systems, such as system booting, configuration file editing, and command-line operations. Once the results of their operation do not match the tutorial, they do not know how to solve the problem.
Lack of proper tutorials: The best and most complete tutorial for installing ArchLinux is the official Installation guide and Wiki. Since the official Wiki is written in a way similar to the documentation, there is no chronological step-by-step installation process that we are used to, causing difficulties for people who are unfamiliar with this type of writing in reading and using. Other tutorials are often outdated or do not take into account the reader’s understanding of Linux, ignoring some of the newcomers who are prone to making mistakes.

This tutorial is designed to be consistent with the existing official Wiki and includes links that are suitable for beginners to learn. I hope that anyone who has read this tutorial will be able to improve their ability to learn existing and future new official Wiki content.

The advantages of ArchLinux or Linux are not mentioned here. I betlieve that people who will review this tutorial must have already understood it. And you can get a lot from this process.

Precautions

Be sure to read each instruction in the tutorial carefully. Most of the installation failures were caused by not reading the tutorial carefully, missing or misdirecting instructions. Be sure to understand the contents of the tutorial, not just enter the command without understanding the description.

Installation Tutorial

Pre-installation

The installation media and their GnuPG signatures can be acquired from the Download page.

Choose a mirror site locates in your region, then download the iso image file looks like archlinux-**-x86_64.iso.

Verify Signature

It is recommended to verify the image signature before use, especially when downloading from an HTTP mirror, where downloads are generally prone to be intercepted to serve malicious images.

If you are using a windows operating system with 7-zip installed, right-click on the downloaded iso image file. Choose CRC SHA>SHA1, then you can see the signature of the image. If the signature does not match what is displayed on the Download page, please re-download the image file from the correct URL.

Create a Virtual Machine

Before creating the virtual machine, enter the BIOS. If the CPU of your physical machine is a Intel CPU, enable Intel VT. Or the CPU is an AMD CPU, enable AMD-V.

Reboot the system and open VMware Workstation. Click on Create a New Virtual Machine.

Select I will install the operating system later.
In the Guest operating system option, choose Linux. Select the version Other Linux 5.x or later kernel 64-bit
Resize the Maximum disk size and choose Store virtual disk as a single file.
Click on Customize Hardware.... Enter the appropriate value of memory and processors for this virtual machine.
Change the New CD/DVD (IDE) connection. Choose Use ISO image file:. Click on Browse... to open the path of the image file and select it.
In Virtualization engine, check the three boxes Virtualize Intel VT-x/EPT or AMD-V/RVI, Virtualize CPU performance counters and Virtualize IOMMU (IO memory management unit).
If you want to install a user graphic interface after installing ArchLinux, it is recommended to check the box Accelerate 3D graphics in Display-3D graphics.

Boot the Live Environment

Click on Power on this virtual machine. After startup, you will see the following interface.

If you do not see this interface, please check the integrity of the iso image file.

Select the first option Boot Arch Linux (x86_64) and press Enter to enter the installation environment.
At this point, ArchLinux starts loading and you will see the screen showing the following.

After the loading is complete, you will enter an interface with a command line.

If FAIL or other error message appears and it cannot be started, please search for the error message to get the solution.

If you are unfamiliar with the common operations of the Linux command line, please learn some of the common shortcuts or commands below.

Tab: Command-line auto-completion. Type the first few characters of the command or file name and press Tab, it will automatically complete the command or display all commands that match the characters you type. ↑ or Ctrl+p: Display the previous command. ↓ or Ctrl+n: Display the next command. Ctrl+c: Terminate the currently executing command.

For other commonly used shortcuts, you can view 10 Linux Shortcuts You Can’t Live Without.

Set the Keyboard Layout (Optional)

If your current keyboard layout is US, you can skip this step.

The default console keymap of ArchLinux is US. Available layouts can be listed with:

ls /usr/share/kbd/keymaps/**/*.map.gz

To modify the layout, append a corresponding file name to loadkeys, omitting path and file extension. For example, to set a German keyboard layout:

loadkeys de-latin1

Console fonts are located in /usr/share/kbd/consolefonts/ and can likewise be set with setfont.

Verify the Boot Mode

In fact, the default boot mode provided by VMware Workstation is BIOS+MBR.

Enter the following command, you can see that there is no partition whose Type is EFI System.

fdisk -l

Connect to the Internet

Archlinux cannot be installed offline. We need to download the required components online. Therefore, next we have to connect to the Internet.

Make sure your physical machine is connected to the Internet.

Enter and execute the following command to obtain the IP address.

dhcpcd

Then enter and execute the following command to determine if the network connection is working.

ping www.google.com

If you can see something like the following, it means that ArchLinux is connected to the Internet.

Tip: Use the shortcut Ctrl+c to terminate the currently executing command.

Update the System Clock

Use timedatectl to ensure the system clock is accurate:

timedatectl set-ntp true

Under normal circumstances, this command does not output anything.

Part the Disks

When recognized by the live system, the virtual disk is assigned to a block device /dev/sda. Enter and execute the following command to view current partition status.

fdisk -l

The partition status has been shown previously.

Enter and execute the following command to create a root partition.

fdisk /dev/sda

Enter o to create a new MBR partition table.
Enter n to create a new partition.
- First select the partition type, press Enter to select the default option primary.
- Then you need to assign a partition number to the new partition. Press Enter to use the default partition number 1.
- Select the first sector. Under normal circumstances, you can press Enter directly to use the default value.
- Select the last sector. Enter the value of the last sector and press Enter. If you want to make the newly created partition completely occupy the free disk space, you can directly press Enter to use the default value of the last sector.
Enter p to view the newly created partition. You can see something like the following.
Enter w to write all previous operations to the disk.
Once the partitions have been created, each must be formatted with an appropriate file system. Enter and execute the following command to format the root partition you just created.

mkfs.ext4 /dev/sda1

Mount the File Systems

Enter and execute the following command to mount the file system on the root partition to /mnt.

mount /dev/sda1 /mnt

Installation

From this step, we need to do some file editing operations. So you need to master the basic operations of a well-known command-line editor Vim. It is recommended to learn from Interactive Vim Tutorial. You just need to know how to edit, copy, paste and save a file with Vim.

Select the Mirrors

The mirrors are the sources of the package we downloaded. We need to select different mirrors according to our region to speed up the download.

Enter and execute the following command to use vim to edit the file /etc/pacman.d/mirrorlist.

vim /etc/pacman.d/mirrorlist

Tip: When entering the path, you can use Tab to auto-complete it.

The higher a mirror is placed in the list, the more priority it is given when downloading a package. You need to move the geographically closest mirrors to the top of the list.

For example, use :/China to find the mirrors under the string China. Press dd in NORMAL mode to cut the line under the cursor. Press gg to return to the beginning of the file. Press P (uppercase) to paste the line to the front of the file.

Manually input Zhengjiang University Mirror after Tsinghua University Mirror pasted before.

## China
Server = http://mirrors.tuna.tsinghua.edu.cn/archlinux/$repo/os/$arch
Server = http://mirrors.zju.edu.cn/archlinux/$repo/os/$arch

Input :wq to save and quit the file.

Install Essential Packages

The next step is to install the base ArchLinux package to the disk. This is an online download and installation process. Use the pacstrap script to install the base package, Linux kernel and firmware for common hardware.

pacstrap /mnt base base-devel linux dhcpcd

Depending on the download speed, you need to wait for a while here. When the command prompt reappears, you can proceed to the next step.

Configure the System

After installing the base package of ArchLinux, we need to configure the system.

Fstab

Enter and execute the following command to generate an fstab file which is used to mount partitions automatically.

genfstab -L /mnt >> /mnt/etc/fstab

Since this step is important, we need to output the generated file to check if it is correct. Enter and execute the following command.

cat /mnt/etc/fstab

We can see that /dev/sda1 is mounted to the root partition.

Chroot

Change root into the new system. chroot means change root, which is equivalent to handing over the control to the newly installed ArchLinux system. After performing this step, our operations are performed on the newly installed system on the disk.

Enter and execute the following command.

arch-chroot /mnt

Time Zone

Enter and execute the following command to set the time zone to your region.

ln -sf /usr/share/zoneinfo/Region/City /etc/localtime

For example, we can set the time zone to Shanghai.

ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

Run hwclock to generate /etc/adjtime:

hwclock --systohc

Install Required Package

Because we have chroot to the new system, there are only some of the most basic packages. At this time, we need to install some required packages ourselves. Then this tutorial will introduce ArchLinux’s package management tool pacman. In most cases, a single line of commands can solve the problem of packages and their dependencies.

The command format of installing new packages is pacman -S packagename. Pacman will automatically check the other packages (dependencies) needed for this package and install them together. Below we will install some packages through pacman. These packages will be used later.

Enter and execute the following command.

pacman -S vim dialog wpa_supplicant networkmanager

Localization

Set the languages we use. Use Vim to edit /etc/locale.gen.

vim /etc/locale.gen

Uncomment en_US.UTF-8 UTF-8 and other needed locales in /etc/locale.gen, and generate them with:

locale-gen

For example, we can use :/ to find zh_CN.UTF-8 UTF-8, zh_HK.UTF-8 UTF-8, zh_TW.UTF-8 UTF-8 and en_US.UTF-8 UTF-8 then delete the # before them.

Create (when the file does not exist, Vim will create a file with the same name) the locale.conf file.

vim /etc/locale.conf

Add the following to the first line of the file.

LANG=en_US.UTF-8

Input :wq to save and quit the file.

Network Configuration

Create the hostname file.

vim /etc/hostname

Enter your own myhostname in the first line of the file.

Input :wq to save and quit the file.

Edit the /etc/hosts file.

vim /etc/hosts

Add the following at the end of the file (replace myhostname with your own hostname).

127.0.0.1 localhost ::1 localhost 127.0.1.1 myhostname.localdomain myhostname

Input :wq to save and quit the file.

Root Password

Set the root password.

passwd

Type and retype your root password.

BootLoader

Choose and install a Linux-capable boot loader. Here we install the most popular boot loader Grub2.

First install os-prober and ntfs-3g, which can be used with Grub to detect existing systems and automatically set startup options.
```
pacman -S os-prober ntfs-3g
```
Install grub.
```
pacman -S grub
```
Deploy grub.
```
grub-install --target=i386-pc /dev/sda
```
Generate the configuration file.
```
grub-mkconfig -o /boot/grub/grub.cfg
```

If you do not see the message as shown, please double-check that the above process is completed correctly.

BootLoader Check

Use the following command to check whether the entry of the system is successfully generated. If it is not generated normally, there will be no system entry when booting.

vim /boot/grub/grub.cfg

Check if there is an ArchLinux entry near the end of the menuentry section. The following figure shows the detected ArchLinux entry.

If you do not see ArchLinux entry or the file grub.cfg does not exist, please check the directory /boot first.

See if there are files initramfs-linux-fallback.img initramfs-linux.img intel-ucode.img and vmlinuz-linux. If not, the Linux kernel is not deployed properly. This is most likely caused by the /boot directory not being properly mounted. After confirming that the /boot directory is correct, you can redeploy the Linux kernel.

Pacman -S linux

Then regenerate the configuration file grub.cfg and try to find the system entry.

Reboot

Exit the chroot environment by typing exit or pressing Ctrl+d.

Finally, restart the machine by typing reboot.

Click on Edit virtual machine settings. Change the CD/DVD (IDE) connection. Choose Use physical drive: Auto detect. Now you have removed the installation media and then you can login into the new system with the root account.

Post-installation

See General recommendations for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).

For a list of applications that may be of interest, see List of applications.

Eigenigma

The Node That Never Sleeps

I. Where Things Stand

II. The Breaker

III. Withholding Judgment

IV. Ruling Things Out

V. The Invisible Fault

VI. Limping Along

VII. Certainty

Two Weeks of Self-Hosting CJK Fonts: From Lighthouse to CLReq

1. The Trigger

2. Phase One: Self-Hosting and Iterative Subsetting

3. Two Cracks

4. Phase Two: From Per-Page Slicing to unicode-range, and Retiring Heti

5. Chinese Typography Was Never Just About Fonts

6. The Web Platform's Debt to CJK

LLM as the Omnipotent Implied Reader: An Addiction Mechanism Beyond Sycophancy

1. The Sycophancy Trap

2. You Are Not Conversing. You Are Writing

The Computational Fact

So What Is Dialogue, Then?

Three Objections Worth Taking Seriously

Where This Leaves Us

3. The Omnipotent Implied Reader

4. Temporal Short-Circuit

5. The Double Supposition

6. Coda: The Editable Subject

My Digital Legacy Architecture: A Personal Manifesto for Weathering Technological Tides

1. First-Principles Architecture: Embrace Composability, Abandon Silver Bullets

Principle 1: Separate Content from Presentation

Principle 2: Open & Plain-Text First

Principle 3: Data Ownership & Control

Principle 4: Composable & Replaceable Architecture

2. The Pain of Migration: A Decade of Digital Nomadism

3. North Star & Crossroads: A Decision Framework Emerges

Option 1: Stay (or double down) in Netlify’s ecosystem

Option 2: Move to Supabase—into a bigger “garden”

Option 3: Go back to basics—temptation of a VPS

Option 4: Modern PaaS—a middle ground

4. Fatal Coupling: A Next.js Case Study

5. A Blueprint for Decades Ahead: My Personal Digital-Legacy Architecture

Layer 1: The Content Bedrock

Layer 2: The Media Warehouse

Layer 3: The Logic Brain

Layer 4: The Presentation Skin

A Gradual-Migration Strategy

Epilogue: Simplicity Is the Ultimate Sophistication

8 Hours and 2,000 Lines of Code: A Blog-Category Tool’s Runaway Journey

Genesis: A Five-Minute Fix

Act I: A Snowball Out of Control

10:30 a.m.—From One-Off Script to CLI Tool

12 p.m.—Feature Creep: Adding sync

3 p.m.—Refactor: Embracing Layered Architecture

5 p.m.—Rounding Out Features: fixup and File Locks

Act II: Reflection & Re-evaluation

Efficiency: The ROI Is Terrible

Experience: The Process Has Intrinsic Value

Content: An Unexpected Bonus

Epilogue: Rethinking “overengineering”

Postscript: Balancing Idealism and Reality

A Title in Rainbow Gradient

AI’s “Smell Test”: From Outcome Supervision to Process Supervision—How Do We Teach Machines to Truly Think?

Diagnosing the Ailment: Why Does AI Lack a “Sense of Smell”?

Result Data vs. Process Data

The Iceberg Behind Fermat’s Last Theorem

The “Scarcity Trap” of Process Data

The Bottleneck Revealed: A Master of Form, a Mimic in Essence

Breaking the Deadlock: Three Waves of Process Supervision

Stage 1 Theoretical Foundations and the Costly “Gold Standard” (2023)

Stage 2 Automation on the Offensive—A Race to Cut Costs (2024)

Stage 3 Paradigm Shift and Generative Intelligence (2025)

New Challenges on the Horizon

New Bottleneck 1 Compute Economics

New Bottleneck 2 The Return of Explainability

New Bottleneck 3 Lagging Evaluation and Safety

Conclusion From Feeding Data to Building Ecosystems

No Pictures in the Mind — A Belated Recognition of My Aphantasia

AI and Intellectual Levelling — Reflections Sparked by a Foray into Russian Letters

Deep Dive: Arc Browser & AeroSpace Focus Conflict Leading to Workspace Flashback Bug on macOS

The Problem: Frustrating Workspace Snapback

4. Phase Two: From Per-Page Slicing to `unicode-range`, and Retiring Heti

10:30 a.m.—From One-Off Script to CLI Tool

12 p.m.—Feature Creep: Adding `sync`

3 p.m.—Refactor: Embracing Layered Architecture

5 p.m.—Rounding Out Features: `fixup` and File Locks

Pinpointing the Culprit: `makeKeyAndOrderFront:`

Implementation: A Custom `<Chart>` Component

Why Not Just Use an `<iframe>`?