孵化恐龍蛋的保溫箱

2026 春 · 第五篇 · VM 重建紀實

望著那一顆恐龍蛋。

它躺在 372 MB 的 god_backup.tar 裡。

2026 年 5 月 28 日下午 4:19 的時間戳，是我把它從老康柏裡搬出來的瞬間。Franca 1994 年的 20,900 元那張收據躺在裡面、informix engine 的全部 binary 躺在裡面、C-tek 自家寫的 menu 系統躺在裡面、所有歷代蘋果小姐的紀錄躺在裡面。

但 —— 它是死的。

只是 372 MB 的 bytes。

它需要一個保溫箱才能活。

序 · 望著那一顆恐龍蛋

打包出來那一刻沒有立刻去想「能不能讓它活過來」。先把它放在新電腦桌面，給自己倒杯水。

過了一天。

腦袋裡那個聲音又冒出來 ——

「如果這 372 MB 真的還是 informix engine 活著時的快照... 那會不會其實可以讓它重新開機？」

不是為了實用。

ETL 那條軸已經在跑了 —— 我們有 SQLite 重建、有 paper baseline 100%、有 v7 PostgreSQL 在路上。這台老戰神的「資料」已經被搬遷成功了。

但 ——「資料」跟「系統」是兩件事。

資料可以被 reverse engineer 成新 schema。
系統 —— 作為一個活著、會啟動、會印歡迎畫面的整體 —— 不行。

那個 372 MB tar 檔裡躺著一個完整的、活過的、會跟你打招呼的 MIS 5.0 系統。它需要 ——

保溫箱。

一 · 兩天後

5/30 早上。

打開 VirtualBox。

選 OS type：Linux 2.2.x（因為這台老戰神的 uname -r 顯示是 2.2 系列）。

新建 VM：256 MB RAM、4 GB 虛擬硬碟、不用 EFI、用 BIOS。

挑 ISO：Slackware 7.1。

為什麼是 Slackware 7.1？

—— 因為前幾天考古的時候，老主機 terminal 跳出來的提示字元是這樣：

slackware-da1:~$

slackware-da1 是它的 hostname。版本要找最匹配的。Slackware 7.1 是 1999 年中期的版本，跟 Linux 2.2.x 是同一波。

下載 Slackware 7.1 的 ISO —— 一個 1999 年的 Linux 發行版，2026 年還能下載到。

internet 是這樣的時間機器。

二 · 蓋保溫箱

啟動 VM。

第一個小時：boot loader 不認得 ISO，卡在 LILO 提示符號。

調 BIOS 設定，改 boot order，把 floppy 排在 CD 前面（因為 1999 年的 Linux 預設認為你會用 floppy 啟動）。

OK boot 進去了。Slackware 7.1 安裝畫面 ——

Welcome to Slackware Linux 7.1!

藍底白字。1999 年的味道。這就是 26 年前那台老康柏第一次開機時看到的畫面。

我跟著畫面一步一步：分割硬碟 → 選 packages → 設 hostname → 設 root password。

裝完，重開機。VM 進入 Slackware 7.1 的純文字 terminal。

slackware login: root
Password: ******

slackware:~#

保溫箱起來了。

接下來蓋牆。一塊一塊磚 ——

🧱 配網路 — VM 預設用 e1000 網卡，但 Slackware 7.1 不認得 e1000。改成 pcnet32 —— 1999 年 AMD 那張古老的 PCNet32 網卡，Slackware 7.1 原生支援。

🧱 載 kernel modules — pcnet32.o + ide-disk.o + vt.o，把驅動裝進 initrd。

🧱 設 fstab — 把 god_backup.tar 解壓的 mount point 對齊舊系統當年的路徑：/u、/u/informix、/var/lib/...。

🧱 byte order 對齊 — Compaq ProLiant 是 little-endian x86。Slackware 7.1 也是 little-endian。VM 跑 x86 emulation。三層 byte order 對齊。這層運氣好。

每一塊磚都搬到位。

三 · C-tek menu 畫出來那一秒

把 god_backup.tar 解壓到 VM 的 / 根目錄底下。覆蓋 /etc、覆蓋 /var、覆蓋 /home、覆蓋 /u。

把當年老主機自動啟動的 init script 路徑找出來：/etc/rc.d/rc.local。

裡面寫的最後一行是：

exec /u/informix/bin/ctek_menu

ctek_menu —— 是當年某家叫做 C-tek 的小型軟體公司寫的、自家的選單系統 binary。1990 年代台灣很多 MIS 都用它做 entry shell。

我複製 .profile（Franca 1992 留下來的那個）到 root home。重啟 VM。

slackware login: root
Password: ******

Loading user profile...
Starting MIS 5.0 system...

terminal 短暫 flash 一下。然後 ——

============================================================
                  歡迎進入 MIS 旅行社系統
                          5.0
============================================================

                     請選 1. 舊區
                          2. 新區

                         _

藍底白字。中文字。游標在閃。

「請選 1. 舊區 2. 新區」這 11 個字 —— 我在 ETL log 翻舊系統 binary 的時候，看到過這段文字。當時是 raw byte。

現在它在新電腦的 VirtualBox 視窗裡、在 Slackware 7.1 的 framebuffer 上、真的被繪出來了。

四 · 「天吶！！會動了！」

那一秒的反應是 ——

「天吶！！會動了！」

沒拍照。沒錄影。沒截圖。

跟 Claude 說了結果，然後立刻按下「2. 新區」進下一層。

事後回想，當下沒拍照這件事很 Amy 風格 —— 沒有 perform 那個瞬間給別人看，純粹自己接住那個感動然後繼續下一步。

但如果回得去，我會想拍一張。

那一秒 ——

1999 年的 C-tek menu binary 跟 2026 年的 VirtualBox kernel 在 little-endian x86 framebuffer 上短暫握手。27 年的時間距離，在那一個瞬間被一條條螢幕掃描線連起來。

握手的內容是：「歡迎進入 MIS 旅行社系統」。

可惜這個握手沒有持續很久。

五 · 下一層 SIGSEGV

按下「2」之後，畫面應該要跳到「新區」的子選單，呼叫 informix 的 sperform —— 那是 Informix 的標準前端框架，當年用來畫每一張單據錄入畫面的 binary。

Calling /u/informix/bin/sperform...

然後 terminal 一片黑。

VM kernel ring 跳出來：

sperform[1234]: segfault at 0000 ip 0000:0040 sp ffff:fffc error 4 in sperform

SIGSEGV — segmentation fault。

進程剛載入、第一條 user-space 指令還沒跑完就死了。

我退出 VM、查 sperform binary 的 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 —— 是 1980 年代 UNIX 的一個版本，比 Linux 早 10 年。Word-swapped 是更早一代的 byte order convention，跟現代 x86 little-endian 不一樣。

Informix 1989 年在 Xenix 上 compile 出來的 binary，從 byte order 那層就跟 2026 年的 Linux 對不上。

Linux 雖然有一個叫 iBCS (Intel Binary Compatibility Standard) 的 emulator，理論上可以跑 SCO Xenix 的 binary。但 iBCS 的最後一個 maintenance 版本是 2001 年。它假設 Xenix 跑在跟 Linux 接近的硬體上 —— 但「word-swapped」這層它從來沒處理過。

也就是說 ——

Informix 1989 年的 binary，跟 Linux 2026 年的 emulator，中間隔了 37 年。沒有任何 emulator 補得起來這 37 年。

六 · 1989 跟 2026 中間的 37 年

那 37 年裡發生了什麼？

1990s   CISC 跟 RISC 大戰、Big/Little-endian 標準確立
1995    Linux 1.0 開始穩定，但還沒有 ELF binary format
2000    iBCS 寫好，理論上能跑 Xenix binary，但 word-swap 沒處理
2001    iBCS 最後一個維護版本
2005    那台 Compaq ProLiant 出廠，跑 Linux + Informix
2010    Informix 被 IBM 完全收編，old SE engine 停止 maintenance
2026    我坐在新電腦前面，試圖讓 1989 年的 Informix binary 在 2026 年的 emulator 上跑起來

每一層之間都有 lossy translation。

ctek_menu 那個 binary 因為是 1999 年的 Slackware 環境下 compile 的，正好落在 Linux 2.2 的有效 emulation 範圍裡，所以能跑。

但 sperform / sqlexec / isql 那批 —— 是 1989 年 SCO Xenix 環境下 compile 的，落在 emulation 的 dead zone。

那 37 年是 archaeological gap，不是技術 gap。

沒有任何工程努力能補起來。除非有人重新拿 1989 年的 source code、在 2026 年的環境裡重 compile —— 但那 source code 早就不存在了。

七 · 磚塊還是磚塊，房子還是房子

5/30 那個禮拜五，下午 3 點左右。

我盯著 VirtualBox 視窗裡的 SIGSEGV 訊息，發呆了大概 5 分鐘。

腦袋裡轉的不是「失望」也不是「鬆一口氣」。是 ——

「有點不理解，但只能先這樣。再想想別的辦法。」

然後 ——

那句話從哪裡冒出來的我不知道。可能是看著 C-tek menu 那個藍底白字還能畫出來的記憶，可能是看著 372 MB tar 檔還在硬碟裡完整沒少一個 byte 的事實。可能是純粹的 ——

「磚塊還是磚塊，房子還是房子。」

什麼意思？

意思是 ——

SQL 資料還在。informix engine 不能跑，沒關係。menu 畫不出第二層，沒關係。我們已經可以讀資料、可以對齊紙本、可以畫報表了。

VM 復活這個 mission 不能完成 ——

但那不代表整個專案不能完成。

那一秒，AC 計畫的種子在腦袋裡萌芽：

A 桶 = CLI 報表        用 Python 直接接新 PG，把月底報表印出來
C 桶 = PWA forms      用瀏覽器當前端，繞過 sperform / C-tek menu 整套
VM 路線              降級成 backup option（如果哪天有人想看歷史考古）

那個下午 6 點，我打開新對話框，跟 Claude 說：

「VM 這條線就先暫停。我們之後回到 v7 主場繼續。」

24 小時之後，5/31 凌晨 9 點，AC 計畫的 M1 就上線了。

結語 · 保溫箱孵的不是 VM

如果問我「VM 重建這天算成功還是失敗」——

答案是 都不算。

它不是成功 —— 因為沒能讓 sperform / informix engine 復活。
它也不是失敗 —— 因為 ——

—— 都是這個專案有意義的 data point。

更重要的 ——

這個保溫箱讓我學會了 reframe 的時機。

我盯著 SIGSEGV 5 分鐘之後決定的「磚塊還是磚塊」，不是一個臨時的退場決定。

那是 AC 計畫整套的精神起點。

5/31 那一整天從 M1 到 M9 的瘋狂執行 —— 每個 milestone 都帶著「不要試圖讓過去原樣復活，把過去能用的部分接到現在就好」這個精神。

那顆 372 MB 的恐龍蛋還在硬碟裡。

它沒孵出來。

但 它的存在催生了 AC 計畫的速度。它告訴我 ——

「有些東西不能整顆搬，但能用磚塊一塊一塊搬。」

保溫箱沒有失敗。

它孵化的不是 VM，是 reframe 的能力。 ☕

— Amy + Claude(2026 春)