1. Qubes OS 文件复制回报链可攻陷 Dom0 (Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel)
Qubes 安全公告 QSB-118 披露：用户若从 Dom0 运行 qvm-copy-to-vm，把文件复制到已被攻陷的 qube，目标虚拟机可借错误回报中的文件名向 Dom0 注入任意命令，进而接管整个系统。qfile 协议传输结束后会返回校验和、错误码和最后接收的文件名；发生错误时，Dom0 将这些内容写入图形提示。问题在于文件名清理函数只替换非 ASCII 字符和双引号，仍保留 Shell 元字符，而显示错误的函数又把拼接字符串交给 system() 启动对话框，攻击者输入因而进入高权限 Shell。虚拟机内部版本不受影响，因为它直接执行程序而不经过 system()。所有 Qubes OS 版本均受影响；4.3 的修复包是 qubes-core-dom0-linux 4.3.22，先进入 security-testing，之后转入稳定仓库。官方建议照常更新，无需额外处置。
原文链接：https://www.qubes-os.org/news/2026/08/29/qsb-118/
论坛讨论链接：https://news.ycombinator.com/item?id=49496918
评论认为后果严重，但触发面比标题看起来窄：攻击者必须先控制某个 qube，再诱使用户从本应保持干净的 Dom0 主动向它复制文件；普通虚拟机之间的复制路径不使用 system()，不受影响。不过一旦成功，权限会直接跃升到 Dom0。争论随后集中到 system()：有人认为它不适合现代高权限代码，任何拼入命令的外部数据都可能穿过 Shell；也有人补充，system() 并非绝对不能用，但完整字符串必须来自可信本地来源。本文含不可信文件名的错误提示，更适合直接执行程序或用管道、环境变量传递数据。
2. 加州年龄验证法为 Linux 与开源软件留出豁免 (California lawmakers unanimously pass Linux exemption from age-verification law)
加州议会一致通过 AB 1856，修订即将实施的《数字年龄保障法》，把按 GPL、MIT、BSD、Apache 等允许复制、再分发和修改条款发布的操作系统与应用排除在“操作系统提供者”定义之外，因此 Debian、Fedora、Ubuntu、Arch 和 BSD 家族无需收集年龄数据。修正案还排除未通过受监管应用商店、以独立可执行程序形式提供的组件，apt、pacman 等包管理器中的库和依赖因而得到覆盖；只分发宿主应用内扩展或插件的商店也不在范围内。法案删除把设备主要使用者一概写成儿童的原始定义，并禁止在法律没有要求时索取年龄信号，避免接口演变为通用数据收集渠道，同时为误判提供善意免责。Windows、macOS、iOS 与 Android 仍须执行：新账户从 2027 年 1 月 1 日开始收集，既有设备期限为 7 月 1 日；SteamOS 是否豁免尚未明确。
论坛讨论链接：https://news.ycombinator.com/item?id=49495372
评论没有深入法条，而是从“孩子会不会因此转向 Linux”谈到技术兴趣的来源。开场者打趣说，豁免可能让孩子都变成 Linux 原生用户，终于迎来“Linux 桌面之年”；多人随后把 Minecraft 视为一代人接触命令行、Java 参数和服务器配置的入口。有人回忆因给游戏作弊、和兄弟争高分而开始编程，也有人说大学申请者最常见的计算机兴趣起点就是电子游戏。评论者普遍把自行搭服务器、改参数、解决具体问题看成主动学习，认为求职时不必遮掩，反而能体现兴趣和动手能力。
3. 罗曼空间望远镜启程勘测暗宇宙 (Nancy Grace Roman Space Telescope)
NASA 的南希·格雷斯·罗曼空间望远镜于 2026 年 8 月 30 日发射，正踏上约三个月、百万英里的旅程前往最终轨道。它以 NASA 首位首席天文学家、被称为“哈勃之母”的 Nancy Grace Roman 命名，核心任务是研究暗能量、暗物质、系外行星和红外天体物理。罗曼的视场至少是哈勃的 100 倍，预计服役期内可测量多达十亿个星系的光，适合快速、大范围地绘制宇宙并寻找随时间变化的目标。其宽视场仪器负责巡天；日冕仪则遮挡恒星强光，直接观察系外行星与行星形成盘，同时验证未来任务所需技术。任务还将统计银河系行星系统，回答宇宙加速膨胀等问题。NASA 页面显示航天器已完成建造并进入飞行阶段，后续观测将与哈勃和韦布的窄域深度能力互补。
原文链接：https://science.nasa.gov/mission/roman-space-telescope/
论坛讨论链接：https://news.ycombinator.com/item?id=49490870
HN 讨论最兴奋的是“宽而快”：罗曼单幅覆盖范围可大于满月，配合近 3 亿像素宽视场相机，可先从大面积、多时次图像中找出超新星等变化目标，再交给韦布深入观测。另一条主线是数据开放；评论称巡天数据处理后立即公开、没有专属期，但有人追问原始数据能否下载，以及在 NASA 平台处理时的存储和算力费用。大家还讨论了侦察卫星镜面来源、为何昂贵望远镜不造两套，以及日冕仪作为系外行星成像技术前驱的意义。讨论重点是任务互补，并非简单比较哪台望远镜“更强”。
4. CPython 正式支持 RISC-V (RISC-V is now officially supported by CPython)
CPython 已把 RISC-V 列为 PEP 11 中的 Tier 3 正式支持架构。作者说明，这项进展来自过去几个月的集中改进，也建立在社区长期积累之上：贡献者持续在真实硬件上测试，修复架构相关问题，完善构建支持，报告缺陷并审查补丁。稳定、持续的 RISC-V 实机测试尤其关键，RISE Project 及多名贡献者为此提供了支持。Tier 3 只是起点，团队正研究通过 RISE RISC-V Runners 把该架构直接纳入 CPython CI，并希望长期推进到 Tier 2；此外还计划探索利用 RISC-V 特性的架构专属优化。官方也邀请硬件持有者构建、运行 CPython 及自身测试套件并反馈问题，同时指出包、编译器、工具和基础设施仍需整个 Python 生态继续完善。
原文链接：https://blog.python.org/2026/08/riscv-now-officially-supported/
论坛讨论链接：https://news.ycombinator.com/item?id=49425252
讨论首先追问官方支持哪套 RISC-V 扩展基线。CPython 参与者解释，目前稳定测试机器只有 RV64GC，实际目标也是它；有人希望未来采用含向量、位操作扩展的 RVA23，但必须等待硬件与用户生态普及。manylinux riscv64 标签同样意味着 RV64GC，贸然提高基线会让现有用户及其 wheel 失去兼容性。有人建议用 QEMU 补测，回应认为模拟器可行，却解决不了真实硬件尚未迁移。32 位 RISC-V 多用于微控制器，更适合 MicroPython 等项目。
5. AI 爬虫正吞掉 Linux 内核站点两成算力 (Creepy Crawlies)
Linux 内核基础设施维护者 Konstantin Ryabitsev 公布了 git.kernel.org 遭 AI 爬虫消耗的实测数据：5 个分布式节点共 90 个 CPU 核心，其中长期有 14 至 16 个核心只负责把 Git 提交渲染成 HTML，耗费已超过克隆代码等全部正常访问。根源并非数据难取——内核仓库和邮件列表本可直接克隆——而是爬虫逐个访问约 148 万次提交，并在 922 个高度重复的分叉仓库中制造数十亿个可抓取网址。站点每天收到约 600 万次随机提交请求，Anubis 工作量证明会立即挡下 66%，但已有 33% 能完成挑战；维护者估计真实用户流量仅约 2%。从按 User-Agent、IP 和子网封禁，到提高挑战难度，都只换来短暂缓解，还让手机用户等待并发热。团队正关闭昂贵功能、限制匿名访问，但仍承诺提供数据下载，只是不再容忍最低效的逐页抓取方式。
原文链接：https://people.kernel.org/monsieuricon/creepy-crawlies
论坛讨论链接：https://news.ycombinator.com/item?id=49491791
评论焦点是 Anubis 的工作量证明能否持续。一位读者称，难度 6 在 iPhone 上用网页实现需约 180 秒，但用 ARM SHA-256 指令写原生扩展后可在毫秒级完成；专用矿机算力更高，因此提高难度只会先伤害真人。另一位认为关键是 JavaScript 与原生代码相差三个数量级：爬虫要翻取远多于普通人的页面，只要单页有成本，挑战仍能扩大批量抓取代价。第三位则把目标限定为阻止“笨爬虫”意外压垮网站；若爬虫因此支持缓存、不再遍历随机旧提交，即使最终通过挑战，也算达成目的。
6. 我们为何会对软件缺陷视而不见 (Bug Blindness)
作者把“缺陷盲视”描述为一种适应过程：他每周能注意到数百乃至数千个问题，却常看到团队内部坚信产品运行良好，即使普通用户必须掌握一串反直觉的规避动作才能使用。Blackboard 员工不知道产品广受师生厌恶，是组织认知脱离外部体验的例子；积灰的机械鼠标则展示了个人如何逐渐学会用夸张手势补偿失灵，直到旁人上手才发现异常。类似习惯也存在于 Google Docs、登录流程和日常设备操作中，久而久之被误认为“计算机素养”。内部试用虽有帮助，但开发者最擅长形成绕路习惯，因此仍可能看不见问题。作者认为，愿意接受具体反馈的人可以重新学会识别缺陷；在编码代理让低质量软件更易批量产生、也让修复更便宜的今天，首先看见质量仍可改进，反而变得更加重要。
原文链接：https://danluu.com/bug-blind/
论坛讨论链接：https://news.ycombinator.com/item?id=49494520
评论者提出两种相反成因。开发者的心智模型与系统实现贴得太近，因而继承同一批盲点：他们会测试零杯、负一杯等边界输入，却想不到普通顾客只是问洗手间在哪里。非技术用户则可能根本不建立稳定模型，只记住“失败就再试一次”。当软件充满缺陷、反用户设计和不可预测行为时，把电脑当作精灵而不是可理解的机器，甚至可能是信息成本更低的策略。于是开发者因理解过深而漏看问题，普通用户因放弃理解而默默绕过问题；真正令人挫败的，是仍坚持把软件视作经过设计、理应可推理的系统。
7. Haiku R1 Beta 6 时隔两年发布 (Haiku R1/beta6 has been released)
Haiku 项目于 2026 年 8 月 26 日宣布 R1/beta6 正式发布。这个版本距离上一版 beta 已约两年，发布时间也恰好落在 Haiku 诞生 25 周年约一周之后。当前抓取到的公告正文非常简短，只确认了版本、发布日期和这两个时间背景，并提供 Release Notes、媒体联系与下载入口；页面本身没有展开列出新增功能、修复项目、硬件兼容范围或升级注意事项。因此，从现有正文能够确定的是一次间隔较长的测试版更新，而不能据此声称它包含某项具体改进。想核对完整变更的读者仍需进入公告所链接的发行说明；现有材料也不支持把评论区里的个人测试结果当成官方版本特性。对本次摘要而言，保持这一来源边界比补写一份未经抓取验证的更新清单更重要。
原文链接：https://www.haiku-os.org/news/2026-08-26_haiku_r1_beta6
论坛讨论链接：https://news.ycombinator.com/item?id=49499867
一名 IUP 工具包维护者称 Haiku 后端观感和性能很好，Hello World 内存约 3MB，低于 Win32 的 4MB，也少于 GTK、Qt 和 WinUI。另一名 ThinkPad X1 Yoga 用户却遇到 beta6 无法启动，只能在安全模式禁用 ACPI；连接 Focusrite Scarlett 时，新 USB Audio 工作还会触发内核崩溃。他暂时换回 AI 协助编写的驱动，但项目不接受 AI 代码，成果无法贡献。讨论由此转向是否建立影子仓库，保存这类移植和驱动。
8. 用宜家 Kallax 改出两座家用工作台 (Hacking IKEA Furniture)
作者搬家后想在书房同时获得工作台的实用深度和客厅家具的外观：工业货架太像车库，普通柜体最深约 40 厘米，定制家具又昂贵，于是以两组 2×2 的宜家 Kallax 和卖不掉的旧书桌为基础改造。160×80 厘米桌板从两端各切出一块 80×60 厘米台面；每组柜体上下加 MDF 板，台面、橡胶垫、MDF 与 Kallax 预钻孔后倒置锁紧，抽屉、柜门、装饰膜和旧隔板补齐收纳。作者特别提醒，Kallax 面板并非实木，螺丝过紧会穿破表层；用纸模板同时钻配对板材，比反复量尺寸可靠。项目也踩到板材被错切成 355 毫米而非 335 毫米、孔位误测和螺丝批头不统一等坑。单座成本约 130 欧元，旧桌板按零成本计算。成品靠墙时扎实，只有横向推动会轻微晃动，作者计划下次加强该方向的支撑。
原文链接：https://greenlightning.eu/diy/hacking-ikea-furniture/
论坛讨论链接：https://news.ycombinator.com/item?id=49497810
抓取到的评论以一位读者对宜家的长期评价为主。他转述建筑师朋友的看法：宜家最大的贡献，是把现代审美以大众负担得起的价格带进普通家庭；与过去只求实用、外形沉闷的“木屋家具”相比，这种普及改变了公众品味。评论也反驳“实木或设计师家具天然更好”的想法：耐用会增加价格、安装和搬运成本，人们也未必真要把家具传给下一代；昂贵设计家具的做工并不总能支撑售价。对年轻人和预算有限者，他在欧洲市场很难找到同时兼顾价格、外观、质量和可获得性的替代品牌，因此认为宜家的品质通常已经足够。
9. 为了让每行对齐，他重写了整篇攻略 (“I just chose words carefully”)
等宽字体让每个字符占据相同宽度，普通排版和右对齐尚可处理，居中却会因不存在“半个空格”而难以真正匀称；两端对齐更麻烦，空格容易被拉得过大且无法均匀分布。常见排版会靠断词改善，但连字符在等宽文本里格外醒目，也会干扰复制粘贴。上世纪 90 年代末，rs1n 为一篇《超级银河战士》攻略采用了另一种办法：不用排版程序，而是逐句改写、谨慎选词，让文本右边缘自然对齐。这种人工处理贯穿了此后约 1.7 万字内容，FAQ 中那句“我只是仔细选择了词语”正是答案。作者把它视作罕见的屏幕写作实践，也联想到实体书为避免孤行而改写文字，以及界面设计者为了让按钮或提示语塞进固定宽度而反复调整措辞的日常。这个例子展示了版面约束如何直接参与写作，而不只是文字完成后的装饰。
原文链接：https://unsung.aresluna.org/i-just-chose-words-carefully/
论坛讨论链接：https://news.ycombinator.com/item?id=49503601
讨论里有人现场用四空格缩进写出两端对齐的评论，并回忆自己在 DOS、OS/2 和早期 Windows 时代长期这样写邮件；熟练后，只需随手替换长短不同的词，速度并不会慢太多。他还曾花很久把文字排成圣诞树形状。不过，这种格式在窄屏手机上会换行错乱，横屏才勉强可读。另一位读者举出 Laravel 注释块的例子：固定三行，并让每行依次缩短三个字符。有人认可尺寸约束会迫使作者思考写什么，也提醒它只保证长度合适，并不保证表达清楚、易读。
10. 地球上最长的水上与陆上直线路径 (Longest Straight Line Paths on Water or Land on the Earth (2018))
这篇 2018 年的论文研究一个看似直观、实际受球面几何与地形数据约束的问题：在地球表面上，不碰到陆地的最长水上直线路径，以及不经过水域的最长陆上直线路径分别在哪里。arXiv 页面记录作者为 Rohan Chabukswar 与 Kushal Mukherjee，论文最初提交于 2018 年 4 月 9 日，现列为第 4 版，分类为数学史与综述，并提供 PDF、实验性 HTML 和 TeX 源文件入口。当前抓取正文没有显示论文摘要，不能从页面本身复原算法细节；讨论中的读者概括称，作者取得高程数据并实现搜索算法，验证了 Reddit 用户先前提出的海上路线，同时给出陆上路线。这里不补写材料中未出现的精确算法、误差模型或端点结论。
原文链接：https://arxiv.org/abs/1804.07389
论坛讨论链接：https://news.ycombinator.com/item?id=49496782
读者把论文概括为：Reddit 用户先用实体地球仪和一根线寻找路线，再以 Google Earth 制作可视化；论文作者随后用高程数据和算法验证其海上猜想，并寻找陆上答案。评论给出的量级是，两条路径约占地球周长的 80% 和 28%。争议集中在“陆地”如何定义：有人提出从塞内加尔附近到中国、约 13250 公里的更长路线，认为论文因把低于海平面的区域视作水而漏掉它；反方指出该线可能穿过苏伊士运河，而论文给出的路线本来也跨越河流湖泊。若要求绝不碰水，南极洲又会引出冰是否算固态水的问题。