在 Fedora 主机上，一个基于 eBPF 的“yeet”脚本取代了官方的 `statsd_exporter`。一个小型 TCX eBPF 探针挂载到入站和出站流量控制钩子，按端口捕获 UDP 载荷，并将其复制到环形缓冲区，而不会接收或修改数据包。JavaScript 收集器负责解码 StatsD 计数器、仪表、直方图和集合，并将名称及标签转换为 Prometheus 指标。
收集器在 SharedWorker 中运行。抓取时，一个短生命周期且不创建套接字的隔离实例通过 yeet 的 HTTP 网关将注册表渲染为 Prometheus 文本格式。应用继续向 8125 端口发送无需确认的 UDP 数据包；即使没有 StatsD 监听器，也能生成指标。
只需添加相应的解码器，同一套数据包捕获机制还可以支持 Redis、memcached、Graphite 和其他明文行协议。其取舍包括：在发送端而非目标端观察流量、使用无需 YAML 映射的简化指标命名、自动添加 `_total` 后缀、捕获上限为 512 字节，以及不支持加密载荷。
每日HackerNews RSS
一则 Hacker News 讨论：有人计划用 eBPF 程序替换端口 8125 上的网络监听器，在网络接口层监控流量，并使用 JavaScript 解码器将捕获到的数据行转换为 Prometheus 指标。评论者强烈质疑这种方案的复杂性，认为基本的套接字监听器更容易通过 `ss`、`netstat` 和 `strace` 等工具进行检查。由于流量很小且仅在本地传输，他们认为 eBPF 方案没有明显的性能优势，而且过于不透明，难以调试。
Kagi 将停止直接开发适用于 Linux 和 Windows 的 Orion，并将在未来 30 天内将这两款版本开源。公司将把其规模较小的团队和资源重新集中到适用于 macOS 和 iOS 的 Orion 上，预计将在速度、稳定性和功能方面进行改进。 Kagi 计划与开源基金会和组织合作，长期维护这些项目，但不会担任核心维护者。有兴趣接手 Linux 或 Windows 项目的开发者、维护者或组织，可以联系 [email protected]。 当前 Linux 测试版仍可使用，但 Kagi 将在 2026 年 10 月 2 日之后停止提供更新，因此不建议将其作为主力浏览器。适用于 Windows 的 Orion 原计划于 2026 年末发布，如今将改为以源代码形式发布，由社区继续开发和维护。Kagi 表示，选择不基于 Chromium 进行分支开发，是为了保持浏览器引擎的独立性和用户隐私。
Kagi 的《Orion 在 Linux 和 Windows 上的最新进展》引发了一小波讨论。评论者对将这款浏览器扩展到 Apple 平台之外持怀疑态度，理由是其潜在市场份额有限，而且 Kagi 的资源也不足；不过，在彻底放弃之前先发布，仍被认为是更理想的做法。长期使用 macOS 的用户则担心，安全性方面的改进可能会影响 Orion 的稳定性。还有人预计，随着时间推移，Linux、Windows 和 Apple 版本会逐渐分化，从而导致基于 WebKit 的行为和功能出现不一致。
由京都微型计算机（KMC）制造的 **Partner-N64 PC** 是一套任天堂 64 开发工具，支持实时调试。它需要使用经过改装的 N64 主机，并额外增加信号线，将卡带连接器的 **IRQ** 和 **RESET** 信号连接到 CPU。这样，调试器软件就可以在源代码断点处暂停游戏、检查内存、继续执行或重置主机。
该工具发布了两个版本：适用于 Windows 95/98 PC 的 **Partner-N64PC**，以及适用于 SGI 工作站的 **Partner-N64NW**。卡带通过并行接口卡和带状电缆连接到开发 PC，并内置 EEPROM 存储器。
该工具还支持任天堂仅在日本推出的 **64DD** 扩展设备。它可以加载 IPL4ROM 引导程序，同时由 IPL ROM PAK 提供所需的 FONT 和 WAV 数据。**NUS-DCC-00** 适配器允许开发者同时连接两个卡带，将开发用闪存卡带与 SRAM 或 ROM 卡带组合起来，以便进行更逼真的测试，并实现无需 Partner-N64 即可启动 64DD。
Hacker News
最新
|
往期
|
评论
|
提问
|
展示
|
职位
|
提交
登录
Nintendo 64 Partner-N64 开发工具包
（behindthecode.ca）
19 分
由 paulgerhardt 提交
2 小时前
| 隐藏
| 往期
| 收藏
| 1 条评论
帮助
Founderarcstone
2 小时前
[–]
太喜欢了！N64 在巅峰时期简直太棒了！
回复
考虑申请 YC 的 2027 年冬季批次！
申请截止时间为 11 月 2 日。
指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请加入 YC
|
联系我们
搜索：
原昌宏于1994年在电装公司开发出二维码，其设计灵感来自基于网格的围棋游戏。二维码的二维设计能够存储远超传统UPC条码的信息，不仅可以从任意角度扫描，还能减少重复扫描的次数。电装公司虽然为这项技术申请了专利，但随后免费公布了技术规范，推动了二维码的广泛应用。
目前，负责管理UPC公司前缀的GS1正通过“Sunrise 2027”计划推动零售行业采用二维码。尽管这一变化并非法律强制要求，但大型零售商正在升级扫描设备和数据库，延误适配的品牌甚至可能被商超下架。
对制造商而言，这一转变有望改善产品追踪、召回管理、防伪验证，并提供配料、过敏原、保质期和处理说明等详细信息。不过，包装、库存系统、数据存储和标签质量都必须同步更新，产品在过渡期内可能需要同时标注UPC码和二维码。
大型品牌已经开始重新设计包装，而较小的供应商则可能面临成本高昂的期限压力。消费者也很可能从中受益：在受访者中，79%更偏好二维码，但前提是二维码能提供及时、相关的信息，而不只是增加数据量。
Hacker News 上一篇题为“条形码即将灭绝”的讨论分享了一篇文章，介绍了从传统条形码转向二维码等信息量更丰富的格式。评论者欢迎数据容量和商品追踪能力的提升，同时也对传统条形码怀有怀念之情。一位评论者偏爱二维码，觉得它更有趣，看起来像游戏棋盘。另一位则认为，DigiMark 几乎看不见的条形码是更好的选择。第三位则开玩笑说，应该在传统条形码消失前保留一个。
作者认为，尽管几十年来人们一直在研究并进行部分实验，桌面窗口管理仍植根于过时的硬件变通方案。现代桌面难以适应不断变化的显示器配置、不同的用户使用习惯、混杂多种工作内容的浏览器标签页，以及困在应用程序内部而非传统文件系统中的数据。
他们提出的替代方案以任务为中心组织窗口，使用无限、可滚动的画布，并将每台显示器视为一个可移动的视口。浏览器标签页可以拆分为独立窗口，布局会在扩展坞连接状态变化后保持不变，隐私状态也会根据可观察到的机器状况作出响应。本地大语言模型可以检查窗口和标签页内容，并通过受限操作提出任务分组和布局方案；在确定性代码应用更改之前，必须先显示预览并获得用户确认。
此前的各种方案——包括 Rooms、WindowScape、平铺式窗口管理器、Windows Timeline 和 Sets、macOS 舞台管理器、KDE Activities，以及 PWA 窗口——要么难以使用，要么缺乏操作系统层面的整合，要么未能成为默认方案，要么强加给所有人同一种交互模式。
原型系统还暴露了一些严重问题：行为遥测可能让人感到受到侵犯；用户的空闲状态无法反映附近是否存在隐私威胁；无限追加的布局会变得令人不知所措；保留空间记忆也会与清理过时工作发生冲突。尽管如此，这次探索仍表明，质疑沿袭下来的桌面设计假设，并尝试结构性的替代方案，是有价值的。
一则 Hacker News 讨论将 tmux 视为用户实际使用的操作系统，使终端会话能够跨本地、远程和 Windows 环境持续存在。评论者将这种模式与浏览器的垂直标签页、虚拟桌面和全屏应用进行比较，同时警告文件系统的隔离可能会削弱可移植性。
主要问题是如何在重启后保留会话：现代操作系统理想情况下应当在内核或操作系统更新后，仍能保留用户态状态。对于 tmux 用户，建议使用 **tmux-continuum** 和 **tmux-resurrect** 插件自动保存和恢复会话。
一个交互式工作负载选择器和 logarithmic scale slider? 对数刻度滑块，用于对比从每秒 100 到 1,000,000 个输出 token 的假想写作速度。 在最高速度下： - 生成 1,000 个故事结局（每个 1,000 个 token）约需 1 秒； - 生成 40 份应用草稿（每份 20,000 个 token）约需 0.8 秒； - 生成 10,000 条批评意见（每条 300 个 token）约需 3 秒； - 完成 10,000 次排练（每次 1,000 个 token）约需 10 秒。 在每秒 100 个 token 的速度下，相同工作负载分别约需 2 小时 47 分钟、2 小时 13 分钟、8 小时 20 分钟和 27 小时 47 分钟。 这些估算仅计算输出内容，并非模型实测数据。估算不包括阅读、排序、工具调用、权限授予、测试、部署、人工投入和实验。Token 预算表示可用的写作额度，并不等同于已完成的产品。
《黑客新闻》上的一篇讨论设想了如果大语言模型能够以每秒一百万个词元的速度运行，就可能催生哪些实用的实时 AI 应用。一位评论者认为，这样的速度和低延迟会让模型真正成为人类能力的延伸，例如根据舞者的动作实时生成音乐。
原帖作者称，一款“Codex ultrafast”模型借助 Astra 硬件已经达到每秒约 500 个词元，但目前尚不具备经济可行性。他预测，随着“6.1 sol model”即将发布，每秒一百万词元的能力可能在约六个月内变得普遍，从而支持各种交互式应用，而无需持续承担成本压力。整场讨论将超高性能吞吐量视为通往沉浸式、双向 AI 体验的大门，而不只是让静态文本生成得更快。
变更耦合是指，即使看起来彼此无关，代码也往往会一起发生变化。与源代码中可见的依赖关系不同，变更耦合需要通过变更历史来发现。它应作为帮助理解和判断现状的工具，而不是一项需要降至最低的指标，也不是一个需要优化的理想比率。 有些耦合是必要的；但过多的隐性耦合会让一次小修改扩散到多个文件、模块和团队，从而增加定位和排查工作的难度、上下文切换、协作成本、风险以及认知负担。 将代码的物理存放位置与变更耦合进行比较，可以发现四种情况：经常一起变化的代码存放在一起，通常是健康的；独立变化的代码分开存放，也是健康的；经常一起变化的代码却存放在不同位置，可能需要将其集中到一起；而很少一起变化的代码存放在一起，可能需要将其拆分。这些情况只是调查线索，不是自动执行的规定。 造成变更耦合的原因可能包括共享的业务规则、合规要求、数据结构、执行顺序或基础设施。代码集中到一起可能会形成单体系统，而事件、微服务、接口和领域边界并不会自动消除逻辑耦合。团队应优先关注成本高昂的耦合模式，调查其根本原因，并考虑移动、合并、拆分或依赖倒置等做法。由于业务需求和耦合关系会不断变化，团队还应定期复查结果。
Hacker News
最新
|
往期
|
评论
|
提问
|
展示
|
职位
|
提交
登录
变更耦合：为什么一行修改会牵动十个文件
（buildingbetterteams.de）
3 分
作者：mooreds
1 小时前
|
隐藏
|
往期
|
收藏
|
讨论
|
帮助
考虑申请 YC 2027 年冬季批次！
申请截止至 11 月 2 日。
指南
|
常见问题
|
列表
|
API
|
安全
|
法律声明
|
申请 YC
|
联系我们
搜索：
（无内容）
一则标题为**“超大臀部智能”**的 Hacker News 帖子在发布的第一小时获得了 17 分和三条评论。讨论气氛轻松戏谑，并以人工智能为主题：一位评论者开玩笑称赞虚构总统德韦恩·埃利桑多·激浪·赫伯特·卡马乔寻求了专业建议；另一位借“哎呀！我的蛋蛋！”这个说法玩梗，提出开设一个全天由 AI 生成内容的流媒体频道，并命名为“蛋蛋即服务”。第三条评论则只是写道：“欢迎来到 Costco，我爱你。”总体而言，这串讨论充满了荒诞幽默，以及对 AI 生成内容的调侃。
研究人员在萨利希海发现了七种海蜘蛛，其中两种此前未知；这是该地区百年来首次发现新的海蜘蛛种类。这些动物是与蝎子、蜘蛛和鲎有关联的古老海洋蛛形动物，但尤为独特的是，它们最多有12条腿，通过皮肤呼吸，并利用称为“抱卵肢”的特化附肢携带卵。
研究人员利用扫描电子显微镜和DNA分析，确认了毛足海蜘蛛（*Callipallene pilosuspedes*），其“毛茸茸的脚”和触手状口器酷似微缩版的沙拉克；他们还发现了基新塔尼蛛（*Tanystylum kiixin*），其名称源自发现地点附近的一个原住民村庄。*T. kiixin* 的腿短而坚硬，能够收集碎屑和微型寄生虫，从而在身体上形成微型生态系统。这些发现凸显了这些常被忽视的生物在生态和演化上的奇特之处。
# 黑客新闻
新
|
往期
|
评论
|
提问
|
展示
|
工作
|
投稿
登录
## 城里出现了一种新的海蜘蛛
（nautil.us）
7 分
作者：whiteblossom
2 小时前
隐藏
|
往期
|
收藏
|
讨论
|
帮助
考虑申请 YC 2027 年冬季批次！
申请截至 11 月 2 日。
指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请加入 YC
|
联系我们
搜索：
Cloudflare 正在推出其托管型 OHTTP（Oblivious HTTP）网关的封闭测试版。这是一项付费的区域附加服务，可让应用后端接收保护隐私的 HTTP 请求，而无需获知用户的 IP 地址或 TLS 指纹。 OHTTP 将隐私保护职责分由两个独立运营的一方承担：中继负责隐藏客户端身份，但无法读取加密内容；网关负责解密请求，并在不包含客户端标识符的情况下将其转发到应用服务器。Cloudflare 的网关支持标准 OHTTP 和分块 OHTTP、自动扩缩容、托管 HPKE 密钥，以及通过 Cloudflare Access 进行中继身份验证。它运行在 Cloudflare 的全球网络上，能够为托管在 Cloudflare 上的源站提供服务，且增加的延迟极低。为保持信任隔离，该网关会拒绝通过 Cloudflare 自有基础设施中继的请求。 Cloudflare 已将 Privacy Gateway 更名为 OHTTP Relay。开发者可以在源站不位于 Cloudflare 时，使用 Cloudflare 的中继搭配自行运营的网关；也可以在源站位于 Cloudflare 时，使用新的网关搭配第三方中继。 OHTTP 只能保护网络元数据；应用程序仍须避免在请求正文中包含可识别用户身份的信息。
一篇 Hacker News 帖子介绍了 Cloudflare 新的 OTTP 网关，获得 9 分和两条早期评论。主要评论者认为，这项技术虽然可能保护隐私，但最需要它的人可能没有时间或足够专业知识进行配置，而 sophisticated attackers 和恶意代理则可能轻松采用它。他们还警告了一个“柠檬”问题：如果经过该网关的流量经常具有恶意，用户和安全系统可能会开始不信任所有通过它的流量，长期下来这会损害服务的声誉。另一位评论者开玩笑 predicts：“ClInternet：由 Cloudflare 打造的万维网。”