2026 05 08 HackerNews

2026-05-08 Hacker News Top Stories #

  1. 美国国会图书馆将 SQLite 列为长期存储推荐格式;讨论中有人提到更轻量的只读替代如 PeakSlab 及 SQLite 的 wasm 体积与连接性能取舍。
  2. Burning Man 通过 MOOP 地图量化清理难度以达成极低垃圾标准,清理多由志愿者在恶劣环境中完成且整体表现逐年改进,但仍有遗留如固定螺栓等问题。
  3. 作者认为技术团队在资本驱动与 AI 焦虑下迷失,初级岗位萎缩与经验传承断层加剧,呼吁回归长期建设与师徒制。
  4. 克鲁格曼指称特朗普任内石油期货多次疑似内线交易、监管失灵损害市场功能并滋生掠夺型经济,引发对战争牟利与选民责任等更广泛争议。
  5. Chrome v148 移除“设备端 AI 不发数据至谷歌服务器”的表述,引发用户对潜在回传与训练用途的不信任与隐私担忧。
  6. 谷歌以 Fraud Defense 升级 reCAPTCHA 抗 AI 欺诈,被担忧将借设备完整性校验把网页访问与“认证设备”绑定、加剧对用户隐私与自由的限制。
  7. Inkscape 1.4.4 以稳定性与性能修复为主并加入少量小改进(如默认文件名),但部分用户仍抱怨书法笔等工具体验不佳。
  8. 尼日利亚“Pathways to Choice”通过多维支持促使女孩持续在校,使童婚率两年降约80%并带来教育溢出与高收益,但效果依情境且需长期评估。
  9. Val Town 因外部会话表与限流等问题放弃 Clerk,转向可自托管的 Better Auth 以降低单点与供应商风险,同时权衡自建认证的复杂度与维护成本。
  10. 作者主张将确定性的控制流程与验证逻辑放在运行时,用 LLM 作组件而非大脑,并通过任务拆分与子代理提升可靠性与可审计性。

https://sqlite.org/locrsf.html

该网页介绍了 SQLite 作为美国国会图书馆推荐的数据集存储格式。根据网页内容,SQLite 被认为是一种小巧、快速且可靠的存储格式,适合长期保存和访问数字内容。

网页详细说明了“推荐存储格式”的定义,即那些能够最大化数字内容存续和持续可访问性的格式。推荐标准包括多个方面:

  1. 公开性:格式的完整规范和验证工具是否公开且易于获取,重点在于是否有完整文档,而非是否由标准机构批准。
  2. 采用度:格式在信息资源创建者、传播者和用户中的使用广泛程度,包括作为主格式、交付格式和系统间交换格式。
  3. 透明度:数字表示是否可以通过基本工具直接分析,例如是否能用纯文本编辑器阅读。
  4. 自我描述性:数字对象是否包含基本的描述性、技术和管理元数据。
  5. 外部依赖:格式是否依赖特定硬件、操作系统或软件,以及未来处理这些依赖的复杂性。
  6. 专利影响:专利是否会阻碍档案机构持续保存内容。
  7. 技术保护机制:是否存在加密等机制,阻碍可信存储库保存内容。

此外,网页指出截至 2018 年,除了 SQLite,国会图书馆还推荐 XML、JSON 和 CSV 作为数据集的存储格式。页面还提供了相关链接,供用户了解更多关于推荐存储格式的信息。


HN 热度 595 points | 评论 179 comments | 作者:whatisabcdefgh | 1 day ago #

https://news.ycombinator.com/item?id=48042434

  • PeakSlab 是一个比 SQLite 更轻量、更快的数据库格式,适合只读场景,特别适合字典和文件归档,支持 zstd 压缩,wasm 模块仅 38kb。
  • SQLite 的 wasm 和 JavaScript 代码体积较大,约 1.2MB,加载较慢,不适合某些轻量级 PWA 字典应用。
  • PeakSlab 更简单,设计上不支持复杂的写操作,适合不可变数据存储,更像字典格式而非传统数据库。
  • BerkeleyDB 和 SSTables 等传统键值存储系统与 PeakSlab 有相似之处,但它们通常支持写操作且许可和生态不同。
  • SQLite 设计简洁,支持多种 SQL 功能,包括各种连接操作,但某些复杂连接(如全外连接)可能性能较差,需合理建索引优化。
  • 使用文本文件或简单格式存储数据虽然简单,但缺乏索引导致查询性能差,且难以保证数据一致性。
  • 对于图像扫描压缩,有人采用 16 色量化和 PNG 压缩,JBIG2 解码在某些场景下能提供更高效的单色图像存储。
  • SQLite 作为成熟稳定的项目,适合需要写操作和复杂查询的应用,且支持多读写模式和持久化 IPC。
  • PeakSlab 针对特定需求优化,适合跨平台 PWA 字典应用,提供全文搜索和 HTML 标签处理,解决了 SQLite 加载慢和文件大问题。

2. 燃人节 MOOP 地图 (The Burning Man MOOP Map) #

https://www.not-ship.com/burning-man-moop/

这篇文章介绍了美国内华达州每年举办的 Burning Man 活动及其环境保护措施。活动期间,约 7 万人在干涸的湖床上搭建临时城市 Black Rock City,活动结束后城市会被完全拆除。然而,仍有约 150 人负责在活动场地上进行细致的清理工作,寻找并清除“MOOP”(Matter Out of Place,意为“错位物质”),包括螺丝、亮片、烟头等各种垃圾。

文章重点介绍了 2025 年 Burning Man 的 MOOP 地图,这张地图通过颜色标示不同区域的清理难度和垃圾量,黄色表示中度污染,红色表示污染严重,清理工作难以推进。环境恢复经理 Dominic Tinio(昵称 DA)解释说,MOOP 地图帮助社区了解自己的环境影响,确保活动符合美国土地管理局(BLM)的严格标准,即每英亩地面上不得有超过一平方英尺的垃圾。

文章还提到,BLM 每年会在场地上进行 120 个点的检测,2023 年有 11 个点超过了限制,接近未通过标准。2025 年发现的垃圾中,最多的是用来固定帐篷和艺术装置的螺栓。MOOP 团队会将清理数据反馈给相关营地,促使他们改进,严重违规者会被记录并影响未来的营地分配。

MOOP 地图已有 20 年历史,数据显示尽管 Black Rock City 规模不断扩大,社区在“无痕原则”(Leave No Trace)上的表现逐年改善。DA 认为,MOOP 地图的最大作用是推动社区不断进步,增强环保意识。

文章最后提到,虽然作者完成了为 Not-Ship 网站招募会员的活动,但这项工作仍依赖读者支持继续进行。文章还推荐了其他有趣内容,如利用弹珠演奏的乐器 Wintergatan 和一个全由“buffalo”组成的语法正确句子。


HN 热度 507 points | 评论 271 comments | 作者:speckx | 10 hours ago #

https://news.ycombinator.com/item?id=48049653

  • 清理 Burning Man 遗留垃圾的工作非常辛苦,需要在无遮蔽的环境下徒步捡拾,并且对垃圾进行详细记录和拍照,确保符合极低的污染标准。
  • 参与清理工作不仅是体力活,也带来团队合作和成就感,是活动成功的重要保障。
  • 其他黑客营地的搭建和清理工作也有类似的体验,参与者享受与志同道合的人共度时光的过程。
  • Burning Man 的艺术装置搭建者可以提前进入现场,体验独特的筹备过程。
  • 清理团队成员通常是志愿者,也有部分带薪岗位。
  • 清理工作使用定制软件和电子设备进行数据记录和管理。
  • 去年因连续多天暴雨和强风,导致场地泥泞且垃圾更难清理,增加了清理难度。
  • 泥泞使得垃圾隐藏在泥土中,清理时需要破碎泥块并仔细筛查,工作强度大大增加。
  • 雨后路面变得坑洼不平,影响交通和骑行体验。
  • 参与者分享了防止泥巴粘鞋的各种有趣方法,但实际清理泥巴仍然是个挑战。
  • 1998 年 Burning Man 结束后遭遇暴雨,导致车辆陷入泥泞,部分人被困数周,显示恶劣天气对活动影响巨大。

3. 编程依然糟糕 (Programming Still Sucks) #

https://www.stvn.sh/writing/programming-still-sucks-fqffhyp

这篇文章以作者在生日派对上被问及人工智能是否会取代技术工作者的经历为开端,探讨了当前科技行业的困境和变化。作者指出,尽管外界对技术工作的想象充满理想化,但现实却充满了混乱和不确定性。技术团队面临着管理混乱、缺乏明确方向和资源削减的困境,AI 的引入虽提高了部分生产力,但也带来了裁员和焦虑。

文章通过一个比喻——船长被迫接管一艘结构混乱、功能失调的船,形象地描述了技术领导者在快速变化和资源紧缩环境中的无奈和压力。作者回忆了过去技术团队中师徒制和代码审查的重要性,强调这些传统培养方式的消失导致了经验和技能的断层。

作者还提到,随着初级工程师的减少,团队失去了未来高级工程师的培养土壤,长远来看将面临更大的人才缺口。尽管如此,仍有一些资深员工默默维护着关键系统,确保基础设施的稳定运行,但他们的工作往往被忽视。

整体上,文章反映了技术行业在 AI 浪潮和管理压力下的复杂现实,呼吁关注技术团队的长期健康和经验传承,而非单纯追求短期效率和成本削减。


HN 热度 482 points | 评论 272 comments | 作者:jeromechoo | 1 day ago #

https://news.ycombinator.com/item?id=48040269

  • AI 并非夺走工作岗位的罪魁祸首,真正的问题是贪婪和资本驱动的剥削。
  • 编程行业充满了腐败和对社会的破坏,许多人因此选择转行寻找“更真实”的职业。
  • 科技本意是改善社会,但实际效果往往适得其反,AI 只是众多负面影响中的一个例子。
  • 年龄影响对科技的看法,经历过多次失望的老一辈更为悲观,而年轻人则抱有更多希望和天真。
  • 快速变化的时代让老一辈的经验变得不再有用,年轻人凭借天真和新知识占据优势。
  • 老一辈的知识能识破许多虚假承诺,但年轻人因天真被雇佣重复错误,助长了剥削。
  • 资深从业者的价值在于能够拒绝不合理的要求,但管理层往往不愿听取这种声音。
  • 过去自由开源软件的理想与现今被企业控制的现实形成鲜明对比。
  • 技术本身是中立的,但其应用和部署往往带来负面后果。
  • 技术进步常被用于军事和控制目的,反映出人类本性未变。
  • 过去几十年相比,许多人更怀念上世纪六七八九十年代的生活状态。
  • 有些人选择逃离现代社会,寻找更简单的生活方式,但现实中难以完全脱离资本主义影响。

4. 盗窃石油期货:内幕交易者不断在我们利益上大发横财 (Grand Theft Oil Futures: Insider traders keep making a killing at our expense) #

https://paulkrugman.substack.com/p/grand-theft-oil-futures

本文由保罗·克鲁格曼撰写,揭露了特朗普政府期间频繁发生的石油期货内幕交易现象。文章指出,每当特朗普就伊朗战争发布重大声明前,市场上都会出现大规模、极其盈利的石油期货空头交易,这些交易明显利用了内幕消息,提前获利数亿美元。例如,某次在 Axios 报道美伊接近达成协议前 70 分钟,就有价值约 9.2 亿美元的空头合约被大量抛出,随后油价大幅下跌,内幕交易者获得巨额收益。

这种内幕交易不仅反映了特朗普政府对相关违法行为的放任,也暴露出市场监管的严重缺失。内幕交易破坏了期货市场的正常功能,削弱了市场作为风险对冲工具的作用,使得普通买卖双方可能在信息不对称的情况下遭受损失,进而降低了市场的整体效率和经济稳定性。

克鲁格曼进一步指出,这种现象是更广泛“掠夺型经济”崛起的一个缩影。在这种经济环境中,商业成功更多依赖于关系和内部信息,而非公平竞争和创新,这不仅损害了经济增长,也侵蚀了社会的道德基础,可能导致国家走向衰退。文章呼吁关注和反思这种腐败现象对经济和社会的深远影响。


HN 热度 476 points | 评论 305 comments | 作者:Qem | 13 hours ago #

https://news.ycombinator.com/item?id=48047981

  • 石油期货价格的剧烈波动背后是战争和人类痛苦,而非偶然。
  • “血流成河时买入”这句话被误用,原指股票投资,不应简单套用到战争和石油市场。
  • 对罗斯柴尔德家族的批评有时被指控为带有种族主义色彩,但这是一种长期存在的战争暴利指责。
  • 罗斯柴尔德家族近期与杰弗里·爱泼斯坦等丑闻有关联,引发阴谋论和争议。
  • 选民对政治现状负有部分责任,不投票也被视为默认现状。
  • 投票率低导致现有政治人物容易连任,建议实行强制投票和将投票日设为法定假日。
  • 有人建议未通过预算应立即重新选举,避免政府关门。
  • 特朗普在任期间有军事冒险倾向,部分被内阁专业人士制约,后来更换内阁后局势恶化。
  • 特朗普的部分军事行动和外交策略早有迹象,疫情是阻止其进一步行动的因素。
  • 民众对特朗普军事冒险的警告曾存在,但未被主流媒体广泛报道,部分因政治反击和舆论操作。

5. Chrome 取消了关于本地人工智能不向谷歌服务器发送数据的声明 (Chrome removes claim of On-device Al not sending data to Google Servers) #

https://old.reddit.com/r/chrome/comments/1t5qayz/chrome_removes_claim_of_ondevice_al_not_sending/

Chrome 删除了"设备端 AI 不会向 Google 服务器发送数据"的说法

我怀疑根本没人用这个"功能",但还是要说一下。

更新前

Chrome v147.0.7727.138 写道:“Chrome 可以使用直接在您的设备上运行的 AI 模型,无需将您的数据发送到 Google 服务器。”

更新之后,他们删除了这一说法,所以数据很可能会被发送给 Google。 Chrome v148.0.7778.97 删除了该说法。


HN 热度 422 points | 评论 159 comments | 作者:newsoftheday | 8 hours ago #

https://news.ycombinator.com/item?id=48050964

  • 将 AI 集成到桌面应用并将数据发送回服务器是收集用户数据的有效手段,许多用户对此毫不知情。
  • 这种数据收集行为类似于 Windows Recall 的做法。
  • 有人将 Chrome 戏称为“互联网浏览器”,暗指其对互联网的探索功能。
  • 用户对是否能控制自己的信息发送给 Google 以及数据是否被用于训练感到不确定和担忧。
  • 谷歌此前声称不会发送数据,但实际情况可能并非如此,用户对谷歌的信任度低。
  • 大型科技公司普遍存在大规模数据收集,常用暗箱操作或推断方式获取用户数据。
  • 政府通过法律手段获得对这些数据的访问权,用户隐私保护形同虚设。
  • 有观点支持互联网内容发布需实名制,以便识别虚假信息和境外干预。
  • Firefox 提供了阻止未来 AI 集成的选项,但用户对其是否有效持怀疑态度。
  • AI 业务的核心在于数据收集,模型质量次于数据量,数据对保险商和广告商等买家有价值。
  • 浏览器通过分散用户群体绕过网站反爬措施,利用用户端完成数据采集。
  • 谷歌因其特殊地位无需担心反爬措施,网站主动允许谷歌爬取数据。
  • 科技公司与政府关系密切,数据收集行为部分是为政府服务。
  • AI 公司成为军事承包商,推动对 VPN 和匿名行为的限制,监控资本主义趋势明显。
  • 拥有独特数据源(如 Chrome 用户数据)的模型提供商在竞争中占优势。
  • 有观点质疑 Chrome 是否真的将数据发送回 Google,若属实将引发合规问题。
  • Chrome 长期记录用户活动元数据,用户可选择关闭相关记录。
  • 许多用户对 Chrome 的数据收集行为早已习以为常。
  • 对 Chrome 此次行为感到意外和讽刺。
  • 质疑此类数据收集是否合法,担心监管机构因公司体量过大而无力处罚。

6. 谷歌云欺诈防御:reCAPTCHA 的下一代进化 (Google Cloud fraud defense, the next evolution of reCAPTCHA) #

https://cloud.google.com/blog/products/identity-security/introducing-google-cloud-fraud-defense-the-next-evolution-of-recaptcha/

本文介绍了谷歌云最新推出的 Google Cloud Fraud Defense 平台,这是 reCAPTCHA 的进化版,旨在应对自主 AI 代理带来的新型欺诈和滥用风险。该平台通过验证机器人、人类和 AI 代理的合法性,帮助企业保护数字交互和电子商务安全。

Fraud Defense 提供了多项核心功能:一是“代理活动测量”,通过仪表盘和行业标准技术识别和分析代理流量,了解风险和信任状况;二是“代理策略引擎”,允许企业根据风险评分、自动化类型和代理身份等条件,灵活控制用户和代理的访问权限;三是“AI 抗性挑战”,通过新型二维码挑战验证人为操作,阻止恶意自动化请求。

该平台继承并扩展了 reCAPTCHA 的核心防护能力,现有用户无需迁移即可自动成为 Fraud Defense 客户。Fraud Defense 通过三大策略保障安全:防范不断演变的威胁,覆盖整个客户数字旅程的风险管理,以及减少用户操作摩擦,提升业务转化率。数据显示,该平台能显著降低账户接管风险,并支持 AI 购物助手提升平均订单价值。

谷歌云鼓励用户访问 Fraud Defense 官网和控制台,参与 Next ‘26 大会,了解更多功能并体验演示,助力企业在自主 AI 时代构建安全可信的数字环境。


HN 热度 392 points | 评论 406 comments | 作者:unforgivenpasta | 1 day ago #

https://news.ycombinator.com/item?id=48039362

  • 未来浏览网页可能需要现代安卓设备且安装 Google Play 服务,iPhone/iPad 也需满足相应条件。
  • Google Play 服务的要求暗示设备需通过 Play Integrity 认证,即设备必须是“认证安卓”设备。
  • 设备完整性验证可能会逐步引入,采用“逐步推进”的方式减少用户反弹,最终实现设备锁定。
  • Google 与政府和军方合作加深,同时限制用户隐私和自由,用户权益受到威胁。
  • 许多用户因频繁出现验证码而转向其他搜索引擎,尤其在使用隐私浏览模式时更常见。
  • Google Play 服务不一定强制要求设备完整性 API 支持,但具备该能力的设备更可能通过验证。
  • 使用未登录 Google 账号的设备访问 Google 服务时,可能更频繁触发验证码。
  • 一些用户拒绝使用 Google 账号,导致无法安装官方应用,影响正常使用。
  • 有替代方案如 Aurora Store 可匿名下载应用,但存在隐私泄露风险。
  • 对于设备锁定和身份验证,部分用户更愿意接受政府提供的匿名身份验证方案,而非依赖海外科技公司。
  • 不同用户对政府和海外公司的信任度不同,有人更担心政府监控,有人则担心企业限制自由。

7. Inkscape 1.4.4 发布说明 (Inkscape 1.4.4) #

https://inkscape.org/doc/release_notes/1.4.4/Inkscape_1.4.4.html

该网页是 Inkscape 1.4.4 版本的发布说明,发布于 2026 年 5 月 6 日。Inkscape 1.4.4 是一个维护和修复版本,主要内容包括:

  • 修复了 20 个崩溃问题,其中包括三个导致 Inkscape 无法启动的严重错误。
  • 修复了近 20 个其他 bug,提升了 6 项性能。
  • 新增了一个调色板和一个用于将星形和多边形旋转至“中立”或“直立”位置的新按钮。
  • 更新了 27 种界面语言翻译和 15 种文档翻译。
  • 提供了适用于 Windows ARM 架构的安装文件。

该版本作为桥接版本,支持将计划中的 Inkscape 1.5 多页面文件格式转换为 1.5 之前的旧格式,保证旧版本的兼容性。新格式采用标准的 svg:view 元素,增强了跨 SVG 查看器的兼容性。

崩溃修复涵盖启动时重复文件条目、Windows 不同驱动器的文件访问、图形平板启动、创建和撤销新页面、Unicode 字符对话框关闭、特定 PDF 和 SVG 文件打开、导入图像尺寸设置、文本工具、连接器工具等多种场景。

用户界面方面,修正了图层和对象对话框中移动对象时边界框显示错误,提升了大量路径文档的缩放速度,更新了包含版本号的图形,修复了反向裁剪释放后裁剪路径不可见的问题,优化了复制粘贴大批带渐变对象的速度和格式稳定性。

对话框改进包括填充和描边对话框颜色调整时减少撤销记录,图层和对象对话框在大量选中对象时打开更快,支持右到左语言展开对象对话框,调整对象不透明度时保存样式,提升对象属性对话框选择路径速度,优化偏好设置中节点删除算法说明,修复欢迎对话框多窗口打开内容重复问题。

工具改进有渐变工具编辑速度提升,星形/多边形工具新增“转为直立”按钮,文本工具改进了对齐文本中固定宽度空白的处理和文本渲染时对语言元数据的支持。

新增功能包括为“粘贴到页面”设置快捷键,添加了 Elementary OS 的调色板,修正了 US zine 模板中的数字与描述不匹配问题,命令行帮助信息优化,Windows ARM 版本不再打开终端窗口。

整体来看,Inkscape 1.4.4 版本主要聚焦于稳定性和性能提升,修复了大量崩溃和界面问题,增强了多语言支持和用户体验,同时为即将到来的 1.5 版本做了兼容性准备。


HN 热度 341 points | 评论 104 comments | 作者:s1291 | 1 day ago #

https://news.ycombinator.com/item?id=48040622

  • 这次 Inkscape 1.4.4 版本新增了允许用户设置默认保存文件名的小功能,提升了使用体验。
  • 有用户希望默认文件名能自动使用上一次保存的文件名,减少设置步骤。
  • 有人感谢贡献者,认为这些小改进让软件更好用。
  • 目前默认文件名仍是 draw.svg,但可以手动更改。
  • 有用户建议增加带日期戳的命名功能。
  • 书法笔工具仍存在严重问题,响应慢且效果差,且需要 Windows Ink 支持,用户体验不佳。
  • 书法笔工具的问题已经存在多年,且在 1.x 版本中退步明显,用户期待后续版本改进。
  • Inkscape 作为免费开源软件,用户应理解其开发资源有限,适当表达意见并支持贡献。
  • 有观点认为批评软件不等于攻击开发者,合理反馈有助于软件进步。
  • 也有观点指出过度苛责和无休止的抱怨会让开发者感到疲惫,影响积极性。

8. 当尼日利亚女孩继续上学时,童婚率大幅下降 (Child marriages plunged when girls stayed in school in Nigeria) #

https://www.nature.com/articles/d41586-026-00720-8

这篇政策简报介绍了一项在尼日利亚北部实施的多方面干预项目“Pathways to Choice”,该项目旨在减少未成年少女早婚现象。研究发现,通过鼓励 12 至 17 岁的未婚少女接受教育和培训,该项目使两年后少女结婚率从 86% 大幅下降至 21%,减少了 80%。此外,项目显著提高了女孩的学校出勤率,增强了她们的社会支持、自我认知和自我倡导能力。

该干预还带来了溢出效应,参与者的弟妹入学率也显著提升,姐妹入学率增加 87%,兄弟增加 41%。经济效益方面,每投入 1000 美元,项目带来了 1627 美元的净收益,收益成本比达到 2.41。研究强调,尽管项目前期投入较高,但多角度、综合性的干预措施在解决复杂社会问题上更具成效。

文章指出,全球约有 6.5 亿女性曾在 18 岁前结婚,尤其是在尼日利亚北部,早婚率高达 80%。早婚对少女的健康、教育、经济收入及安全均有负面影响,阻碍其发展。项目的成功表明,提供教育机会并克服经济和社会障碍,是延迟少女结婚年龄的有效途径。

最后,研究提醒,项目效果受社会文化背景影响较大,适用于教育尚未普及且社会接受教育作为替代早婚的地区。长期效果仍需进一步跟踪评估。整体来看,该研究为制定减少早婚的政策提供了有力的实证支持。


HN 热度 325 points | 评论 249 comments | 作者:surprisetalk | 10 hours ago #

https://news.ycombinator.com/item?id=48049208

  • 基础设施项目(如修路)和促进女性权益的性别项目对社区的长期经济影响最大且持久。
  • 基础设施建设如道路能促进教育和市场经济发展,且不依赖持续资金维护。
  • 性别项目通过改变对女性的态度和消除结构性障碍,提升社区经济多样性和产出,效果持久。
  • 教育和卫生项目效果不稳定,资金一旦停止,设施往往无法正常运转。
  • 在无有效政府和安全保障的地区,基础设施容易被破坏,缺乏防卫措施会导致项目失败。
  • 社区缺乏维护基础设施的文化,导致设施因缺乏保养而损坏。
  • 非洲国家总体人类发展指数自 90 年代以来有所提升,否定其不可救药的观点。
  • 性别项目通过改变文化规范,不需要持续可变成本,因而更具粘性。
  • 教育项目需要持续投入教师和资源,资金断裂后难以维持。
  • 投资女性更有效,因为女性更依赖社区且不易迁移。
  • 教育延迟女性结婚年龄,不仅因为学习占用时间,更因为学校提供了安全支持和自立能力。
  • 简单将减少童婚归因于“女孩留在学校”是过于简化,实际是多方面支持系统的结果。

9. 从 Supabase 到 Clerk,再到 Better Auth (From Supabase to Clerk to Better Auth) #

https://blog.val.town/better-auth

这篇文章讲述了 Val Town 从使用 Supabase 和 Clerk 的身份验证服务,逐步转向采用 Better Auth 的过程和原因。作者回顾了 2023 年 Val Town 如何放弃 Supabase,转用 Render 作为数据库,Clerk 作为身份验证服务,但到 2023 年底便发现 Clerk 存在诸多问题,最终在 2026 年初切换到了 Better Auth。

文章指出 Clerk 的核心问题在于它试图替代用户表和会话表,但其 API 存在严重的速率限制(每秒仅允许五次请求),这对社交网站 Val Town 造成了极大困扰。Clerk 默认假设用户只需访问自己的信息,无法很好支持社交网站中频繁访问其他用户数据的需求,导致必须在 Clerk 和 Val Town 数据库之间同步用户信息,增加了系统复杂性。此外,Clerk 成为单点故障源,服务中断时不仅影响登录登出流程,甚至使已登录用户无法正常使用网站,严重影响了网站的稳定性。

尽管如此,作者也承认 Clerk 在提供多种框架 SDK、管理后台和反欺诈措施方面表现不错,适合简单的前端应用,但不适合复杂的社交平台。切换身份验证服务并非易事,团队希望减少频繁更换带来的开发负担。

Better Auth 被选中是因为其代码质量高,支持多框架,且作为开源项目可独立运行,减少了对第三方服务的依赖。虽然仍存在供应商风险,但 Better Auth 不再将会话管理外包,提升了系统的可靠性。作者还提到 AuthKit 是另一选择,但更倾向于 Better Auth 的开源和独立性。Better Auth 的仪表盘和付费插件设计巧妙,支持轻量级用户管理。

总体来看,文章详细分析了身份验证服务在复杂社交网站中的挑战,强调了系统可靠性的重要性,并分享了 Val Town 团队在选择和切换身份验证方案上的经验教训。


HN 热度 295 points | 评论 226 comments | 作者:stevekrouse | 1 day ago #

https://news.ycombinator.com/item?id=48038827

  • 自己维护用户表看似简单,但随着需求增加,如 SSO、OAuth、2FA 等认证方式,复杂度大幅提升,第三方服务能节省大量时间和精力。
  • 许多 B2B 客户尤其是中大型企业要求支持 SSO 和权限管理,单纯邮箱密码认证难以满足需求。
  • 有些人坚持只用邮箱和密码认证,认为这样能保持对用户数据的完全控制,避免依赖第三方,且不愿意花时间学习复杂的认证集成。
  • 第三方认证服务虽然方便,但也可能带来运维负担,比如证书管理、权限映射等问题。
  • 自建认证系统需要投入大量运维和支持资源,可能导致团队变成运维团队。
  • 开源认证方案如 Supabase Auth 和 Keycloak 存在,但自托管难度较大,且需要持续维护。
  • OAuth 等认证方式可以自己实现,不一定非要依赖第三方服务,但集成和维护成本较高。
  • 支持多种认证方式(如 Google、Apple 登录)能降低用户注册门槛,提高转化率,但有些开发者不喜欢依赖大厂的登录按钮。
  • 认证系统不是核心产品,投入过多精力会分散团队注意力,使用第三方服务可以让团队专注于核心业务。
  • 认证集成涉及复杂的标准和细节,第三方服务通常提供更成熟的解决方案和支持。

10. 智能代理需要控制流程,而非更多提示语 (Agents need control flow, not more prompts) #

https://bsuh.bearblog.dev/agents-need-control-flow/

这篇博客文章讨论了智能代理在处理复杂任务时,依赖更多提示语链的局限性。作者认为,可靠的智能代理需要在软件中编码确定性的控制流程,而不是依赖不断复杂化的提示语。

文章指出,提示语链虽然在狭义任务中有用,但它们本质上是非确定性的,难以验证和推理,随着复杂度增加,可靠性会迅速下降。相比之下,软件通过递归组合、模块和函数实现可预测的行为,便于局部推理和扩展。

为了提高智能代理的可靠性,逻辑应从自然语言提示转移到运行时环境,采用明确的状态转换和验证检查,将大型语言模型视为系统的一个组件,而非全部系统。

此外,确定性编排只是解决方案的一部分。由于系统可能出现无声失败,缺乏积极的错误检测,智能代理可能迅速得出错误结论。没有程序化验证时,只有三种选择:人工监督以防错误扩散、事后全面审计,或盲目接受输出结果。


HN 热度 283 points | 评论 154 comments | 作者:bsuh | 7 hours ago #

https://news.ycombinator.com/item?id=48051562

  • 让模型完全管理高层控制流程在处理大量文件时不稳定,容易出错且效率低下,加入确定性控制流程能大幅提升可靠性。
  • 目前的模型还不足以完全替代人类设计和实现复杂流程的能力,更多是提高生产力而非完全自动化。
  • 将任务拆分成更小、更易处理的部分,可以用较低能力的模型实现甚至超过当前最先进模型的效果。
  • 使用代码脚本或简单的自动化工具辅助控制流程,可以快速搭建稳定的工作流程,且成本较低。
  • 依赖单一大模型完成所有任务不现实,分工给多个子代理分别负责不同环节更有效。
  • 目前模型在执行代理任务时的可靠性仍有限,距离真正稳定自动化还有一定时间。
  • 通过不断反馈和开源工具,社区正在探索更好的代理系统设计方案。

Hacker News 精彩评论及翻译 #

Google Cloud fraud defense, the next evolution of … #

https://news.ycombinator.com/item?id=48039980

The requirements for the mobile devices are listed here: https://support.google.com/recaptcha/answer/16609652

So it seems that you will need a modern Android device with Google Play Services installed or a modern iPhone/iPad to be allowed to browse the web in the future.

No mention of device integrity verification yet, but the writing is on the wall.

bramhaag

移动设备的要求列在这里:https://support.google.com/recaptcha/answer/16609652

所以看来,未来你需要一台安装了谷歌服务的现代安卓设备,或者一台现代的iPhone/iPad,才能被允许浏览网页。

目前还未提及设备完整性验证,但趋势已经很明显了。


Vibe coding and agentic engineering are getting cl… #

https://news.ycombinator.com/item?id=48044402

The disconnect for AI is that it is a jagged frontier and it only really shines when one of its jagged frontiers extends counter to one of your valleys.

If you’ve been writing Perl for 30 years, you might not want to learn JavaScript just to make a little fun idea in your head to show your wife. Vibe code that shit man. Who cares? Your wife does not care about LOC or those internal design decisions you made.

If you’re trying to learn something new like an algorithm, protocol, or API write that shit by hand. You learn by doing, and when you know how the thing works and have that mental context, you will always be faster than an AI. Also, when did we stop liking to learn? Why is it a bad thing to know all the ins and outs of a programming language? To write and make all the decisions yourself? That shit is fun. I don’t care if you disagree.

If you’re at work and they really care about getting something out of the door, do whatever you think is best. If you just wanna ship vibed code and review PRs all day, all the power to you. If you wanna write it by hand, and use AI like a scalpel to write up boiler plate, review code, do PR audits, etc… go for it!

A hammer is a really great tool that has thousands of purpose-designed uses. I still prefer my key to get into my car. It’s all tools, you are a person.

A lot of this stuff if coming top-down from people who do not have the experience you do. Wouldn’t a smart employee use their expertise to advise the organization? If you work at a company where that would not be okay, maybe it’s time to start looking for another firm.

u8

人工智能的问题在于它是一个参差不齐的前沿领域,只有当它的某个参差的前沿正好与您的某个短板相反时,它才会真正发挥作用。

如果你写了30年的Perl,你可能不想为了给你老婆展示脑海中的一个小有趣的想法而去学JavaScript。用Vibe写代码吧,谁在乎呢?你老婆才不关心代码行数或者你做出的那些内部设计决策。

如果你想学习新的东西,比如算法、协议或者API,那就亲手写代码。你是通过实践学习的,当你知道某个东西是如何工作的,并且有了那个心理框架时,你总是会比AI快。另外,我们什么时候开始不喜欢学习了?了解一门编程语言的方方面面怎么就成了坏事?自己写代码,自己做所有决策,那真的很有趣。我不在乎你是否同意。

如果你在工作中,公司真的很在意能尽快上线产品,那就做你认为最好的事情。如果你只想写Vibe代码然后整天审查PR,那我支持你。如果你想亲手写代码,并用AI像手术刀一样辅助写样板代码、复查代码、做PR审核,那就去做吧!

锤子是一个非常棒的工具,有千千万万个专门的用途。但我仍然更喜欢用钥匙打开我的车门。这都是工具,而你是人。

很多观点都是上层对没有你那种经验的人发出的。难道一个聪明的员工不应该利用他们的专业知识来为组织提供建议吗?如果你在一家公司,提出建议会被拒绝,那或许是时候考虑换家公司了。


Higher usage limits for Claude and a compute deal … #

https://news.ycombinator.com/item?id=48038416

Anthropic renting out the data center Elon built for Grok is the kind of plot twist you can’t make up.

arian_

Anthropic 出租埃隆为 Grok 建造的数据中心,这种剧情反转真是无法编造。


Appearing productive in the workplace #

https://news.ycombinator.com/item?id=48039225

What is described here closely resembles my experience too.

My company is full of managers who haven’t written code in years. They hired an architect 18 months ago who used AI to architect everything. To the senior devs it was obvious - everything was massively over engineered, yet because he used all the proper terminology he sounded more competent to upper management than the other senior managers who didn’t. When called out, he would result to personal attacks.

After about 6 months, several people left and the ones who stayed went all in on AI. They’ve been building agentic workflows for the past 12 months in an effort to plug the gap from the competent members of staff leaving.

The result, nothing of value has been released in the past 18 months. The business is cutting costs after wasting massive amounts on cloud compute on poorly designed solutions, making up for it by freezing hiring.

proofofcontempt

这里描述的情况和我的经历非常相似。

我公司的管理层大多已经多年没有写过代码了。18个月前他们聘请了一位架构师,这位架构师用 AI 来设计所有架构。对于高级开发人员来说很明显——所有东西都被大幅度过度设计了,但因为他使用了所有正确的术语,听起来比其他用词不当的高级经理更有能力,被上层管理层看得更重。当有人指出问题时,他会采取人身攻击。

大约六个月后,有几个人离职,留下的人开始全面依赖 AI。他们过去12个月一直在构建自主工作流,试图弥补那些离职的有能力员工带来的空缺。

结果是,过去18个月没有发布任何有价值的东西。公司在对设计糟糕的解决方案花费了大量云计算资源后,正在削减成本,通过冻结招聘来弥补。


Knitting bullshit #

https://news.ycombinator.com/item?id=48035955

Increasingly, my reaction to AI-generated content of basically all types is simply a deep, resonant sadness.

The growth of AI feels a little like losing a limb - there is an initial shock of sadness, an initial dose of loss, an initial sense of what has been taken away.

But then for months and years afterwards, the daily occurrence of some other little humdrum experience, and only at the moment of the encounter does one think, “Ah yes, this too is forever changed.”

Like sounding the depths of a dark well, where every day you lower the rope a little further, but every day there is nothing to feel but a pointless swinging in a vast, unquantifiable emptiness.

ipsento606

我对几乎所有类型的AI生成内容的反应,越来越多的是一种深沉而共鸣的悲伤。

AI的发展感觉有点像失去了一条肢体——最初是震惊,是失落,是一种被夺走了什么的感觉。

但接下来几个月甚至几年,每天都会遇到一些平凡琐碎的小事,只有在那一刻你才会想,“啊,这也永远变了。”

就像在测量一口黑暗深井的深度,每天你都把绳子放得更深一些,但每天唯一能感受到的,就是在这无边无际、无法测量的空虚中毫无意义地荡来荡去。


Vibe coding and agentic engineering are getting cl… #

https://news.ycombinator.com/item?id=48037871

Vibe Coding (and LLMs) did not create undisciplined engineering organizations or engineers. They exposed and accelerated them.

Plenty of engineers have loose (or no!) standards and practices over how they write coee. Similarly, plenty of engineering teams have weak and loose standards over how code gets pushed to production. This concept isn’t new, it’s just a lot easier for individuals and teams who have never really adhered to any sort of standards in their SDLC to produce a lot more code and flesh out ideas.

etothet

Vibe 编码(以及大型语言模型)并没有创造出无纪律的工程组织或工程师,而是揭示并加速了这一现象。

许多工程师在编写代码时都存在宽松(甚至没有)标准和规范。同样,许多工程团队在代码推送到生产环境的流程上也有薄弱且宽松的标准。这个概念并不新鲜,只是对于那些从未真正遵守过任何软件开发生命周期标准的个人和团队来说,现在更容易产出大量代码并完善想法。


I switched from Mac to a Lenovo Chromebook #

https://news.ycombinator.com/item?id=48051744

Going from complaining about Apple not having enough polish in the fine details of their UI to suggesting we all switch to Chromebooks is so completely inconsistent that there must be other motivations.

In one post they’re complaining about things like Apple having the search bar in different locations in different apps, and in the next post they’re seriously trying to tell us that a laptop that requires modifying the software and running shell commands copied from the internet so you can run a text editor to change settings and drivers is the solution? They dropped a note about how they haven’t actually tried development on the chromebook at the end but say they assume it would be okay. For someone telling us to switch to Chromebooks, they haven’t even finished doing their own homework

Linking to an SEO spam website called technical.city for performance comparisons is another clue that this choice was driven by something else first and the reasoning was backfilled. The new MediaTek part is fast, but there’s more to laptop performance than a single bar chart from a site citing ancient benchmarks like PassMark.

I can’t read this as anything other than an attempt to make a contrarian choice and then present it as the superior alternative.

Aurornis

从抱怨苹果在界面细节上缺乏打磨,到建议大家都换用Chromebook,这种转变完全前后矛盾,肯定还有其他动机。

一篇帖子里他们抱怨苹果把搜索栏放在不同应用里的位置不统一,下一篇帖子却认真告诉我们,要运行一个需要修改软件、复制网上命令行来运行文本编辑器以更改设置和驱动的笔记本才是解决方案?他们最后还提到自己其实没真正试过在Chromebook上开发,但假设应该没问题。对于一个劝我们转用Chromebook的人来说,连自己的功课都没做完。

文章引用了一个叫technical.city的SEO垃圾网站进行性能对比,这也是这个选择背后有别的动机、然后找理由补充的一个线索。新的MediaTek芯片确实很快,但笔记本性能远不止依靠一个引用过时基准(比如PassMark)的单一柱状图。

我只能把这看作是故意唱反调,然后把这种选择包装成更优方案的尝试。


Agents can now create Cloudflare accounts, buy dom… #

https://news.ycombinator.com/item?id=48032013

That is ironic. Four years ago, cloudflare didn’t let human me have an account / buy domains because I signed up, never used a single service but didn’t respond to a request to verify my drivers license

This account is in violation of Cloudflare’s Terms of Service. Specifically fraud. The suspension is permanent.

(Yes that’s really it. Sincerely. No “but I also abused X”)

jackconsidine

这真是讽刺。四年前,Cloudflare 不让我这个真人开账户或购买域名,因为我注册了,但从未使用过任何服务,却没有回应他们核验我驾照的请求。

该账户违反了 Cloudflare 的服务条款,具体是欺诈行为。账户被永久停用。

(是的,就这样。真的。没有“但我也滥用过X”之类的说法。)


Today I’ve made the difficult decision to reduce t… #

https://news.ycombinator.com/item?id=48032858

Leaders will own much more, with as many as 15+ direct reports. […] Every leader at Coinbase must also be a strong and active individual contributor. Managers should be like player-coaches, getting their hands dirty alongside their teams.

Oof. So not only are they giving their remaining managers more reports, but those managers will be expected to do lots of other, non-management work.

Sure, nothing can go wrong there… Even if they didn’t have non-managerial work to do, 15+ direct reports is just too many. They’re not going to get to spend enough time meeting each report’s needs, not a chance.

I think as layoffs emails go, it’s a pretty good one (as the current top comment points out[0]), but boy, I would not want to be working at a company like what Coinbase is turning into. Non-technical teams shipping code to prod? No thanks. “AI-native pods”? No thanks. I do like the idea of one-person teams; I was at my most productive when I was in that kind of role (though I’m not sure my experience generalizes). I get that companies are still struggling to figure out how to adapt to LLMs, but… damn.

Pretty solid severance package for the folks being laid off, though.

[0] https://news.ycombinator.com/item?id=48021843

kelnos

领导者将负责更多事务,直接汇报人数可能多达15人以上。……Coinbase的每位领导者同时也必须是强有力且积极的个人贡献者。经理们应该像球员兼教练一样,亲自参与团队的具体工作。

哎呀。所以他们不仅让现有的经理们负责更多直接下属,而且这些经理们还得做大量其他非管理工作。

当然,这肯定不会出问题……即使他们没有其他非管理工作,15个以上的直接汇报人也太多了。他们根本没法花足够时间满足每个下属的需求,绝无可能。

我觉得作为裁员通知邮件来说,这封算是挺不错的(正如当前热评所指出的),但天哪,我可不想在Coinbase正在变成的这种公司工作。非技术团队上线代码?不要。所谓“AI本地团队”?不要。我倒挺喜欢单人团队的理念;当我处于那种角色时效率最高(虽然我不确定这种经历是否具有普遍性)。我能理解公司们还在努力适应大型语言模型,但……真是让人无语。

不过,对于被裁掉的人来说,补偿方案还是相当不错的。


The bottleneck was never the code #

https://news.ycombinator.com/item?id=48035454

I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. The inability for the business to define a focused, productive roadmap has always been the problem in software engineering. Constantly jumping to the next shiny thing that yields almost no ROI but never allowing systemic tech debt to be addressed has crippled many company’s I have worked at in the long-term.

jugg1es

我认为有经验的工程师一直都知道,速度真正的问题更多是组织层面而非技术层面。业务无法定义一个专注且高效的路线图,一直是软件工程中的问题。不断追逐下一个光鲜亮丽但几乎没有回报的新事物,却从不允许系统性的技术债务得到解决,这在我曾工作过的许多公司长期来看已经造成了严重的阻碍。


AI slop is killing online communities #

https://news.ycombinator.com/item?id=48053584

I have largely written Reddit off and no longer visit it after an experiment I did where I had an agent karma farm for me and do some covert advertising. As I went through the posts it wrote I realized that as a reader I would have NO idea that these were just written by a computer. Many many people (or other bots) had full on conversations with it and it scared me a bit.

I am not quite there with Hacker News but I do know for a fact that many “users” here are LLMs.

Online communities are definitely dying. I guess I hope that maybe IRL communities have a resurgence in this wake.

carlgreene

我基本上已经放弃了Reddit,而且在做了一个实验后不再访问它。我让一个代理帮我刷业力点数并进行一些隐蔽的广告宣传。当我浏览它写的帖子时,我意识到作为读者,我根本不会知道这些帖子是由电脑写的。很多人(或者其他机器人)和它进行了完整的对话,这让我有点害怕。

我对Hacker News还没有完全失望,但我确切知道这里有许多“用户”其实是大型语言模型。

网络社区确实在走向衰落。我希望现实生活中的社区能在这之后重新兴起。


Appearing productive in the workplace #

https://news.ycombinator.com/item?id=48047945

The first is when novices in a field are able to produce work that resembles what their seniors produce […]. > The second is when people generate artifacts in disciplines they were never trained in.

There is a third shape. Experts who have become so reliant / accustomed to AI that it dilutes their previously sharp judgment and, importantly, taste. I am seeing more and more work produced by experts which seems strangely out of character. A needlessly verbose text written by someone who was previously allergic to verbosity. An over-engineered solution (complete with CLI, storage backend, documentation, unit tests) for a trivial problem which that person would’ve solved by an elegant bash one-liner only 3 years ago. The work itself is always completely immune to any rational criticism, as it checks all the boxes: extensive documentation, scalable, high test coverage, perfect code style, and for texts perfect grammar, non-offensive, seemingly objective. But, for lack of a better word, it simply lacks taste.

lqet

第一种情况是领域内的新手能够产出与资深人士相似的作品……
第二种情况是人们在自己从未受过培训的学科中生成作品。

还有第三种情况。那些专家变得过度依赖或习惯于使用人工智能,以至于削弱了他们原本敏锐的判断力,尤其是对品味的影响。我看到越来越多专家创作的作品显得奇怪,完全不像他们以前的风格。比如曾经抗拒冗长文字的人写出无谓啰嗦的文本;或者某人三年前还能用优雅的bash一行命令解决的问题,现在却用过度设计的解决方案(包括命令行界面、存储后端、文档、单元测试)来处理。作品本身总是完全经得起理性批评,因为它满足了所有标准:详尽的文档、可扩展性、高测试覆盖率、完美的代码风格,对文本来说语法完美、无冒犯性且看似客观。但是,缺乏更好的词语来形容,它就是缺乏品味。


The bottleneck was never the code #

https://news.ycombinator.com/item?id=48035574

This is a false dichotomy. Software development has always been about keeping people in agreement, from the customer to the coder, and all the people in between (the fewer the better).

Meetings that increases sync between customer and coder are few and precious.

In large organisations ceremonial meetings proliferate for the wrong reasons. People like to insert themselves in the process between customer and coder to appear relevant.

I personally am fond of meetings with customers, end-users, UX designers, and actual stakeholders.

I loathe meetings with corporate busybodies who consume bandwidth for corporate clout.

No, I don’t need another middle manager to interface themselves between me and my users.

ftmootnomoat

这是一种错误的二分法。软件开发一直都是关于让人们达成一致,从客户到程序员,以及所有中间的人(越少越好)。

能增加客户和程序员之间同步的会议是少而珍贵的。

在大型组织中,形式主义的会议因错误的原因大量增多。人们喜欢把自己插入客户和程序员之间的过程,以显得自己重要。

我个人喜欢与客户、最终用户、用户体验设计师和实际利益相关者开会。

我讨厌那些为了企业影响力而消耗资源的公司多管闲事者的会议。

不,我不需要另一个中层管理者来插入我和用户之间。


Zuckerberg ‘Personally Authorized and Encouraged’ … #

https://news.ycombinator.com/item?id=48030682

What’s frustrating is all those kids who got criminal charges for running MP3 sites back in the day [1], and this guy rips off every piece of media in existence and will walk away literally because he’s too rich to be charged.

[1] See, e.g. https://en.wikipedia.org/wiki/Oink%27s_Pink_Palace#Legal_proceedings

qingcharles

令人沮丧的是,曾几何时那些因为运营MP3网站而被起诉的孩子们[1],而这个家伙却盗取了所有存在的媒体内容,却因他太有钱而根本不用承担任何责任。

[1] 参见,例如:https://en.wikipedia.org/wiki/Oink%27s_Pink_Palace#Legal_proceedings


Programming Still Sucks #

https://news.ycombinator.com/item?id=48044825

AI didn’t take our jobs. Greed did. Same greed that moved factories to Bangladesh and keeps slaves in cobalt mines in the Congo, wearing a new mask. Tell the nephew to do something else. Anything. It won’t save him either, but at least he won’t have to pretend the thing destroying his life is a robot.

This hit me hard. This article is art. I think I need to sleep on this and read it again in the morning.

fooqux

人工智能并没有夺走我们的工作。贪婪才是。正是这种贪婪把工厂迁到了孟加拉,还让刚果的钴矿养着奴工,不过换了副新面孔。告诉你的侄子去做别的事情。什么都行。这也救不了他,但至少他不用假装那个毁了他生活的东西是机器人。

这句话让我很受触动。这篇文章简直就是艺术。我觉得我需要好好睡一觉,明天早上再读一遍。


Valve releases Steam Controller CAD files under Cr… #

https://news.ycombinator.com/item?id=48042122

I don’t disagree with most of your statement, but Valve has and continues to make lots of money from loot boxes in both CS and TF2. Just want to point out that they do do stuff like that too.

xingped

我并不反对你大部分的说法,但Valve确实从CS和TF2的战利品箱中赚了很多钱,而且现在仍在赚。只是想指出他们也确实做过类似的事情。


Valve releases Steam Controller CAD files under Cr… #

https://news.ycombinator.com/item?id=48038509

I’m not sure that’s Valve’s fault.

Windows is designed for gamepads to emulate an Xbox controller. All those Steam Deck competitors are implemented as an Xbox controller with a partial keyboard grafted on. That’s why you need Legion Space or Armoury Crate to make them usable - they tell the controller firmware what keybindings to send for those rear paddles.

InputPlumber serves this purpose on Linux. Without it, you just get ABXY, start, select, nav, and shoulder buttons - the same layout that’s been on the Xbox forever, because games don’t understand the random partial keyboard that shares an internal USB hub with the Xbox pad clone. Thankfully on Linux, you’re not stuck with one durable keybinding per paddle - once InputPlumber unifies that USB hub back into a controller, you can map all its buttons per-game with Steam Input. This controller brings that same convenience to Windows too.

It’s not that Valve is making a proprietary controller - it’s that the Windows gaming ecosystem assumes a proprietary controller, and Valve doesn’t conform to that assumption. Instead, they provide a fully featured controller and let you configure it per-game in Steam. Considering Steam is the launcher most people use for most games, that’s a totally reasonable tack.

bsimpson

我不确定这是不是Valve的错。

Windows设计游戏手柄时是为了模拟Xbox手柄。所有那些Steam Deck的竞争产品实际上都是作为带有部分键盘的Xbox手柄来实现的。这就是为什么你需要Legion Space或Armoury Crate才能使它们可用——它们告诉手柄固件如何为背面的按键发送键位绑定。

在Linux上,InputPlumber就是用来完成这个目的的。没有它,你只能获得ABXY、开始、选择、导航和肩部按钮——这就是Xbox一直以来的布局,因为游戏无法识别那个共享内部USB集线器的随机部分键盘和Xbox手柄克隆。幸运的是,在Linux上,你不会被限制为每个背键一个固定的按键绑定——一旦InputPlumber将那个USB集线器重新统一为一个手柄,你就可以用Steam Input为每个游戏单独映射它的所有按钮。这个手柄也为Windows带来了同样的便利。

问题不在于Valve制造了一个专有手柄,而是Windows的游戏生态系统默认假设是专有手柄,Valve并没有遵从这个假设。相反,他们提供了一个功能齐全的手柄,并允许你在Steam中为每个游戏单独配置。考虑到Steam是大多数人玩大多数游戏时使用的启动器,这完全是一种合理的做法。