2024-06-04

47 篇热帖

1. Hacking millions of modems and investigating who hacked my modem (samcurry.net)

这篇文章讲述了作者一次偶然发现自身网络流量被未知IP地址拦截重放的离奇经历,进而展开的一系列调查,最终发现了美国互联网服务提供商(ISP)Cox Communications的一个重大安全漏洞,该漏洞可能影响了数百万用户的调制解调器设备。

事件起因与初步调查 作者在工作中发现自己发往AWS服务器的HTTP请求在几秒后被一个未知的IP地址(159.65.76.209)完全重放。测试不同设备(电脑、手机)和不同云服务商(AWS、GCP)后,确认问题源头在于其家用调制解调器或ISP网络。查询该IP地址发现其曾用于托管针对南美一家网络安全公司的钓鱼网站,并可能关联邮件服务器域名。因设备是租赁的,作者在ISP门店被迫上交旧调制解调器并更换新设备后,异常流量重放现象停止。

多年后的新发现 近3年后,作者与朋友重新调查。通过分析关联的域名模式,他们发现该IP地址指向的域名(如limit742921.tokyojingoism44769.xyz)符合恶意软件使用的域名生成算法(DGA)特征,暗示该IP很可能是一个用于控制受感染路由器的命令与控制(C&C)服务器

发现Cox Business门户网站漏洞 作者将调查转向ISP的管理工具。他假设黑客可能攻击了ISP内部用于远程管理客户设备的系统。通过分析Cox Business门户网站的前端代码,作者发现其核心API路径(/api/cbma/)是一个反向代理,后端运行的是Spring框架。

关键技术发现与漏洞利用

  1. Swagger API文档泄露:通过URL编码技巧(在.js文件后附加%2f),作者绕过了静态资源路由限制,访问到了完整的Swagger API文档,发现有超过700个API端点,涵盖账户、设备、账单、语音等广泛功能。
  2. 授权绕过漏洞:测试发现,许多需要授权的API端点(如客户资料搜索),只需简单地重复发送同一个未授权的HTTP请求,最终就会得到成功的200响应。这使得未经授权的访问成为可能。
  3. 完整的攻击链实现
    • 信息搜集:通过客户姓名搜索,可获取其账户唯一标识符(GUID)。
    • 获取设备信息:利用账户GUID,可查询该账户下所有连接设备的MAC地址、型号、序列号等详细信息。
    • 设备控制:最关键的发现是,通过一个需要encryptedValue参数的API(用于更新设备设置,如WiFi密码),作者发现该参数的验证存在缺陷。他只需要目标设备的MAC地址,即可构造一个有效的加密值,并成功向该设备发送配置更新命令。作者通过将自己的WiFi名称改为“Curry”并导致网络重启验证了这一点。

漏洞影响与修复 该系列漏洞意味着,一个完全外部的攻击者无需任何前提条件,就能够:

  • 搜索并获取Cox商业客户的个人信息(包括FBI现场办事处等敏感客户)。
  • 查询任意客户设备的MAC地址及连接设备。
  • 对数百万台通过Cox网络管理的调制解调器执行命令、修改设置,获得相当于ISP技术支持人员的权限。 Cox在收到报告后迅速下线了有漏洞的API端点(6小时内),并随后修复了授权问题。

结论与未解之谜 作者披露的漏洞揭示了ISP与客户设备之间信任层的安全缺陷。尽管此次发现的API漏洞被快速修复,但作者最初的个人调制解调器被入侵事件(发生在2021年,早于该漏洞服务上线2023年)的具体原因仍是未解之谜。攻击者重放流量的目的也令人费解。

3. I am sick of LeetCode-style interviews (nelson.cloud)

摘要:厌倦LeetCode风格面试的作者自述

背景与现状
作者于2023年11月因健康原因离开Robinhood职位后,开始参加各种面试。在此过程中,作者对LeetCode风格的面试感到极度厌倦,认为这类面试无法真实反映软件工程师的实际工作职责。

批评要点

  • 不切实际:大多数公司采用LeetCode面试仅仅是因为模仿大型科技公司(如Google、Facebook/Meta、Amazon)的做法,而非基于实际岗位需求。
  • 荒谬性:面试要求候选人记忆可轻易通过Google查询的知识,这与工程师所建议的“不要死记硬背”相矛盾,显得不合理且脱离现实。
  • 个人经历:作者在LeetCode面试中既有成功也有失败,但失败经历并未影响其观点;相反,是多年的专业经验(如AWS、Kubernetes、Ruby on Rails)促使他形成这一批评。

观点与现状

  • 作者认为LeetCode面试存在根本问题,但承认自己尚无解决方案。
  • 面试模式无法评估真实工程能力,导致招聘过程与岗位需求脱节。

后续行动与资源

  • 作者发出邀请:如果需要具备AWS、Kubernetes和Ruby on Rails经验且避免使用类似LeetCode测试的软件工程师职位,欢迎联系。
  • 文章提及进一步讨论,包括Hacker News上的相关话题和重新设计技术面试以重视经验而非考试技能的倡议。
5. Win for copyright user rights in Canada: Digital locks do not trump fair dealing (www.michaelgeist.ca)

加拿大版权用户权利胜利:数字锁不凌驾于公平使用之上

加拿大联邦法院在“Blacklock’s Reports诉加拿大总检察长案”中作出里程碑式裁决,认定数字锁(digital locks)不应凌驾于公平使用(fair dealing)之上。两者必须和谐共存,用户即使在涉及数字锁的情况下,仍可依赖公平使用原则。这一裁决对图书馆、教育领域及更广泛的用户群体具有重大影响,旨在恢复数字世界中的版权平衡。

背景与争议

2012年《版权现代化法案》引入了反规避措施,以符合世界知识产权组织互联网条约的要求,为数字锁提供法律保护。这些措施旨在防止规避技术(如电子书或DVD上的防复制技术),但引发广泛争议,因为担忧它们会破坏版权平衡——即在保护创作者权益与确保公众公平访问之间取得平衡。最高法院曾确立公平使用是用户权利,与创作者权利相平衡,但反规避规则可能被版权持有者利用技术限制用户的合法使用。

案例详情

本案源于Blacklock’s Reports(一家付费新闻服务机构)与加拿大政府部门之间的长期诉讼。Blacklock’s指控其文章在政府内部超许可范围分享,侵犯版权。此前,联邦法院已在2016年裁决中支持公平使用,允许文章在合理范围内分享。最新裁决涉及15篇分发给加拿大公园管理局媒体人员的文章,法院再次认定公平使用适用,并批评Blacklock’s的许可条款混乱。

数字锁与密码的核心问题

Blacklock’s主张其内容受密码保护,密码构成技术保护措施(TPM),规避密码本身即构成侵权,且公平使用不适用。联邦法院全盘否定了这一观点,指出:

  • 密码不构成TPM:TPM必须是有效控制访问的技术、设备或组件,而密码仅是一种访问控制,不具技术保护特征。
  • 合法获取的密码不构成规避:使用合法获得的密码访问内容不属于规避行为,公平使用权利依然有效。
  • 法院强调,分享密码并非无条件免责,但密码获取方式可能影响公平使用的适用性。

裁决关键点

法院重申版权平衡的重要性,并指出:

  • 公平使用优先:TPM条款不能剥夺公平使用权利,公平使用是版权法的基石,始终可用。
  • 立法意图:国会未明确授权数字锁完全取代公平使用,因此裁决必须维护版权平衡。
  • 技术标准:版权持有者若依赖反规避规则,必须使用真正的TPM(如防复制技术),而非简单密码。

影响与意义

这一裁决恢复了加拿大版权法中的用户权利,确保在数字环境下,公平使用原则不被技术保护措施侵蚀。它为图书馆、教育机构和用户提供了法律保障,允许在合理范围内绕过数字锁进行合法使用。同时,裁决提醒版权持有者需谨慎使用技术保护,不能仅以密码来强化控制。

尽管案件可能上诉,但当前裁决为加拿大版权实践确立了重要先例,平衡了数字时代的创作者权益与公众访问权。

6. Encryption at Rest: Whose Threat Model Is It Anyway? (scottarc.blog)

静态加密:到底是谁的威胁模型?

这篇文章探讨了Web应用和云服务中静态加密的实际应用,重点指出许多开发者对其威胁模型理解不足,导致加密措施可能沦为“安全剧场”。

核心问题与背景

  • 在AWS加密团队的经历显示,静态加密的威胁模型常被忽略
  • 开发者通常未清晰理解面临的风险,以及加密如何保护数据。
  • 磁盘加密(FDE)仅能防护硬盘被盗或丢弃时的数据泄露,无法防御在线攻击(如SQL注入)。

静态加密的类型与挑战

  • 客户端加密:在应用层加密数据后再存储,比磁盘加密更安全,但实现细节至关重要。
  • 假设的典型架构:用户→应用服务器(管理密钥、加密/解密数据)→数据库(存储密文)。
  • 关键问题:密钥管理(建议使用云服务如AWS KMS)和加密模式选择。

加密技术与攻击风险

  • 应使用AEAD模式(如AES-GCM、XChaCha20-Poly1305),避免CBC或ECB等不安全模式。
  • 混乱代理攻击:数据库管理员可复制用户A的密文,替换用户B的密文,通过应用解密获取A的明文数据。攻击简单且有效。
  • 防护措施:使用AAD(关联认证数据)将密文与上下文(如用户ID、主键)绑定,确保解密时验证上下文。

实例与演进

  • CipherSweet库的教训
    • 初期通过不同字段使用不同密钥缓解风险,但若AEAD模式不支持密钥承诺,仍可能被绕过。
    • 后续版本引入密钥承诺机制(如BoringCrypto使用BLAKE2b-MAC)。
    • 最新版本(4.7.0)通过setAutoBindContext(true)自动绑定主键,简化上下文绑定操作。

为何现状不理想?

  • 问题常未被广泛认知或理解。
  • 开发者缺乏统一威胁模型,导致安全需求不一致。

建议与结论

  • 核心原则:验证访问模式,使用AAD绑定上下文。
  • 鼓励开发者进行威胁建模,向供应商询问对混乱代理攻击的防护措施。
  • 威胁模型因场景而异,本文聚焦Web/云应用,其他场景(如设备盗窃、政治风险)需单独讨论。

总结:静态加密需明确威胁模型,客户端加密应选择AEAD模式并绑定上下文,以防范基本的混乱代理攻击。开发者应提升安全意识,通过正确实施加密真正保护数据。

7. If English was written like Chinese (1999) (zompist.com)

本文通过构想英语采用类似汉字的书写系统(称为“英字”),类比说明了中文汉字的结构与运作原理。主要内容如下:

  1. 两种方案:直接使用汉字(如日语做法)存在读音和专有名词处理难题,因此提出创造一套适合英语的“英字”系统,原则是一个音节对应一个特定意义的字符。

  2. 基本构建

    • 以象形字(如马、山、王)和会意字(如东、罪)为基础。
    • 核心机制是语音部首系统:以一个基础字符为“声符”,代表一组押韵的音节,再通过添加有限的部首(共214个,来源于基本字符或其简写)来区分意义。例如,声符“王”(king)加上不同部首可衍生出“king”、“thing”、“sing”等。
    • 部首既区分发音,也暗示意义类别(如“虫”部多与昆虫相关),但由于数量有限且选择有时基于词源(如“villain”原指农民,故用“田”部),这种意义关联可能模糊或奇特。
  3. 系统扩展

    • 多音节词:将词按语素拆分,每个音节对应一个英字。同一语素的各音节通常共享相同部首(如“person”)。
    • 词缀:非音节的词缀(如复数 -s)通过添加小标记表示(如在表示“is”的字符上加点表示-s)。
    • 外来词:近期借用的词逐个音节用现有最接近的英字表示(如“Fellini”)。
  4. 查检与认知影响

    • 字典按部首的笔画数排列,每个部首下再按额外笔画数排列字符。
    • 该系统会促使人们将语言视为由英字组合而成,弱化传统“单词”概念,更强调字的内部结构与组合。可能导致“图形词源学”的误判(如误以为“person”与“son”有关),并可能引发复合词的缩写(如“语言”一词可能最终只用一个字表示)。
  5. 类比目的:全文旨在通过构建“英字”系统,揭示汉字的本质特征:绝大部分为形声字(声符表音,部首表义);部首数量有限,信息含量低于声符;字典按部首和笔画编排;书写系统对语言思维有深刻影响。

  6. 与现实汉字的差异:作者指出,为简化说明,“英字”系统忽略了现实汉字的一些复杂性,例如:古今语音变化导致声符表音不准、字符历史演变、书写风格简化、以及不同地区的简化字差异等。此外,英语多音节语素和大量借用词比汉语更复杂,使得该系统在应用于英语时会更具挑战性。

8. Intel's Lion Cove Architecture Preview (chipsandcheese.com)

调度器分离设计

Lion Cove 最重大的改变是将统一数学调度器拆分为 6端口整数调度器4端口向量调度器,调度器槽位总数约为上一代的两倍。此设计带来两大核心优势:

  1. 提升能效:可独立对未使用的向量调度器进行时钟门控,从而降低整体功耗或将电力重新分配以提升其他模块频率。
  2. 简化设计:分离后,向量调度器专注处理3操作数指令和掩码,而整数调度器仅处理2操作数指令且无掩码,彻底避免了统一调度器在扩展端口时面临的极高硬件复杂度。

缓存层级重构

Intel 重新标记了缓存层级并引入新的中间缓存:

  • L0 缓存:原 L1 改称 L0,延迟降至 4 周期(恢复至 Skylake 水平),保留较大容量,带宽 128B/周期。
  • L1 缓存:新增 192KB 中间缓存,延迟 9 周期,作为 L0 与 L2 间的缓冲,带宽同为 128B/周期。
  • L2 缓存:容量增至 3MB,延迟仅微增 1 周期至 17 周期。在 Lunar Lake 中,为节省功耗和面积,L1 到 L2 的带宽被限制为 64B/周期。

超线程移除与架构定制化

在 Lunar Lake 产品中,Lion Cove 物理移除了超线程(Hyperthreading)组件。此举不仅减小了芯片面积,还大幅简化了 Thread Director 的调度逻辑(仅需分配 P-Core 和 E-Core)。得益于向“Sea of Cells”设计转变,Intel 现可针对特定产品高度定制架构,未来的 Arrow Lake 或服务器 CPU 仍可按需保留超线程支持。

前后端与执行单元升级

  • 前端:取指带宽增至 48 Bytes/周期,Uop 缓存增大,分支预测优化,以喂饱更宽的后端。
  • 乱序引擎:核心解码宽度从 6-wide 增至 8-wide,重排序缓冲区(ROB)增至 576 条目。
  • 整数执行:ALU 增至 6 个,整数乘法单元从 1 个增至 3 个,首次实现单周期多次整数乘法。
  • 向量执行:SIMD ALU 增至 4 个,新增第二个浮点除法器,并优化了除法操作的吞吐量与延迟。
  • 内存子系统:L1 DTLB 容量增至 128 条目,新增第 3 个支持存储寻址的 AGU。

性能提升与设计理念转变

通过上述结构性优化,Lion Cove 实现了 14% 的 IPC(每时钟性能)提升。其最重要的意义在于设计理念的转变:高度可定制化的架构使 Intel 能够针对未来不同产品线的特定需求,更精准地优化 P-Core 设计。

9. The long-lost Tarzan Atari game, preserved (gamehistory.org)

遗失的《泰山》Atari游戏重见天日

这篇文章详细介绍了为Atari 2600开发但从未发行的《泰山》游戏被重新发现和保存的过程。

游戏背景与开发

  • 发布时间线:游戏最初计划于1983年随电影《格雷斯托克:泰山传奇》上映同步发行。ColecoVision版于1984年8月发布并获得好评,但Atari 2600版在开发完成后因市场崩溃而被取消。
  • 开发团队:游戏由新泽西的设计公司James Wickstead Design Associates(JWDA)为Coleco开发。主要开发者包括程序员Henry Will IV、艺术家Robin McDaniel Ballweg和音效设计师Todd Marshall。Coleco方面则由设计师Lawrence Schick和Phil Taterczynski负责监督。
  • 设计核心:游戏是一个多屏幕的横向卷轴动作冒险,玩家控制泰山奔跑、跳跃、攀爬、游泳和战斗,以从猎人和Opar兽人手中拯救被囚禁的猿猴朋友。设计上必须遵守埃德加·赖斯·巴勒斯遗产协会的规定:泰山不能死亡,因此游戏被设计为基于时间限制。
  • 技术挑战:作为一款16KB的游戏,它使用了当时不常见的bankswitching技术来突破Atari 2600硬件的内存限制。JWDA为其开发了独特的bankswitching方案。

游戏内容

  • 玩法:每个屏幕都有不同的挑战和敌人(如猎人、巨猿、毒蛇、鳄鱼)。玩家需要运用各种动作通过障碍,最终在悬崖边拯救被用锁链放下的囚禁猿猴。
  • 难度:游戏有四个难度等级,增加了需要通过的屏幕数量。时间是关键要素,泰山被击晕时时间会加速流逝。

市场崩溃与游戏命运

  • 市场崩溃:1983年北美游戏市场崩溃是导致游戏被取消的主要原因。过度生产、价格战和消费者信心丧失摧毁了整个行业。
  • Coleco的困境:Coleco因同时推出有缺陷的ADAM电脑而遭受重大损失,最终于1985年停产ColecoVision。Atari也被出售。
  • 开发团队的影响:JWDA在市场崩溃后离开游戏行业,Coleco也大幅裁员。许多开发中的项目被悄悄取消。

重新发现与保存

  • 发现过程:2022年,收藏家Rob "AtariSpot"从一名前Coleco员工处购得了一个可运行的游戏卡带。
  • 技术保存:Atari家自制游戏程序员Thomas Jentzsch帮助将游戏数据从原始卡带中转储出来,并将其修改为标准的“F6” bankswitching方案,使其能在模拟器和闪存卡上运行。两个版本都已公开。

历史意义

  • 时代见证:《泰山》是当时美国游戏开发者创造力和专业性的代表,却因市场崩溃而未能面世。它的重见天日为1983-1984年的游戏开发提供了珍贵的实物证据。
  • 行业反思:文章将当前游戏行业的裁员浪潮与1980年代的崩溃相提并论,强调了游戏历史保存工作的重要性。像《泰山》这样的失落项目提醒人们,许多辛勤工作的成果可能永远无法被玩家体验。
10. Oldest largest German Minecraft server shut down and open sourced everything (github.com)

德国最古老最大的 Minecraft 服务器 MuxCraft 关闭并开源所有内容

基本信息

  • 服务器状态:已于 2023 年 7 月关闭,此前自 2012 年 3 月起运营,拥有超过 413,165 名玩家。
  • 定位:德国最成功的 Minecraft PvP 服务器。
  • 开源内容:所有服务器文件与地图均上传至 Archive.org 可供下载。
  • 官方渠道:网站 muxcraft.eu、YouTube、Discord 与联系邮箱均在公告中列出。

核心功能模块

经济与商店系统

  • GemShop:支持玩家在游戏币(Coins)与宝石(Gems)间兑换,用于购买物品、等级等。
  • 玩家商店:类似股票市场的可视化商店,动态追踪物品价格、供需变化及交易量。
  • 高级市场:用户友好的拍卖行。
  • 挖矿系统:野外挖掘矿石获得游戏币,奖励经通胀调整。
  • 交易系统:提供安全的交易界面,防止欺诈。

基地系统

  • 支持创建、重置基地,并可邀请好友。
  • 闲置机制:基地闲置 72 小时后可被“掠夺”。
  • 基地价值根据商店中区块价格自动计算,并设有基地排行榜。
  • 提供基地参观、保存为示意图(需 GOLD 等级)、每日投票延长基地等功能。

性能与反作弊

  • 反延迟系统:全自动监测 TPS,管理实体、物品掉落、红石优化等。
  • 机器人检测系统:通过验证 GUI 检测 VPN、自动附魔、挖矿机器人,并能识别聊天机器人(误报率为 0%)。

游戏娱乐

  • 赌场:提供老虎机、轮盘、二十一点等多种现实赌场游戏,设有能量系统及特殊区域。
  • 活动系统:自动化举办聊天、常规及大型活动(如竞技场、迷宫、生存游戏等),奖励经通胀调整。
  • 额外内容:包含永久药水效果、自行车、表情头像、坐骑、宠物、增益工具、宝箱等丰富元素。

社交与玩家管理

  • 好友与氏族系统:支持好友添加、氏族创建与管理,含专属聊天与排名。
  • 聊天系统:具备智能防刷屏、自适应黑名单、IP 过滤等功能。
  • 玩家菜单:根据进度与等级动态显示,包含设置、管理员选项等。

PvP 与竞技

  • 1v1 与氏族战:提供竞技场系统,支持随机套件、自定义设置。
  • 训练系统:可生成具有自定义路径与行为的 PvP 机器人。
  • 赛季与排名:设有 PvP 数据统计、奖杯系统及每月赛季。

管理与工具

  • 团队管理:包含管理菜单、惩罚系统、聊天过滤、玩家总览、支持票务系统等。
  • 实用工具:虚假雪景、计分板管理、NPC、全息图、烟花效果、修复重复漏洞等。

技术构建指南

  1. 构建环境:使用 IntelliJ IDEA 的 Artifact 系统构建 JAR 文件。
  2. 步骤
    • 创建空 JAR Artifact。
    • 将项目编译输出及依赖库(如 Client、Server、Shared、邮件、JSON、HTTP 库等)提取至输出根目录。
    • 执行 Build Artifacts 生成插件文件。
  3. 部署
    • 将生成的 JAR 文件与 MuxSystem 文件夹上传至服务器 plugins 目录。
    • 根据需要调整配置文件。
  4. 数据库配置
    • 编辑 src/main/java 目录下的 config.yml 文件。
    • 设置 MySQL 数据库的用户名、密码及连接 URL(支持多服务器共享数据库)。

许可证

该项目为自由无限制软件,可任意使用、修改与分发。

11. Show HN: Allocate poker chips optimally with mixed-integer nonlinear programming (github.com)

项目概述

Poker Chipper 是一款用于优化现金扑克游戏筹码面额分配的工具。在传统的扑克游戏中,手动选择筹码面额往往繁琐、易错且难以达到最优。该工具允许用户输入玩家数量、买入金额、盲注和筹码总数,通过数学优化算法快速计算出最优的筹码分配方案,并支持保存、分享或通过高级选项进行微调。

核心功能与工作原理

  • 优化算法:采用混合整数非线性规划(MINLP),这是一种受约束的非凸优化方法。
  • 求解器机制:底层使用 SCIP 求解器。用户的输入被转化为影响候选面额“要求”的约束条件,以及影响面额评估和排名“得分”的目标函数。
  • 纯客户端计算:Poker Chipper 是一个完全静态的 Web 应用,所有优化计算均在用户的浏览器端完成。项目通过 Emscripten 将原生的 SCIP 求解器编译为 WebAssembly (WASM),从而实现在浏览器中高效运行。

技术架构与代码结构

项目采用纯前端架构,各模块通过异步请求和消息传递进行通信:

  • 前端界面:基于 Svelte 构建(src/App.svelte 及 UI 组件),负责用户交互。
  • 核心计算src/solve.js 负责将用户输入转换为 MINLP 模型并调用 WASM SCIP 求解;src/solveWorker.js 作为 Web Worker,确保求解过程在非阻塞线程中运行,避免界面卡顿。
  • 离线与缓存public/serviceWorker.js 提供 Service Worker 支持,实现静态资源的缓存和离线访问(PWA 功能)。
  • 实验与编译experiments/ 目录包含早期使用 Python (Z3/SCIP) 的概念验证及编译 SCIP 的 Dockerfile;src/compiled/ 存放编译好的 WASM 文件及相关支持文件。

项目状态与贡献指南

  • 维护状态:项目代码稳定,无重大待开发功能。由于是纯静态应用,无服务器端处理逻辑,具有极高的可扩展性和极低的维护成本,能够长期稳定在线。
  • 贡献规则:鼓励通过 GitHub Issues 提交 Bug 报告和功能请求。对于超过 20 行代码的 Pull Request,要求必须伴随事先讨论或详尽的说明,否则可能被延迟合并或拒绝。
  • 支持方式:作者鼓励通过社交媒体分享、报告 Bug、Star 项目或托管多语言版本来支持项目。若需资金捐助,建议捐赠给电子前哨基金会 (EFF)、互联网档案馆、Signal 基金会或 Mozilla 等对公众有益的组织。
12. Research as leisure activity (www.personalcanon.com)

“研究作为休闲活动”:一种超越学术的智识探索

本文的核心源于图书馆员Karly Wildenhaus对网站Are.na的描述:“研究作为休闲活动”。作者认为,这不仅精准描述了该平台(一个供艺术家、研究者等私下或协作保存图文、链接等内容的“频道”系统),更深刻地揭示了优秀软件产品的本质:它们不仅提供功能,更塑造思维方式和生活方式。

作者进而阐述了广义的“研究”定义,并强调“研究作为休闲活动”是其特别动人的形态。

研究的通用定义(跨学科基础):

  1. 始于提问:源于探索未知、贡献知识与文化的渴望。
  2. 依托证据:无论是科学实验的定量分析,还是人文领域对原始文献的定性审读,都需追求某种真实与准确,并承认其局限性。
  3. 植根学科传统:研究者需了解所在学科的历史、理论与实践,通过文献综述在既有知识体系中定位自己。
  4. 产出成果:研究不止于收集与综合,需以会议、论文、书籍等形式推进新论点与思想。
  5. 应具当代相关性,但不局限于当下:研究应回应紧迫议题,但也需重视看似无直接应用价值的基础研究(如mRNA疫苗技术曾长期被视为冷门)。
  6. 依托社群:通常需要导师、同行与后辈构成的智力社区提供支持与视角。

“研究作为休闲活动”的特质:

  1. 由激情与本能驱动:高度个人化,追随当下兴趣,允许主题间跳跃,适合享受“涉猎者”角色的人。
  2. 反学科的、不拘一格的:不受狭隘专业训练的束缚,可以从任何学科中汲取有趣的思路、工具与方法。
  3. 保持必要的严谨:可以忽略某些学术规范(如详细脚注、伦理审查),但其严谨性并不必然低于有时也产出低质研究的专业科学。
  4. 实践者广泛:包括艺术家(如利用Are.na开发主题的Laurel Schwulst)、广泛阅读并发布的博主(如Maria Popova)、准学术研究者(如独立研究实验室的Geoffrey Litt)、以写作为天职的文化评论家,以及互联网上那些源于微小兴趣最终深入广阔文化议题的自学者。他们往往从具体(如研究束身衣)出发,连接到性别、贸易、殖民等宏大主题。
  5. 带来深刻的愉悦与生命意义:它描述了一种以阅读、学习、写作和思想协作为乐的生活,将研究融入休闲,由好奇心引领,在个人兴趣与人类更大图景间建立联系。

文中还提及了与“研究作为休闲活动”精神相通的艺术实践(如Mieko Shiomi的活动诗、Fluxus运动的Alison Knowles的参与式作品),以及关于生活中巧合与模式的文化观察(如Meghan O'GieblynLauren Berlant的相关论述),这些内容进一步扩展了“研究”在广义上的创造性与文化意义。

13. Why YC went to DC (www.ycombinator.com)

文章总结

本文由Y Combinator(YC)总裁兼CEO Garry Tan撰写,阐述了YC前往华盛顿特区(DC)与政策制定者会面的动机和目的,旨在倡导支持“小科技”(即新兴初创企业)在人工智能(AI)时代的发展。

背景与问题:过去几十年,大型科技公司因缺乏监督而导致社交媒体危害、反竞争行为等问题。当前在AI领域,华盛顿有重复这些错误的风险,政策可能过度偏向大公司,抑制创新。

YC的DC之行:Garry Tan代表YC社区与两党领袖和白宫官员会面,讨论关键政策议题,包括开源AI的重要性、通过移民获取人才、通过反垄断行动促进市场开放,以及消除非竞争条款。目的是让初创企业的声音在政策制定中被听取。

YC社区现状:YC目前拥有11,000名创始人和5,000家初创企业,覆盖美国几乎每个州。2024年将从50,000份申请中资助超过500家公司,其中绝大多数与AI相关。这些初创企业是推动AI创新和广泛受益的关键力量。

AI的潜力与挑战:AI有望改善生活,如应对气候变化和降低医疗成本。但实现这些好处需要为初创企业提供发展空间。政策制定不能只关注大公司,否则会扼杀新兴企业。

具体政策建议

  • 优先开源AI模型:开源模型促进透明度、协作和创新,而闭源模型(常被大公司采用)可能限制竞争和集中权力。政策应支持开源发展,避免过度管制。
  • 加强反垄断行动:推动大型企业提高互操作性,防止自我偏好,恢复市场竞争和创新。类似“美国创新和选择在线法案”的措施应被重新考虑。
  • 禁止非竞争条款:支持FTC(联邦贸易委员会)禁止所有员工非竞争条款的做法,帮助创始人建立新公司,颠覆现状。

呼吁:文章强调,美国建立在个人主义和机会平等的基础上。在AI新时代,政策应为小科技创造成功机会,制定促进公平、开放和竞争市场的AI法规。忽略初创企业的视角将是一个严重错误。

14. Go east from Seattle (finmoorhouse.com)

从西雅图向东走:地理与几何谜题解析

谜题与答案

文章提出了一个地理谜题:从美国西雅图出发,面朝正东,沿地球表面一直“直线”前进,离开北美洲后到达的第一个国家是哪里? 答案是:澳大利亚

核心原理:大圆与测地线

谜题的“陷阱”在于对球面“直线”的理解。在球面上,“直线”的最合理定义是大圆(Great Circle),即测地线(Geodesic),代表曲面上两点间的最短路径。

  • 等纬度线并非直线:若始终保持正东方向(纬度不变),实际上需要不断向左转向。除赤道外,等纬度线不是大圆,因而不是球面上的直线。
  • 实际路径:从西雅图出发的大圆路径会跨越南北半球,绕过非洲南部,最终抵达澳大利亚(珀斯附近)。在地球仪上拉紧一根从西雅图向东延伸的绳子即可直观验证此最短路径。

地图投影的视觉误导

直觉上容易误答“法国”,主要归因于常见二维地图投影(如墨卡托投影)的视觉误导:

  • 在常规地图上,等纬度线看似笔直,而大圆路径显得弯曲。
  • 仅在心射切面投影(Gnomonic projection) 中,球面上的大圆才会显示为真正的直线。

补充探讨:测地线的严谨定义

  • 曲面与三维空间:有人提出三维空间中的直线会飞向太空,但题目明确限制为“沿地球表面”前进,因此讨论的是球面测地线。
  • 定义的争议:若将“直线”定义为在特定二维投影(如墨卡托投影)上呈直线,则等纬度线可算作直线(此时答案为法国)。但作者认为“保持向前不改变方向”是更自然、更符合直觉的理解。
  • 地球形状误差:地球并非完美球体,而是扁球体(极半径比赤道半径短约0.3%),但这微小的形状偏差不足以改变最终到达澳大利亚的结论。
16. Feynman Computer Science Lecture – Hardware, Software, Heuristics (1985) [video] (www.youtube.com)
17. Sphere Rendering: Flat Planets (emildziewanowski.com)

球面渲染:扁平行星的技术方案

背景与挑战

为球体贴纹理看似简单,实则暗藏诸多难题。作者在项目中需要为天空盒创建气态巨行星和卫星,二者均需自转,气态巨行星还需动态大气纹理。传统UV球体方案面临一系列问题:网格边缘锯齿、纹理采样效率低、极点存在扭曲、存在明显接缝、无法在同一网格绘制大气光环。

核心解决方案:扁平圆盘

放弃复杂3D球体网格,改用扁平圆形多边形网格。该方案的关键优势在于:

  • 性能优化:天空盒中行星距离远且视角固定,无需复杂网格。
  • 纹理映射灵活:通过像素着色器(Pixel Shader)精确控制纹理映射。
  • 集成大气渲染:可在同一网格上绘制大气光环。

像素着色器实现关键技术

1. 表面方程

  • 使用解析方程在着色器中定义球面。
  • 通过UV向量长度判断像素是否在圆盘内。
  • 重建球面Z坐标:z = sqrt(1 - x² - y²)

2. 纹理映射

  • 数学原理:将2D圆盘坐标映射到3D球面,涉及环绕圆柱、形成圆形等步骤。
  • UV生成函数:通过反正弦函数将表面位置转换为UV坐标。
  • 方向控制:允许行星轴倾斜(俯仰和翻滚),使用3×3旋转矩阵。
  • 自转实现:通过平移纹理U坐标而非旋转网格来模拟自转,避免接缝问题。
  • 缩放与接缝处理:通过分象限偏移将接缝隐藏到行星背面。

3. 着色与光照

  • 法线:表面位置本身即为法线(当半径=1时)。
  • 光照模型:采用简单的兰伯特光照(表面法线与光向量的点积)。
  • 法线贴图:在像素级别计算切线、副切线、法线(TBN矩阵)以支持凹凸贴图。

4. 解决极点问题

  • 极点贴片:在行星两极覆盖特殊纹理(如冰盖),既隐藏扭曲又增加视觉趣味。
  • 极点校正:通过调整UV的Y坐标来修正纹理的极点挤压。

5. 大气层渲染

  • 创新方法:借鉴《雷神之锤》的思路,用行星表面的光照信息近似模拟大气光晕。
  • 实现技巧:扩展表面法线计算大气亮度,并对不同通道进行重映射以模拟光线吸收。
  • 渐变效果:通过表面法线的Z分量和到球面的距离来控制大气的可见性和衰减。
  • 混合:最终将表面纹理与大气层进行Alpha混合。

总结

该方案通过像素着色器完全替代传统球体网格,成功解决了UV球体的所有固有问题。最终效果是一个视觉上完美的球体,支持复杂的纹理和着色操作,允许使用较小尺寸的动态纹理以提升性能,且无需复杂的后处理。该技术方案在保持艺术风格的同时,实现了高度的灵活性和性能优化。

18. New telescope images of Jupiter's moon Io rival those from spacecraft (phys.org)
21. The Moral Economy of the Shire (nathangoldwag.wordpress.com)

《夏尔的道德经济学》摘要

政府结构与税收

夏尔(The Shire)的政府极度精简。法律上,它是由亚尔诺国王授予霍比特人的自治领地,需维护桥梁道路并承认国王为领主。阿诺王国覆灭后,夏尔设立了世袭的“大统领”(Thain)一职,但主要具有礼仪性质。唯一重要的选举官职是米歇尔戴尔文市长,每七年选举一次,兼任邮政局长和治安长官,管理邮递员和治安员(主要负责找回走失牲畜和阻止外人进入)。

由于缺乏庞大的官僚机构,夏尔很可能几乎没有直接税收。政府运作可能依靠桥梁道路通行费、关税或精英家族的自愿馈赠。

社会经济结构

夏尔并非纯自给自足经济。它拥有磨坊、全职工匠、酒馆和经济作物种植(如烟叶),但缺乏对外贸易和工业。其经济基础是地主贵族阶层:比尔博、弗罗多、梅里和皮平等主角均属于这一阶层。他们拥有土地和农业资本(如磨坊、牲畜、农具),通过收取地租为生,从而能享受悠闲生活。

大多数霍比特人是佃农自耕农,依赖贵族阶层。社会结构围绕家族和氏族网络运作,权力来自非正式的影响力、财富和亲属关系,而非正式官职。这导致政府无需中央集权,重大决策常在社交宴会中通过非正式网络达成。

庇护-依附关系(Clientelism)

夏尔社会的核心组织原则是“庇护关系”。地主贵族(如巴金斯家族)与依附者(如甘姆齐家族)之间存在双向义务:依附者提供劳役、租金和社会支持(如投票、展示声望);地主则提供礼物、借贷、灾荒时的宽容以及法律援助。这种关系兼具经济保障和社会安全网功能,确保在前现代农业的高风险环境中生存。

甘姆齐家族与巴金斯家族的关系是典型例子:山姆不仅是仆人,更是弗罗多的“封建随从”,双方存在深厚的情感和义务纽带。慷慨赠礼和举办宴会是霍比特人的主要活动,类似于美洲原住民的“夸富宴”,用于彰显地位和巩固联盟。

现代商业入侵与社会冲击

夏尔的传统秩序在《王者归来》结尾遭遇挑战。萨克维尔-巴金斯家族的洛索通过与萨鲁曼勾结,引入外部资本和暴力,垄断经济(如磨坊、酒馆、农场),并雇佣人类暴徒打压竞争、掠夺资源。这体现了商业资本主义对传统“道德经济”的破坏:外来势力瓦解了庇护网络,地主不再履行传统义务,导致社区陷入风险。

这一过程呼应了现实历史中的农民起义(如1930年代印度支那反殖民起义、1525年德国农民战争),其根源常是市场整合对传统社会保护机制的侵蚀,而非单纯的经济剥削。

社会变革与结局

霍比特精英领导的反叛推翻了洛索政权,但夏尔再也无法回归战前状态。山姆·甘姆齐继承巴金斯家族财富和声望,连续七届当选市长,其家族(园丁家族)通过与图克家族联姻,成为夏尔最有影响力的家族之一。这表明传统结构虽遭冲击,但新的精英阶层通过适应变化延续了影响力。

作者的分析目的

作者并非要揭露夏尔“黑暗真相”,而是借托尔金构建的理想化前工业社会模型,探讨现实历史中的政治经济学。托尔金有意描绘了一种基于传统、家族和庇护关系的农村社会,但其理想化外表下隐藏着复杂的劳工组织、财富分配和风险应对机制。通过分析虚构的夏尔,我们可以更深刻地理解现实历史中类似社会的运作逻辑、稳定性及其在现代化冲击下的脆弱性。

22. CO2 helps viruses stay alive longer in the air (www.statnews.com)

CO2 延长病毒在空气中的存活时间

传统认知与新发现

长期以来,二氧化碳(CO2)主要被视为评估室内通风状况的间接指标,通过监测其浓度来推断空气被呼吸道呼出物污染的程度。然而,英国布里斯托大学的研究团队通过新型技术发现,CO2 在延长病毒空气存活时间方面扮演着直接且关键的角色:环境中 CO2 浓度越高,病毒在空气中的存活能力就越强。

关键研究工具:CELEBS 系统

为精确研究病毒在空气微粒中的行为,Allen Haddrell 等人历时六年开发了 CELEBS(可控电动力悬浮生物气溶胶提取系统)。该技术利用压电元件生成化学成分、大小和病毒数量均一的气溶胶微粒,并通过电磁场使其悬浮,从而能在受控环境下观察单个微粒的演变,避免了传统雾化器可能带来的测量偏差和对微生物的物理损伤。

核心发现:CO2 通过维持 pH 值延长病毒活性

  1. 机制:人体呼出的呼吸道微粒中含有碳酸氢盐。在通风不良的室内,呼出的 CO2 积累,其与碳酸氢盐形成缓冲系统,使气溶胶微粒保持接近中性的 pH 值。而许多呼吸道病毒(如 SARS-CoV-2)在中性 pH 环境下稳定性较高。
  2. 实验结果
    • 在 CELEBS 系统中,微粒因水分蒸发会迅速变为碱性,导致病毒快速失活(新冠病毒在 20 分钟内失去 90% 感染能力)。
    • 传统使用旋转鼓和雾化器的方法会意外在实验环境中积累 CO2,人为维持了有利于病毒的中性 pH 环境,这可能解释了以往不同研究得出的病毒存活时间差异巨大的原因。
  3. 浓度影响:将环境 CO2 浓度升至 800 ppm(通常被认为是良好通风的基准)就能显著延长多种 SARS-CoV-2 变异株的存活时间。在更高浓度下(如拥挤、通风不良的房间),40 分钟后仍具有感染性的病毒量是清洁空气中的 10 倍

研究意义与影响

  1. 对病毒学研究的冲击:这一发现挑战了以往基于旋转鼓等方法获得的大量病毒存活数据,指出其中许多研究可能无意中因 CO2 积累而影响了结果的准确性。
  2. 对公共卫生政策的启示:研究将 CO2 的角色从单纯的通风指标转变为病毒存活的增强剂。这强调了改善室内空气质量(特别是降低 CO2 浓度)不仅是为了减少呼出物吸入,更是为了创造不利于病毒存活的环境。
  3. 引发的争议与澄清:早期预印本发布时,研究曾引发关于其是否会被误解为否定病毒空气传播的担忧。研究者后续澄清,他们的结论恰恰支持通过通风降低气溶胶病毒载量
  4. 政策倡导:研究结果为推动制定更严格的室内空气标准提供了科学依据。有专家建议,当前将 800 ppm 作为 CO2 浓度上限的建议可能仍需进一步降低。

未来展望

尽管有科学家认为病毒存活机制可能更复杂,但 CELEBS 技术正被推广至全球更多实验室。随着大气 CO2 水平持续上升以及禽流感等病毒的潜在威胁,理解病毒、人体与环境之间的相互作用变得愈发紧迫。研究团队下一步将利用该技术研究甲型流感病毒。

24. Creating a Safari webarchive from the command line (alexwlchan.net)

Safari命令行网页存档工具创建摘要

本文介绍了作者开发一个从命令行创建Safari网页存档(.webarchive)文件的Swift脚本的过程。

背景与动机

作者希望本地存档已收藏的网页,认为Safari网页存档格式具备以下优势:

  • 每个网页保存为单个文件,包含完整HTML/CSS/JS,便于管理和备份。
  • 可通过Safari界面保存无法被自动爬虫抓取的页面(如需登录或存在付费墙的页面)。
  • 存档可离线存储,保留隐私页面,且不依赖单一工具(格式为二进制属性列表,可被非Apple工具读取)。

现有工具与改进

作者发现newzealandpaul/webarchiver工具,但指出其错误信息不明确,且使用已弃用的WebView和Objective-C代码。因此决定使用Swift和现代WKWebView类重写。

技术实现关键点

  1. 使用createWebArchiveData API:该WKWebView方法可异步创建网页存档。
  2. 解决异步加载问题:在脚本环境中,需通过运行RunLoop.main循环等待页面加载和存档创建完成,避免脚本提前结束。
  3. 错误处理与状态检查
    • 实现WKNavigationDelegate协议,监控页面加载错误和HTTP状态码(如非200则终止脚本)。
    • 确保仅在页面成功加载后才创建存档,避免存档错误页面。
  4. 命令行参数支持:将URL和输出路径作为参数传入,使脚本更通用。

最终脚本功能与使用

  • 项目托管于alexwlchan/safari-webarchiver GitHub仓库。
  • 脚本可接收URL和文件路径参数,成功加载页面后生成.webarchive文件。
  • 包含错误检查(网络问题、无效URL、HTTP错误等),且默认不覆盖已有文件。
  • 作者已用该脚本成功存档约85%的书签链接。

该脚本为自动化批量保存Safari网页存档提供了实用方案,兼顾灵活性与可靠性。

25. Intel Unveils Lunar Lake Architecture (www.anandtech.com)

根据提供的文章内容,该页面并非关于“Intel Lunar Lake Architecture”的详细技术文章。实际内容是一个技术讨论论坛的板块索引列表,涵盖了CPU与超频、主板、显卡、内存与存储、显示器、电源、机箱与散热、笔记本、网络、外设与组件、电脑组装、操作系统、编程、游戏、硬件交易等多个分类,展示了各板块的帖子与消息数量。

因此,无法从当前内容中总结出关于 Intel Lunar Lake 架构的具体技术细节、目的、结构或关键功能。所提供的文本仅反映了该技术论坛的版块构成和活跃度概况。

若需了解Intel Lunar Lake架构,需要提供包含该主题实质内容的技术文章。

26. New theory suggests time is an illusion created by quantum entanglement (bgr.com)

新理论:时间是量子纠缠产生的错觉

核心观点

一项新理论提出,时间可能并非物理现实的基本元素,而是由量子纠缠产生的一种错觉。

理论背景与动机

  • 量子纠缠:指两个物体之间存在不可分割的联系,无论距离多远,对其中一个的干扰都会同时影响另一个。
  • 广义相对论的时间观:时间是宇宙时空的基本组成部分,并会在引力(如黑洞周围)作用下发生弯曲和膨胀。
  • 量子理论的时间观:时间是绝对的,不可弯曲且不会改变。
  • 研究动机:由于两大基础物理理论对时间的定义存在冲突,Alessandro Coppo 等研究人员致力于寻找一种统一且全新的时间定义。

新理论的核心机制

  • 时间纯粹是量子纠缠的后果。
  • 物体之所以看起来随时间发生变化,唯一的原因是它与“时钟”发生了纠缠。
  • 如果从宇宙外部进行观察,整个宇宙将呈现为完全静态和不变的状态。

研究现状与展望

  • 该理论为时间的定义提供了极具潜力的全新视角,并获得了许多物理学家的认可。
  • 目前仍需完善诸多细节,以彻底验证时间是否确为量子纠缠的产物。
  • 这些理论构想是否具备实际的可测试性,是未来面临的关键挑战。
  • 相关研究成果已发表在《Physical Review A》期刊上。
28. Python's many command-line utilities (www.pythonmorsels.com)

Python命令行实用工具总结

Python标准库中的许多模块可以作为命令行工具使用,通过python -m <模块名>的方式运行。这种机制利用__name__变量区分模块导入和脚本执行:当模块作为脚本运行时,__name__被设为"__main__"

通用实用工具

  • http.server:在当前目录启动一个简易HTTP服务器(默认端口8000),常用于预览Sphinx文档等。
  • webbrowser:在默认浏览器中打开指定URL。
  • json.tool:格式化输出JSON数据,便于阅读。
  • calendar:在终端显示日历,可指定年份和月份。

类似Linux命令的工具

这些工具提供了常见命令行工具的Python替代方案,尤其适用于Windows或缺少对应工具的环境:

  • uuid:类似uuidgen,生成UUID(Python 3.12+)。
  • sqlite3:类似sqlite3命令行客户端(Python 3.12+)。
  • zipfile:类似zip/unzip,用于压缩解压ZIP文件。
  • gzip:类似gzip/gunzip,处理gzip压缩。
  • tarfile:类似tar,处理tar归档。
  • base64:类似base64,进行Base64编解码。
  • ftplib/smtplib/poplib/imaplib/telnetlib:提供FTP、SMTP、POP3、IMAP、Telnet协议的客户端功能。
  • random:类似shuf,进行随机选择(Python 3.13+)。

Python开发相关工具

  • pip:安装和管理第三方Python包。
  • venv:创建Python虚拟环境。
  • pdb:Python调试器,运行时会在程序首行设置断点。
  • unittest:自动发现并运行当前目录下的所有unittest测试。
  • pydoc:显示模块或对象的文档(同help()函数)。
  • doctest:运行Python文件中的doctest示例。
  • ensurepip:在pip未安装时重新安装pip。
  • idlelib:启动Python的IDLE图形化REPL。
  • zipapp:将Python模块打包为可直接运行的ZIP文件。
  • compileall:将Python文件预编译为字节码缓存。

代码分析工具

用于检查Python代码的内部结构:

  • tokenize:将Python文件分解为词法单元(token)。
  • ast:显示代码的抽象语法树(AST)。
  • dis:将Python代码反汇编为字节码。
  • inspect:检查Python对象的源代码(仅限纯Python实现的对象)。
  • pyclbr:快速查看模块中的类、方法和函数概览。

彩蛋与趣味工具

  • hello:输出“Hello world!”。
  • this:显示《Python之禅》(PEP 20)。
  • antigravity:在浏览器中打开XKCD关于Python的漫画。
  • turtledemo:展示turtle绘图模块的示例。

高级与实用工具

  • asyncio:启动支持async/await的异步REPL。
  • cProfile/profile/pstats:性能分析工具,cProfile基于C实现更快,profile为纯Python实现;pstats用于分析生成的统计文件。
  • pickle/pickletoolspickle显示pickle文件的内容,pickletools详细展示pickle文件的底层结构。
  • timeit:测量Python表达式的执行时间。
  • site:显示Python环境信息,如sys.path和用户目录。
  • sysconfig:显示详细的Python安装配置。
  • platform:显示当前操作系统信息。
  • mimetypes:查询文件类型扩展名或根据文件猜类型。
  • quopri:对电子邮件数据进行quoted-printable编解码。
  • filecmp:比较两个目录的内容差异。
  • encodings.rot_13:进行ROT-13编解码。
  • tabnanny:检查Python文件是否混合使用了制表符和空格。

总结

Python标准库集成了大量实用的命令行工具,覆盖了从通用操作、系统管理、开发调试到代码分析的多个场景。这些工具通过python -m命令即可快速调用,无需额外安装,为开发者提供了便捷的解决方案。

29. Mamba-2 – State Space Duality (tridao.me)

Mamba-2: 状态空间对偶性

核心思想与背景

Mamba-2 的核心是结构化状态空间对偶性 (SSD)。它旨在解决初代 Mamba (Mamba-1) 的两个主要问题:

  1. 理解问题:状态空间模型 (SSM) 与主流的注意力机制之间缺乏清晰的概念联系。
  2. 效率问题:Mamba-1 在训练期间的硬件效率低于注意力机制,因为其计算方式不擅长利用现代加速器(如 GPU)对矩阵乘法的高度优化。

SSD 模型详解

线性 (SSM) 模式

SSD 从与 Mamba 相同的选择性状态空间模型 (Selective SSM) 方程出发: h_t = A_t h_{t-1} + B_t x_t y_t = C_t^T h_t 其中,A_t, B_t, C_t 可以随时间变化(选择性)。与 Mamba-1 的关键区别在于,SSD 进一步限制了状态转移矩阵 A 的结构:

  • Mamba-1 (S6层)A 为对角矩阵。
  • Mamba-2 (SSD层)A标量乘以单位矩阵 (a_t * I)。这意味着同一头内所有状态维度共享相同的递归动态。 此外,Mamba-2 采用了多头机制,类似于 Transformer 中的多头注意力,每头有独立的 SSM 参数,但头内各通道的 SSM 动态是共享的。

二次 (注意力) 模式

给定与 SSM 模式相同的参数张量 (A, B, C, X),SSD 可以定义一个等价的矩阵计算形式M = L ∘ (C B^T) y = M x 其中,L 是一个下三角矩阵,其元素由 a_t 的累积乘积构成。

  • 当所有 a_t = 1 时,L 退化为因果掩码,此计算等价于因果线性注意力Y = (L ∘ (Q K^T)) V
  • 一般情况下,L 矩阵的作用可以被解释为一种输入依赖的相对位置编码或“折扣因子”,其值由位置间距离和可学习的 a_t 参数决定。这正是 SSD 模型“选择性”的来源。

状态空间对偶性

SSD 的核心发现是:上述线性 (SSM) 和二次 (注意力) 两种计算模式是完全等价的,它们定义了同一个函数映射。这种等价性被称为“对偶性”。

SSD 与既有模型的对比

SSD vs. 传统 SSM

  • 结构:SSD (Mamba-2) 的 A 结构比 Mamba-1 更受限(标量 vs. 对角),但允许更大的状态维度 N(例如从 16 提升至 64 或 256)。
  • 效率:这种结构限制是为了能够用矩阵乘法来计算,从而在训练时获得更高的硬件效率。
  • 权衡:虽然理论上 Mamba-1 的表达能力可能更强(更灵活的 A),但 Mamba-2 通过共享动态实现了更大的状态空间和更快的训练速度。

SSD vs. 注意力机制

  • 差异:SSD 相当于去掉了标准注意力的 softmax 归一化,并应用了一个元素级乘性掩码 L
  • 效率:去除 softmax 使得有效状态大小从线性降为常数,并将计算复杂度从二次降至线性。掩码 L 是区分 SSD 与普通线性注意力的关键,它编码了位置信息和选择性。

算法效率与实现

SSD 的两种等价计算模式各有优劣:

  • SSM 模式 (递归):FLOPs 线性 (O(T N^2)),适合自回归推理,状态大小恒定。
  • 注意力模式 (矩阵乘):FLOPs 二次 (O(T^2 N)),但矩阵乘法在 GPU 上执行效率高。
  • SSD 算法 (融合):通过分块计算(将序列分成块,在块内用注意力模式计算,块间用 SSM 模式传递状态),结合了两者优点。该算法保持了与 SSM 相当的线性 FLOPs (O(T N^2)),同时通过利用矩阵乘法大幅加速了训练,且实现简洁。

架构与实验结果

  • 架构改进:Mamba-2 并行生成 SSM 参数 (A, B, C) 与输入 (X),而非顺序生成,这简化了设计并利于张量并行等扩展技术。
  • 语言建模:在 Pile 数据集上的实验显示,Mamba-2 的性能与 Mamba-1 相当或略优,但训练速度显著更快
  • 合成任务 (MQAR):在困难的多查询关联回忆任务中,Mamba-2 表现远优于 Mamba-1,主要得益于其更大的状态尺寸。即使在控制状态尺寸的情况下,Mamba-2 也展现出优势。

总结

Mamba-2 (SSD) 是一个统一的序列模型层,通过状态空间对偶性,将 SSM 的递归视角与注意力的矩阵视角联系起来。其主要贡献在于:

  1. 理论框架:提供了理解 SSM 和注意力机制深层联系的新视角。
  2. 计算效率:设计了融合的 SSD 算法,在保持线性 FLOPs 的同时,利用矩阵乘法极大提升了训练速度
  3. 模型能力:通过结构限制,支持更大的状态维度,从而在如关联记忆等任务上获得性能提升。 尽管 Mamba-2 在 A 矩阵结构上比 Mamba-1 更受限,但实验表明这并未损害性能,且带来了显著的效率收益。
30. Show HN: PlayBooks – Jupyter Notebooks style on-call investigation documents (github.com)

PlayBooks 项目简介

PlayBooks 是一个由 Doctor Droid 驱动的自动化生产环境问题调查工具,其风格类似于 Jupyter Notebooks。它的核心目标是通过自动化调查流程来减少排查生产问题所需的时间,并在可能的情况下完全实现自动化。

核心功能与工作原理

Doctor Droid 作为一个机器人,能够在收到警报时自动连接到超过15种的可观测性工具与服务器,执行命令并获取数据。其调查流程通过名为 PlayBooks 的智能文档进行配置。

PlayBooks 文档能够连接到整个技术栈中需要监控的各个部分,支持的操作包括:

  • 获取日志与指标数据
  • 查询数据库
  • 在远程服务器上执行命令
  • 获取容器数据
  • 定义自定义API调用

使用与入门

  1. 体验:项目提供了一个沙盒环境,其中包含一些示例 PlayBook。用户还可以在社区的 Slack 工作空间的 #demo-alerts 频道查看自动回复的警报示例。
  2. 安装
    • 可以通过 Docker 快速开始,使用命令:docker-compose -f deploy.docker-compose.yaml up -d
    • 对于 Helm chart 或自定义分支部署,需要参考项目的安装文档。
  3. 学习:可以通过项目的 YouTube 频道观看教程。

社区与支持

  • 贡献:有意贡献者需阅读贡献指南。
  • 反馈与需求:可以通过 Slack 或 GitHub Issues 分享。
  • Bug报告:可以通过 Jam 工具创建并在 GitHub 或 Slack 上分享。
  • 资源:项目提供 Slack 社区、开发路线图和文档等资源。
31. Grokfast: Accelerated Grokking by Amplifying Slow Gradients (arxiv.org)

Grokfast:通过放大慢梯度加速Grokking现象

核心问题与现象

机器学习中存在一种称为**“grokking”的奇异现象:模型在训练初期就能近乎完美地拟合训练数据(过拟合),但在经过数十倍迭代后,才突然实现泛化**。该研究旨在从实践角度,加速这种延迟泛化的过程。

方法原理

作者将模型参数在训练过程中的梯度变化视为时间序列信号,并通过频谱分解将其拆分为两个成分:

  1. 快变分量:导致过拟合的成分。
  2. 慢变分量:诱导泛化的成分。

技术方案:Grokfast

基于上述分析,作者提出Grokfast算法。其核心是仅通过几行代码,在梯度下降过程中放大慢变梯度分量,从而将grokking现象加速超过50倍

实验结果与验证

  • 通用性:算法在图像、语言、图等多种任务上均有效。
  • 实用性:该技术使原本“奇特”的突然泛化现象变得实际可用
  • 代码公开:研究代码已开源。

总结

Grokfast通过对梯度信号进行频谱分析并放大慢变分量,提供了一种简单而高效的方法,能显著加速模型从过拟合到泛化的跃迁过程,增强了该现象在实践中的可利用性。

32. The state of the art in copter drones and flight control systems (www.mdpi.com)
33. Posthog – open-source analytics and UX research tool (github.com)

PostHog:开源产品分析与用户体验研究平台

PostHog 是一个集多种工具于一体的一体化开源平台,旨在帮助团队构建成功的产品。其核心功能涵盖:

  • 产品分析:支持自动捕获或手动埋点,基于事件分析用户行为,并通过可视化或SQL进行分析。
  • 网页分析:提供类似Google Analytics的仪表盘,监控网站流量、用户会话、转化率、核心网页指标及收入。
  • 会话回放:录制并回放用户与网站或移动应用的真实交互,以诊断问题和理解行为。
  • 功能标志:安全地向特定用户或群组逐步发布功能。
  • 实验:测试产品变更,并统计测量其对目标指标的影响,支持无代码设置。
  • 错误追踪:追踪错误、获取警报并解决问题。
  • 问卷调查:使用无代码模板或自定义构建工具创建问卷。
  • 数据仓库:同步来自Stripe、Hubspot等外部工具及自有数据仓库的数据,并可与产品数据联合查询。
  • 数据管道:对传入数据进行自定义过滤和转换,并实时发送至25+工具或通过Webhook进行批量导出。
  • AI可观测性:为LLM驱动的应用捕获链路追踪、生成内容、延迟和成本数据。
  • 工作流:创建自动化操作或向用户发送消息的工作流。

所有功能均提供慷慨的免费额度(例如每月首100万事件免费),之后按使用量付费。

入门方式

  1. PostHog Cloud(推荐):最快的方式是注册PostHog CloudPostHog Cloud EU的免费账号。
  2. 自托管(进阶):开发者可通过一行Docker命令部署一个爱好者版本,建议至少4GB内存。此版本适用于每月约10万事件以下规模,之后建议迁移至云版本。官方不为自托管部署提供客户支持。

设置与集成 安装后,可通过JavaScript代码片段、多种SDK或API进行集成。官方提供涵盖前端(JavaScript、React、Vue等)、移动端(React Native、Android、iOS等)及后端(Python、Node、Ruby等)的广泛SDK和文档支持。

开源与商业模式

  • 开源许可:主代码库采用MIT许可证,部分企业版目录有单独许可。
  • 纯开源版本:提供完全去除专有代码的posthog-foss仓库。
  • 定价:付费计划定价完全透明,详见官网定价页。

社区与贡献 PostHog鼓励社区参与,包括:在路线图上投票或获取功能早期访问、提交PR、提交功能请求或报告错误。公司还公开了其运营手册。同时,PostHog正在快速成长并招募新成员。

35. Special-use domain 'home.arpa.' (2018) (datatracker.ietf.org)

RFC 8375:特殊用途域名 home.arpa. 摘要

本文档将 home.arpa. 指定为特殊用途域名,用于住宅家庭网络内部的非唯一命名。它修正了先前RFC 7788中默认域名 .home 的问题,因为 .home 存在现有使用冲突且查询会泄露到根域名服务器。home.arpa. 的名称具有本地意义,仅在其所属的家庭网络范围内有效。

核心目的与定义

  • 用途:为家庭网络设备和服务提供本地命名与服务发现机制,无需用户配置。
  • 作用域:名称仅在单个家庭网络内部解析和使用,非全球唯一。
  • 协议更新:更新了家庭网络控制协议,使其默认使用 home.arpa. 而非 .home

DNS解析的关键行为规范

  1. 本地解析:以 .home.arpa. 结尾的查询必须由家庭网络内部的本地解析器处理,不得被递归转发到家庭网络逻辑边界之外。
  2. 对解析器的要求
    • 递归解析器:必须透明支持DNSSEC查询。除非配置为转发,否则应像处理其他本地服务区域一样处理 home.arpa. 查询(禁止转发),但针对 home.arpa. 委托的DS记录查询例外。
    • 可配置性:递归解析器必须可配置,以便将 home.arpa. 及其子域的查询转发到该家庭网络的本地权威服务器。
    • 存根解析器:在手动配置了其他解析器的情况下,允许(但非强制)为解析 home.arpa. 而使用本地提供的解析器,以确保正确解析。
  3. 应用程序与用户:应用程序不应将 home.arpa. 视为特殊域名,用户可像使用其他域名一样使用它,其设计旨在提示用户该名称指向家庭网络内的设备。

安全考虑

  • 本地有效性:对 home.arpa. 子域的查询响应仅具有本地意义,其可信度不应高于其他DNS查询。
  • DNSSEC限制:由于不存在全球唯一的信任锚(根区域中没有 home.arpa. 的安全委托),标准的DNSSEC验证无法基于根信任锚对 home.arpa. 区域内的名称进行验证。要使验证生效,需要在验证解析器中手动配置特定家庭网络实例的本地信任锚。
  • 隐私与安全权衡:允许存根解析器绕过手动配置以使用本地解析器来解析 home.arpa.,这可能带来安全和隐私影响,需根据部署环境权衡。

域名委托

IANA已在 .arpa. 区域中为 home.arpa. 创建了一个不安全委托(无DS记录),并将其指向黑洞服务器。这种不安全委托对于在本地家庭网络中正确解析 home.arpa. 名称并避免DNSSEC验证失败至关重要。

总结

RFC 8375 正式确立了 home.arpa. 作为家庭网络内部本地命名的标准化特殊用途域名,明确了其非全局唯一的性质,并详细规定了DNS解析器、权威服务器和应用程序的相关行为,同时分析了其安全特性和限制。它取代了先前RFC 7788中存在问题的 .home 用法。

36. Google to shut down Google One VPN on June 20 (www.zdnet.com)

Google宣布将于2024年6月20日关闭其订阅服务Google One中包含的VPN功能。

关停原因: Google发言人解释称,公司正在重新聚焦于支持更多高需求功能,以保持订阅服务的新鲜感。调查显示该VPN服务的用户使用率较低,因此决定停止该功能。

背景信息

  • Google One于2018年推出,是一个涵盖云存储、照片编辑工具、暗网监控等功能的订阅制服务,套餐价格从每月1.99美元到19.99美元不等。
  • VPN功能于2020年10月添加,最初仅限于部分付费计划和Android设备,随后逐步扩展至所有付费计划并支持iOS、Windows和macOS。
  • 该VPN旨在保护用户在多设备(尤其是公共Wi-Fi环境下)的网络安全。

替代方案

  • Google Fi VPN:Google Fi无线订阅服务提供VPN功能,支持Android和iPhone,套餐价格从每月35美元到110美元不等。
  • Pixel设备内置VPN:Pixel 7、7 Pro、7a及Fold机型将于2024年6月3日通过系统更新获得与Pixel 8系列相同的内置VPN功能。
  • 第三方VPN工具:用户可从Google Play商店或其他渠道获取众多第三方VPN服务。

注意事项: Google方面已提供帮助页面,指导用户在服务关停后如何从设备上移除该VPN。

37. Scientists should use AI as a tool, not an oracle (www.aisnakeoil.com)

科学家应将AI作为工具,而非预言家

文章指出,AI炒作不仅源于企业和媒体,也来自AI研究者自身。例如,2023年12月《自然》杂志上两篇被广泛宣传的论文声称利用AI发现了超过220万种新材料,并通过机器人合成了其中41种,但随后被揭露大部分材料鉴定错误或早已为人所知,大数据集中的样本也多为无效数据。

机器学习的核心卖点是“无需理解即可发现”,这导致基于机器学习的科学中错误频发。作者三年前就发现“泄漏”(类似于应试教育)错误普遍存在,影响了17个学科的数百篇论文。最新汇编显示,受影响学科已增至30个,其中以医学领域为主(因为医学错误后果更严重,更注重方法审查),涉及论文约650篇,但实际规模可能远大于此。

泄漏只是导致可重复性失败的原因之一。从数据收集、预处理到结果报告,机器学习科学每一步都存在缺陷,包括不恰当的基准比较、非代表性样本、结果对建模选择敏感、不报告模型不确定性等。此外,研究者常不公开代码和数据,阻碍了可重复性(例如,某研究显示93%承诺共享数据的论文未兑现)。

这些问题的根源早于机器学习就已存在于科学界,如“不发表即灭亡”的文化、偏重发表阳性结果、缺乏揭穿错误研究的激励、低质量研究很少被撤回等。机器学习进一步加剧了质疑的理由:性能评估复杂且许多方面未解决,机器学习代码比传统统计模型更复杂且不标准化,而同行评审不审查代码,编码错误很难被发现。

然而,作者认为研究质量低下的最大原因是普遍炒作导致研究者缺乏怀疑精神。研究者常对模型结果抱有过高期望:模型表现不佳时,他们假设自己操作有误并调整模型,而非考虑问题可能本身难以预测;模型表现良好时,他们轻信结果,而忽视泄漏或其他缺陷;模型表现超预期时,则假设AI发现了人类无法想到的模式——这种将AI视为“异类智能”的神话进一步助长了轻信。这形成了一个反馈循环:过度乐观催生有缺陷的研究,进而误导整个领域对AI能力的预期。作者指出,由于错误研究未被纠正,发表优秀研究反而变得困难,因为其模型无法超越已有的“先进水平”。

随着工具越强大、越黑箱,错误和过度自信的风险越大。当前科学界正拥抱大型语言模型和生成式AI,这带来了新的陷阱,如“理解的幻觉”。作者预测,基于机器学习的科学可重复性危机在改善前可能会恶化。

但文章也指出了一些希望。机器学习科学通常仅涉及数据分析而非人体实验,因此其他研究者原则上可以下载代码和数据进行验证,这比重复心理学或医学研究成本低得多。此外,如果研究者知道需要注意什么,大多数错误是可以避免的。关键在于改变研究文化,让研究者更谨慎工作,并激励可重复性研究。

为此,作者团队的“泄漏”论文已产生影响,并帮助研究者规范建模和文档。他们还领导了一个跨学科团队开发了REFORMS检查清单(32项),帮助研究者避免八类常见陷阱,该清单已在《科学进展》发表。

结论:作者强调AI是工具,而非革命、人类理解的替代品或通往未来的捷径。但多数科学领域已陷入AI炒作,导致常识被搁置(例如,政治科学曾声称以超过90%的准确率预测内战爆发,实则源于泄漏)。当前各领域采用AI的“曲棍球棒”增长曲线并非好事,而是令人担忧的——在短短几年内改变科学认识论是任何领域都无法承受的。这并非有机采纳工具的过程,而是研究者追逐趋势以获取资金的结果。鉴于炒作程度,AI-for-Science资金计划可能使情况恶化。作者建议,至少将部分AI-for-Science资金转向更好的培训、批判性探究、元科学、可重复性研究和其他质量控制工作,以最小化危害。

38. Tell HN: Chromium forks for legacy platforms are disappearing from GitHub
41. Show HN: Huewords, a Word and Logic Puzzle (huewords.snellman.net)

Huewords 是一款结合单词和逻辑推理元素的游戏,由 Juho Snellman 设计并开发。游戏包含每日谜题和随机谜题,随机谜题设有三个难度等级。玩家可通过官方 Discord 服务器报告问题、提出功能建议或参与游戏讨论。游戏使用了 jQuery、Lora 字体、Roboto 字体以及 ZapSplat 的音效等开源资源。

43. xLSTM code release by NX-AI (github.com)

xLSTM (Extended Long Short-Term Memory) 代码发布摘要

项目概述

xLSTM 是一种基于原始 LSTM 理念的新型循环神经网络(RNN)架构。通过引入指数门控(Exponential Gating)、归一化与稳定技术以及全新的矩阵内存(Matrix Memory),它克服了传统 LSTM 的局限性,在语言建模中展现出与 Transformer 和状态空间模型(SSM)相媲美的性能。NX-AI 团队已成功在 2.3T tokens 上训练了 70 亿参数的 xLSTM 语言模型(称为 xLSTM Large)。

安装与环境配置

  • 基础依赖:基于 PyTorch(>=1.8),推荐使用提供的 YAML 文件创建 Conda 环境。
  • 安装方式:可通过 pip 安装 xlstm 包,或从 GitHub 克隆源码进行本地开发安装。
  • 加速内核:运行 xLSTM 7B 模型必须额外安装 mlstm_kernels 包以获取高性能计算内核。

核心架构与功能模块

1. xLSTM Large (7B 模型)

  • 优化与开源:针对训练吞吐量和稳定性进行了深度优化。架构代码位于 xlstm/xlstm_large,提供独立的单文件实现。模型权重已在 Hugging Face 开源。
  • 使用方式:提供 Jupyter Notebook 示例,展示如何配置模型参数(如指定 Triton 内核)并执行前向传播。

2. NeurIPS 论文基础组件

  • xLSTMBlockStack:作为现有项目的替代主干网络(类似 Transformer 块堆叠),适用于非语言任务或集成到其他架构中。支持通过 Python 数据类或 YAML 文件(结合 daciteomegaconf)进行灵活配置。
  • xLSTMLMModel:专为语言建模设计,是 xLSTMBlockStack 的封装,增加了 Token 嵌入层和语言模型头(LM Head)。
  • sLSTM CUDA 内核:要求 GPU 计算能力(Compute Capability)>= 8.0,并提供环境变量配置以解决自定义 CUDA 环境下的编译问题。

硬件兼容性建议

  • NVIDIA/AMD GPU:主要在 NVIDIA GPU 上测试,其 Triton 内核也兼容 AMD GPU。
  • Apple Silicon:建议关闭 Triton 内核,使用原生 PyTorch 实现;或使用社区驱动的 MLX 原生移植版本(xLSTM-metal)。

实验验证

合成实验证明了 xLSTM 中 sLSTM 和 mLSTM 模块的互补优势:

  • 奇偶校验任务(Parity task):依赖 sLSTM 内存混合提供的状态跟踪能力。
  • 多查询关联回忆任务(Multi-Query Associative Recall):衡量记忆能力,mLSTM 的矩阵内存和状态扩展在此任务中优势显著。
  • 综合表现:结合两者的 xLSTM 架构在上述两类任务中均能有效解决难题,表现优异。
45. Show HN: Web Development with Htmx, Type-Guided Components, Pure Python (getludic.dev)
47. Koheesio: Nike's Python-based framework to build advanced data-pipelines (github.com)

Koheesio:用于构建高级数据管道的Python框架

概述

Koheesio(芬兰语“凝聚力”之意)是一个稳健的Python框架,专为构建高效的数据管道而设计。它鼓励模块化和协作,允许从简单、可重用的组件创建复杂的管道。Koheesio支持多种实现方式,可与各种数据处理库或框架无缝协作,适用于任何数据处理任务,无论底层技术或数据规模如何。该框架利用Pydantic进行强类型化、数据验证和设置管理,确保管道组件的高级类型安全和结构化配置。

核心定位与特点

  • 非工作流编排工具:Koheesio并非旨在替代工作流编排工具(如Apache Airflow、Luigi或Databricks工作流),这些工具用于管理复杂的计算工作流并生成DAG(有向无环图)。相反,Koheesio专注于为数据任务提供稳健、模块化和可测试的框架。
  • 核心优势:聚焦于工作流中的单个任务,使其尽可能健壮、可重复和可维护。它将任务分解为小的、可管理的工作单元,这些单元可轻松测试、重用并组合到由其他工具(如Apache Airflow)编排的更大工作流中。
  • 原则与目标:遵循模块化、可重用性、可测试性和透明性的核心原则,旨在确保可预测的管道执行,通过充分测试的代码和丰富的特性集,成为构建稳健且适应性强的数据管道的理想选择。
  • 协作与创新:封装了多年的软件和数据工程专业知识,促进协作和创新的社区,专注于数据管道、数据转换、ETL作业、数据验证和大规模数据处理。

核心组件

Koheesio包含三个核心组件:

  1. Step(步骤):管道中的基本工作单元,代表数据管道中的单个操作,接收输入并产生输出。
  2. Context(上下文):用于设置任务环境的配置类,可在任务间共享变量,并根据环境调整任务行为。
  3. Logger(日志记录器):用于记录不同级别消息的类,提供透明度和可追溯性。

与其他库/工具的比较

Koheesio被定位为一个通用的数据管道框架,与专注于特定领域的工具形成对比:

  • 与机器学习框架对比:Flyte、Kubeflow、Kedro、Metaflow、MLflow、TFX、Seldon Core等主要专注于机器学习工作流。Koheesio更通用,适用于各类数据处理任务,不限于ML。
  • 与编排工具对比:Apache Airflow、Luigi、Databricks Workflows、Prefect、Snakemake、Dagster、Ploomber、Pachyderm、Argo等专注于工作流编排。Koheesio的任务代码通常与这些编排引擎兼容。
  • 与其他库对比:Dask(并行计算)、dbt(SQL转换)、Broadway(Elixir)、Ray(分布式计算)、DataJoint(数据关系)等各有专长。Koheesio强调模块化和协作,提供更通用的数据处理能力。

安装与集成

  • 安装方式:可通过pip、hatch或poetry进行安装。
    • Pip: pip install koheesio
    • Hatch: 在pyproject.toml[dependencies]中添加koheesio = "<version>"
    • Poetry: 运行poetry add koheesio或在pyproject.toml[tool.poetry.dependencies]下添加koheesio = {version = "..."}
  • 额外功能(Extras):提供可选集成模块,需要额外安装依赖:
    • spark:支持Spark Connect和Delta。
    • spark.dq.spark_expectationsse):为Spark DataFrame提供数据质量检查。
    • box:集成Box云内容管理服务。
    • sftp:集成SFTP安全文件传输协议。
    • snowflake:集成Snowflake云数据仓库平台。
    • 安装方式示例:pip install koheesio[spark]或在pyproject.toml中添加koheesio[spark]

贡献指南

项目欢迎贡献,开发过程包括:

  • 代码标准:使用pylint、black和mypy确保代码标准,提交前需通过make check检查。
  • 测试:使用pytest进行测试,提交前需通过make test确保所有测试通过。
  • 发布流程:力求频繁发布,通常在添加新功能或修复错误后,由具有管理员权限的开发者在GitHub上创建新版本并发布到PyPI。