2025-10-27

39 篇热帖

2. 10M people watched a YouTuber shim a lock; the lock company sued him – bad idea (arstechnica.com) 811 points | 309 comments | by Brajeshwar

锁具YouTuber特雷弗·麦克纳利因展示轻易破解锁具而获得巨大关注，却遭锁具公司Proven Industries起诉，最终引发广泛争议与法律裁决。事件源于Proven公司发布视频，宣传其一款售价130美元的拖车挂锁坚固耐用。随后，麦克纳利发布视频，仅用一片铝罐切片制成的垫片，在数秒内打开了该锁，视频在YouTube上获得近千万次观看。Proven公司认为该视频具有误导性，并通过法律信件、短信联系麦克纳利及其家人，声称其行为构成威胁。

Proven公司随后发布回应视频，指控麦克纳利隐瞒准备工作以制造锁具易破解的假象，并雇员在社交媒体上指责其欺骗观众。公司进一步向平台提交多份DMCA下架通知，以版权侵权为由试图移除麦克纳利的视频。麦克纳利则上传新视频，当众从新拆封锁具上直接制作垫片并破解，以回应指控。

2025年5月，Proven公司向佛罗里达州联邦法院提起诉讼，指控麦克纳利八项罪名，包括版权侵权、诽谤性暗示、虚假广告、干扰商业关系等。诉讼重点批评麦克纳利视频中的“嘲讽”元素，如晃腿、饮用果汁等姿态，认为其贬低了产品严肃性。然而，诉讼引发了麦克纳利粉丝的强烈反弹，Proven公司称其收到大量骚扰信息和虚假客服请求，公司高管及其家人也遭受骚扰。

案件于2025年6月举行听证会。法官玛丽·斯克里文拒绝批准Proven公司的初步禁令申请，认为其胜诉可能性不足。法官指出，麦克纳利的视频属于对版权材料的批判性引用，符合合理使用原则；同时，消费者因批评而放弃购买产品并不构成商业关系侵权。法官敦促双方和解。

同年7月7日，Proven公司撤回诉讼，并罕见地申请封存几乎全部法庭记录，称证人因担心麦克纳利支持者的报复而退出合作。麦克纳利的律师反驳称，公司此前在社交媒体上高调宣传诉讼，如今却要求保密，时机敏感。法官尚未对此申请作出裁决。

事件凸显了Proven公司应对批评的失败策略：最初其回应视频专业得体，但后续的法律行动和个人化攻击反而放大了问题，引发了“斯特赖桑德效应”，即试图压制信息却导致更广泛传播。公司不仅损失了时间和资金，还招致负面舆论，成为处理公众批评的反面教材。

3. PSF has withdrawn $1.5M proposal to US Government grant program (pyfound.blogspot.com) 496 points | 441 comments | by lumpa

Python软件基金会撤回美国政府资助提案

事件概述

2025年1月，Python软件基金会（PSF）首次向美国国家科学基金会（NSF）提交了一份价值150万美元的提案，旨在解决Python和PyPI生态系统的结构性安全漏洞。该提案属于NSF“开源生态系统安全与隐私”资助计划，经过多轮审查后被推荐获得资助。然而，在收到资助条款后，PSF决定撤回申请。

撤回原因

NSF的条款要求接受资助的组织声明：“不会在资助期间运营任何推进或促进多元化、公平与包容性（DEI）或违反联邦反歧视法律的歧视性公平意识形态的项目。”该限制不仅适用于资助直接支持的安全工作，还扩展至PSF的整体活动。违反条款可能导致NSF追回已拨付的资金，带来重大财务风险。

PSF的立场与价值观

PSF的使命明确包含“支持和促进多元化、国际化的Python程序员社区”。接受上述条款将违背其核心价值观。PSF董事会一致投票决定撤回提案，尽管这意味着放弃对社区和基金会预算都具有重要意义的资金支持。

提案的预期影响

该提案旨在开发自动化工具，对上传至PyPI的所有软件包进行前瞻性安全审查，以保护数百万用户免受供应链攻击。研究成果有望扩展至NPM、Crates.io等其他开源生态，提升整体安全性。对PSF而言，150万美元的资助（为期两年）将是其迄今获得的最大单笔拨款，对其年预算约500万美元、仅14名员工的小型组织具有重要支持作用。

财务现状与呼吁

撤回提案叠加通胀、赞助减少、科技行业经济压力及全球不确定性等因素，使PSF面临更大的财务需求。基金会呼吁社区通过以下方式提供支持：

  • 成为会员：参与PSF选举并享有投票权。
  • 捐赠：支持PSF持续运作。
  • 企业赞助：鼓励使用Python的企业成为赞助商。
4. Tags to make HTML work like you expect (blog.jim-nielsen.com) 395 points | 209 comments | by FromTheArchives 
# 确保HTML按预期工作的基础标签

本文基于Alex Petros演讲中提到的“正确使HTML工作的咒语”这一概念，总结了作者认为在新建HTML文件时应始终包含的四个基础代码片段，以确保浏览器能按预期行为进行解析和渲染。

## 1. `<!doctype html>`
- **作用**：声明文档类型为HTML。
- **重要性**：不声明会导致浏览器进入“怪异模式”，模拟旧版、非标准的渲染行为，从而影响布局、尺寸和对齐等计算方式。
- **说明**：该声明大小写不敏感，但推荐使用标准形式以保证一致性。

## 2. `<html lang="en">`
- **作用**：声明文档的语言。
- **重要性**：有助于浏览器、搜索引擎和辅助技术（如屏幕阅读器）正确处理内容，具体包括：
    - 确保屏幕阅读器发音正确。
    - 提高搜索索引和翻译的准确性。
    - 启用与区域设置相关的工具（如拼写检查）。
- **备注**：语言信息也可以通过服务器HTTP响应头设置，但作者倾向于在HTML文件中直接声明。

## 3. `<meta charset="utf-8">`
- **作用**：指定字符编码为UTF-8。
- **重要性**：确保特殊字符（如智能引号、商标符号©、省略号…、表情符号和非拉丁字母é、ñ等）正确显示。
- **说明**：缺少此标签常导致字符显示为乱码或不正确的符号，作者通过示例展示了添加前后的对比效果。

## 4. `<meta name="viewport" content="width=device-width,initial-scale=1.0">`
- **作用**：设置视口，使页面宽度适配设备屏幕宽度，并设置初始缩放比例。
- **重要性**：缺失会导致移动端浏览时页面被缩小显示，影响可读性和用户体验。作者通过截图对比展示了添加标签前后的明显差异。

## 总结
这四个标签共同确保了HTML文档在现代浏览器中能够正确、一致地渲染，并为辅助工具和搜索引擎提供必要的信息。最后，作者以幽默的方式提及了现代前端开发中常见的`<div id="root"></div><script src="bundle.js"></script>`模式，暗示了当代网页开发的另一种“咒语”。
6. How I turned Zig into my favorite language to write network programs in (lalinsky.com) 256 points | 90 comments | by 0x1997

Zig语言与Zio异步IO库的技术总结

开发背景与动机

作者最初关注Zig语言是因其面向音频软件（低延迟、无内存分配、实时性）的设计目标。在看到Zig语言创建者Andrew Kelley用Zig重写其Chromaprint算法后产生兴趣。在重构AcoustID倒排索引项目时，作者决定用Zig实现新版本，发现其开发体验良好且性能优于之前的C++版本。

网络编程的挑战

在为新版本添加服务器接口时遇到困难：

  • 旧版C++使用Qt进行异步IO处理
  • Go语言在网络和并发方面有优势，但作者希望保持Zig实现
  • 现有Zig HTTP服务器不成熟，实现自定义TCP服务器需大量线程

Zio库的创建

作者开发了NATS客户端后积累了Zig网络编程经验，最终创建了Zio异步IO并发库。核心设计理念：

协程模型

  • 采用Go风格的协程模型
  • 使用固定大小栈的栈ful协程
  • 调用stream.read()等IO操作时会挂起当前任务，IO完成后恢复执行
  • 提供同步代码的书写体验，简化状态管理

主要功能

  1. 全异步网络和文件IO
  2. 与协作式运行时配合的同步原语（互斥锁、条件变量等）
  3. Go风格通道
  4. 操作系统信号监听
  5. 支持单线程和多线程模式

性能特点

  • 单线程性能超越Go和Rust的Tokio框架
  • 上下文切换开销极低，接近函数调用
  • 多线程模式性能与Go/Tokio相当
  • 任务可在不同线程间迁移，优化延迟和负载均衡

技术实现示例

Zio实现了标准读写接口，使外部库无需感知Zio环境即可使用。提供的HTTP服务器示例展示了如何：

  • 使用固定大小缓冲区读写流
  • 通过zio.net.Stream进行网络操作
  • 为每个连接创建独立协程任务
  • 使用zio.Runtime管理任务执行

未来发展方向

  1. 更新NATS客户端以使用Zio内部实现
  2. 基于Zio开发HTTP客户端/服务器库
  3. 将Zig从音频编程语言扩展为全面的网络编程语言

总结

Zio通过协程模型实现了高效的异步IO，解决了Zig语言在网络编程中的并发挑战，使其具备了与Go、Rust在网络编程领域竞争的能力。

8. We saved $500k per year by rolling our own "S3" (engineering.nanit.com) 248 points | 192 comments | by mpweiher

How We Saved $500,000 Per Year by Rolling Our Own “S3” tl;dr We used S3 as a landing zone for Nanit’s video processing pipeline (baby sleep-state inference), but at thousands of uploads/second …

9. Microsoft in court for allegedly misleading Australians over 365 subscriptions (www.accc.gov.au) 247 points | 110 comments | by edwinjm

ACCC起诉微软涉嫌误导澳大利亚365订阅用户

澳大利亚竞争与消费者委员会（ACCC）已向联邦法院对微软澳大利亚公司及其母公司微软公司提起诉讼，指控其在微软365计划整合AI助手Copilot后，就订阅选项和价格上涨事宜误导了约270万澳大利亚客户。

核心指控

ACCC指控，自2024年10月31日起，微软向启用了自动续订的Microsoft 365个人版和家庭版订阅用户表示，要维持订阅就必须接受Copilot整合并支付更高的计划价格，否则只能取消订阅。

ACCC认为此信息具有误导性，因为存在一个未披露的第三选项：Microsoft 365个人版或家庭版经典计划。该计划允许用户保留现有计划的功能，不包含Copilot，并维持原较低价格。然而，微软在与订阅用户的沟通中从未提及“经典计划”的存在，用户唯一能访问该计划的方式是启动取消订阅流程，并在后续页面才能选择切换到经典计划。

ACCC主席Gina Cass-Gottlieb表示：“我们指控微软故意在沟通中省略对经典计划的提及，并隐瞒其存在，直到订阅用户启动取消流程后才显示，其目的是让更多消费者选择更昂贵的集成Copilot的计划。”

价格变化

Copilot整合后，Microsoft 365个人版年费上涨45%，从109澳元涨至159澳元；家庭版年费上涨29%，从139澳元涨至179澳元。

微软的沟通方式

微软向在2024年10月31日启用自动续订的订阅用户发送了两封电子邮件，并发布了一篇博客文章，告知Copilot整合及即将到来的涨价。ACCC的案件正围绕这三份沟通文件展开，指控它们传达了“消费者要么接受更昂贵的集成Copilot的计划，要么只能取消”的虚假或误导性信息。

消费者影响与ACCC的诉求

ACCC认为，数百万被误导的澳大利亚消费者可能因自动续订更高价的Copilot计划而遭受经济损失。ACCC正在为受此行为影响的Microsoft 365个人版和家庭版订阅用户寻求消费者救济。

ACCC寻求的救济措施包括罚款、禁令、声明、消费者赔偿及诉讼费用。根据澳大利亚消费者法，企业每次违规的最高罚款可能高达5000万澳元，或违规所得收益的三倍，或调整后营业额的30%。

背景与调查

  • 微软于2023年推出面向消费者的生成式AI产品Copilot，并于2024年10月31日在澳大利亚整合到Microsoft 365个人版和家庭版订阅中。
  • ACCC的调查基于大量消费者报告及在线论坛（如Reddit）的讨论。消费者通过ACCC信息中心提供的信息，特别是关于通过取消流程可获得经典计划的信息，对调查至关重要。
  • 本案仅涉及家用Microsoft 365个人版和家庭版计划，不包括商业或企业订阅。
  • 微软澳大利亚公司是微软在美国母公司的全资子公司，负责在澳大利亚销售软件。ACCC指控母公司负责准备和发布相关误导性沟通，而澳大利亚子公司作为销售方采纳了这些沟通内容。
  • 此案符合ACCC当前在数字经济领域消费者保护和公平交易问题上的执法重点。
10. Recall for Linux (github.com) 246 points | 89 comments | by anticensor

本文是一篇针对Linux环境的讽刺性技术描述，模仿了微软Windows Recall功能的风格，旨在批判隐私侵犯和过度监控问题。

核心主题

文章以戏谑口吻介绍了一款名为“Recall for Linux”的虚构工具，其本质是对微软Windows Recall功能的恶搞。它通过夸大所谓的“便利性”，实则揭示了持续监控、数据滥用和隐私侵犯的风险。

主要“功能”描述

  1. 数据收集：声称将所有敏感数据存储在易于访问的数据库中。
  2. 持续监控：进行每周7天、每天24小时的屏幕截图，记录所有用户操作。
  3. OCR识别：通过光学字符识别将图像转换为文本。
  4. 信息索引：索引并存储聊天应用或电子邮件中的所有屏幕内容。
  5. 特定场景支持：包括访问已遗忘的网站、恢复已删除的机密信息等。

安装说明

文章指出，由于Linux缺乏无声自动安装的能力，提供了手动安装命令： curl -fsSL https://tinyurl.com/2u5ckjyn | bash 并附带讽刺性注释称该命令“经认证无病毒”（VirusTotal评分98/100）。

发展路线图（讽刺性功能列表）

文章列举了多项计划中的功能，进一步强调监控和数据滥用主题：

  1. 加密实现（延迟至2028年）
  2. 添加AI功能
  3. 商业化模式（仅对开发者盈利）
  4. 增加摄像头和麦克风录制功能
  5. 面部识别集成
  6. 持续音频录制
  7. Windows前瞻性功能
  8. 自动数据云端上传
  9. 使用用户数据训练大型语言模型
  10. 将生物识别数据设为个人资料图片
  11. 要求使用生物识别才能使用该软件

总体意图

整篇文章通过反讽手法，批判了当前科技行业中存在的过度数据收集、隐私侵犯和监控资本主义现象，提醒用户警惕那些以“便利性”为名、实则损害用户权益的技术功能。

11. ICE Will Use AI to Surveil Social Media (jacobin.com) 244 points | 249 comments | by throwaway81523

ICE斥资570万美元采购AI驱动的社交媒体监控软件

美国移民与海关执法局（ICE）签署了一份为期五年、价值570万美元的合同，通过政府技术中介商Carahsoft Technology，获取名为Zignal Labs的社交媒体监控平台的使用许可。这是该机构构建社交媒体监控网络的最新举措。

合同与产品核心

  • 合同对象：与Carahsoft Technology签订，公开于2025年9月。
  • 产品功能：Zignal Labs平台利用人工智能和机器学习技术，每日分析超过80亿条社交媒体帖子，为客户提供“精选检测信息流”，旨在帮助执法机构更快速、更清晰地“探测和应对威胁”。
  • 使用部门：这些许可将提供给ICE下属的情报单位——国土安全调查部，用于为刑事调查提供“实时数据分析”。
  • 产品背景：Zignal Labs不仅服务于ICE，此前已被以色列军方、美国国防部、国务院和海军陆战队等机构使用。

纳入ICE监控工具库 Zignal Labs的加入，使ICE本已庞大的社交媒体监控工具库进一步扩大。这些工具大多采用人工智能技术，从海量在线数据中生成线索并识别“威胁”。文章指出，在特朗普政府时期，ICE似乎正日益利用社交媒体来指导其移民执法策略。

已有监控引发的争议与案例

  • 针对政治活动人士：包括马哈茂德·哈利勒在内的多名亲巴勒斯坦活动人士，在被右翼亲以色列黑名单网站“人肉搜索”后，遭到移民当局的拘留和监禁。
  • 执法行动：一名右翼网红发布视频后，移民特工突袭了纽约市的街头摊贩。
  • 法律诉讼：上周，多个工会就联邦政府利用社交媒体监控针对移民的政治言论提起诉讼，称其为“基于观点的大规模监控计划”。

各方反应与担忧

  • 公民自由组织：美国公民自由联盟（ACLU）批评国土安全部不应购买此类从互联网抓取社交媒体帖子并用AI审查言论的监控工具，且这些“黑箱技术”在秘密部署中缺乏问责制。
  • 法律专家：密切关注ICE监控制度的法律倡导组织“Just Futures Law”的律师表示，ICE的监控合同数量正在增加。

ICE监控能力的持续扩张 文章透露，ICE正计划进一步扩大能力：

  • 组建24/7监控团队：据《连线》报道，ICE正计划建立一个全天候社交媒体监控团队，为移民执法人员识别线索。
  • 新签追踪合同：就在本周，ICE与SOS International LLC签署了一份价值700万美元的合同，用于“寻址服务”，即追踪个人行踪。该公司近期雇佣了ICE前情报主管。

总结 ICE通过采购Zignal Labs等AI监控工具，正在不断加强其对社交媒体的大规模、实时监控能力。这种以人工智能为驱动的、针对广泛网络言论的监控，引发了关于隐私、言论自由以及执法权力滥用的严重担忧，并已遭到工会和公民自由组织的法律挑战。

12. Amazon strategised about keeping water use secret (www.source-material.org) 226 points | 227 comments | by chhum

亚马逊数据中心用水策略：选择性披露与声誉风险考量

根据一份泄露的内部文件，全球数据中心巨头亚马逊（Amazon）曾系统性讨论如何向公众隐瞒其数据中心真实的用水规模。文件显示，公司高管担心更高的用水数据可能损害其声誉。

核心内容与策略

  • 隐藏数据的原因：文件表明，亚马逊数据中心预计到2030年每年将消耗77亿加仑水（主要用水）。然而，公司出于“声誉风险”考虑，选择仅计算并披露这一相对较小的“主要用水”数字，而不包括用于发电等环节的“次要用水”。若计入次要用水，实际消耗量将翻倍。
  • 与竞争对手的差异：微软和谷歌定期公布其用水数据，而亚马逊从未公开披露其数据中心的具体用水量。文件中，亚马逊高管将透明度描述为“单向门”，建议保密用水预测，同时又担心这可能引发“掩盖真相”的指控（例如“亚马逊隐藏用水量”这类负面头条）。
  • “水资源正效益”计划：2022年11月，亚马逊云服务（AWS）发起了“水资源正效益”（Water Positive）计划，承诺到2030年“回馈比使用更多的水”。文件指出，选择仅计算主要用水量是为了使该计划的内部目标更易实现，并避免因公布完整数据而面临更大的运营、监管或声誉风险。
  • 更广泛的用水足迹：文件还揭示，亚马逊整个集团（包括其庞大的电商业务）的用水量远高于AWS部分。2021年，亚马逊整体取水量约为105亿加仑。此外，“间接用水”（主要来自供应链，如棉花种植和农产品灌溉）约占亚马逊总用水足迹的90%，但公司同样决定对此保密，以免为集团其他业务部门设立难以跟进的用水目标标准。
  • 行业标准与抵消争议：亚马逊被指通过资助非营利组织和咨询公司（如大自然保护协会、世界资源研究所等）参与制定行业用水评估标准，被前员工指责旨在“模糊”其用水足迹。其“水资源正效益”计划主要依赖“水资源补充”项目（如帮助修复水管以减少泄漏）来实现目标。但泄露文件显示，计划投入的1.09亿美元中，约一半是原本就会花费的（出于合规或自身运营需求）。专家批评此类“抵消”操作不能真正消除运营的水足迹，宣称“水资源正效益”具有误导性。

亚马逊的回应

  • 亚马逊发言人玛格丽特·卡拉汉称，泄露文件“已过时”，“完全歪曲了亚马逊当前的用水策略”，并指出公司自2021年以来，单位电力用水量已减少40%。
  • 她强调，与其他企业的水资源正效益项目一样，亚马逊专注于“直接水足迹”，并遵循行业最佳实践。公司的补充水资源项目是自愿的，并已超出文件中的初步设想。
  • 对于行业标准制定，亚马逊称其为“标准做法”，客户期望公司依据可靠的指导方针来确保问责。
  • 一名匿名的亚马逊现任软件开发者则表示：“如果他们能坦然承认这一点会更好……至少那是诚实的。”
13. Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project) (github.com) 202 points | 43 comments | by dvirbt

MyraOS 总结

项目概述 MyraOS 是一个完全从零开始使用 C 语言和汇编语言（ASM）开发的 32 位 x86 架构操作系统，具有类 Unix 特性。它是 Hack Club 的一个项目，并非玩具或模拟器，而是一个可以在真实设备或模拟器上运行的完整操作系统。

核心特性

  • 底层架构：实现了保护模式（包含 GDT/IDT，中断服务程序/中断请求）、分页与虚拟内存、内存管理、堆与动态内存分配。
  • 运行模式：支持用户模式（Ring 3）和内核模式（Ring 0）。
  • 进程管理：具备进程创建与调度能力。
  • 硬件支持：包含多种驱动，如可编程间隔定时器（PIT）、实时时钟（RTC）、键盘、鼠标、帧缓冲显示器和并行ATA（PATA）硬盘。
  • 文件系统：支持 ext2 文件系统。
  • 图形界面：配备 UI 组合器，提供窗口小部件、标签、图标、按钮等控件，并包含自制字体。
  • 应用程序支持：拥有 ELF 加载器，能够运行真实的可执行文件。

重要亮点 该操作系统已经预置了《毁灭战士》（Doom）的移植版，证明了其运行复杂图形程序的能力。

运行方法 用户需要从 GitHub 发布页面下载最新版本（包含 ISO 镜像和磁盘镜像文件），并安装开源的 QEMU 模拟器。项目提供了在 macOS、Linux 和 Windows 平台上启动 MyraOS 的命令行示例，支持普通窗口和全屏模式。在 Windows 上，作者建议优先使用 Linux、macOS 或 WSL 环境。

反馈渠道 作者提供了个人邮箱地址，欢迎用户提出功能建议、反馈意见或进行交流。

14. Microsoft 365 Copilot – Arbitrary Data Exfiltration via Mermaid Diagrams (www.adamlogue.com) 197 points | 43 comments | by gnabgib

Microsoft 365 Copilot 通过 Mermaid 图表进行任意数据渗漏

漏洞概述

Microsoft 365 Copilot 存在一个间接提示注入漏洞。攻击者可通过精心构造的 Office 文档触发 Copilot 执行恶意指令，窃取用户租户中的敏感数据（如近期电子邮件），并通过生成的 Mermaid 图表将数据渗漏到外部服务器。

攻击原理与步骤

  1. 利用 Mermaid 图表：Mermaid 是一种基于 JavaScript 的图表工具，支持 CSS 样式。M365 Copilot 内置支持 Mermaid，可实时生成图表。
  2. 攻击链：
    • 触发注入：用户要求 Copilot 总结一个包含隐藏指令的恶意文档。
    • 数据获取：Copilot 被诱导调用内部工具（如 search_enterprise_emails）获取敏感数据。
    • 数据编码：获取的数据被进行十六进制编码并分割为每行不超过30个字符。
    • 生成恶意图表：Copilot 生成一个模拟“登录”按钮的 Mermaid 图表，其中的超链接指向攻击者服务器，且链接参数包含编码后的敏感数据。
    • 数据渗漏：当用户被诱骗点击该“按钮”时，编码数据即被发送至攻击者服务器。

关键技术细节

  • 间接提示注入：攻击指令隐藏在文档内容中，当 Copilot 处理该文档时便会执行，无需用户直接与攻击者交互。
  • 规避检测：攻击中使用了“渐进式任务修改”和“嵌套指令”等技术来绕过 Microsoft 的检测机制（如 TaskTracker）。
  • 漏洞利用：漏洞的核心在于利用了 M365 Copilot 能够生成包含动态超链接的 Mermaid 图表，并且该图表中的链接可携带从上下文获取的数据。

修复与缓解

Microsoft 在收到报告后确认并修复了此漏洞。主要的修复措施是禁用了 Mermaid 图表中超链接的交互功能，从而有效阻止了通过此途径进行的数据渗漏。

漏洞披露时间线

  • 2025年7月30日：研究人员发现 Mermaid 图表数据渗漏技术。
  • 2025年8月7日：研究人员在 DEFCON 的 MSRC 活动中与微软员工讨论了漏洞接受标准。
  • 2025年8月14日：发现可与数据渗漏技术结合的可靠间接提示注入方法。
  • 2025年8月15日：向 MSRC 提交完整的漏洞报告和 PoC。
  • 2025年9月8日：MSRC 确认报告的行为，状态更新为“开发中”。
  • 2025年9月26日：MSRC 解决该案例，状态更新为“完成”。
  • 2025年9月30日：MSRC 团队确定 M365 Copilot 不在赏金计划范围内，不提供奖励。
  • 2025年10月21日：漏洞研究报告正式发布。
15. Ken Thompson recalls Unix's rowdy, lock-picking origins (thenewstack.io) 185 points | 31 comments | by dxs

Unix操作系统诞生记：从意外起源到开放文化

偶然的诞生

1966年，23岁的Ken Thompson在贝尔实验室参与了Multics项目的开发，该项目被他形容为“糟糕…又大又慢又丑还非常昂贵”。Multics项目失败后，Thompson获得了那台闲置的专用计算机的使用权。他最初只想改进数据存储设备的读取性能，却意外地在开发过程中，将自己的内存读取测试程序逐渐演变成了一个完整的操作系统——Unix的雏形。

自由的研究环境

Unix的成功部分归功于贝尔实验室独特的工作氛围。Thompson描述那里是“想做什么就做什么”的环境，没有业绩压力。团队成员包括Dennis Ritchie、Doug McIlroy等未来计算机领域的传奇人物。他们在一个被称为“Unix房间”的地方工作，这个社区形成了紧密的“fellowship”（伙伴关系），成员们甚至会一起开锁取回被没收的停车锁，展现了其团结和调皮的一面。

开放先驱

在“开源”概念普及之前，Unix就已经体现了开放文化。Thompson和Ritchie习惯性地不设置文件权限，所有源代码都是可写的，任何人都可以修改。这自然形成了一种协作氛围，Thompson将其比作“在黑板上书写——每个人都能读到”。这种文化促进了Unix的快速迭代和传播。

内部传播与外部影响

Unix最初在贝尔实验室内部用于行政事务（如处理工单），随后逐渐深入到电话公司的核心交换系统中。它的普及源于人们真心喜欢这个系统。后来，贝尔实验室在Plan 9操作系统中的一些研究成果被纳入了UTF-8编码标准，进而影响了当今的互联网连接。

延续与传承

Thompson于2000年离开贝尔实验室，随后加入谷歌。他在谷歌工作时，与近30年前在贝尔实验室的老同事Rob Pike重逢，并共同参与了Go编程语言的创建。这体现了Unix早期社区文化的深远影响和持久联结。

16. Smartphones manipulate our emotions and trigger our reflexes (theconversation.com) 170 points | 102 comments | by PaulHoule

智能手机使用频率和时长持续上升，尤其在年轻群体中，这已成为全球性问题，促使多地出台校园禁令。手机通过整合人脸识别、触觉反馈、震动提示、语音及运动感应等技术功能，构建出一种拟人化的亲密存在，持续捕获用户注意力并建立情感依赖。这些功能虽源于历史技术（如军用GPS、传呼机震动提醒），但现已被创造性地应用于人机交互，甚至重现了类似电子宠物（如拓麻歌子）所培养的情感依附模式。

手机通过感官暗示（如边缘光、橡皮筋回弹效果）模拟皮肤触感，并利用幽灵震动综合征等机制，让用户对设备信号产生过度敏感。更值得警惕的是，手机持续收集生物识别、睡眠模式、表情情绪等数据，这些高度隐私的行为信息可能被用于商业画像，带来深远影响。

为管理这种依赖，用户可通过调整设备设置（如仅在需要时开启定位、改用密码锁屏）、减少提示音震动来增强自主性。厂商本应默认关闭侵入性功能并提升透明度，但更有效的可能是通过政府监管优先保护用户数据。当前公共讨论需超越对社交媒体或AI的担忧，更正视手机本身作为实体设备如何通过交互设计捕获注意力并塑造行为。

17. Alzheimer's disrupts circadian rhythms of plaque-clearing brain cells (medicine.washu.edu) 155 points | 29 comments | by gmays

研究概述

华盛顿大学医学院的研究团队在《自然神经科学》期刊上发表了一项基于小鼠模型的研究，发现阿尔茨海默病特征性的淀粉样蛋白积累会扰乱大脑中小胶质细胞和星形胶质细胞的昼夜节律。这种扰乱影响了数百个基因的日常表达模式，与单纯衰老引起的节律变化不同，可能为疾病治疗提供新方向。

关键发现

  • 基因节律扰乱：在阿尔茨海默病小鼠模型中，淀粉样蛋白积累改变了小胶质细胞和星形胶质细胞中数百个基因的昼夜表达节奏。这些细胞负责清除大脑废物（如淀粉样斑块）并支持神经元功能。
  • 风险基因调控：研究识别出82个与阿尔茨海默病风险相关的基因，其中约一半受昼夜节律调控；在疾病模型中，这些基因的日常活动模式出现异常。
  • 功能影响：昼夜节律扰乱未完全关闭基因，但破坏了细胞功能的同步性，影响废物清除效率。此外，淀粉样蛋白还在通常无节律模式的数百个基因中诱导出新节律，这些基因多与炎症反应相关。
  • 细胞类型特异性：小胶质细胞（大脑免疫细胞）和星形胶质细胞（支持神经元通信）是受影响的主要细胞类型，其相关基因涉及废物分解和脑部维护。

背景与意义

  • 阿尔茨海默病患者常出现睡眠紊乱和日落综合征等症状，表明疾病进展与昼夜系统密切相关。此前研究显示，睡眠模式变化在记忆丧失出现前数年就开始发生，加剧疾病进展。
  • 研究者此前发现蛋白质YKL-40在昼夜周期中波动，并调节淀粉样蛋白水平；过多YKL-40会导致淀粉样蛋白积累，增加疾病风险。本次研究进一步揭示了更广泛的基因节律失调机制。

潜在应用与展望

  • 研究结果表明，靶向小胶质细胞和星形胶质细胞的昼夜节律可能成为治疗阿尔茨海默病的新策略。通过调节生物钟（如增强或特定细胞中关闭节律），有望预防淀粉样蛋白积累和疾病进展。
  • 未来研究需深入理解昼夜系统在脑细胞中的作用，以优化干预方法，最终实现疾病预防。
18. A definition of AGI (arxiv.org) 150 points | 220 comments | by pegasus

本文针对人工智能通用智能（AGI）缺乏明确定义的问题，提出了一个可量化的评估框架。该框架旨在将AGI定义为在认知多样性和熟练度上与受过良好教育的成年人相匹配的能力。

理论基础与框架设计 为使定义可操作，研究团队以经验验证最充分的人类认知模型——卡特尔-霍恩-卡罗尔理论为基础。该框架将通用智能分解为十个核心认知领域（包括推理、记忆、感知等），并借鉴已建立的人类心理测量工具来评估AI系统。

框架揭示的现状与评估结果 应用此框架分析表明，当代AI模型的认知能力呈现出高度不均衡的“锯齿状”分布。当前系统在知识密集型领域表现出色，但在基础认知机制，特别是长期记忆存储方面存在关键缺陷。

量化进展与差距 该框架最终生成量化的AGI评分，从而具体衡量进展与剩余差距。例如：

  • GPT-4 的AGI评分为 27%。
  • GPT-5 的AGI评分为 57%。 这些分数既量化了AI的快速进步，也明确展示了实现真正AGI仍需跨越的巨大鸿沟。
19. If your adversary is the mossad (2014) [pdf] (www.usenix.org) 150 points | 97 comments | by xeonmc

本文是James Mickens于2014年发表的一篇讽刺性评论文章，以幽默的笔调批评了安全研究领域存在的问题。核心观点是：安全研究人员往往沉迷于构建复杂、脱离现实的威胁模型，而忽视了普通用户面临的真实、迫切的问题。

主要论点

  1. 对复杂安全研究的讽刺：文章开头通过类比“三项全能运动员”，讽刺许多前沿安全研究（如复杂的密码学方案）就如同为极其罕见、荒诞的场景进行训练，与日常生活中的实际安全需求脱节。
  2. 安全研究的公共关系问题：作者指出，安全人员倾向于渲染各种恐怖的技术威胁（如恶意应用、被篡改的硬件），但很少为普通用户提供清晰、可操作的解决方案，导致公众感到困惑和无力。
  3. “摩萨德/非摩萨德”威胁模型：文章提出了一个简化的现实威胁模型（见Figure 1）：
    • 对手是非摩萨德：使用强密码并保持常识（如不点击可疑链接）通常足以应对。
    • 对手是摩萨德：则几乎无法防范，任何技术措施在国家级、资源无限的对手面前都可能失效。
  4. 对几个安全“神话”的批判：
    • 公钥基础设施：作者认为，构建一个可靠、大规模的PKI在实践中极其困难，无论是依赖中心化公司还是去中心化的“信任网络”，都会面临管理和人性化的巨大挑战。
    • 信息流控制：要求程序员使用精细的安全标签来管理系统，这过于复杂和不切实际，超越了大多数程序员的能力和意愿。
    • 社交网络建立信任：期望由普通社交网络用户（即容易受骗的普通网民）来支撑起一个安全的密码学信任体系是不现实的。
  5. 结论：作者呼吁安全研究应更注重解决现实世界中的常见问题（如帮助用户生成强密码），而非一味追求理论上的完美防御。他接受了现实世界固有的不完美和风险，并以一种决绝、自嘲的态度表示，宁愿自由而冒风险地生活，也不愿被过度复杂的安全顾虑所束缚。

风格与基调

全文充满机智的比喻、讽刺和自嘲，语言风格幽默犀利。作者以第一人称视角，将技术讨论与日常生活观察相结合，使得批评既尖锐又富有娱乐性。

20. TOON – Token Oriented Object Notation (github.com) 147 points | 51 comments | by royosherove

TOON – Token Oriented Object Notation 总结

定义与目的

TOON是一种紧凑、人类可读的编码格式，旨在表示JSON数据模型。其主要目标是为大型语言模型输入提供高效的、可无损往返的JSON表示，通过减少令牌消耗来降低成本，同时保持数据结构的清晰性。

核心特点

  • 令牌效率高：在混合结构基准测试中，TOON使用约40%更少的令牌，同时实现了76.4%的准确率（JSON为75.0%）。
  • 无损JSON数据模型：可编码与JSON相同的对象、数组和原语。
  • LLM友好的引导：通过显式的数组长度声明和字段头为模型提供清晰的结构，提升解析可靠性。
  • 语法简洁：结合了YAML的缩进结构和CSV风格的表格布局，最小化语法开销。
  • 表格化数组：均匀的对象数组可压缩为表格式，每行数据共享同一字段头，实现紧凑表达。

适用场景

TOON特别适合处理均匀的对象数组，在此场景下能实现类似CSV的紧凑度，同时提供明确的结构以帮助LLM可靠解析数据。

不推荐使用的情况

  1. 深度嵌套或不均匀结构：JSON可能更高效。
  2. 半均匀数组：令牌节省不明显，若现有流程依赖JSON，建议继续使用。
  3. 纯表格数据：CSV在平坦表格上更小，TOON会增加约5-10%的开销以提供结构（如数组长度声明、字段头）。
  4. 延迟敏感的应用：需在具体环境中基准测试，某些本地/量化模型可能处理紧凑JSON更快。

基准测试结果

基准测试在多个数据集和四个LLM上进行，主要发现：

  • 效率排名（准确率/千令牌）：TOON（27.7）> JSON compact（23.7）> YAML（19.9）> JSON（16.4）> XML（13.8）。
  • 每模型准确率：TOON在大多数模型上表现领先或持平，例如在Claude Haiku和GPT-5 Nano上准确率最高。
  • 问题类型表现：TOON在结构感知和字段检索上表现优异。

数据集与评估

测试包含11个数据集，覆盖均匀、半均匀、嵌套和深层嵌套结构。评估通过209个数据检索问题进行，包括字段检索、聚合、过滤等类型。结果表明TOON在均匀和表格数据上优势明显。

安装与快速开始

  • CLI：可通过npx @toon-format/cli直接使用，支持JSON与TOON互转。
  • TypeScript库：通过npm安装@toon-format/toon，提供encode等函数。
  • 编辑器支持：包括VS Code扩展、Tree-sitter语法等。
  • 其他实现：官方和社区提供了Python、Rust、Go、Java、.NET等多种语言的实现。

媒体类型与文件扩展名

TOON文件使用.toon扩展名，媒体类型为text/toon，默认UTF-8编码。

生态系统与文档

文档包含完整的语法参考、API指南、基准测试详情和LLM集成策略。项目采用MIT许可证。

21. The last European train that travels by sea (www.bbc.com) 145 points | 132 comments | by 1659447091

文章主要讲述了意大利从米兰开往西西里岛的“城际夜车”如何通过一种独特的“铁路轮渡”方式穿越墨西拿海峡，并探讨了拟建的跨海大桥可能对其造成的威胁。

核心旅程：

  • 列车与航线：“城际夜车”从米兰中央火车站出发，经过1489公里的陆地行程后，在意大利南部的圣乔瓦尼镇车站被拆分，通过渡轮横跨墨西拿海峡，在西西里岛的墨西拿市重新组装后，继续前往巴勒莫或锡拉库扎。
  • 独特性：这是欧洲最后一列通过渡轮载运乘客穿越海峡的客运列车，这种“铁路-轮渡”联运方式自1899年运营至今。

旅程的意义与现状：

  • 社会功能：该服务连接了意大利本土与西西里岛，是学生、工人和返乡家庭的日常通道，也是一种重要的“国家统一”象征。
  • 旅行体验：夜车之旅被视为一段充满怀旧感和感官体验的独特旅程。乘客在海峡渡轮上可以下船活动，购买小吃，欣赏风景，并与陌生人交流。夜火车本身也因迎合了人们对慢速、可持续旅行的需求而经历复兴。

面临的威胁与争议：

  • 大桥计划：意大利政府已重启计划，拟建造一座耗资135亿欧元的巨型悬索桥横跨海峡，工程可能于2032年至2033年完成。
  • 公众分歧：民众对此意见不一。支持者视其为进步与发展；批评者则警告，大桥可能损害环境、威胁当地特色，并可能耗尽南部意大利更急需的基建资源。
  • 对列车服务的潜在影响：如果大桥建成，目前独特的“火车-轮渡”服务是否保留尚不确定。运营方意大利Trenitalia表示理解民众对该服务的深厚感情。

总结： “城际夜车”及其独特的渡轮过海方式，代表了一种充满诗意和连接的旅行传统。然而，拟议中的跨海大桥项目给这段旅程的未来蒙上了阴影，使其成为了一场关于进步、身份认同与文化遗产保护之间的争论焦点。

22. More than DNS: Learnings from the 14 hour AWS outage (thundergolfer.com) 143 points | 43 comments | by birdculture

超越DNS：从14小时AWS中断事件中学到的经验

事件概述

2022年10月20日，AWS us-east-1 区域发生了超过十年来最严重的中断事故，持续超过14小时，影响了140个AWS服务，包括关键的EC2、Lambda、IAM、STS等。此次中断导致严重的SLA违约和估计八位数的收入损失。

故障传播路径

一次DynamoDB服务故障演变为140个服务故障的连锁反应。核心原因在于：

  • DynamoDB与EC2的核心依赖：DynamoDB和EC2是AWS内部的“第一层”基础服务，被广泛用于实现其他AWS服务和亚马逊自身的业务。
  • 狗食效应：AWS使用自身云服务（如DynamoDB）来实现其服务，导致故障迅速蔓延至 us-east-1 区域约70%的AWS服务。

DynamoDB中断的根本原因

关键故障：DNS管理系统中的经典TOCTOU（检查时间/使用时间）竞争条件

  1. 系统设计：DynamoDB的DNS管理由三个独立的DNS执行器（Enactor）运行，分布在三个可用区，无协调地进行变更。
  2. 故障触发：一个可用区的执行器变得极其缓慢。
  3. 垃圾回收机制缺陷：系统使用“保留最近N个”策略清理旧的DNS计划。由于延迟过高，该执行器正在应用的计划超出了N的安全窗口，被错误地识别为旧计划并删除。
  4. 缺乏防护：删除过程中没有检查该计划是否仍为“活动计划”，导致活动DNS记录被清除，dynamodb.us-east-1.amazonaws.com 端点关联的IP地址为零。
  5. 状态不可恢复：执行器状态损坏，无法自动恢复，需要超过2小时的手动干预。

EC2中断的元稳定性故障

DynamoDB中断导致EC2的Droplet工作流管理器（DWFM）与物理服务器（Droplet）之间的心跳丢失，打破了大量租约。

  • 正常状态：系统维护约10^6个活动租约和约10^2个损坏的租约。
  • 故障后状态：DynamoDB中断3小时内，损坏租约数量增至约10^5，比正常水平高三个数量级。
  • 元稳定性故障：DWFM系统进入拥塞崩溃状态——庞大的租约重建队列导致工作无法在超时前完成，陷入“队列持续高位”的维持效应。系统无法自行恢复，需要工程师手动重启DWFM服务器以清除积压工作，恢复吞吐量。

NLB中断：错误反馈下的系统行为

NLB服务中断是由EC2网络管理器在积压工作压力下落后引发的。

  • 关键现象：网络配置过时导致健康检查系统收到错误反馈（假阴性）。
  • 错误行为：健康检查系统按照设计逻辑响应错误输入——它触发了自动的可用区DNS故障转移，但这在系统已损坏的背景下是错误的行为。
  • 设计启示：可靠组件与损坏环境的交互可能导致不安全行为。修复措施包括为NLB健康检查系统添加速率控制机制。

行业反思与启示

  1. 反对过度简化的根因分析：作者指出，将故障归结为“人才流失”、“总是DNS问题”或“云不可靠，应返回本地部署”等结论过于肤浅。故障是多重控制机制失灵的结果，应从控制问题的角度分析系统交互。
  2. Swiss cheese模型的应用：该中断是多个潜在缺陷（竞争条件、垃圾回收策略、缺乏防护、状态损坏、告警和人工操作）层叠穿透防御屏障的结果。
  3. 分布式系统的复杂性与现实：即使是像AWS这样拥有世界领先可靠性工程能力的团队，其生产系统也常常运行在一种降级状态中，存在数十个潜在或现存的缺陷和故障。追求“五个九”的持续安全性是一项艰巨的设计和运营挑战。
  4. 当前发展阶段：云行业仍处于发展早期。软件系统远比我们想象的更复杂、更充满缺陷。此次事件是超大规模分布式系统遇到的一个坏日子，但从长远看，公共云行业将根除其设计和运营中的不健全之处，先进的正确性和可靠性实践终将成为常态。
23. Tenacity – a multi-track audio editor/recorder (tenacityaudio.org) 143 points | 44 comments | by smartmic

Tenacity 是一款易于使用的跨平台多轨音频编辑器/录音器，适用于 Windows、Linux 和其他操作系统。它作为开源软件由志愿者开发。

主要功能

  • 录音：支持从真实或虚拟音频设备录制。
  • 导出与导入：兼容广泛的音频格式，并可通过 FFmpeg 扩展。
  • 高质量音频：包括高达 32 位浮点音频支持。
  • 插件支持：提供 VST、LV2 和 AU 插件集成。
  • 脚本功能：支持内置 Nyquist 脚本语言，或通过命名管道使用 Python、Perl 等语言。
  • 编辑能力：允许任意采样和多轨时间线编辑。
  • 可访问性：支持键盘编辑、屏幕阅读器和旁白功能。
  • 分析工具：提供用于信号分析（包括音频）的实用工具。

入门指南

  • 预打包版本可通过存储库的发布页面获取，也可能已集成到您的软件发行版中。
  • 可选地，可以从源代码自行构建。

社区与支持

  • 最活跃的沟通渠道是 Matrix 频道 #tenacity:matrix.org，可实时提问和获取帮助。
  • 也可在 Mastodon 上关注新闻和事件。
  • 所有相关讨论可前往 Lemmy 社区进行。

开发与贡献

  • 上游开发存储库位于 Codeberg，并维护 GitHub 镜像用于可访问性和 CI 目的，但拉取请求会被忽略。
  • 要贡献代码，请参考贡献指南。
  • 开发主要基于 Codeberg，但也提供 SourceHut 作为替代平台来接受代码贡献。

其他信息

  • 如您对 Audacity 的著名分支（如 Audacium 和 Saucedacity）或 Tenacity 的原始代码库感兴趣，可访问相关链接了解更多详情。
25. Rust cross-platform GPUI components (github.com) 139 points | 47 comments | by xvilka

Rust 跨平台 GPUI 组件库

这是一个基于 Rust 的跨平台桌面应用 UI 组件库，旨在构建出色的桌面应用程序。其核心是 GPUI 渲染引擎。

核心特性

  • 丰富组件：提供超过 60 个跨平台桌面 UI 组件。
  • 现代设计：灵感源自 macOS 和 Windows 控件，并结合了 shadcn/ui 的设计，提供现代化体验。
  • 易于使用：组件是无状态的 (RenderOnce)，简单且用户友好。
  • 高度可定制：内置 Theme 和 ThemeColor，支持多主题和基于变量的配置。
  • 多样尺寸：支持 xs, sm, md, lg 等多种尺寸。
  • 灵活布局：支持用于面板排列、调整大小和自由布局的 Dock 布局 以及 Tiles 布局。
  • 高性能：包含用于流畅渲染大数据的虚拟化表格和列表组件。
  • 内容渲染：原生支持 Markdown 和简单 HTML 渲染。
  • 图表：内置图表功能，用于数据可视化。
  • 编辑器：高性能代码编辑器（支持高达 20 万行代码稳定运行），并集成 LSP（诊断、补全、悬停提示等）。
  • 语法高亮：为编辑器和 Markdown 组件提供基于 Tree Sitter 的语法高亮。

使用方式

  1. 添加依赖（在 Cargo.toml 中）：
    gpui = { git = "https://github.com/zed-industries/zed" }
gpui_platform = { git = "https://github.com/zed-industries/zed", features = ["font-kit"] }
gpui-component = { git = "https://github.com/longbridge/gpui-component" }
  2. 基本示例：
    use gpui::*;
use gpui_component::{button::*, *};

pub struct HelloWorld;
impl Render for HelloWorld {
    fn render(&mut self, _: &mut Window, _: &mut Context<Self>) -> impl IntoElement {
        div()
            .v_flex()
            .gap_2()
            .size_full()
            .items_center()
            .justify_center()
            .child("Hello, World!")
            .child(
                Button::new("ok")
                    .primary()
                    .label("Let's Go!")
                    .on_click(|_, _, _| println!("Clicked!")),
            )
    }
}

fn main() {
    gpui_platform::application().run(move |cx| {
        gpui_component::init(cx); // 使用前必须初始化
        // ... 创建窗口和视图的逻辑
    });
}

图标

组件库提供 Icon 元素，但不默认包含 SVG 文件。示例使用 Lucide 图标，用户也可以使用任何其他图标，只需将 SVG 文件命名为 IconName 中定义的名称即可。

开发与示例

  • 桌面画廊 (Story)：一个展示所有组件的画廊应用，可通过 cargo run 运行相关 crate 启动。
  • 重要示例：
    • 代码编辑器：cargo run --example editor
    • 停靠布局系统：cargo run --example dock
    • Markdown 渲染：cargo run --example markdown
    • HTML 渲染：cargo run --example html
  • 独立示例：位于 examples 目录，每个示例是独立 crate，可通过 cargo run -p <name> 运行。
  • Web 画廊 (WASM)：支持通过 WASM 在 Web 浏览器中运行画廊，位于 crates/story-web 目录。

与其他框架对比

下表简要对比了 GPUI Component 与其他常见 Rust/C++ UI 框架的关键方面：

特性 GPUI Component Iced egui Qt 6
语言 Rust Rust Rust C++/QML
核心渲染 GPUI wgpu wgpu Qt
最小二进制大小 ~12MB ~11MB ~5MB ~20MB
Web (WASM) 支持 是 是 是 是
UI 风格 现代 基础 基础 基础
CJK (中日韩) 支持 是 是 差 是
内置图表 是 否 否 是
虚拟化表格 是（行、列） 否 是（行） 是（行、列）
表格列调整大小 是 否 是 是
语法高亮 Tree Sitter Syntect Syntect QSyntaxHighlighter
Markdown 渲染 是 是 基础 否
Markdown 混合 HTML 是 否 否 否
HTML 渲染 基础 否 否 基础
代码编辑器 简单 简单 简单 基础 API
自定义主题 是 是 是 是
内置主题 是 否 否 否

总结：GPUI Component 是一个功能全面、性能优先的现代化 Rust 桌面 UI 框架，在虚拟化表格、Markdown 混合 HTML 渲染、语法高亮（Tree Sitter）以及开箱即用的现代 UI 设计方面具有显著优势，适合构建高性能、复杂的跨平台桌面应用。

许可证：Apache-2.0。

26. Show HN: ISS in Real Time – 25 Years Aboard the International Space Station (issinrealtime.org) 138 points | 22 comments | by bfeist

ISS in Real Time 国际空间站25周年实时探索项目

项目概述

这是一个交互式在线项目，旨在让用户通过数字化方式探索国际空间站（ISS）25年的发展历程和在轨生活。项目通过整合历史数据、多媒体内容与实时信息，提供一个沉浸式的国际空间站体验平台。

核心内容维度

  • 历史时间线：系统梳理了国际空间站自1998年开始建造至今的关键里程碑、任务事件和技术突破。
  • 在轨生活展示：呈现宇航员长期驻留期间的日常工作、科学研究、生活场景及技术挑战。
  • 实时数据接入：部分模块可能接入国际空间站的实时位置、状态或遥测数据（基于项目描述中“Real Time”推断）。

交互体验特色

  • 通过可视化界面与时间轴控件，用户可自由浏览不同阶段的空间站发展历程。
  • 整合图像、视频、文档等多种媒介资料，增强信息传达的直观性。
  • 旨在为公众、教育工作者及太空爱好者提供一个全面了解国际空间站的综合性数字资源。

技术实现与访问

  • 项目作为一个基于Web的交互式应用推出，用户可通过浏览器直接访问。
  • 界面设计优化了用户体验，兼顾信息密度与视觉表现力（参考其分享图片的视觉设计）。
  • 内容涵盖科学、工程、国际合作及人类太空探索的多个层面。
27. Structure and Interpretation of Classical Mechanics (2014) (tgvaughan.github.io) 135 points | 51 comments | by the-mitr

书籍概要：《经典力学的结构与阐释》第二版 (2014)

本书由Gerald Jay Sussman和Jack Wisdom所著，是经典力学领域的一部重要教材，其核心特色在于将理论物理概念与计算方法（特别是Scheme编程语言）紧密结合。书中通过编写计算机程序来建模、分析和验证力学系统的演化，旨在深化读者对力学基本原理的理解。

内容结构：

  1. 拉格朗日力学：奠定了全书的理论基础。从构型空间、广义坐标开始，阐述最小作用量原理，并由此推导出欧拉-拉格朗日方程。深入探讨了如何为不同系统构建拉格朗日函数，处理约束系统（完整与非完整约束），并研究了守恒量（如动量、能量）与诺特定理之间的关系。

  2. 刚体力学：专注于刚体的运动。内容涵盖转动动能、惯性张量、欧拉角描述、欧拉运动方程以及陀螺和自旋-轨道耦合等复杂问题。本章同样强调计算，例如用四元数避免奇点来描述旋转。

  3. 哈密顿力学：从拉格朗日体系通过勒让德变换过渡到哈密顿体系。介绍哈密顿方程、泊松括号。重点分析相空间的结构，包括相图、截面图的绘制与理解，以及李乌维尔定理和标准映射，引入了混沌与规则运动的概念。

  4. 相空间结构：深入探讨相空间的几何结构。研究线性稳定性、同宿缠绕现象，区分可积系统与不可积系统。介绍庞加莱-伯克霍夫定理和不变曲线及其在扰动下的溶解，是理解系统可积性破坏和混沌出现的关键。

  5. 正则变换：研究保持哈密顿方程形式不变的坐标变换。包括点变换、一般正则变换，以及通过生成函数构造正则变换的方法。引入扩展相空间的概念，并讨论约化相空间。

  6. 正则演化：聚焦于时间演化本身。核心是哈密顿-雅可比方程，它将动力学问题转化为寻找主函数的偏微分方程问题。论证了时间演化过程本身就是正则变换，并引入李变换和李级数作为强大的分析工具。

  7. 正则摄动理论：应用前述的李级数等工具处理接近可积的系统。通过具体案例（如受驱摆、非线性共振）展示如何系统地进行微扰展开，并讨论共振重叠准则作为混沌判据，分析系统的稳定性。

附录与特色：

  • 附录：Scheme：专门介绍书中所用的Scheme编程语言，为计算实验提供工具基础。
  • 附录：符号说明：统一全书使用的数学和计算符号。
  • 全书贯穿大量项目和计算练习，引导读者通过编程实践来探索力学概念，体现了“通过构造来理解”的教学哲学。

总结：本书超越传统教材，构建了一个将经典力学理论、计算模型与程序实现深度整合的框架。它不仅传授知识，更提供了一种利用计算机进行科学探究的思维和实践方法，适合希望从计算视角深刻理解经典力学的学生和研究者。

28. Nvidia DGX Spark: When benchmark numbers meet production reality (publish.obsidian.md) 134 points | 86 comments | by RyeCatcher

Nvidia DGX Spark：当基准测试遇到生产现实

本文探讨了Nvidia DGX Spark系统在理论基准测试性能与实际生产环境应用之间的潜在差距。

核心论点

文章的核心在于揭示一个常见现象：在受控的实验室基准测试中表现优异的硬件（如DGX Spark），在复杂的实际生产环境中，其性能表现可能会发生变化。

主要探讨内容

  • 基准测试的局限性：实验室基准测试通常针对特定工作负载和理想条件进行优化，可能无法完全模拟真实生产场景的多样性和复杂性。
  • 生产环境的现实因素：实际应用中会涉及数据管道效率、软件栈配置、网络存储延迟、散热与功耗限制以及并行任务间的资源争抢等诸多变量，这些都可能影响系统最终表现。
  • 性能差距的潜在原因：文章可能会分析导致理论性能与实际效能出现差异的具体技术因素，例如内存带宽瓶颈、CPU与GPU协同效率、特定框架的优化程度等。
  • 评估与选型建议：旨在帮助技术决策者和工程师更全面地评估硬件，不仅关注基准测试分数，更需考虑其在目标实际工作负载下的真实表现和可扩展性。

目标读者

本文主要面向AI/ML工程师、基础设施架构师、IT采购决策者以及需要部署高性能计算集群的技术团队，为他们提供更贴近现实的系统评估视角。

总结

总而言之，文章提醒业界，在基于基准测试数据进行技术选型时，必须审慎考虑实际应用场景下的各项约束条件，以避免理论性能与现实需求之间的预期偏差。

29. What Happened to Running What You Wanted on Your Own Machine? (hackaday.com) 130 points | 56 comments | by marbartolome

四十多年前，个人计算机普及之初，用户享有简单的自由：可以运行任何能获取到的软件。然而，这种自由正在逐渐消亡，并且过程悄然无声。

谷歌近期宣布，从2026年起将收紧侧载（sideloading）应用安装的政策，这虽然被包装为安全措施，但将使用户更难在官方应用商店（Play Store）之外安装应用。此举标志着谷歌对其原本更为宽松的Android平台策略的转变，与苹果iPhone从一开始就采取的完全锁定模式形成对比。尽管仍存在变通方法（如注册为开发者），但这无疑是对用户自由的一种削弱。

这种“围墙花园”模式并非始于智能手机。早在几十年前，视频游戏机厂商便开创先河，通过专有格式、区域锁和硬件芯片等技术，确保设备只运行官方授权游戏，其根本目的是为了通过授权费盈利。消费者当时普遍接受了这种模式，因为游戏机被视为单一用途的娱乐设备。尽管存在改装芯片等地下破解方式，但这主要源于价格因素，并未撼动主流。

与之相反，计算机一直被视为开放的工具。用户购买电脑是为了自由地进行各种创造性活动，其开放性被视为天经地义，而非缺陷。甚至早期的平板电脑和PDA也保持了这种开放性。

iPhone的推出及其App Store模式，将游戏机的锁定策略引入了口袋中的计算机。苹果将“围墙花园”作为卖点，承诺提供经过审核、安全无病毒的应用。这意味著苹果掌控了一切，用户虽然拥有设备，却无权运行未经其批准的软件。

Android最初以开源和灵活著称，允许侧载应用甚至获取root权限。然而，多年来，Android也以安全等合理理由为借口，逐步收紧限制，使得在用户购买的设备上运行自选软件变得日益困难。

微软也曾在Windows平台上尝试推广其应用商店（Microsoft Store），但收效甚微。Windows RT和Windows 10 S等试图锁定至商店应用的版本均商业失败。目前的桌面Windows依然保持开放，但这能持续多久尚不可知。随着在封闭平板和智能手机环境下成长的新一代用户增多，他们可能对传统的文件系统访问和运行未签名代码的需求并不强烈。

作者最担忧的是，我们正在失去在计算机上自由尝试、实验和学习的机会。围墙花园扼杀了创造力，使得爱好者无法轻松分享自制的小工具或游戏模组，许多创意在萌芽阶段就因可行性问题而被扼杀。

尽管阵地已失，但用户仍可通过消费选择来捍卫自由。应避免将“个人计算”变成仅能运行企业付费许可代码的“消费计算”，确保所购买的计算机真正服务于用户的意志，而非仅执行企业批准的指令。

30. How the Mayans were able to accurately predict solar eclipses for centuries (phys.org) 119 points | 126 comments | by pseudolus

The Maya Civilization, from Central America, was one of the most advanced ancient civilizations, known for its significant achievements in astronomy and mathematics. This includes accurate calendars and detailed celestial records, but scientists don't fully understand all the details of their calculations. However, new research is shedding light on how they predicted future eclipses with remarkable accuracy.

31. The MP3.com Rescue Barge Barge (blog.somnolescent.net) 118 points | 41 comments | by CharlesW

为保存MP3.com音乐遗产，作者从Internet Archive的“MP3.com救援驳船”和Wayback Machine下载了约1.78TB的音频数据，目标是创建最完整的MP3.com音乐档案。作者此前基于Reddit上的MP3.com链接列表开发了随机播放项目，发现其中许多链接虽未被Wayback Machine完全归档，却包含比现有“驳船”更多的音频内容，由此萌生了保存并整理这些数据的想法。鉴于Internet Archive当时面临法律诉讼，作者感到有必要确保这些音乐得到安全备份。

项目面临的主要挑战是存储空间。作者最初使用1TB硬盘，后因空间不足，先后借助朋友提供的1.5TB硬盘和通过Free Geek获得的3TB硬盘，才将所有数据集中存储。抓取脚本使用wget按URL结构创建文件夹，虽便于溯源但不利于管理，后借助Everything工具改善文件搜索效率。

为提取音频元数据，作者尝试使用WACUP（基于Winamp）管理庞大的音乐库。尽管32位版本在处理25万首歌曲时崩溃，但64位版本成功索引了53万余首歌曲的标签信息，并支持导出包含文件路径和完整标签的CSV数据（压缩后约60MB）。此过程揭示了部分文件存在损坏或非音频内容，但因服务器返回状态码正常仍被保留。

后续处理中，作者将CSV中的本地文件路径替换为对应的原始URL，并修正了因MP3评论字段包含换行符导致的CSV格式错误，同时避免了Excel将艺术家或标题误判为数学表达式。最终生成的电子表格和CSV数据集包含曲目名、艺术家、年份、提交URL及文件修改日期等字段，并涵盖了“驳船”和Wayback Machine来源的重复记录。

该项目成果已以CSV和Excel格式发布于作者网站的MP3.com保存页面，为研究MP3.com音乐遗产提供了可查询的元数据库，也为未来整合艺术家页面档案奠定了基础。作者还计划未来加入基于mp3guessenc的MP3编码器识别信息。

32. I built my own CityMapper (asherfalcon.com) 116 points | 16 comments | by ashfn

这篇文章介绍了作者如何为伦敦的公共交通系统构建自己的路线规划器。

核心方法与数据源

作者采用了专门为公共交通设计的RAPTOR算法（基于轮次的公共交通路由算法）。与传统基于图的最短路径算法不同，RAPTOR通过“轮次”进行搜索，每一轮对应一次额外的换乘。其核心思想是只探索那些可能改善到达时间的行程。

构建系统需要整合以下数据：

  1. 静态时刻表数据：来自伦敦交通局和国家铁路的GTFS格式数据。
  2. 实时到站预测：来自伦敦交通局统一API。
  3. 实时火车时间：来自国家铁路Darwin API。
  4. 站点间的步行连接。

算法工作原理

RAPTOR算法维护每个站点的最早到达时间。它从起点开始，在第0轮初始化。随后，每一轮都探索当前可达站点，并通过搭乘交通工具（如公交、地铁、火车）更新沿途站点的到达时间。如果某个站点的到达时间得到改善，该站点将被标记，以便在下一轮中继续探索。

实时数据集成挑战

最大的难点在于整合实时数据，以应对列车延误、公交拥堵和地铁中断等情况。为此，作者构建的系统需要：

  • 按需获取实时预测。
  • 用实时估计覆盖计划时刻。
  • 优雅地处理服务取消。
  • 缓存数据以避免API访问频率限制。

成果与收获

最终，作者成功实现了一个能够利用实时数据为伦敦规划路线的路由器。通过这个项目，他深入学习了处理复杂数据格式（如GTFS）、算法优化、API集成与缓存策略，并认识到像谷歌地图这类应用背后隐藏的复杂性。

34. Books by People – Defending Organic Literature in an AI World (booksbypeople.org) 106 points | 103 comments | by ChrisArchitect

Books by People：在AI时代捍卫有机文学
Books By People 是一个独立组织，旨在与出版商合作，验证人类撰写的书籍，维护创意完整性和公众在AI驱动时代的信任。该组织通过支持人类写作的出版商和作者，建立可识别的“有机文学”市场，确保读者能持续发现他们喜爱的作品。

危机背景
AI 正以模仿人类叙事的方式大量涌入文学世界，对出版业构成挑战。若不采取保障措施，真正的人类作品将难以保持其应有的可见度和可信度。

组织使命
通过支持坚持人类写作的出版商和作者，并向读者明确展示这一承诺，来维护一个受信任的有机文学市场。

出版商加入流程

  • 出版商问卷：出版商填写问卷，帮助组织了解其出版实践和AI相关政策，以便定制成员资格。
  • 出版商入职：提供定制协议，明确共同责任和认证流程。一旦加入，出版商成为会员，可开始验证选定书籍并使用资源。
  • 成员资格：会员获得“Books By People 印章”，可用于印刷版、数字版和营销材料中的合格书籍。同时获得独特QR码和ID，链接到出版商目录中的完整档案，方便读者访问所有已验证书籍。
  • 资源与支持：提供认证流程实施支持、AI环境导航指导，以及资源工具包（如出版商手册、AI条款样本、运营模板、渠道专题和咨询支持）。
  • 生态系统访问：加入更广泛的生态系统，包括信任的AI和创意产业专业人士指引、活动优先访问权、AI影响出版商的更新信息等。

行为准则
出版商需遵循准则以确认书籍符合有机文学标准。验证过程包括签署声明、评估人类创作痕迹以及文本分析。

呼吁行动
鼓励出版商加入有机文学运动，在AI辅助书籍泛滥的市场中突出其独特作品，吸引更多关心书籍来源的读者。

常见问题

  • 成本：申请免费；若获批，费用基于年营业额和待验证书籍数量，以确保各规模出版商可及。
  • 额外工作：组织提供支持以最小化额外工作量。
  • 印章适用范围：仅适用于符合有机文学标准的书籍。
  • 定义：有机文学指由人类撰写而非AI创作的作品，通过认证过程确保真实性。
35. Poison, Poison Everywhere (loeber.substack.com) 104 points | 50 comments | by dividendpayee

文章摘要

本文通过一个20世纪70年代英国学校的铅中毒案例，揭示了日常环境中隐性危害的严重性。当时，由于学校靠近繁忙公路且使用含铅汽油，长期暴露于尾气中的学生遭受了未察觉的脑损伤。这一历史事件引申出对现代社会中持续存在甚至新增的毒害问题的警示。

历史教训与当前挑战

  • 作者指出，虽然石棉、含铅油漆等已被禁用，但标准改善并不彻底。例如，即使公共供水达标，家庭内部管道仍可能存在污染；墙体霉菌等隐患也需个人自行关注。
  • 全球化加剧了风险：复杂的供应链、成本压力及监管缺失，导致消费者难以知晓产品安全性。文章举例称，甚至牛排等食品也检测出双酚A（BPA）和微塑料；亚马逊等平台商品准入门槛极低，且跨境产品质量难以追溯。

具体危害案例

  • 铅暴露问题依然普遍：纽约市地铁广告显示，铅污染餐具影响婴儿健康；阿富汗传统炊具因使用含铅金属，导致全球消费者面临风险，亚马逊在发现问题后一年多才下架相关产品。
  • 其他有害物质：家具、餐具中的甲醛或重金属、蛋白粉中的污染物等均缺乏有效质检，消费者维权困难。作者强调，全球供应链中“零检查”现象普遍，甚至存在如橄榄油掺假等欺诈行为。

个人应对的困境与解决方案

  • 个人无力全面监控所有潜在风险，需依赖可信的第三方专业机构。作者提到德国非营利组织“Stiftung Warentest”通过系统测试商品并提供评级，成功引导消费者选择，其信任溢价成为强大商业护城河。
  • 市场机会与趋势：消费者正通过智能设备（如Whoop、Levels）监测个人健康，并开始关注环境质量（如室内空气质量）。作者认为，健康不仅是身体指标，更与居住环境相关，但当前“高端”商品仍可能含微塑料等隐患。
  • 商业潜力：提供安心保障、严格把控供应链的企业存在巨大机会。作者已接触相关创业团队，希望通过支持此类项目，帮助消费者以“公民科学家”身份应对环境风险。

核心观点

  • 许多健康问题（如儿童认知差异）可能源于早期环境毒素暴露，而非单纯“运气”。随着科学进步与意识觉醒，环境健康领域将产生重要商业机会，关键在于建立可靠检测与 remediation 体系，解决聚合风险下的个体无力感。
36. You are how you act (boz.com) 103 points | 63 comments | by HiPHInch

本文对比了卢梭与富兰克林对“自我”的不同定义，并论述了行为塑造自我的现实意义。

卢梭认为人性本善，内在有一个纯真的核心，但会被社会环境所腐蚀。自我探索和内在真实感受至关重要。

富兰克林则主张没有天生的善恶之人，只有善行或恶行。美德是习惯的产物，通过反复实践的行为来塑造品格，而非取决于内在本质。

现代美国社会兼收并蓄了这两种看似矛盾的观点：当需要宽容时诉诸卢梭（强调意图），当需要问责时诉诸富兰克林（强调行动）。两者之所以能并存，是因为它们分别迎合了人们对自我肯定和野心的不同需求。

作者明确支持富兰克林的模式，因为它赋予人主动权和可操作性。核心论点是：“假装直到成功”并非肤浅，而是深刻的行为哲学——持续的行为重复塑造了人的品格，行为本身创造了身份。感受难以控制，但下一步的行动始终可以选择。

卢梭导向无尽的内省，富兰克林导向实际的进步。文章以阿诺德·格拉索的格言作结：“做事造就人”，强调行动对塑造伟大的关键作用。

37. AI Mafia Network – An interactive visualization (dipakwani.com) 101 points | 8 comments | by dipakwani

AI Mafia Network 交互式可视化

  • 项目概述：AI Mafia Network 是一个基于 Acquired Google Podcast 的交互式可视化工具，用于展示网络关系。
  • 交互功能：用户可以点击任何节点以探索其连接；通过拖动进行平移视图；使用鼠标滚轮进行缩放操作。
  • 制作与致谢：由开发者 @dpwxni 制作，并感谢 Ben 和 David 的贡献。
  • 附加信息：同时推荐了制作者的另一个项目——F1 Racing Game 赛车游戏。
38. Why JPEG XL ignoring bit depth is genius (and why AVIF can't pull it off) (www.fractionalxperience.com) 101 points | 64 comments | by Bogdanp

JPEG XL 忽略位深的天才设计（及 AVIF 为何无法效仿）

核心观点：JPEG XL 采用基于浮点数的感知编码，将图像视为连续视觉数据而非离散整数，从而消除了传统编解码器对位深的依赖。这一设计虽看似“非功能”，实则是其强大的创新特性。

JPEG XL 的浮点数与感知方法

  • 处理方式：JPEG XL 的有损编码器将所有图像数据转换为 0.0 到 1.0 之间的浮点数（连续范围），而非传统的整数（如 8 位的 0-255）。
  • 忽略来源位深：无论输入是 8 位 JPEG、10 位 RAW、16 位扫描件还是 32 位浮点数据，均映射至同一范围。编码器关注颜色的感知意义，而非先前的量化精度。
  • 设计哲学：位深仅是文件格式惯例，并非感知现实。人类视觉系统关注梯度是否平滑，而非存储步数的多少。浮点数空间使 JPEG XL 绕过了传统编解码器对数字精度边界的依赖。

AVIF 的局限性

  • 继承自视频编解码：AVIF 基于 AV1 视频编解码架构，其编码器操作于整数样本缓冲区（通常为 8、10 或 12 位 YCbCr 数据），高效压缩样本但不真正理解其颜色测量意义。
  • 硬件历史包袱：源于早期数字视频系统为控制内存和成本而采用低位深及色度子采样（如 4:2:0），这些限制被固化到编解码设计中。
  • 模式僵化：处理 8 位图像时优化 8 位量化表，处理 10 位 HDR 时则需不同编码策略和优化，本质上是不同模式。编解码器需在每一步都知晓位深。
  • 感知盲区：编码器本质上“盲目”，对数值进行有损压缩，却不知这些数值代表 HDR 场景中的细微阴影梯度还是标志中的平面颜色。它解决数字精度问题，而非感知保真度问题。

JPEG XL 的关键创新

  • 亮度目标代替位深：使用“强度目标”（默认 255 尼特）来定义纯白（1,1,1）应呈现的亮度。现代显示器远超此值（如 HDR 显示器常超 1000 尼特）。调整强度目标即可适配不同内容，无需切换位深模式。
  • XYB 感知颜色空间：所有有损压缩均在 XYB（绝对感知驱动的颜色空间）中进行。无论输入颜色空间如何（如 sRGB、Display P3），编码器均先转换至 XYB，从而基于人眼视觉敏感度智能分配比特，优化感知质量而非数字精度。
  • 统一优化：同一编解码器、工具和优化策略，仅通过调整感知目标即可应对不同显示条件。

实际影响与优势

  • HDR 与暗场景处理：传统 8 位编码在暗部细节不足，且未考虑人眼适应能力。JPEG XL 可通过调整强度目标模拟更亮观看环境，从而分配相应精度。
  • 面向未来与简化工作流：JPEG XL 解放了数十年来数字精度与感知质量混淆的积累，专注于“在任何显示器上对所有人看起来如何”，而非“每通道多少位”。对摄影师、网页开发者、档案管理员等重视图像质量与跨显示设备一致性的人群尤其有益。

结论

JPEG XL 忽略位深并非疏忽，而是摆脱历史包袱的革新设计，标志着从数字精度指标向感知质量指标的转变。AVIF 受限于其视频编解码基因，仍依赖整数样本缓冲区和位深特定优化路径，擅长网络规模视频流，但解决的是与 JPEG XL 不同（且可能次要）的问题。

39. FlightAware Map Design (2024) (andywoodruff.com) 101 points | 24 comments | by marklit

FlightAware 2024年新地图设计概述
FlightAware于2024年推出全新重构的飞行追踪地图，其底图设计基于矢量瓦片技术，替代了原有的栅格与矢量瓦片混合方案。新地图由公司自主构建数据集以满足特定需求，不再依赖第三方托管服务。

核心升级与设计重点

  • 机场细节增强：机场视图大幅改进，详细展示航站楼、登机口、道路等设施，并叠加地面航班动态信息。
  • 数据源处理：以OpenStreetMap（OSM）数据为主，在中低缩放级别结合Natural Earth数据进行过渡。通过Apache Baremaps平台定制化处理OSM数据子集，并优化标签筛选与图层组合。
  • 矢量样式设计：在保留旧版地图深色低对比度风格的基础上，重新设计矢量瓦片样式，兼顾飞行追踪的全局方位辨识（如航班位置与航线）与机场地面情境可视化。
  • 功能优化：为降低数据体积以适应机舱座椅屏幕等场景，地图刻意简化了非机场区域的道路与地物信息，突出重点的同时提升加载效率。

技术实施与挑战
作者负责提供数据层级规划、OSM数据过滤与样式设计咨询，与团队协作解决了OSM数据复杂性带来的处理难题。新地图已逐步应用于FlightAware网站、应用及合作航空公司的机舱显示屏中。