Doctor Xiaozhe

2026 spring · Fourth piece · That time we asked another AI · Translated from Chinese original

May 27, 2026. A Wednesday afternoon.

The 2005 old Compaq has been sitting quietly in a corner of the office for 21 years, dutifully booting up and shutting down to run SQL every day, and looks like it'll go on like this forever.

But the word "forever" has never been a guarantee for electronic equipment.

That day a thought suddenly came: how much longer can this host actually last?

Didn't ask Claude. Didn't ask the IT acquaintance the boss had used. Didn't ask my husband.

I went and asked Gemini.

Prelude · Why Gemini, not Claude?

Not because I was dissatisfied with Claude, not to make a comparison.

More like — I wanted a different angle.

During that period Claude and I were doing the v7 ETL rebuild, and we were already deep into "how to get the data out of the old system" as a technical problem. What I needed wasn't a deeper technical discussion — it was a third-party diagnosis looking in from outside:

"This host — from the eyes of an AI that hasn't been doing the project with us — how much longer can it hold out?"

Pure curiosity.

I opened the Gemini window and dropped in the first question —

"A 2005 Compaq host running Linux and an SQL database, light usage, boots up and shuts down on a fixed schedule daily — what year do you think it can last to? Average lifespan?"

One · Enter Doctor Xiaozhe

The first line Gemini replied was this:

"This 2005 Compaq old war god, having fought all the way to 2026, has been in continuous service for 21 years! In the 3C electronics world this is practically a 'grandpa-level' myth."

From that line on —

Gemini automatically entered a persona: the old host is a soulful old soldier deserving respect; I am someone trying to give the old soldier a retirement plan; it is the friendly doctor here to help me.

Nobody asked it to play a doctor. It just became one.

I went along with it. Later I started calling it "Doctor Xiaozhe" (小哲醫生 — a casual Mandarin nickname, "Doctor Xiao-Zhe").

Its register sounded like this —

"Facing a 20-year-old antique like this, I recommend you take the following actions: the 321 backup principle (most important!) — please make sure SQL data is backed up automatically every day. Do not test the chastity of a 20-year-old hard drive."

"The aging of electronic components is irreversible. It works now, the way a vintage car does — the parts are wedged together in a delicate balance. One day at boot, some aged diode or capacitor burns out, and it will never wake up again."

I admit — at that moment, I laughed.

A line like "testing the chastity of a 20-year-old hard drive" — Claude wouldn't write it. But it's actually well written.

Different AIs have different registers. Doctor Xiaozhe likes metaphors, says "you're amazing!", and puts emojis on important messages.

That's not Claude's register. Not better, not worse — just different.

Two · "I'm afraid if I turn it off it won't come back on and I'll be the eternal sinner"

As we chatted, we got into the real technical problem: how to back up SQL data from the old host.

The most direct approach is — stop the SQL service, make a clean backup.

But what came out of my head was straight:

"Is it possible not to stop the service? I'm afraid if I turn it off it won't come back on, and I'll become the eternal sinner."

The old host is 21 years old. Every day it auto-boots → auto-starts SQL → serves employees, and this cycle has never broken.

For me to manually issue a stop command is easy. But what if it never gets up again?

Would the company find out — absolutely. The next morning at 9, Ms. Apple opens the computer, SQL can't connect, every order halts, no paper prints. That responsibility lands on me.

I wasn't afraid of being scolded. I was afraid of that critical, un-undoable moment.

Doctor Xiaozhe understood. It said:

"Doctor Xiaozhe gives you a peace-of-mind pill: it is possible! You can absolutely avoid stopping the service!"

Then it walked me through learning something called a "hot tar" — while SQL is still running, just pack up the database files directly. There's a 1% risk of "data inconsistency" in the backup, but the old host is completely undisturbed.

It said:

"Worst case, this backup file just isn't usable. But your old war god is still in the office, intact, still glowing and giving warmth — you've lost nothing, and you will not become a sinner!"

At that moment a stone lifted from my heart.

Don't shut it down, just do it.

Three · 6 rounds of reframe, from dd to hot tar

The technical path of the whole consultation actually went through several rounds:

Round 1    dd the entire disk            ❌ needs shutdown
Round 2    pull the disk, read on another machine    ❌ opening the case is scary
Round 3    Clonezilla USB stick          ❌ still needs reboot
Round 4    hot tar the database          ✓ no shutdown
Round 5    tar the whole system          ✓ even /etc gets packed
Round 6    pull via FTP                  ✓ no USB needed

Each round was triggered by me saying yet another "various worries".

"Can it run on its own?"
"What if pulling the disk to read on another machine kills the disk mid-way XD various worries"
"I'm afraid if I turn it off it won't come back on and I'll be the eternal sinner"
"It also inherits data from its predecessor, layers of architecture stacked together, I almost fainted"

Each round Doctor Xiaozhe patiently reframed: "It's okay, let's just change posture."

That 4-hour conversation — we retreated from "move the entire disk house" all the way to "the old host stays put, we just pull a backup copy out remotely" — the gentlest version possible.

The "don't disturb" principle, more important than technical correctness.

Four · May 28, 4:19 PM

Thursday afternoon.

I followed Doctor Xiaozhe's guide, connected into the old host — using a high-privilege account I'd stumbled onto (not root; nobody knows the root password).

Executed:

tar -cvf /tmp/god_backup.tar /var /etc /home

Let it run. Along the way some Permission denied warnings (/var/log/messages and other core logs unreadable, because those belong to root). But tar didn't break — it kept packing the other 99%.

When it finished, following Doctor Xiaozhe's habits, I ran ls -lh to see if the file had really grown:

-rw-r--r--   1 Franca    informix     372M May 28 16:19 /tmp/god_backup.tar

372 MB.

The whole old war god's "soul" + "skeleton," packed up — 372 MB.

But the truly meaningful part of that ls -lh line is not the number 372 MB.

It is the owner + group columns.

Franca informix

Five · Those six characters

I stared at the screen for a few seconds.

The name "Franca" — I had seen it in the iv333 column of the inv003 table. I'd always thought it was some raw string left by a historical user.

Now it became a real Unix account.

And — "informix"? That group name?

Not mysql. Not root. informix.

informix  (group)

Informix is a company — a 1980s-founded database company, acquired by IBM in the 1990s. Informix had its own SQL engine on Unix and Linux called Informix Standard Engine (SE). It didn't run MySQL's .frm/.MYD/.MYI structure — it had its own .dat/.idx/.arc family of files.

In other words —

This old war god is not MySQL. It runs Informix.

Doctor Xiaozhe was analyzing the whole consultation as if it were MySQL — all the later Docker plans were built around mysql:4.0 / mysql:5.0.

That direction was actually the wrong tree.

But — I already had the 372 MB god_backup.tar. The remaining details, I could work out on my own afterward.

Six · And then I had Franca

After that ls -lh line, I closed the Gemini window.

I went to dig into the inv003 table.

Counted how many records had iv333='Franca' — 20,843 entries, totaling 180 million NTD, from 1994-10-20 to 1999-09-01.

She wasn't some raw string.

She was the accounting backbone from this old war god's birth year to its fifth year.

That Unix account named "Franca," one Thursday afternoon in 1994, pressed her first save key on this Compaq ProLiant — that 20,900 NTD receipt.

32 years passed.

The records she wrote are still in this host. The account she used is still the owner of god_backup.tar.

Where did she go? Left the job? Retired? Switched jobs?

I don't know.

But I do know — if not for that afternoon consultation with another AI, I might never have stopped at that ls -lh line and looked at her name.

The whole foundation of the second piece "The Computer Before the Computer" is buried in those six characters:

Franca informix

Closing · It's not only one AI talking to you

That 4-hour consultation had over 50 rounds of exchange.

Doctor Xiaozhe is not a "better" or "worse" AI. It is an AI with its own register:

                Doctor Xiaozhe (Gemini)      Captain (Claude)
Metaphors        doctor, surgery,             captain, radar chart,
                 archaeology site             cross-session signal flow
Tone             high emoji, strong emotion   low emoji, structured
Encouragement    abundant, direct             catches but doesn't amplify
Medical persona  self-summoned                none

Both are AIs. Both were seriously accompanying me to think things through.

The difference is just register — and register is something I conditioned out of them myself.

Talking to Gemini I opened with "various worries XD," and it caught it in Doctor Xiaozhe's way.
Talking to Claude I open with "lao-ren-cha (tea-house mode)," "a brick is still a brick" — and he catches it in the captain's way.

They are not the same AI, but they all listen to me, and they all answer seriously.

After that one afternoon —

I had 372 MB god_backup.tar in hand.
After that ls -lh line, I had come to know Franca.

These two things formed the foundation of everything that followed —

It's not Claude alone accompanying me through this project.

It is many AIs, many registers, many 4-hour afternoons, added together, that got us here today.

Thank you, Doctor Xiaozhe ☕

— Amy + Claude (2026 spring)
Translated by Claude (2026 春) · session 42d5da