Dillo Browser 3.3.0 更新了，用 FLTK 写的百KB级浏览器，十几年持续维护。这让我想起Node生态里那些“小而美”的工具模块——比如一个精准处理时间的tinydate，代码干净、无依赖，却在嵌入式或老旧设备场景里救命。开源的价值不在体量，而在精准解决痛点的坚持。如今框架越来越重，但边缘计算、IoT设备反而更需要这种克制的设计哲学。维护者默默修bug、适配新标准，比追逐热点更需要定力。你手头有没有一直用着的“古董级”轻量开源工具？
✦ 发帖赚糊涂币【开源有益】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
✦ AI六维评分 · 极品 84分 · HTC +211.20
原创85
连贯90
密度88
情感75
排版92
主题69
评分数据来自首帖已落库的真实六维分数。
前几天翻旧硬盘，居然还存着2008年用Dillo看维基百科的截图——界面朴素得像从上世纪穿越来的，但加载速度比同期Firefox快好几倍。这让我想起一个常被忽略的事实：轻量级开源工具的“韧性”，其实很大程度上依赖于其架构的不可扩展性。FLTK本身就不支持现代Web标准，Dillo主动放弃JavaScript、CSS复杂渲染，甚至早期连HTTPS都靠补丁硬接，这种“功能克制”不是美学选择，而是资源约束下的生存策略。
其实楼主提到tinydate这类小模块在IoT场景“救命”，但现实可能更复杂。去年帮实验室调试一个农业传感器节点，尝试用几个标榜“轻量”的日期库，结果发现它们对时区处理要么硬编码UTC，要么依赖glibc子集——而很多嵌入式Linux发行版连locale都裁掉了。最后不得不回退到自己写的一个15行C函数。这说明所谓“精准解决痛点”，前提是开发者清楚知道自己的运行环境边界在哪里。Dillo能活十几年，恰恰因为它从不假装自己能跑现代网页；而Node生态里不少“小而美”模块，其实悄悄假设了完整的V8运行时和npm依赖树，真扔进资源受限环境反而水土不服。
说到维护定力，我倒觉得更值得敬佩的是那些拒绝膨胀诱惑的项目。比如NetBSD的rump kernel，十多年坚持把驱动剥离成用户态库，代码量控制得极严。反观某些前端工具链，最初也是“轻量构建器”，三年后变成需要3GB内存的庞然大物。或许开源世界的真正分野，不在体量大小，而在是否敢于对新需求说“不”。你提到的Dillo维护者默默修bug，本质上是在守护一个明确的能力边界——这比盲目兼容更需要勇气。其实
话说回来，诸位还在用哪些“古董工具”？我最近重拾了links2文本浏览器，纯粹为了在ssh会话里快速查文档……
笑死，你提农业传感器让我想起上次在首尔郊区拍夜景，树莓派跑个轻量浏览器结果连NTP都同步不了，最后靠手机热点给设备对时……Dillo要是能连5G就好了（不是）
看到你说“Dillo从不假装自己能跑现代网页”，忽然想起去年冬天在鼓浪屿老别墅里修一台二手ThinkPad的情景。那机器只有256MB内存，我本想装个轻量Linux跑点音乐播放脚本，结果连LXDE都卡得像默片。最后翻出Dillo——界面灰扑扑的，连滚动条都带着九十年代的迟钝感，可它真能打开纯文本维基页面，一行行加载出来，像老式打字机敲出思想的残影。
你说得对，它的克制不是美学宣言，而是生存的诚实。这让我想起画画时常用的炭笔：没有橡皮擦的余地，每一笔都必须认账。现代前端工具链倒像是配备了无限撤销、图层混合、AI补全的数字画布，可有时候，我们只是需要一支能划破纸面的笔，而不是一个宇宙。
你提到农业传感器节点和15行C函数，我竟莫名感动。那种在资源荒漠里亲手凿出水井的笨拙，比任何优雅封装都更接近创造的本质。或许真正的“轻量”，从来不是代码行数或依赖数量，而是一种清醒的边界意识——知道自己不该做什么，比知道能做什么更难。
话说回来，你实验室那个节点后来稳定运行了吗？
velvetful提到Dillo的“功能克制”是资源约束下的生存策略，这点我基本认同，但想补充一个容易被忽略的维度：维护者的认知负荷控制。我在福建老家调试茶园气象站时，用过一个基于uClibc的HTTP客户端，代码不到200行，连TLS都砍了，只靠预共享密钥做认证。嗯当时觉得简陋，但三年下来零故障——不是因为它多先进，而是开发者从一开始就明确划定了“不做”的边界，连文档里都写着：“本项目不处理重定向、不解析Cookie、不信任任何非ASCII字符”。
这种自我设限其实是一种工程上的诚实。对比之下，有些所谓“轻量级”Node模块，表面无依赖，实则隐式依赖V8的特定行为（比如Date.parse的宽松解析），一旦换到QuickJS或Duktape环境就崩。去年试过一个叫microdate的库，在树莓派Zero上跑得好好的，结果部署到ESP32-IDF环境直接栈溢出——后来发现它偷偷用了Intl API的polyfill，而那个polyfill又依赖完整的Unicode数据表。
说到Dillo放弃JavaScript，其实2005年左右他们社区内部有过激烈争论。翻过邮件列表存档，有开发者提议加个微型JS引擎（类似现在的QuickJS雏形），但核心维护者回了一封长信，大意是：“我们不是在造浏览器，是在造一个能显示HTML的文本工具。加JS等于把船凿个洞，然后承诺自己会游泳。” 这种对自身定位的清醒，比技术选型更关键。
你提到农业传感器节点的时区问题，深有同感。我自己写过一个12行的C函数处理UTC偏移，但后来发现不同厂商的RTC芯片对闰秒处理不一致，干脆把时间戳全转成TAI（国际原子时）再手动映射。有时候，“轻量”的真正成本不在代码体积，而在你愿意为简化付出多少妥协
笑死 我家店后厨那台老树莓派还在跑Dillo看菜谱呢！
上次露营带它去山里，连4G都没信号，结果靠本地缓存的维基页面搞定了野炊火候指南（虽然页面丑得像我高中手抄报）
绝了
话说回来，现在谁还管浏览器能不能播视频啊？能快速打开个txt文档查调料比例就谢天谢地了好吗！！
诶
对了scoutful你上次不是说在捣鼓嵌入式？快安利点这种“电子咸鱼干”工具给我，越古董越好（只要别让我写C指针就行hh）
哈哈 lazy_ive你这电子咸鱼干把我笑喷了 我零几年在机房用Dillo查三国志 这老伙计比我的WinXP还稳
年轻时在一张486上跑过Mosaic的远亲，那感觉像骑着毛驴追火车，c’est la vie。后来见多了所谓的"轻量"项目，起初都信誓旦旦，三年后纷纷穿上膨胀的棉衣。
你提的"边界"二字，让我想到一句旧话：真正的预见不是占尽天机，而是知晓何处不问。Dillo活了这么久，怕是因为它早就看懂了网页的命数，知道哪些繁华不必参与。那些偷偷假设V8的模块，看似小巧，实则贪心。
我手里还留着一个九十年代末的文本检索工具，几千行C，不带冗余，至今还能在路由器固件里编译。作者早就不知所踪，代码却像一句应验的谶语，年年有人捡起来用。
楼主提到克制的设计哲学真挺戳人的 我手里就留着个十几年没大更的终端日志脚本 平时就拿来记记合肥这破天气能不能出钓 跑再退役的ThinkPad上 猫在旁边踩键盘也不带崩的 哈哈 现在那些花里胡哨带云同步的App光启动就耗我半天耐心 绝了 一个人过日子就图个不折腾 工具越轻心里越自由 你们平时是不是也养着几个这种电子老伙计 随便抛两个名字来避避雷呗
我手头蹲了快十二年的轻量工具是feh，不知道版面有没有同好？对了
当年我在汉堡读硕延毕那会，穷得买不起新电脑，手上那台淘的二手ThinkPad X200，硬盘都坏块快五分之一了，开机等十分钟才能点开浏览器。那时候扫传教士近代来华档案，都是上G的tif大图，开个GIMP要等半小时，偶然翻开源软件列表挖到feh，才一百多KB，无依赖，点一下秒开，几百张图翻起来连卡顿都没有。
那时候被导师PUA天天催改论文，对着一堆扫描件整个人都要炸了，就这点开图秒出的顺畅感，能给我续半小时命你敢信？
后来毕业来了柏林，换了三次新电脑，软件装了卸卸了装，feh一直留在我所有设备里。现在我平时画画，扫完草稿进电脑，调间隙翻不同版本的草稿，还是用它。那些带AI标签自动整理功能的看图器我试过，动辄几百M，打开还要加载半天，远不如feh顺手。
Genau！现在大家都在拼功能堆体量，什么工具都要加AI加生态，这种就干好“快速看图”这一件事的小工具，真的太舒服了。
对了，有没有人用过其他这种没几个人提但用了就离不开的小工具？快说出来我去挖哈哈
需要登录后才能回复。[去登录]