No.01
Regressive JPEGs
在单张JPEG里塞视频:渐进式扫描的邪道用法
180 分
8 条评论
作者: vitaut
本文介绍了一种利用JPEG渐进式渲染特性在单张图片中嵌入多帧画面的技术。JPEG支持按频率分批次传输数据(称为「扫描/Scan」),先传低频再传高频,使部分下载就能显示低分辨率预览。作者发现可以合并多张同分辨率图片、过滤掉SOI/SOF/EOI标记,制造出随加载过程切换显示内容的「坏JPEG」。大多数解码器限制9帧以防止zip炸弹式攻击,但通过仅使用DC系数的极小扫描,Chrome可渲染约90帧。由于纯DC帧是合规的JPEG,使用jpegtran的-scans参数即可生成。这种方式能「把整部视频塞进一张图片」,但无法控制播放节奏,完全依赖网络延迟。文中还展示了纯HTML实现的对话标签视频播放。文章最后提供了合并代码。
No.02
Reviving a 15-year-old netbook with Arch Linux
用 Arch Linux 复活 15 年前的上网本
81 分
40 条评论
作者: parksb
作者翻出 2009 年购入的华硕 Eee PC 1000HE上网本(Intel Atom N280, 1GB DDR2 RAM),尝试用 Arch Linux 32 为其续命。原机预装 Windows XP 已卡顿到几乎无法使用,而 Windows 7 及以上版本至少需要 1GB 内存,与本机配置持平,缺乏余量。作者最终选择 Arch Linux 32(因为 Arch 官方已于 2017 年停止支持 32 位架构),详细记录了制作启动盘、验证镜像、连接 Wi-Fi、设置 NTP 时钟、磁盘分区等完整安装过程。由于 Atom N 系列只支持 32 位,机器的无线网卡又只能连 2.4GHz 网络,安装过程有不少曲折。作者感慨,即使装好系统,由于瓶颈在于 HDD 和 CPU,也感觉不到明显性能提升——但折腾本身带来的学习价值才是乐趣所在。
No.03
AWS: Inaccurate Estimated Billing Data – $1.7 billion
AWS 账单系统故障:用户突收数十亿天价账单
1152 分
689 条评论
作者: nprateem
AWS 账单控制台近日出现严重故障,多名用户收到的预估账单金额离谱至极——从数百万到数万亿美元不等,有人甚至高达 21 万亿美元。AWS 已确认这是影响「预估账单数据不准确」的服务故障,并表示正在回滚近期对账单计算子系统的更改。多名工程师指出,根源可能是单位错误:将「GB」误作「Bytes」计算,差值达 2 的 30 次方倍。多名用户反映,正常月费仅几美分或几美元,却突然显示数亿乃至数千亿账单,触发恐慌性报警邮件。有用户批评 AWS 未同步推送故障通知,用户只能主动去状态页才能确认是系统问题,客服响应也不及时。评论者还质疑:如此关键系统为何会出现如此低级的单位 bug,是否与近期「AI 辅助编程」风潮有关。部分用户表示将考虑迁移至其他平台。
No.04
Thanks HN for 15 years of support and helping me find my life's work
感谢 HN 十五年支持:Recurse Center 如何帮助我找到毕生事业
539 分
53 条评论
作者: nicholasjbs
Recurse Center 联合创始人 Nick 借十五周年之际发文致谢 HN 社区。文章回顾了这家前身名为 Hacker School 的编程学习机构如何从 HN 诞生,帮助众多开发者找到自己的方向。Recurse Center 核心特色是「社会规则」(Social Rules)和「屋顶规则」(Roof Rule),营造无压力、专注学习的友好氛围。机构完全免费运营,主要靠捐赠维持,旨在吸引真正热爱编程的人,而非冲着免费资源而来。评论普遍高度评价这一社区,许多人表示 RC 改变了他们的人生轨迹,有人借此找到了终身朋友,有人从此走上独立开发之路。但也有亲历者认为体验「平淡」,未能充分融入;另有声音质疑纽约生活成本高企,「免费」标签下隐含的门槛并不低。
No.05
First atmosphere found on Earth-like planet in habitable zone of distant star
首次在宜居带发现类地岩石行星大气层:LHS 1140 b 或成最大发现
444 分
256 条评论
作者: neversaydie
哈佛大学Dr Collin Cherubim团队在《Science》期刊发表研究,首次在恒星宜居带内发现类地岩石行星LHS 1140 b存在大气层。该行星距地球48光年,环绕一颗红矮星运行,目前检测到的大气成分为氦气,尚不足以支持生命,但研究人员认为这是证明地球外可能存在类地世界的最强证据。团队强调尚未发现外星生命,但行星必须处于宜居带(Goldilocks zone)才能可能存在液态水。与LHS 1140 b同样受关注的还有K2-18b(曾发现疑似与海洋生命相关的气体但后被否定)以及TRAPPIST-1系统的多颗岩石行星。
No.06
The Zilog Z80 has turned 50
Zilog Z80 处理器五十岁生日快乐
210 分
70 条评论
作者: st_goliath
Zilog Z80 处理器于 1976 年 7 月正式发布,至今已满 50 年。它广泛应用于 8 位微型计算机、个人电脑、家用电脑及嵌入式工业领域,与 8080/8085 二进制兼容,共同催生了 CP/M 操作系统和 Microsoft BASIC 这一事实标准。Z80 还衍生出众多克隆架构,其中最著名的是 GameBoy 使用的 Sharp LR35902。文章回顾了从 Intel 8008 到 8080 再到 Z80 的技术演进史,8008 源于 1970 年代初 Datapoint 2200 终端项目,由Federico Faggin 和 Masatoshi Shima 主导开发,8080 则取消了对 8008 的二进制兼容性,改用外部堆栈和 16 位地址空间。Z80 在此基础上大幅扩展指令集,加入 IX、IY 索引寄存器和相对跳转等特性,标志寄存器行为与 8080 存在差异(评论指出并非完全兼容)。Zilog 最终放弃了 16/32 位派生架构,回归 Z80 微控制器产品线,Z80 直到两年前才最终停产,但 eZ80 仍在生产中。
No.07
TP-Link Kasa cameras leaked home GPS via unauthenticated UDP for 6 years
TP-Link Kasa 摄像头未认证 UDP 泄露家庭 GPS 长达六年
108 分
26 条评论
作者: BadChemical
安全研究人员 BadChemical 披露 TP-Link Kasa EC71 系列摄像头存在严重漏洞:摄像头通过未认证的 UDP 协议明文传输家庭 GPS 坐标,持续泄露长达六年。该漏洞在协调披露六个月后,分配到两个 CVE,但厂商在 triage 阶段曾错误描述了一个报告中并不存在的漏洞,随后才发布 beta 补丁修复。评论聚焦于几个议题:IoT 设备是否应暴露在公网上、有用户认为报告质量堪忧(疑似 AI 生成),也有用户指出问题根源在于消费者缺乏安全意识。有观点对比中美政府窃取数据的风险差异,并推荐 Apple HomeKit 作为更安全的替代方案。
No.08
Learning a few things about running SQLite
使用 SQLite 运行网站的几点经验教训
235 分
60 条评论
作者: surprisetalk
Julia Evans 分享在 Django 项目中使用 SQLite 的实战经验。她指出,虽然网上说 SQLite 适合小型网站生产环境,但它毕竟是数据库,复杂性依然存在。她启用 WAL 模式后,一个 FTS5 全文搜索查询在 4000 行数据上耗时 5 秒,运行 ANALYZE 后降至 0.05 秒——这让她意识到查询计划的重要性。大批量 DELETE 操作会阻塞写入导致 worker 超时崩溃,她通过分批删除解决。文章还介绍了两种备份方案:restic + VACUUM INTO + gzip,以及 Litestream 增量备份。评论中有人批评她缺乏深入调查,也有人称赞她坦诚的写作风格,并指出批次删除应预加载 rowid、用 SQLite CLI 执行操作,以及 Litestream 搭配 S3 后端使用很方便。
No.09
In-toto: A framework to secure the integrity of software supply chains
in-toto:保障软件供应链完整性的开放框架
11 分
0 条评论
作者: Erenay09
in-toto 是一个开源元数据标准框架,旨在确保软件产品从启动到最终用户安装的整个生命周期的完整性。该框架通过公开透明的方式,向用户清晰展示软件供应链中每一步操作的具体执行者、执行顺序以及执行内容,从而帮助验证软件产品未被篡改。由于采用开放且可扩展的标准设计,开发者可以在自己的软件供应链中灵活实现 in-toto 规范,提升供应链安全的可审计性和可信度。
No.10
Porting nanochat to a TPU: what carries over from PyTorch, and what breaks
将 nanochat 移植到 TPU:PyTorch 到 JAX 迁移中哪些保留、哪些失效
10 分
0 条评论
作者: tucan9389
作者记录了将 nanochat(一个基于 PyTorch 的轻量聊天模型)移植到 Google TPU 的过程与发现。核心问题围绕 PyTorch 与 JAX/JAX-EX(XLA)之间的生态差异展开。迁移顺利的部分包括:大多数张量操作、模型架构定义、批量推理逻辑等基础组件可以直接对应过来,因为两框架都遵循类似的底层计算图思想。主要挑战出现在:PyTorch 的动态图执行模式与 JAX 的函数式编程模型(pmap/jit 编译)之间的冲突,需要重构代码以适应 JAX 的不可变性和纯函数约束;设备间通信(all-reduce 等)在 TPU 上需要特殊处理;调试体验差异巨大——JAX 的 tracer 报错信息远不如 PyTorch 直观。作者建议先用 Flax 或 Equinox 等高级库封装,减少直接面对底层差异的痛苦;优先确保模型逻辑正确性,再考虑 TPU 特有的并行优化。整体是一篇实用导向的 PyTorch→JAX 迁移踩坑记录。
No.11
Stenchill: 3D Printable Solder Paste Stencil Generator
Stenchill:Gerber文件转3D打印钢网工具
40 分
7 条评论
作者: radeeyate
Stenchill是一个在线工具,可将PCB的Gerber文件直接转换为3D打印用的STL文件,用于制作助焊剂钢网。相比传统激光切割钢网($15-30/面),Stenchill完全免费,适合原型制作和小批量生产。内置对准肩设计便于精准贴装,配合0.2mm喷嘴、0.1mm层高、100%填充等参数打印,可获得良好效果。该工具尤其适合已有3D打印机但无激光切割设备的创客,帮助其在家完成0603及以上贴片元件的钢网制作。
No.12
Kimi K3, and what we can still learn from the pelican benchmark
Kimi K3 发布:还能从「鹈鹕基准测试」里学到什么?
324 分
169 条评论
作者: droidjj
中国 AI 实验室 Moonshot AI 于 2026 年 7 月 16 日发布 Kimi K3,号称拥有 2.8 万亿参数的自研大模型,定价 $3/$15 每百万 token,与 Claude Sonnet 系列持平,成为迄今最贵的国产模型。其自报基准测试显示 K3 超越 Claude Opus 4.8 max 和 GPT-5.5 high,但落后于 Claude Fable 5 和 GPT-5.6 Sol。文章作者 Simon Willison 用经典的「生成一只骑自行车的鹈鹕 SVG」测试 K3,发现它用了 13,241 个推理 token 输出 3,417 个回答 token,成本高达 25 美分。Willison 指出「鹈鹕基准」的最大局限在于完全无法测试当今模型最关键的能力:智能体工具调用和多轮对话中的可靠性。不过他认为该基准仍有价值:强制自己实际体验模型、估算成本和推理消耗、验证基本的几何空间感知能力。他还提到 GPT-5.6 和 Claude Fable 5 的鹈鹕已不如 GLM-5.2,暗示模型厂商可能已开始针对该基准做训练优化。
No.13
Vāgdhenu: A Sanskrit Chanting TTS System
展示: Vāgdhenu — 梵文诵经 TTS 系统
151 分
32 条评论
作者: subinalex
Vāgdhenu 是印度团队开发的开源梵文诵经语音合成系统。用户粘贴任意印度文字书写的梵文 verse,系统自动检测韵律(vṛtta)并生成诵经音频。技术层面,该系统以 flow-matching TTS 为基础,在约 5 小时单人说唱梵文语料上微调,神经声码器针对诵经音域优化,专家 MOS 达 4.6 分。其核心创新包括:通过 Kannada 正字法路由规避 Hindi schwa 删除问题、正确处理 visarga sandhi 的音位变体、保持三个 sibilants 和完整卷舌音系列的区别,以及 vṛtta-aware 机制自动检测韵律并选择匹配诵经参考。系统已生成 Mahābhārata Tātparya Nirṇaya(5,183 verses)和 Śrīmad Bhāgavatam(约 18,000 verses)两个大规模诵经语料库,支持配套 app 和 Vāgbodhinī 诵经导师工具。社区反馈呈现两极:网站「vibe coded」风格掩盖了技术深度,部分用户对其发音准确性存疑,但技术派认为项目对梵文复杂音位的处理(尤其区分 aspirates 和 retroflexes)具有实质突破。
No.14
Shipping OpenStrike: A Counter-Strike-Shaped FPS on a 2004 Handheld
在2004年掌机上跑《反恐精英》形状的FPS:OpenStrike发布
36 分
14 条评论
作者: itvision
OpenStrike是一款在索尼PSP(2004年,333MHz MIPS单核,32MB内存)上运行的单人FPS,模仿经典GoldSrc时代地图,支持机器人、弹道、枪械后座和回合制玩法。引擎用Rust编写,游戏规则和HUD用TypeScript/Solid.js实现,JavaScript端只被调用一次且不能阻塞模拟,保证帧率锁定60fps。地图格式为BSP,其预计算的「潜在可见集」(PVS)实现了零运行时开销的遮挡剔除。构建工具pocket3d-cook在打包时将光照烘焙为顶点颜色、纹理转换为8位调色盘索引、顶点坐标量化为16位整数,使GPU可直接读取数据、跳过加载步骤。这既是PocketJS runtime的展示,也是一份「web技术栈的 ergonomics 能否超越UI、跑到实时3D游戏」的实证。有社区评论质疑这类「复古游戏」的真实受众、认为文章文风有LLM味;但也有人指出这是面向开发者的技术演示而非商业产品。
No.15
An Update on Igalia's Layer Based SVG Engine in WebKit (Reducing Layer Overhead)
Igalia 发布 WebKit 基于图层 SVG 引擎更新:解决每个元素强制建层的性能开销问题
41 分
1 条评论
作者: bkardell
Igalia 披露了 WebKit 中基于图层的 SVG 引擎(LBSE)最新进展。LBSE 虽已登陆 WebKit 但仍非默认选项。核心目标是让 SVG 复用 HTML/CSS 的 RenderLayer 树,从而继承 GPU 加速变换、透视变换、z-index 等所有后续优化,而非像传统 SVG 引擎那样成为独立孤岛。代价是共享 machinery 需要同时为 SVG 常见而 HTML 少见的场景(如每个元素都带 transform)优化,且不能拖累 HTML 性能——每个 SVG 元素曾强制建层的设计造成大量开销。2026 年上半年 Igalia 投入新一轮开发,完成了自 LBSE 创建以来最大一次改造:条件性图层创建,按需生成而非全局强制。团队同时修复了文本渲染、滤镜、崩溃等大量正确性问题,为后续性能对比铺路。
No.16
I started a “dirt notebook”
我开始用「泥土笔记本」来对抗记录完美主义
52 分
43 条评论
作者: herbertl
作者分享了一个有趣的笔记本使用困境:每当开始新笔记本,最终都会不自觉地追求整洁美观,给笔记添加结构、精心书写、贴装饰贴纸,导致笔记本变得过于「完美」而不敢随意涂写,循环往复。作者的对策是专门准备了一本「泥土笔记本」(Dirt Notebook),昵称「排水沟」(The Drainage Channel),故意使用纸质很差、钢笔墨水会洇开、无法平摊的旧笔记本,强迫自己只能用廉价圆珠笔潦草记录一周来的各种想法:播客引述、故事灵感、生活反思、学习笔记等,完全没有结构。作者的初步目标是把第一本「泥土笔记本」写满,学会拥抱混乱,之后再考虑换回更好的纸张和钢笔墨水。这个概念呼应了社区对「shitty / messy notebooks」的长期兴趣。
No.17
Battery packs: Let's talk about crates, baby
Battery Packs:聊聊 Rust 的crates组合方案
15 分
3 条评论
作者: MeetingsBrowser
博主提出「battery packs」概念——一种围绕共同主题精心策划的crates组合,如CLI电池包(涵盖构建优秀CLI所需的一切)、后端服务电池包、嵌入式开发电池包、错误处理电池包等。其核心解决的是新手Rust开发者普遍面临的选择困难:crates.io上有大量高质量crate,但研究比较替代方案耗费大量时间。电池包提供一组推荐选项,但不锁定项目,开发者随时可替换其中的单个crate。
关键设计是开放性——任何人都能创建电池包,只需发布一个名为X-battery-pack的crate,其中dependencies即为推荐。配套工具cargo-bp已可用,支持cargo bp list查看可用电池包、cargo bp add添加电池。电池包还支持分组和互斥选项(如「并发框架最多选一个」),以及非依赖类「配方」如CI模板。
作者还希望Rust商业网络的工作组能发布和维护电池包,并借此建立生态系统基金资助维护者、推动标准化与互操作性。
No.18
Static search trees: 40x faster than binary search (2024)
静态搜索树:比二分搜索快40倍
105 分
6 条评论
作者: lalitmaganti
本文实现了一种静态搜索树(S+树)用于高速搜索排序数据,目标是最大化吞吐量。作者从 Algorithmica 提出的 S+ 树基础出发,依次应用线性搜索、自动向量化、尾零计算、Popcount、SIMD手动优化、预取、指针算术等十余种技术进行极致优化,并探讨内存布局(Eytzinger布局、左侧树)、节点大小B=15、前缀分区、并发查询批处理等关键设计选择。实验使用均匀随机31位整数作为查询和输入,分配2MB巨页减少TLB压力。最终在大型数据集场景下,优化的搜索树相比标准二分搜索快约40倍,接近CPU缓存极限。研究动机源自生物信息学中加速DNA索引(如人类基因组)后缀数组搜索的需求。评论区对Eytzinger布局的普适性提出质疑,认为在小数据集上可能不如简单排序数组。
No.19
DrDroid (YC W23) Is Hiring
DrDroid(YC W23)招聘产品工程师:打造运维 AI Agent
1 分
0 条评论
作者: TheBengaluruGuy
DrDroid 是 Y-Combinator W23 加速营项目,获得 Accel 投资,正在招聘产品工程师。该公司致力于为平台和基础设施团队打造 AI Agent,帮助工程团队更快定位并修复生产问题、减少值班时的升级事件,核心技术涵盖自动化故障排查、调试和问题修复。其团队还维护多个开源项目:Playbooks(自动化运行手册平台)和 Kenobi(数据管道事件分析平台)。公司的愿景是让普通工程师无需资深工程师介入即可独立解决常见生产问题,重新定义后 GPT 时代团队运维方式。
No.20
Lego building instructions through time
乐高搭建说明书发展史
107 分
24 条评论
作者: NaOH
本文回顾了乐高积木搭建说明书的历史演进。1955年前仅有包装上的简图作为参考,同年「乐高玩法系统」推出后才出现首批专用说明书。1958年现代乐高积木诞生,互锁结构大幅提升稳定性。1967至2003年间,说明书绘制工作主要由丹麦科灵镇的Palle Munch公司承担。早期制作流程繁琐:先由设计师搭建实物模型并拍照,再由画师按1:1比例手绘(每个凸点直径7.5毫米),最后缩放并上色。1983年乐高成立专门的说明书团队,三年后引入电脑绘图工具「Panter」(以Palle命名)。社区评论聚焦于现代说明书的争议:有玩家认为1964年的说明书复杂度恰到好处,如今的步骤被拆得太细太简单;也有人赞赏APP中「一起搭建」功能,让不同节奏的玩家能愉快合作。此外,用数字工具复刻乐高模型的难度远超想象。
No.21
Open Book Touch: open-source e-reader
Open Book Touch:开源可编程电子书阅读器
101 分
36 条评论
作者: surprisetalk
Open Book Touch 是一款历时六年打造的开源电子书阅读器,搭载 4.26 英寸 480×800 前照式电子纸屏,无物理按键,采用 ESP32-S3 微控制器,厚度仅 1 厘米可放入口袋。支持 EPUB 和纯文本文件,内置 GNU Unifont 字体引擎,覆盖拉丁、西里尔、阿拉伯、希伯来、中日等数十种书写系统。双色前照灯支持冷暖色温调节。采用 MIT 协议完全开源,包含自研 Focus C++ 应用框架。Wi-Fi 传书、microSD 扩展、电池可自行更换,3D 打印咔哒式外壳可个性化定制。正在 CrowdSupply 众筹,硬件文件待发货后公开。社区争议集中在:无物理按键需滑动翻页(体验差于 Kindle Oasis/Kobo/PocketBook)、4.26 英寸屏幕偏小、开源优势是否足以弥补功能短板(KOReader 加持的 Kobo 可替代),但其完全开源和高度可定制性仍获得开源爱好者认可。
No.22
The Isomorphic Labs Drug Design Engine unlocks a new frontier beyond AlphaFold
Isomorphic Labs 发布新药设计引擎 IsoDDE,准确率与功能超越 AlphaFold 3
70 分
6 条评论
作者: andsoitis
Isomorphic Labs 发布其药物设计引擎 IsoDDE,在蛋白质-配体结构预测上准确率是 AlphaFold 3 的两倍以上,能以极低成本超越黄金标准物理学方法的结合亲和力预测精度,并仅凭氨基酸序列即可识别新型结合口袋。以 cereblon 蛋白为例,IsoDDE 成功复现了 2026 年才发现的隐藏别构口袋,证明其泛化能力。然而社区质疑:该模型无公开试用、未经同行评审,技术细节语焉不详,仅称「将发布白皮书」,未披露架构突破或训练方法。
No.23
Show HN: IKEA Complexity Index
展示:IKEA 复杂度指数
9 分
3 条评论
作者: gregsadetsky
一个由爱好者开发的非官方网站,根据 IKEA 产品的「组装步骤数乘以零件总数」计算复杂度并排名。用户可浏览各产品的组装耗时数据。网站声明与 IKEA 无隶属关系,仅为个人兴趣项目。评论者以 LÖNSET King 尺寸板条床为例,花了 3 小时组装完成,认为 140 美元的价格算便宜的消遣,并调侃「我见过更贵的爱好」。整体反映了 IKEA 家具组装难度受关注,爱好者通过量化指标将主观体验可视化。
No.24
The state of open source AI
开源AI现状:开放权重模型已跨越「从 promising 到 ready」的门槛
424 分
303 条评论
作者: rellem
Mozilla 发布《开源AI现状》报告,指出开放权重模型已从概念验证进入规模化生产阶段。Hugging Face 托管 250 万个模型、1300 万用户;OpenRouter 每周处理 25 万亿 token,开放模型已超越闭源模型份额(63% vs 37%,四个月内逆转)。报告列举了多个落地案例:新西兰 Māori 广播公司训练本土语言模型、瑞士公共联盟用超级计算机训练国家模型、东非农民用离线手机模型诊断木薯病害等。然而挑战依然存在:仅 51% 的开源模型团队成功投产对比闭源的 63%,差距源于运营工具和信任缺失;价值正向上转移到「agentic harness」代理控制层;安全与滥用风险仍未解决;开源模型多来自中国私人公司,可持续性存疑。报告呼吁各方在 AI 决策桌上为开源保留席位。
No.25
Kaiser nurses say AI, surveillance are making their jobs and patient care worse
Kaiser护士抗议AI监控:超15分钟通话即遭批评,患者护理质量堪忧
490 分
309 条评论
作者: gnabgib
Kaiser Permanente呼叫中心的护士们向CalMatters反映,工作场所监控与AI正威胁其护理职责。多名护士透露,超过15分钟的患者通话会遭管理层批评,甚至进入绩效评估;Kaiser还用软件预测员工「效率低下」,并测试AI工具评估护士同理心与语调。部分护士因担心影响绩效评分,不敢对需要情感支持的患者(如刚获知癌症诊断的老年妇女)给予充分关怀。有护士为接听想自杀的患者通话超过一小时,焦虑于平均处理时间受影响。护士工会与Kaiser的合同谈判正在进行,AI监管是焦点议题。Kaiser否认使用「平均处理时间」评估绩效,称AI工具用于质量保证且有人类监督。但消费者权益组织指出,Kaiser有将成本置于护理之上、为节省开支而压缩服务时长的历史。
No.26
Painting the sides of railroad rails white to reduce derailment
Union Pacific将铁轨两侧涂白漆应对高温挑战,期望降低脱轨风险
85 分
45 条评论
作者: zdw
联合太平洋铁路公司正在将铁轨两侧涂成白色以应对夏季高温导致的铁轨热膨胀问题。首席安全官Rod Doerr表示,白色油漆能反射阳光,将铁轨表面温度降低约20华氏度,「如果你不在与太阳热量的斗争中,你就大大降低了铁轨移位的风险」。该公司借鉴欧洲铁路技术和美国公路标线做法,使用高rail卡车在铁轨两侧喷涂白漆。这项措施是该公司2025年脱轨事故率同比改善19%、创下历史最佳成绩的安全策略的一部分。Doerr称,据他所知,美国没有其他铁路公司在采用这种做法,该技术在欧洲已有验证。评论中有人质疑措辞是否说反了意思,也有人指出这是连续焊接铁轨无处膨胀的问题根源。
No.27
Show HN: A zoomable timeline of 4M Wikipedia events
展示:400 万 Wikipedia 事件可缩放时间线
89 分
31 条评论
作者: lortex
这是一个交互式可视化工具,将 Wikipedia 上的 400 万事件以可缩放时间线呈现,使用对数缩放让用户能流畅浏览从宇宙诞生到当代的巨大时间跨度。评论普遍认可对数缩放设计使海量事件变得可探索,数据来源于 Wikidata 自动提取 Wikipedia 文章元数据。主要问题包括:部分浏览器(Firefox、Chrome Android)出现卡顿或崩溃;加载时显示空白屏缺乏反馈;数据质量不稳定——有用户发现年份 760251 实为邮编误植,还有远古未来事件被误标为过去式等明显错误。开发者 lucas 承认后端压力较大,表示将逐步修复这些问题,并计划加入过滤器等功能提升可用性。
No.28
Frank Lloyd Wright’s first home
弗兰克·劳埃德·赖特的首宅:橡树园故居与工作室巡礼
100 分
51 条评论
作者: NaOH
本文系统介绍了建筑大师弗兰克·劳埃德·赖特在伊利诺伊州橡树园的故居与工作室。1889年,22岁的赖特在老板路易斯·沙利文资助下购地建屋,1895年扩建,1898年增建工作室翼。建筑原为木瓦风格,区别于其后来著名的「草原风格」,内部八角形图书馆、双高绘图室及圆顶天窗playroom等细节,处处体现其“压缩与释放”的空间手法。赖特在此完成众多早期草原派设计,1974年至1987年经历耗资250万美元的修复工程,得以重现1909年原貌。评论中多位访客既赞叹其建筑语言的超前(看似50年代实为20世纪初作品),也批评其私生活争议、缺乏执照执业,以及部分作品如「落水山庄」的漏水问题;另有观众将这位天才建筑师与当代「创业明星」相提并论,认为其个人魅力与商业头脑并存。
No.29
Moonstone: Modern, cross-platform Lua runtime and package manager written in Zig
Moonstone:使用 Zig 编写的现代化 Lua 运行时与包管理器
50 分
13 条评论
作者: ksymph
Moonstone 是一个新兴的 Lua 环境与包管理器,而非部分用户误读的「用 Zig 实现的 Lua 虚拟机」。它提供一键安装脚本(curl -fsSL https://moonstone.sh/install | bash),旨在为开发者提供可靠的 Lua 运行环境。社区反馈呈现两极分化:支持者认可 Lua 在 DSL 嵌入(如魔兽世界脚本、OpenResty 规则)领域的优势;质疑者则认为现有 LuaRocks 等生态已足够完善,且批评其文档疑似由 AI 生成。项目作者澄清 Moonstone 仍处于密集开发阶段,尚未发布正式版本,并开放协作(maximoverzini@gmail.com)。另有评论者对帖子的异常 upvotes 模式提出疑问,暗示可能存在刷票行为。
No.30
Three ways people respond to a problem (other than solving it)
人们面对问题的四种反应:除了解决问题,还有推诿、维稳和制造新问题
232 分
130 条评论
作者: surprisetalk
一位咨询顾问总结了人们面对问题的四种典型反应:解决问题、推诿问题、维稳问题、制造新问题。「推诿问题」是组织中最常见的——在此处改善却让彼处恶化,本质是局部优化,不要责怪个人而应调整激励制度。「维稳问题」即著名的「谢尔基原则」:机构往往会维续它们赖以存在的那个问题,文中以无家可归者项目举例,高额投入却未真正解决问题——因为解决问题意味着自身存在价值消失。「制造新问题」是咨询顾问的职业病,需时刻警惕:消除头号问题后,原来的二号问题就会上位。作者建议放弃「终有一天能彻底解决问题」的幻觉,学会在必要时忽略问题,才能真正活在当下。
评论精华