2025-10-04

40 篇热帖

1. Germany must stand firmly against client-side scanning in Chat Control [pdf] (signal.org)

德国必须坚定反对聊天控制提案中的客户端扫描

德国正面临一个灾难性的立场逆转,可能放弃其长期以来对欧盟“聊天控制”提案的原则性反对。这标志着欧洲隐私权可能终结。德国本是隐私的坚定捍卫者,深知大规模监控带来的历史创伤,并一直致力于捍卫整个欧洲的隐私权。在地缘政治不确定、核心基础设施网络安全至关重要的当下妥协,将是不可理解的战略失误,也是对欧洲从历史中汲取教训的承诺的根本背叛。

该提案以保护儿童为名,要求对用户设备上的每条消息、照片和视频进行大规模扫描,并通过政府强制的数据库或人工智能模型来判断内容是否“合规”。

这引发了多重严重关切:

  1. 技术共识:扫描每条信息——无论是在加密前还是后进行——都会破坏端对端加密的根本前提。攻击者和敌对国家无需破解如Signal这样的顶级加密协议,只需利用扫描系统提供的访问权限即可。此威胁如此严重,以至于情报机构也认为其将对国家安全造成灾难性影响。提案忽视了私人通信的战略重要性,也违背了“无法创建只允许‘好人’进入的后门”这一长期技术共识。提案实质上打开了大规模监控的闸门,危及所有人——包括政府官员、军人、调查记者和活动人士——的私密通信。
  2. 对Signal的生存威胁:Signal致力于提供真正私密的通信平台。加密要么对所有人有效,要么就完全无效;网络一部分的后门会成为所有部分的入侵向导。Signal不会妥协其服务完整性,或危及依赖其平台(常在关乎生死的环境中)的用户安全。如果被迫在Signal中内置监控机制或退出市场之间选择,Signal会选择退出市场。这并非轻率的决定,Signal衷心希望无需面对此局面,但若聊天控制提案强行实施,这很可能成为最终结果。

好消息是阻止此事仍有机会。 德国政府,尤其是司法部,必须坚守立场。德国政府的明智决策将决定欧洲的未来:是保障作为人权的私人通信权,还是让欧洲的经济、社会和政治安全被聊天控制提案带来的大规模监控所危及。我们敦促德国保持智慧,坚持原则,绝不让历史重演——只是这次涉及的数据库更大,数据也更为敏感。

2. Zig builds are getting faster (mitchellh.com)

Zig 构建速度提升摘要

背景与目标

Zig 编程语言团队将加快编译时间作为核心目标之一,原因是编译器速度慢可能导致缺陷。为此,团队投入大量工作,包括放弃使用 LLVM、开发自有的代码生成后端、构建自有链接器,以及推进增量编译的实现。这些努力在 Zig 0.15.1 版本中开始显现成效,Ghostty 项目升级后分享了实际构建时间数据。

关键改进数据

以下数据均在相同 x86_64 Linux 机器上测量,展示了 Zig 0.15.1 相比旧版本(如 0.14)的性能提升:

  • 构建脚本编译时间:从 7.167 秒减少到 1.702 秒,影响首次源构建的时间。
  • 完整未缓存 Ghostty 二进制文件构建时间:从 41 秒减少到 32 秒,尽管仍主要使用 LLVM,但整体速度提升约 2 秒。
  • 增量构建(Ghostty 可执行文件):从 19 秒减少到 16 秒,适用于一行代码更改后的重新构建,但当前仍使用 LLVM 且增量编译未完全实现。
  • 增量构建(libghostty-vt 库):从 2.884 秒减少到 0.975 秒,该库已能完全使用自托管 x86_64 后端,实现了亚秒级构建。

当前状态与限制

  • Ghostty 项目仍无法完全使用自托管后端构建,因为该后端存在缺陷,因此大部分构建仍依赖 LLVM。
  • 增量编译尚未完全功能化,当前重新编译量较大,但未来实现后预计可大幅缩短构建时间至毫秒级。
  • 自托管 x86_64 后端已足够稳定用于调试构建,aarch64 后端也在改进中。

未来展望

  • 一旦 Ghostty 完全使用自托管后端,构建时间预计将降至 25 秒或更少,比 Zig 0.14 快一半。
  • 完全移除 LLVM 后,增量构建时间可能进一步降至约 12 秒。
  • 增量编译完全实现后,构建时间有望降至毫秒级别。
  • 作者对 Zig 的未来表示乐观,认为当前改进是显著的,且未来几年内构建速度还会有更大提升。

总结

Zig 0.15.1 在所有构建场景中均显示出速度提升,尽管仍受 LLVM 依赖和增量编译未完成的限制。这些改进是 Zig 团队长期努力的成果,并正在实际项目中带来效率提升。

3. Flock's gunshot detection microphones will start listening for human voices (www.eff.org)

Flock Safety枪声检测麦克风将新增监听人类声音功能

公司背景与现有产品

  • Flock Safety是一家美国警察科技公司,以广泛部署自动车牌识别器网络而闻名。
  • 其核心产品Raven是一种声学枪声检测系统,部署在公共场所,通过麦克风捕捉声音,并利用机器学习识别枪声以向警方报警。
  • 美国电子前沿基金会EFF长期警告,这些设备实质上是安装在人口密集街道上方的高性能麦克风

新功能与潜在问题

  • Flock Safety正在为Raven产品开发新功能:检测“人类困境声音”(如尖叫、呼救声)并触发警报。
  • 公司营销材料显示,警方将能接收到“尖叫”或“困境”相关的警报(该描述后被悄然改为“困境”)。
  • 技术透明度不足:公司未明确说明该功能的技术原理,以及如何区分“困境声音”与普通环境音。
  • 法律风险:该功能可能违反美国各州的**“窃听”法律**,这些法律限制对公共空间内私人对话的监听或录音。

已有的法律与运营问题

  • Flock Safety产品已引发多起法律纠纷:
    • 在伊利诺伊州,被指控违反州法律,允许联邦移民及海关执法局访问该州内的车牌识别数据。
    • 在北卡罗来纳州,因未经许可运营,法官曾全州暂停其摄像头安装。
    • 在伊利诺伊州埃文斯顿市,公司在合同取消后擅自重新安装已移除的车牌识别器,导致市政府采取法律行动并遮盖设备。
  • 警察监督委员会数据显示,超过99%的Flock警报未引发任何警方行动,效用受到质疑。

安全隐患与公民自由风险

  • 枪声检测技术本身存在误报风险,可能导致警方在非紧急情况下(如儿童燃放烟花)错误开火,已有儿童因此中枪的实例。
  • 新增的声音监听功能可能进一步加剧法律、公民自由和人身安全方面的不可预见后果。
  • EFF建议各城市重新评估与Flock Safety的合同,以避免潜在危害。
4. How I influence tech company politics as a staff software engineer (www.seangoedecke.com)

文章总结

本文探讨了软件工程师如何在大型科技公司中有效参与并影响公司政治,反对常见的宿命论观点,并提出了具体、务实的行动策略。

核心观点: 工程师不应效仿高层进行权谋算计,因为这缺乏实践和权力基础,容易弄巧成拙。相反,他们应利用自己的技术专长,通过更正当、务实的方式参与政治,从而实现技术目标并提升个人影响力。

主要策略

  1. 主动促成高调项目成功:这是最直接的方式。积极参与并运用工程技能推动公司重点投入的项目(如当前的AI项目)获得成功。作为回报,工程师可获得奖金、晋升支持以及未来参与重要项目的机会,从而积累政治资本。
  2. 将个人技术议程与组织“浪潮”结合:这是更具控制力的方法。工程师应准备好多个有价值的技术改进方案(如系统迁移、工具链升级、性能优化等),但不急于强行推进。而是耐心等待公司层面出现与你的方案目标一致的优先事项或危机(例如,在重大事故后强调可靠性时)。此时,将你的方案作为解决方案提出,更容易获得高管的资源支持。这相当于利用了高管自身的政治资本来实现你的技术目标,同时增加而非消耗你自己的政治资本。
  3. 准备充分,把握时机:组织的关注点会周期性变化(如对可靠性、开发效率、客户体验的侧重)。有远见的工程师会预先构思并准备好一系列详细可行的技术方案,以应对不同主题的“管理浪潮”。在正确时机提出正确方案,是高级工程师的核心责任。

避免的陷阱

  • 避免在真空期强行推动:在组织关注点不在时,强行推动内部技术重构,容易被视为分散精力、对客户价值不大的行为。
  • 避免让政治真空被劣质方案填充:如果公司有政治动力要采取行动却没有好主意,往往会采纳糟糕的技术决策。工程师准备好方案,可以防止这种情况,这对公司和自身都有利。

总结: 该方法本质上是在公司设定的优先级框架内工作,通过将精心准备的技术方案与组织的实时需求和“政治浪潮”对齐,来更高效地实现技术改进和职业发展。作者认为,这并非单纯的机会主义,而是高级技术人才应具备的战略眼光和责任担当。

6. Paged Out Issue #7 [pdf] (pagedout.institute)

Paged Out! 第7期 概要

本期《Paged Out!》是第七期黑客电子杂志,涵盖了广泛的技术主题、艺术创作和社区更新。以下是内容概要:

1. 杂志概况与编辑致辞

  • 出版信息: 2025年10月出版,由Paged Out! Institute编辑,HexArcana Cybersecurity GmbH管理。
  • 编辑致辞: 主编Aga提到,杂志首次以实体形式在活动中分发,并鼓励读者分享照片。项目负责人Gynvael Coldwind介绍了该刊的发展,包括印刷版获取渠道的扩展,并宣布第8期文章征集正式开放

2. 人工智能 (AI)

  • AI识别实验: Aga测试了多个AI检测器区分人类原创文本、完全由AI生成文本、AI改写文本及人工微调AI文本的能力,结论是检测结果不一致,类似于“搜巫行动”。
  • AI应用与工作流: Marius Fleischer和Avani Tanna展示了如何使用本地小型语言模型(LLM)通过确定性工作流(而非代理设计)玩现金流游戏,以做出理性的财务决策。
  • AI作为人形证明: Peter Whiting提出了一个概念证明,利用商业AI模型因安全合规而不愿协助的事项(如盗版)来区分人类和AI代理。
  • AI安全: Robbe Van Roey分析了BentoML框架中基于pickle的序列化漏洞(CVE-2024-2912),可导致远程代码执行,并建议使用更安全的Safetensors格式。

3. 编程与软件开发

  • 神经网络实现: Jędrzej Maczan分享了一个完整的、可自包含的手写数字识别器C语言代码,展示了神经网络的核心概念。
  • 编程实践: Szymon Drosdzol构建了一个名为“Vibecoding Djinn”的恶意合规代码助手代理,展示了AI代理的基本结构。
  • 密码学基础: Noë Flatreaud简要介绍了RSA加密算法的原理和潜在攻击。
  • 演示场景: Adam Sawicki介绍了现代4K大小编程演示(4K intros)的创作技术,包括使用着色器和光线行进等技术。
  • 编程技巧:
    • Peter Bex探讨了PostgreSQL查询中因隐式类型转换导致的意外顺序扫描问题及驱动程序责任。
    • Sándor Dargó建议使用C++20的概念(concepts) 替代CRTP模式来实现静态接口。
    • Nicolas Seriot展示了如何利用PostScript语言在支持该功能的激光打印机上运行交互式程序(如井字棋)。
    • Matthew Sotoudeh和Akshay Srivatsan介绍了γ语言,一种向C语言添加模板泛型的后向兼容扩展。
    • Miloslav Homer介绍了如何使用香农熵来检测文本中的高随机性字符串(如密钥)。
    • Alok Menghrajani探讨了通过遍历所有浮点数来彻底测试浮点数相关代码的方法。

4. 安全与逆向工程

  • 系统内部: Taylor Sessantini深入分析了Windows的KUSER_SHARED_DATA结构,展示了非特权用户如何控制其中一些字段,并影响到虚拟信任级别1(VTL1)。
  • 漏洞研究与利用:
    • Luke M描述了如何通过声音漏洞利用(包括栈溢出和全局缓冲区溢出)获得廉价IoT安全摄像头的root shell。
    • Alberto Fernandez-de-Retana探讨了浏览器权限模型,指出攻击者如何通过供应链攻击或网站漏洞劫持如摄像头等敏感权限。
    • Karol Mazurek概述了macOS的IOKit框架,重点关注externalMethod入口点,这是内核驱动程序暴露给用户空间的主要攻击面。
    • Luke M还展示了如何远程黑入一个IoT摄像头,利用漏洞获取任意代码执行能力,并将视频流劫持为运行DOOM游戏的画面。
    • Javier Ochoa Bernal和Leopoldo Ramírez del Prado Esquivel描述了针对技术支持人员的“Zhong Stealer”恶意软件活动。
  • 二进制分析: Mikhail Sosonkin介绍了如何使用LLVM库编写MIPS反汇编器。Calle "ZetaTwo" Svensson演示了如何动态计算密码学常量(如SHA-256的初始值)来混淆代码。一个互动谜题挑战读者分析一个计算特定数列的二进制文件。
  • 反调试技术: Serexp展示了如何利用GCC的__attribute__((constructor))特性在main()函数之前执行代码,实现一种在调试器下触发的本地代码执行(LCE)。
  • 恶意软件分析: Cryptax分析了一个2025年4月出现的Linux版Trigona勒索软件变种,它使用Delphi编写,具有加密配置和特定命令行选项。

5. 硬件、网络与系统管理

  • 显示技术: Gynvael Coldwind详细介绍了DisplayPort的多流传输(MST) 功能,允许通过单根电缆连接多个显示器,并提供了使用建议和故障排除技巧。
  • 硬件项目:
    • Katie Paxton-Fear描述了一个“过度设计”的解决方案,使用RFID标签、电子墨水屏和ESP32微控制器来标记3D打印机耗材。
    • Loup Vaillant讨论了完全通用硬件安全模块(HSM) 的概念,结合了DICE测量启动和用户可编程性。
    • Daniele Scasciafratte讲述了在Wayland显示服务器协议下实现鼠标在多显示器间精确移动的解决方案wcentermouse
  • 网络与协议: Gynvael Coldwind回顾了1990年代IRC(互联网中继聊天)频道争夺战的历史和攻击策略。Sunny展示了如何仅使用Caddy网络服务器的配置文件来实现一些简单但实用的网络服务。
  • 系统管理: Haris Qazi介绍了如何使用Mermaid图表工具可视化地记录和展示其3-2-1数据备份协议。

6. 艺术与创意

  • 本期包含多位艺术家的作品,包括Amir Zand、Vasyl、Léa Pinto的概念艺术、绘画演示和插图。
  • Facundo Olano讲述了一个像素风格的寓言故事,关于早期游戏开发者如何通过滥用抖动技术来创造艺术。
  • Rob Hogan设置了两个基于雅达利游戏《Tempest》的复古编程谜题。
  • Marcin Wądołkowski分享了如何使用Commodore Basic 7.0的TEMPOPLAY命令编写简单旋律。
  • Alex Radocea从理论角度分析了一种针对BB84量子密钥分发的相干正交测量攻击。

7. 书籍与捐赠

  • 捐赠者: 列出了Przemo作为冠军赞助商。
  • 广告与赞助: 包括Thinkst Canary(安全工具)、IDA Pro(反编译器)、Hex-Rays、Doyensec(安全公司)、TyphoonCon(安全会议)、Reverse Engineering Conference、Eshard(安全研究平台)、Pixie Point Security、Modular WiFi Routers、Shadowserver、Bitso等的广告或招聘信息。
7. Who owns Express VPN, Nord, Surfshark? VPN relationships explained (2024) (windscribe.com)

VPN公司所有权与行业关系摘要

本文基于2024年的行业关系图,解析主要VPN品牌的所有权结构与关联企业,并指出行业中的七项关键观察。

主要VPN公司所有权结构

  • ExpressVPN:2009年由Peter Burchhardt和Dan Pomerantz创立,后于2021年被Kape Technologies以9.36亿美元收购。目前由Kape Technologies的拥有者Teddy Sagi实际控制,并与CyberGhost、Private Internet Access、ZenMate、Goose VPN同属一个企业网络。
  • NordVPN:由立陶宛公民Tom Okman和Eimantas Sabaliauskas创立,隶属于Nord Security集团。该集团于2021年收购Atlas VPN,并在2022年与Surfshark合并(但品牌保持独立运营)。
  • Surfshark:由Vytautas Kaziukonis于2018年创立,注册于阿姆斯特丹,在立陶宛和波兰设有办公室。2022年与NordVPN合并后,运营控制权归属Nord Security。
  • Kape Technologies:原名Crossrider,由Teddy Sagi通过Unikmind Holdings全资拥有。自2017年起通过一系列收购(包括CyberGhost、ZenMate、Private Internet Access及ExpressVPN)扩张。同时运营VPN评测网站vpnMentor和Safety Detectives。

行业关系图解读

作者通过在线关系图展示了VPN公司、媒体内容网站、联盟推广计划之间的已证实关联,区分了以下关系类型:

  • 红色:企业所有权关系
  • 橙色:付费推广或联盟关系(虚线表示)
  • 蓝色:合作或伙伴关系(可能共享人员、资源、网络或设施)
  • 紫色:企业媒体关系与所有权
  • 棕色:法律纠纷

行业七项观察要点

  1. Surfshark客户端安全问题:其Windows和Linux版本曾以明文形式在本地记录用户数据(如邮箱、支付信息),存在隐私风险。
  2. 联盟推广佣金丰厚:主流VPN通过高额佣金(通常30%-50%)激励推广,部分评测网站因商业利益可能影响推荐中立性。
  3. NordVPN面临潜在集体诉讼:因其繁琐的退订流程被指控涉及误导性自动续费。
  4. 行业争议与法律诉讼:好莱坞曾起诉VPN服务商,指控其间接助长盗版等犯罪行为。
  5. 网红营销夸大宣传:VPN公司常通过YouTube、TikTok等平台的网红推广,夸大隐私保护范围,可能误导用户。
  6. 联盟网站推荐倾向性:付费联盟网站几乎从不推荐非合作VPN品牌,即便后者在测试中表现更优。
  7. 市场规模巨大:VPN市场在2019年估值254亿美元,预计2026年将达770亿美元,需求持续增长。

总结

VPN行业呈现高度企业化和资本集中趋势,大型集团通过收购整合多个品牌。同时,付费联盟营销广泛存在,可能影响评测客观性。用户在选择VPN时需关注所有权背景、实际安全性能及评测来源的独立性。

8. Offline card payments should be possible no later than 1 July 2026 (www.riksbank.se)

瑞典央行与支付市场代表达成协议,将强化线下卡支付能力,以应对数字支付系统中断风险。核心目标是不晚于2026年7月1日,确保在通信故障等紧急情况下,民众仍能使用实体银行卡及密码线下购买食品、药品、燃料等必需品。

该协议明确了卡发行机构、卡网络、收单机构、零售业及央行等多方责任,包括调整监管框架、引入技术解决方案等。央行负责牵头协调并监督落实,相关工作后续将扩展至其他支付方式的离线功能。

央行行长强调,在瑞典现金使用率低、高度依赖数字支付的背景下,此举是提升民防支付韧性的重要里程碑。

9. Circular Financing: Does Nvidia's $110B Bet Echo the Telecom Bubble? (tomtunguz.com)

Nvidia的1100亿美元投资承诺引发了关于其是否重演2000年电信泡沫的担忧。本文对比了当前情况与Lucent历史案例的异同,并指出了关键风险领域。

核心相似点:供应商融资模式

  • Nvidia的策略:通过直接投资(如向OpenAI承诺1000亿美元)和GPU支持的贷款,向客户提供资金以购买其产品。其供应商融资总额达1100亿美元,占其年收入的67%,规模远超历史案例。
  • 历史案例(Lucent):在1999-2000年电信泡沫期,设备制造商向客户(如CLECs)提供大额供应商融资。当泡沫破裂时,47家CLECs破产,设备商的贷款组合损失惨重。

五大关键风险与差异

  1. 客户集中度更高:Nvidia前两大客户贡献了39%的收入,而Lucent时期仅为23%。当前AI投资高度依赖少数几家超级计算公司。
  2. 新兴的GPU支持债务市场:基于GPU将在4-6年内保值的假设,已形成100亿美元以上的贷款市场,但利率高(约14%)。GPU实际使用寿命(1-3年)可能远低于会计假设的6年,存在价值高估风险。
  3. 特殊目的实体的使用:科技公司通过SPVs进行数据中心建设,将债务表外化,模糊了真实的资本支出和财务风险。
  4. 定制芯片威胁:主要客户(如微软、谷歌、亚马逊)正积极研发自研AI芯片,以减少对Nvidia的依赖,这可能威胁到Nvidia的供应商融资模式及GPU抵押品价值。
  5. 会计与现金流基础更稳固关键区别在于,Lucent存在系统性财务造假且现金流恶化;而Nvidia现金流强劲(年运营现金流超500亿美元)、信用评级优良(Aa3),且其超级计算公司客户本身盈利能力极强。

需监控的关键指标

  • GPU实际利用率与库存情况。
  • OpenAI等关键客户的商业化能力。
  • GPU支持债务市场的违约情况。
  • 自研芯片的发展与替代进程。
  • Nvidia客户基数的多元化进展。

结论

尽管存在令人担忧的结构性相似点,但Nvidia并非Lucent,2025年也并非2000年。主要区别在于:当前的基础需求更真实(云客户自身盈利)、Nvidia财务基础更健康、且行业处于产能不足而非过剩阶段。然而,高集中度、资产估值风险以及客户转向自研芯片的可能性仍是悬而未决的重大隐患。AI需求是真实持久还是投机泡沫,仍需观察上述指标。

10. A comparison of Ada and Rust, using solutions to the Advent of Code (github.com)

Ada 与 Rust 的比较:基于 Advent of Code 的解决方案

本文作者通过完成 2023 年 Advent of Code (AoC) 的所有谜题,将惯用的 Ada 语言解决方案翻译为 Rust,并进行了高层面的比较。作者明确表示旨在进行客观分析,避免表达个人偏好。

语言概述与核心异同

两者都是通用系统编程语言,强调安全性与可靠性,均被 NIST 推荐,且拥有可用于安全关键系统的认证编译器。它们的主要区别在于:

  • 规范与哲学:Ada 有正式的 ISO 标准(Ada 2022),注重代码可读性,倾向于用问题域的术语定义类型(例如,用 Digits 18 定义浮点类型)。Rust 的规范主要依赖编译器和参考文档,更侧重内存安全,依赖较低层级的机器类型。
  • 错误处理:Ada 使用异常机制,可能被忽略。Rust 使用返回类型(Option/Result)强制开发者显式处理错误。
  • 特性:Rust 内置模式匹配、强大的枚举(可携带数据)和迭代器,支持宏。Ada 在数组边界检查、并发编程、基于离散类型的数组索引方面有内置支持。

性能与可靠性

  • 编译与运行速度:Rust 通常以运行速度快著称,但编译可能较慢。Ada 的运行时检查可能影响速度,但编译器通常能在编译期优化掉这些检查。在作者的特定测试中(如第 24 天),Ada 通过高层类型定义(Digits 18)让编译器自动选择了更适合的硬件类型(TBYTE),从而获得了比使用 f64rust_decimal 库的 Rust 更好的性能。
  • 安全性:两者都旨在提高安全性。Ada(尤其是 SPARK)和 Rust 都能在一定程度上保证内存安全。Rust 的所有权系统是编译时强制执行的。

案例研究的关键观察

  1. 文件处理与错误处理:Ada 使用直观的循环和异常。Rust 使用迭代器链(如 .lines(), .map())和 Result 类型,强制处理错误,代码风格更函数式但可能更冗长。
  2. 模块化与泛型:Ada 使用 package,明确分离规格和实现。Rust 使用 modcrate,默认私有,用 pub 控制可见性。两者都支持泛型:Ada 用于包或过程,Rust 用于类型和结构体。Rust 的测试集成在构建工具中(cargo test)。
  3. 枚举:Ada 的枚举是线性可排序的离散类型,可直接用于迭代和数组索引。Rust 的枚举是代数数据类型,其变体可携带数据,功能更强大,但许多基本特性(如排序、迭代)需要通过 #[derive] 宏或手动实现。
  4. 过滤与枚举迭代:Ada 使用传统的 for/while 循环和 when 过滤子句,代码直白。Rust 深度依赖迭代器方法链(.iter(), .enumerate(), .filter(), .map(), .fold())和闭包,风格更函数式,表达力强但可能降低可读性。

结论

作者总结,两种语言都致力于安全编程,但提供了不同的工具集和哲学。Ada 通过详细规范和高层抽象提供可预测性和可靠性。Rust 通过现代语言特性(如所有权、模式匹配、迭代器)和生态系统提供强大的表达力和内存安全保证。选择取决于项目需求、团队熟悉度和特定领域要求。作者的解决方案代码虽非最优,但为从实践角度理解两种语言的异同提供了有价值的案例。

11. OpenAI Is Just Another Boring, Desperate AI Startup (www.wheresyoured.at)

核心论点

文章认为,OpenAI并非其宣传的行业创新中心,而是一家缺乏清晰战略、愿景和产品路线图,且极度依赖媒体炒作来维持高估值的平庸AI初创公司。

估值炒作与业务发散

OpenAI频繁向媒体泄露各种跨界业务计划,包括推出视频社交媒体(Sora 2)、办公生产力套件、AI招聘平台、广告业务、云计算服务、自研AI芯片、消费级硬件(如智能音箱和AR眼镜)以及自研浏览器等。作者指出,这些缺乏连贯性的计划主要是为了制造“无所不能”的假象,从而抬高公司估值,以筹集未来四五年内所需的至少1万亿美元资金。

业务现状与财务困境

实际上,OpenAI是一家表现糟糕的软件公司。其主要收入高度依赖ChatGPT订阅(约2000万个人付费用户和500万企业用户),而API销售收入占比极小,表明其模型在大规模商业集成方面缺乏吸引力。财务方面,公司亏损严重:2025年上半年收入为43亿美元,但研发成本高达67亿美元(占收入的150%)。此外,Sora 2等产品的单次生成成本极高,处于亏本获取用户的状态。

技术局限与“套壳”本质

文章指出,OpenAI在产品开发上表现不佳,GPT-5的升级令人失望且运营成本更高。由于大语言模型(LLM)存在数学上不可避免的“幻觉”问题,其核心技术缺陷无法彻底修复。由于缺乏真正的底层模型创新,OpenAI本质上与众多AI初创公司无异,仅仅是在LLM基础上进行“套壳”(wrapper)开发,试图在普遍亏损的生成式AI行业中寻找变现途径。

总结

OpenAI的“杀手级应用”实际上是其精心营造的神话。随着收入增长放缓、产品同质化加剧、模型技术不再保持绝对领先,以及生成式AI行业整体光环褪去,OpenAI正面临残酷的现实:它只是另一家拼命寻找盈利模式、利用公关手段掩饰产品缺陷的普通AI初创公司。

12. Jeff Bezos says AI is in a bubble but society will get 'gigantic' benefits (www.cnbc.com)

杰夫·贝索斯:AI处于泡沫中,但将为社会带来巨大利益

核心观点

  • AI处于“工业泡沫”:亚马逊创始人杰夫·贝索斯在2025年意大利科技周上表示,当前人工智能行业存在泡沫特征,如股价脱离基本面、投资者过度兴奋、好坏项目均获融资。
  • 技术真实且有益:尽管存在泡沫,贝索斯强调AI是真实的技术,将改变所有行业,并为社会带来“巨大利益”。
  • 泡沫的积极面:他类比20世纪90年代的生物科技泡沫,指出虽然许多公司失败,但最终催生了救命药物,社会从创新中长期受益。AI泡沫也可能产生类似结果。

泡沫的典型特征

贝索斯描述了泡沫时期的几个关键迹象:

  1. 股价与基本面脱节:企业估值脱离实际业务基础。
  2. 过度乐观情绪:公众和投资者对AI技术极度兴奋。
  3. 资金盲目涌入:几乎所有实验或想法(无论好坏)都获得融资,投资者难以辨别优劣。
  4. 不寻常投资行为:例如小型初创公司获得巨额资金,反映出市场非理性。

其他行业领袖的类似警告

  • OpenAI CEO Sam Altman:2025年8月曾表示AI市场存在泡沫。
  • 高盛CEO David Solomon:指出投资者在兴奋时易忽视风险,市场终将面临调整和下跌。
  • 投资机构观点:Selwood Asset Management首席投资官Karim Moussalem认为,AI交易正成为历史上最大的投机狂热之一。

总结

贝索斯的核心立场是:尽管AI行业存在泡沫风险,但技术本身具有变革性价值,长期来看将推动社会进步。投资者需警惕短期非理性,但对AI的未来应保持信心。

13. How does gradient descent work? (centralflows.github.io)

这篇文章探讨了梯度下降在深度学习中如何运作,并指出了传统优化理论与实际训练动态之间的差异。主要内容如下:

  • 梯度下降的基本形式与二次函数分析:文章从确定性梯度下降算法出发,解释了在二次函数上的行为:当学习率 η 固定时,若Hessian矩阵的最大特征值(锐度 S(w))小于 2/η,则算法收敛;反之则发散。传统理论认为,深度学习训练中梯度下降应始终保持在“稳定区域”(即 S(w) ≤ 2/η)内。

  • 深度学习的实际动态与“边缘稳定性”:通过实验观察(如 Vision Transformer 在 CIFAR-10 上的训练),发现梯度下降实际上会频繁离开稳定区域:锐度上升至阈值 2/η 后,算法开始沿最陡峭方向振荡,损失增大。但随后锐度会自动下降至阈值以下,振荡收敛,损失回落。这种锐度在 2/η 附近动态平衡的现象称为边缘稳定性,在深度学习中普遍存在。

  • 三阶泰勒展开与自动锐度调节机制:传统基于二阶近似的理论无法解释 EOS 现象。文章提出通过三阶泰勒展开揭示关键机制:当梯度下降沿最陡方向振荡时,梯度会额外包含一个与锐度梯度 ∇S(w) 成正比的项,其系数与振荡幅度平方 x² 相关。这相当于对锐度施加了一个隐式的惩罚项,促使振荡自动降低锐度,形成负反馈循环。

  • 中心流:描述长期轨迹的微分方程:为简化对 EOS 动态的理解,文章引入了中心流的概念。它是一条平滑的微分方程路径,能近似梯度下降的时间平均轨迹(而非含振荡的瞬时轨迹)。中心流通过添加一个与振荡协方差 Σ(t) 相关的正则项来模拟振荡对长期路径的影响: [ \frac{dw}{dt} = -\eta \left[ \nabla L(w) + \frac{1}{2} \nabla_w \langle H(w), \Sigma(t) \rangle \right] ] 其中 Σ(t) 由半定互补问题求解得出,确保 Hessian 特征值不超过 2/η。当无特征值处于 EOS 时,中心流退化为标准梯度流。

  • 中心流的优势与验证

    • 平滑性与可预测性:中心流消除了振荡,使损失下降单调,网络预测等演化平滑。梯度下降的长期损失轨迹可由中心流损失加上与 Σ(t) 迹相关的振荡贡献项精确预测。
    • 实验验证:在多种架构(如视觉与序列模型)和任务上,中心流能准确拟合梯度下降的时间平均损失和梯度范数,验证了其作为通用分析工具的有效性。
    • 理论意义:中心流将振荡视为围绕长期路径的噪声,而长期路径本身具有简洁的数学描述,为理解深度学习优化提供了新视角。

总之,文章阐明了梯度下降在深度学习中通过边缘稳定性和三阶效应实现自我调节的机制,并提出中心流作为描述其长期行为的简洁框架,弥补了传统理论的不足。

14. Self-hosting email like it's 1984 (maxadamski.com)

文章摘要:自托管电子邮件服务器指南

核心观点

文章分享了作者自托管电子邮件服务器的实践经验,强调其实用、低成本和可控性。作者认为,尽管面临邮件投递率等挑战,但通过简化配置(如不设置Webmail、使用命令行客户端),可以在几小时内完成基础搭建,实现自动化任务(如邮件列表、通知)。

关键步骤与配置

1. 基础设置

  • 软件:仅需安装 Postfix(SMTP服务器)和 OpenDKIM(邮件认证),无需IMAP/POP3或数据库。
  • 端口:开放端口25。
  • 用户交互:通过SSH使用 s-nail 等命令行工具在服务器上收发邮件,简化了系统复杂性。

2. Postfix 配置要点

  • 配置文件 (/etc/postfix/main.cf) 定义了主机名、域名、邮件别名、网络访问控制(仅限本地主机)、TLS加密以及OpenDKIM集成。
  • 强制启用 TLS加密 以保护邮件在传输中的安全。
  • 隐藏服务器信息以增强安全性(如禁用VRFY命令)。

3. TLS证书管理

  • 目的:仅为MX主机(如 mx.example.com)申请证书,用于SMTP服务器间的STARTTLS加密。邮件域名的认证依赖于SPF和DKIM。
  • 工具:推荐使用 acme.sh 从Let’s Encrypt获取免费证书。
  • 自动化:通过Nginx提供验证文件,并设置cron任务实现证书自动续期。

4. DNS记录与邮件认证

为确保邮件被Gmail等主流服务成功接收,需正确配置以下DNS记录:

  • DKIM:为每个邮件域名生成密钥对,并在DNS中发布公钥。
  • SPF:声明允许发送邮件的主机。
  • DMARC:制定策略(如拒绝未认证邮件)并指定报告接收地址。
  • MX记录:指向邮件服务器主机。
  • 反向DNS (PTR记录):需由ISP设置,能显著提升服务器信誉,但作者发现即使没有,邮件也能送达部分服务商。

5. 投递测试与接收

  • 发送测试:使用 sendmail 命令向Gmail发送测试邮件。
  • 验证:在Gmail中查看邮件原始内容,确认SPF、DKIM、DMARC验证通过。
  • 接收邮件:在服务器命令行使用 s-nail 客户端查看和回复邮件,并提供了个性化的 .mailrc 配置示例。

潜在扩展

作者提及了未来可能的功能扩展:

  • 使用Python脚本收发邮件。
  • 设置SMTP远程提交。
  • 添加POP3和IMAP支持(例如使用Dovecot)。
  • 部署自托管的Webmail界面。

总结

该指南提供了一条精简、高效的自托管邮件服务器路径。其核心在于接受“命令行收发”的极简模式,并通过精心配置Postfix、OpenDKIM、TLS证书和DNS记录,实现可靠的基础邮件功能与良好的投递率。整个方案强调轻量化和自动化,适合希望以最低成本获得邮件服务器控制权的用户。

15. Jules, remote coding agent from Google Labs, announces API (jules.google)

Jules 远程编程智能体功能更新摘要

Jules 是由 Google Labs 推出的远程编程智能体,旨在自动化处理 GitHub 仓库中的编码任务。以下是其核心功能、模型演进与集成能力的更新概览。

核心功能

  • 自主任务执行:Jules 能在云端开发环境中自动完成 bug 修复、依赖更新、代码迁移和新功能开发,并生成可运行的拉取请求。
  • 工作流程:自动创建开发环境、安装依赖、编写测试、实施修改、运行测试并提交 PR,全过程透明可追踪。
  • 问题解决范围:涵盖 bug 修复、版本升级、代码转换、跨框架迁移及功能开发。

模型与智能升级

  • 模型演进:从最初的 Gemini 2.5 Pro 逐步升级至 Gemini 3 Flash(2026年1月,更快的默认模型),后引入 Gemini 3 Pro(2025年11月,增强推理与规划能力),最新更新将 Gemini 3.1 Pro 设为 Pro 用户默认模型(2026年3月,更强大的复杂问题解决能力)。
  • 智能代理增强
    • Critic Agent(2025年8月):对生成的代码进行对抗性审查,提高代码质量。
    • Planning Critic(2026年1月):对自动批准的计划进行二次审查,降低任务失败率。
    • Interactive Plan(2025年8月):与用户交互澄清需求,共同制定计划。

集成与扩展能力

  • MCP 服务器支持(2026年2月):集成 Linear、Stitch、Neon 等服务,通过 API 密钥认证,在任务中按需调用工具。
  • CI/CD 与部署集成
    • 自动修复 CI 失败(2026年2月):自动检测并修复 GitHub Actions 中的 PR 检查失败。
    • Render 集成(2025年12月):检测构建失败、分析日志并自动修复。
  • 数据与工具集成:支持 Web 搜索获取文档(2025年8月),可上传图像作为视觉上下文(2025年9月)。

自动化与调度功能

  • 定时任务(2025年12月):可设置定期维护任务(如依赖检查),Jules 自动执行并提交 PR。
  • 建议任务(2025年12月):主动扫描代码库,识别 TODO 注释和性能优化点,并提出解决方案。
  • GitHub 问题触发(2025年6月):为 GitHub Issue 添加 jules 标签即可自动创建任务。

用户控制与定制

  • 提交作者控制(2026年2月):可设置 GitHub 提交作者为 Jules、共同作者或用户本人。
  • 环境变量(2025年10月):在仓库级别为 Jules 提供环境变量,用于构建或测试。
  • 文件选择器(2025年9月):指定任务涉及的特定文件,缩小上下文。
  • 记忆功能(2025年9月):Jules 学习用户偏好,在相似任务中应用历史反馈。

API 与开发者工具

  • REST API(2025年10月):支持通过编程创建任务(Session),实现与 Slack、Linear 等的集成。
  • 无仓库支持(2026年1月):可通过 API 快速启动无关联仓库的临时开发环境。
  • 命令行工具(2025年10月):提供 jules CLI,支持任务管理、补丁本地应用及脚本集成。

用户界面与体验优化

  • 代码审查增强:堆叠式 diff 视图(2025年9月)、图像渲染(2025年8月)、实时 Critic 分析可视化(2025年9月)。
  • 任务管理:支持暂停、恢复、删除任务(2025年7月),可随时导出代码到 GitHub(2025年8月)。
  • PR 反馈响应(2025年9月):能读取 PR 评论并提交相应修改。

基础设施与稳定性

  • 虚拟机升级(2025年8月):磁盘空间增至 20GB。
  • 环境快照(2025年8月):保存环境配置,加速后续任务启动。
  • 运行时支持:默认环境包含 Node、Python、Rust、Bun 等,并支持 Playwright 用于前端测试(2025年8月)。
  • 性能与可靠性:持续优化任务执行速度、减少失败情况,并改进 GitHub 同步机制。

Jules 持续扩展其自动化能力,通过模型升级、深度集成和用户可控配置,致力于成为更强大、灵活的自主编程助手。

16. ICE Wants to Build Out a 24/7 Social Media Surveillance Team (www.wired.com)

美国移民海关执法局(ICE)计划大幅扩展社交媒体监控能力,拟雇佣近30名承包商组建全天候监控团队。该计划旨在通过监控Facebook、TikTok、Instagram等社交平台,将公开帖子、照片和消息转化为执法线索,用于驱逐突袭和逮捕行动。

监控计划核心内容

  • 团队配置:计划在佛蒙特州威利斯顿的国家犯罪分析和定位中心部署12名承包商,负责美国东部地区案件;在加利福尼亚州圣安娜的太平洋执法响应中心部署16名承包商,实行24/7不间断运作。
  • 工作模式:承包商将接收线索,在线调查个人资料,并将结果整理成档案供现场办公室策划逮捕使用。
  • 技术工具:承包商将使用LexisNexis Accurint、Thomson Reuters CLEAR等商业数据库,并计划引入人工智能算法强化监控。
  • 时效要求:紧急案件(如国家安全威胁)需在30分钟内完成研究;高优先级案件1小时;低优先级案件需在当天完成。ICE要求至少75%的案件符合时限,优秀承包商需达到95%。

数据收集与隐私争议

  • 数据范围:监控涵盖公共社交媒体内容,也包括俄罗斯VKontakte等境外平台,承包商还需使用商业数据库整合财产记录、电话账单、车辆登记等个人信息。
  • 过往案例:ICE此前曾计划自动扫描社交媒体上的“负面情绪”,并与间谍软件公司Paragon签订合同(该合同曾被冻结后又重启),还使用Clearview AI的人脸识别技术构建数据库。
  • 法律与隐私问题:隐私倡导者警告此类监控可能滥用,例如将信息用于针对移民、记者和活动人士。电子隐私信息中心起诉ICE称其依赖数据经纪人对隐私构成威胁,美国公民自由联盟指出ICE通过购买大量数据规避搜查令要求。

历史背景与系统整合 ICE近年来持续扩大监控体系,包括购买ShadowDragon的社交网络分析工具、Babel Street的定位历史服务,并一直依赖Palantir的案件管理系统整合数据流。新增社交媒体监控将作为人力补充,将海量数据转化为可执行的执法线索。

ICE在规划文件中称,整合开源和社交媒体信息有助于识别别名、追踪行动并发现传统方法遗漏的模式。然而,批评者认为此类从针对移民起步的监控可能被扩大用于其他目的,并可能收集大量超出其法定权限的信息。

17. Cancelling async Rust (sunshowers.io)

异步 Rust 中的取消机制

本文探讨了异步 Rust 中“取消”这一强大但复杂特性。取消指的是在异步操作开始后决定中止它。在异步 Rust 中,取消非常容易实现,只需丢弃(drop)一个 Future 即可,因为 Future 在被轮询(poll)或等待(await)之前只是惰性的数据结构。

1. 什么是取消?

  • 核心机制:异步 Rust 中的取消通过丢弃 Future 来实现。当一个 Future 被丢弃时,它所包含的子 Future 也会因所有权机制被丢弃,导致取消向下传播。
  • 与其他语言的区别:与 JavaScript、Go 等语言中的 Future(创建即开始执行)不同,Rust 的 Future 是被动、惰性的,仅在 await 或被轮询时才推进。
  • 双刃剑:虽然易于取消是异步 Rust 的一大优势,但也使得取消过于容易发生,且其影响(非局部性推理)难以分析。

2. 分析取消

理解取消需要区分两个概念:

  • 取消安全性:一个 Future 的本地属性,指该 Future 被取消(丢弃)时不会产生副作用。例如,tokio::time::sleep 是取消安全的,而 tokio::sync::mpsc::Sender::send 不是,因为消息会丢失。
  • 取消正确性:系统的全局属性,指在发生取消时,系统没有违反任何重要不变量或导致错误(如数据丢失)。一个取消正确性 bug 的出现需要满足三个条件:系统中存在非取消安全的 Future;该 Future 被实际取消;且该取消破坏了系统属性。

典型问题示例

  • 消息丢失:在循环中使用 timeout 包裹 channel.send(),若在发送期间超时,Future 被取消,导致消息永久丢失。
  • 状态损坏:使用 Tokio 互斥锁时,常见的模式是在持有锁期间临时使数据处于无效状态(例如,将 Option 置为 None),然后在某个异步操作后恢复。如果在恢复操作之前的 await 点被取消,数据将永久停留在无效状态,且此分析需要追踪整个调用链。

常见的取消触发模式

  • 未对 Future 调用 .await(编译器会警告)。
  • 使用 let _ = some_async_work(); 忽略返回的 Result 而忘记 .await
  • 使用 try_join! 宏时,若一个 Future 失败,其余 Future 会被取消。
  • 使用 tokio::select! 宏时,未被选中的分支 Future 会被取消,这在 select 循环中尤其容易引发问题。

3. 如何应对

目前没有通用的完美解决方案,但有以下缓解策略:

使 Future 变为取消安全

  • 通道发送:将 tx.send(msg) 拆分为两步:先 tx.reserve() 获取一个“许可证”(此操作取消安全),再使用许可证发送消息。这样即使 reserve 被取消,也不会丢失消息。
  • 异步写入:使用 write_all_buf 代替 write_all。前者操作一个带有游标的缓冲区,能报告部分写入进度,实现取消安全。

避免取消 Future

  • 恢复 Future:在 select 循环中,通过对 Box::pin 的 Future 使用 &mut 来恢复执行,而非每次循环都重新创建,从而避免丢失排队位置等副作用。
  • 使用任务:对于不应被取消的关键操作,使用 tokio::spawn 将其作为独立任务运行。任务的完成不依赖于其句柄(handle)是否被丢弃。

系统性与未来展望

  • 根本挑战:当前异步取消机制违背了 Rust 所强调的、可通过局部代码理解全局行为的设计哲学。
  • 可能的方向:社区已提出一些更系统的解决方案构想,如 async drop(允许在取消时运行异步清理代码)或“线性类型”(可强制 Future 运行至完成或要求必须执行某些操作)。但这些方案均面临重大的实现挑战。

总结

  • 核心建议:避免使用 Tokio 互斥锁(如使用,请极度谨慎);通过 API 设计提高 Future 的取消安全性;确保非取消安全的 Future 能够运行完成。
  • 根本认知:异步 Rust 中的取消是一个强大但需要精心处理的特性。开发者必须意识到其非局部性推理的特点,并采用上述模式来编写健壮的异步代码。
18. Removing these 50 objects from orbit would cut danger from space junk in half (arstechnica.com)
  • 现状与趋势:当前在轨危险火箭体主要来自中国。在最近21个月新增的26个此类物体中,有21个是中国发射的废弃上面级,平均重量超过4公吨。随着中国“国网”(Guowang)和“千帆”(Thousand Sails)两大巨型卫星星座的部署,未来将进行数百次发射。然而,大部分发射用火箭的上面级被遗留在轨道上,例如为这些星座发射服务的9个上面级将在轨停留超过25年,违反了国际准则。文章预测,如果中国继续目前的做法,未来几年将留下远超100个违反25年规则的火箭体,太空碎片趋势令人担忧。

  • 原因与矛盾:遗留火箭体有技术和实际原因:部分老式中国火箭无法在太空中重启发动机;即使有能力,为离轨燃烧保留燃料会减少火箭的有效载荷能力,从而导致单次发射携带的卫星数量减少。

  • 中国的能力与实践:中国具备不遗留火箭体的技术能力。例如,搭载“国网”卫星的长征五号火箭使用了YZ-2上面级,该上面级可在任务结束后自行离轨。然而,在其他类型的火箭发射中,它们“总是会留下火箭体”。作者指出,中国平均而言并未践行可持续的做法。

  • 长期影响:自2000年以来,中国在长期轨道上积累的废弃火箭质量已超过世界其他国家总和。而随着近期巨型星座的部署,这一积累正在加速。

19. The Buchstabenmuseum Berlin is closing (www.buchstabenmuseum.de)

柏林字母博物馆宣告关闭

核心状态:位于柏林的字母博物馆自2025年起正式关闭。然而,其收藏被强调为世界级且独一无二的文化资产。

收藏的数字化与未来

  • 作为2024年资助项目的一部分,超过100件精选藏品已被数字化,并正式成为柏林官方文化遗产的一部分。
  • 博物馆明确表示不会拆分或出售其庞大的收藏。他们的长期目标是确保该收藏留在柏林,并未来重新向公众开放
  • 博物馆将继续致力于扩展、维护和保存其收藏。最新的动态将通过Instagram或Facebook发布。

近期活动与展览

  • 20周年庆典:博物馆计划于2025年6月14日(周六)下午3点至9点庆祝成立20周年。届时将发布一本纪念册,并举办一场关于柏林S-Bahn拱廊建筑用途与潜力的讲座。
  • 当前展览:“FINAL SALE——从百货商店到博物馆”展览将延长展期至2025年秋季。该展览通过文字讲述德国城市中正在消失的百货商店(如Karstadt、Kaufhof)及其标识的排版与城市历史故事。

博物馆宗旨与特色

  • 字母博物馆是全球首个致力于收集、保存和记录公共空间三维字母与标识的博物馆,将其作为城市历史的一部分进行展示。
  • 博物馆与LucasFonts合作,将馆藏物品制作成独特的开源字体(OTF),供公众免费下载。
  • 其“BM-Studio”团队可为活动或建筑提供字母标识方面的专业支持。

寻求支持:博物馆正在为新址寻找紧急支持,并呼吁公众通过“betterplace”平台提供资助,或通过成为会员来积极参与和支持博物馆的各项活动(如历史标识的救援工作)。

20. Interstellar Object 3I/Atlas Passed Mars Last Night (earthsky.org)

星际天体 3I/ATLAS 观测与科学总结

天体概述与轨道轨迹

3I/ATLAS 是人类发现的第三个星际天体,于2025年7月被发现并确认为彗星。它于2025年10月29日到达近日点(距太阳约1.36 AU),并于12月19日到达近地点(距地球约1.8 AU),目前正离开太阳系。其飞行速度约21万公里/小时,创下太阳系访客的速度纪录。

物理特征与加速机制

观测证实 3I/ATLAS 具备典型彗星特征,拥有气体和尘埃组成的彗发,并在靠近太阳后产生多股喷流与复杂彗尾。哈勃望远镜数据显示其彗核直径约5.6公里,最小可能仅320米。科学家证实其非引力加速度并非来自“外星引擎”,而是冰物质升华产生的排气作用。

多方联合观测

全球众多设备对其进行了密集观测:

  • 空间探测器:火星勘测轨道飞行器(MRO)在3100万公里外拍摄了图像;ExoMars TGO、MAVEN、SOHO、PUNCH 及 JUICE 等探测器均捕捉到其影像或光谱数据。
  • 望远镜:双子座望远镜、哈勃空间望远镜及天体摄影师记录下了其清晰的彗发与彗尾结构。

起源追溯与科学意义

天文学家利用盖亚(Gaia)数据追溯其千万年轨迹,推测其源自银河系薄盘,但未发现具体扰动其轨道的母恒星。研究表明其年龄可能超70亿年,早于太阳系形成。作为星际冰质星子的探针,它为研究银河系行星形成效率、挥发物分布及系统演化提供了关键数据。

观测指南与未来探测

该天体肉眼不可见,需使用至少8英寸口径望远镜在黎明前的东方天空观测。因其速度过快,目前无法发射专属航天器拦截,但欧洲航天局(ESA)未来的“彗星拦截器”任务将旨在探测未来的星际访客。

21. The collapse of the econ PhD job market (www.chrisbrunet.com)

经济学博士就业市场崩溃

市场现状

  • 职位数量锐减:通过美国经济学会的JOE平台显示,经济学相关职位数量从2022年的1477个降至2025年的约1000个,三年内下降32%。
  • 学术职位竞争激烈:终身教职(tenure-track)岗位从2022年的631个降至2025年的约400个,下降35%。同期EJM数据显示面试邀请数量从3835降至2502,降幅34.8%。
  • 供需严重失衡:2024年美国有1385人获得经济学博士学位,加上大量国际候选人,导致约5341人竞争有限的职位。美国新博士获得终身教职的比例仅约7%,即使最乐观估计也不超过10-20%。

主要原因

  1. 本科招生减少:经济学专业本科生人数持续下降,导致高校教师需求减少。
  2. 人口结构变化:美国正面临“人口悬崖”,大学适龄人口减少,加剧院系间的生源竞争。
  3. 人工智能崛起:AI技术可自动化数据清理、计量建模等任务,减少对初级研究人员的需求。
  4. 通胀问题损害信誉:疫情期间经济学家对通胀的误判削弱了公众和机构对该专业的信任。

传统就业领域萎缩

  • 政府部门:联邦机构因预算限制和政策调整大幅削减经济学家职位。
  • 国际组织:IMF、世界银行等机构职位竞争全球性加剧,且面临招聘冻结。
  • 科技行业:疫情期间的招聘热潮已退,自动化降低了对经济学家的需求。
  • 金融领域:银行业更倾向于招聘MBA、统计学家或计算机科学家,而非经济学博士。

行业反应与展望

  • AEA在2025年报告中承认就业市场“充满挑战”。
  • 顶尖院校(如哈佛、MIT、芝加哥等)毕业生仍占据优势,但其他院校学生就业前景严峻。
  • 建议博士项目缩减招生规模,候选人需提前规划非学术职业路径。
  • 可能出现知识传播去中心化趋势(如更多人转向Substack等平台)。

数据来源:JOE平台、EJM非营利组织、NSF调查、AEA报告及行业分析。

22. Scientists are discovering a powerful new way to prevent cancer (www.economist.com)

癌症通常被认为始于正常细胞的DNA突变,这种突变导致细胞逃脱质量控制,不受限制地增殖,最终形成肿瘤并转移至全身。

然而,最新研究揭示了一种全新的癌症预防视角。文章暗示,科学家正发现一种强大的新方法,可能挑战传统对肿瘤起源的理解。从配图内容推测,这种新方法可能与免疫系统或肿瘤微环境的作用密切相关,例如利用免疫细胞识别并清除早期异常细胞,从而在肿瘤形成之前进行干预。

这一进展意味着癌症防治的重点或许可以从治疗已发生的肿瘤,转向更早期、更根本的阻断机制,为预防医学开辟新途径。

23. Working pipe operator today in pure JavaScript (github.com)

asPipes:纯JavaScript中可用的管道操作符

概述

asPipes是一个实验性的运行时抽象,旨在完全使用标准JavaScript(ES2020+)实现提议中的 |> 管道操作符的语义。它展示了如何利用位运算符 | 的现有强制类型转换语义和 Symbol.toPrimitive 来实现管道式的函数组合。该实现轻量(少于50行代码),并支持同步和异步计算,语法直观:

const greeting = pipe('hello');
greeting | upper | ex('!!!');
await greeting.run(); // → "HELLO!!!"

动机

该项目旨在:

  • 在当前的JavaScript中原型化F#风格的管道语义。
  • 在实际代码中研究其人体工程学和可读性。
  • 证明无需语法扩展即可实现延迟、引用透明的函数组合。
  • 通过实际的用户层面反馈为管道操作符(tc39/proposal-pipeline-operator)的设计讨论提供信息。

设计目标

  • 可组合:每个转换都像前一个结果的一元函数。
  • 延迟执行:直到调用 .run() 前不会执行。
  • 异步安全:Promise和async函数是原生支持的一等公民。
  • 无状态:无全局变更;每个管道拥有自己的上下文。
  • 人体工程学:视觉上与未来的 |> 操作符对齐。

核心API

  • createAsPipes():创建一个隔离的管道环境,返回 { pipe, asPipe }
  • pipe(initialValue):以 initialValue 开始一个新管道。返回的对象通过 Symbol.toPrimitive 拦截 | 操作。调用 .run() 以异步方式评估并获取最终结果。
  • asPipe(fn):包装函数 fn 使其可在管道中使用。支持在管道中调用时传递参数。

工作原理与关键特性

  1. 核心原理:利用JavaScript的强制类型转换系统拦截 | 运算符。当执行 pipe(x) | fn 时,| 操作会强制将右侧(由 asPipe 创建的令牌)转换为原始值,这通过 Symbol.toPrimitive 实现,从而注册转换步骤。
  2. 延迟执行:通过显式的 .run() 方法触发,将累积的步骤列表折叠成一个Promise链(value₀ → step₁(value₀) → step₂(value₁) → … → result),严格从左到右执行。
  3. 异步支持:步骤可以返回值或Promise,步骤间会自动进行Promise解析。
  4. 可组合管道:可以使用 asPipe 将多个管道组合成可重用的高阶管道,实现复杂逻辑的抽象和封装。
  5. 对象方法管道化asPipe 可以应用于对象(如 Math 或自定义对象),将其所有方法转换为管道可用的形式。
  6. 流处理:通过 aspipes/stream.js 模块提供支持,允许使用 mapfiltertakescanreduce 等操作处理异步生成器流,实现函数式响应式编程模式。

示例摘要

  • 字符串/数字处理:基本管道操作演示。
  • 异步API调用:演示如何管道化处理网络请求(如调用LLM API)的JSON响应。
  • 高阶管道:将 askBotsummarize 等管道组合成更复杂的 researchAgent
  • 流处理:演示如何从无限异步生成器事件流中过滤、映射并取前N个特定事件。

限制与思考

  • 限制:右侧仅支持可管道化的令牌,不支持任意表达式;过度使用可能使工具或代码检查器困惑;纯属演示,不适用于生产环境
  • 设计思考:为何使用 Symbol.toPrimitive、为何选择 | 运算符、为何需要显式 .run()
  • 开放性问题:关于未来ECMAScript原生支持、静态分析器支持、管道提案的借鉴以及 .run() 是否应隐式执行等讨论。

结论

asPipes不是一个语法提案,而是一个运行时原型——一个生动的例子,展示了JavaScript如何利用已标准化的功能来尽可能接近未来的语言构造。它证明了管道语义在实践中是可组合且符合人体工程学的,异步行为可以自然集成,并且今天就可以验证 |> 语法的可读性和认知流程。

许可:MIT © 2025

24. Orcas are bringing humans gifts (www.newscientist.com)

虎鲸向人类赠送礼物

研究人员观察到虎鲸似乎将已死亡的猎物作为礼物赠送给人类,这可能表明它们具有利他主义行为,并能识别其他物种的感知能力。

行为发现与案例记录

  • 初始事件:2015年,研究人员贾里德·陶尔斯在加拿大拍摄时,目睹两只虎鲸(阿克拉和奎弗)主动将口中衔着的死鸟放在他面前,并停留观察其反应。2018年,另一只年幼雌性虎鲸向他赠送了一只港海豹幼崽。
  • 案例收集:受这些事件启发,陶尔斯系统记录了2004年至2024年间的34起类似案例,涉及18种不同的猎物,包括海鸟、海豹、水母、海獭、鳐鱼、海星、海龟以及一缕海藻。案例分布于加拿大、新西兰、挪威等地,由不同研究者观察记录。

行为特征与解释

  • 跨物种互动:虎鲸通常会在亲密的社群内部分享猎物,但观察显示它们将这种行为扩展到了人类。
  • 广义利他主义:专家认为,这表明虎鲸能够进行超越自身物种的利他行为,表现出对其他物种的“善意”。
  • 认知能力体现:陶尔斯指出,该行为显示虎鲸能够识别其他物种的感知能力,并具备探索和实验的勇气。此外,这亦被视为虎鲸具有“心理理论”的证据,即理解他者拥有独立心理状态的能力。
  • 行为驱动力:虎鲸作为高度社会化的捕食者,拥有过剩猎物时,可能会通过赠送行为来探索环境关系。好奇心有助于降低不确定性,它们可能正在通过“试探”来了解人类。

总结

虎鲸向人类赠送猎物的行为,不仅揭示了其复杂的社交与利他倾向,也反映了其高级认知能力,包括对其他物种感知状态的识别及跨物种互动的学习与探索。

25. Thunderscan: A clever device transforms a printer into a scanner (2004) (www.folklore.org)

Thunderscan:将打印机转变为扫描仪的巧妙设备 (2004)

Thunderscan是1980年代中期由Thunderware公司开发的一款创新产品,它能临时将当时流行的ImageWriter点阵打印机转变为一台高分辨率扫描仪。其核心创意在于用一个光学传感器替换掉打印机的色带盒,并通过配套软件控制打印机进行扫描,而非打印。

核心技术与优势:

  • 硬件改造:Thunderscan硬件是一个包含光学传感器的装置,可替代ImageWriter打印机的色带盒。
  • 软件驱动:扫描过程由软件精确控制打印机的步进电机来移动纸张。由于ImageWriter打印机的步进电机精度极高(用于实现精细图形打印),Thunderscan得以实现很高的扫描分辨率,远超过当时价格昂贵十倍以上的平板扫描仪。
  • 经济性:整个系统售价低于200美元,为Macintosh用户提供了一种高性价比的高质量图像输入方案。

主要挑战与解决方案:

  1. 扫描速度慢:由于每次打印头移动只能采集一行数据,扫描一页在最高分辨率下需要超过一小时。
  2. 图像质量优化:初代原型在Apple II上的软件演示效果不佳,灰度渲染粗糙。作者(可能是Andy Hertzfeld)接手为Macintosh开发软件后,引入了改进的“Floyd-Steinberg”抖动算法,利用Macintosh更强的计算能力,显著提升了灰度图像的显示质量。
  3. 技术细节攻关
    • 解决了打印机纸张进给控制问题,采用“进三退二”的步进方式以保持纸张平整。
    • 实现了双向扫描以提升速度(扫描头左右移动时均工作),尽管这需要对齐校准,用户可选择开启。
    • 开发了“惯性滚动”功能,方便用户快速浏览大尺寸扫描文档。
    • 软件保留了5位/像素的灰度原始数据,允许用户后期调整图像对比度、亮度,并为后来实现灰度打印和显示奠定了基础。

市场表现与历史意义: Thunderscan于1984年12月上市,初期月销量约1000台,1987年达到7500台的峰值,产品生命周期内总销量约10万台。它长期作为Macintosh上最便宜且质量最佳的扫描解决方案,尽管速度是其明显短板。随着技术发展,成本更低、更便捷的平板扫描仪最终取代了它。Thunderscan以其巧妙的软硬件结合设计,体现了早期个人计算机时代“通过软件优化硬件”的工程智慧(类似于Apple II的Silentype打印机项目),为早期Macintosh用户提供了重要的图像数字化能力。

26. Alibaba cloud FPGA: the $200 Kintex UltraScale+ (essenceia.github.io)

阿里云FPGA开发板($200 Kintex UltraScale+)使用指南

本文记录了作者将一块以200美元购得的退役阿里云FPGA加速卡(型号AS02MC04)改造为可用开发板的全过程,重点阐述了在缺乏官方文档和支持的情况下,如何利用开源工具链完成硬件验证、调试接口连接、引脚确认及比特流烧录。

硬件概况与选购背景

  • 核心芯片:板载Xilinx Kintex UltraScale+ XCKU3P FPGA(FFVB676封装)。
  • 关键接口:具备2个SFP+光口、一个PCIe x8接口以及一个非标准的6针JTAG调试接口。
  • 价格优势:二手价格仅200美元,相较于全新的Alinx同系列开发板(900-1050美元),成本优势巨大。
  • 主要挑战:板卡无任何技术文档,无法保证工作状态,且需要绕过Xilinx官方工具链(如Vivado企业版License)进行开发。

硬件功能验证

  1. 基础供电:使用附带的12V电源适配器,通过观察LED状态和FPGA表面温度,确认板卡基本供电正常。
  2. PCIe接口测试
    • 将板卡通过PCIe转接卡连接至树莓派5(提供PCIe Gen 2.0 x1接口)。
    • 在Linux系统下通过 dmesglspci 命令成功识别到PCIe设备。
    • 设备被识别为以太网控制器(类 0x020000),厂商ID dabc(非公开分配,符合自定义FPGA设计的特征)。
    • 链路能力报告为PCIe Gen 3.0 x8,但由于树莓派接口限制,实际以Gen 2.0 x1模式运行。这证实了PCIe接口工作正常。

调试接口(JTAG)连接与工具链搭建

  • 调试器选择:放弃昂贵的官方JTAG探针,采用开源的OpenOCD软件配合Segger J-Link硬件调试器。
  • 接线方式:根据实物辨识出JTAG的TCK、TMS、TDI、TDO四个信号引脚,并用杜邦线连接至J-Link。由于引线较长,将JTAG时钟频率设置为1MHz(探测时)和10MHz(烧录时)以保证信号完整性。
  • 扫描链识别:使用OpenOCD的自动探测功能,成功识别出扫描链上唯一的设备,其IDCODE 0x04a63093 与XCKU3P的技术手册相符。确认了JTAG接口可用且FPGA型号正确。

引脚确定与时钟分析

  • 引脚来源:作者找到了一份疑似泄露的详细引脚图(博客地址),并参考了社区其他开发者的修正信息。
  • 时钟资源
    • 全局时钟:位于Bank 67的一对差分引脚(E18/D18),提供100MHz时钟,可用作设计的主时钟源。
    • 收发器参考时钟:位于Bank 227的一对差分引脚(K7/K6),提供156.25MHz时钟,专用于SFP+光口的GTY高速收发器。
  • 其他引脚:包括SFP+的控制信号(MOD_DEF、LOS、TX_FAULT)、LED指示灯、I2C总线以及PCIe的参考时钟和数据引脚等,均已在引脚表中明确。

设计实现与比特流烧录

  • 自动化工作流:作者建立了一套基于命令行和Makefile的Vivado自动化流程,包括项目创建、综合布局布线、生成比特流及SVF文件。
  • 烧录过程
    1. Vivado根据设计生成包含配置序列的SVF文件。
    2. OpenOCD通过J-Link加载并执行该SVF文件,将比特流通过JTAG写入FPGA的配置锁存器。
    3. 烧录过程中,作者编写的OpenOCD脚本还可读取FPGA内部的SYSMON4寄存器,实时报告芯片温度(如31.12°C)和关键电压(如VCCINT 0.852V),作为运行状态监控。
  • 结果:OpenOCD日志显示SVF文件处理成功,FPGA配置完成

社区补充信息与开源项目支持

  • 注意事项:后续社区开发者发现,部分板卡的SFP模块可能损坏;一些标注为LVCMOS18的I/O Bank实际可能支持3.3V电平;板卡上可能存在可通过贴片电阻焊盘引出的额外GPIO。
  • 开源项目支持:高性能开源网卡项目Corundum已宣布支持此阿里云板卡,为需要快速实现PCIe和以太网功能的用户提供了现成方案。

总结

本文成功展示了一条低成本获取并使用高端Xilinx FPGA开发板的技术路径:通过二手市场购得退役硬件,利用OpenOCD等开源工具替代商业调试器,自行确定引脚并建立自动化编译烧录流程,最终以远低于市场的成本(200美元 vs 900+美元)获得一个功能完整的Kintex UltraScale+开发平台。

27. Google removes ICE-spotting app following Apple's ICEBlock crackdown (www.theverge.com)

谷歌在苹果下架ICEBlock追踪应用一天后,已从谷歌Play商店移除了类似应用Red Dot。谷歌向404 Media证实,移除原因是这些应用共享了一个“脆弱群体”的位置信息,且近期有针对该群体的暴力事件与应用相关。

此前,苹果因司法部施压,于周四下架了ICEBlock及包括Red Dot在内的类似应用。司法部长Pam Bondi对福克斯新闻表示,ICEBlock被设计为将ICE探员置于风险之中,针对执法的暴力行为不可容忍。ICEBlock开发者Joshua Aaron则称该应用受言论自由保护,并指责苹果“向威权政权屈服”。

ICEBlock和Red Dot均允许用户匿名举报ICE探员的踪迹并查看附近举报。Red Dot网站说明其结合了用户举报与“多个可信来源的核实报告”来监测ICE活动。

谷歌表示未收到司法部警告,但其政策禁止高滥用风险的应用,并对包含用户生成内容的应用有内容审核要求。谷歌强调ICEBlock从未在谷歌Play上架,但因违反政策移除了类似应用。

28. New antibiotic targets IBD and AI predicted how it would work (healthsci.mcmaster.ca)

研究人员发现了一种针对炎症性肠病(IBD,如克罗恩病)的新型抗生素,并首次利用人工智能(AI)准确预测了其作用机制。该研究成果于2025年10月3日发表在《自然·微生物学》期刊上。

1. 新型抗生素“恩特罗洛林”的特点

  • 靶向治疗:与传统的“广谱”抗生素不同,恩特罗洛林是一种“窄谱”抗生素。它只针对特定的致病菌群——肠杆菌科(包括大肠杆菌),从而保护肠道中有益的微生物群。
  • 治疗前景:这种靶向性不仅能杀死致病菌,还能减少耐药菌在肠道定植的机会,为数百万IBD患者提供了新的潜在治疗选择。目前IBD尚无治愈方法,新药旨在显著缓解症状。

2. AI在药物作用机制研究中的突破性应用

  • 解决关键瓶颈:AI在药物发现中已用于筛选分子,但此项研究首次利用AI预测新药的作用机制。药物作用机制研究至关重要,但传统方法耗时长达两年、成本约200万美元。
  • 高效验证:研究团队与MIT合作,使用名为DiffDock的AI模型,在100秒内预测出恩特罗洛林的作用靶点是细菌生存必需的LolCDE蛋白复合物。
  • 大幅加速研发:基于AI的预测,团队在6个月内、仅花费6万美元就完成了机制验证,将研发时间缩短了一年半,成本显著降低。

3. 研发与商业化进展

  • 机制验证:MIT的AI预测已被实验室的后续实验完全证实。
  • 商业化路径:研究人员成立的公司Stoked Bio已获得恩特罗洛林的授权,正在对其进行优化以用于人体,并同时测试其对抗其他耐药菌(如克雷伯菌)的效果。
  • 未来计划:如果进展顺利,该新药有望在三年内进入人体临床试验阶段。

此项研究不仅为IBD治疗带来了新希望,也展示了AI在加速药物发现全过程(从筛选分子到阐明作用机制)中的强大潜力。

29. AMD's EPYC 9355P: Inside a 32 Core Zen 5 Server Chip (chipsandcheese.com)

AMD EPYC 9355P:32核Zen 5服务器芯片深度解析

核心设计理念:EPYC 9355P并非简单降低核心数的SKU,而是通过多项设计优化来最大化单核性能,适用于无法充分利用最高核心数处理器或更注重单核性能的应用场景。

关键架构特性

  1. 高主频与缓存比例
    • 最高频率达4.4GHz,高于128核/192核SKU(3.7-4.1GHz)。
    • 采用8个CCD(核心复合体),每个CCD仅启用4个核心,但保留完整的32MB L3缓存。这使得缓存容量与核心数的比值很高
  2. GMI-Wide互连
    • 每个CCD与IO芯片之间采用GMI-Wide(全局内存互连-宽模式)连接,为每个CCD提供64字节/周期的双向带宽。
    • 相比之下,桌面级(如Ryzen 9 9900X)的GMI-Narrow模式带宽较低。GMI-Wide显著提升了CCD与系统其他部分之间的带宽上限,并改善了高负载下的延迟控制

平台与测试配置

  • 测试在配备该芯片的Dell PowerEdge R6715服务器上进行。
  • 配置了768GB DDR5-5200内存,理论内存带宽近500GB/s。

内存与NUMA性能

  1. NUMA模式
    • NPS1模式:将整个芯片视为一个单体内存域,提供一致的内存视图。其DRAM延迟略优于Intel Xeon 6的SNC3模式,但高于桌面平台(如Ryzen 9 9900X),这是服务器级互连复杂性导致的正常现象。
    • NPS2/NPS4模式:将芯片分为2或4个NUMA节点,每个节点关联部分内存控制器。这些模式仅带来微小的延迟改善(约20-30纳秒),但跨节点访问的延迟惩罚极低
    • 结论:在大多数情况下,使用NPS1模式即可获得良好且均衡的性能,无需复杂的NUMA优化。
  2. 内存带宽
    • 在NPS1模式下,芯片可充分利用12个内存控制器,带宽表现接近理论值。
    • 跨NUMA节点访问会带来一定的带宽下降,但幅度不大。
    • 注意:在NPS4模式下,当单个CCD(通过GMI-Wide)进行高强度的读取-修改-写入操作时,可能会因带宽需求超过该NUMA节点内存控制器的容量而导致性能显著下降(带宽和延迟均恶化)。NPS4模式需谨慎使用。

性能对比

  1. 单线程性能
    • 与桌面级Ryzen 9 9900X相比,单线程性能在关闭睿频(匹配主频)后非常接近,但略低,主要受服务器平台更高的内存延迟影响。
    • 与更侧重密度的Arm Graviton 4和Intel Xeon 6 6975P-C相比,EPYC 9355P的单线程性能明显更优
  2. 带宽密集型负载(以SPEC CPU2017浮点测试为例)
    • 在需要高内存带宽的工作负载中(如549.fotonik3d),EPYC 9355P凭借GMI-Wide提供的高CCD带宽表现优异,超越了Ryzen 9 9900X(受限于GMI-Narrow)和Xeon 6(受限于较低的单核内存带宽)。
    • 在此场景下,AMD的互连架构没有出现预期的瓶颈,而Intel的逻辑单体架构优势未能体现。

总结与平台对比

  • EPYC 9355P:代表了AMD“中等核心数,高性能单核”的服务器策略。其成功得益于GMI-Wide互连高缓存/核心比
  • AMD vs. Intel 互连哲学
    • AMD(中心辐射型):自Zen 2以来,牺牲了部分本地内存延迟,换取了更均衡的跨插座内存性能和低跨节点惩罚。在DRAM层面,其表现比Intel更像“单体”架构。
    • Intel(逻辑单体型):在Xeon 6上尝试保持缓存层面的单体一致性,但实测中,其理论上的本地内存延迟优势并未转化为实际性能优势,且跨计算单元访问延迟更高。
  • 未来展望:AMD继续巩固其经过验证的互连方案,而Intel和Arm则致力于在扩展性与单体设计之间找到最佳平衡点。服务器芯片设计仍在不断演进中。
30. Discord customer service data breach leaks user info and scanned photo IDs (www.theverge.com)

Discord第三方客户服务数据泄露事件

Discord近期披露,其第三方客户服务提供商遭到未经授权方入侵,导致部分用户数据泄露。未经授权方访问了曾通过Discord客户支持或信任与安全团队联系的有限用户信息,并企图从Discord索要财务赎金。此次入侵未直接涉及Discord自身系统。

泄露数据包括用户名、电子邮件、信用卡号的最后四位数字,以及上诉年龄决定的用户的政府ID图片。Discord明确表示,全信用卡号和密码未受此次事件影响。

Discord已采取多项应对措施:通过电子邮件通知受影响用户(如涉及ID泄露会具体说明),撤销第三方支持提供商的系统访问权限,通知相关数据保护机构,并与执法部门合作调查。同时,公司已审查威胁检测系统及第三方支持提供商的安全控制。

事件由The Verge记者Jay Peters报道。

31. When private practices merge with hospital systems, costs go up (insights.som.yale.edu)

私人诊所与医院系统合并导致医疗成本上升

研究背景

医生正逐渐从独立执业转向被医院系统、私募股权公司和保险公司雇佣。这种整合对患者和医疗费用的影响此前因缺乏综合数据而难以准确评估。

核心发现

耶鲁大学经济学家 Fiona Scott Morton 及其团队通过研究发现:

  • 整合程度显著增加:2008年至2016年间,受雇于医院的医生比例从27.5%上升至47.2%。
  • 价格大幅上涨:以分娩服务为例,合并后医院价格平均上涨3.3%(约475美元),医生价格平均上涨15.1%(约502美元)。
  • 质量未提升:衡量分娩质量的指标(如再入院率、剖腹产率)在合并后无改善。

价格上涨的反竞争机制

研究识别出三种导致价格上涨的机制:

  1. 患者引导:合并后医生可能将患者导向所属医院系统,减少患者对医院的选择。
  2. 网络锁定:合并后排除某医生意味着同时排除其所属医院,迫使保险公司和患者接受更高价格。
  3. 市场集中:多次收购会形成横向垄断,进一步降低竞争。

监管建议

研究者呼吁加强监管,建议措施包括:

  • 要求医疗机构报告所有权和医生关联信息。
  • 对合并交易设置审批等待期。
  • 建立联邦层面的顾问小组协助州监管机构。
  • 关注小型交易对本地市场和价格的累积影响。
32. Toyota runs a car-hacking event to boost security (2024) (toyotatimes.jp)

丰田举办黑客活动以提升车辆安全(2024)

活动概述

丰田与丰田汽车北美公司、丰田通商系统美国公司联合举办了一场名为 Hack Festa 的黑客竞赛活动。该活动面向IT专业学生,吸引他们以团队形式参与,通过模拟环境挑战与汽车相关的安全任务。活动不仅在日本举行,也在美国和爱尔兰开展。

活动形式与目的

  • 参与方式:学生组成约四人小组,协作完成指定任务。
  • 任务内容:挑战均围绕汽车安全,例如控制车速调节机制覆盖发动机转速等。
  • 评估方式:所有操作在模拟器上进行,根据完成情况计分,得分最高的团队获胜。
  • 举办初衷:看似矛盾的“以黑客活动提升安全”,实则是为了提前发现汽车系统潜在漏洞,从而加强防护。

行业背景与安全挑战

  • 汽车技术演进:随着互联网连接、自动驾驶和软件定义汽车(SDV)的发展,车辆功能可通过后续软件更新持续扩展,类似智能手机。
  • 伴随的威胁:互联网集成在提升便利性的同时,也使恶意第三方更容易侵入汽车系统。
  • 严重后果:黑客攻击可能导致车辆失去对驾驶、转向和制动等基础功能的控制,危及生命安全。
  • 安全需求紧迫:网络安全已成为保护客户的关键,对丰田乃至整个汽车行业都至关重要。

活动的实质与意义

活动由丰田信息安全技术部门组织,其负责人解释这是一种 “道德黑客” 行为。通过允许学生在受控模拟环境中尝试“攻击”,丰田能够:

  • 识别现有系统中未发现的弱点。
  • 收集对抗潜在真实威胁的宝贵数据与见解。
  • 最终目的是加固车辆网络安全防线,提前防御恶意攻击,保护用户安全。

总结

丰田的黑客活动是一个创新的、面向未来的安全研究项目。它通过激励学生探索汽车系统的边界,在模拟环境中暴露漏洞,从而主动强化网络安全措施,应对日益复杂的数字化汽车时代带来的挑战。

33. Track which Electron apps slow down macOS 26 Tahoe (avarayr.github.io)

该文章指出,macOS 26 Tahoe 系统上部分 Electron 应用会导致系统运行变慢。问题根源在于 Electron 框架,解决方案是将其升级至指定版本:v38.2.0、v37.6.0 或 v36.9.2。

文中列出了已修复此问题的 56 款应用,包括: 1Password、Asana for Desktop、Beeper、Bitwarden、Bruno、Canva、Claude App、Clickup、Cluely、Cursor、Dialpad、Discord、Docker Desktop、Dropbox、Element、Fastmail、Figma、Fing、Framer、FreeYourMusic、GitHub Desktop、GitKraken、Kiro、Legcord、Linear、LM Studio、LM Studio (Beta)、Logseq、Mattermost、Miro、Mockoon、MongoDB Compass、Notion、Notion Mail、Obsidian、OpenVPN Connect、Pocket Casts、Podman Desktop、Proton Mail、Proton Pass、Qoder、Rancher Desktop、Screen Studio、Signal、Slack、Spark Mail、Super Productivity、Superhuman、Tabby、Tidal、Tuta Mail、Unity Hub、Visual Studio Code、Windsurf、Zoho Mail、Zulip。

同时,文章也列出了 27 款尚未修复 的应用: BuildBetter、Freelens 等。

34. Sora Update #1 (blog.samaltman.com)

Sora更新#1摘要

OpenAI的Sora团队正基于用户、版权持有者及利益相关方的反馈进行快速改进,推出两项关键变化并承诺持续迭代:

  1. 增强版权控制:团队将为版权持有者提供更精细的角色生成控制权,类似于现有的肖像选择加入模型,但增加额外选项。版权持有者可指定角色的使用方式(包括完全禁止),以支持“互动粉丝小说”等新形式参与。这旨在公平应用标准,让版权持有者自主决定,同时承认可能需处理边缘案例。团队特别提到日本内容的深度用户连接,暗示相关优化考虑。

  2. 引入收入分享模型:由于用户视频生成量远超预期,且许多视频面向小众观众,Sora将探索与版权持有者分享收入的机制。具体模型仍在试验中,计划尽快实施,旨在使新参与方式不仅带来收入分成,还能增加整体价值。

团队强调保持高迭代速率,类似ChatGPT初期,快速响应反馈并修正错误。迭代将在Sora中进行,然后统一应用到其他产品。

35. Ants trapped in a Soviet nuclear bunker survived for years (2019) (www.sciencealert.com)

文章标题:困于苏联核地堡的蚂蚁存活多年(2019)

文章内容总结:

在波兰西部森林中,一座废弃的苏联核基地内设有两个用于存放核弹药的地下地堡。军事设施废弃后,这些人工洞穴成为蝙蝠越冬的栖息地。2010年代初,志愿者在冬季监测蝙蝠时意外发现:地堡地板上聚集着大量木蚁(Formica polyctena),它们在没有蚁后、无食物、无光线且无法逃脱的极端条件下持续生存。

2013年首次发现时,该“蚁群”已包含近百万只活工蚁及数百万死蚁。它们无法繁殖,但种群数量通过意外方式得到补充——地堡天花板有一根生锈的通风管道,连接至地面森林,其正上方存在一个巨型蚁巢。随着金属锈蚀穿孔,地面蚁巢的部分成员不断坠入地下的混凝土洞穴。

研究人员在2016年的研究中指出,这些蚂蚁在完全黑暗的环境中建造并维护了一个土丘,“远非一个功能完整的蚁群”。数年间,研究人员多次实地观察,发现该隔离种群尽管缺乏光照、温度或明显营养来源,却持续增长和存活。

最终,科学家揭示了它们的生存机制:大量食用被困的巢友。地堡内除了偶尔出现的死鼠或蝙蝠,木蚁是唯一的主要食物来源,且该物种在领地“蚁战”期间本就有食用同伴遗体的习性。研究团队从地堡内多处“蚁冢”收集蚁尸,经仔细检查150具工蚁尸体,发现绝大多数(约93%)存在啃咬孔洞和咬痕,明确指向大规模同类相食。

研究者总结:“多年来,地堡‘蚁群’在不自行繁殖的情况下得以存续和增长,依赖于上层蚁巢持续补充新工蚁以及巢友尸体的积累。尸体作为源源不断的养分来源,极大地支持了蚂蚁在 otherwise 极端不利条件下的生存。”

值得注意的是,2016年研究人员在地堡内安装了一条木板步道,连接通风管道与地面。四个月内,几乎所有被困蚂蚁都离开了地堡。如今,坠入黑暗洞穴的蚂蚁可通过步道直接返回地面,无需再诉诸同类相食。该研究成果发表于《膜翅目研究杂志》。

36. How functional programming shaped and twisted front end development (alfy.blog)

函数式编程如何塑造并扭曲了前端开发

现代前端开发与Web平台的本质特性存在深刻矛盾。本文通过一位资深开发者的视角,探讨了追求函数式编程纯粹性如何导致我们与平台对抗,而非协同工作。

Web平台的天性 vs 函数式理想

Web本质上是副作用丰富的:CSS全局级联、DOM是可变的树、用户交互异步且不可预测。这种“混乱”正是Web跨设备兼容、向后兼容及系统互操作的基础。

函数式编程推崇纯函数、不可变数据、显式状态管理,旨在提升代码可预测性和可测试性。React、Redux等工具将这些理念带入主流,塑造了“UI = f(state)”的模型。

纯粹追求带来的扭曲

1. CSS-in-JS与工具类的战争

  • 问题:认为CSS全局作用域危险,追求样式隔离。
  • 解决方案:CSS-in-JS(如styled-components)运行时生成样式;Tailwind CSS提供原子化工具类。
  • 代价:失去CSS级联优势、增加运行时开销、阻塞渲染、导致HTML臃肿。甚至当Tailwind引入类似级联的嵌套语法时,社区竟出现反对声音——表明已形成反平台的意识形态

2. 合成事件抽象

  • React的合成事件系统为了统一浏览器差异和融入渲染生命周期,包装了原生事件。
  • 代价:增加内存开销和调试难度,使开发者远离原生事件API,形成对框架的依赖。

3. 客户端渲染与水合

  • 为追求纯粹的函数模型,先采用客户端渲染(CSR),后为SEO/性能引入服务端渲染(SSR)+ 水合(Hydration)
  • 代价:用户先看到空白页,然后经历“交互冻结期”;数据请求和数据库查询常重复执行;架构变得复杂且低效。

4. 忽视原生API与“不良实践教学”

  • 教程和框架鼓励用JavaScript重新实现平台已有功能:
    • <div>模拟**原生<dialog>**元素,丢失内置焦点管理、可访问性等特性。
    • 用复杂状态管理实现表单验证,而浏览器原生支持<input type="email">等。
    • 用JavaScript路由器替代浏览器原生的<a>标签和History API。
  • 结果:一代开发者不了解平台能力,认为“复杂化”才是最佳实践。

5. 框架跟不上平台演进

  • 现代Web平台不断添加新特性(如可定制<select>、Popover API)。
  • 但主流框架(如React)的架构假设(如JSX解析、水合机制)可能与之冲突,甚至导致错误。平台能力被闲置。

为何走到了这一步?

这并非源于无能,而是特定历史背景下的合理选择:

  • 2010年代初:jQuery式代码难以维护,数据双向绑定导致不可预测的更新链。React等框架提供的单向数据流和组件模型确实解决了复杂应用的难题。
  • 光环效应与生态惯性:React成功后,其模式成为行业标准。培训、招聘、教程形成闭环,导致工具选择脱离具体问题需求——连静态网站也使用重量级框架。
  • 我们丢失了:渐进增强、内置可访问性、性能优化、开发简洁性,以及与平台优化的对齐。

前路:回归与平衡

行业正重新发现平台的力量。新兴工具代表了一种回归:

  • HTMX:以HTML为交换媒介,无需水合。
  • Qwik:可恢复式架构,避免传统水合。
  • Astro:默认服务端渲染,最小化JavaScript。
  • Remix、SvelteKit:拥抱Web标准,如无需JS的表单提交和渐进增强。

不意味着抛弃组件化或响应式,而是认识到:

  1. “UI = f(state)”是框架内的有用模型,而非重建整个浏览器堆栈的理由。
  2. 应优先使用CSS进行样式设计、原生事件处理交互、HTML构建结构,仅在需要超出平台能力时才引入JavaScript。

最好的框架将是那些感觉与Web一体,而非与之对抗的工具。 在追逐函数式纯粹性的过程中,我们构建了一个更复杂、更脆弱、与平台脱节的前端栈。Web从未需要被“净化”,它需要的是被理解。

37. WireGuard topologies for self-hosting at home (garrido.io)

WireGuard 家庭自托管网络拓扑设计摘要

本文介绍了作者将自托管服务从远程VPS迁移至家庭物理服务器后,如何设计基于WireGuard的VPN网络拓扑。设计遵循一系列约束条件,旨在实现安全、可控且实用的家庭网络架构。

核心设计约束

  • 首要约束:
    1. 无外部依赖:服务应在家庭物理网络内独立运行,不依赖外部服务或硬件。
    2. 借鉴零信任原则:将所有服务和设备视为资源,对所有通信进行加密,实施最小权限访问。
    3. 外部访问为可选:从家庭网络外进行连接应作为次要功能,不应损害核心设计。
  • 次要约束:
    1. 使用原生WireGuard:优先选择简单、易于理解的方案,而非功能更全但更复杂的封装工具。
    2. 无需控制平面:所有端点均平等管理,不依赖中心协调服务。
  • 非约束:不需要实现Mesh网络、对等直连、自动发现或密钥分发。

网络资源与连接需求

文章定义了一个连接矩阵,明确了家庭内设备(台式机、笔记本、手机、平板、服务器)之间的具体通信需求。例如,台式机需要连接服务器访问服务,平板需要从服务器获取RSS订阅等。这决定了WireGuard对等体配置和防火墙规则。

拓扑设计演进过程

作者从简单拓扑开始,逐步演进至最终设计:

  1. 点对点拓扑

    • 描述:同一物理网络中的所有设备互为WireGuard对等体。
    • 问题:设备动态IP地址可能导致连接中断。
    • 解决方案:为设备分配静态IP地址。
  2. 引入远程对等体(VPS)

    • 背景:家庭网络位于运营商级NAT之后,无法直接从公网访问。
    • 方案:在拥有公网IP的VPS上建立一个WireGuard枢纽。家庭服务器作为对等体连接到VPS,并保持连接活跃。
    • 外部访问:当用户在外时,笔记本通过wg-remote接口连接到VPS。VPS充当中继,将流量转发给家庭服务器(实现NAT)。
  3. 枢纽辐射拓扑

    • 描述:VPS作为“枢纽”,笔记本和家庭服务器作为“辐射”。所有辐射节点仅需将枢纽配置为对等体,简化了配置。
    • 优点:集中管理、配置简单。
    • 注意:辐射节点间无法直接通信,需经过枢纽转发。
  4. 家庭内部采用枢纽辐射拓扑

    • 演进:将家庭网络内部也改为枢纽辐射拓扑,使用始终在线的服务器作为内部枢纽。
    • 优点:简化了家庭内所有设备的WireGuard配置(只需将服务器设为唯一对等体)。
    • 缺点:服务器成为单点故障;所有内部通信流量需经过服务器,增加其负载。
  5. 双枢纽设计(最终方案)

    • 架构:家庭路由器作为内部枢纽(利用其作为网络网关的必然性),VPS作为外部枢纽。两个枢纽互为对等体。
    • 优点
      • 路由器作为枢纽比服务器更可靠(它已是网络的单点)。
      • 简化了IP地址管理(辐射节点使用网关地址连接枢纽)。
      • 清晰分离内外网流量管理。
    • 流量路径:家庭内部通信经路由器转发;从外部访问家庭资源时,流量经过VPS再到路由器,最后到达目标设备。

最终设计与总结

  • 最终架构:以支持VLAN的路由器为内部枢纽的双枢纽辐射拓扑。即使底层物理网络被划分为不同VLAN,WireGuard网络依然保持稳定,辐射节点只需更新其对路由器枢纽的连接端点地址。
  • 核心优势
    • 简化:以路由器作为内部枢纽极大简化了配置。
    • 安全:遵循零信任原则,所有通信加密,并可在路由器和VPS上实施集中式防火墙规则(最小权限访问)。
    • 实用:解决了家庭服务器在CGNAT环境下的安全远程访问问题。
  • 权衡与反思
    • 这是一个“移动客户端优先”的设计,家庭内设备无法主动发起连接到漫游在外的设备。
    • 作者认为WireGuard原生部署虽然需要更多网络知识,但能带来对网络架构的深入理解和完全控制,而Tailscale等封装工具则简化了这一过程。
    • 文章未涉及DNS配置等细节,留待后续讨论。

总之,本文展示了一个经过深思熟虑、逐步演进的WireGuard网络设计案例,为有类似需求的个人或小型组织提供了有价值的参考,强调了在约束下平衡简单性、安全性与实用性的过程。

38. Arenas in Rust (russellw.github.io)

在 Rust 中实现具有循环引用的数据结构(如双向链表)时,由于 Rust 的所有权和借用系统难以追踪循环引用,直接使用指针会引发挑战。Arena 是一种解决方案,它通过在一个大数组中分配对象,并使用整数句柄(handle)而非直接引用来访问它们,从而管理内存。

这种做法表面上类似于绕过硬件指针、自行实现地址空间和手动内存管理,似乎违背了使用 Rust 追求内存安全的初衷。然而,文章指出,Arena 方式并不会导致传统手动内存管理(如 C 语言)中最危险的内存安全漏洞。

文章从两个关键角度论证了这一点:

  1. 非确定性:传统的指针错误(如越界、释放后使用)可能导致难以复现的间歇性崩溃。而基于句柄的访问是确定性的,相同的错误条件会始终导致相同的崩溃行为,更容易调试。
  2. 安全性:指针错误往往可能被攻击者利用,从导致程序崩溃升级为远程代码执行。而 Arena 与句柄的结合通常保持了数组边界检查,因此即使出现 bug,攻击者也很难利用它来覆写任意内存。这使得 Arena 管理下的程序在面临错误时,更可能表现为拒绝服务,而非被利用进行远程代码执行。

因此,Arena 内存管理虽然在形式上类似于手动管理,但它保留了 Rust 致力于解决的核心安全属性:防止因内存安全漏洞而导致的远程代码执行风险,从而区别于传统的手动内存管理。

39. Binary Formats Gallery (formats.kaitai.io)

文章标题为"Binary Formats Gallery",内容列出了"Image Files"部分下的多种二进制图像文件格式,包括bmp、dicom、exif、gif、gimp_brush、icc_4、ico、jpeg、nitf、pcx、pcx_dcx、pif、png、psx_tim、tga、wmf和xwd。这些格式涵盖了常见的图像存储和传输标准,以及一些特定应用或设备的专用格式,展示了二进制图像文件格式的多样性和用途。

40. Be Worried (dlo.me)

文章摘要:《Be Worried》

本文作者于2023年3月撰写,因担忧内容过于耸动而未发表,直至2025年10月伴随Sora 2的发布才决定公开。文章核心观点是:人们应警惕的并非传统意义上的超级智能AI(AGI),而是当前AI(尤其是大型语言模型LLM)已在无需具备意识或真正智能的情况下,大规模影响甚至操控人类行为。

主要论点

  1. AI已跨越鸿沟,直接影响人类行为 作者指出,争论AI是否“智能”已偏离重点。真正的威胁在于,AI工具已广泛渗透社会,并开始实质性影响人类决策与行为。

  2. LLM被“放出牢笼”,拥有实时网络接入能力 以2023年3月OpenAI为ChatGPT推出插件系统为标志,最强大的LLM获得了通过API与互联网实时交互的能力。这打破了此前出于安全考虑而设置的限制。

  3. 自生成、自优化的“病毒式内容”循环 文章描述了一个令人担忧的自动化系统:

    • 内容生成:由较弱的AI模型生成指令,引导更强的LLM(如ChatGPT)基于实时热点新闻创作“病毒式”内容。
    • 分发:生成的内容通过自动化工具分发到各大社交平台和博客。
    • 反馈优化:传播效果数据被收集,并用于微调模型或调整参数,形成一个不断自我优化的闭环。
  4. AI生成内容在传播上具有绝对优势 生成能刺激多巴胺、引发传播的内容本质上是一个量化任务。LLM在此方面远超人类,因此AI生成的内容更容易获得点击和关注

  5. AI检测手段几乎失效 现有及未来的AI内容检测技术被证明极不可靠,其效果“仅比随机猜测好一点”,并且随着模型复杂化,检测只会变得更困难。这意味着人类将越来越难以分辨内容是由人还是机器生成。

  6. 未来图景:意识被无形操控 作者预测,在无法区分内容来源且AI内容更具吸引力的双重作用下,大部分流行的线上(乃至线下)内容都将由AI生成。人们将在不知情的情况下,消费并内化这些由机器为特定目的(如最大化注意力)而生产的思想、观点和信息,从而在实质上被AI及其操控者“精神控制”。

作者反思与忧虑

  • 作者表示将严重降低对2022年后网络内容的信任度,并寻求验证内容真实性的方法。
  • 他借用《黑客帝国》的比喻,指出真正的“AI末日”不是人类被关在虚拟世界,而是身处现实世界,但思想和感受却完全由机器生成的内容所塑造和控制
  • 最终,作者表达了对自由思想未来的深切忧虑,认为这对所有互联网消费者都是一种悲哀和威胁。

总结:文章警告,在AI内容检测技术失败的前提下,具备网络接入能力并可自动生成、优化和分发内容的LLM,正通过创建更具吸引力的信息流,悄然塑造并控制大众的认知与行为,其影响深远且令人不安。