原标题：《Codex Is Down》 评分: 37 | 作者: armcat 💭 让 Codex 修 Codex，结果先把自己修成 404？ 🎯 讨论背景 这条帖子讨论的是 OpenAI 的 ChatGPT 网页端和 Codex（代码代理/编程助手）在登录后出现异常：有用户发现已登录状态下访问 chatgpt.com 会直接返回裸 404，而无痕模式却正常，像是账户态、鉴权或后端路由出了问题。还有人提到在 VS Code（微软的代码编辑器）里使用 Codex 时，后端接口 backend-api/codex/responses 也报 404，说明故障不只影响网页，还波及 IDE 集成。评论随后把话题延伸到“如果云端 AI 服务挂了怎么办”，有人提 GLM 5.3、Qwen（阿里巴巴开源模型系列）和本地高性能硬件上的替代方案，试图把依赖从单一服务转向本地或其他模型。与此同时，Claude（Anthropic 的聊天/编程模型）也被贴出状态页，显示 API Error 529 Overloaded，让讨论进一步变成对云端 AI 服务脆弱性的集体吐槽。 📌 讨论焦点 登录态与接口异常
原标题：《Intrusive Linked Lists》 评分: 27 | 作者: tripdout 💭 把老式链表改名成 intrusive，就算创新了？ 🎯 讨论背景 这篇帖子讨论的是 intrusive linked list（把链表指针嵌在元素结构体内部）和常见的非 intrusive 容器之间的取舍。评论里多次提到 `std::list `（C ++ 标准库里的链表容器）、`container_of `（Linux/C 里常用的宏）以及 C 里用宏模拟泛型链表的做法。许多人把这种结构和 OS kernel、embedded systems、memory manager、老游戏引擎联系起来，因为它能减少分配、减少 indirection，并支持同一对象挂到多条链上。另一条背景线索是术语历史之争：有人认为 intrusive 是 C ++ 时代为了和 `std::list ` 对照才流行起来的名字，但老式 C 代码其实早就大量使用这种嵌入式链表；评论还顺带提到 AmigaOS 的特殊链表头设计，说明不同系统对边界和哨兵的处理各有巧妙之处。 📌 讨论焦点 性能与零分配优势 很
原标题：《ICE Has a $2M Contract for Spyware That Can Hack Phones Without a Click》 评分: 32 | 作者: miohtama 💭 花 200 万买零点击间谍软件，这也叫移民执法？ 🎯 讨论背景 这篇帖子围绕一则报道展开：ICE（美国移民与海关执法局）被指签了约 200 万美元的 Graphite 间谍软件合同。Graphite 是 Paragon Solutions（以色列商业监控软件公司）推出的 mercenary spyware，可借助 zero-click exploit 在用户无感的情况下入侵手机。评论里反复提到 Citizen Lab（多伦多大学专门研究数字监控的团队）、WhatsApp、iMessage 和 Apple Threat Notification，因为这些都是此类攻击和取证常见的线索。讨论一方面在争论 ICE 是否正在变成准军事化的国内执法力量，另一方面在解释 commercial spyware 市场为什么能以看似不高的价格持续扩张。还有人指出后续报道里 DHS 曾否认与 Parag
原标题：《Gemini 3.8 Flash》 评分: 1094 | 作者: bratao 💭 还没全量上线，就先拿 benchmark 封神了？ 🎯 讨论背景 Gemini 3.8 Flash 是 Google DeepMind（Google 的 AI 研究部门）发布的低延迟、低成本模型，属于 Gemini Flash 系列，和更重的 Pro/旗舰档不同。评论把它和 Anthropic（Claude 的开发商）的 Claude Opus、OpenAI（ChatGPT 背后的公司）的 GPT 系列，以及 Qwen（阿里巴巴的模型家族）、GLM（智谱的模型家族）、Kimi（月之暗面的大模型）反复对比，主要看代码代理、旅行规划、文档抽取和多模态分析谁更划算。很多人还在讨论 Google AI Studio（Google 的模型试用平台）、Gemini app、Antigravity（Google 的编码代理 CLI/界面）和 OpenRouter（模型路由服务）之间的可用性差异，因为同一个模型在不同入口上的版本、限额和延迟差别很大。帖子里频繁出现 Artificial Analysis（
原标题：《Elevated Errors for Multiple Models》 评分: 62 | 作者: __vivek 💭 算力短缺到每周都炸，还叫高可用服务吗？ 🎯 讨论背景 这条 HN 讨论围绕 Anthropic 的 Claude 服务在同一时间出现 elevated errors，以及 xAI 的 Grok 也同步报错展开。评论区把问题和 SpaceX datacenters、Colossus（xAI 相关的大型数据中心集群）联系起来，推测可能是共享机房或算力池出了故障。另一条重要背景是 Claude Code（Anthropic 的终端编码助手）的 auto mode 依赖 Sonnet（Claude 的中档模型）来判断编辑操作是否安全，因此一旦 Sonnet 不可用，整个写代码流程会被卡住。评论还反复提到 weekly quota、capacity、fallback 和 local open-weight models，说明这场讨论不只是一次宕机，而是围绕 LLM 服务的算力供给、可靠性和用户迁移成本。 📌 讨论焦点 共因疑似是共享数据中心故障 不少人把 Cla
原标题：《Reverse Engineering Unknown File Formats with ImHex》 评分: 228 | 作者: carlos-menezes 💭 未知格式？最后不还是 zip 套 sqlite 吗？ 🎯 讨论背景 这篇讨论围绕 ImHex（一个用于逆向二进制文件格式的 hex editor）展开，它的特点是带有可写规则的 Pattern Language（格式描述 DSL），适合把未知文件拆成字段、数组和条件结构来看。评论里很多经验都来自真实的逆向场景：老式数据库文件、游戏存档、PS2 memory card、Unreal 资源文件、Outlook 本地邮件格式，以及各种企业系统里层层嵌套的封装。大家普遍认为，入门时最有效的方法不是“猜”，而是先做差分、看 entropy、找校验和，再结合程序来源判断它可能是 struct、terminator 还是某种 serializer。也有人强调，很多看起来神秘的格式最后只是 zip、sqlite、JSON、XML 或 base64 的组合，只是历史包袱让它们变得又丑又难拆。 📌 讨论焦点 老派逆向经历与职
原标题：《Fish Bad, Sugar Good and Other Medieval Ideas About Food》 评分: 23 | 作者: mooreds 💭 没冷藏没微生物学，瞎猜也能写成饮食科学？ 🎯 讨论背景 这篇讨论围绕一篇讲中世纪欧洲饮食观念的文章展开，核心是 Galen（古希腊罗马时期的医学权威）和 humoral theory（体液学说）如何把食物分成“热/冷、干/湿”，从而得出诸如 lettuce（生菜）寒湿有害、citrus（柑橘）有助消化之类的结论。评论者把这些说法放回当时条件下理解：没有 refrigeration（冷藏），鱼和家禽更容易腐败；糖很稀缺，干果和保存食品更重要；高强度体力劳动也让高热量食物更受欢迎。另一条线索讨论史料偏差，因为识字并能写下食谱、医书和农业观察的人往往是男性，女性的劳动和饮食经验更少进入记录。整体上，讨论把中世纪饮食知识看成一种由经验、医学权威和社会结构共同塑造的体系，并不断拿它和现代 food culture（饮食文化）比较。 📌 讨论焦点 食物禁忌常是经验性的安全规则 很多评论认为，所谓“鱼坏、糖好”在没有冷藏和卫
原标题：《4.5B Posts Scraped from TikTok》 评分: 26 | 作者: TheOnlyWayUp 💭 绕过风控抓 4.5B 条，还算研究吗？ 🎯 讨论背景 这条帖子讨论的是一个声称收录了 45 亿条 TikTok 帖子的抓取项目，源码据说放在一个私有 Go 仓库里，并以一次性付费、终身访问的方式出售。评论者从页面里的 LLM 文案和零散说明推断，项目重点并不是“保存视频”，而是绕过 TikTok 的 bot filters（反爬/反机器人机制），通过伪装成合法客户端去调用 API（应用程序接口）抓取内容。有人补充说，数据集里未必预先包含实际视频或素材，媒体可能要在运行时通过 TikTok API 按代码请求，这意味着 TikTok 一旦改动接口或风控，整套代码就要更新。讨论同时围绕合法性、版权和分发风险展开：它被明确描述为违反 TikTok 的 Terms of Service（服务条款），并可能在 Hugging Face（常见的数据集托管平台）上遭遇 DMCA takedown（版权下架）。 📌 讨论焦点 隐私与数据所有权争议 不少评论者认为，这类
原标题：《WebLLM: high-performance in-browser LLM inference engine》 评分: 127 | 作者: saikatsg 💭 浏览器 GPU 都不稳，还谈高性能推理？ 🎯 讨论背景 WebLLM 是一类把大模型推理直接搬到浏览器里的引擎，依赖 WebGPU（浏览器内的 GPU 计算 API）来获得可用性能。评论显示，这种方案在桌面浏览器上并不“开箱即用”：Linux 上常要手动打开实验性开关，浏览器还可能因为驱动栈和显卡选择问题而只用到集显或软件回退。即使能跑，模型权重也通常要先下载几百 MB 到 1GB，所以它更像“把推理端塞进网页”而不是轻量应用。讨论还把它和 Transformers.js、ONNX Runtime、llama.cpp 等 browser-side / wasm 推理方案放在一起比较，反映出网页端 AI 生态正在分流到多个技术栈。 📌 讨论焦点 WebGPU 兼容性与显卡选择困难 很多人先卡在最基础的一步：浏览器里根本没有可用的 WebGPU，直接报 WebGPUNotAvailableError。Firef
原标题：《Japan halves speed limit to 30km/h on all narrow city streets》 评分: 50 | 作者: haunter 💭 60km/h 冲进窄巷，是赶着去投胎还嫌路不够窄？ 🎯 讨论背景 这条新闻说日本要把没有中心线、没有中央分隔、且宽度小于 5.5 米的住宅道路法定限速从 60km/h 降到 30km/h，涉及约 87 万公里道路，约占日本一般道路的 70% ，消息来自 Mainichi Shimbun（日本《每日新闻》）。评论区补充了日本街道极窄、路灯和行人空间混杂、很多路段本来就不适合高速通过的背景，还提到日本买车常要证明自己有停车位，街边停车受限，所以城市更适合步行和小型车。另一个常被提起的前例是 2011 年的 zone 30 试点，据称在学校路段和住宅路段把死亡与重伤降了 30% 。整场讨论还拿荷兰、德国、法国、西班牙、瑞典、立陶宛等国作对比，核心争论是：光改限速够不够，还是必须配合执法和道路设计。 📌 讨论焦点 窄街道本就不适合 60km/h 很多评论先质疑旧限速本身就离谱，因为日本住宅区的街道往往极窄，常
