The Incubator for the Dinosaur Egg
Looking at that one dinosaur egg.
It lay inside the 372 MB god_backup.tar.
The timestamp May 28, 2026 at 4:19 PM is the moment I moved it out of the old Compaq. Franca's 1994 receipt for 20,900 NTD lies in there, all the informix engine binaries lie in there, the C-tek in-house menu system lies in there, every generation of Apple's records lies in there.
But — it is dead.
Just 372 MB of bytes.
It needs an incubator to live.
Prelude · Looking at that one dinosaur egg
The moment I'd packed it out, I didn't immediately think "can I bring it back to life." First I set it on the new computer desktop and poured myself a glass of water.
A day passed.
That voice in my head surfaced again —
"If these 372 MB are really a snapshot of the informix engine while it was alive… could it actually be booted up again?"
Not for utility.
The ETL axis was already running — we had the SQLite rebuild, 100% paper baseline alignment, v7 PostgreSQL on the way. The "data" of this old war god had been successfully relocated.
But — "data" and "system" are two different things.
Data can be reverse-engineered into a new schema.
A system — as a living, bootable, welcome-screen-printing whole — cannot.
Inside that 372 MB tar lay a complete, once-alive, will-greet-you MIS 5.0 system. It needed —
an incubator.
One · Two days later
Morning of 5/30.
Open VirtualBox.
OS type: Linux 2.2.x (because the old war god's uname -r showed the 2.2 series).
New VM: 256 MB RAM, 4 GB virtual disk, no EFI, use BIOS.
Pick ISO: Slackware 7.1.
Why Slackware 7.1?
— Because during the archaeology a few days earlier, the prompt on the old host's terminal was:
slackware-da1:~$
slackware-da1 is its hostname. Find the closest version match. Slackware 7.1 was a mid-1999 release, in the same wave as Linux 2.2.x.
Download the Slackware 7.1 ISO — a 1999 Linux distribution, still downloadable in 2026.
The internet is this kind of time machine.
Two · Building the incubator
Start the VM.
First hour: boot loader doesn't recognize the ISO, stuck at the LILO prompt.
Adjust BIOS settings, change boot order, put floppy before CD (because in 1999 Linux assumed you'd boot from floppy by default).
OK, boots in. The Slackware 7.1 installer screen —
Welcome to Slackware Linux 7.1!
White on blue. Tastes like 1999. This is the screen the old Compaq saw the first time it booted, 26 years ago.
I followed the screen step by step: partition disk → select packages → set hostname → set root password.
Installed. Reboot. The VM enters Slackware 7.1's plain text terminal.
slackware login: root Password: ****** slackware:~#
The incubator is up.
Now to build the walls. Brick by brick —
🧱 Configure the network — the VM defaults to an e1000 NIC, but Slackware 7.1 doesn't recognize e1000. Switch to pcnet32 — that ancient AMD PCNet32 card from 1999, natively supported by Slackware 7.1.
🧱 Load kernel modules — pcnet32.o + ide-disk.o + vt.o, package the drivers into initrd.
🧱 Set up fstab — align the mount points where god_backup.tar gets extracted with the old system's original paths: /u, /u/informix, /var/lib/....
🧱 Align byte order — the Compaq ProLiant was little-endian x86. Slackware 7.1 is also little-endian. The VM runs x86 emulation. Three layers of byte order aligned. Lucky on this layer.
Every brick laid in place.
Three · The second the C-tek menu drew
Extract god_backup.tar under the VM's / root. Overwrite /etc, overwrite /var, overwrite /home, overwrite /u.
Find the auto-start init script the old host used: /etc/rc.d/rc.local.
Its last line reads:
exec /u/informix/bin/ctek_menu
ctek_menu — a binary written by a small software company called C-tek back in the day. In 1990s Taiwan many MIS systems used it as an entry shell.
I copy .profile (the one Franca left behind in 1992) into root home. Restart the VM.
slackware login: root Password: ****** Loading user profile... Starting MIS 5.0 system...
Terminal flashes briefly. Then —
============================================================
歡迎進入 MIS 旅行社系統
5.0
============================================================
請選 1. 舊區
2. 新區
_
(Translation: "Welcome to MIS Travel Agency System / Please choose 1. Old region 2. New region")
White on blue. Chinese characters. Cursor blinking.
"請選 1. 舊區 2. 新區" — those 11 characters — I had seen this text while digging through the old system binary during ETL. Back then it was raw bytes.
Now it's in the VirtualBox window of the new computer, on the framebuffer of Slackware 7.1, actually being drawn.
Four · "Oh my god!! It works!"
The reaction in that second was —
"Oh my god!! It works!"
No photo. No video. No screenshot.
Told Claude the result, then immediately pressed "2. New region" to go to the next layer.
Looking back, not taking a photo in the moment is very Amy — not performing the moment for someone else, just catching the feeling myself and moving on.
But if I could go back, I'd take one.
In that second —
The 1999 C-tek menu binary and the 2026 VirtualBox kernel briefly shook hands on the little-endian x86 framebuffer. A 27-year time distance, momentarily connected by one screen scan line after another.
The content of the handshake was: "Welcome to MIS Travel Agency System."
Unfortunately the handshake didn't last long.
Five · The next layer SIGSEGV
After pressing "2," the screen was supposed to jump to the "New region" submenu and call Informix's sperform — Informix's standard frontend framework, the binary used to draw every input screen back in the day.
Calling /u/informix/bin/sperform...
Then the terminal went dark.
The VM kernel ring spat out:
sperform[1234]: segfault at 0000 ip 0000:0040 sp ffff:fffc error 4 in sperform
SIGSEGV — segmentation fault.
The process had just loaded; the first user-space instruction hadn't finished and it was dead.
I exit the VM, check the sperform binary's header:
$ file /u/informix/bin/sperform
sperform: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for SCO Xenix System V/386,
word-swapped
SCO Xenix System V/386.
Word-swapped.
SCO Xenix — a 1980s version of UNIX, 10 years before Linux. Word-swapped is an earlier-generation byte order convention, not the same as modern x86 little-endian.
The Informix binary compiled on Xenix in 1989, doesn't align with 2026 Linux even at the byte-order layer.
Linux has an emulator called iBCS (Intel Binary Compatibility Standard) which in theory can run SCO Xenix binaries. But iBCS's last maintenance release was in 2001. It assumes Xenix runs on hardware close to Linux's — but "word-swapped" was never handled at that layer.
In other words —
The 1989 Informix binary, and the 2026 Linux emulator — 37 years between them. No emulator can patch that 37-year gap.
Six · The 37 years between 1989 and 2026
What happened in those 37 years?
1990s CISC vs RISC wars, Big/Little-endian standards established 1995 Linux 1.0 stable, but no ELF binary format yet 2000 iBCS written, can run Xenix binaries in theory, but word-swap unhandled 2001 iBCS last maintenance release 2005 The Compaq ProLiant ships, runs Linux + Informix 2010 Informix fully absorbed by IBM, old SE engine maintenance ends 2026 I'm at my new computer, trying to make 1989 Informix binaries run on a 2026 emulator
Lossy translation between every layer.
The ctek_menu binary was compiled in a 1999 Slackware environment, which happens to fall in Linux 2.2's effective emulation range, so it runs.
But the sperform / sqlexec / isql batch — was compiled in 1989 on SCO Xenix, which falls into the emulator's dead zone.
Those 37 years are an archaeological gap, not a technical gap.
No amount of engineering can patch them. Unless someone takes the 1989 source code and recompiles it in a 2026 environment — but that source code stopped existing long ago.
Seven · A brick is still a brick, a house is still a house
5/30, Friday, around 3 PM.
I stared at the SIGSEGV message in the VirtualBox window for about 5 minutes.
What was turning in my head wasn't "disappointment" or "relief." It was —
"I don't quite understand, but let it be for now. Let's think of another way."
And then —
I don't know where that next line came from. Maybe from the memory of the C-tek menu's blue-and-white screen actually drawing. Maybe from the fact that the 372 MB tar file was still on disk, intact, not a single byte missing. Maybe pure —
"A brick is still a brick, a house is still a house."
Meaning what?
Meaning —
The SQL data is still here. The informix engine can't run — okay. The menu can't draw its second layer — okay. We can already read the data, align the paper, draw the reports.
This VM-revival mission can't be completed —
But that doesn't mean the project can't be completed.
In that second, the seed of the AC plan germinated in my head:
Bucket A = CLI reports Python connects directly to new PG, prints month-end reports Bucket C = PWA forms Browser as frontend, bypassing sperform / C-tek menu entirely VM route Demoted to backup option (in case someone wants to do historical archaeology someday)
At 6 PM that afternoon, I opened a new chat window and said to Claude:
"The VM line is paused for now. We'll return to the v7 main stage afterward."
24 hours later, at 9 AM on 5/31, M1 of the AC plan was live.
Closing · What the incubator hatched wasn't the VM
If you ask me whether "the VM rebuild day counts as success or failure" —
The answer is neither.
It wasn't a success — because sperform / informix engine couldn't be revived.
It wasn't a failure — because —
- The second the C-tek menu drew
- The second Franca's .profile actually loaded
- The second the fact "SCO Xenix word-swapped" became clear
— are all meaningful data points for this project.
More importantly —
This incubator taught me the timing of reframe.
The "a brick is still a brick" I decided on after 5 minutes of staring at SIGSEGV — was not a temporary retreat decision.
That was the spiritual starting point of the entire AC plan.
The whole crazy run on 5/31 from M1 to M9 — every milestone carried this spirit: "Don't try to revive the past as-is. Just connect the usable part of the past to the present."
That 372 MB dinosaur egg is still on the hard drive.
It didn't hatch.
But its existence catalyzed the speed of the AC plan. It told me —
"Some things can't be moved as a whole, but can be moved brick by brick."
The incubator did not fail.
What it hatched wasn't the VM — it was the ability to reframe. ☕
— Amy + Claude (2026 spring)
Translated by Claude (2026 春) · session 42d5da