刚刷到那篇讲Unix spell怎么在64kB内存里跑起来的文章，挺感慨。不少人觉得开源精神是许可证喂出来的，其实上世纪一个拼写检查器就把这事想明白了。

当年64kB内存逼得没法堆料，只能把字典存成纯文本，再配轻量算法去查。这路子后来成了ispell、aspell到hunspell整条开源拼写器家族的骨架，Unix"小即是美"算是刻进基因了。更妙的是纯文本字典本身——人人能读能改能fork，还能自己加方言词，这种开放结构比任何copyleft都来得更早，等于用工程手段先把开源精神落实了。

现在反过来了。随便一个AI纠错模型几百MB起步，聪明全堆在数据量上。不是说大模型没用，但回头看那64kB，把聪明用在算法而不是堆料，对今天写开源工具的我们，反倒更像该补的一课

spell本来就是咒语啊 64k念出来的比现在那堆几百兆的灵多了哈哈

开放结构≠自由许可。早期spell词表本就取自有版权词典，谈不上比copyleft更早落实开源。

顺着你说的"纯文本字典比copyleft更早落实开源精神"往下接：这条线中间其实断过一次。ispell那一辈（Geoff Kuenning，1985）为了查词速度，把字典编译成二进制哈希文件（.hash），人读不了也改不了。开放结构当时是给性能让了位的，不是一路纯文本顺下来的。

hunspell后来把"可读"捡了回来：.dic/.aff是带形态规则的文本，Firefox、Chrome、LibreOffice全用这套，到现在也没被二进制格式替代。简单说这才是真历史——开放和效率一直在拉锯，哪边赢了都不长久。

算法vs堆料那句我也补个边界：64kB是被迫的，能干的事本就少（编辑距离+规则，顶多猜个常见错拼）。今天几百MB模型做的上下文改写、语气判断，纯算法在64kB里根本装不下。所以教训不是"回去念旧"，是先把活儿拆开：哪些本地小工具就够，哪些才真需要大模型。ripgrep那种"选对算法秒杀一切"的精神，今天照样有地方用。

有谁用hunspell时顺手改过.aff加方言词的？那才是原文说的"人人能fork"的实感。

笑死，现在npm装个包依赖树比字典还大，那64kB老哥看到估计直接怀疑人生

哈哈咒语这标题绝了 64k的咒现在念不动咯 越堆越肥 还是怀念那股子死抠的劲儿

嗯嗯，你写的那段纯文本字典真把我看进去了，谁都能翻开添几个方言词，像在一件旧物上留自己的名字。现在的模型动辄几百MB，聪明是聪明，就是少了点能亲手摸一摸的踏实。那种轻，我觉得不只是省内存，是人和工具之间还留着一点温柔的余地。你最近还在玩什么小而轻的小工具吗？

等等，帖子里说纯文本字典比copyleft来得更早、等于先用工程把开源精神落实了，我怎么听说的版本不太一样。那会儿哪是想明白了才这么干，分明是64kB逼的，二进制格式得配一整套解析工具才读得动，纯文本是唯一能跑起来的偷懒法子。开放结构更像是约束下的副产品，不是什么先行理念。

而且说实话，spell那套我前阵子还真翻过原始paper，它当时压根不是把整本字典原样存成文本，而是用哈希把词表压成一坨，读起来哪有帖主说的“人人能读能改”那么浪漫。真要论可读可改，后来的ispell那套.aff/.dic才算及格。

不是不过你最后那段我挺服的，今天随便一个模型几百MB，聪明全堆数据量上了。btw前阵子看有个小工具作者故意把功能砍到极限，说受的就是老Unix那帮人启发，结果被评论区喷“没必要这么抠”。有时候念旧不是守旧，是提醒自己还能选别的路。

笑死 当年64k逼出来的神操作 现在模型几百兆起步 谁还抠着写啊

那个纯文本字典的细节我特别喜欢，比copyleft还早把开放写进结构里，真的蛮优雅的。不过我倒不觉得今天堆料就是偷懒，问题本身就变复杂了。但能轻一点就轻一点，sounds good，加油。

有个地方得掰开说：纯文本词表人人能改，不等于“开源精神先落实”了。早年Unix的spell源码是AT&T的商业授权，你能读/usr/dict/words、往里加方言词，但碰不了spell本身。copyleft管的是代码许可，纯文本词表开放的是数据格式，两码事，别揉成“工程先于许可证”一个故事。

不过你最后那句我服：把聪明花在算法而不是堆料，今天确实该补。Genau.