每日HackerNews RSS
FFmpeg 9.0
92 天前
由于对 Wordle 官方统计数据缺乏详细分析感到不满，作者利用四年来每日的 WhatsApp 游戏结果，对自己的个人游戏表现进行了深入研究。通过用 Python 脚本解析导出的聊天记录，他们绕过了 Wordle 服务器端追踪的局限性，构建了一份全面且独立的个人游戏历史记录。
对自 2022 年 1 月以来 1,552 场游戏的分析显示，其胜率为 99.4%，且游戏难度随时间推移呈明显的上升趋势。尽管作者的日常习惯（如清晨游玩、使用固定的开局词）保持不变，但平均每局的猜测次数却稳步增加，这很可能是因为常用词汇已被耗尽。数据还推翻了几个假设：在“繁忙”的早晨玩游戏并不会影响表现，且失败也不会对后续游戏产生负面影响。
最终，该项目将一个简单的日常习惯转化为了有意义的数据集。通过掌控自己的“Wordle 遗产”，作者获得了官方应用程序无法提供的关于自身作为玩家进化的细致洞察。
最近一则 Hacker News 的讨论聚焦于通过个人数据收集来追踪长期 Wordle 表现的做法。用户们分享了他们分析多年趋势的方法，这些方法往往超越了官方 Wordle Bot 的统计数据，转而通过创建自定义电子表格和可视化图表来进行分析。
参与者讨论了“运气”与“技巧”指标的细微差别，并指出个人表现往往与全球平均水平相关。其他人则分享了他们自己为记录游戏历史而制作的 GitHub 风格热力图。该讨论串还涉及了个人数据项目所面临的技术挑战，例如维护网页可视化图表的难度，以及旧博客平台上广告的干扰问题。总体而言，该社区展现了对数据驱动的自我反思的共同兴趣，以及为追踪日常习惯构建自定义界面的渴望。
在孤岛中进行“氛围编码”（Vibe coding）会产生技术债务和难以管理的 PR。**ADLC 团队技能**（十二要素智能软件开发生命周期的一个开源组件）通过为工程团队提供共享的、版本控制的**认知层**，取代了零散的个人提示词工程。 通过整合团队章程、产品策略 (PDR)、架构标准 (ADR) 和评估基准，ADLC 将 AI 智能体从孤立的猜测者转变为负责任的团队成员。 **核心功能：** * **团队 AI 指令：** 一个基于 Git 的中央仓库，在会话开始时自动将团队上下文整合进智能体的系统提示词中。 * **规范驱动的工作流：** 通过 `mission-brief`，团队从对话式提示转向基于契约的执行，遵循 `规范 → 规划 → 实现` 的闭环。 * **治理与评估：** 实施“验证优先”的开发模式；在人工审查之前，通过自动化的 LLM 评判和快速检查，根据业务风险对代码进行验证。 * **构建即删除（Build-to-Delete）：** 一个系统的反馈循环，随着模型能力的提升，自动剔除过时的规则。 * **通用编排：** 与供应商无关，开箱即用，支持 Claude Code、Cursor、Copilot 等工具。 ADLC 使团队能够“调试规范，而不只是调试代码”，从而确保整个组织内 AI 工程的一致性、可追溯性和可扩展性。
关于 `tikalk/adlc-team-skills` 代码库的 Hacker News 讨论中出现了紧急警告，称该项目已被恶意软件入侵。用户反馈称，最近的一次提交添加了恶意文件，旨在 VS Code 或 Claude 会话中自动运行。据报道，该恶意负载会尝试对系统进行指纹识别，并窃取敏感凭据，包括 AWS 密钥、GitHub/npm 令牌、Kubernetes 机密以及 HashiCorp Vault 中的内容。强烈建议用户**不要**安装或打开该代码库；如果已经操作过，请立即轮换凭据。
除了安全威胁外，此次讨论还凸显了人们对“代理技能”（agent skills）和冗余系统提示词（system prompts）的广泛怀疑。许多开发者认为，将大量背景信息和指令塞入 AI 代理会导致“巫术式”编码、增加令牌成本并降低性能。评论者建议，与其使用复杂的代理防御机制，团队应依赖代码检查器（linters）和静态分析器等确定性工具来强制执行编码标准。普遍的共识是，AI 生成的项目文档往往难以阅读，团队应优先考虑人工编写的文档以及简单、可重复的工作流程，而非复杂的代理设置。
这份摘要评估了遵循“简洁代码”（Clean Code）准则（如多态、短函数和面向对象封装）所带来的性能成本。作者通过将这些“简洁”实现与传统的面向数据方法进行对比，并使用标准的形状计算示例，证明了行业内的通用做法可能会导致显著的运行时性能下降。 尽管“简洁代码”的倡导者认为这些规则能提高可维护性，但作者指出，遵循这些规则——特别是用类层次结构和虚函数调用来取代高效的数据结构和分支语句——引入了不必要的间接性。这些模式阻碍了编译器进行有效的优化，导致性能比面向数据的替代方案慢 10 到 25 倍。 最终，作者认为这些架构选择以微不足道的可读性提升为代价，牺牲了十多年来的硬件进化成果。文章得出结论，由于这些方法论，软件性能被不必要地降低了。作者建议，虽然代码组织很重要，但开发人员必须拒绝那些对编译器隐藏数据结构和逻辑的“简洁”规则，因为其速度成本高昂，难以证明其合理性。
文章《整洁代码，性能糟糕》（Clean Code, Horrible Performance）引发了关于“整洁代码”原则与系统性能之间权衡的激烈争论。
批评者认为，该书推崇对规则的教条式遵循——例如过度的函数拆分、多态和僵化的抽象——这往往会掩盖逻辑、增加认知负荷，并因缓存未命中和不必要的间接调用引入显著的性能开销。许多开发者认为，这些“整洁代码”准则往往是在真空状态下应用的，忽略了硬件架构和特定领域复杂性的现实。
拥护者或态度更温和的人士则建议，这些原则应被视为启发式方法而非绝对定律。他们主张性能与可维护性并非相互排斥；相反，目标应该是编写出高性能的“简单”代码，开发者应运用“工程判断力”来选择何时优先考虑灵活性，何时优先考虑效率。
归根结底，这场讨论反映了人们对盲目照搬（cargo-culting）编程模式的广泛不满。各方达成共识：最有效的方法是编写尽可能简单的代码，仅在必要时进行优化，并意识到若不顾语境盲目遵循任何方法论，往往会导致软件既无性能也难维护。
1582年，天主教世界从儒略历过渡到格里高利历，以纠正长久以来的历法偏差。为使两个系统对齐，10月5日至10月14日这十天被正式从历史中删除。因此，在格里高利历中，这些日期并不存在。 本文探讨了现代编程语言如何处理这些“不存在”的日期。Ruby 能正确拒绝创建该时段的格里高利历日期，但 Python 和 Perl 均未能将其标记为无效，允许程序员实例化这些不可能存在的日期。 作者以此案例强调了日期和时间实现中精确性的重要性。他指出，虽然 `ncal` 等工具试图考虑不同地区采用格里高利历的历史差异，但对于软件开发者而言，实现完美的历史准确性仍然是一项复杂的挑战。
本次讨论探讨了因从儒略历转向格里历所导致的“不存在”日期这一复杂问题。核心技术结论是：大多数编程库使用**前推格里历（proleptic Gregorian calendar）**，即默认将现行的格里历规则无限向过去延伸。这种做法简化了计算，但对历史学家和数据库工程师而言却产生了逻辑上的不一致，因为它忽略了各国实施历法改革的具体“过渡日期”（例如天主教欧洲为 1582 年，英国及美国为 1752 年）。
辩论中的关键点包括：
* **表示误差：** 简单地跳过日期（正如格里历改革所做的那样）会使日期运算变得困难。有人建议使用在特定历史节点拼接儒略历和格里历规则的“复合历法”。
* **“纪元”解决方案：** 专家强调，内部日期时间处理应依赖明确的数字时间戳（如 Unix 时间戳），仅在面向用户的输出时才使用特定历法的逻辑。
* **背景至关重要：** 由于全球各地的采纳日期不同，历史准确性不仅取决于日期本身，还需要了解文档的地理和法律背景。
综上所述，尽管前推格里历是现代软件的标准，但将其应用于历史事件时，它仍然是一个“虚构”的框架。
```rust use std::collections::HashMap; enum Data<K, V> { Value(V), KeyValue(K, V), } fn main() { let data = vec![ Data::KeyValue("Steve", 10), Data::Value(20), Data::KeyValue("Bill", 30), Data::Value(40), ]; let map = data .into_iter() // 模式匹配与解构 .map(|item| match item { Data::KeyValue(k, v) => { println!("{k}: {v}"); (k.to_string(), v) } Data::Value(v) => { println!("unknown: {v}"); ("unknown".to_string(), v) } }) // 将项累加到 map 中 .fold(HashMap::new(), |mut map, (key, value)| { map.entry(key) .and_modify(|existing| *existing += value) .or_insert(value); map }); println!("Map: {:?}", map); // Map: {"unknown": 60, "Bill": 30, "Steve": 10} } ```
在这篇2012年的文章中，作者伊恩·利尔蒙斯（Iain Learmonth）讲述了他被困在故障公寓电梯里的惊魂经历。尽管他向阿伯丁市议会缴纳了维护费，但利尔蒙斯发现电梯的警报按钮形同虚设，只会发出声响，却无法通知紧急服务部门或大楼管理处。 被困在屏蔽信号的金属箱里，利尔蒙斯在移动网络信号差和社交媒体求助失败的困境中挣扎。然而，当电梯运行至他家Wi-Fi的覆盖范围时，他成功利用 **mosh**（移动终端）连接到了 SDF MetaArray。由于 mosh 是为处理高丢包率而设计的，它使他能够通过终端发送电子邮件，从而促使消防队赶到现场。 尽管电梯在救援人员被召唤时又自行恢复了工作，但这番折磨还是让利尔蒙斯对大楼的基础设施失去了信任。他在文章结尾幽默地写道，他计划增强家里的Wi-Fi信号，以确保如果再次被困，至少还有一种可靠的方式可以寻求帮助。
2026年8月4日，一起重大供应链攻击事件导致多个常用 npm 包（包括 `keyv`、`flat-cache` 和 `file-entry-cache`）的关键维护者 GitHub 账户被攻破。攻击者通过直接向主分支推送恶意代码，发布了带有有效来源签名（provenance signatures）的受损版本，影响了超过 868 个软件包，这些软件包的月下载量总计达数十亿次。 此次攻击表现为一种自我传播的蠕虫病毒。一旦受害者运行 `npm install`，一个经过混淆的投放脚本（`setup.mjs`）就会执行并安装 Bun 运行时，随后运行有效载荷（`Math_Symbol.js`）。该有效载荷旨在积极窃取敏感数据，包括： * **令牌与密钥：** npm、GitHub、AWS、Stripe、Slack 和 HashiCorp Vault 的凭据。 * **基础设施访问权限：** Kubernetes 机密信息和本地环境变量。 * **系统文件：** SSH 密钥、私钥、`.env` 文件和 VPN 配置。 该蠕虫还会针对其他维护者进行感染扩散。强烈建议用户检查其依赖项、执行安全扫描，并对这一针对软件供应链的自动化、高影响威胁保持警惕。
一项被称为“Shai-Hulud”的活跃供应链攻击已波及超过 2,000 个 NPM 软件包，影响了每月数十亿次的安装。该恶意软件利用 `preinstall` 脚本执行一个经过高度混淆的释放程序（`setup.mjs`），进而下载并运行恶意负载（`Math_Symbol.js`）。此负载旨在窃取敏感的环境密钥，通过公开的 GitHub 仓库泄露这些数据，并进一步感染其他开发者的机器。
此次攻击在 Hacker News 上引发了关于软件安全的热烈讨论，讨论的主要要点包括：
* **缓解策略：** 专家建议实施“依赖冷却期”（在采用新版本前等待几天）、使用不具备发布权限的隔离 CI/CD 工作流，以及禁用自动依赖更新。
* **系统性弱点：** 评论者强调了安装过程中执行任意代码的危险，以及 JavaScript 生态系统中过度依赖所固有的风险。
* **安全工具：** 讨论强调了纵深防御的重要性，提倡使用诸如用于密钥注入的本地代理、静态/动态分析工具（如 Packj），以及严格隔离构建与测试环境。
* **注册中心责任：** 人们对 NPM 和 GitHub 等主要注册中心仍未针对此类广泛的自动化攻击实施更强大、更主动的检测表示强烈不满。
Homebench – 测试本地大模型在速度、内存及质量方面的表现 Homebench – Benchmark local LLMs for speed, memory, and quality
92 天前
**homebench** 是一款零配置、以本地优先为核心的工具，旨在您的个人硬件上对大语言模型（LLM）进行基准测试。它填补了单纯的速度测试与复杂评估框架之间的空白，并提供了一个实时终端用户界面（TUI），以便从质量、速度和内存占用等方面对模型进行对比。
### **主要功能**
* **统一基准测试：** 自动发现来自 Ollama、LM Studio、llama.cpp、vLLM 或任何兼容 OpenAI 协议服务器的模型。
* **综合指标：** 测量每秒生成 Token 数（tokens/sec）、首字延迟（TTFT）以及内存占用情况。
* **质量评估套件：** 包含 31 个确定性任务，涵盖数学、推理和代码编写。可选的“LLM 裁判”模式可用于评估开放式任务。
* **硬件分析：** 提供 `fit` 命令，根据您的内存/显存（RAM/VRAM）容量评估哪些模型适合在您的系统上运行。
* **开发者友好：** 功能包括自动保存结果历史、运行结果差异对比、批量吞吐量测试，并支持自定义任务包（JSON/YAML）。
### **入门指南**
通过 pip 安装：`pip install homebench`
**快速使用：**
* `homebench`：运行快速默认基准测试。
* `homebench --all --full`：对所有模型进行全面的基准测试。
* `homebench fit`：检查哪些模型适合您的特定硬件。
`homebench` 是开源的，要求 Python 3.9+ 环境，能够为优化您的本地 LLM 设置提供即时、可操作的数据。
在多线程编程中，顺序锁（sequence locks）提供了一种非阻塞锁的替代方案，但它存在一个关键缺陷：在并发访问期间复制非原子数据会导致 Rust 和 C++ 中的未定义行为（UB）。检测到竞争条件并不等同于防止复制过程中发生的非法内存访问。
为了解决这个问题，**iceoryx2** 库引入了 `ByteAtomic`，这是一个能够实现字节级原子读写操作的封装器。它通过确保内存复制是逐字节进行而非作为单一非原子单元执行，从而避免了未定义行为。
该实现通过利用自定义的 `AtomicCopy` 特性，克服了未初始化内存（填充字节）带来的风险。该特性允许系统识别并仅复制数据结构中已初始化的字段，从而安全地跳过未初始化的间隙。
虽然 `ByteAtomic` 防止了内存复制带来的未定义行为，但它本身无法保证逻辑数据的完整性；用户仍需使用同步机制（如顺序锁）来防止“撕裂读取”（torn reads）。`ByteAtomic` 为在传统锁无法满足需求的系统中构建可靠、高性能的无锁结构，提供了必要的基础安全机制。
这篇 Hacker News 讨论聚焦于 `iceoryx2` 团队发布的一篇关于“ByteAtomic”封装的文章，该封装旨在安全地执行并发内存拷贝。
作者解释称，在 Rust 中，即使使用了顺序锁来丢弃损坏的结果，当发生数据竞争时，标准的 `memcpy` 操作也会触发未定义行为（UB）。他们的解决方案提供了一种在不违反语言安全保证的前提下执行这些拷贝的方法。
社区讨论主要集中在以下三个方面：
1. **实用性与理论的权衡**：批评者认为，“未定义行为”问题属于语言层面的技术细节，硬件层面可以处理得很好。他们认为强制执行逐字节的原子操作会显著降低性能。
2. **同步定义的界定**：关于术语出现了技术分歧——特别是无锁（lock-free）、无等待（wait-free）和顺序锁（sequence locks）之间的区别，以及考虑到顺序锁在写入者被中断时可能导致阻塞，探讨了其在安全关键系统中是否适用。
3. **替代方案**：资深开发人员建议，对于共享内存通信，RCU（读-拷贝-更新）或指针交换等替代模式通常比字节级原子封装更高效且更合适。