Kobo SDK 为在电子墨水（E-ink）设备上构建应用提供了声明式框架。它负责处理布局、电子墨水刷新周期、生命周期事件和返回导航等核心复杂问题，使开发者能够专注于应用逻辑。 主要特性包括： * **功能门控访问**：应用不直接访问硬件，而是请求资源（网络、存储等），由运行时安全地处理权限结果。 * **强大的工具链**：包含用于布局诊断的模拟器，支持异步操作（HTTPS、可取消任务）以及原子键值存储。 * **部署**：应用以已签名的静态 ARMv7 二进制文件形式交付，通过简单的命令行接口（`kobo new`、`kobo dev`）集成到开发工作流中。 该 SDK 使用基于特征（trait）的模式（`KoboApp`），开发者通过 `ScreenBuilder` 定义状态并实现 UI 更新。这种架构确保了设备的独特显示限制和导航模式由运行时自动处理，同时让开发者能够编写简洁、模块化的代码。
每日HackerNews RSS
最近的一篇 Hacker News 帖子指出，Kobo 电子阅读器现已支持第三方应用程序，这一进展受到了社区的高度热情回应。用户尤其对添加自定义功能的潜力感到兴奋，例如改进笔记管理和引文回顾工具。
这场讨论反映了电子阅读器社区中存在的广泛分歧。尽管一些 Kindle 用户对 Kobo 设备新获得的灵活性表示羡慕，但另一些人则认为电子阅读器应当保持专注阅读、功能单一的初衷。此次更新的支持者反驳称，能够运行应用程序并不代表强制使用，这提供了一种可选的实用性，而非造成混乱。一些用户还对 Kobo 未来可能采取的限制措施表示担忧，而另一些人则借此机会批评了未经越狱的 Kindle 设备中过多的广告。总体而言，社区认为这是电子阅读器定制化进程中一个令人印象深刻的里程碑。
LiteLLM (YC W23) 正在招聘 – Rust / 性能工程师 LiteLLM (YC W23) Is Hiring – Rust / Performance Engineers
15 小时前
请启用 JavaScript 以运行此应用程序。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
LiteLLM (YC W23) 正在招聘 – Rust / 性能工程师 (jobs.ashbyhq.com)
8小时前 | 隐藏
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
`nixpkgs-multiverse` 使用大型 JSON 文件将软件包版本映射到修订版本。由于 Nix 的 `builtins.fromJSON` 是及时的（eager），即便是访问单个软件包，也需要解析整个数兆字节的文件，随着数据集的增长，这成为了性能瓶颈。
为了解决这个问题，作者探索了几种高效查询的替代方案：
* **`builtins.exec`**：通过 fork Shell 进程来运行 SQLite。这种方法很简单，但由于频繁 fork 和重新解析输出，速度较慢。
* **`builtins.importNative`**：使用 C++ 直接对接 SQLite。其性能极高（可在多次查询间缓存句柄），但需要开启不安全的本地代码执行功能。
* **大型 `.nix` 文件**：试图利用 Nix 本身的惰性（laziness），但实际表现比 JSON 更差，因为 Nix 解析器在构建初始抽象语法树（AST）时依然是及时的。
* **`builtins.wasm`**：使用 WebAssembly 在求值器（evaluator）内运行自定义的 SQLite VFS。虽然在可移植性和安全性方面很有前景，但存在显著的启动（JIT）开销。
最终，作者认为由于安全限制和性能权衡，这些方法目前都不适合作为公共工具使用。因此，该项目目前仍沿用 JSON。
这篇 Hacker News 帖子讨论了《将 SQLite 引入 Nix 的三种方法》一文，探讨了在 Nix 生态系统中处理大数据集的各种方式。
评论者们对使用 SQLite 的必要性展开了讨论，并提出了数据访问和性能优化的替代方案：
* **二分查找（Binary Search）：** 有用户建议将数据转换为二进制结构并使用 `bsearch`，以完全避免数据库带来的开销。
* **WASM Blobs：** 另一个建议是将数据直接编译进 WASM blob。这可以利用浏览器的速度和二进制缓冲区，但每次更新仓库时都需要重新编译。
* **优化：** 其他参与者认为，如果目前 7.5MB 的 JSON 数据集导致了性能瓶颈，那么升级现有的 JSON 解析器可能比引入数据库引擎更为高效。
此次讨论凸显了社区对于通过“非常规”或极具创造性的工程实验来改善 Nix 数据访问体验的持续兴趣，同时还提到了诸如 `nkv` 等探讨过类似优化方案的现有项目。
在文档中添加“针对 AI 智能体（For AI agents）”标题的做法正变得越来越普遍，但这往往会让真实用户感到突兀且被排除在外。为了验证这些显式的呼唤是否真的有效，作者通过实验测试了针对智能体的指令是否比标准且优质的文档更能提升大模型的表现。
结果表明，虽然明确、清晰的指令能显著改善模型行为，但专门的标签或“点名”并不能带来任何可衡量的优势。模型对带有或不带“仅限智能体”标签的指令处理方式完全相同。
作者认为，刻意迎合智能体既没必要，也可能损害用户体验。与其创建生硬的机器专用章节，文档应通过以下方式提升所有用户的可访问性：
* **简洁明确的指导**以及完整且易于解析的代码示例。
* **语义压缩**，在不牺牲质量的前提下减少 Token 数量。
* **策略性展示**（例如折叠区域或单独的 AI 友好型 Markdown 文件），以应对技术密度过高给人类阅读带来的困扰。
归根结底，好的文档对所有人均有效。专注于清晰度和结构不仅能惠及人类开发者，也能让 AI 智能体受益，从而使人为的“智能体呼唤”变得多余。
这段 Hacker News 的讨论探讨了向 AI 智能体“耳语”（whispering）的有效性，即在文档中提供特定、隐藏或结构化的指令来引导智能体的行为。
讨论的要点包括：
* **指令位置：** 用户建议将指令放在“首屏”位置或使用专门的文件（如 `AGENTS.md`）可能会影响智能体对信息的优先处理。一些人提议利用内容协商，向 AI 和人类读者提供不同的说明。
* **文档与代码：** 虽然有人认为搜索源代码比依赖可能过时的文档更准确，但另一些人强调，文档对于传达架构意图和最佳实践至关重要。
* **工作流优化：** 一种推荐的策略是将文档与源代码配对，同时使用代码检查工具（linter）来抑制“草率”的代码注释。开发人员可以改为引用特定的文档文件，以防止智能体在代码库中充斥冗长的解释。
* **挑战：** 参与者承认设计实验来衡量这些效果的难度，并指出简单的测试往往会达到“饱和点”，导致难以准确区分性能的提升。
总体而言，社区倾向于使用结构化、专门构建的文档来有效引导智能体，同时避免污染代码库。
本文探讨了 NVIDIA RTX 4090 上全局加载指令（`LDG.E`）的硬件运行流程，该流程是通过计时实验逆向工程得出的。通过追踪一个向量加法内核的内存请求，作者详细描述了数据从寄存器文件到 DRAM 再返回的路径。 流程始于流式多处理器（SM），指令在从寄存器读取地址后被发送到加载/存储单元（LSU）。请求经由合并器（coalescer）优化后发送至 L1 缓存，该缓存采用虚拟寻址的组相联结构。若 L1 未命中，虚拟地址会通过转译后备缓冲区（TLB）转换为物理地址，请求随后通过交叉开关路由至 36 个 L2 缓存切片中的一个。 如果数据不在 L2 中，请求将进入内存控制器，由其管理 GDDR6X DRAM。控制器执行“激活”操作以打开 DRAM 库中的一行，随后进行列读取以获取所需数据。数据随后沿层级结构原路返回——经过 L2、交叉开关和 L1——最终写入寄存器。整个往返过程大约需要 660 个周期。作者提供了复杂的基于奇偶校验的函数，用于模拟地址到切片的映射以及 L1 索引。
这段文字概述了 Hacker News 上关于技术文章《当 GPU 读取内存时发生了什么》的讨论。
该文章探讨了 GPU 访问显存（VRAM）过程中复杂且往往缺乏文档记录的底层流程。由于 NVIDIA 的硬件架构高度封闭，作者通过计时实验对这些底层的内存访问路径进行了逆向工程。
社区的反应凸显了这一主题的难度，许多用户指出，对于如此复杂的计算机架构，并没有所谓的“浅显易懂（ELI5）”版本。讨论延伸到了几个具体的技术细分领域，包括：
* **硬件的未来：** 争论人工智能驱动的代码优化是否最终能让硬件设计变得更简单。
* **指令复杂性：** 关于软件是否能真正取代乱序执行等硬件级功能的争论。
* **技术细节：** 深入探讨了 PCIe DMA、BAR（基地址寄存器）配置，以及系统内存与显存之间的数据传输方式。
总的来说，该讨论帖对工程师而言是一个极具深度的“知识黑洞”，因其专业性而备受赞誉，并激发了读者对底层系统编程、内存层级结构和 GPU 架构的研究兴趣。
我只想搜索 I Just Want to Search
16 小时前
现代搜索已从精准检索工具演变为由“相关性”和算法推荐驱动的不可预测系统。曾经，“Google-fu”（指运用特定搜索指令和引号的技巧）是一项核心能力，而如今，各平台经常忽略这些指令，优先展示其指标认为用户“应该”看到的内容，而非用户实际请求的内容。
这种衰退在网页浏览器、电商平台、电子邮件服务和视频平台中表现得尤为明显。用户失去了控制权，被迫应对 SEO 垃圾内容、被无视的搜索指令以及隐藏的过滤器。虽然转向模糊语义匹配可能是为了有效处理海量数据，但这却以牺牲那些仅需要字面结果的资深用户为代价。
作者认为，企业将整体参与度置于实用性之上，致使那些清楚自己需求的用户失去了“手动模式”。解决方案很简单：各平台应提供一个“仅字面匹配”的开关，绕过预测算法，实现可靠、精确的检索。在人工智能驱动内容策展的时代，高性能、用户可控且优先于算法猜测的搜索工具，存在着清晰且未被开发的市场需求。
Hacker News 上的一场讨论探讨了搜索引擎质量的下降，这是由针对 SEO 垃圾信息和低质量内容的无休止对抗所导致的。用户“gtowey”认为，自动化系统在这一“猫鼠游戏”中注定会失败，因为垃圾信息发布者总是会比算法领先一步。
所提出的解决方案是转向人工编辑控制，这将打破操纵循环。尽管谷歌等科技巨头因成本高昂而避免采用这种模式，但作者建议采取类似维基百科的去中心化、志愿者审核模式。虽然并非万无一失，但维基百科的模式已被证明在应对复杂的攻击时具有极强的韧性，为提供更精选、更值得信赖的搜索体验提供了潜在蓝图。
```Hacker News最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交登录通过本地混淆进行代码混淆 (vitalik.eth.limo)由 fbrusch 发布于 11 小时前，29 分 | 隐藏 | 过往 | 收藏 | 1 条评论帮助
__MatrixMan__ 8 小时前 [–]
这是第三部分。如果不先浏览第一部分，我觉得很难弄清楚它在讲什么：https://vitalik.eth.limo/general/2026/06/29/obfuscation1.htm...回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索： ```
Nari Labs 发布了高性能 Qwen3-TTS CustomVoice 实现方案，在单张 NVIDIA H100 SXM 上实现了业内领先的延迟表现与效率。
通过与 vLLM-Omni、SGLang-Omni、VoxServe 及 M* 进行基准测试对比，Nari Labs 证明其系统是唯一能够在每秒 10 次请求（RPS）下，将首音频延迟（TTFA）的 p95 值维持在 50 毫秒以内的方案；在 20 RPS 下，延迟仍保持在 100 毫秒以下。在满负荷运行时，该方案每 100 万字符的成本约为 2 美元，远低于 ElevenLabs（每百万字符 100 美元）和 Cartesia（每百万字符 49 美元）等竞争对手。
核心技术优化包括：
* **统一调度：** 将说话人（Talker）、代码预测器（Code Predictor）和编解码器（Codec）置于单一调度层，在确保批处理效率的同时优先处理紧急的 TTFA 任务。
* **智能执行：** 利用状态缓存解码避免冗余处理，针对固定结构捕获 CUDA 图，并动态调整音频分块大小以平衡速度与稳定性。
* **流式优化：** 实现动态静音修剪与输入流式传输，确保以最快速度输出音频。
Nari Labs 已将其实现方案和基准测试方法开源，旨在为包括图像和视频模型在内的未来实时多模态推理奠定可扩展的基础。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
我们如何将语音合成（TTS）模型的响应时间控制在 50 毫秒以内 (nari-labs.com)
11 点，由 toebee 发布于 44 分钟前 | 隐藏 | 过往 | 收藏 | 1 条评论
帮助
toebee 44 分钟前 [–]
首段音频响应时间（TTFA）对于实时语音应用至关重要。开源实现（如 vLLM-Omni、SGLang-Omni）在生产环境中往往速度较慢，且在追求低延迟时可能会遇到实时播放的问题。我们希望解决这一痛点。
我们对流行的开源 TTS 模型 Qwen3-TTS 进行了优化，在 1 张 H100 上实现了每秒 10 次请求时 34 毫秒的 P95 TTFA。我们开源了该实现和基准测试，并详细介绍了实现方法。
GitHub: https://github.com/nari-labs/nari-qwen3-tts
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索:
AgentSight 是一款零侵入式可观测性工具，利用 **eBPF** 技术在内核层面监控 Linux 系统上的 AI Agent。它无需修改代理代码，即可通过捕获 LLM API 调用、令牌消耗和进程行为，提供全栈可视化能力。 **核心功能：** * **深度监控：** 通过实时 Web 仪表板追踪令牌使用情况、会话健康状况和 LLM 活动。 * **中断检测：** 识别 LLM 错误、上下文溢出和进程崩溃等关键问题。 * **审计与发现：** 自动发现正在运行的 AI Agent，并保存系统级操作的完整日志。 * **无缝集成：** 提供基于 Copilot Shell 的内置自然语言查询功能，并与“Tokenless”集成以可视化成本节约指标。 **要求与部署：** AgentSight 要求 Linux 内核版本 ≥ 5.8，并需 root 权限以运行 eBPF 探针。它通过 `anolisa` CLI 和 systemd 进行管理。虽然 macOS 支持本地会话跟踪分析，但基于 eBPF 的实时可观测性仅限于 Linux 系统。该工具包含强大的安全功能（如基于令牌的仪表板身份验证），并允许通过 `/etc/agentsight/config.json` 进行自定义配置。AgentSight 通过深度、低开销的系统可观测性，为维护 Agent 的可靠性和性能提供了一种统一、自动化的解决方案。
抱歉。
这篇回顾记录了1992年计算机科学家劳伦斯·保尔森（Lawrence Paulson）与莱斯利·兰波特（Leslie Lamport）就后者那篇具有挑衅性的论文《类型被视为有害》（Types Considered Harmful）所进行的合作。兰波特认为，规范语言应当基于无类型集合论，而非类型系统。 起初，保尔森和同行评审人大卫·麦卡利斯特（David McAllester）因兰波特对类型化形式体系理解的缺陷而建议拒稿。然而，编辑安德鲁·阿佩尔（Andrew Appel）坚持发表，促使保尔森与兰波特共同署名，在保留论文精神的同时修正了其中的技术错误。经过漫长且涉及新任、苛刻审稿人的评审过程，该论文最终附带免责声明得以发表。 27年后的今天，作者认为兰波特的论点并未经受住时间的考验。现代类型系统已成为工业级验证不可或缺的工具，而无类型形式体系在符号重载和错误风险增加等实际问题上显得力不从心。保尔森指出，就连兰波特自己的TLA+语言最终也引入了类类型限制。最终，作者总结道，尽管探索集合论符号仍有价值，但类型化系统已在确保可靠规范和验证方面证明了其自身价值。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
我曾与 Leslie Lamport 合著那篇论文 (lawrencecpaulson.github.io)
baruchel 发布于 1 小时前 | 13 点 | 隐藏 | 过往 | 收藏 | 2 条评论 | 帮助
blltprfmnk 8 分钟前 | 下一条 [-]
标题漏掉了原文开头的“如何”二字，这完全改变了含义。
回复
srean 34 分钟前 | 上一条 [-]
> 另一位审稿人 David McAllester 也得出了同样的结论。
是那位提出了 PAC-贝叶斯界（PAC-Bayesian bounds）的 David McAllester 吗？
答：是的。
https://link.springer.com/article/10.1023/A:1007618624809
回复
指导原则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：