Pixel 11 Pro Fold 兼具强劲性能与便捷体验。它搭载全新的 Tensor G6 芯片和 16GB 运行内存，为 Gemini 智能功能提供深度优化，带来流畅的操作体验。该设备在充电方面进行了重大升级，支持 30W 有线充电（30 分钟可充至 50%）及 25W Qi2.2 无线充电，并配备可靠的 24 小时续航电池。 该设备的一大创新亮点是专为聋人社区打造的无障碍功能。得益于与手语使用者的合作，其双屏免提设计能够完美支持美国手语 (ASL)。用户只需向外屏摄像头打手语，翻译结果便会实时显示在外屏上；此外，全新的“手语转文字”功能已直接集成至“实时转录”和 Gboard 输入法中。无论是用于办公生产力还是无障碍沟通，Pixel 11 Pro Fold 都能助您时刻保持连接，赋能日常生活。
每日HackerNews RSS
Google Pixel 11 Pro Fold 的发布在 Hacker News 上反响平平，许多用户对此次升级的价值提出了质疑。
批评者主要对硬件规格感到失望，特别是与竞争对手相比毫无增长的电池容量、Pro 机型缩水至 12GB 的运行内存，以及减少的 AI 订阅权益。尽管一些用户认可其增加了 IP68 级防尘防水，但其他人认为相机硬件依然停滞不前。
讨论中还显露出一种“科技疲劳”感。用户指出，现代智能手机已经达到了“够用就好”的阶段，使得年度升级显得越来越没必要。一些人指出新推出的“HiLight”通知功能具有讽刺意味，因为它只是将过去 Android 已有的功能重新包装成了创新。最终，舆论普遍认为 Pixel 11 Pro Fold 缺乏足够的升级理由；多位评论者表示，他们宁愿继续使用前代产品，或者对这种渐进式的手机发布已逐渐失去兴趣。
以下是所提供内容的中文摘要：
Norbert Landsteiner 发布了“Commodore 8 位磁盘映像工具集”，这是一套专为 Commodore PET 及相关 8 位系统设计的网页端工具。作为更新版 PET 2001 模拟器的一部分，该工具集提供了一个直观的界面，用于处理 Commodore 磁盘映像（D64、D80、D82）。
该工具集包含两个主要组件：
1. **磁盘映像检查器 (Disk Image Inspector)：** 一个点击式工具，允许用户浏览磁盘结构（包括 BAM、目录和数据块）并导出单个文件。
2. **D64 生成器 (D64 Composer)：** 一个向导工具，支持用户通过添加、重命名和重新排列文件来创建及自定义 35 轨的 D64 磁盘映像。
除软件发布外，文章还深入探讨了 Commodore 磁盘架构的技术细节，涵盖了轨道与扇区分配、块可用性映射表 (BAM)、目录条目格式以及 PRG、SEQ 和 REL（相对）文件的运行机制。作者强调，这项工作完全由人工编写完成，旨在拒绝使用现代人工智能工具，以确保技术准确性并维护历史计算知识的完整性。
抱歉。
**hax** 是一款轻量级、极简的 AI 命令行工具，专为偏好终端工作流的开发者设计。它以单一原生 C 二进制文件编写，资源占用极低，非常适合在不占用过多系统内存的情况下运行本地大语言模型（LLM）。 主要功能包括： * **无缝集成：** 自动发现本地模型，并支持 OpenAI、Anthropic 和 llama.cpp 等主流提供商。 * **终端友好：** 遵循标准终端行为，输出整洁，支持滚动回看，并采用流式 Markdown 显示。 * **透明度：** 提供可查阅的会话记录视图（Ctrl+T）和详细的网络协议追踪，以便审计模型交互。 * **Unix 哲学：** 遵循传统工具标准，使用 XDG 路径、纯文本配置和子进程组合，而非复杂的插件系统。 **hax** 有意避开了 IDE 面板或应用市场生态等臃肿功能，专注于打造一个稳健、透明且高性能的代理工具。它适用于 macOS 和 Linux（可通过 Homebrew 或静态二进制文件安装），并为交互式会话、一次性提示词和会话恢复提供了简洁的接口。无论你是为了审计 AI 行为还是管理有限的系统资源，hax 都为现代 AI 集成提供了一种可靠的“老派”方案。
Hacker News 的用户正在讨论 **Hax**，这是一款全新的极简主义终端原生编码代理，完全使用 C 语言编写。该工具由 OleksandrC 开发，凭借其相较于基于 JavaScript 或 Python 的大型替代方案所具备的速度优势和极低的资源占用，获得了广泛关注。
讨论中的要点包括：
* **性能：** 用户称赞 Hax 运行速度快、易于构建，且保持了“令人耳目一新”的极简特性。多位用户反馈已成功将其与本地大模型（通过 llama.cpp）以及 DeepSeek 等自定义 API 提供商配合使用，且成本极低。
* **设计选择：** 虽然有人质疑为何在一个现代项目中使用 C 语言，但开发者解释称，C 语言是实现最小资源占用的最有效语言，也是他最熟悉的语言。支持者则强调了 C 语言在不同硬件架构间无与伦比的可移植性。
* **实用性：** Hax 可以处理读取、编辑和执行 Bash 命令等核心任务。用户指出，尽管一些高级模型是针对特定代理工具集进行微调的，但它们通常能很好地适应 Hax 的简化指令结构。
* **市场反响：** 该项目作为一种高效、务实的替代方案，受到了广泛欢迎。用户正积极在 GitHub 仓库贡献反馈和错误报告。
请启用 JavaScript 并关闭所有广告拦截器
德国倡导组织 HateAid 已针对 Meta 的 AI 智能眼镜向相关部门提起刑事控诉。该组织认为，这些眼镜违反了德国《电信数字服务数据保护法》（TDDDG）第 8 条的规定；该法律禁止分发旨在秘密记录他人且具有伪装性质的监控设备。
HateAid 主张，由于这些眼镜外观与日常眼镜无异，无法像智能手机或传统相机那样向公众提供充分的告知。尽管 Meta 在眼镜上设置了用于提示录像的微型 LED 指示灯，但批评者认为该指示灯极易被遮挡或被忽视，不足以保障个人隐私。
这场争议凸显了人们对可穿戴技术“设计即监控”本质的广泛担忧。反对者指出，此类设备允许用户进行隐蔽的视频录制，随后上传至 Meta 的服务器进行处理。批评者认为，公众不应被迫接受陌生人在公共空间采集数据，且这些设备违背了《通用数据保护条例》（GDPR）通常要求的清晰、明确的同意标准。此案备受关注，或将成为欧洲法律如何处理隐私权、可穿戴 AI 与隐蔽录制之间冲突的潜在判例。
Grok 4.6 Grok 4.6
17 小时前
因检测到滥用流量模式而被拦截
x.AI 发布 **Grok 4.6** 后，在 Hacker News 上引发了激烈讨论。用户普遍称赞该模型令人印象深刻的基准测试表现，并指出其以低于许多竞争对手的价格提供了“Fable 级”的智能水平。许多贡献者将其视为 OpenAI 和 Anthropic 等大型实验室强有力的竞争者。
技术讨论集中在业内人工智能能力快速趋同的现象上。评论者认为，这种水平相当是由算力的广泛普及、研究技术的共享以及合成强化学习任务的使用所驱动的，而非单一公司所拥有的“护城河”。
然而，舆论呈现出严重的极化。虽然一些用户对其在编程和设计方面的功能改进感到兴奋，但另一些用户则明确表示拒绝使用 Grok，原因是担心埃隆·马斯克的介入、模型的对齐方式以及内容安全方面被报道的问题。关于“虚假民意（astroturfing）”和政治偏见的指控凸显了人们对该品牌的怀疑，部分用户将道德考量置于模型性能之上。
本文介绍了解决 $n$ 维格中最短向量问题（SVP）的重大进展。作者提出了一种随机算法，改进了此前 $2^{n+o(n)}$ 的最优复杂度，在经典计算下实现了 $2^{0.6039n+o(n)}$ 的时间复杂度，在量子计算下实现了 $2^{0.5411n+o(n)}$ 的时间复杂度，且空间复杂度为 $2^{0.5n+o(n)}$。 其核心创新点在于利用了周期性高斯函数在半最短向量处的黑塞矩阵（Hessian）。具体而言，在 $v/2$ 处（其中 $v$ 为最短向量），黑塞矩阵表现出一个与 $v$ 紧密对齐的特征向量。通过利用离散高斯样本来估计 $\mathcal{L}/2\mathcal{L}$ 中各奇偶类下的黑塞矩阵，该算法能够识别出最短向量所在的类，并随后通过有界距离解码算法将其恢复。作者通过随机子格陪集和先进的采样技术进一步优化了该过程，这些方法在格密码研究中可能具有更广泛的应用价值。这些改进代表了在提高 SVP 计算效率方面迈出的重要一步。
这篇 Hacker News 讨论聚焦于一篇关于解决最短向量问题（SVP）的新研究论文，该算法的运行时间为 $2^{0.6039n}$。
讨论区初期主要关注标题的格式问题，特别是如何在纯文本平台上呈现 LaTeX 风格的符号。评论者们争论了表示 $2^{0.6039n}$ 以及包含 $o(n)$ 符号的最佳方式。
在内容层面，用户讨论了这一进展对密码学的影响。一个关键问题是，这一进展是否会威胁到 Falcon 等后量子签名方案的安全性。专家们指出，尽管该论文改进了 SVP 的可证明界限，但它与目前设定密码学安全参数时所采用的“最先进”启发式假设仍有距离，这些启发式假设通常远低于这些可证明的界限。
最后，讨论还涉及了人工智能在学术研究中的作用。尽管参与者对作者的“AI 使用披露”持赞赏态度，但一些人对论文的实际效用表示怀疑。批评者认为，除非该理论有代码支持，并能与 `fplll` 等现有工具进行基准测试对比，否则尚不清楚该方法是否具有实际的密码学应用价值，还是仅仅是一个理论成果。
Qwen3.8 是 Qwen 开源模型家族中最新且最先进的版本，其中包括旗舰模型 Qwen3.8-Max。该模型基于 Qwen3.5 架构构建，参数量达 2.4T（激活参数 95B），在编程、研究、专业工作以及长视野智能体任务方面均有显著提升。 **核心功能：** * **增强的智能体执行能力：** 改进了自主规划和反馈处理机制，可可靠地完成多步骤任务。 * **超长上下文：** 支持默认 1M token 的上下文长度。 * **推理控制：** 引入 `reasoning_effort`（低/中/极高）以调节推理深度，并支持 `preserve_thinking` 以保留推理过程上下文。 * **部署：** 兼容 vLLM、SGLang 和 TokenSpeed 等主流推理框架。如需托管基础设施，可使用官方 Qwen Cloud API。 **模型详情：** * **架构：** 混合专家模型 (MoE) 结合多 token 预测 (MTP)。 * **使用方式：** 专为纯文本输入设计，并强制开启“思考”模式。 * **性能：** 基准测试显示其在软件工程 (SWE-bench)、智能体工作流和通用推理任务中均具备行业领先能力。 为获得最佳效果，建议用户使用推荐的采样参数（例如 `temperature=1.0`，`top_p=0.95`），并为内部推理过程和最终输出预留足够的 token 限制。
近期发布的 **Qwen3.8-2.4T-A95B** 在 Hacker News 上引发了热烈讨论。作为一个拥有 2.4 万亿参数的超大规模模型，它正被拿来与 Opus 4.8 和 Fable 5 等顶级模型进行对比。
**关键点：**
* **性能与获取：** 尽管该模型的性能备受推崇，但其开源权重版本排除了视觉功能，并限制了默认上下文长度。爱好者们已开始讨论潜在的社区解决方案，例如“外挂”视觉模块。
* **硬件要求：** 该模型体量极大，BF16 权重约 4.9TB，FP8 版本也需要极高的内存。虽然有用户建议通过 1-bit 量化使其在高端发烧友设备上运行，但其他人警告称，相较于更小、更高效的模型，它对于大多数家庭实验室来说仍不切实际。
* **市场背景：** 人们将其与 Kimi k3（2.8 万亿参数）及 DeepSeek 模型进行了对比。用户还指出，预计很快会发布更易于使用的 Qwen3.8-27B 版本。
* **社区情绪：** 社区观点不一；虽然该模型的原始智能表现令人印象深刻，但其极高的资源需求以及开源版本缺乏“开箱即用”的功能，为部署带来了显著障碍。
uBlock Origin 放弃了在 Facebook 上拦截广告的抗争 uBlock Origin Is Giving Up the Fight to Keep Ads Off Facebook
17 小时前
请启用 JavaScript 和 Cookie 以继续。
最近的一场 Hacker News 讨论凸显了 uBlock Origin 在维护 Facebook 广告拦截规则时所面临的挑战。用户反映，Meta 频繁更改网站的 DOM 结构以绕过这些拦截器，导致一些开发者因这种持续且耗费资源的“猫鼠游戏”而放弃尝试。
该讨论帖引发了关于在 Facebook 等平台上进行广告拦截是否可行的广泛争论。一些用户认为拦截无效，因为该平台的核心商业模式就是依赖广告投放；另一些人则建议，如果用户真的想要无广告体验，就应该彻底停止使用该服务。针对未来的绕过方案，有人提出了技术性建议，例如利用 OCR 和大语言模型从视觉数据中剔除广告，而非直接针对底层代码进行对抗。
评论者还提到了 Facebook 的社会影响，指出许多本地企业、应急服务和社区组织现在都依赖该平台，这使得许多人难以做到“直接离开”。归根结底，这场讨论反映出人们对一种共同的挫败感：在那些不惜一切代价优先考虑广告收入的平台面前，想要掌控个人数字体验变得越来越困难。
GiveCampus 是教育机构领先的筹款平台，致力于让教育变得更加普及和实惠。公司拥有 1,300 多家合作伙伴，目标是促成 1,000 亿美元的慈善捐赠。作为一家由 Y Combinator 支持的行业领导者，公司目前处于盈利状态，且发展迅速。 GiveCampus 现诚聘一位**技术工程开发经理**加入其远程优先的团队。该职位向工程副总裁汇报，负责管理 2 个以上的工程小组（包括技术负责人和工程师），监督产品交付并推动员工的职业发展。 **核心要求：** * 10 年以上实践开发经验，并在敏捷环境下担任过 3 年以上的管理职位。 * 精通 Ruby、Python 或 JavaScript/Node.js，具备 MVC 框架、现代前端框架（React/Vue）以及 SQL 数据库的使用经验。 * 具备平衡人员管理与技术领导力的成熟能力，包括架构设计、代码审查（PR reviews）和辅导 mentorship。 * 出色的沟通能力，能够与产品经理及高层领导保持协作。 该职位提供在一家使命驱动型平台工作的机会，公司目前正投入 1 亿美元用于人工智能开发。GiveCampus 崇尚包容性的文化，并鼓励即使不完全符合所有要求的申请者也积极投递简历。
抱歉。
竞技场分配器（Arena Allocators）与动态数组（ArrayLists）并不兼容。 ArenaAllocators don't play nicely with ArrayLists
18 小时前
这篇文章解释了为什么 `ArenaAllocator.free()` 在大多数实际场景中基本等同于“空操作”（no-op）。 若要通过 Arena 回收内存，被释放的块必须是最近一次分配的内存，且位于 Arena 当前的内部节点上。由于这些内部条件很难同时满足，调用 `free` 通常无法真正归还内存。 这一问题在 `ArrayList` 等动态结构中表现最为明显。当 `ArrayList` 扩容时，它会分配新内存、拷贝现有数据并释放旧块。由于新块变成了最近一次的分配，旧块无法被 Arena 回收。这一过程会导致严重的内存膨胀，其占用空间可能达到实际需求的三倍。 为缓解这一问题，开发者应： 1. **预设集合容量：** 使用 `initCapacity` 或 `ensureTotalCapacityPrecise` 来避免不必要的重新分配。 2. **减少交替分配：** 在扩容集合时，尽量避免进行其他内存分配，以提高“原地扩容”操作发生的概率。 尽管这些做法对任何分配器都有益，但在使用 `ArenaAllocator` 时，它们对于防止内存失控增长至关重要。