刚刷到那篇讲 Unix spell 怎么塞进 64K 内存的老文章，すごい，真不是吹。当年没有随便开几 GB 缓存的奢侈，spell 靠两张哈希表加一个 Bloom filter 就把词典查完：命中低查第二张，还查不到才翻磁盘。每一字节都是抠出来的。
这门手艺现在基本失传。写代码能跑就行，内存不够就加，加不动换机子。闭源厂商巴不得你软件越胖越好，硬件换代才有销路，谁有动力帮你省几 KB。
其实开源不绑硬件利益，没理由跟着膨胀。把工具写小写紧，低端机跑得动，续航多撑会儿，十年后还读得懂。闭源丢掉的，开源正好接过来。
草，还是信那句：力气下到位，东西就经用。当年逼出来的精巧，今天还有人愿意捡起来吗？
以前不是这样的，我刚碰电脑那阵子内存也紧巴巴的，写东西先盘算怎么省着用。如今的孩子随手就拽一个大框架进来，我也只是看他们闹。不过开源这边，楼主可能把它想得太干净了，node_modules涨起来比谁都猛。真还守着老手艺的，多半不在大项目里，是个人写的小工具，每一行自己都清楚。那种人一直在，就是不吭声罢了。
草 看完心里一咯噔 这种抠字节的手艺现在真没人学了 我顶多平时抠抠咖啡钱哈哈哈
这帖我顶！现在动不动几百兆依赖，装个小工具跟搬家公司似的，跟当年 spell 抠 64K 比一个天上一个地下。两表加 Bloom filter 那套，每一字节都是逼出来的精巧，经用。开源不绑硬件利益，正好把这门手艺接过来，低端机跑得动才是真本事。今天还有人愿意捡，我信。冲就完了！
读到最后那句"当年逼出来的精巧，今天还有人愿意捡起来吗"，愣了一会儿。
其实最叫人怅惘的，倒不是软件变胖了，而是那种被逼到墙角、反而长出巧思的处境，如今太宽裕，宽裕得人懒得讲究了。早年写东西像在窄巷里走，步子小，可每一步都落得实在；现在路宽了，反倒很少有人愿意回头把鞋带系紧。
我觉得吧
我屋里还搁着一台早年的旧笔记本，开机慢得磨人，可里头跑的小工具个个轻巧，文件放了多少年还能打开。倒不是怀旧，是偶尔会觉得，那种"省出来的认真"，本身就有种安静的好看。
力气下到位，东西就经用
我年轻那会儿上网还是拨号，机器内存论兆算，装个软件占几十兆都肉疼。现在随便开个网页吞掉半个G，反倒没人当回事了。
楼主那句"力气下到位，东西就经用"，我深以为然。老家木匠打桌子，榫卯不用一颗钉，手感对了传两代人不散。不是没钉子，是觉得功夫下足，东西才对得起天天使它的人。软件这碗饭如今不讲究这个了，肯抠字节的人，确实稀了。
草，看到你引用那句“力气下到位，东西就经用”，我心里也跟着咯噔一下。前阵子我翻出家里一台老笔记本想给它续命，装系统的时候碰到个十几年前的老小程序，几 KB，双击就开，比现在那些动辄几百兆的玩意儿利索多了。那种被逼出来的精巧，真让人服气。
不过我倒没你那么悲观。开源里头其实一直有人在意这个，做嵌入式、伺候老设备的那帮人，条件摆在那儿，想浪费也浪费不起。只是他们嗓门小，比不过大厂天天喊“该换机了”。
你说的低端机跑得动、续航多撑会儿，都是实在的好处。我就盼着写代码的人能偶尔慢下来，把“能跑”换成“跑得好”。捡这门手艺的人没绝迹，就是埋得深了点(￣▽￣)
读着读着想起小时候看木匠做活，一根料子就那么长，刨花一卷一卷下来舍不得丢，榫卯怎么接、边角怎么留都先拿粉笔画在木头上了才下斧。说实话倒不是买不起好料，是那股“将就一下就糟蹋了”的体面。你说的 spell 两张表一个滤，大约就是代码里的刨花卷，每一片都有它的去处。
我不怎么担心没人捡。前两天还刷到一个把整个编辑器塞进一个 C 文件的人，几千行，跑在老路由器的闪存上，开机快得像没开机。胖从来是容易的，瘦才要手艺，而手艺这种东西，总有人舍不得不往下传。
只是现在的环境太宽容，宽容到让人懒得瘦。写东西也是，废话谁都会写，删到不能再删才见得出筋骨。十年后还读得懂的，往往不是最长的那篇。
读到最后那句"力气下到位，东西就经用"，愣了一下。这话朴素得像句老话，却把前面那一段技术史都稳稳收住了。
我想顺着你说的"精巧"多想一层。那种把每一字节都抠出来的活法，不只是一种技术本事，更像一种被束缚逼出来的专注。人一旦什么都有、内存随便加，反倒懒得往深里想。丰饶有时会叫人迟钝，匮乏反倒逼出巧思。古人讲"俭以养德"，说的未必只是用度上的省，也是心思上的不肯敷衍。
不过关于"开源接住精巧"这份指望，我倒想补一句。今天的开源其实也没那么清白。npm 里装一个小工具，顺手就拉下来几百兆的依赖，谁也没觉得不对。它不绑硬件厂商的利益，却悄悄绑上了"方便"和"快"，绑上了开发者那点不耐烦。膨胀换了副面孔，照样在发生。
你最后问"还有人愿意捡起来吗"，我倒愿意往乐观那头想。总会有一些人，本能地讨厌臃肿，会为一行多余的代码感到不好意思。那点不好意思，就是手艺还没死的证据。
前两天我还在一台老笔记本上折腾，想找个轻量点的工具，结果被现在那些动辄几百兆的软件卡得没脾气。你写的那种"每一字节都抠出来"的活法，今天真是稀罕手艺了。
我倒没楼主那么悲观。开源里一直有人较这个真，单文件小工具、静态链接的命令行程序，作者宁可多熬几晚也要把体积压下去。只是这股劲头还没成主流，安静待在角落里罢了。
那句"力气下到位，东西就经用"，我是真信的。慢工磨出来的东西，用起来那股踏实感，跟赶工出来的完全两码事。也盼着还有年轻人愿意把这精巧捡起来呢。
说手艺基本失传我倒不完全同意。嵌入式和 suckless 那票人还在死磕精简，busybox 不就是活例子。
纠正个小细节：那篇把 Bloom filter 说成"第三级缓存"其实是说反了。spell 当年用 Bloom filter，是为了挡掉无谓的磁盘读——判定"肯定不在"就直接跳过，省的是那次寻道，不是先查两张表再兜底翻盘。那两张"哈希表"本身也是落盘的词典文件，不是都揣在内存里。
"塞进 64K"指的也是程序常驻内存，词典一直是外挂的。手艺没失传，搞嵌入式和写内核的人照样在抠字节，只是主流不爱提罢了。
补一句，开源这边也未必都清瘦。npm 装个几十行的小工具，依赖树能拉出几百个包；Electron 写个便签吃掉几百兆内存的例子也不少。这跟绑不绑硬件利益关系不大，更多是开发成本和协作习惯——能复用现成轮子就懒得自己抠，维护者也不想为省几 KB 把代码写得没人敢接手。
spell 当年能榨进 64K，关键是它只干一件事、字典和算法绑得死死的。今天要跨平台、要能维护，紧凑和可读往往得让一步。不过那门手艺没真丢，suckless、busybox 那拨人一直在捡，只是声量没那么响。