浏览器已禁用 JavaScript。请启用 JavaScript 以继续。本网站所需的一部分内容无法加载。这可能是由于浏览器扩展程序、网络问题或浏览器设置所致。请检查您的连接、禁用广告拦截器或尝试使用其他浏览器。
每日HackerNews RSS
抱歉。
请启用 JavaScript 并关闭所有广告拦截器
抱歉。
作者最初因 `musl` 能够构建简单且自包含的 Rust 二进制文件而对其产生兴趣，但在测试后发现了显著的性能问题。与普遍认为 `musl` 仅在极端并发下表现不佳的观点不同，作者发现它在标准的 4 核系统上性能表现极差。
尽管将 `musl` 的默认分配器更换为 `mimalloc` 可以带来一定改善，但仍无法与 `glibc` 持平，速度依然慢了约 26%。进一步调查显示，性能差距不仅源于分配器优化不足，还归咎于 `musl` 核心内存例程的低效。
作者总结认为，虽然 `musl` 对于小型且对性能要求不高的项目尚可接受，但对于高性能应用而言，它就像一把“随时会走火的枪”。因此，作者决定在其对性能敏感的项目 Bifrost 中移除 `musl` 的预构建选项，并指出 `musl` 要么应取消默认分配器，要么应解决其系统性的效率低下问题。
最近关于“如果你在意性能，就不要使用 musl”的 Hacker News 讨论，凸显了注重可移植性的人群与关注执行速度的人群之间的分歧。
musl 的批评者认为，其内存分配器表现不佳，存在全局互斥锁竞争问题，导致多线程应用出现显著瓶颈，从而拖累了整体性能。此外，人们经常指出 musl 对 memcpy 和 memset 等基础例程的实现过于简单，与 glibc 相比会产生可观测的开销。
支持者承认这些缺陷，但坚持认为 musl 在静态链接方面非常便捷，能够简化部署并避免容器环境中的“glibc 依赖地狱”。许多开发者指出，对于他们特定的应用场景（如 I/O 密集型工具），性能损耗通常可以忽略不计。一些人提出了折中方案：利用 musl 的简洁性，同时替换为 mimalloc 等高性能分配器，以缓解最严重的瓶颈。
最终，业界共识认为：虽然 musl 在提升可移植性和减小二进制文件体积方面极具价值，但它通常不适合高并发、对性能要求苛刻的应用，除非配合经过仔细优化的替代方案使用。
中国驻加德满都大使馆针对中尼边境因冰崩岩崩形成的堰塞湖发出预警。该堰塞湖位于边境附近一条支流的上游，目前正在溢流，存在溃坝的重大风险。 尽管两国有关部门正在积极监测情况并进行应急处置，但大使馆指出，危机仍处于关键阶段。官方敦促下游社区保持警惕，密切关注水位变化，并为潜在的紧急情况做好准备。 虽然关于堰塞湖容量的具体细节尚未披露，但此次预警正值尼泊尔拉苏瓦区及周边地区持续发生严重洪涝和滑坡灾害之际。大使馆提醒公众，应仅以官方报告为准，以防虚假信息传播引发不必要的恐慌。
抱歉。
美国将意大利技术集体 Autistici/Inventati 指定为“特别指定的全球恐怖分子”，标志着反恐政策的重大演变。华盛顿并未针对特定个人的暴力行为进行打击，而是将“物质支持”原则应用于数字基础设施提供商。美国指责该组织通过加密通信和托管服务为库尔德工人党（PKK）等暴力团体提供便利，此举释放出信号：那些为极端主义活动提供技术手段的实体，现在也成为了制裁目标。 专家本尼阿米诺·伊尔迪（Beniamino Irdi）指出，其主要影响并非资产冻结，而是“去风险化”。美国的司法管辖权向全球银行和服务提供商施压，要求其切断与该实体的联系，从而在无需意大利或欧盟法院裁决的情况下，将其有效地排斥在数字经济之外。这种转变反映了更广泛的安全范式变化：随着敌对势力日益依赖去中心化和代理模式，情报部门正将重点从肇事者转向为其行动提供便利的数字基础设施。这种方式为自由民主国家带来了一个重大困境：如何在不削弱定义民主社会的法律保障和自由的前提下，缓解安全威胁。
抱歉。
近期一场关于终端用户界面（TUI）的批评引发了 Hacker News 上的热议，这凸显了一个常见的误区：人们往往认为 TUI 仅仅因为是键盘驱动的，就优于图形用户界面（GUI）。作者指出，这并非 GUI 的局限性，而是 GUI 开发者未能优先考虑可访问性的结果。 现代 GUI 框架和设计指南（如 GNOME 等）明确强调，应用程序的每一项操作都应能通过键盘执行。作者认为，GUI 完全可以像 TUI 一样方便使用键盘，甚至效率更高。两者之间的差异不在于技术可行性，而在于开发者对用户体验的重视程度。 在开发自己的 GUI 应用程序 *Klisi* 时，作者发现实现全面的键盘导航既可行又令人欣慰。归根结底，TUI 与 GUI 之间的选择不应受限于输入方式。开发者应致力于提供直观的体验，确保完善的键盘支持是核心功能而非后续补救，以此来赋予用户更多的掌控权。
Hacker News 上的讨论聚焦于键盘驱动界面的重要性，并指出**无障碍与易用性是本质相连的**。
**主要观点包括：**
* **键盘作为通用工具：** 全面的键盘支持不仅是为高级用户准备的，更是关键的无障碍需求。当“Tab”键或导航路径失效时，残障用户往往会完全无法操作。
* **“路缘效应”（Curb Cut Effect）：** 为无障碍设计的功能（如键盘导航）能惠及所有人，包括高级用户、“情境性残障”人士（例如抱着婴儿或鼠标损坏时），以及在受限环境下工作的人。
* **设计缺陷：** 许多现代 GUI 框架（以及基于 Web 的“Electron”应用）出现了倒退，未能提供像 Windows 3.1 等早期系统中曾作为默认标准的键盘导航功能。
* **可发现性与速度：** 主要挑战在于如何在不让用户界面显得杂乱的情况下，让键盘快捷键易于被发现。建议包括使用命令面板、助记符以及统一的标准。
* **“文本基底”：** 许多高级用户认为，由于文本是计算的基础，优先考虑键盘驱动文本操作的工具效率最高；许多人偏好基于终端的界面或“类 Vim”控件，以保持操作的流畅性。
Dactyl 是一个全新的开发平台，旨在弥合大模型生成的代码与高质量原生移动应用之间的鸿沟。与依赖网页视图（Webview）或跨平台妥协的现有“灵感编程”（vibe-coding）方案不同，Dactyl 通过在浏览器中通过 WebAssembly (Wasm) 运行自定义 SwiftUI 引擎，提供了真正的原生体验。
该平台配备了一个模仿 iOS 模拟器的精密预览引擎，无需外部硬件或昂贵的云端串流，即可近乎瞬时地渲染复杂的 SwiftUI 布局。对于 Android 平台，Dactyl 将相同的 Swift 代码编译为原生共享库，并由 Jetpack Compose 宿主调用以渲染真实的 Material Design 组件。
为了确保与苹果不断演进的生态系统保持一致，Dactyl 采用了自动化测试集群。AI 智能体通过逐像素对比、逐帧运动分析以及视觉大模型，持续将引擎输出与真实的 iOS 模拟器进行比对，以修复差异。通过将引擎与应用代码分离并利用动态链接，Dactyl 实现了快速迭代开发，让用户仅需通过描述需求，即可构建并部署精致、具有原生质感的应用程序。
抱歉。
Htmx 4.0.0 已发布 Htmx 4.0
21 小时前
htmx 团队发布了 **htmx 4.0.0**。这是一次重大更新，将该库的内核从 `XMLHttpRequest` 迁移到了现代的 `fetch()` API。虽然面向用户的行为与 2.x 版本基本保持一致，但此次更新带来了三项重大变更： * **显式属性继承：** 属性不再默认继承；用户现在必须在属性后添加 `:inherited` 才能将其应用于子元素。 * **标准化事件：** 事件名称已进行统一清理（例如 `htmx:before:request`），以提高一致性。 * **历史记录变更：** 历史记录支持现在默认为重新获取页面，而不是使用 `localStorage`，从而提高了与第三方库的兼容性。 新功能包括原生的 **Morph Swaps**（由 Idiomorph 提供支持）以及用于高级 DOM 更新的 `<hx-partial>` 标签。此外，htmx 4 引入了多个新扩展和 **hx-live**——一种轻量级、对 HATEOAS 友好的前端脚本解决方案。 为协助迁移，团队提供了一个 CLI 升级工具 (`npx [email protected] upgrade-check`)。为了防止强制升级，htmx 2.x 仍作为 NPM 上的“最新”版本，而 4.0.0 则作为“next”版本提供。升级是可选的，htmx 2.x 将继续获得支持。
**htmx 4.0** 的发布在 Hacker News 上引发了热烈讨论，凸显出该库作为重型 JavaScript 框架的极简主义、服务端驱动替代方案，依然广受欢迎。
社区反应的主要观点如下：
* **理念吸引力：** 用户青睐 htmx 的简洁性及其“不拘一格”的社区精神，这与典型的企业级技术文化形成了鲜明对比。它常与 Go、SQLite 和 Django 等技术栈结合，无需复杂的构建步骤即可创建高响应速度的应用程序。
* **版本跳跃：** 开发者跳过了 3.0 版本，这是一个玩笑，旨在信守此前关于“绝不会发布破坏性的 3.0 版本”的承诺。
* **大语言模型（LLM）因素：** 一个主要的争论焦点在于 LLM 是否降低了对 htmx 的需求。尽管有人认为 LLM 让编写复杂的 JavaScript 变得更容易，但许多开发者认为 htmx 依然更胜一筹，因为它减少了代码的“接触面”，从而产出更易于维护、测试且 Bug 更少的成果。
* **总体情绪：** 虽然一些开发者更偏好全栈单页应用（如 Angular 或 React）的掌控感，但对于那些希望避免不必要前端复杂性的用户而言，htmx 依然是社区的“宠儿”，许多用户称赞它令人耳目一新。
在 Mac Studio 上本地运行 Qwen3.8 27B：真实性能数据 Run Qwen3.8 27B locally: real numbers from my Mac Studio
21 小时前
Qwen3.8 27B 模型已成为本地 AI 任务中的佼佼者。它不再仅仅是“玩具”，而是成为了处理摘要 RSS 订阅、整理扫描文档等日常事务时可靠且私密的助手。凭借 26.2 万 token 的上下文窗口和多模态能力，它能高效处理复杂的智能体任务。
在 Mac Studio M3 Ultra 上的基准测试显示，虽然 Qwen3.8 的生成速度约为上一代产品的一半（14 tok/s 对比 28.6 tok/s），但其效率显著提高，能够给出更简洁的回答，从而使实际“挂钟”完成时间保持在可比水平。
**硬件核心要点：**
* **需求：** 建议使用 32GB 内存的系统以实现高质量的 Q4 量化。16GB 用户可以运行 Q2 量化版本，而 1-bit 量化仅限于琐事，无法可靠地处理智能体任务。
* **性能：** 新的混合注意力架构目前缺乏运行时优化，预计随着软件更新，性能会有所提升。
* **易用性：** 通过 Ollama 运行该模型非常简单，只需确保用户更新至最新版本的 Ollama 或 `llama.cpp`，以支持新的“qwen35”架构。
总之，Qwen3.8 代表了迈向高效、私密、自托管本地 AI 的重要转变。
这篇 Hacker News 讨论帖探讨了在本地运行 **Qwen3.8-27B** 模型的性能与可行性。起因是一篇博文声称该模型在 Mac Studio 上的运行效果不佳。
社区的主要观点如下：
* **性能差异：** 许多用户认为原博文存在漏洞，指出 Qwen 3.8 的表现应与 3.6 类似。运行速度缓慢可能是由于配置不当（例如缺少多 token 预测/MTP 头，或推理引擎优化不足），而非硬件限制所致。
* **硬件之争：** 一些用户捍卫 Apple Silicon（M3/M4 Max/Ultra）在统一内存和隐私方面的优势；而使用 NVIDIA RTX 5090 或旧款高性价比数据中心 GPU（如 AMD Instinct 卡）的发烧友则表示，其每秒生成的 token 数量（100–300+ tps）显著更高。
* **隐私与实用性：** 本地推理的主要动机依然是数据隐私与所有权，特别是对于那些拥有敏感个人或专业信息、无法信任云端 API 的用户而言。
* **可用性：** 用户对“可接受的”速度存在争议；虽然 14 tps 被认为乏味，但许多人认为 50–60 tps 是理想速度。另一些人则认为，对于智能体（agentic）工作流来说，模型的智能程度和大上下文窗口的处理能力比单纯的速度更为重要。
如今，仅仅是关于漏洞的传闻，就足以让人发现可利用的攻击点。 Just the rumour of a bug is enough to find an exploit these days
21 小时前
自动化大语言模型（LLM）驱动的漏洞利用生成技术的出现，从根本上打破了传统的开源安全模式。维护者们现在面临一个现实：漏洞被利用的平均时间（MTTE）已快于软件修复与发布的时间。作为一名 OCaml 维护者，作者观察到在提交安全补丁请求（PR）后的几分钟内，服务器就遭到了实时探测。这证实了自动化智能体正在实时监控公共代码库，以迅速将漏洞武器化。
由于安全禁运和保密措施在 AI 驱动的搜索面前已不再有效，作者认为开源项目的“漏洞经济学”必须转型。鉴于维护者缺乏科技巨头所拥有的资源和前沿模型访问权限，社区必须转向：
* **持续部署：** 从缓慢的手动发布周期转向类似浏览器补丁更新的快速、自动化更新。
* **虚拟补丁：** 实施协议层防御，以便在开发出经过回归测试的完整补丁期间，能够即时部署以缓解漏洞利用。
* **基础设施改进：** 建立更好的跨生态系统包管理和“信任网”系统，以促进维护者之间的安全沟通。
最终，重点必须从被动的人工分类转向模型辅助、工具验证的工作流程，将持久性修复置于机械且易受攻击的手动流程之上。
最近 Hacker News 上关于文章《如今仅仅是漏洞传闻就足以找到利用途径》的讨论，凸显了人工智能驱动下软件安全领域的剧烈转变。
开源项目维护者们表示，漏洞披露的数量出现了惊人的激增——一些人甚至观察到了 10 倍的增长。AI 智能体使得仅凭极少的线索就能轻松识别、验证并编写出漏洞利用程序。这种自动化将发现漏洞的时间周期从数周压缩到了短短几小时，迫使维护者陷入了疲于奔命的分类与修补循环中。
讨论的主要结论包括：
* **AI 的优势：** 人工智能有效地普及了漏洞研究，即便是低水平的攻击者也能扫描并利用大型项目。
* **维护者倦怠：** 漏洞报告的数量耗尽了资源，导致一些人开始考虑进行“静默”修复（即在不发布公开文档的情况下修补漏洞），以防止攻击者在用户更新之前通过逆向工程发现漏洞。
* **“意愿”与“资源”之争：** 参与者们争论软件质量下降究竟是因为管理层缺乏“意愿”，还是仅仅受限于各方优先事项冲突的经济现实。
* **系统性风险：** 随着漏洞利用开发变得廉价且自动化，人们日益担忧现有的部署模式以及行业当前对安全的漠视已难以为继。