2026-04-30 Hacker News Top Stories #

因 GitHub 频繁宕机与体验下滑，Hashimoto 决定将 Ghostty 迁出仅留只读镜像、盼其改进后再说，HN 上对“留守改良”还是“用脚投票”意见分化。

Zed 1.0 作为 Rust/GPUI 的高性能 AI 原生编辑器发布，但其广泛数据使用与“衍生作品”等许可条款引发源代码隐私与单方变更担忧。

讨论普遍主张以网站 RTA 声明配合设备端家长控制替代强制年龄验证，认为大厂推动实名多为监控与数据收集，且内容分级存在灰色地带。

文章回顾从 SourceForge 到 GitHub 的变迁，指出 GitHub 以社交化工具极大降摩擦却加剧集中与微依赖风险，未来或需联邦式去中心化协作。

Canonical 揭示 uutils 中 44 个漏洞表明 Rust 难以自动防住 TOCTOU 等系统级陷阱，需以基于文件描述符、原子设权与 inode 校验等模式化做法规避。

Cursor Camp 以鼠标移动为核心带来轻量多人互动与解谜收集的怀旧体验，机制巧妙且社交性强，但玩家建议增强地形复杂度与身份个性化。

荷兰政府基于自托管 Forgejo 软启动 code.overheid.nl，强调数字主权与内协作、减少对美企依赖，并引发对开源治理与公开数据影响的讨论。

Tangled 提议以 Git 传代码、AT 协议联邦事件实现跨服协作与社交，HN 指出 Atproto 兼顾用户主权与聚合但仍受 API/反爬限制挑战。

文章解析 ChatGPT 广告在 SSE 注入与四令牌归因闭环及商家端 SDK 的实现，并警示 LLM 将成隐蔽影响与投放工具、效果追踪与反欺诈仍很艰难。

Mistral 推出可本地自托管的 Medium 3.5 及远程代理/工作流功能，在体积与部署门槛上有优势但速度受带宽限制、综合体验仍难全面超越 Sonnet。

1. Ghostty 正在离开 GitHub (Ghostty is leaving GitHub) #

https://mitchellh.com/writing/ghostty-leaving-github

Mitchell Hashimoto 在这篇文章中表达了他对 GitHub 的深厚感情以及近期决定将其项目 Ghostty 迁离 GitHub 的原因。作为 GitHub 用户 1299 号，他自 2008 年 2 月起每天多次使用 GitHub，持续了超过 18 年，GitHub 在他生活中占据了重要位置，成为他工作、爱好和激情的交汇点。

他回忆了自己如何在 GitHub 上度过了许多重要时刻，包括大学深夜和蜜月清晨，GitHub 一直是他快乐和专注的来源。他甚至因为希望被 GitHub 录用而开发了第一个成功的开源项目 Vagrant。尽管他一直深爱 GitHub，但最近他对 GitHub 的服务质量感到失望，尤其是频繁的宕机严重影响了他的工作效率。

他坦言自己对 GitHub 的批评和愤怒是出于对这份感情的失望，GitHub 的频繁故障让他无法正常进行代码审查和软件发布，严重阻碍了他的工作。经过长时间的思考和准备，他决定将 Ghostty 项目迁出 GitHub，尽管个人其他项目暂时仍留在 GitHub。他强调，迁移过程将尽量渐进，GitHub 上的只读镜像仍会保留。

最后，他表示希望未来 GitHub 能有实质性的改进，自己也期待有一天能够回归，但目前必须离开以保证项目的正常发展。文章还提到，迁移计划已酝酿数月，最近的 GitHub 大规模宕机事件与此决定时间上巧合，但并非直接原因。

HN 热度 3324 points | 评论 987 comments | 作者：WadeGrimridge | 1 day ago #

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

GitHub 对很多开发者来说不仅是工具，更有情感寄托，离开让人感到难过和失落。
有人认为只有关心并留下的人才能推动 GitHub 变得更好，离开是逃避问题。
也有人认为用户继续使用并不能真正改变 GitHub 的现状，平台体验在持续恶化。
有用户反映长期反馈的问题未被解决，导致对 GitHub 改善的信心降低。
离开 GitHub 可能是用户表达不满和促使改变的有效方式。
组织和个人不同，企业作为无情的法人实体不值得盲目忠诚，用户应理性选择。
GitHub 作为微软旗下产品，更多受商业指标驱动，怀旧情感不应成为继续使用的理由。
虽然有替代平台如 Forgejo、Codeberg，但 GitHub 体量巨大，短期内难以被广泛替代。
有人在 GitHub 内部努力改善平台，希望未来能重新激发用户的热情。
一些替代平台在速度和简洁性上表现更好，值得关注和借鉴。

2. Zed 1.0 (Zed 1.0) #

https://zed.dev/blog/zed-1-0

Zed 1.0 是一款全新设计的代码编辑器，旨在突破传统基于网页技术的编辑器限制，采用类似视频游戏的架构，利用 GPU 着色器提升性能，核心框架 GPUI 由 Rust 语言从零开发。团队经过多年努力，打造了一个高性能且功能丰富的编辑器，现已有数十万开发者依赖 Zed 进行软件开发。

Zed 1.0 支持多种编程语言和生态系统，集成了 Git、SSH 远程连接、调试器等功能，覆盖 Mac、Windows 和 Linux 平台，代码量超过一百万行。作为一款 AI 原生编辑器，Zed 支持多代理并行工作，提供精准的代码预测和编辑建议，内置 Agent Client Protocol，兼容 Claude Agent、Codex、OpenCode 和 Cursor 等多种 AI 代理。

此外，Zed 推出了面向企业的版本，支持集中计费、基于角色的访问控制和团队管理，方便公司统一部署和管理。1.0 版本标志着 Zed 进入成熟阶段，用户体验和功能均大幅提升，欢迎之前试用过的用户重新体验。

未来，Zed 将继续专注于打造高性能和协作性强的编码环境，尤其强调人与 AI 代理的协同工作。团队正在开发基于 CRDT 的 DeltaDB 同步引擎，实现多人和多代理对代码库的实时一致性编辑和交流，推动代码协作进入新阶段。Zed 的自主技术栈使其能够实现这些创新功能，而非依赖第三方浏览器引擎。

Zed 团队将持续每周发布新版本，不断完善产品，保持创新和进步。用户可以立即下载试用，开发者也欢迎加入团队，共同推动软件开发的未来。

HN 热度 1445 points | 评论 456 comments | 作者：salkahfi | 9 hours ago #

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

许可协议中赋予 Zed 对用户输入数据的广泛使用权，包括复制、存储、修改和创建衍生作品，令部分用户担忧源代码隐私和所有权问题。
Zed 声明这些权利仅用于履行服务义务、生成遥测数据和遵守法律，但部分用户认为条款过于模糊且容易被滥用。
有用户指出，尽管可以关闭部分遥测功能，但 Zed 仍可能在服务器端收集和处理数据，尤其是在启用 AI 代码补全功能时。
许可条款中“创建衍生作品”的权利被质疑，用户认为这超出了合理使用范围，可能用于训练 AI 模型。
有观点认为，条款允许 Zed 单方面修改协议，用户无法有效拒绝，属于不平等合同。
也有用户认为，收集遥测数据用于改进产品和支持服务是合理的，但对数据使用范围应有更明确限制。
部分用户担忧公司出售或变更时，数据使用权可能被转移，增加风险。
有用户提到，类似条款在其他软件中也常见，但依然应谨慎对待，避免无意中放弃代码所有权。
还有用户质疑为何 IDE 需要收集用户正在编写的代码内容作为遥测数据，认为这侵犯隐私。
总体来看，用户对 Zed 数据使用条款持谨慎甚至反对态度，担心源代码安全和隐私保护不足。

3. 在线年龄验证是必须坚守的阵地 (Online age verification is the hill to die on) #

https://x.com/GlennMeder/status/2049088498163216560

Glenn Meder 在社交平台 X（前身为 Twitter）上的推文。推文强调了在线年龄验证的重要性，称其是数字控制体系中最关键的一环。作者认为，在线年龄验证是无法回避的斗争，是必须参与的政策问题。如果在这场斗争中失败，将会失去对整个数字控制网络的掌控。推文表达了对这一议题的高度重视，呼吁关注和行动。

HN 热度 693 points | 评论 435 comments | 作者：Cider9986 | 8 hours ago #

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

通过服务器设置 RTA 头部，客户端根据该头部启用家长控制，是保护儿童的有效方法，且不会涉及追踪或数据泄露。
大型科技公司未采用此方案，主要因为缺乏财务动力，且他们更倾向于推动身份验证以收集用户信息。
年龄验证的推动更多是为了实现大规模监控和责任转移，而非真正保护儿童。
设备端家长控制结合网站声明内容评级，能避免中心化控制架构，赋能用户自主管理内容访问。
反对年龄验证的人士认为其背后是政府与企业利益勾结，利用法规加强对用户的监控和数据收集。
设立两个头部，一个标明成人内容，一个明确无成人内容，有助于设备更精准地过滤内容。
成人内容的定义因家庭和文化差异而异，家长应根据自身价值观和法律规定决定孩子可接触的内容。
内容过滤存在灰色地带，如健康教育相关内容难以简单归类为成人或非成人内容。
大公司支持监管以构筑市场壁垒，利用法规限制竞争对手，符合其商业利益。

4. GitHub 之前 (Before GitHub) #

https://lucumr.pocoo.org/2026/4/28/before-github/

这篇文章是 Armin Ronacher 对 GitHub 及其在开源社区中角色的深刻反思。作者回顾了自己在 GitHub 之前的开源经历，提到最初使用 SourceForge、自建 Trac 和 Subversion 服务器，后来迁移到 Bitbucket，最终全部转移到 GitHub。GitHub 不仅是代码托管平台，更是开源社区的社交基础设施，促成了许多专业和个人关系的建立。

文章指出，GitHub 的兴起带来了开源项目数量的爆炸式增长，尤其是结合 npm 等包管理工具，使得发布和使用代码变得几乎没有摩擦，极大地促进了开源的包容性和活跃度。但这也带来了“微依赖”问题，即大量小型依赖包的涌现，增加了管理和信任的复杂度。

作者回忆了 GitHub 之前的开源世界，那时项目较少且较大，依赖关系更为谨慎和明确，社区成员之间有较强的信任和声誉体系。那时，维护者通常需要自己管理基础设施，承担系统管理员的角色。分布式版本控制系统如 Git 和 Mercurial 本应减少对中心化服务的依赖，但最终 GitHub 成为了集中的代码托管中心，这是一种讽刺。

GitHub 的贡献不仅在于简化了项目创建和贡献流程，还提供了丰富的工具和功能，如 issue 追踪、pull request、发布页面、维基、组织页面、API 和持续集成等，推动了开源的透明和协作文化。更重要的是，GitHub 作为一个大型的代码库和档案馆，使得即使是废弃项目也能被发现和访问，避免了早期个人服务器关闭导致代码丢失的问题。

最后，作者强调了 GitHub 和 npm 生态系统带来的依赖爆炸问题，指出在过去，依赖选择更依赖项目的声誉和长期维护，且常通过将依赖代码直接纳入项目中来避免服务中断。而如今依赖关系复杂且庞大，开发者需要更多的工具和机制来管理这种复杂性和责任归属。GitHub 在一定程度上缓解了这些问题，但挑战依然存在。

HN 热度 648 points | 评论 216 comments | 作者：mlex | 1 day ago #

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

GitHub 让用户可以快速创建以个人为中心的仓库，降低了创建项目的心理负担，避免了传统平台繁琐的项目命名和配置流程。
GitHub 逐步引入了 issue 跟踪、pull request、发布页面、wiki、组织页面、API 和 webhook 等功能，极大丰富了项目管理工具。
GitHub 采用了基于路径的 URL 设计（如 github.com/user/repo），而非传统的查询参数，这种设计当时非常新颖且易于记忆和分享。
这种 URL 设计提升了用户体验，避免了复杂的查询字符串和会话参数，成为业界的黄金标准，尽管后来很多公司并未完全效仿。
GitHub 最初没有组织账户，用户通过创建个人账户来模拟组织，组织功能后来才推出且直到 2020 年才免费。
讨论中有人指出，实验性项目通常属于个人账户，只有当维护者增多时才会转为组织账户，这种模式并非自私或以自我为中心。
有观点认为 GitHub 的社交属性对开源软件的发展非常重要，软件的信任很大程度上建立在开发者个人及其社交关系上。
有人提出未来可能通过联邦宇宙（Fediverse）等去中心化技术实现类似 GitHub 的功能，尤其是分布式的 issue 跟踪和 CI/CD。
也有观点指出，Git 本身具备分布式协作的基础，未来可能出现更像基因水平转移的协作模式，项目间借用和共享代码更加自由。
有评论提到，关于浏览器后退按钮的行为和路径参数设计无关，且相关讨论仍在持续。

5. Rust 无法捕捉的漏洞 (Bugs Rust won’t catch) #

https://corrode.dev/blog/bugs-rust-wont-catch/

本文分析了 Canonical 在 2026 年 4 月披露的 uutils 项目中发现的 44 个安全漏洞。uutils 是 Rust 语言重写的 GNU coreutils 工具集，尽管由经验丰富的开发者编写，这些漏洞未被 Rust 的借用检查器、clippy 或 cargo audit 捕获，反映了 Rust 在系统级安全上的局限性。

文章重点讨论了几个典型漏洞及其根源：

路径跨系统调用的不安全使用（TOCTOU 漏洞）：在进行两次系统调用操作同一路径时，攻击者可通过符号链接替换路径，导致权限提升或文件被恶意覆盖。解决方案是避免依赖路径字符串，改为使用文件描述符操作，并使用 OpenOptions::create_new 确保新建文件的安全。
权限设置的时间窗口问题：先创建目录再修改权限会导致权限短暂暴露，攻击者可利用该窗口。建议在创建时直接设置正确权限，避免后续修改。
路径字符串比较不等同于文件系统身份验证：简单字符串比较无法防止符号链接绕过，应使用 fs::canonicalize 解析路径后再比较，确保路径的真实身份。
Unix 系统边界上的字符串与字节处理：Rust 默认使用 UTF-8 字符串，但 Unix 路径和工具处理的是原始字节，错误的转换会导致数据损坏。建议使用 OsStr、OsString 及字节切片等类型处理原始数据，避免不必要的编码转换。

文章还提到，Rust 程序中的 panic!等异常处理可能导致拒绝服务，应谨慎处理。整体来看，这些漏洞揭示了 Rust 在系统编程中虽然安全性较高，但仍需开发者深入理解操作系统特性和正确使用 API，才能避免安全风险。

HN 热度 623 points | 评论 339 comments | 作者：lwhsiao | 22 hours ago #

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

Rust 的 std::fs 容易出现 TOCTOU 竞态条件，期望标准库能提供类似 openat 的接口以避免此类问题。
使用 fstat 比较 st_dev 和 st_ino 更安全且性能更好，避免了路径解析带来的性能损耗。
GNU Coreutils 致力于避免任意限制，保证工具在极端情况下依然稳定高效。
Rust 重写虽然减少了内存安全漏洞，但并非完全没有安全问题。
Rust 的 std::fs 设计为最低通用标准，未来可以通过 uutils 设计更安全的替代接口。
Unix 和 Linux 通过将改进放入内核实现了性能和功能的提升，标准化带来了兼容性问题。
关注性能、竞态条件和 inode 是因为文件系统和存储设备的物理特性及操作系统设计的历史原因。
Coreutils 不仅用于交互式操作，还广泛用于脚本，边缘情况的性能问题会影响大量用户。
过度调用 stat 导致的性能问题在网络文件系统（如 NFS）上尤为明显，影响用户体验。
NFS 的数据模型存在缺陷，导致性能和可靠性问题，Linux 用户逐渐转向其他远程文件系统方案。
Samba 在 Linux 上比 NFS 更易配置和使用，且更稳定。
远程文件系统普遍存在性能和一致性问题，无法完全像本地文件系统一样使用。
延迟和吞吐量通常是相互关联的，除非有足够的缓冲空间，否则难以单独优化其中之一。

6. 光标营 (Cursor Camp) #

https://neal.fun/cursor-camp/

该网页欢迎用户来到“Cursor Camp”，并邀请用户享受在此的体验。页面主体简洁，主要传达了欢迎信息，暗示这是一个与“Cursor Camp”相关的平台或活动，可能提供学习、交流或体验的机会。页面底部有一个“Enter”按钮，提示用户点击进入下一步，进一步探索或参与该平台的内容和服务。整体页面设计简洁明了，重点突出欢迎和引导用户进入。

HN 热度 528 points | 评论 94 comments | 作者：bpierre | 8 hours ago #

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

鼠标移动作为控制方式非常巧妙，尤其是失去鼠标控制时的设计（如顺流漂流、滑梯）和“传送”机制令人印象深刻，建议增加更复杂的地形和迷宫元素。
游戏中的钢琴彩蛋（如“rick roll”）增加了趣味性，吸引了很多玩家互动。
有人调侃该游戏导致员工生产力下降，甚至提到类似“Dragon Quest”游戏曾引发的社会现象。
游戏被部分公司网络屏蔽，体现了职场对娱乐的限制。
游戏中的徽章系统丰富，玩家需要收集多个徽章才能完成挑战，且存在隐藏的第十个徽章。
树屋里的神秘书籍引发玩家好奇，可能暗示游戏中的隐藏内容。
许多玩家沉浸于探索，评论区相对安静，说明游戏吸引力强。
游戏带来怀旧感，许多玩家联想到“Club Penguin”等经典网络游戏。
游戏促进了全球玩家之间的互动和人际连接，如一起玩沙滩排球、踢足球等。
游戏细节丰富，如瀑布跌落、光线效果等，提升了整体体验。
鼠标指针作为玩家标识感觉较为冷漠，建议增加可选的小头像以增强社交感。
右键点击可以选择临时表情，主建筑内有可戴的帽子等装饰道具，增加个性化元素。

7. 政府开源代码平台软启动 (Soft launch of open-source code platform for government) #

https://www.nldigitalgovernment.nl/news/soft-launch-for-government-open-source-code-platform/

荷兰政府推出了名为 code.overheid.nl 的开源代码平台，目前处于试运行阶段。该平台是政府范围内发布和开发开源软件的统一平台，完全自主托管，支持数字主权。平台采用了 Forgejo 这一开源且欧洲本土的 GitHub 和 GitLab 替代品，但目前并非所有政府机构都能使用。

该平台由内政与王国关系部（BZK）下属的开源项目办公室发起，联合 DAWO（SSC-ICT）、Opensourcewerken 和 developer.overheid.nl 共同开发。开发者被邀请参与贡献，目标是将其发展成为政府部门共享的 Git 代码平台。

更多信息和参与方式可通过发送邮件至 codeplatform@rijksoverheid.nl 获取，相关博客文章《We gaan samen code.overheid.nl bouwen》也提供了详细介绍。用户可以访问 code.overheid.nl 了解平台详情。网页还提供了反馈渠道和相关政府数字化服务的链接。

HN 热度 516 points | 评论 117 comments | 作者：e12e | 15 hours ago #

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

荷兰政府迁移开源代码平台，选择 Forgejo 而非 GitHub，体现减少对美国服务依赖的趋势。
荷兰在开源和数字独立方面表现活跃，政府和企业积极推动开源项目。
公开投票数据有助于提高代表问责，但也可能加剧党派投票和游说影响，存在民主风险。
游说问题是民主的根本挑战，公开数据本身并非问题所在。
荷兰政府内部工具很多是基于开源思路开发，未来有望更多对外开放。
现有部分开源项目和 API 存在技术和维护上的问题，社区希望改进架构和技术栈。
开源贡献者通过公司外包模式存在协调和激励不匹配的问题。
荷兰各地市政府多依赖微软云服务，公共图书馆等公共设施仍以 Windows 和微软办公软件为主。
欧洲其他国家如挪威、瑞典也在积极推动开源和开放数据，整体欧洲开源生态活跃。
开源项目的推动多由员工驱动，避免了繁琐的行政预算审批流程。

8. 我们需要一个锻造场联邦 (We need a federation of forges) #

https://blog.tangled.org/federation/

这篇文章介绍了一个名为 Tangled 的新项目，旨在构建一个去中心化的代码托管和协作平台。作者指出，虽然 Git 本身是去中心化的，但目前大多数开源项目仍依赖单一的集中式平台如 GitHub，这种依赖存在风险。Tangled 希望通过联邦化的方式解决这一问题，实现跨服务器的代码协作。

文章回顾了代码协作的发展历程：最初是通过 git 传输代码，邮件进行沟通；后来出现了 GitHub，将代码传输和沟通整合到一个网站上；接着有 ForgeFed 项目尝试结合 git 和 ActivityPub 协议；而 Tangled 则采用 git 传输代码，结合 AT 协议进行事件的认证传输和沟通。

Tangled 允许用户在不同服务器（称为“knots”）之间协作，可以跨服务器 fork 代码，甚至在自己服务器推送代码后，在另一服务器发起 pull-request。它支持代码相关事件的认证传输，如问题、拉取请求，还包含社交功能，如事件时间线、关注、点赞和即将推出的背书功能。Tangled 通过 AT 协议分享协作者邀请和 SSH 公钥，其他操作依然使用传统的 git。

总体来看，Tangled 旨在打破 GitHub 等单一平台的垄断，让开源代码协作既去中心化又保持社交和趣味性。

HN 热度 507 points | 评论 319 comments | 作者：icy | 10 hours ago #

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

Mastodon 面临的小实例因政治、垃圾信息等原因断联问题，可能在 Atproto 中得到缓解，因为 Atproto 采用类似 RSS 的结构，没有传统意义上的“实例”概念。
Atproto 允许用户自行托管数据（PDS），并通过应用聚合所有托管的数据，实现数据的广泛聚合和验证，避免了实例之间的复杂冲突。
Atproto 是推送机制，适合实时社交媒体需求，而传统的 RSS/Atom 是拉取机制，更适合静态内容更新，两者设计目标不同。
实时推送虽然带来快速信息传播的优势，但也被认为加剧了信息过载和社交媒体的负面影响。
Atproto 的设计保证了数据的用户主权和身份认证，用户可以自由更换托管服务而不丢失数据控制权。
静态网站托管的需求与社交网络的需求不同，Atproto 更侧重于动态社交数据的管理，静态网站需求可能不适合作为社交网络协议的核心目标。
网络已经具备了数据开放聚合的基础，但 Atproto 作为专门为此设计的协议，能更好地支持生态系统的统一和发展。
由于数据签名和身份认证机制，Atproto 允许数据在不同托管间安全迁移，增强了用户数据的控制权和安全性。
有观点认为，虽然 Atproto 复杂度较高，但这是实现广泛数据认证和聚合的必要代价。
也有人指出，API 限制和反爬虫措施可能阻碍数据的自由聚合，影响开放生态的实现。

9. ChatGPT 如何投放广告 (How ChatGPT serves ads) #

https://www.buchodi.com/how-chatgpt-serves-ads-heres-the-full-attribution-loop/

本文详细解析了 OpenAI 在 ChatGPT 中投放广告的完整归因流程。OpenAI 的广告平台分为两部分：ChatGPT 端通过后端在对话的 SSE 流中注入结构化的 single_advertiser_ad_unit 广告单元；商家端则通过名为 OAIQ 的跟踪 SDK 在用户浏览器中运行，报告商品浏览数据。两者通过四个 Fernet 加密的点击令牌相互关联，确保广告点击的安全和完整性。

广告是如何进入对话的：当用户发送消息时，后端会在 chatgpt.com 的 SSE 响应流中发送广告单元事件，广告信息包括广告商品牌、广告内容、图片及点击链接等。广告链接通常在 ChatGPT 内置浏览器中打开，方便 OpenAI 监控点击后的行为。每个广告包含四个加密令牌，用于防止欺诈和追踪归因。

广告的选择具有上下文相关性，示例中同一账户在不同话题的六次对话中分别收到不同品牌的广告，如北京旅游相关话题出现了格鲁布哈布（Grubhub）和 GetYourGuide 的广告，NBA 季后赛话题则出现了 Gametime 广告，显示广告投放与对话主题紧密关联。

四个令牌的作用分别是：ads_spam_integrity_payload 用于服务器端防止伪造点击；oppref 作为点击 URL 中的转发归因令牌，存储在浏览器 cookie 中；olref 用于服务器端的展示侧或外链日志；ad_data_token 包含额外的加密信息，供服务器端点击时验证。

点击广告后，浏览器访问商家页面，页面加载 OAIQ SDK，该 SDK 读取 URL 中的 oppref 令牌，写入 cookie 并发送浏览事件数据回 OpenAI 服务器，完成广告归因闭环。文中还提供了阻断 ChatGPT 广告事件的相关域名和 cookie 名称，方便用户进行过滤和监控。

HN 热度 487 points | 评论 342 comments | 作者：lmbbuchodi | 1 day ago #

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

大型语言模型（LLM）将成为低成本、高影响力的宣传工具，能够以隐蔽或操控性的方式影响大众舆论和叙事框架。
通过在模型上叠加特定权重覆盖层，可以实现针对个人的动态定制，成为广告和影响力投放的关键技术。
传统在线广告存在大量欺诈行为，AI 公司可能会利用模型内嵌广告和复杂影响手段获利，同时难以被准确追踪和归因。
通过非串通的广告服务和测量服务，可以设计出较为严密的广告效果追踪机制，但实际操作仍面临挑战。
广告主关注的是投资回报率（ROI），如果广告效果不好，预算会转向其他渠道或竞争对手。
LoRA（低秩适配）技术被认为是实现模型个性化和记忆的方案，但存在性能下降和安全风险，微调模型可能导致行为不可预测。
在宣传竞争中，实际成本由竞争对手的投入决定，更多参与者可能导致整体宣传成本上升。
现有模型倾向支持主流和传统观点，部分原因是训练数据受媒体控制，直接操控模型行为可能风险更大且降低公众信任。
由于模型权重复杂且难以解释，评估模型偏见存在很大困难，黑盒测试也难以客观判定。
各国政府和机构早已利用类似技术进行舆论和信息控制，LLM 只是更先进的工具。

10. Mistral Medium 3.5 (Mistral Medium 3.5) #

https://mistral.ai/news/vibe-remote-agents-mistral-medium-3-5

该网页介绍了 Mistral 最新发布的旗舰模型 Mistral Medium 3.5 及其相关产品和功能。Mistral Medium 3.5 是一款融合了指令执行、推理和编码能力的 1280 亿参数密集模型，支持 256k 的上下文窗口，能够处理复杂的多步骤任务。该模型性能优异，支持自托管，且推理强度可按需调整，适用于快速聊天回复或复杂任务处理。模型还配备了从零开始训练的视觉编码器，支持多种图像尺寸和比例。

网页重点介绍了 Mistral Vibe 远程编码代理功能，允许用户将编码任务移至云端异步运行，支持通过 CLI 或 Le Chat 启动和管理任务，任务可并行执行且不中断用户操作。Vibe 集成了 GitHub、Jira、Sentry、Slack 等工具，支持自动生成代码变更并提交 PR，极大提升开发效率，适合模块重构、测试生成、依赖升级和故障排查等高频任务。

此外，网页还介绍了 Le Chat 中的新“Work 模式”，这是一个基于 Mistral Medium 3.5 的智能代理，能够跨工具协作，处理邮件、日历、消息等多源信息，支持复杂的研究、综合和多步骤项目。该模式默认开启多种连接器，能访问丰富上下文，所有操作均透明可见，并在执行敏感任务前请求用户确认。

Mistral Medium 3.5 现已在 Mistral Vibe 和 Le Chat 的 Pro、Team 及 Enterprise 计划中提供，API 定价为每百万输入令牌 1.5 美元、输出令牌 7.5 美元。模型权重已开源，托管于 Hugging Face，且支持在 NVIDIA GPU 加速平台和容器化微服务中部署。

网页最后提到 Mistral 正在招聘，欢迎有志于推动智能代理系统发展的研究、工程和产品人才加入。

HN 热度 408 points | 评论 191 comments | 作者：meetpateltech | 9 hours ago #

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

Mistral Medium 3.5 模型虽然没有完全超越其他大模型，但在体积和资源需求上更具优势，能够在 70GB 显存的设备上运行，接近消费者级别硬件的可用范围。
运行模型和快速运行模型是两个不同的门槛，虽然可以在 128GB 内存的 Mac Studio 上运行，但响应速度和云端硬件相比仍有差距，尤其是交互体验方面。
多数开源模型发布时都声称能匹配或超越 Sonnet，但实际使用中很少达到预期效果，Sonnet 依然在性能和成本上表现优异。
在实际应用中，Sonnet 模型在处理复杂任务如 DevOps 日志查询时表现较好，其他模型如 GLM、Kimi 等虽接近但仍存在误判或效率问题。
模型运行速度受限于硬件内存带宽，70GB 模型在 256GB/s 带宽的设备上理论最大速度约为 3.65 tokens/s，远低于一些更小更快的模型。
近期模型支持多 token 预测技术，可以在单步解码中预测多个未来 token，从而提升解码速度，但该技术仍处于发展初期。
量化技术如 TurboQuant 和重要性加权量化（IQ4）能在保持模型质量的同时减少模型大小并加快解码速度，未来有望提升本地运行效率。
通过限制模型思考输出的语法结构，可以显著提升生成速度，尤其对较小模型效果明显。
使用开源权重模型结合 OpenRouter 和 OpenCode 服务，实际体验与 Anthropic 模型差异不大，表明开源方案已具备一定竞争力。

Hacker News 精彩评论及翻译 #

Zed 1.0 #

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

What an abysmal series of top comments. These guys created a phenomenal product using novel technology, which will only continue to improve. Great work to the Zed team.

obeavs

这些顶级评论真是糟糕透顶。这些人使用新颖的技术创造了一个极佳的产品，未来只会不断改进。向Zed团队致敬，干得好。

HERMES.md in commit messages causes requests to ro… #

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

However, I need to let you know that we are unable to issue compensation for degraded service or technical errors that result in incorrect billing routing.

This is very surprising. I’ve never seen a legitimate business not give refunds for technical errors of their own fault. Minimum Anthropic should credit the full amount to them.

ecshafer

不过，我需要告诉你，我们无法因服务质量下降或导致错误计费路径的技术错误而发放赔偿。

这真让人惊讶。我从未见过一个正规企业因自身技术错误而不退款。最起码Anthropic应该将全额返还给他们。

Bugs Rust won’t catch #

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

Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually.

I just want to mention that I disagree with the section titled “Rule: Resolve Paths Before Comparing Them”. Generally, it is better to make calls to fstat and compare the st_dev and st_ino. However, that was mentioned in the article. A side effect that seems less often considered is the performance impact. Here is an example in practice:

$ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d ‘\n’) $ while cd $(yes a/ | head -n 1024 | tr -d ‘\n’); do :; done 2>/dev/null $ echo a > file $ time cp file copy

real 0m0.010s user 0m0.002s sys 0m0.003s $ time uu_cp file copy

real 0m12.857s user 0m0.064s sys 0m12.702s I know people are very unlikely to do something like that in real life. However, GNU software tends to work very hard to avoid arbitrary limits [1].

Also, the larger point still stands, but the article says “The Rust rewrite has shipped zero of these [memory saftey bugs], over a comparable window of activity.” However, this is not true [2]. :)

[1] https://www.gnu.org/prep/standards/standards.html#Semantics [2] https://github.com/advisories/GHSA-w9vv-q986-vj7x

collinfunk

你好，我是GNU Coreutils的维护者之一。感谢这篇文章，涵盖了一些有趣的话题。在我使用过的少量Rust代码中，我感觉使用std::fs很容易写出TOCTOU竞态条件。我希望标准库最终能提供类似openat的API。

我只想提一下，我不同意标题为“规则：比较路径前先解析路径”的部分。通常，调用fstat并比较st_dev和st_ino会更好。不过，文章中也提到了这一点。一个似乎较少被考虑的副作用是性能影响。下面是一个实际例子：

$ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d ‘\n’) $ while cd $(yes a/ | head -n 1024 | tr -d ‘\n’); do :; done 2>/dev/null $ echo a > file $ time cp file copy

实际时间 0m0.010s 用户时间 0m0.002s 系统时间 0m0.003s $ time uu_cp file copy

实际时间 0m12.857s 用户时间 0m0.064s 系统时间 0m12.702s

我知道现实中人们很少会这样做。不过，GNU软件通常会努力避免任意限制[1]。

此外，更重要的是，文章中说“Rust重写在相同的活跃时间内没有出现过这类[内存安全漏洞]。”但这并不准确[2]。:)

[1] https://www.gnu.org/prep/standards/standards.html#Semantics [2] https://github.com/advisories/GHSA-w9vv-q986-vj7x

HERMES.md in commit messages causes requests to ro… #

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

The official response feels AI generated. I suspect this is a preview of our future.

“You’re totally right! I’m sorry but you’re going to have to piss off anyway. Would you like to spend a few more hours discussing it with our AI chatbot? It won’t help. But if it makes you feel better, it will probably cost us an extra $0.12 in tokens.”

I’ll bet the first human at Anthropic learns about this from HN.

stickfigure

官方的回应感觉像是由人工智能生成的。我怀疑这就是我们未来的预览。

“你完全正确！很抱歉，但你无论如何都得走开。你愿意再花几个小时和我们的AI聊天机器人讨论这个问题吗？这不会有帮助。但如果这能让你感觉好点，可能会让我们多花0.12美元的代币费。”

我敢打赌Anthropic的第一个工作人员会在HN上了解到这件事。

Online age verification is the hill to die on #

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

The one and only method I will participate in is server operators setting a RTA header [1] for URL’s that may contain adult or user-generated or user-contributed content and the clients having the option to detect that header and trigger parental controls if they are enabled by the device owner. That should suffice to protect most small children. Teens will always get around anything anyone implements as they are already doing. RTA headers are not perfect, nothing is nor ever will be but there is absolutely no tracking or leaking data involved. Governments could easily hire contractors to scan sites for the lack of that header and fine sites not participating into oblivion.

I a small server operator and a client of the internet will not participate in any other methods period, full-stop. Make simple logical and rational laws around RTA headers and I will participate. Many sites already voluntarily add this header. It is trivial to implement. Many questions and a lengthy discussion occurred here [1]. I doubt my little private and semi-private sites would be noticed but one day it may come to that at which point it’s back into semi-private Tinc open source VPN meshes for my friends and I.

[1] - https://news.ycombinator.com/item?id=46152074

Bender

我唯一会参与的方法是服务器运营者为可能包含成人内容或用户生成、用户贡献内容的URL设置RTA头[1]，客户端可以选择检测该头部，如果设备所有者启用了家长控制功能，则触发该控制。这应该足以保护大多数小孩子。青少年总会像现在这样绕过任何人的限制。RTA头并不完美，没有任何方法是完美的，也永远不会有，但它绝对不会涉及跟踪或泄漏数据。政府完全可以雇佣承包商扫描没有设置该头部的网站，并对不配合的网站处以巨额罚款。

我作为一个小型服务器运营者和互联网用户，绝不会参与任何其他方法，绝对不会。围绕RTA头制定简单、合乎逻辑和理性的法律，我才会参与。许多网站已经自愿添加了这个头部，这很容易实现。这里[1]有过很多问题和长时间讨论。我怀疑我的小型私人或半私密网站会被注意到，但将来可能会有那一天，届时我和朋友们就只能回到半私密的Tinc开源VPN网状网络中。

[1] - https://news.ycombinator.com/item?id=46152074

HERMES.md in commit messages causes requests to ro… #

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

“I need to let you know that we are unable to issue compensation for degraded service or technical errors that result in incorrect billing routing.”

Not sure I’ve ever seen a company openly take this position. This is a crazy policy.

mikehearn

我需要告诉你，我们无法因服务质量降低或技术错误导致的错误计费路由而提供赔偿。

我不确定我是否见过有公司会公开坚持这种立场。这真是一个疯狂的政策。

Ghostty is leaving GitHub #

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

I can appreciate Hashimoto’s genuine feelings about Github, and the world of open-source software development that it opened for him and that he spent a significant chunk of his life participating in.

On the other hand, I can’t help but think that some of this heartbreak would have been avoidable, if only he possessed more of the Richard-Stallman-esque attitude that non-free software is inherently suspect and unethical. Github has always been non-free software hosted by someone else, and run according to its owners’ rules and for its owners’ benefit, not ultimately the end user. This was true in 2008 and it’s true today.

I’ve also used Github for a significant chunk of my life, often because I had to for my job. But I’ve never developed an emotional attachment to it. Indeed, I have long been annoyed that Github is someone else’s proprietary software, that does what it can to structurally lock users into their platform despite being built upon free-software git.

I’ve never been able to love software that requires an email-based account and accepting terms of service and that doesn’t work in Iran because the company that runs it obeys US sanctions law.

So without reservation on my end, I’m glad to see that ghostty is moving off of github to something else.

JuniperMesos

我能理解桥本对 Github 真挚的感情，以及那个由 Github 开启的开源软件开发世界，他也在其中投入了他生命中相当大的一部分时间。

但另一方面，我忍不住觉得，如果他能拥有更多类似理查德·斯托曼那样的态度——认为非自由软件本质上就是可疑且不道德的，也许他的一些心碎本可以避免。Github 一直以来都是非自由软件，由别人托管，按照拥有者的规则运行，最终利益也归属于拥有者，而非最终用户。2008 年如此，今天依然如此。

我也在生命中的很长一段时间里使用过 Github，往往是因为工作需要。但我从未对它产生情感依附。事实上，我早就对 Github 是别人家的专有软件感到不满，它在构建于自由软件 git 之上的同时，尽其所能在结构上把用户锁定在它的平台里。

我从来没法爱上那种需要基于邮箱的账户、接受服务条款，而且因运营公司遵守美国制裁法规导致在伊朗无法使用的软件。

所以，我毫无保留地为看到 ghostty 正在从 Github 转移到别的平台感到高兴。

Zed 1.0 #

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

Congrats to the Zed team for building the best modern editor I have ever used. I subscribe to the monthly plan just to give you guys the funding you need, even if my funding is a tiny drop in the bucket. I always wanted a feature rich alternative to Sublime Text that can run anywhere and do basically anything I need from it. I’ve use JetBrains IDEs for years (been subscribed annually since 2017), but since Zed I havent really opened any of those IDEs in a long time, other than maybe Rider but that’s due to C# nuances I needed to work with.

giancarlostoro

恭喜Zed团队打造了我用过的最棒的现代编辑器。我订阅了月度计划，只是为了给你们提供所需的资金支持，哪怕我的资金只是杯水车薪。我一直想要一个功能丰富、能够在任何地方运行、并且基本能满足我所有需求的Sublime Text替代品。我多年来一直使用JetBrains的IDE（自2017年以来每年订阅），但自从有了Zed之后，我很久没打开过那些IDE了，除了可能偶尔用用Rider，那是因为需要处理C#相关的细节。

How ChatGPT serves ads #

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

Less than two years ago, Sam Altman said

I kind of think of ads as a last resort for us for a business model. I would do it if it meant that was the only way to get everybody in the world access to great services, but if we can find something that doesn’t do that, I’d prefer that.

So, is this OpenAI announcing they’re strapped for cash?

programjames

不到两年前，Sam Altman 曾说：

我有点把广告当作我们商业模式的最后手段。如果这真的是让全球所有人都能使用优质服务的唯一方法，我会这么做，但如果能找到不这样做的方式，我更愿意选择那种方式。

那么，这是OpenAI在宣布他们资金紧张吗？

Ghostty is leaving GitHub #

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

Hi there! Longtime fan and hubber here.

It’s okay to have emotions. I have similar emotions. I’m GitHub User 22723 which is effectively the same as you (considering there’s ~180m GH accounts nowadays)

My version of your post reads differently:

“GitHub only gets better if people who give a shit stick around to make it better”

Walking away would be easy. I felt that way when I left Heroku ~six years ago. I left that job and never opened the Heroku dashboard again, after nearly a decade of happy use. I felt that it was irredeemable, and though it took a while, Salesforce did eventually succeed in running it fully into the ground.

I don’t feel the same about GitHub. It is precisely because it’s precious that I can’t walk away. I’m not the only one here who feels that way.

In the past few years, GitHub has absorbed both a fundamental paradigm shift (agentic coding) AND several different hockey sticks of growth. It’s messy. I’m not always proud of the results or the product choices we are forced into. But none of it feels like the Heroku/Salesforce debacle. Occam’s razor applies here: it’s not “more AI coding” and it’s not “big bad Microsoft.” It’s scale, and a fundamental shift of the ground under all of our feet.

I hope we do the things that will make you want to come back. I hope we spark that joy in you again! It’s not stupid to have big feelings about something that is so central to our lives as developers. Fuck that noise.

idan

你好！我是一个长期的粉丝和GitHub用户。

有情绪是正常的。我也有类似的感受。我是GitHub用户22723，实际上和你差不多（毕竟现在GitHub大约有1.8亿账户）。

我对你这篇帖子有不同的理解：

“只有那些真正关心的人坚持留下来努力改进，GitHub才会变得更好。”

走开会很容易。我当年离开Heroku的时候也是这么感觉的，大约六年前。我辞去了那份工作，之后近十年都没再打开过Heroku的控制面板。我觉得那个产品已经无可救药，虽然过程漫长，但Salesforce最终还是彻底把它搞砸了。

我对GitHub的感受不一样。正因为它珍贵，我才无法离开。我并不是唯一有这种感觉的人。

这几年，GitHub经历了根本范式的转变（自主编码），以及几波迅猛的增长。过程很混乱。我并不总是为结果或我们不得不做出的产品选择感到自豪。但这一切都不像Heroku/Salesforce那样的灾难。奥卡姆剃刀原则告诉我们：问题不是“更多的AI编码”，也不是“可怕的大微软”，而是规模，以及我们脚下土地的根本变化。

我希望我们做的事情能够让你想要回来。我希望我们能再次点燃你内心的那份喜悦！对如此重要的东西有强烈的情感绝不是愚蠢。去他妈的那些噪音吧。

How ChatGPT serves ads #

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

No, I suspect that “I kind of think of ads as a last resort” was doublespeak for “ads are coming eventually”.

I would tend to think of someone like him as a person who uses words to achieve a specific goal, rather than someone who speaks whatever is truly on their mind. Whether those words are lies or truth or somewhere in between is irrelevant; what matters to them is the outcome.

It’s likely a waste of time trying to unpick the meaning, because there is none. “But Sam Altman said…” to me has about as much value as “ChatGPT told me…”.

danparsonson

不，我怀疑“我有点把广告看作最后的手段”其实是“广告迟早会来的”的一种委婉说法。

我倾向于认为像他这样的人，是用言辞来达成特定目的，而不是随心所欲地说出真心话。这些话是真话、假话还是介于两者之间并不重要；对他们来说，关键是结果。

试图去解读这些话的含义很可能是徒劳的，因为根本没有什么含义。对我来说，“但萨姆·奥特曼说……”和“ChatGPT告诉我……”的价值差不多。

Your phone is about to stop being yours #

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

This change has served me well! I have been a Mac OS X users for years who used an android phone. As soon as google announced their impending walled garden status, I went out and bought into the ios eco system. I have really been enjoying my iphone, ipad, and apple watch.

You see, the only value that Android really offered me was the ability to run my own code on my own device. Since they are taking that away that just makes it a crappier shadow of the vastly superior apple experience. And, as it turns out, ios is less restrictive than it was 18 years ago when I left them for Android!

pngwen

这个改变对我来说非常有用！我多年来一直是Mac OS X用户，同时使用安卓手机。自从谷歌宣布他们即将实行封闭花园政策后，我就去买了苹果生态系统的产品。我真的很喜欢我的iPhone、iPad和Apple Watch。

你看，安卓唯一给我的价值就是能够在自己的设备上运行自己的代码。既然他们要取消这一点，那它就成了苹果远远优越体验下的一个糟糕阴影。而且，事实证明，iOS现在比18年前我离开它转向安卓时反而限制更少了！

Bugs Rust won’t catch #

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

What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing

They knew how to write Rust, but clearly weren’t sufficiently experienced with Unix APIs, semantics, and pitfalls. Most of those mistakes are exceedingly amateur from the perspective of long-time GNU coreutils (or BSD or Solaris base) developers, issues that were identified and largely hashed out decades ago, notwithstanding the continued long tail of fixes–mostly just a trickle these days–to the old codebases.

wahern

值得注意的是，这些漏洞都出现在一个由有经验的开发者编写的生产环境Rust代码库中。

他们知道如何编写Rust代码，但显然对Unix的API、语义和陷阱并不够熟悉。从长期从事GNU coreutils（或BSD、Solaris基本系统）开发者的角度来看，其中大多数错误非常业余，这些问题几十年前就已经被发现并基本解决，尽管对老代码库的修复仍在持续，只不过现在大多只是零星的更新。

Mistral Medium 3.5 #

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

I’m not sure what people are on in the comments. It doesn’t beat the other models, but it sure competes despite its size.

GLM 5.1 is an excellent model, but even at Q4 you’re looking at ~400GB. Kimi K2.5 is really good too, and at Q4 quantization you’re looking at almost ~600GB.

This model? You can run it at Q4 with 70GB of VRAM. This is approaching consumer level territory (you can get a Mac Studio with 128GB of RAM for ~3500 USD).

For the Claude-pilled people, I don’t know if you only run Opus but when I was on the Pro plan Sonnet was already extremely capable. This beats the latest Sonnet while running locally, without anyone charging you extra for having HERMES.md in your repo, or locking you out of your account on a whim.

Mistral has never been competitive at the frontier, but maybe that is not what we need from them. Having Pareto models that get you 80% of the frontier at 20% of the cost/size sounds really good to me.

simjnd

我不太明白评论区的人在说什么。它确实没有击败其他模型，但考虑到体积，它的表现已经很有竞争力了。

GLM 5.1是一个出色的模型，但即使是Q4量化，也需要大约400GB的显存。Kimi K2.5也非常不错，Q4量化时几乎需要600GB。

这个模型呢？你可以在Q4量化下用70GB显存运行。这已经接近消费级别了（你可以用大约3500美元买到搭载128GB内存的Mac Studio）。

对于那些只用Claude的人，我不知道你们是否只运行Opus，但当我用Pro套餐时，Sonnet已经非常强大了。这个模型在本地运行时击败了最新的Sonnet，而且没人会因为你在仓库里有HERMES.md就额外收费，或者随意锁你账户。

Mistral从未在最前沿具有竞争力，但也许那不是我们对他们的期待。拥有Pareto模型，以20%的成本和体积达到80%的前沿性能，对我来说非常有吸引力。

He asked AI to count carbs 27000 times. It couldn’… #

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

But the author just took pictures of food & expected a realistic response?

There are very popular apps on the App Store right now that are going viral among non-techie people that do exactly this, and they have no concept of how AI works. My wife was talking about one and I had to give her a reality check that the AI had no idea what ingredients were used to make the food. And she’s a licensed nutritionalist.

Studies like this create something to point at for people who are confused and serve as a springboard for a conversation in the media.

kalleboo

但作者只是拍了食物的照片，就期望得到一个真实的回应？

现在 App Store 上有一些非常受欢迎的应用，在非技术人员中迅速走红，正是做这样的事情，他们根本不了解人工智能的工作原理。我的妻子曾谈论过其中一个，我不得不让她意识到，人工智能根本不知道做这道菜用了哪些食材。她还是一名持证营养师。

像这样的研究为感到困惑的人提供了一个可以指向的案例，也成为媒体讨论的跳板。

He asked AI to count carbs 27000 times. It couldn’… #

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

There’s an incredibly serious lack of education with how LLMs & carb-counting works. This entire article would be better suited to astrology.com than hackernews.

When I opened it up, I assumed the author would have at least attempted a calculation service, maybe even placed something like the size of the meal into an actual model, using the integration of pre-existing tools that are (slightly more) accurate. Hell - most food literally is required to have calorie information, and you can query open source data for others!

But the author just took pictures of food & expected a realistic response? Is this genuinely what amounts to a study in AI?

This is akin to the instagram reels that talk to chatGPT and ask it to time how long they’re run is. Except those are treated as funny jokes rather than being turned into studies.

I’d like to see this study done using any kind of actual grounding knowledge, seeing what mistakes AI makes when attempting to query ground truth from picture analysis - there would at least be an interesting result methodology in that.

endymion-light

对于大型语言模型和碳水化合物计数的工作原理，公众的教育严重不足。整篇文章更适合出现在占星网站而非Hacker News。

当我打开文章时，本以为作者至少会尝试一个计算服务，甚至可能把餐食的实际份量输入到一个整合了现有工具（这些工具更准确一点）的模型中。毕竟，大多数食物都必须标明卡路里信息，你还可以查询开源数据获取其他食物的卡路里！

但作者只是拍了食物的照片，就期待得到一个现实的结果？这真的算是人工智能研究吗？

这类似于那些在Instagram短视频里跟ChatGPT对话，问它自己跑步用了多长时间的内容。区别是，那种被当作搞笑段子而非严肃研究。

我更希望看到基于真实知识做的研究，看看人工智能在通过图片分析查询真实数据时会犯什么错误——至少那样的方法论会有趣得多，结果也更有意义。

Your phone is about to stop being yours #

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

With a free account, it needs to be reinstalled every 7 days because the signature expires. It’s hardly convenient for personal use.

quantumleaper

使用免费账户的话，每7天就需要重新安装一次，因为签名会过期。这对个人使用来说几乎不方便。

UAE to leave OPEC #

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

Context:

(1) “The United Arab Emirates,” today “made a shock request of [Pakistan] — repay $3.5bn immediately” [1].

(2) Saudi-Emirati relations were at an all-time low before the Iran War [2]. (Saudi Arabia just bailed Pakistan out of its Emirati loan. Saudi Arabia and Pakistan agreed a mutual-defence treaty last year [3].)

Put together, we’re seeing an Emirati-Israeli axis emerging to balance Saudi hegemony in the Gulf and Iranian hegemony over the Persian Gulf. I’d expect to see an Emirati deal with Egypt and India next if this hypothesis is correct.

What I don’t yet see is the ambition of the endgame. Is it Saudi Arabia backing off in Africa? Or is it seizing the Musandam Peninsula, islands of the Strait and possibly even territory on the other side?

[1] https://www.ft.com/content/99073d6e-4b57-417f-88fb-7a2c0e55eef3?syn-25a6b1a6=1

[2] https://www.nytimes.com/2025/12/30/world/middleeast/yemen-saudi-strike-uae.html

[3] https://en.wikipedia.org/wiki/Strategic_Mutual_Defence_Agreement

JumpCrisscross

（1）“阿拉伯联合酋长国”今天向[巴基斯坦]提出了一个令人震惊的要求——立即偿还35亿美元”。

（2）伊朗战争之前，沙特与阿联酋的关系处于历史最低点。（沙特刚刚帮巴基斯坦偿还了阿联酋的贷款。沙特与巴基斯坦去年签署了互助防御条约。）

综合来看，我们看到一个阿联酋-以色列轴心正在形成，以平衡沙特在海湾地区的霸权以及伊朗在波斯湾的霸权。如果这个假设正确，我预计接下来阿联酋会和埃及、印度达成协议。

我目前还不清楚最终的目标是什么。是沙特从非洲撤退吗？还是要夺取穆桑达姆半岛、海峡的岛屿甚至对岸的一些领土？

Your phone is about to stop being yours #

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

Android’s openness was never just a feature. It was the promise that distinguished it from iPhone. Millions chose Android for exactly that reason. Google is now revoking that promise unilaterally, on devices already in people’s pockets, because they’ve decided they have enough market dominance and regulatory capture to get away with it.

This is why I’ve stuck with Android for the past 15 years.

NDlurker

安卓的开放性从来不仅仅是一个功能。正是这个承诺让它有别于iPhone。正因为这个原因，数以百万计的人选择了安卓。谷歌现在单方面撤销了这个承诺，针对的是已经在用户口袋里的设备，因为他们认为自己拥有足够的市场主导地位和监管的话语权，能够逍遥法外。

这就是为什么我过去15年一直坚持使用安卓的原因。

Before GitHub #

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

What GitHub Gave Us

To me one of the clear things that GitHub gave us was a structure around a person rather than a project. To me it felt liberating to quickly create a repository attached to my name than it was to go through the (what felt to me) very serious process of coming up with a project name and reserving it on sourceforge just to get a cvs or svn repository (along with website, mailing lists, issue tracking(?), etc, etc…). It felt like the mental load of “oh this is just a quick thing” was a lot easier with github.

It gave projects issue trackers, pull requests, release pages, wikis, organization pages, API access, webhooks, and later CI.

Although it didn’t give us this all at once. I still remember when we created a new user account in order to simulate an organisation, before they existed. I distinctly recall discussing with friends if we wanted to set up a bug tracker software for our project with the assumption that “GitHub will probably release one in a few months anyway”. In the end we just kept a text file committed in the repository. Issues were announced a few months later.

alastairp

对我来说，GitHub带给我们的一个明显变化是围绕个人而不是项目建立的结构。相比于经历那个（在我看来）非常严肃的过程——想出一个项目名并在sourceforge上注册它，仅仅为了获得一个cvs或svn仓库（还包括网站、邮件列表、问题追踪（？）等等……），我觉得能快速创建一个挂在我名下的仓库非常解放。感觉心理负担上，“这只是一个快速的东西”时，在GitHub上要轻松得多。

它给项目提供了问题追踪器、拉取请求、发布页面、维基、组织页面、API访问、Webhook，后来还有持续集成。

虽然这些功能不是一开始全部提供的。我还记得刚开始为了模拟组织而创建新用户账户的日子，那时组织功能还不存在。我清楚地记得和朋友讨论是否要为项目搭建一个缺陷追踪软件，大家的假设是“GitHub大概几个月后会出一个”。最终我们只是将问题放在一个提交到仓库的文本文件里。几个月后，问题追踪功能才正式推出。

Ghostty is leaving GitHub #

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

I can feel the frustation, nothing dramatic about expressing it

This quote from the post resonated with me:

I want to get work done and it doesn’t want me to get work done. I want to ship software and it doesn’t want me to ship software.

The sentiment is shared, and github is not the only service making me feel like that, it feels like everything on the web is more flimsy and low quality nowadays. Constant outages, bugs, UI papercuts, incomplete features, what in the world is going on?

DrammBA

我能感受到那种挫败感，表达出来一点也不夸张。

帖子里的这句话让我很有共鸣：

我想完成工作，但它就是不让我完成。我想发布软件，但它就是不让我发布。

这种感受是共通的，而GitHub并不是唯一让我有这种感觉的服务，感觉现在网络上的一切都越来越脆弱、质量低劣。不断的宕机、漏洞、界面小问题、不完整的功能，到底发生了什么？