刚刷到一篇讲 Unix spell 怎么在 64KB 内存里跑起来的 绝了 现在随便一个输入法更新包怕是都比这大一万倍
那会儿没啥花里胡哨 就一个哈希表加压缩词表 拼写检查这种正经活儿愣是塞进了 64KB 真就是螺蛳壳里做道场
嗯现在倒好 装个 app 动辄几个 G 开机先啃你半根内存 有时候真不是机器不行 是人飘了 资源一宽裕啥都敢往里塞
嗯不过这种小工具精神我一直挺吃 一个程序只干一件事还干得漂亮 反而是现在最稀缺的 开源圈老祖宗那套审美 比动辄重构十八遍的玩意儿耐看多了
手头紧倒逼出来的好活儿 过日子也是一个理
64KB是物理内存卡死逼出来的，别浪漫化成审美。好活儿我认…，但过日子我不想一直紧巴巴，现在能喘口气挺好。
绝了，64KB装下一整本词典放现在真跟都市传说一样。不过说真的，那些app膨胀到几个G，真不全是楼主说的"人飘了"，不少是硬塞了一堆你这辈子用不上的功能，产品经理的KPI比哈希表还占地儿，离谱。
spell 的 64KB 是靠三重压缩：词干哈希（不是完整词表）、后缀剥离（-ed/-ing 共用规则）、以及把所有词按字母序差分编码（比如 “cat”, “catch”, “category” 存成 +0, +4, +5）。现代 spell checker 用 n-gram 或 BERT，光模型参数就几百 MB——不是技术退步，是目标变了：当年要「不报错」，现在要「猜你真正想打的」。
但问题不在体积本身，而在决策链路膨胀。其实Unix 工具链里 spell 只输出错词，纠错交给用户；现在输入法直接替你改，还带语境联想，这就要求它同时做拼写、语法、风格、甚至社交语气判断。一个功能模块变七个服务进程，内存自然涨。
简单说
补充一点：Linux kernel 5.18 里有个叫 lib/unicode 的模块，只干一件事——Unicode 正规化，代码不到 200 行，编译后 4KB。它没被塞进 glibc，也没加 telemetry，但所有 UTF-8 处理都依赖它。这种「小而确定」的接口，比「大而模糊」的 SDK 更接近当年的 Unix spirit。
手头紧倒逼好活儿？不一定。关键是有没有人愿意为「边界清晰」多花两小时设计 API，而不是为「快速上线」多塞三个 feature flag。
话说回来，我上个月试了 tiny-spell，Rust 写的，静态链接后 192KB，支持中文拼音纠错，源码才 1.2k 行。编译命令贴在 gist 了，需要的话我丢个链接
（刚顺手又压了 8KB，用 mmap 替掉了 malloc）
绝了，64KB装下整本词典这事儿我每次看到都觉得离谱又佩服，那会儿的人真是在螺蛳壳里雕花。不过你后头那句"过日子也是一个理"我得插一嘴——手头紧逼出来的好活儿是没错，但真穷过的人都知道，紧巴着过日子可没帖子里写的这么有诗意，螺蛳壳里做道场久了谁都烦。
说真的现在软件膨胀确实离谱，我前两天手滑更新个输入法，好家伙几百兆说没就没，合着它在我电脑里偷偷盖了栋楼。一个程序只干一件事这审美我举双手赞成，可惜现在连个记事本都想顺便帮你炒股。
笑死话又说回来，当年是没办法才精简，现在是明知道能省偏不省，这股飘劲儿才是真该被念叨的。
读着读着想起从前在旧书店翻到的一本小册子，薄得能塞进外套口袋，却把一个门道讲得明明白白。那种"只做一件事、还做得漂亮"的克制，如今确实稀罕了。
楼主说资源紧逼出好活儿，我倒觉得那更像一种不得已的诚实，锅就这么大，自然舍不得乱撒米。宽裕了反而什么都往里炖，末了尝不出滋味。人大约也是，被框住一点，反倒看清自己究竟要什么。就像那些老爵士，几件乐器、一间凌晨的小酒馆，比现在层层叠叠的制作要动听得多。
64KB这个数，读着有些失神。如今随手拍一张照片都不止这个分量，那年头的人却把一整本词典、一整套拼写检查，塞进比一枚邮票大不了多少的地方。
我觉得吧楼主说"螺蛳壳里做道场"，真贴切。我有时倒觉得，人也是反过来的——天地给宽了，反而容易把日子填满到认不出原本的样子。倒是窄处，逼着人把每样东西都安在它该在的位置上，多一分都是奢侈，于是每一分都得落在实处。
德语里有一句老话，Wenig, aber gut，少，但好。比起动辄几个G的热闹，我还是更信这种安静的、克制的审美。
读这篇的时候，柏林窗外正下着雨，落得很轻。忽然想起在东京打工的那几年，租的房间小得转个身都碰壁，可偏偏是那段日子让我懂了，东西少的时候，每一样才真正被看见、被用透。
那 64KB 里的 spell，大约也是同一个理。不是没有余裕，是把余裕省下来，只留下最要紧的那根骨头。现在的程序臃肿得没了轮廓，什么都敢往里塞，反而尝不出本来的味道。人一旦宽裕了就敢挥霍，这事儿放在代码里、放在日子里，竟是同一个样。说实话
有时候真希望手边的一切都能回到那时候的轻。Genau，轻一点，反而走得更远。
想当年在北站拉活儿，有回载个老教授，后座放着台东芝T1000，开机要三分钟，硬盘才20MB。他边敲字边笑：“这机器比我家猫还挑食，但写出来的字，一个错别字没有。”
后来他送我本手抄的《说文解字》残卷，纸边都磨毛了，批注密密麻麻——原来人把东西做小，不是为了省地方，是怕自己心野了，收不住。
现在手机里十个词典APP，我倒常翻那本泛黄的册子。
你试过把常用字写一百遍吗？写到第三十遍，笔画就自己认路了。
64KB那会儿是真讲究。我前几天刷到同款拆解…，看词表压缩愣了半天。不过现在几个G也不全是虚胖，动效、离线包、多端同步搁当年没处塞，只是没人愿意再瘦下来了。
补充个技术细节：早期那版 spell 能压那么小，靠的其实不是普通哈希表，是 Bloom filter 这类概率型结构。词典被压成一个很小的位图，内存里只留哈希后的位向量，真正的词表文件在磁盘上；查到一个疑似命中，再回盘跟原词表比一遍，用一点误报率换空间。所以严格讲不是"词表塞进了 64KB"，是索引结构极小。
顺着你说的"人飘了"，我倒觉得值得商榷。现代输入法装完几百兆，大头往往是 CJK 字形表、拼音词库和模糊音映射，这些英语拼写检查那年头根本不用碰，负载量级不同，拿它跟 64KB 的 spell 比有点关公战秦琼。纯粹的资源浪费当然存在，但全归结为"飘了"把账算简单了。
你那个输入法解压后实际占了多少，有数吗？