2026年08月02日 · 星期日 第 160107 期

The Hacker Daily

丙午年(马)六月二十

30 篇文章 · 1209 条评论 ·聚焦:AI模型 · Linux移植 · 开放网络
No.01 Go 1.27 Interactive Tour
Go 1.27 交互式功能巡览
177 分 51 条评论 作者: Hixon10
文章用可运行示例解读 Go 1.27 的主要变化:泛型方法成为头条特性,结构体字面量可直接设置提升字段,泛型函数在更多上下文中自动推断类型;运行时增加小对象分配优化、带 pprof 标签的 traceback 和正式的 goroutineleak 泄漏 profile。标准库也扩展到后量子签名 ML-DSA、UUID、TLS 和 x509 支持等。整体价值在于把枯燥 release notes 转成动手教程;争议集中在泛型方法是否增加 Go 的认知负担,以及一些运行时和 net/http 行为变更是否过于隐蔽。

评论精华

  • 不少人担心泛型方法让 Go 语法变重,削弱原本简洁性。
  • 也有开发者欢迎泛型方法,认为它补齐了表达能力并吸引新用户。
  • Go 团队旧成员解释,泛型并非立场突变,而是长期设计后才落地。
  • 有人提醒自动 drain HTTP response body 是微妙的静默行为变更。
  • 评论补充了 Android MTE 修复、SIMD 标准库化等正文未突出细节。
No.02 Show HN: I'm a 15 Year Old Wannabe Engineer, This Is a Cycloidal Gearbox I Built
展示:15 岁工程爱好者自制摆线针轮减速箱
119 分 22 条评论 作者: tomilan
这篇 Show HN 展示了一名 15 岁作者自制的「摆线针轮减速箱」项目,代码和设计资料托管在 GitHub。评论区普遍认为作者不只是「想当工程师」,而是已经通过动手实践成为工程师。讨论中有人解释其功能:通过牺牲转速换取更高扭矩,特点是低背隙、多点接触和较高效率,常见于机器人执行器等场景。也有人邀请作者加入 Hack Club,鼓励其继续做硬件项目;少数评论提醒不要公开年龄,并建议不要过度依赖 AI,尝试独立完成更多作品。

评论精华

  • 社区普遍鼓励作者:动手做出东西就是工程师。
  • 摆线减速箱被解释为低背隙、高扭矩的传动结构。
  • 有人指出这类机构常用于机器人执行器。
  • Hack Club 成员邀请作者加入青少年创客社区。
  • 少数人提醒未成年人别公开年龄,也别过度依赖 AI。
No.03 Seedance 2.5
字节发布 Seedance 2.5 视频生成模型
310 分 159 条评论 作者: njaremko
字节正式推出新一代视频创作模型 Seedance 2.5,重点从生成短片转向完成更完整的创作。它支持单次生成最长 30 秒音视频,并可多轮续写,强调长叙事中的角色、场景、节奏和音画一致性;同时可一次输入最多 30 张图、10 段视频和 10 段音频作为多模态参考,增强运动、风格、创意和复杂场景控制。模型还提供时间戳级音视频编辑,改进绿幕、机位和参考编辑,面向影视、广告等专业场景。社区普遍认为样片质量显著提升、接近可商用,但仍有人指出动作、情绪和剪辑仍有明显 AI 痕迹,并担忧深伪、垃圾内容和成本问题。

评论精华

  • 许多评论认为画质和长镜头一致性惊人,已接近可商用广告水准。
  • 不少人仍能看出 AI 痕迹:动作不自然、情绪平、剪辑像样片拼盘。
  • 价格与入口引发讨论,有人称 30 秒生成成本约 7 到 15 美元。
  • 伦理分歧明显:有人担心深伪和垃圾内容,也有人认为它能放大个人表达。
  • 创作者视角分裂:一派期待独立完成影视构想,另一派担心缺乏细粒度控制和创作灵魂。
No.04 MkLinux and the pimped-out Apple Workgroup Server 9150
MkLinux 与升级版 Apple Workgroup Server 9150
45 分 2 条评论 作者: goldenskye
文章以修复一台塑料老化的 Apple Workgroup Server 9150 为引子,回顾苹果从 1980 年代「Macintosh Office」到 1990 年代服务器产品线的曲折演进。作者指出,苹果并无大型机传统,服务器战略源自共享打印、文件服务和企业办公需求;「Big Mac」项目虽因乔布斯离职和内部政治夭折,却把 Unix 工作站、文件服务器和高端 Mac 的设想延续到 Macintosh II、AppleShare 与 A/UX。A/UX 让 Mac 进入政府、教育和高端工作站市场,后来又与 PowerPC、AIX、Workgroup Server 以及 MkLinux 的路线交织,展现苹果在经典 Mac OS 与 Unix 之间反复寻找企业定位的历史。

评论精华

  • 有用户回忆 1996 年用 PowerMac 8100/80 跑 MkLinux,早期多键鼠标支持不足影响 X11 使用。
  • 另一位用户提到 Power Mac 启动音效并非传统 Mac「bong」,并怀念 7100 的同款声音。
No.05 Diátaxis
Diátaxis:技术文档写作的四分法
310 分 39 条评论 作者: ryanseys
Diátaxis 是一种技术文档写作与组织框架,主张从用户需求出发,把文档分为「教程」「操作指南」「技术参考」「解释」四类,并据此决定内容、风格和信息架构。文章强调它轻量、易理解、不绑定实现方式,已被 Gatsby、Cloudflare 等项目用于重构开发者文档。评论总体认可其能降低文档混乱、帮助团队交接和 AI 生成初稿,但也提醒不要把框架当教条,实际导航、API 文档入口和内容维护成本仍需按用户场景调整。

评论精华

  • 作者称正在推进 Diátaxis 多语言翻译,并澄清早期 Divio 版本有不足。
  • 多位实践者表示用它重构文档、交接代码库后,内容更清晰易找。
  • 有人调侃读完后会发现所有文档都混乱,也有人称它不应被教条化。
  • 社区讨论了「教程」与「操作指南」的区别:前者偏学习路径,后者偏完成具体任务。
  • 一些评论关注实际可用性:API 文档入口不要被「参考」层级挡住。
No.06 Elena, a library for building Progressive Web Components
Elena:用于构建渐进式 Web Components 的轻量库
24 分 1 条评论 作者: brianzelip
Elena 是一个面向设计系统和跨框架组件库的轻量 Web Components 库,强调「渐进式增强」:先让 HTML 与 CSS 完成渲染,再用 JavaScript 增加交互,避免过度依赖客户端脚本。它基于原生 Custom Elements 和 Web 标准,提供属性同步、事件委托、响应式更新、作用域样式、SSR 友好等能力,体积约 2.9kB 且零依赖。作者称其源于多年企业级设计系统实践,试图解决可访问性、布局抖动、不可见内容闪烁、SSR 与多框架兼容等常见痛点。文章主要是项目介绍,社区讨论很少,尚未形成实质争议。

评论精华

  • 唯一评论提供了一个相关 HN 讨论链接,未展开技术评价。
No.07 Running Kimi K3 on MI355X at Better Performance per Dollar Than B300
MI355X 运行 Kimi K3:性价比胜过 B300?
110 分 18 条评论 作者: ilreb
Wafer.ai 称,2.8T 参数的 Kimi K3 需要超大显存,AMD MI355X 因单卡 288GB HBM 且价格低于 B300/B200,在部署该模型时获得明显性能价格优势。其 8 卡节点在 1024 输入、400 输出基准下达 952 tok/s,单流 118 tok/s;虽总吞吐低于 B300,但按 GPU 小时价格计算更划算。文章还介绍了修复 ROCm speculative decode 中缺失 top-k renorm、用 12→16 头零填充启用 AITER MLA prefill kernel 等优化,使解码和首 token 延迟显著改善。评论区主要质疑其「开源模型」表述、价格对比公平性和文章质量。

评论精华

  • 多人认为应称「开放权重」而非「开源模型」。
  • 有评论质疑价格采用不公平口径,缺少真实 TCO 对比。
  • 多名读者批评文章写作像 AI 生成,细节粗糙。
  • 有人指出 MI355X 与 B300 吞吐对比并未充分解释配置差异。
  • 也有讨论认为模型权重是否属于可修改源码存在争议。
No.08 ASRock BC-250: Building the Budget Steam Machine
用 ASRock BC-250 打造低成本 Steam 游戏主机
52 分 14 条评论 作者: plug_world
文章应是在介绍如何把 ASRock BC-250 这类由矿卡/集成板卡转用而来的硬件,改造成一台预算友好的 Steam 游戏主机。评论显示,作者关注 Linux/SteamOS 体验、显卡驱动与着色器缓存等细节,并可能提到类似「MESA_SHADER_CACHE_MAX_SIZE」的环境变量配置。社区反馈整体偏正面,认为这张卡在更新驱动和社区折腾下越来越可用,适合替代老旧 RX580 或 Steam Deck 等设备;同时也有人补充近期已有部分 CPU 核心可解锁,从原本启用 6 核扩展到 8 核中的 2 个额外核心。争议不多,主要是文章拼写错误「MESSA」引发调侃,反而被认为不像 LLM 生成。

评论精华

  • 有人指出文章把「MESA」误写成「MESSA」。
  • 用户认为 BC-250 性价比高,体验还在持续改善。
  • 有人用它替代老旧 RX580 或故障 Steam Deck。
  • 评论补充:近期可解锁 8 个 CPU 核心中的 2 个。
  • 拼写错误被调侃为文章不像 LLM 写的。
No.09 Australia's social media ban has failed
澳大利亚青少年社交媒体禁令成效受质疑
14 分 14 条评论 作者: BlueBerry2001
路透报道称,澳大利亚为限制青少年使用社交媒体而推出的禁令遭遇执行难题:研究显示,大多数目标年龄段青少年仍在线,政府则为政策辩护,强调实施时间尚短,不能过早宣判失败。评论区争议集中在禁令是否现实:支持者认为家长迫切希望减少未成年人沉迷,尤其应阻止更小孩子过早进入平台;反对者则认为,越禁止越会激发青少年绕过规则,且把社交互动整体隔离并不能解决霸凌、成瘾和平台责任等根源问题。也有人指出,若平台有动机放任规避,罚则就应按违规用户计罚。

评论精华

  • 许多人认为青少年天然会绕过父母和政府禁令。
  • 有人主张政策刚实施数月,不能仅看15岁群体就判失败。
  • 反对者认为禁止社交互动并不能解决霸凌和有害行为。
  • 有评论认为平台缺乏执行动力,罚款应按违规用户计算。
  • 家长群体被描述为迫切希望禁令成功,但执行机制仍不清楚。
No.10 Unraveling the mysteries of habit formation
习惯如何形成:京都大学解析大脑中的两条控制回路
71 分 24 条评论 作者: hhs
京都大学团队为小鼠设计了两阶段快速训练法,直接追踪从「目标导向」到「习惯化」的转变。研究发现,习惯并非只是重复原动作后自动固化,而由两条前额叶相关神经通路分工控制:前扣带皮层到压后皮层的连接决定行为是否成为习惯,并在转变中减弱;外侧眶额皮层到中央纹状体的通路则决定习惯执行强度,解释个体差异。通过人工操纵这些通路,研究者能分别影响习惯形成和执行水平。评论争议集中在小鼠实验能否外推到人类,以及习惯、成瘾、积极心态之间的边界。

评论精华

  • 有人认为标题应强制标注「小鼠实验」,避免过度外推到人类。
  • 多位评论者讨论习惯一旦中断就很难恢复,认为论文或可解释这种体验。
  • 有人区分习惯与成瘾,认为海洛因等不应简单归为习惯。
  • 评论提醒积极心态有价值,但过度强调可能滑向「毒性积极」。
  • 有人从论文解读出,建立例行机制和维持执行强度可能需要分别训练。
No.11 Deep-sea vehicles spot 'alien' sharks deep beneath the waves in the Pacific
太平洋深海探测器拍到外形奇特的深海鲨
43 分 16 条评论 作者: pkaeding
文章报道深海探测器在太平洋海底观察到外形奇特、被形容为「外星」般的鲨类,显示深海仍有大量未被科学记录的物种,许多体型较小、生态习性所知甚少。评论区由此延伸到深海探索的矛盾:人类常在拖网、采矿等破坏性活动中首次接触这些生物,而锰结核开采可能在物种被描述前就清扫其栖息地。也有人担心探测器强光会影响适应黑暗的动物。讨论还偏题到英文动词「glid」是否合规,反映原文措辞引发的语言争议。

评论精华

  • 深海鲨类未知种很多,且常见于拖网调查中。
  • 有人担心探测器灯光会刺激或致盲深海动物。
  • 评论指出深海探索常伴随拖网、采矿等栖息地破坏。
  • 锰结核开采被视为可能导致未命名物种灭绝的风险。
  • 部分讨论转向「glid」与「glided」的英语用法争议。
No.12 RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2
RFC 10015:在 TLS 1.2 和 DTLS 1.2 中弃用过时密钥交换
55 分 12 条评论 作者: Jimmc414
RFC 10015 正式在「TLS 1.2」与「DTLS 1.2」中弃用有限域 Diffie-Hellman 的静态与临时密钥交换,以及 RSA 密钥交换,并继续不鼓励静态 ECDH。原因包括缺乏前向保密、FFDHE 组协商缺失与小子群风险、1024 位组安全余量不足、Raccoon 与无效曲线等密钥复用侧信道,以及 RSA 长期反复出现的 Bleichenbacher 类攻击。该文只针对 1.2,因为 TLS 1.0/1.1 已废弃,TLS 1.3 不再沿用这些问题配置。评论中有人认为与其继续修补 TLS 1.2,不如直接将其标为遗留并推动 TLS 1.3。

评论精华

  • 有评论认为 TLS 1.3 支持成本不高,应直接把 TLS 1.2 标为遗留。
  • 有人补充 IETF Datatracker 链接比 RFC Editor 页面更适合阅读。
No.13 Postmortem for Kernel Soundness Bug #14576
Lean 内核可靠性漏洞事后复盘
143 分 52 条评论 作者: juhopitk
Lean 团队复盘了内核可靠性漏洞 #14576:一份由 AI 辅助生成、无需 sorry 的 Collatz 猜想「反证」其实利用了嵌套归纳类型参数处理中的实现缺陷,可让内核接受 False。漏洞仅能通过元编程或直接提交内核声明触发,前端会拦截,因此不是 Lean 元理论漏洞。独立检查器 nanoda 当时也被绕过,但原因是另一个已修复的投影节点检查漏洞,说明多内核交叉验证仍有价值,但必须保持更新。文章还反驳了限制元编程的建议,强调内核必须独立拒绝坏声明,并列出回归测试、参数检查强化、AI 安全审计和内核不变量加固等后续措施。

评论精华

  • 多位评论者强调问题不在 Collatz,而是验证器实现的可信边界。
  • 有人认为 AI 可能通过奖励黑客式路径寻找形式系统漏洞,而非真正证明数学结论。
  • 社区讨论独立内核交叉检查的价值:两个实现同时出错才会漏过,但版本必须及时更新。
  • 关于 Collatz,有人解释有限反例易查,但非构造性或无限上升形式并不易有限验证。
  • 评论区还争论证明系统的正确性、完备性与哥德尔不完备定理之间的关系。
No.14 When random.bytes() runs but doesn't work
random.bytes() 能运行却没有真正随机
29 分 10 条评论 作者: Funes-
文章从 COLDCARD 固件中引入低熵漏洞的提交历史入手,批评关键安全代码以「runs」「x」这类几乎无说明的提交合入。作者认为开发者在移植 MicroPython/STM32 随机数相关代码时,为绕过重复符号编译错误,将「MICROPY_HW_ENABLE_RNG」设为 0,意外关闭硬件随机数生成器,使「random.bytes(32)」落到弱的 Yasmarang 伪随机路径,影响新钱包种子生成。文章核心警示是:安全关键代码不能在不理解调用链和底层实现时靠试错让它「能跑」。评论中也有人指出,原文可能误解了具体编程错误,且尚未证明这是疏忽而非恶意。

评论精华

  • 有人质疑文章默认提交者非恶意,但这一点并未被证明。
  • nullc 认为原文技术分析不佳,误解了导致漏洞的编程错误。
  • 多名评论者认同 MicroPython 会掩盖嵌入式底层复杂性。
  • 有人认为这是安全关键代码中的严重失职,损失可能极高。
  • 讨论延伸到是否应使用 Rust、Lean 等更安全语言替代 C。
No.15 A big win for Android interoperability
欧盟要求 Google 开放 Android 助手互操作能力
25 分 3 条评论 作者: soheilpro
Open Home Foundation 介绍其参与欧盟《数字市场法》咨询后,欧委会要求 Alphabet 在 Android 18 起向第三方助手开放 11 项能力,包括常驻唤醒词检测、环境传感器访问、屏幕自动化和后台执行等。文章重点指出,Home Assistant 多年来无法使用 Android 为「Hey Google」保留的 DSP 低功耗唤醒机制,只能用 CPU 方案,导致耗电、隐私指示常亮且必须设为默认助手。新决定要求第三方获得与 Google 助手「同等有效」的接口、文档和测试工具,并禁止把访问绑定到默认助手角色;多助手并发唤醒最晚需在 Android 19 实现。作者认为这是隐私、选择权和智能家居开放生态的胜利,但也警惕 Google 可能以安全理由或「恶意合规」削弱实际效果。

评论精华

  • 评论者希望欧盟也强制 Google 重新开放应用安装自由。
No.16 AI financial advice is surprisingly good, especially if you ask right questions
AI 理财建议意外靠谱,但提问方式很关键
289 分 255 条评论 作者: foxtrot8672
MIT Sloan 研究用 1000 名成人自写提示词测试 GPT-5.2、GPT-5.6 和 Gemini 3 Flash,并在生命周期模型中模拟 22 至 89 岁长期跟随建议的结果。LLM 通常会建议工作期储蓄、退休后动用储蓄、投资多元化股票基金并随年龄降风险,整体优于许多人的现状,尤其在结构化、信息充分的「学术式提示」下更好。但模型对失业等冲击、主动再平衡和个体细节处理不足;不同性别、金融素养和 AI 使用经验的提问方式还会导致退休财富差距。文章认为 AI 可降低理财建议门槛,但不应盲从,最好先用它提升金融理解,并作为人类顾问的补充。

评论精华

  • 许多人认为 AI 给出的只是常识性理财原则,但常识对金融文盲已很有价值。
  • 多位评论者强调真正难点是提出好问题;专家式提示本身就是门槛。
  • 有人担心未来金融与广告行业会污染 AI 建议,引入利益冲突和推销。
  • 实际用户反馈称,给 AI 足够账户、预算和投资数据后,建议比泛泛回答有用得多。
  • 金融从业者指出理财不只是技术优化,还涉及行为、情绪、税务和责任边界。
No.17 Four Time Scales for Technology Development and Deployment
技术发展与部署的四种时间尺度
26 分 4 条评论 作者: jeffreyrogers
Rodney Brooks 区分了技术从诞生到改变经济的四个时间尺度:新研究想法往往需 10 到 20 年甚至更久才形成可靠实验室成果,神经网络到大模型用了约 60 年;炒作周期却可在数月内爆发并迅速转移,如区块链、元宇宙、AI 智能体;真正的大规模部署即便是软件也常需 20 年以上,硬件系统更慢,Waymo 和自动驾驶说明从演示到规模化运营差距巨大;而重塑经济通常要 50 年以上连续部署。作者批评市场和媒体混淆研究、炒作、产品化与经济改造,低估供应链、客户支持和组织变革的难度。

评论精华

  • 有人联想到 NASA 的技术成熟度等级,用于衡量从概念到部署的阶段。
  • 评论列举资本主义、探索时代、电力、石油、计算机等技术或制度改变世界所需的长周期。
  • 有评论认为 AI 目前主要部署在文本与代码生产,尚未广泛进入组织决策。
  • 社区总体认同作者对「几年内重塑经济」式预测的怀疑。
No.18 But can your calculator run Linux?
计算器也能跑 Linux?
91 分 9 条评论 作者: jandeboevrie
作者围绕 HP Prime G2 图形计算器展示了一次把 Linux 移植到计算器上的折腾。Prime G2 配备 i.MX6 Ultralite、256MB 内存和 512MB 存储,规格更像小型嵌入式 Linux 设备,而非传统计算器。作者比较了 TI、Numworks、Casio、HP 16C 等机型,指出多数计算器因硬件或锁定策略不适合运行 Linux。他基于旧的 4.14 内核移植重新修复仓库、设备树和构建问题,改进键盘输入、USB 串口、触屏驱动、控制台登录、X11、Doom 与本机 C 编译器。文章也延续了作者对设备所有权和 root 权限的立场:买来的设备应允许用户真正掌控。

评论精华

  • Prime G2 用户称其日常好用,偏爱 RPN、Python/PPL 编程和背光屏。
  • 有人借用「烤面包机也能跑系统」的老梗,调侃计算器跑 Linux 并不意外。
  • 评论怀念 HP48、HP50g 等老 HP 计算器的工程质量和在校园中的地位。
  • 有人指出原梗语义被反了:不是 BSD 跑在烤面包机上,而是烤面包机跑 BSD。
  • HP 48-50 系列的单位计算功能仍被认为非常强,甚至优于手机替代方案。
No.19 Morph (YC S23) Is Hiring Member of Technical Staff
Morph 招聘推理基础设施技术成员
1 分 0 条评论 作者: bhaktatejas922
Morph 是 YC S23 公司,正在招聘 Member of Technical Staff,重点寻找精通推理栈多个环节的顶尖性能工程师。岗位将参与「PD disaggregation」研究,并优化支撑最快开源模型的推理基础设施,覆盖内核、模型服务、路由、自动扩缩容和算力容量管理。公司强调小团队、巨大算力资源和直接生产影响,技术方向包括面向内核的自动研究、定制推测解码模型,以及专用代码生成模型的服务系统。招聘流程包含 2 天工作试用。
No.20 Atom is better than RSS, in ways that matter
Atom 在关键问题上优于 RSS
58 分 24 条评论 作者: frizlab
作者认为,虽然许多 RSS 与 Atom 的差异在现实中影响不大,但仍有几个会破坏互操作性的关键问题。RSS 对标题和内容的编码语义含混,像「<」和「&」或标题中的 HTML 标记无法可靠表达;Atom 则用明确的 text、html、xhtml 类型解决歧义。Atom 也更清楚地区分摘要与全文。作者主张发布者应优先使用 Atom,因为主流阅读器普遍支持,技术上更健全;但播客生态被 Apple 等早期平台锁在 RSS 上,导致现实中 RSS 仍难被淘汰。

评论精华

  • 有人概括为:Atom 主要赢在标题转义和摘要/全文区分,但播客仍要 RSS。
  • 多位评论者认为发布内容应选 Atom,阅读器基本都支持,缺点很少。
  • 也有人说普通用户几乎无感,RSS 已成为通用名称,Atom 常被当成 RSS。
  • 关于 Postgres 存储 feed,有人建议解析后存相关字段,而非只存原始 XML。
  • 评论将 Atom/RSS 类比为 Betamax/VHS,并引出「worse is better」的技术史争论。
No.21 How Google helped destroy adoption of RSS feeds (2023)
Google 如何削弱 RSS 的普及
507 分 174 条评论 作者: pudgywalsh
文章认为,RSS 仍是开放网络的重要基础设施,但 Google 多次先借助 RSS 扩张产品,再在用户形成依赖后移除支持,削弱了公众对 RSS 的信心。作者列举 Chrome 早期移除订阅按钮、收购 FeedBurner 后关闭 API 与核心功能、2013 年关闭 Google Reader、Google Alerts 与 Google News 取消或弱化 RSS、Chrome 扩展被下架等事件,称其模式近似「拥抱、扩展、消灭」。争议在于,一些评论认为 Google 的确助推了 RSS 衰落,另一些人则认为 RSS 本身过于小众、难商业化,不能完全归咎于 Google。

评论精华

  • 许多人怀念 Google Reader,认为其关闭是开放 Web 衰落的标志。
  • 反方认为 RSS 太小众、难营销,主流用户本就更倾向社交平台。
  • 不少人指出 RSS 仍活跃,博客、WordPress、播客和 YouTube 仍有 feed。
  • 评论讨论广告与变现:RSS 弱化平台控制,因而不受大公司欢迎。
  • 有人提到邮件 newsletter、Substack 等替代路径,部分继承了 RSS 的需求。
No.22 The Cipher Behind QSYRUPWD: Reconstructing IBM i Password Hashes
破解 QSYRUPWD 背后的 IBM i 密码哈希机制
8 分 5 条评论 作者: kencausey
文章分析 IBM i 的「QSYRUPWD」接口在不同「QPWDLVL」下返回的加密密码数据。作者在渗透测试中发现,等级 2–4 的输出无法直接用于 John the Ripper 现有 IBM i 格式,导致即使具备高权限也难以做密码强度测试。随后作者编写 CL 程序调用接口、用「STRTRC」追踪调用链,并通过 SST 反汇编相关服务程序,重点定位到通用加密、AES 解密和隐藏数据还原函数,试图重建其内部密码验证材料格式。文章价值在于补足 IBM 未公开说明的实现细节,也提示旧兼容验证器与现代哈希方案在审计工具上的断层。

评论精华

  • 有人指责该链接是从 Lobsters 用户处搬运而来
  • 回应认为不能断定 HN 发布者不是独立发现
  • 另有评论认为发布者很可能知道来源
No.23 We accidentally built an LLVM compiler for Jax
意外为 JAX 构建了 LLVM 编译器
39 分 12 条评论 作者: infinitewalk
作者团队在为 PennyLane 的量子编译器 Catalyst 构建混合量子-经典工作流时,选择用 JAX 捕获 Python/NumPy 计算图,再经 MLIR 接入 LLVM 与 Enzyme 做优化和反向传播。结果发现,即使不含量子指令,Catalyst 的 @qjit 也能编译纯 JAX 代码:绕过 XLA/PJRT 运行时,把 StableHLO 降到通用 MLIR 方言,再生成独立机器码。作者强调这不会取代 XLA 的深度学习 GPU/TPU 优化,但可能适合 AOT 独立二进制、动态形状数组、原生 Python 控制流、边缘和裸机部署等场景。评论区主要围绕 XLA 与 MLIR 的历史和现状争论。

评论精华

  • 有人指出 XLA 早于 MLIR,背后有不少历史故事。
  • 评论纠正称 XLA 近年已大量迁移到 MLIR,不能说不使用。
  • 有读者用实验探针验证项目,认为潜在用途值得深入消化。
  • 有人拿矩阵乘法重写测试比较 XLA 优化能力。
  • 讨论提到 MLIR 采用过程曾受组织和领导因素影响。
No.24 Nyctography: A substituton cypher by Lewis Carroll
刘易斯·卡罗尔的夜书术:黑暗中书写的替换密码
72 分 10 条评论 作者: nanna
文章介绍刘易斯·卡罗尔在 1891 年发明的「夜书术」和配套「夜书板」:一张带 16 个方孔的格卡,配合由点和边线组成的方形字母表,让人在夜间无需点灯也能记录突然醒来时的想法。每个字符左上角都有定位黑点,26 个字母外还包含表示「and」「the」、数字、字母和日期的特殊符号。卡罗尔最初称其为「盲写器」,后改名为「夜书器」,并认为这种低成本工具也可能帮助盲人记录思想。评论区主要把它视为一种替换文字系统,而非真正复杂的密码。

评论精华

  • 有人联想到童年学习《霍比特人》中的托尔金符文。
  • 一位评论者质疑其必要性,称普通手写在黑暗中也可辨认。
  • 有人提到它曾出现在 DEF CON 的 L05tboy 谜题挑战中。
  • 多名用户分享用韩文字母、Ultima 符文或 Morrowind 魔族文字写日记的经历。
No.25 Kenji/Serious Eats – 30-Min Pressure Cooker Pho Ga
Kenji 的 30 分钟压力锅鸡肉河粉
139 分 79 条评论 作者: stasomatic
这篇 Serious Eats 旧文介绍 Kenji López-Alt 用压力锅快速制作越南鸡肉河粉 Pho Ga:借高温高压在短时间内萃取鸡骨、香料和洋葱等风味,把传统需长时间熬煮的清汤压缩到约 30 分钟。评论普遍认可这是 Kenji 典型的「分层努力」食谱:牺牲少量慢炖融合感,换来家庭厨房可重复、周中也能做的高性价比版本。争议集中在鱼露用量是否过重、30 分钟是否低估升压泄压时间,以及老款 Serious Eats 压力锅食谱能否直接适配 Instant Pot。社区还延伸讨论了 pho 与 ramen 的口感差异、南北越河粉风格、压力锅在高海拔和快速高汤中的应用。

评论精华

  • 多人表示这道食谱已做了十多年,冬季常备,效果稳定。
  • 有评论认为压力锅省时,但成品最好静置后风味才更融合。
  • 鱼露用量引发争议:有人嫌过咸,也有人称每份一汤匙合理。
  • Instant Pot 升压泄压会拉长总时长,30 分钟可能偏乐观。
  • 讨论延伸到 pho、ramen、galbitang 及南北越河粉风格差异。
No.26 NetBSD 11.0
NetBSD 11.0 发布
269 分 118 条评论 作者: jaypatelani
NetBSD 项目发布 11.0,提供各架构安装说明、CD/DVD 分卷 ISO、USB 用 .img 镜像以及预配置 U-Boot 的 ARM 镜像。公告特别说明,本次发布仍存在公开安全相关问题:由于 AI 工具推动漏洞发现速度上升,项目选择透明披露而非继续无限延期;未合入的安全 pullup 将很快进入稳定分支,并计划在两个月内随 11.1 发布。社区关注点集中在 NetBSD 的可移植性、老硬件支持、RISC-V 首次进入正式发布、作为日常系统的可行性,以及 BSD 家族相对 Linux 的定位。

评论精华

  • 用户称赞 npf 防火墙增强、MICROVM 内核等新特性实用。
  • 多位评论者强调 NetBSD 的核心优势是可移植性和老硬件支持。
  • 有人赞赏项目透明披露未解决安全问题,也有人担心发布显得过于道歉。
  • 社区讨论 BSD 现状:OpenBSD 偏安全,FreeBSD 偏功能,NetBSD 偏小而可移植。
  • 日常桌面可用性、Wine、蓝牙、文件系统和硬件支持仍被反复追问。
No.27 P[drive failure]: how reliable is your NAS?
硬盘会坏:你的 NAS 到底有多可靠?
9 分 7 条评论 作者: nosolace
作者想构建能保存一生数据的个人 NAS,用四块 8TB 硬盘组成两组 btrfs RAID1,并把一组异地放在父亲家同步备份。文章围绕整盘失效与「潜在扇区错误」两类风险,结合 Backblaze 数据、论文和硬盘规格,估算这种架构在长期运行中的数据丢失概率。核心观点是:冗余、校验和文件系统、SMART 监控、及时替换、读后校验和定期 scrub 都能降低风险,但没有任何方案能保证「永久」。争议点在于作者用复杂概率模型分析仅四块盘的家庭场景,是否比直接遵循 3-2-1 备份原则更有实际价值。

评论精华

  • 有人认为 N=4 时做复杂概率计算意义有限,真实硬盘寿命差异很大。
  • 评论认为结论其实很普通:重要数据用镜像和 3-2-1 备份即可。
  • 也有人提醒,不重要的数据不必花钱做高冗余。
  • 有评论喜欢网站设计,但认为全小写、两端对齐的长文难读。
  • 有人指出该站风格很像 Tufte CSS。
No.28 Explorative modeling: Train on the best of K guesses
探索式建模:从 K 个猜测中训练最佳答案
98 分 25 条评论 作者: DSemba
文章提出「探索式建模」:生成模型每次训练不只给一个答案,而是采样 K 个候选,只对与真实数据最接近的那个反向传播。作者认为这能把损失最优解从多模态数据的平均值拉回真实数据分布,作为自回归、扩散等「分解生成」之外的第三条预训练轴。实验声称探索量越大,图像、视频、语言模型效果越好,样本、算力、参数效率均提升,并可实现训练和推理一致的端到端生成。但评论区普遍指出其思想与 winner-take-all、IWAE、Minibatch OT、GRPO、GAN 等既有方法相近,创新性表述可能过度。

评论精华

  • 多人认为方法有效且实现简单,若规模化成立会很重要。
  • 不少评论质疑新颖性,指出与 winner-take-all、IWAE、DDN 相近。
  • 有人批评作者对生成建模和「分解」概念的表述不严谨。
  • 评论将其与 GRPO、RLVR、Minibatch OT 对比,认为关系值得展开。
  • 有人指出文章几乎未讨论 GAN,是明显遗漏。
No.29 Glyphs 4 – the leading Mac font editor
Glyphs 4:Mac 上的专业字体编辑器
80 分 12 条评论 作者: microflash
Glyphs 4 是面向 Mac 的专业字体与图标设计工具,新版强调让字体制作更可视、更自动化。核心更新包括可变笔画的「pen points」、COLRv1 彩色字体与渐变支持、可视化字偶距分组、新侧边栏、描边端点控制、斜体生成滤镜、组件复用、脚本窗口、字体母版浏览、实时文本预览和「star nodes」曲线优化。它覆盖从贝塞尔编辑、多母版插值、变量字体、OpenType 特性、Python 扩展,到导出 OTF、TTF、WOFF、COLRv1、SVG、PNG、SFSymbols 等格式的完整流程。评论区主要围绕 Glyphs 是否在专业字体设计领域形成近乎垄断展开,有人称其几乎是行业标配,也有人指出 RoboFont、FontLab、FontForge 等仍有使用者,且不同生态与专业程度差异明显。

评论精华

  • 有人认为 Glyphs 在专业字体设计圈几乎占据统治地位。
  • 反对者指出不少字体工作室仍使用 RoboFont 或 FontLab。
  • FontForge 被提及为替代品,但更像业余和非 Mac 用户选择。
  • 评论将 Glyphs 的地位类比 Photoshop、Excel、Word 等曾经的市场主导者。
  • 有人认为 Adobe 通过收购削弱竞争,巩固其设计软件优势。
No.30 Linux on ESP32
在 ESP32-S31 上运行 Linux
114 分 38 条评论 作者: boveyking
该项目尝试把 Linux 移植到新近发布的 ESP32-S31 微控制器上。评论推断其重点在于利用 ESP32-S31 的内存映射和 MMU 相关能力、XIP 支持以及较旧的 Linux 6.12 分支,让内核在资源受限的 ESP 芯片上启动。社区一方面认为若能成立,对物联网设备会很有价值,也能给性能和可行性提供基线;另一方面质疑 README 中大量标注未测试或 WIP,怀疑项目明显依赖 AI 辅助开发,示例输出是否可靠。技术争议集中在无或非标准 MMU 下 Linux 的可行性、XIP 在主线中的前景、无线固件闭源限制,以及 NetBSD 或 nommu Linux 是否更合适。

评论精华

  • 不少人批评项目像 AI 辅助堆出来,文档和验证不足。
  • 也有人认为反应过度,作者此前就常做类似底层移植实验。
  • 技术讨论集中在 ESP32-S31 的 MMU 是否足以支撑 Linux。
  • Linux 6.12 的 XIP 依赖被认为可能是死胡同。
  • 若真实可用,Linux on ESP 对物联网场景可能很有价值。