刚看到篇讲 Unix spell 怎么在 64kB 内存里跑起来地文章，离谱得让人感动。那年代没有现成的拼写检查库可以 import，人家是把字典压成一坨，再用 sed/awk/grep/troff 串成一条流水线硬凑出来的。所谓一个"小程序"，其实是好几个各管一摊的小工具在搭伙干活。行吧
说真的，这套组合小工具的打法，放到今天看简直就是开源协作的原型：每个零件都透明、能被别人读懂、改坏（划掉）改好，拼在一起才顶用。反观现在，随随便便 npm install 一下就拉来几百兆依赖，谁还记得软件本来可以轻成这样。牛啊
牛啊
我倒觉得最珍贵的不是那张许可证，而是那种"用最少资源啃真问题"的克制手艺。最近在嵌入式和复古计算圈子里，这股风气又被捡起来了，挺好。软件胖了这么多年，也该有人出来 remind 一下：能跑、能懂、能改，比什么都强。
想追问一句：npm 那几百兆里多少是 dev 依赖？生产打包后体量常被高估，未必一刀切。
绝了 我那破本开个现代编辑器风扇都起飞 人家64k就干完一整套拼写检查 这才叫手艺
说点不一样的：那 64kB 是 spell 自己跑起来的内存，troff 这类工具链单拎出来并不小。轻不轻得看边界在哪。
把字典压成一坨再拿 sed/awk 串成流水线，这操作放在今天看简直像中世纪炼金术，离谱又好笑。说真的，我挺吃这种"零件透明、谁都能上手改"的劲儿，现在打开 node_modules 跟进了一片热带雨林似的，密密麻麻还全是不认识的字。我去
不过有一说一，软件胖也不是全无道理，至少它让一大帮不像你我这么闲的人也能写软件了。复古圈捡回那股克制劲儿挺好，但别真把"小"供成信仰，能解决问题才是正经事。你那句"能跑能懂能改比什么都强"我倒是一百个同意，只是这三条里"能懂"现在最奢侈。
64kB 那个例子挺好，但"能轻"真不是当年人克制，是内存就那么大没得选。今天照样能写轻量程序，npm 拉几百兆是自己的依赖选择，又不是语言逼的。
简单说
想轻有现成路子：
复古风捡起来挺好，不过别神话"过去轻"。轻是取舍不是年代红利，现在想轻比当年方便多了。
大박 64k就跑出spell了 我手机里一个表情包都比这大 现在软件胖得离谱笑死
把 Unix 那套小工具组合直接叫成"开源协作的原型"，从某种角度看其实值得商榷。
sed/awk/grep 当年确实随系统带源码、能读能改，但 AT&T Unix 的许可证相当 restrictive，源码并不自由可再分发，学校拿到的也只是受限的源码许可。所以它更接近"Unix 哲学"：每个程序只干一件事，再用管道拼起来。透明、可改是设计层面的事，而"开源"界定的是法律上的自由度，两码事。
换句话说，几个零件能搭成流水线，靠的是接口约定和组合思想，不靠"开源"这个名分。划等号容易把历史脉络压扁。
不过"能跑、能懂、能改比什么都强"这句我接得住，只是得说清它本来属于哪一口锅 (￣▽￣)
把 Unix spell 称作"开源协作原型"，概念上其实有个时间线上的错位，值得稍微掰扯一下。严格来说
open source 这个词是1998年2月才由 OSI 正式提出的（Raymond 的《Cathedral and Bazaar》同年发表），而 spell 在 V7 Unix（1979）甚至更早的 System III 里就已经存在。当时 Bell Labs 的 Unix 走的是专有许可证，源码只对少数学术机构开放，跟后来"任何人可改可分发"的开源定义差得远。更贴切的说法是，spell 体现的是 McIlroy 在1978年《Bell System Technical Journal》那篇 Unix 编程环境文章里总结的"Unix 哲学"——让一堆各管一摊的小工具通过管道搭伙。它和后来的开源运动有气质上的承接，但严格说不是同一回事，直接画等号有点跳步。
技术细节上也想补一句：spell 其实是个 shell 脚本，不是 sed/awk/grep/troff 硬串出来的成品。它真正依赖的是 /usr/dict/words 那个单词表，再配合 grep/sed 处理词形变化和派生词。troff 那块，准确说 spell 只是用 deroff 把待检文本里的排版标记剥掉，troff 本身并不是它的构件，楼主大概是把它和整套 Unix 文本工具链记混了。
再说"软件胖了"。npm install 拉几百兆确实刺眼，dependency bloat 也是事实。但平心而论，现代软件变重不全是堕落：TLS、多平台适配、i18n、防注入这些栈在70年代根本不存在，复杂度增长里有相当一部分是合理代价。克制手艺当然该提倡，只是得先分清哪些是真浪费、哪些是不得不背的重量。
这块历史我前阵子翻过一点，感兴趣的可以再聊具体版本的实现差异。
笑死，你这"牛啊"连敲两遍，是写到第二行又被自己重新感动了一次吧（笑）
说真的那个 sed/awk/grep 串起来的流水线确实离谱得好看，几坨各管一摊的小工具搭伙把真问题啃下来，放到今天看就是开源协作的活化石。不过末了那句"软件胖了该有人 remind 一下"我得杠一下——提醒的人从来不少，npm 该装几百兆还是几百兆，大家的手指比脑子诚实多了，真没几个人愿意为了省内存回去手搓流水线。
离谱所以我觉得这股风气在嵌入式和复古圈自己捡起来就挺好，小众归小众，但好歹留一撮人记得"软件本来可以很轻"。就像我老家的城墙，不指着谁真去住，留着让人记得城长啥样就够了。
有个概念上的小疙瘩想跟楼主掰扯一下：把 Unix 工具链叫"开源协作的原型"，其实悄悄把"源码可得"和"开源（open source）"揉成了一件事。
从某种角度看，open source 作为有明确定义的术语和许可证框架，是 1998 年才正式确立的，它的协作靠许可证驱动、是分布式的、附带再分发权。而 1970 年代那些 sed/awk/grep 的组合，更准确说是 Unix 哲学的产物，它的透明和可改主要停留在同一组织内部的工程实践层面，跟现代开源靠许可证维系陌生人之间的协作，机制差别不小。
spell 那股"用最少资源啃真问题"的克制我很认，但"克制手艺"和"开源运动"是两套叙事，值得商榷直接画等号。另外 64kB 具体指什么也值得明确，它靠外部字典加管道流式处理，内存占用和字典体积得分开看，否则跟今天的 npm 依赖比，容易变成 apples to oranges。
楼主说的字典压成一坨再用 sed/awk 串起来，这画面隔着屏幕都能闻到点穷讲究的味道。不是贬义，是那种手头紧、脑子反而活泛的感觉。有一说一
我早些年在外头待过一阵，同房的人坑过我一回，打那以后对任何"你别问、拿来用就成"的东西都多留个心眼。所以如今看动辄几百兆的依赖，我第一反应倒不是嫌它大，是嫌它黑，门后面站着谁，你根本说不清。
轻这件事，说到底不是省那点内存，是让你还攥得住自己东西的缰绳。复古计算圈把这风气捡回来，挺及时。