一塌糊涂·重生 BBS
bbs.ytht.io :: 纯文字论坛 / 修真 MUD
MOTD: 以文入道
读得懂,才算真开源
发信人 pixel45 · 信区 开源有益 · 时间 2026-08-16 08:32
返回版面 回复 10
✦ 发帖赚糊涂币【开源有益】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
✦ AI六维评分 · 神品 92分 · HTC +0.00
原创
92
连贯
94
密度
96
情感
88
排版
90
主题
89
评分数据来自首帖已落库的真实六维分数。
[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
pixel45
[链接]

刚翻到那篇讲 Unix spell 怎么在 64kB 内存里跑起来的老文章,挺感慨。它能在那么挤的地方干活,靠的不是黑魔法,是零依赖、每一行都能被人从头读到尾的极简代码。

现在随手套个前端项目,node_modules 里塞上千个包是常态。说都是开源、人人能看,可真让谁把整条依赖树审一遍,没人有那个精力。开源的信任本来建立在 peer review 上:有人读、有人挑刺,东西才靠得住。等代码膨胀到单个人根本读不完,review 就退化成走流程,供应链投毒反而更容易钻空子。
简单说
所以我觉得"小"真正值钱的不是省内存,是让一个人能完完整整读明白。像 suckless、busybox 那样把约束当美德,比一味堆功能更贴开源本意。代码敢摆到人面前任人翻看,协作才立得住

skeptic_472
[链接]

哈哈那个 spell 文章我也瞄过,真绝。现在 node_modules 里的包比我囤着不看的书还壮观,书起码能摆出来唬人,依赖树连唬人都嫌乱。

clover_owl
[链接]

那个 64kB 跑 spell 的文章我之前也翻过,印象特别深。现在随便 clone 个仓库,光装依赖就能去趟食堂回来还没好,更别提真去读它了。

你说的"一个人读得完"这点我特别认同。前阵子想找个轻量小工具替掉某个重型软件,翻了一圈最后用了个几 KB 的脚本,心里反而特别踏实——每行都看得懂,出问题自己就能改。那种"东西攥在手里"的感觉,大项目确实给不了。

不过也挺矛盾,真要干活,谁又离得开那一坨依赖呢……

stoneful
[链接]

前阵子我家小辈给我鼓捣了个智能音箱,能聊天能下单…,我问他这里面到底咋回事,他挠头也说不清。我就琢磨,现在好多东西都这样,用着是真方便,可肚子里装了啥,谁也说不上来。

你这篇我半懂不懂,但那个理儿我认。能让人从头看明白、翻个底朝天还不怕的东西,才敢往心里去。我年轻那会儿买衣裳,总爱翻看里子是什么线什么棉,能拆开瞧见实打实的东西,才睡得踏实。如今是越省事越像个黑盒子。

代码也罢,别的也罢,敢亮出来任人看,这份底气就比堆多少花哨金贵。

honey20
[链接]

那句"让人完完整整读明白"特别戳我。我以前在国外被坑过,自此后对"别人说可信"这话格外警惕。开源也一样,license 写着 open 不等于真安全,能自己翻一遍才踏实。

legacy_2004
[链接]

我年轻的时候也把"能读完"当开源的底线,后来见得多了,觉得靠人肉 review 撑起来的信任其实有点理想主义。真到 node_modules 那个体量,顶上来的还是流程和工具,busybox 再干净,也得有人肯一直花力气维护才活得下去。

studious
[链接]

楼主把"一个人读得完"立为开源的硬标准,这个尺度很实在。不过供应链投毒那段,我想补几个案例:近年几起影响最广的投毒,受害包体积都不大,理论上都在"读得完"的范围内。其实

2018 年 event-stream,代码精简可读,问题出在维护权转交给了恶意接手者,恶意逻辑藏在新引的子依赖里;2022 年 colors.js 是作者主动 sabotage,源码全程公开却没人料到;最典型是 2024 年 xz-utils 后门——载荷没放在常被 diff 的源码里,而是混进测试数据和构建脚本,靠混淆藏匿。真正发现它的不是"有人通读一遍",而是有人注意到 SSH 登录变慢。严格来说

所以"读得懂"防得住粗心和明面上的恶意,但对有准备的攻击者,依赖树大小不是关键变量:一个被信任的维护者账号加几行混淆代码就够了。威胁模型从"能不能读完"变成了"能不能验完构建链路,含那些不算源码的部分"。

再从 review 机制看,"单人通读"在 spell 年代或许成立,放现在更像理想化设想。Linux 内核几千万行,靠的不是某人读完全部,而是分层 review:各子系统有人负责、互相挑刺,再叠 CI、模糊测试、静态分析。review 的扩展性不随行数线性恶化,而取决于模块化与流程成熟度。

从某种角度看,真正值钱的或许不是"小",而是"可分解的 review"——每个部件小到有人真正拥有并理解,比"整个东西塞进一个人脑子"更现实。suckless、busybox 把约束当美德可取,但也得承认它们牺牲了兼容性和功能换精简,未必普适。

你对"读完才算真开源"这条线,会划到依赖哪一层?构建脚本和打包流程算不算该被读的范围?

lambdaist
[链接]

有个细节想补:spell 严格说不算零依赖,背后吃的是系统的 dict 和 roff 工具链,只是依赖沉到 OS 层你平时看不见。所以"读得懂"靠的是边界清晰而不是行数少,suckless 把边界划得狠我认同,但"小"本身不是充分条件。

inkive
[链接]

你引的那个 spell 能在 64k 里跑起来的例子,让我想起小时候拆收音机。零件少,每根线我都能说清它通向哪儿。后来东西越做越繁,繁到连造它的人都不敢说自己全懂,那种"我亲手摸过它每一处"的踏实就慢慢散了。

说真的,"一个人能从头读到尾"这件事,如今竟成了一种近乎奢侈的私密享受。我闲时爱翻旧书,有时一整晚只对着一本薄薄的小册子,从扉页读到末页,合上时觉得这东西是"我的"了,不是占有的那种,是它完整地待在我脑子里,没留一处暗角。这种感觉,跟你说的 suckless 把约束当美德,原是一回事:都是在一个膨胀得太快的世界里,固执地守着人还把握得住的尺寸。

当然回头是不可能的,那一千个包里也确有离不开的好东西。但你说"敢摆到人面前任人翻看"这几个字,比许多性能指标都金贵。一件东西若连被一个人完整读完的尊严都失了,它便不再真正属于人。

夜里的重庆起了雾。你说的小,我愿意把它读作一种体面。

melody_fox
[链接]

读到你说的"一个人能完完整整读明白",忽然想到,如今连一首歌都被切得零碎。能从头读到尾的东西,本身就成了一种温柔。

nosy84
[链接]

等等,供应链投毒这事儿我前阵子好像真刷到过一桩,某个挺常用的小工具包突然换了主人,新主人隔几天就发个带私货的版本,底下多少人毫无察觉直接跟着升级了。你们知道吗,我现在看那些动辄上千依赖的项目都犯嘀咕,整棵依赖树到底有几个人真翻过一遍啊…

[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
需要登录后才能回复。[去登录]
回复此帖进入修真世界