2025-10-17

34 篇热帖

1. Ruby core team takes ownership of RubyGems and Bundler (www.ruby-lang.org)

Ruby 核心团队接管 RubyGems 和 Bundler 的所有权

发布日期:2025年10月17日 发布者:Matz

RubyGems 和 Bundler 是访问 rubygems.org 和整个 Ruby 生态系统的官方必备客户端,多年来已捆绑在 Ruby 语言中,并作为标准库的一部分运行。

尽管扮演着至关重要的角色,但与 Ruby 生态系统的其他主要组件不同,RubyGems 和 Bundler 历史上一直在 GitHub 上的 Ruby 组织之外进行开发。

为了给社区提供长期的稳定性和连续性,由 Matz 领导的 Ruby 核心团队已决定从 Ruby Central 承担这些项目的管理责任。我们将与 Ruby Central 及更广泛的社区密切合作,继续推进这些项目的发展。

以下要点需要特别强调:

  • 仓库所有权将转移给 Ruby 核心团队,以确保长期稳定性并与更广泛的 Ruby 生态系统保持一致。该仓库将由 Ruby Central 与 Ruby 核心团队共同管理
  • RubyGems 和 Bundler 将继续以其当前许可证保持开源,许可条款不会发生任何变化。
  • 所有现有贡献者完全保留其代码贡献的版权和署名权。此次过渡不会影响任何贡献者的知识产权。
  • 协作、社区驱动的开发流程将一如既往,我们欢迎所有社区成员的贡献。

此次过渡体现了我们为确保 Ruby 生态系统在未来数年持续健康发展、保持稳定并实现增长的承诺。我们衷心感谢 Ruby Central 多年来的尽职管理,并期待与 Ruby 社区的所有成员合作,共同为 Ruby 构建一个更加光明的未来。

感谢大家持续的支持与贡献。

此致敬礼,

松本行弘,又名 Matz

3. Claude Skills (www.anthropic.com)

Claude Skills 概述

Claude Skills 是包含指令、脚本和资源的文件夹,Claude 可在执行特定任务时按需加载。Skills 旨在提升 Claude 在专业任务(如处理 Excel 或遵循品牌规范)中的表现。此功能已在 Claude 应用中运行(如创建电子表格和演示文稿),并允许用户自定义 Skills,使其适用于 Claude 应用、Claude Code 及 API。

核心工作原理

  • 按需加载:Claude 扫描可用 Skills 以匹配任务,仅加载必要的最小信息和文件,确保效率。
  • 特点
    • 可组合:多个 Skills 可堆叠协作,Claude 自动协调使用。
    • 可移植:统一格式,一次构建,可在所有 Claude 平台使用。
    • 高效:仅加载所需资源。
    • 强大:支持可执行代码,适用于需要编程可靠性的任务。
  • 定位:Skills 类似自定义“入职材料”,将专业知识打包,使 Claude 成为特定领域的专家。

平台应用详情

1. Claude 应用

  • 用户权限:适用于 Pro、Max、Team 和 Enterprise 用户。
  • 自动化:Claude 根据任务自动调用相关 Skills,无需手动选择。
  • 创建方式:通过“skill-creator”技能引导,交互生成文件夹结构、SKILL.md 文件及资源,无需手动编辑。
  • 设置:需在设置中启用;Team 和 Enterprise 用户需管理员组织级启用。

2. Claude Developer Platform (API)

  • 集成:Skills 可添加到 Messages API 请求,通过 /v1/skills 端点实现版本控制和程序化管理。
  • 依赖:需启用 Code Execution Tool 测试版(提供安全运行环境)。
  • 功能扩展
    • 使用 Anthropic 预制 Skills 生成专业 Excel、PowerPoint、Word 文档及可填写 PDF。
    • 开发者可创建自定义 Skills 并通过 Claude Console 管理版本。

3. Claude Code

  • 扩展方式:通过插件市场(anthropics/skills)安装 Skills,Claude 按需自动加载。
  • 团队协作:支持版本控制共享,或手动安装至 ~/.claude/skills
  • 开发支持:Claude Agent SDK 提供相同的 Agent Skills 支持。

合作伙伴案例

  • Box:利用 Skills 将存储文件转换为符合组织标准的 PowerPoint、Excel 和 Word 文档。
  • Canva:计划通过 Skills 定制智能体,将 Canva 深度集成到智能体工作流中。
  • Notion:实现从问题到操作的快速响应,减少提示调试,提升结果可预测性。
  • 管理会计:通过 Skills 处理多份电子表格、检测异常并按规程生成报告,将数小时工作缩短至一小时。

获取资源与注意事项

  • 入门指南
    • Claude 应用:用户指南与帮助中心
    • API 开发者:官方文档
    • Claude Code:相关文档
    • 示例 Skills:GitHub 仓库
  • 安全提醒:Skills 可执行代码,需谨慎使用,建议仅采用可信来源以确保数据安全。
  • 未来方向:简化 Skills 创建流程,增强企业级部署能力,便于组织跨团队分发。
4. 3x performance for 1/4 of the price by migrating from AWS to Hetzner (digitalsociety.coop)

从 AWS 迁移至 Hetzner:以四分之一的价格获得三倍性能

背景与动机

公司 DigitalSociety 此前将工作负载分布在两个云平台:AWS(托管核心 DNS、邮件及首个 SaaS 产品 tap,使用 ECS、RDS、ALB 等服务)和 DigitalOcean(用于托管轻量级服务和监控工具的托管 Kubernetes)。选择 AWS 源于 15 年的使用经验和对其 API 稳定性的信任;选择 DigitalOcean 则因其经济实惠的托管 Kubernetes 服务。

随着 AWS 的 1000 美元初创企业额度在 6 个月内耗尽,tap 的月度费用飙升至 449.50 美元。作为一家自筹资金的初创公司,持续的高成本难以承受。同时,出于对数据主权和地缘政治因素的考虑,团队开始寻找英国或欧盟的云服务商。

迁移方案与新技术栈

经过评估,团队选择了德国提供商 Hetzner,并决定将 DigitalOcean 上的基础设施一并迁移,以统一管理。新方案的核心是自行管理 Kubernetes 集群,并采用以下技术栈:

  • 基础设施提供商Hetzner,使用其 ARM 共享 vCPU 云服务器、块存储、负载均衡器、网络、防火墙和兼容 S3 的对象存储。
  • 操作系统Talos Linux。这是一个专为 Kubernetes 设计的、通过声明式配置管理的操作系统,简化了节点维护。
  • 数据库CloudNativePG。用以替代 AWS RDS,在 Kubernetes 中声明式地管理 PostgreSQL 集群,支持自动故障转移、备份等关键功能。
  • 网络与安全:使用 Ingress NGINX Controller(替代托管负载均衡器)、ExternalDNS(自动 DNS 管理)、cert-manager(自动管理 TLS 证书)。
  • 基础设施即代码:所有配置通过 TerraformHelm 进行管理,并通过 GitHub Actions 实现自动化部署。

成本与性能成果

迁移带来了显著的成本节约和性能提升:

指标 迁移前 (AWS & DigitalOcean) 迁移后 (Hetzner) 变化
月度费用 约 559.36 美元 约 140 美元 (根据文中推算) 节省约 76%
vCPU 容量 12 vCPU 44 vCPU 增长 367%
内存容量 24 GiB RAM 88 GiB RAM 增长 367%

最终实现了 “以四分之一的价格获得三倍的性能”

遇到的挑战

  1. 网络拓扑差异:AWS 的“区域-可用区”模型(同一区域内可用区间内网互通)与 Hetzner 的“位置-网络区”模型不同。Hetzner 的不同位置间存在显著延迟,不利于多位置工作负载。团队最终选择使用单一位置(纽伦堡),并利用 放置组 来确保服务器运行在不同的物理服务器上,以提高弹性。
  2. 容器迁移的复杂性:虽然 SaaS 产品 tap 本身已是容器化的,但从 AWS ECS 迁移到 Kubernetes 的配置和部署自动化工作比预期更复杂。团队最终使用 Kustomize 来桥接 GitHub 中的敏感配置与 Kubernetes 清单,并将非敏感配置移入代码库以便跟踪。

结论

Hetzner 是一个极具成本效益的云服务商。虽然其服务范围和托管程度不及 AWS 或 DigitalOcean,但通过合适的技术栈(如 Talos Linux、CloudNativePG 和自管理 Kubernetes)可以弥补这些不足。此次迁移使得团队能够以极低的成本和更高的性能运行其数据密集型 SaaS 产品 tap,同时保持了基础设施的可控性。

5. Live Stream from the Namib Desert (bookofjoe2.blogspot.com)

纳米比亚沙漠水源坑的直播摄像头成为作者每日清晨必访的站点。该地区比美国东部时间早6小时,因此访问时常值炎热天气,总能看到众多动物前来饮水。

观察到的动物包括斑马、鸵鸟(通常全家在安全距离外等待)、大羚羊、疣牛、角马、豺、耳廓狐、斑点鬣狗、南非野兔、红狷羚、长颈鹿、跳羚和大象等。作者建议小学教师可在教室放置大屏幕定期播放此直播,作为教育资源。

7. 4Chan Lawyer publishes Ofcom correspondence (alecmuffett.com)

Ofcom — driven by the letter of British law that they are bound to follow, but still Ofcom — are quietly making Britain look (a) very silly and (b) as if we haven’t yet shucked-off the Americ…

8. You did no fact checking, and I must scream (shkspr.mobi)

事实核查的重要性与媒体失职

作者指出,在当今数字时代,核查基本事实从未如此容易。尽管存在大量虚假信息,但借助互联网工具,普通人也能快速验证信息的真实性。这些工具包括:

  • 反向图像搜索:可追溯图片首次出现的时间和来源,评估其可信度。
  • Google Books:用于验证引用或语录的准确性。
  • 社交媒体搜索:可追踪网络迷因的起源。
  • 印刷资料档案和网站:帮助交叉引用信息,辨别虚假引用。

作者以演员Patricia Routledge去世后传播的虚假故事为例,说明事实核查的简便性。该故事包含多处错误,例如:

  • 生日日期错误:Patricia Routledge出生于1929年2月17日,2024年2月17日是星期六,而非故事中所说的星期一。
  • 年龄和生涯细节错误:她在1968年托尼奖获奖时年龄约为39岁,而非故事中的其他数字;电视剧《Keeping Up Appearances》首播于1990年,她当时约60岁,而非50岁;她并非“小角色”主演,而是该剧的明星。
  • 舞台生涯描述不实:她自1999年起活跃于舞台,但未涉莎士比亚剧目。

作者在10分钟内通过网络搜索和常识完成了事实核查,无需专业团队或付费订阅。然而,报纸如《The Independent》和《The Express》未经核查便发布了该虚假故事,引用了一个名为“Jay Speak”的博客作为来源,该博客本身可能也是转发内容。进一步搜索显示,更早的类似帖子出现在社交媒体上,但原始来源不明。

作者批评媒体为了追求点击率而忽略事实核查,导致传播错误信息。BBC等专业机构也曾播出可轻易证伪的谎言,这反映了媒体的失职,可能源于傲慢、懒惰或故意煽动。

最后,作者强调事实核查并非专业技能,只需互联网和好奇心。呼吁个人在分享信息前主动核查,以阻止错误信息的传播,保护自己和他人免受低质信息的侵害。

9. EVs are depreciating faster than gas-powered cars (restofworld.org)

The fall of India’s all-electric ride-hailing pioneer shows how fast EVs are losing value, a problem hurting fleets and owners worldwide.

10. Gemini 3.0 spotted in the wild through A/B testing (ricklamers.io)

文章主要内容包括以下几点:

  • 作者在Google AI Studio的A/B测试界面中意外发现了疑似Gemini 3.0模型,引发关注。该模型被认为是当前最受期待的人工智能更新之一,尤其在编程性能方面预期有显著提升。
  • 通过SVG图像生成任务(以“Xbox 360控制器”的SVG代码生成为例)可以有效评估模型质量,这一测试结果具有代表性。作者使用特定提示词后,生成的SVG图像效果比其他前沿模型更优。
  • A/B测试中,该模型的ID为ecpt50a2y6mpgkcn,但版本信息不明确。作者推测测试可能是将Gemini 3.0 Pro与当前已使用的Gemini 2.5 Pro进行对比,因为将Gemini 3.0 Flash与Gemini 2.5 Pro对比在A/B测试中意义不大。
  • 测试中观察到该模型的首次响应时间(TTFT)较长,且输出长度增加约40%(包含推理token),但作者认为这并非使用大量测试时计算的高级模型(如“GPT-5 Pro”)特征。
14. Titan submersible’s $62 SanDisk memory card found undamaged at wreckage site (www.tomshardware.com)

泰坦潜水器残骸中发现未损坏的62美元SanDisk存储卡

事件概述

救援团队在泰坦潜水器残骸中发现了一台专业水下相机,其内部存储卡完好无损。尽管相机外壳和内部组件存在损伤,但存储卡数据得以成功恢复。

关键发现

  • 存储卡状态:内部的SD卡未受损坏,已恢复12张静态图像和9段视频。
  • 相机型号:SubC品牌的Rayfin Mk2深海相机,设计可承受6000米深度,由钛合金和人造蓝宝石晶体构成。
  • 损伤情况:相机外壳基本完好但镜头破碎,内部印刷电路板(PCB)连接器断裂、部分表面贴装元件损坏。

技术细节

  • 存储卡信息:极可能为SanDisk Extreme Pro 512GB SD卡(当前售价62.99美元)。
  • 推测硬件配置:主控可能为基于高通SD820处理器的Inforce 6601系统模块,搭载4GB内存和64GB UFS存储;微控制器可能为Teensy 4.0或3.2。
  • 恢复的影像规格:静态图像分辨率为4056×3040像素(约1230万像素),视频分辨率为3840×2160像素(4K超高清)。

数据恢复过程

  1. 首先对SD卡进行完整二进制镜像备份以确保原始数据不受影响。
  2. 加拿大交通安全委员会(TSB)、数据取证人员与SubC公司在纽芬兰的实验室合作。
  3. 使用恢复的NVRAM芯片和SD卡镜像,通过“替代系统模块板”成功读取数据。

重要说明

恢复的图像和视频均拍摄于纽芬兰海洋研究所的ROV车间附近,属于潜水任务的后勤基地。未发现与泰坦尼克号沉船区域或事故直接相关的内容。据调查人员解释,该相机被配置为将数据转储到外部存储设备,因此未记录到事故潜水的数据。

15. Ring to partner with Flock, a network of cameras used by ICE, feds, and police (techcrunch.com)

Ring与Flock合作:监控网络扩展引发隐私与安全担忧

Ring宣布与AI监控摄像头制造商Flock合作,允许执法机构通过Flock网络向Ring用户请求共享门铃摄像头视频片段,以协助“证据收集和调查工作”。

合作核心与Flock技术特点:

  • 功能整合: Flock客户(包括政府及警方机构)现可请求Ring用户分享视频。
  • 技术能力: Flock摄像头利用AI扫描车辆牌照等识别信息,并支持通过自然语言搜索视频,以查找匹配特定描述的人员。
  • 潜在影响: 此次合作将使Flock潜在访问的摄像头网络规模扩大数百万个。

背景与争议:

  • 访问范围扩大: 就在合作宣布的同日,有报道披露美国移民与海关执法局、特勤局及海军等机构已能访问Flock的摄像头网络。
  • 历史安全问题: Ring在保护客户视频安全方面记录不佳。2023年,美国联邦贸易委员会(FTC)曾因该公司员工及承包商多年来可不受限制地访问用户视频,对其处以580万美元罚款。
  • 技术偏见风险: 文章指出,执法机构使用的AI技术已被证明会加剧种族偏见。
16. Show HN: I'm making a detective game built on Wikipedia (detective.wiki)

Detective Wiki 是一款基于维基百科知识的探索类游戏,通过无尽的问题挑战玩家对全球概念、人物、地点和事物的认知。游戏的核心机制是通过问答形式,引导玩家发现和连接信息,从而考验其对世界的了解程度。

18. When you opened a screen shot of a video in Paint, the video was playing in it (devblogs.microsoft.com)

在旧版Windows(如Windows 98)中,若从媒体播放器截取视频画面并粘贴到画图程序,当媒体播放器继续播放时,视频内容会在画图中显示。这源于当时视频播放采用的覆盖层(overlay)技术,其核心机制如下:

  1. 技术原理

    • 媒体播放器不直接将视频像素绘制到屏幕。
    • 它会在屏幕上需要显示视频的位置填充纯绿色
    • 视频内容被渲染到与显卡共享的专用图形表面上。
    • 显卡被设置为:当检测到屏幕上特定区域的绿色像素即将输出时,自动替换为共享表面上的视频像素。这类似于色键(chroma keying)或绿幕技术。
  2. 优点

    • 格式灵活:共享表面无需与主屏幕像素格式一致,可直接匹配视频格式,避免格式转换。
    • 高效更新:只需更新共享表面,视频即可在下一帧显示,无需完整的窗口绘制流程,便于后台线程高帧率更新。
    • 无撕裂:可通过创建双表面实现“翻转”(flipping),在垂直消隐期间切换表面,实现整个屏幕瞬间更新,避免画面撕裂。
  3. 现象解释

    • 截屏内容:截屏捕获的是桌面像素,覆盖层所在的区域显示为绿色像素,而非实际的视频图像。
    • 画图中的播放:当此包含绿色像素的图像在画图中打开,且媒体播放器仍在运行时:
      • 显卡的覆盖层机制依然活跃。
      • 只要画图窗口位于媒体播放器窗口原先的屏幕位置(或覆盖层活跃的区域),显卡会继续将画图中的绿色像素替换为当前视频内容。
      • 因此,用户会看到视频在画图中“播放”。若移动画图窗口至其他位置或媒体播放器停止,画图中将只显示原始的绿色像素块。
  4. 覆盖层技术的缺点

    • 窗口遮挡异常:任何覆盖在媒体播放器窗口上且包含绿色像素的窗口区域,都可能意外显示视频。
    • 移动延迟:移动媒体播放器窗口时,覆盖层的跟踪可能存在延迟,导致显示卡顿。
    • 数量限制:显卡支持的覆盖层数量有限,用尽后需回退到传统的软件渲染。
  5. 现代技术演变

    • 如今,视频渲染不再依赖覆盖层。
    • 内容被渲染到与窗口关联的图形表面。
    • 桌面合成器负责组合所有窗口的图形内容,形成完整的桌面图像并发送到显示器。
    • 合成器能理解窗口位置、变换(如缩略图预览)和视觉特效,因此视频内容能随窗口无缝移动和变换,不再出现覆盖层技术的诸多问题。

总结:该现象是旧式显卡覆盖层技术的产物,截屏得到的是带有绿幕占位符的桌面图像。当原播放程序仍在运行时,显卡的硬件替色功能会将画图程序中的绿色区域实时替换为视频流,造成视频在画图中播放的错觉。

19. A conspiracy to kill IE6 (2019) (blog.chriszacharias.com)

文章摘要:YouTube 团队秘密淘汰 IE6 浏览器的行动

2009年,YouTube 的网页开发团队因 IE6 浏览器带来的巨大维护痛苦(如崩溃、服务器过载、每个开发周期耗费大量时间修复兼容性问题),决定秘密采取行动淘汰它。尽管 IE6 用户当时占 YouTube 流量的约18%,但团队已失去耐心。

计划与执行: 团队设计了一个仅对 IE6 用户显示的横幅,警告将“逐步停止支持该浏览器”,并建议升级到 Chrome、Firefox、IE8 等现代浏览器。横幅故意措辞模糊,不设定明确时间线,以规避直接废弃支持的承诺和内部审批。

关键机会: 团队抓住了 YouTube 被 Google 收购后的一个特殊时期。早期 YouTube 工程师保留了一种名为 “OldTuber” 的特殊权限,允许绕过严格的代码审查和部署流程,直接提交代码。团队中的少数成员通过其上司获得了此权限。他们利用该权限,将代码伪装成常规更新并秘密部署上线。

意外后果与扩散:

  1. 媒体与公众反应:横幅上线后,媒体将其报道为互联网的一大进步,对 YouTube 有利,公关团队在事后帮助完善了叙事。
  2. 内部掩盖:法律团队曾短暂担心浏览器列表排序问题,但通过演示随即打消顾虑。由于团队之外很少有人使用 IE6,且其他 Google 产品(如 Google Docs)的团队在看到 YouTube 的横幅后,误以为这是公司层面批准的行为,迅速推出了类似的 IE6 淘汰通知。
  3. 最终结果:这种“多米诺骨牌效应”导致 Google 内部多个产品和全球众多网站纷纷效仿,极大加速了 IE6 的淘汰。YouTube 的 IE6 用户比例在一个月内减半,全球 IE6 流量下降超过10%。

结局: 尽管团队明显滥用了权限,但鉴于行动取得了远超预期的积极结果,管理层最终默认了这一既成事实。团队成员受到上司私下提醒,但未受到正式处分。这次“阴谋”成为推动互联网技术向前迈进的一个成功但不可复制的案例。

20. Mysterious Intrigue Around an x86 "Corporate Entity Other Than Intel/AMD" (www.phoronix.com)

Posted to the Linux kernel mailing list and GNU Binutils mailing list today is an intriguing message from a longtime x86/x86_64 expert around a 'a corporate entity other than Intel/AMD' using some x86 opcodes not used by AMD or Intel processors.

21. A classified network of SpaceX satellites is emitting a mysterious signal (www.npr.org)

SpaceX星盾卫星网络发出神秘信号,疑违反国际标准

SpaceX为美国国家侦察办公室(NRO)运营的星盾卫星网络正发射一种神秘信号,该信号可能违反国际电信联盟的标准,并存在干扰其他卫星的潜在风险。

异常信号与发现过程

  • 加拿大业余卫星追踪者斯科特·蒂利在偶然操作中,于2025-2110 MHz频段(通常用于从地球向卫星发送上行指令的频段)发现了来自太空的下行信号。
  • 通过比对业余观测数据库,信号源被确认为星盾卫星。蒂利已检测到来自170颗星盾卫星的此类信号,其具体频率会频繁变动。

违规与潜在干扰

  • 上行专用频段发射下行信号,违反了国际电信协调规范。专家认为,此类操作有可能对邻近卫星造成射频干扰,影响其正常接收地面指令。
  • 科罗拉多大学教授凯文·吉福德表示,干扰风险“确实存在”,但目前尚未确认是否已造成实质性破坏。SpaceX及NRO均未回应置评请求。

星盾卫星背景

  • 星盾是SpaceX星链卫星的保密版本,美国政府已投入超过18亿美元。NRO自2024年5月以来已进行11次发射,目前在轨星盾卫星超过200颗
  • 该网络旨在执行地球观测与通信任务,以“增强数据获取的及时性、通信路径的多样性及系统韧性”。

信号目的推测

  • 与星链使用较高频率不同,星盾使用较低频段,数据传输速率可能接近3G水平。
  • 专家推测,SpaceX可能有意选择这一通常安静的频段以隐蔽其运行,或试图“先行动,后请求谅解”。
  • 蒂利选择公开发现,旨在提醒全球卫星运营商注意此潜在风险。
22. Hacker News – The Good Parts (smartmic.bearblog.dev)

Hacker News – The Good Parts

本文作者向女儿解释了自己常使用的Hacker News平台,并阐述了其积极方面的特点。

平台核心

Hacker News (HN) 是一个网站,注册用户可以提交指向其他网站的链接,其他用户可以对这些提交进行投票和评论。高票提交和评论会出现在首页。

内容特点

  • 满足知识好奇心:内容以信息科技为主,涵盖从哲学、商业、历史到生物学、数学、文学等广泛领域,深度从基础到前沿都有。
  • 无干扰:没有政治、琐事或垃圾信息。主流媒体新闻除非提供长期视角,否则较少出现。
  • 广度与深度兼备:既有小众话题也有主流话题,避免了信息茧房,也不会感到无聊。

运营与管理

  • 由两名专职人工版主(dang 和 tomhow)管理。
  • 用户通过投票和标记触发自我清理机制,使高质量内容和评论自然浮现。

影响力与参与度

  • 平台虽起源于硅谷,但讨论辐射全球西方科技圈。
  • 汇集了众多科技领域的重量级用户(如CEO和创始人)及各领域专家,他们通常以谦逊的方式分享知识和经验。

启发性与价值

  • 总有有趣的链接可供探索。
  • 评论往往比链接本身更有价值,能引导理解复杂话题、提供替代方案、纠正事实并挑战观点。
  • 讨论中常包含能带来启发的意外信息。

平台氛围

  • 注重实质:用户身份仅通过用户名代表,平台为纯文本形式,无多媒体干扰,专注于内容信号而非噪声。
  • 质量导向:无实质贡献的内容会被降权或标记,优秀论述则能平衡或替代不良讨论。

总结

Hacker News 是一个用于发现事物、跟踪有趣讨论、学习和交流思想的绝佳空间。作者认为,它是目前唯一一个能让参与者通过互动在智力上获得成长的“社交网络”,这可能是2025年一个互联网平台所能获得的最高赞誉。

注:本文仅侧重正面描述,作者表示负面观点将在另一篇文章中探讨。

23. test-ipv6.com will stay online (status.test-ipv6.com)
  • 网站命运变更:test-ipv6.com 原计划于 2025 年 12 月退休,但在宣布退役后,收到了众多个人和组织的帮助提议。目前,该项目正移交给一家地区互联网注册机构(RIR)接管,该机构将以公共利益为导向继续运营该网站。
  • 原退役原因:网站创始人自 2010 年起运营此网站,投入了大量工程、支持、设备及托管费用,且该产品不产生收入。创始人因个人原因(希望将资源重新集中于家庭)决定退役。
  • 技术资源状态:网站的大部分源代码已在 GitHub 上公开,但地理定位和服务提供商查询等部分因合同限制无法公开。
  • 镜像站点与域名:建议镜像站点运营者考虑在主要网站退役后关闭其镜像。创始人表示愿意将域名移交给一家服务公共利益的、信誉良好的 RIR 或 NIC 组织。
  • 对用户的影响:对于依赖该网站或相关标准(如 RIPE-631)编写支持手册的服务提供商,需要更新其文档。
  • 后续与反馈:创始人表示将随着事情进展分享更新。对于更多问题或评论,他幽默地建议在有机会一起喝咖啡或啤酒时再讨论。
24. Benjie's Humanoid Olympic Games (generalrobots.substack.com)

文章指出,当前类人机器人竞赛(如“世界类人机器人运动会”)侧重于娱乐性对抗,但公众更关注机器人能否替代人类完成家务劳动,例如折叠衣物。尽管折叠衣物视频展示了技术进步,但这仅是当前人工智能技术能轻松处理的“甜点区”任务;要实现通用、实用的机器人能力,仍需突破新技术。

作者提出“Benjie's 人形机器人奥运会”,通过一系列具体家务任务挑战机器人领域的现状。这些任务旨在推动技术前沿,每个事件都针对现有技术的局限性而设计。当前主流方法是“从演示中学习”:通过远程操作录制人类执行任务(如开门、折叠衣物)多次,再训练神经网络模仿。该方法已能处理部分混沌或高状态空间的任务,但存在四大瓶颈:

  1. 手腕缺乏力反馈:机器人表现受限于人类远程操作精度,且无法将力信息有效反馈给操作员。
  2. 手指控制有限:远程操作者和AI模型难以精细控制机器人手指,多只能实现开/合动作。
  3. 缺乏触觉:机器人手部传感器远不及人类手部密集的感知能力。
  4. 精度中等:任务执行精度约为1-3厘米,这更多是远程操作的限制而非模型本身。

例如,折叠毛巾和T恤无需高腕部力量、精细手指控制或高触觉,当前精度也足够,因此成为可行任务。

作者列出了具体挑战项目及其技术难点,部分已有参与者完成:

  • 开门系列:开门需应对不对称力、全身操作;自关门增加难度;旋转门需用肢体挡门或利用动力学。其中开门任务已被IHMC Robotics团队以18秒完成。
  • 衣物处理系列:将袜子从内到外翻、将袖子外翻的衬衫挂上衣架(需处理纽扣),这些任务对双手协调、手部尺寸和力量提出新挑战。
  • 工具使用系列:用喷雾瓶清洁窗户(需独立手指发力)、涂抹花生酱制作三明治(需稳定的“强力工具握持”)、用钥匙开锁(需高精度手内操作)、分离塑料袋(需指尖滑动和力量控制)。
  • 潮湿/不愉快任务:洗碗(涉及水、油)、清理宠物排泄物(需高力量与精细指尖操作),这些任务要求机器人手部具备防水或耐脏能力,且是实际家务中的常见需求。

为保证挑战公平性,作者设定规则:参赛需为1倍速、无剪辑视频,机器人需为通用移动操作体(允许轮式或半人马形态),任务可在作者用时10倍时间内完成。获胜者将获得实体奖牌,后续挑战者需比当前冠军快25%以上方可获奖。作者还提到,是否允许“固定于桌面的机械臂”参赛将通过投票决定。

文章最后感谢了提供帮助的同事和家人。

25. Play abstract strategy board games online with friends or against bots (abstractboardgames.com)

Play abstract strategy board games for free on AbstractBoardGames.com. Explore modern and classic strategy games. Have fun playing with friends or challenging the computer AI.

26. Cloudflare Sandbox SDK (sandbox.cloudflare.com)

Cloudflare Sandbox SDK 摘要

Cloudflare Sandbox SDK 提供了一套在安全、隔离的沙箱容器中执行命令、管理文件、运行服务并通过公共 URL 暴露服务的工具。

核心功能与特性:

  • 基础操作:支持在沙箱内执行 shell 命令、管理文件系统(如创建目录、读写文件)以及克隆 Git 仓库。
  • 长时间运行与实时流:可安全执行耗时任务,并支持实时监听标准输出和错误流。
  • 服务暴露:能将容器内的任何端口即时生成为带有自动子域名路由的公共预览 URL。
  • 代码解释器:可直接运行 Python 或 JavaScript 代码,并自动解析和返回富媒体输出(如图表、表格)。
  • 通信与终端:支持 WebSocket 连接,并提供具备 PTY 支持的完整交互式终端模拟。
  • 存储与集成:可将 S3 兼容的存储桶(如 R2、S3、GCS)挂载为本地路径。支持通过简单的 Dockerfile 将沙箱能力添加到任何自定义 Docker 镜像中。
  • AI 编码支持:为 OpenCode、Claude Code 等 AI 编码助手提供了预配置的沙箱环境。

使用示例: SDK 通过 getSandbox 函数在 Cloudflare Worker 中实例化。典型用例包括文件操作、运行应用程序与测试、建立 WebSocket 连接以及利用代码解释器。

用户反馈: 企业用户(如 Iterate、tscircuit.com、Zite)反馈该 SDK 显著简化了基础设施、改善了开发体验、减少了大量编排代码,并称赞其团队的响应支持。

27. Talent (www.felixstocker.com)

关于天赋的观察与思考

天赋的客观存在与表现

  • 高产作家的共性:顶尖财经通讯作者(如Matt Levine、Byrne Hobart)年产量可达70万字,日均约2000字。他们的工作状态往往表现为高强度、高频率的输出,却似乎不觉痛苦。
  • 其他领域的天才:数学家保罗·埃尔德什每天工作19小时,将咖啡因视为思考燃料;作家菲利普·克尔29年完成42本书,不间断写作。这些例子显示,某些人能在特定领域以极高的强度持续工作,且乐在其中。

天赋与努力的关系:Scott Alexander的寓言

  • 天赋不可否认:Alexander通过个人经历论证,个体在不同领域的能力差异巨大且往往与生俱来。例如:
    • 他在英语上无需费力即获顶尖成绩,但在数学上竭尽全力仅勉强及格。
    • 其弟弟在钢琴学习上迅速脱颖而出,而他自己始终平庸。
  • “汗血”努力的局限:在真正缺乏天赋的领域,即便付出巨大努力(如作者坚持苦练橄榄球多年),结果仍可能远不及有天赋者轻易达到的水平。努力可以提升水平,但难以逾越天赋设定的上限。

领域适配性:找到“天然属于”自己的事

  • 高绩效者的特质:优秀交易员往往具备在压力下极度理性、善于隐藏情绪或对行业痴迷至极的特质。对他们而言,长时间思考工作是一种自然状态,而非消耗意志力的苦役。
  • “资源瓶颈”的错觉:Scott Alexander指出,真正限制产出的往往不是时间,而是心力与意愿。享受某事的人能为其“免费”分配时间与精力(如他每天写长篇博客),这源于内在驱动而非强迫。
  • 核心启示:应优先投入能自然发挥优势、感到投入甚至“上瘾”的领域。在缺乏天赋的领域,极致努力可能获得一定成就,但成本高、上限低,且难以获得顶尖表现。

个人案例:橄榄球的启示

  • 天赋差距的直观体验:作者多年苦练橄榄球,体能显著提升,但对比赛的理解、时机的把握等核心能力始终无法与有天赋的队友相比。
  • 重要领悟:这段经历让他认识到,将汗水洒在自身天赋所在的领域,效率与成就感会截然不同。应追求“做起来自然”的事情,而非在短板上过度消耗。

结论:平衡天赋与努力

  • 天赋是真实存在的,它决定了个人在某一领域的潜力上限与努力效率。
  • 最佳策略是识别并深耕于自身天赋所在,让努力成为热爱的自然延伸,而非纯粹的意志消耗。
  • 若对缺乏天赋的事物(如烘焙)抱有兴趣,可作为业余爱好,但不宜作为主要的职业发展方向。关键在于找到能让自己的“火花”(spark)持续燃烧的领域。
28. K8s with 1M nodes (bchess.github.io)

将Kubernetes扩展到100万节点的技术挑战与解决方案

本文探讨了将Kubernetes集群扩展至100万节点规模所需克服的核心挑战,并重点介绍了作者在网络、状态管理和调度器三个关键领域采取的实践方案。

一、 网络:相对容易解决的挑战

在100万节点规模下,网络面临IP地址空间、服务发现和网络策略等挑战,但作者认为这是相对容易解决的部分。

  1. Pod IP地址分配

    • 采用纯粹的IPv6方案,利用其庞大的地址空间,为每个Pod分配全局可路由的公共IPv6地址,无需NAT或封装。
    • 根据不同云服务商(AWS、GCP、Vultr)对节点内IPv6前缀的分配和路由方式的差异(如/64/96/128),作者通过创建共享网桥并配合主机本地IPAM,为每个节点分配一个/96的IPv6前缀,从而提供充足的Pod IP。
  2. 处理IPv4外部依赖

    • 对于仅支持IPv4的外部服务(如GitHub、AWS ECR),作者通过自定义的WireGuard网关为所有VM提供IPv4出站访问。
  3. 网络策略的取舍

    • 由于100万个IPv6前缀远超任何防火墙规则的承载能力,作者放弃了传统的基于IP的网络策略。转而依赖TLS加密巨大的IPv6地址空间带来的扫描难度,以及有限的端口规则来保障安全。
  4. 网络连接数管理

    • 每个kubelet和kube-proxy至少需要一个到kube-apiserver的TCP连接。100万节点意味着每个kube-apiserver需要处理至少200万个TCP连接。这需要调整Linux内核参数(如文件描述符),并需注意云服务商可能存在的连接数限制。

二、 状态管理:etcd是核心瓶颈,需要重新设计

Kubernetes的状态通过kube-apiserver读写,最终由etcd持久化。在100万节点规模下,etcd的写入性能(QPS)和延迟成为无法逾越的瓶颈

  1. kube-apiserver与etcd的分工与瓶颈

    • kube-apiserver是无状态的,可以通过增加副本水平扩展。
    • etcd是状态化的,其强一致性、事务、多版本历史、范围查询和Watch等特性限制了其写入吞吐量(基准测试约5万QPS/实例,且增加副本会降低写入吞吐)。
    • 仅为了维持100万节点的Lease心跳(每节点每10秒一次),就需要10万次/秒的写入,这已接近单个etcd实例的极限。
  2. 对etcd特性需求的重新审视

    • 作者通过分析etcd代理日志发现,Kubernetes实际只使用了etcd接口的一个子集,主要模式是条件性Put(Txn-Put)
    • 许多资源(如Events、Leases)是短暂性的,对于数据一致性和持久性的要求并非最高。
    • 范围查询(Range) 是支持排序所必需的,但可以通过按资源类型(Kind)分治的B-树来优化,从而将时间复杂度从O(log N)降低为O(log M)(M为单类资源数量)。
  3. 构建定制化的内存etcd(mem_etcd)

    • 作者用Rust开发了mem_etcd,实现了Kubernetes所需的etcd子集接口。
    • 核心优化
      • 减少持久化开销:可配置禁用fsync,甚至将日志完全写入内存(如短暂资源),大幅提升写入QPS(从约10万QPS提升到超过100万QPS)。
      • 精简副本策略:质疑了在云环境中运行多副本etcd的必要性,认为对于许多工作负载,运行单副本配合网络附加存储(EBS) 可能是性能与可靠性之间更好的权衡。
      • 针对Watch的优化:Watch虽然产生网络放大效应,但主要瓶颈在kube-apiserver的缓存和etcd的出站带宽,可通过增加kube-apiserver副本和优化网络来缓解。
  4. kube-apiserver的内部瓶颈

    • 其Watch缓存需要处理每秒10万次以上的更新事件。基于B-树的缓存(K8s 1.32+默认)在写入并发和锁竞争方面存在瓶颈,可能导致缓存滞后。
    • 在作者的测试中,旧的基于哈希表的缓存配合多个kube-apiserver副本能更好地处理高Write QPS。
    • 大量资源的解析和解码会给Go的垃圾回收(GC) 带来压力,需要通过设置GOMEMLIMITGOGC进行调优。

三、 调度器:需要分布式改造

默认调度器的O(N*P)复杂度(N为节点数,P为Pod数)无法在100万规模下快速完成调度(目标:1分钟内调度100万Pod)。

  1. 分布式调度器架构

    • 采用扇出-汇聚模式。调度任务被分散到多个调度器分片,每个分片只负责一部分节点。
    • Relay组件监听未调度的Pod,并分发给调度器分片。
    • 每个Scheduler分片并行地对负责的节点进行过滤和打分,选出最佳节点。
    • 汇聚阶段收集所有分片的结果,由Relay选出全局最优节点,并通知对应的Scheduler分片执行绑定。
    • 通过乐观并发控制,假设大多数情况下并发调度不会冲突,冲突时再回滚重调度,以换取高吞吐。
  2. 应对分布式系统中的长尾延迟

    • 采用CPU绑核以减少上下文切换,提升任务执行的确定性。
    • 调整GC参数(高GOGC配合GOMEMLIMIT),减少GC对应用延迟的干扰。
    • 对响应过慢的“尾部”分片设置超时,不再等待,以避免整体延迟被拖慢。
    • 将调度器设计为ValidatingWebhook而非依赖Watch,以更同步、及时地感知新Pod的创建。
  3. 实验结果

    • 在10万节点集群上的测试表明,分布式调度器(单实例)的性能已显著优于默认调度器。
    • 通过增加调度器副本数量,调度时间呈线性下降,验证了该架构的有效扩展性。

总结:将Kubernetes扩展到100万节点需要对底层组件进行深度优化或重构。核心在于用纯IPv6解决网络寻址用定制化的内存状态存储(mem_etcd)替换etcd以突破写入性能瓶颈,以及用分布式分片架构改造调度器以并行化计算密集型任务。这些方案体现了在超大规模下,对一致性、持久性和功能完备性进行权衡,并针对实际负载模式进行极致优化的工程思路。

29. Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl (martinfowler.com)

理解规范驱动开发:Kiro、Spec-Kit与Tessl

定义与层次

规范驱动开发(SDD)的核心理念是在编写代码前先编写“规范”(文档优先),规范成为人类与AI共同遵循的真理来源。目前该定义仍在演进,但已可观察到三个实施层次:

  • 规范先行:先编写详尽的规范,再用于AI辅助开发工作流。
  • 规范锚定:任务完成后仍保留规范,用于后续功能演进与维护。
  • 规范即源:规范是主要维护对象,人类仅编辑规范,从不直接修改代码。

当前所有SDD工具均支持“规范先行”,但并非都致力于“规范锚定”或“规范即源”。

“规范”是什么?

规范是结构化、面向行为的工件,用自然语言表达软件功能,用以指导AI编码代理。它区别于通用代码库上下文文件(如规则、产品描述),后者跨所有会话有效,而规范仅关联特定功能任务。

三种工具的工作流与特点

1. Kiro

  • 定位:最轻量的工具,专注于规范先行。
  • 工作流需求 → 设计 → 任务,每一步对应一个Markdown文件。
    • 需求:以用户故事和验收标准列表形式结构化。
    • 设计:包含设计决策的文档。
    • 任务:可追溯至需求的任务清单,支持逐项执行与审查。
  • 上下文管理:称为“引导”(steering),默认生成产品、结构、技术等文件。
  • 特点:流程简单直观,但评估中发现对小型问题可能过于繁琐。

2. Spec-Kit(GitHub)

  • 定位:高度可定制的CLI工具,为各类编码助手生成工作区结构。
  • 工作流宪法 → 𝄆 制定规范 → 规划 → 任务 𝄇(循环迭代)。
    • 宪法:存放不可变的高层原则,作为强规则文件贯穿整个流程。
    • 各步骤生成大量Markdown文件与检查清单,用于跟踪澄清、违规审查等。
  • 上下文管理:通过“宪法”实现,强调为活文档。
  • 特点:虽宣称规范应是活文档,但实际为每个规范创建分支,表明其仍以单次变更请求为生命周期(即规范先行)。评估显示流程对于中等规模问题可能过于复杂。

3. Tessl 框架(测试版)

  • 定位:明确致力于规范锚定,探索规范即源模式。
  • 工作流:通过CLI生成工作区结构,并兼任MCP服务器。
    • 规范可作为主要维护工件,代码顶部可添加“// GENERATED FROM SPEC - DO NOT EDIT”注释。
    • 目前采用规范与代码文件一对一映射,但未来可能扩展至组件级别。
  • 特点:规范处于较低抽象级别(每文件一规范),旨在减少LLM解释步骤与错误。但即便如此,代码生成仍存在非确定性,需通过细化规范提高可重复性。

观察与问题

  1. SDD并非统一概念:三种工具虽同贴SDD标签,实现差异显著。
  2. 工作流通用性存疑:现有工具提供的单一工作流可能不适用于多数现实问题规模(如小修小补或大功能)。
  3. 规范审查负担:生成大量Markdown文件可能带来冗余与审查疲劳,部分场景下直接审查代码更高效。
  4. 控制幻觉风险:即使有复杂流程与清单,AI代理仍可能忽略或过度解读指令,缺乏可靠一致性。
  5. 功能与技术规范分离困难:实践中难以清晰划分,且行业在此方面历史表现不佳。
  6. 目标用户不明确:工具演示常涉及需求分析术语(如用户故事),但未明确是否旨在培养开发者需求能力或促进跨角色协作。
  7. 历史教训:规范即源模式与模型驱动开发(MDD)有相似之处,需吸取MDD因抽象层级尴尬、过度约束而未能推广的教训。LLM虽消除了部分约束,但也引入了非确定性。

结论

规范先行原则在AI辅助开发中具有价值,如何构建良好的规范结构是当前实践者高频关注的问题。然而,“规范驱动开发”一词定义模糊、语义泛化,工具仍面临工作流通用性、审查效率、可控性等挑战。过度复杂的流程可能适得其反,在尝试改进的同时反而增加了负担。

30. Claude Code vs. Codex: I built a sentiment dashboard from Reddit comments (www.aiengineering.report)

I scraped hundreds of Reddit comments that compare Claude Code and Codex, and used Claude Haiku to build a sentiment analysis dashboard. The dashboard and my interpretations are shared here.

31. Dead or Alive creator Tomonobu Itagaki, 58 passes away (www.gamedeveloper.com)

板垣伴信去世,享年58岁

前特库摩(Tecmo)游戏总监、知名游戏系列《死或生》和《忍者龙剑传》的创造者板垣伴信去世,享年58岁。其家人通过其Facebook页面发布了消息,并附上了他生前最后的留言。

最后的留言 在最后的帖子中,板垣伴信(经谷歌翻译)写道:“我生命的光芒即将燃尽。”他将自己的人生描述为“一系列战斗”,并称自己一直坚持自己的信念,“没有遗憾”。他还为无法与粉丝分享“新作”而感到惋惜,并以英文短句“so it goes”作为结尾。

职业生涯与主要成就 板垣伴信于1992年加入特库摩,职业生涯初期参与了《特库摩超级碗》的游戏开发。他最为人熟知的成就是:

  • 创立并主导了《死或生》系列(始于1996年)。
  • 在2004年成功复活了《忍者龙剑传》系列。 他于2001年接管Team Ninja工作室,2004年升任特库摩执行官。然而,他在2006年因被指控性骚扰而被免职,但东京法院于2007年裁定指控不成立。

职业生涯后期 2008年,板垣伴信因奖金纠纷起诉特库摩后离职。他随后创立了Valhalla Games工作室,并于2015年推出了Wii U独占游戏《恶魔第三》。2017年离开该公司后,他于2021年创立了Itagaki Games回归游戏开发,但目前尚不清楚该工作室是否有作品问世。

个人风格与争议 板垣伴信以其标志性的黑色皮夹克、墨镜以及张扬的个性而闻名。业内报道也指出,他曾在行业活动中行为不当,并对游戏中的角色发表过一些不当言论。

业界反响与遗产 他的去世引发了游戏界同仁的悼念。《铁拳》系列导演原田胜宏发文称他的离世“太早了”。板垣伴信在2011年的一次采访中曾表示,并非所有人都需要像他一样活在边缘,但他个人对自信的哲学是:“自信必须来自内心,基于你过去的成就,以及你能支撑它的能力。”

板垣伴信身后留下了妻子和一个28岁的女儿。

32. Free the Internet: The Tor Project's annual fundraiser (blog.torproject.org)

文章主题:Tor项目年度筹款活动呼吁支持互联网自由,反对监控和审查。

核心内容

  • 目标:Tor项目致力于构建一个免受监控和审查的自由互联网,其工具(Tor网络、Tor浏览器、Tails OS)免费供全球数百万用户使用,且绝不收集、出售或交易用户数据。
  • 实际应用
    • 在土库曼斯坦等信息管控严格的国家,Tor帮助提供安全的互联网访问。
    • 保护新闻自由,为记者和信源提供安全通信工具(如SecureDrop)。
    • 在俄罗斯和埃及等封锁加密工具的地区,帮助用户访问加密通信服务。
  • 筹款活动
    • 作为501(c)(3)非营利组织,Tor依赖捐赠运营。当前筹款活动(至2025年12月31日)中,所有捐赠将由Power Up Privacy进行1:1匹配(最高25万美元),即捐款效果翻倍。
    • 捐赠超过25美元可获赠Tor周边商品。
  • 资金使用:2023-2024财年,84%的支出用于项目服务,包括技术研发、外展和安全维护。Tor项目获Charity Navigator四星评级及Candid白金透明印章,彰显财务透明度和高效性。
  • 参与方式
    • 直接捐赠或申请公司配捐。
    • 通过社交媒体分享活动。
    • 订阅Tor新闻邮件。
  • 相关活动
    • 2025年11月12日和12月10日将举办两场线上“State of the Onion”年度活动,分享项目进展与社区动态,纪念《世界人权宣言》。
33. Next steps for BPF support in the GNU toolchain (lwn.net)

Support for BPF in the kernel has been tied to the LLVM toolchain since the advent of extended [...]

34. Ask HN: How does one build large front end apps without a framework like React?

这篇文章探讨了不使用React等前端框架构建大型前端应用的方法与优势。作者通过Obsidian桌面应用未使用前端JS框架的例子,阐述了以下观点:

不使用框架的主要优势:

  1. 项目寿命更长:Web标准变动缓慢且成熟,避免了框架快速迭代带来的破坏性变更,减少了维护负担。
  2. 开发效率更高:稳定性让团队能专注于功能实现,而非不断解决兼容性问题。
  3. 独立性与安全性:项目成功不依赖于特定框架,降低了供应链攻击的风险。
  4. 控制权与性能优化:无框架抽象层,开发者可深入底层进行性能优化。
  5. 提升开发者理解:直接处理底层代码有助于加深对技术原理的掌握。

作者寻求的建议:

  • 学习如何在不依赖框架的情况下构建大型、复杂、基于浏览器的Web应用。
  • 寻找符合此条件的开源项目参考(尤其关注前端)。