1.
Jira Is Turing-Complete
Jira 是图灵完备的
126 分
42 条评论
作者: vinhnx
作者通过在 Atlassian Jira 的自动化功能中构造一台 Minsky 双计数器寄存器机,给出了 Jira 图灵完备的严格归约证明。具体映射方式是:用 Epic 的状态编码当前指令,用关联工单的数量充当寄存器,「INC」与「DEC」对应工单的创建与删除,条件分支由 JQL 条件规则实现。文章演示了一个最小可运行实例:用一个 Epic、五个关联工单和每条指令对应的一条自动化规则,完成 2+3=5 的加法运算,并在真实 atlassian.net 实例上记录了五次状态跃迁的执行轨迹。作者还利用「Convert Issue Type」把 DEC+INC 合并为单步操作,把 Fibonacci 机压缩到三个状态、三种工单类型,结果序列出现在 Task 计数中;由于 Jira Cloud 有 10 层链式触发深度上限,需要人工再触发 Epic 继续推进,但归约依然成立。结论是:复杂的 Jira 自动化之所以像程序,是因为它字面意义上就是程序。
2.
Didgeridoo playing as alternative treatment for obstructive sleep apnea(2006)
迪吉里杜管演奏作为阻塞性睡眠呼吸暂停的替代疗法(2006)
78 分
20 条评论
作者: kelseyfrog
这是一篇 2006 年发表于《英国医学杂志》(BMJ) 的随机对照试验研究,探讨澳大利亚原住民传统乐器「迪吉里杜管」(didgeridoo) 演奏对中度阻塞性睡眠呼吸暂停综合征 (OSA) 患者的治疗效果。研究通过中央电话服务进行随机化分配,对招募医师和迪吉里杜管教师双盲设计。结果显示,规律练习该乐器能显著改善患者的睡眠质量、减少日间嗜睡,并降低呼吸暂停-低通气指数。关键机制被认为是吹奏过程中训练了上呼吸道肌肉,特别是「循环呼吸」(circular breathing) 技巧对软腭和咽部肌肉的强化作用。评论区有读者讨论该研究缺乏安慰剂对照组的局限性,也有人指出类似的舌部和咽喉肌肉训练 (如吸气肌训练 IMT) 可能达到同样效果而不扰民。一名读者亲述十年练习迪吉里杜管预防睡眠呼吸暂停复发的经验。
3.
Show HN: Audiomass – a free, open-source multitrack audio editor for the web
展示: Audiomass — 免费开源的网页多轨音频编辑器
331 分
68 条评论
作者: pantelisk
作者发布了 Audiomass 的多轨编辑模式,这是一款完全运行在浏览器中的免费开源音频编辑器,整体仅 98KB JS 加 10KB CSS,体积极为精简。项目在视觉与交互上致敬经典的 Cool Edit Pro 与 Audacity,但带来更现代、平静且直观的 UX,原生支持 FLAC 等格式,被不少用户视为「终于不用再忍受 Audacity」的替代品。代码风格也颇为复古,采用安全闭包、函数赋值、顺序 var 声明等「老派」写法,让一些开发者感到怀旧。社区讨论焦点集中在功能边界:目前不支持 MIDI 与 VST 插件,也缺乏 stem bundle(如 Suno、stemsplitter 输出)的导入;有用户希望加入云端协作与「分支签出」式的多人协作工作流,作者回应会谨慎评估,避免破坏体积与性能。已有用户成功加载 1 小时以上播客甚至 12 小时有声书,整体反馈以正面为主。
4.
I love my Bluetooth keyboard
我爱我的蓝牙键盘
53 分
31 条评论
作者: evakhoury
作者去中国旅行十天没带电脑,只带手机加一个蓝牙键盘,结果意外地爱上了这种组合。他总结了三大好处:一是用键盘给朋友发消息体验远胜虚拟键盘,可快速打字并使用复制粘贴;二是用键盘在手机备忘录里写作接近「打字机体验」,因为手机屏幕离手太远反而难以分心,娱乐内容在小屏上也不够吸引人,但又保留了文字处理器的编辑便利;三是开启 iOS 的「完整键盘访问」后,可用快捷键导航手机,「Cmd+Space」搜索成了他最常用的命令,弥补了手机端缺少 Alt+Tab 的遗憾。作者承认这种方式也让他在聊天中更啰嗦,并注意到手机上写出的段落明显更短,可能因小屏让空白页看起来不那么吓人。他用的是 Logitech Pop 键盘,但并不强推具体型号。
5.
DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost
DeepSeek Reasonix:面向 DeepSeek 的原生编码 Agent,主打高缓存命中与低成本
537 分
225 条评论
作者: Alifatisk
Reasonix 是一个第三方开源编码 Agent(非 DeepSeek 官方),专为 DeepSeek 模型设计,核心卖点是利用 DeepSeek 的「字节稳定前缀缓存」(byte-stable prefix cache)实现 90%+ 的缓存命中率,长会话输入 token 成本可降至原来的 1/5。其设计采用「append-only」事件循环,不做重排序或基于标记的上下文压缩,以最大化前缀复用;同时内置「工具调用修复」(schema-aware repair)来纠正模型输出的 JSON 错误。在 Claude Code 限额收紧、各家前沿模型涨价的背景下,作者意在为 DeepSeek V4 用户提供 C/Codex 之外的廉价替代。但社区争议明显:网页本身被批评由 AI 生成、动画导致布局抖动、字体配色出错;不少人质疑其相对 OpenCode、Pi Agent 等成熟 harness 没有实质差异,且 DeepSeek 官方编码 harness 据称即将发布,第三方工具的存在意义存疑。
6.
Migrating from Go to Rust
从 Go 迁移到 Rust
240 分
226 条评论
作者: jabits
作者是 Rust 咨询顾问,坦言对 Go 设计有偏见,但试图客观对比两者。文章聚焦后端服务场景:Go 和 Rust 都是编译型、静态类型、单二进制部署语言,工具链都很完善,差别在于编译器提供的保障强度。Go 依赖约定、`go vet`、`-race` 等工具和运行时检测来维持正确性,而 Rust 把空值处理(`Option`)、错误传播(`Result`)、数据竞争(`Send`/`Sync`)、资源生命周期等都编码进类型系统。例如共享可变 `HashMap` 跨线程在 Go 中能编译通过、生产环境炸掉,在 Rust 中直接是类型错误,必须用 `Arc>` 或 channel。作者承认 Go 在大多数后端工作负载下「足够快」,迁移动因主要是冗长的错误处理、`nil` 段错误、长期缺失泛型以及类型系统薄弱(连 `Set` 都没有,要用 `map[T]struct{}` 模拟)。文中引用 InfluxDB 3.0 重写案例佐证「无畏并发」的价值,并讨论何时该坚持用 Go、何时迁移划算,以及增量迁移策略。
7.
White Rabbit – sub-nanosecond synchronization for large distributed systems
White Rabbit:面向大型分布式系统的亚纳秒级同步技术
81 分
21 条评论
作者: michaelsbradley
White Rabbit 是源自 CERN 的开源同步技术,为大型分布式系统提供亚纳秒级精度和皮秒级精确度的时间同步,同时支持确定性、可靠的数据传输。它本质上是在 PTP(精确时间协议)和 SyncE(同步以太网)基础上增加额外智能:通过相位锁定环路测量主时钟与本地时钟的相位差,并对光纤温度变化引起的长度变化进行主动补偿,从而在节点间典型距离 10 公里、最多数千节点的规模下实现千兆以太网级可靠数据传输。该技术完全开放硬件、固件和软件,已有多家厂商商业化生产相关设备。CERN 实验室测试显示,在 50 公里光纤上主从客户端的相位锁定抖动约为 10 皮秒;最新的 eRTM 板卡在 100Hz 至 20MHz 区间集成抖动低于 100 飞秒,是目前已知最精密的 WR 节点。文章同时发布了多个 FPGA 与硬件工程师招聘信息,用于推进 WR 交换机 v4 等下一代项目。
8.
Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
Firefox 修复 Intel Raptor Lake CPU 崩溃 Bug
78 分
21 条评论
作者: luu
这是 Mozilla Firefox 的一个补丁(Bug 1950764),用于绕过 Intel Raptor Lake CPU 上的硬件缺陷导致的崩溃。问题出在 Huffman 编码相关代码中,LLVM 编译器生成了「movb %ch, [mem]」这类使用高 8 位寄存器别名(h 寄存器,即 bits 8..15)的存储指令,在受影响的 Raptor Lake CPU 上会触发错误。修复方法是改写源码,把两个 dist 字节合并为单个 2 字节存储,避免这种指令模式。社区指出同样的问题在 Oodle 压缩库(同样是 Huffman 编码场景)中也被独立发现,背景文章见 fgiesen 博客。讨论焦点在于:这种在每个软件里手工绕过硬件 bug 的做法不可持续,正确的解法应该是 Intel 出微码更新或 LLVM 层面规避;而 Intel 此前在 Raptor Lake 电压不稳问题上的处理态度也让用户信任度下降,有人将其与当年的「Pentium FDIV bug」相提并论。
9.
A fundamental principle of aeronautical engineering has been overturned
航空工程基本原理被颠覆:微观粗糙表面反能减阻
149 分
73 条评论
作者: littlexsparkee
日本东北大学流体科学研究所的Aiko Yakino副教授团队首次证明,在物体表面施加肉眼无法分辨的「分布式微观粗糙度」(DMR),可将气动阻力降低多达43.6%。这颠覆了80多年来「表面越光滑阻力越小」的航空工程基本原理。该原理源自1940年谷一郎的研究,但他在1989年自己重新解读数据时已暗示粗糙未必只促进湍流转捩。团队采用1米磁悬浮天平系统(1m-MSBS)让模型在风洞中无接触悬浮,避免支撑杆干扰气流,精确测量了雷诺数0.35×10⁶到3.6×10⁶范围的阻力。DMR涂层高度仅为边界层厚度的1%,机理与高尔夫球凹坑及鲨鱼皮微沟槽完全相反——后者通过制造湍流减小压差阻力,而DMR延迟层流到湍流的转捩,直接抑制壁面摩擦本身。大涡模拟(LES)确认主要因素是摩擦阻力降低而非分离抑制。该技术随机分布、不依赖气流方向,无需运动部件或电力,若应用于飞机有望显著降低运营成本和碳排放。
10.
C constructs that still don't work in C++
那些在 C++ 里仍然行不通的 C 写法(以及一些已经变了的)
49 分
33 条评论
作者: jalospinoso
作者在 2019 年那篇「C 在 C++ 里行不通的写法」基础上,结合 C++20 与 C23 的更新做了重新梳理。核心观点是:C++ 从来不是 C 的超集,讨论兼容性时必须明确语言版本(C17、C23、C++17、C++20、C++23)。C++20 引入了「指派初始化」,但只允许按声明顺序、直接非静态成员,不支持数组下标、嵌套指派或与位置参数混用,因此并非 C99 的等价物。C23 则把 「void f()」改为等同于「void f(void)」,向 C++ 靠拢,但旧 C 代码可能因此在 C23 下编译失败。关于「malloc」与对象生命周期,C++20 为「隐式生命周期类型」打了补丁,「std::malloc」配 「static_cast」对聚合类型不再是反例,但仍不会调用构造函数,对「std::string」之类类型依然是未定义行为,应使用「placement new」或「make_unique」。「const_cast」可以编译并不等于行为有定义,向真正的 const 对象写入仍是 UB。文章强调:写跨语言代码时,要问清谁拥有存储、何时开始生命周期、如何初始化、谁负责析构、失败如何处理。
11.
I spent 50 hours drawing a line graph
我花了 50 小时手绘一张折线图
514 分
91 条评论
作者: dougdude3339
艺术家 Doug MacDowell 分享了用尺子、铅笔、墨水和字模套件手工绘制数据可视化的过程,软件 20 分钟能搞定的事,他花了 50 多小时。文章以一张关于咖啡机电脑的折线图为例,详细介绍了所需工具:光面 Bristol 纸、丁字尺、三角板、圆形模板、Micron 针管笔、字模套件等。绘制流程从打网格开始,用铅笔标点后借助圆形模板控制线宽,再用直边工具连接圆的外缘形成折线,最后上墨、擦除铅笔痕迹。作者推荐了 Tufte、杜波依斯、Brinton 等人的经典手绘数据可视化书目,认为手绘不仅是技艺,更是艺术。他坦言这是一种「软件 20 分钟、人工一周」的反效率实践,但慢工出细活,过程本身就是收获。配图被 Hackaday 评价为「像 1970 年代大学课本里走出来的」。
12.
Constraint Decay: The Fragility of LLM Agents in Back End Code Generation
约束衰减:LLM 智能体在后端代码生成中的脆弱性
227 分
122 条评论
作者: wek
论文系统评估了 LLM 智能体在多文件后端代码生成中处理结构性约束的能力。研究固定统一的 API 契约,覆盖 8 个 Web 框架共 100 项任务,结合端到端行为测试与静态校验进行双重评估。核心发现是「约束衰减」现象:当架构模式、数据库、ORM 等结构性要求逐步累积,智能体性能显著下滑,强配置从基线到完整规约平均掉 30 分断言通过率,弱配置接近归零。框架敏感性分析显示,智能体在 Flask 这类显式简洁框架表现尚可,但在 FastAPI、Django 等约定重的框架中明显劣化。错误分析指出数据层缺陷(查询组合错误、ORM 运行时违规)是首要根因。结论是:同时满足功能性与结构性需求仍是编码智能体的核心未解难题,意味着智能体适合快速原型而非生产级后端。
13.
Microsoft open-sources “the earliest DOS source code discovered to date”
微软开源「迄今发现最早的 DOS 源码」
464 分
164 条评论
作者: DamnInteresting
微软再次公开 MS-DOS 早期源码,这次回溯到品牌诞生之前,发布了 86-DOS 1.00 内核源码、PC-DOS 1.00 内核多个开发快照,以及 CHKDSK 等经典工具的代码。由 Stacey Haffner 与 Scott Hanselman 撰文宣布。文章简述了 DOS 的来龙去脉:程序员 Tim Paterson 最初为 Seattle Computer Products 的 Intel 8086 套件写出 86-DOS(前身为 QDOS,意为「快速且简陋的操作系统」);微软为了给开发中的 IBM PC 5150 提供操作系统,先授权 86-DOS 并聘用 Paterson 继续开发,随后买断全部权利。微软将其授权给 IBM 称作 PC-DOS,自留对外销售权,对外版本即 MS-DOS。八九十年代 IBM PC 兼容机泛滥,使 MS-DOS 成为绝大多数人实际使用的版本。值得一提的是,这批源码因年代久远从未数字化保存,团队不得不从纸质打印件 OCR 还原。
14.
Memory has grown to nearly two-thirds of AI chip component costs
内存成本已占AI芯片元件成本近三分之二
373 分
386 条评论
作者: intelkishan
Epoch AI 对英伟达、AMD、谷歌、亚马逊设计的 AI 芯片进行成本拆解,将单芯片成本分为四类:内存(HBM)、逻辑芯片、先进封装(CoWoS)和辅助元件,再乘以季度产量估算总支出占比。从 2024 年 Q1 到 2025 年 Q4,内存份额从 52% 飙升至 63%,封装从 19% 降至 15%,辅助元件从 15% 降至 9%,逻辑芯片稳定在 13-14%。AI 芯片元件总支出从 2024 年约 220 亿美元增至 2025 年约 520 亿美元,其中 HBM 单项就贡献了约 200 亿美元的增量。这一结构性转变意味着内存已成为 AI 算力扩张的最大成本中心,也是产业链瓶颈所在。
15.
Scientists solve 200-year-old puzzle of how tobacco plants make nicotine
科学家破解 200 年悬案:烟草如何合成尼古丁
84 分
27 条评论
作者: sohkamyung
约克大学与哥本哈根大学团队在《自然·通讯》发表研究,揭开烟草植物(Nicotiana tabacum)合成尼古丁的完整生化路径,终结了自 1828 年首次从烟叶中分离出尼古丁以来困扰科学界 200 年的谜题。研究发现尼古丁分子最初以「葡萄糖加合物」形式合成,葡萄糖为构筑单元提供能量推动两个环状结构拼接,但在最后一步又被脱去并「凭空消失」,正是这一隐藏步骤让该路径长期成谜。团队还解析了两个关键酶 NaGR 和 NicGS 的精确结构,证实尼古丁的两个环分别来自类维生素化合物和氨基酸代谢。该成果具备重要应用价值:烟草近缘种本氏烟草(Nicotiana benthamiana)已被广泛用于「分子农业」生产疫苗和药物,但天然尼古丁污染是长期障碍。掌握合成机理后,研究者可敲除或改造该路径,让烟草成为更纯净的药用蛋白生产平台,甚至改造其酶系统合成新型药物分子,让烟草「不再用于香烟,而是造福医药」。
16.
Build Adafruit projects right from Firefox
Firefox 151 新增 Web Serial:浏览器直连 Adafruit 开发板
159 分
50 条评论
作者: mch82
Mozilla 与 Adafruit 合作推出落地页,宣传 Firefox 151 新增的「Web Serial」API 支持,让用户可直接从浏览器与兼容的开发板(如 Arduino、ESP 系列、Adafruit 板卡)通信,无需安装本地驱动或 IDE。这一变化标志着 Mozilla 立场的重大转向:2020 年 Mozilla 曾明确反对 Web USB、Web Bluetooth、Web NFC、Web MIDI 等「原始设备访问」类规范,认为存在安全与隐私隐患。如今 Firefox 终于跟进 Chromium 阵营已支持 5 年的能力,主要面向教育机器人(First、Vex 等平台)、微控制器烧录(如 Meshtastic)等场景,降低初学者门槛。功能通过类似 Web MIDI 的「附加组件门控」机制启用,需用户显式授权。社区普遍欢迎,但也有人担忧浏览器控制外设带来的恶意代码注入风险,并期待 Web USB、Web Bluetooth 后续跟进。
17.
The Eternal Sloptember
永恒的 Sloptember:AI 编程代理是软件史上最昂贵的错误
288 分
210 条评论
作者: razin
geohot(George Hotz)旗帜鲜明地宣称:将 AI 代理引入软件开发将成为该领域历史上代价最惨重的错误之一。他过去六个月用代理写过 tinygrad、逆向过 USB-PCIe 芯片,结论是代理「会把进度全部前置,然后给你一根老虎机拉杆」,最后的打磨永远做不到位。他承认 AI 是更好的「Google」,做原型极快,但远未达到工程师标准。真正的危害在大型组织内部:高手能识别「slop」并修正,底层员工却用代理产出十倍垃圾,组织平均质量被拉低。他举苹果强推 AI 为例,预测 macOS 两年后只会更糟。人们看到产物时默认背后是人类心智,而 AI 产物以前所未有的方式破碎,语法正确却无法在人类层面被继续构建。他认同 LeCun/Marcus 阵营,认为 LLM 永远不会真正编程,需要「世界模型」而非「注释掉失败测试就宣称通过」的 RLVR。这个时代的真正叙事,是谁能在「AI 精神病」中不自伤。
18.
Using HTTP/2 Cleartext for a server in Go 1.24
Go 1.24 中为服务器启用 HTTP/2 明文传输 (h2c)
82 分
8 条评论
作者: dan_sbl
作者团队在 Google Cloud Run 上运行长连接 SSE(服务器推送事件)流,超时设为 15 分钟。但 Cloud Run 在使用 HTTP/1.1 时存在已知问题:客户端断开不会传递到后端服务,因此他们转向 HTTP/2 明文传输(h2c)。Cloud Run 在前端终止 TLS,可将流量以 HTTP/1.1 或 h2c 转发给后端,对应 RFC 9113 中的「HTTP/2 with Prior Knowledge」模式。文章对比了 Go 1.24 前后的配置方式:旧版需引入 「golang.org/x/net/http2」 和 「h2c.NewHandler」 包装 handler,再用 「http2.ConfigureServer」 配置;Go 1.24 后无需额外包,直接在 「http.Server.Protocols」 上调用 「SetHTTP1」 和 「SetUnencryptedHTTP2」 即可,可读性大幅提升。本地可用 「curl --http2-prior-knowledge」 验证。文末给出 Terraform 配置 Cloud Run 的代码片段,将容器端口命名为 「h2c」,并把超时调到 900 秒以容纳长连接 SSE。
19.
Building Pi with Pi
用 Pi 构建 Pi:AI 智能体时代的开源维护困境
76 分
40 条评论
作者: mplanchard
作者反思在 Earendil 项目「Pi」中用智能体(戏称「clanker」)开发自身的体验。issue 描述如今不只是用户与维护者的沟通,还会被当作 prompt 输入给智能体,因此 issue 质量直接影响修复效果。最棘手的是「5% 人类 + 95% 机器生成」的劣质 issue:包含听起来合理但其实错误的诊断、伪造的最小复现和虚假根因。即便用自定义命令 /is 提示「不要相信 issue 中的分析」,智能体仍倾向把 issue 当证据而非传闻。作者呼吁提交者只描述自己实际观察到的事实,把 LLM 分析放评论里。代码层面,LLM 倾向在局部加宽容性处理,而正确做法是「让坏状态不可能出现」,维护全局不变量。90 天数据:3145 个外部 issue/PR 中 2504 个被自动关闭,PR 合并率不足 10%。作者认为责任不在 GitHub,而在滥用智能体污染他人 tracker 的人。
20.
Mastering Dyalog APL
精通 Dyalog APL:在线交互版教材
142 分
36 条评论
作者: tosh
「Mastering Dyalog APL」是学习 Dyalog APL 的事实标准教材,但 2009 年由 Bernard Legrand 撰写的初版随着语言演进逐渐过时。为此,Rodrigo Girão Serrão 基于 Jupyter Notebook 重写了一版现代化教材,提供更具交互性的学习体验,同时保留了静态在线版和未来的纸质版。新版本在尽量保留原书行文与示例的基础上,更新了过时内容,并新增章节涵盖 Dyalog APL 12.0 之后引入的特性。该在线版仍在持续完善中,存在缺失章节,作者邀请读者通过 GitHub issue 或邮件反馈错误与建议。项目对原书贡献者及 Adám Brudzewsky 等社区成员表达了致谢。
21.
Greg Brockman interview [video]
Greg Brockman 访谈:OpenAI 内幕与 AGI 之路
196 分
206 条评论
作者: prakashqwerty
OpenAI 联合创始人兼总裁 Greg Brockman 接受 Knowledge Project 播客采访,回顾了 OpenAI 创立至今的关键节点。他详述了最初 Napa 闭门会议产出的「三步技术路线」:解决强化学习、解决无监督学习、逐步攻克更复杂任务,这一计划指导了 OpenAI 十年发展。他还解释了为何必须放弃纯非营利结构。访谈重点还原了 Sam Altman 被董事会解雇后的 72 小时:接到电话时的处境、当天辞职的原因、次日在 Sam 家设计「Phoenix」备份公司方案,以及 Ilya Sutskever 那条关键推文如何扭转局势。话题随后转向当下:全球 AI 竞赛格局、OpenAI 内部代码已有相当比例由 AI 编写(「很难说哪部分不是」)、为何停止展示推理过程、算力受限世界中谁能获得 AGI,以及对就业冲击的回应。
22.
Scammers are abusing an internal Microsoft account to send spam links
诈骗者滥用微软内部账号发送垃圾邮件链接
283 分
155 条评论
作者: spike021
数月以来,诈骗者一直在利用微软的一个漏洞,从微软内部邮箱「msonlineservicesteam@microsoftonline.com」发送垃圾邮件。该邮箱本是微软用于发送账户告警、双因素验证码等正式通知的官方地址,被滥用后让钓鱼邮件极具迷惑性,可绕过反欺骗保护机制。攻击者似乎能通过注册新微软账号获取该地址的发送权限,邮件主题模仿欺诈交易告警或私信通知,诱导用户点击诈骗链接。反垃圾邮件组织 Spamhaus 表示该问题已持续数月,并批评「自动化通知系统不应允许如此程度的自定义」,已通报微软。微软在 TechCrunch 询问后回应称正在调查并强化检测拦截机制、移除违规账号。文章指出,类似事件并非孤例:2023 年 Namecheap 邮箱被滥用、年初 Betterment 平台被入侵发虚假加密货币通知,社交媒体上也有用户反映其他公司邮箱遭遇相同问题,显示这是行业性漏洞。
23.
Noroboto: Lying Fonts and Mitigation in Rust
Noroboto:用「撒谎的字体」欺骗 AI 阅读合同
74 分
31 条评论
作者: piker
作者展示了一种针对法律 AI 的攻击手法「lexploit」:利用 Word/PDF 允许文档内嵌字体的特性,构造恶意 TrueType 字体「noroboto.ttf」,让字形外观与原字体一致,但 cmap 把字符映射到 Unicode「私用区」(PUA) 或其他无关码点。人眼看到的是「Maryland」,复制出来或被 LLM 读取的却是乱码或「Delaware」。完全混淆易被 ChatGPT 5.5 通过单字母替换密码分析或 OCR 破解,作者于是引入 4 对 1 随机映射、多 PUA 轮换形成「多表替换」。更危险的是「部分混淆」和「替换攻击」:因 Agent 倾向走表面合法的 Unicode 快路径而懒得 OCR,所有被测平台都被「Maryland 变 Delaware」骗过。作者用 Rust 实现了缓解方案:渲染 ASCII 字形并 OCR,与声称的 Unicode 比对 Levenshtein 距离来计算「字形可信度」,未通过则告警。
24.
Gorilla: A fast, scalable, in-memory time series database (2016)
Gorilla:Facebook 的高速可扩展内存时序数据库(2016)
7 分
1 条评论
作者: xnorswap
本文解读 Facebook 2015 年发表的 Gorilla 论文。Gorilla 是一个内存时序数据库,承担监控数据的写穿缓存角色,最终数据落到 HBase。截至 2015 年春,Facebook 监控系统每秒新增约 1200 万数据点,每天超 1 万亿,要求存储 20 亿条独立时序、保留 26 小时、读延迟低于 1 毫秒、峰值 4 万 QPS。为把海量数据塞进内存,Gorilla 设计了专门的压缩算法,平均压缩比 12 倍。时间戳采用「delta-of-delta」编码:以 2 小时为块,对相邻间隔的差值用变长位编码,约 96% 的时间戳可压到 1 位。数值则利用相邻值变化小的特性,用当前值与上一个值的 XOR 结果,再记录前导零和有效位长度,约 51% 的数值能压到 1 位。架构上按 key 分片、无共享、横向扩展,启动时 1.3TB 内存分布在 20 台机器,后扩到 80 台。持久化用 GlusterFS 三副本。Gorilla 显著加速了 Facebook 的故障定位与根因分析。
25.
Childhood Computing
童年的计算机记忆
197 分
94 条评论
作者: blenderob
作者回忆 1992 年八岁时在印度小镇学校的计算机房经历。机房里是硅厂淘汰下来的 IBM PC 兼容机,单色 CRT 显示器,没有硬盘,只有几百 KB 内存,每月仅有两小时上机时间。进机房前要脱鞋,先用 5¼ 英寸软盘加载 MS-DOS,再加载 LOGO.COM 写小程序看海龟移动。由于没有存储设备,关机即丢失,「保存」意味着把代码抄进笔记本。作者大部分 Logo 编程是在家用纸笔完成,在坐标纸上「测试」程序。他写的一个画动态虚线房子的程序被同学手抄传播,成了他人生第一个「自由开源软件」。文章还提到 Moon Bugs、Digger、Grand Prix Circuit 等游戏带来的震撼,以及他在 2022 年终于实现儿时梦想写出 Andromeda Invaders。机房里电脑的嗡嗡声、POST 自检的哔声、空调房特有的气味,至今仍是他最鲜活的记忆。
26.
Perceptual Image Codec: What Matters in Practical Learned Image Compression
PICO 感知图像编解码器:实用学习型图像压缩的关键要素
110 分
34 条评论
作者: ksec
苹果机器学习团队发布 PICO(Perceptual Image Codec),号称首个兼具实用性、并直接针对人类视觉系统优化的学习型编解码器。团队对实用学习型编解码器的建模选择进行了系统研究,在数百万种模型配置上联合优化感知质量与端侧运行时性能。基于大规模主观用户研究,PICO 相比 AV1、AV2、VC、ECM 与 JPEG-AI 实现 2.3 至 3 倍码率节省,相比最佳学习型编解码器节省 20% 至 40% 码率。在 iPhone 17 Pro Max 上,编码 1200 万像素图像最快 230 毫秒,解码 150 毫秒,比大多数顶级 ML 编解码器在 V100 GPU 上更快。与多数学习型编解码器不同,PICO 还提供跨平台鲁棒性保证。论文以 arXiv 预印本形式发布,作者来自苹果团队。
27.
Getting an old Computer online with Android Ethernet tethering
用安卓以太网共享让老电脑上网
57 分
21 条评论
作者: speckx
作者怀念 Windows 9x/XP 时代的老电脑,但这些机器要么没有 Wi-Fi,要么只支持 WEP 加密,无法连接现代 WPA 网络。在没有以太网口可用的环境里,他给出一个出乎意料简单的方案:买一根便宜的 USB-C 转以太网适配器接到安卓手机上,再用网线连到老电脑的以太网口,然后在手机设置里开启「以太网共享」(Ethernet Tethering)。只要老电脑启用了 DHCP 自动获取 IP,手机就会自动分配地址并把 Wi-Fi 桥接到有线口,理论上对任何带网口的新老电脑都通用。作者也试过带网口的 USB-C 扩展坞,效果一样,只是需要额外供电。他没有 iPhone,不确定 iOS 是否支持类似功能,并自嘲这么简单的办法自己居然拖了这么久才想到。
28.
Why is Vivado 2026.1 dropping Linux support for free tier?
Vivado 2026.1 为何取消免费版的 Linux 支持
316 分
196 条评论
作者: zdw
AMD(原 Xilinx)在 Vivado 2026.1 版本中宣布免费基础版(Standard/Free 版)将不再支持 Linux,仅保留 Windows 平台,付费高阶版本仍保留 Linux 支持。该决定在官方支持论坛引发强烈反弹:用户质疑此举针对的是学生、爱好者、教育用户和开源 FPGA 工具链生态,而这些群体恰恰是 Xilinx 长期以来相对 Altera/Intel 取得社区优势的关键。学术界与 CI/CD 工作流高度依赖 Linux,Windows 无法提供同等的交叉编译与脚本化能力。官方回复被批评回避核心问题、态度傲慢,仅强调「不可接受的辱骂行为」却不解释为何砍掉 Linux 免费支持。许多人推测这是为了迫使付费用户购买更高阶 license,或削减维护成本,但代价是把下一代工程师推向 Lattice、Altera Quartus Lite,乃至中国 FPGA 厂商和 OSS CAD Suite 等开源工具链。
29.
I keep bouncing off the Scheme language
我总是学不会 Scheme 语言
148 分
71 条评论
作者: ingve
作者公开承认自己虽然深爱 Scheme,甚至以 SICP 教材为博客命名,却始终无法真正掌握它。他能读懂 Scheme 代码,借助 LLM 也能在 Racket 里搭出类 Smalltalk 的实时环境,但落到自己动手写时就卡壳。问题在于他长期被「ALGOL 神经类型」塑造,习惯按指令序列和内存位置思考,几十年的 Java、Smalltalk-80 等 Simula 系 OP 经验进一步固化了这种思路。最近两个 Web 项目(包括 SICPers 播客的书单 SE100),他都考虑过用 GNU Artanis,最终却退回到 Go。他欣赏 Guix、Shepherd 这类 Scheme 软件的优雅与威力,也想为生态做贡献,但必须先迈过「已经熟练掌握更复杂的另一种方式」这道坎,愿意以初级开发者姿态重新学习。这篇文章是他给自己立的 flag,逼自己再试一次。
30.
Time to talk about my writerdeck
聊聊我的「写作终端」改造
479 分
284 条评论
作者: hggh
作者将一台六年旧的 System76 Galago Pro 笔记本改造成专用写作设备「writerdeck」,目的是摆脱现代互联网的注意力干扰。她选择 Debian Trixie 的纯 tty 命令行环境,不安装 X11 或 Wayland,从根源上斩断打开浏览器的肌肉记忆。具体配置包括:用 nm-tui 管理网络以便偶尔备份,装 kmscon 让 tty 支持 Ctrl+加减号缩放字体,用 neovim 写作,tmux 做分屏并自定义状态栏,通过 acpi 显示电池电量、light 命令绑定 F8/F9 调节屏幕亮度,最终用 vimwiki 组织笔记。她强调重点是「用现有设备开始写」而非折腾完美方案,硬盘加密都省了因为内容本就要公开。文章本质是一份可复制的极简写作环境搭建指南,也是对「单一用途设备」理念的实践。
💬 评论精华