## std::shared_mutex: C++ 中的读写锁
本文探讨了 `std::shared_mutex`，这是 C++17 的一项特性，为主要读取的数据提供了改进的并发性。与提供独占访问的 `std::mutex` 不同，`std::shared_mutex` 允许多个读取者同时访问资源，同时确保写入者拥有独占访问权。
其核心优势在于，在频繁读取和不频繁写入的场景中（例如缓存、配置数据或统计信息），可以提高吞吐量。基准测试表明，在读取密集型工作负载中使用 `std::shared_mutex` 代替 `std::mutex` 可以显著提高性能（在某个示例中，运行时从 285 毫秒减少到 102 毫秒）。
关键注意事项包括避免递归锁定以及无法在潜在死锁的情况下将共享锁升级为独占锁。虽然 `std::shared_mutex` 会引入一些开销，但它仍然是一个有价值的工具，尤其是在优先考虑简单性时。
尽管 C++20 及更高版本引入了新的并发特性（例如 `std::jthread` 和信号量），但 `std::shared_mutex` 仍然是有效地管理主要进行读取操作的共享状态的实用解决方案。
每日HackerNews RSS
## 理解 C++17 的 `std::shared_mutex` - Hacker News 讨论总结
这次 Hacker News 讨论围绕 C++17 中引入的 `std::shared_mutex`，这是一种读者-写者锁，专为大量读者和少量写者的情况设计。用户将其与 Rust 的 `RwLock` 以及更广泛的读者-写者锁概念进行比较。
一个关键点是 `shared_mutex` 不会与较低级别的并发原语（如原子操作、条件变量或 RCU（安全内存回收））*竞争*。虽然 RCU 有时可以替代 `shared_mutex` + 状态方法，但 `shared_mutex` 提供了同步机制，保证所有线程在写入后都能观察到新值。
对话深入探讨了性能方面的考虑。RW 锁可能会受到缓存争用的影响，但存在可以缓解这种情况的实现。还建议使用 seqlock 和 hazard pointer 等替代方案，因为没有一种并发原语是普遍最优的。
用户还讨论了 C++ 和 Rust 标准库锁定 API 的局限性，指出缺乏细粒度控制（例如设置读者/写者优先级），并且通常需要依赖外部 crate 或自定义实现来满足特定用例。
2026年2月，Andrej Karpathy 强调了一种新的AI发展趋势，他称之为“爪子”（Claws）。在LLM代理的基础上，“爪子”代表着更进一步的复杂性，改进了编排、调度、上下文管理和持久性。 本质上，“爪子”是设计在个人硬件上运行并通过消息进行通信的AI代理系统。Karpathy 注意到小型、开源“爪子”实现激增，例如 NanoClaw（仅4000行代码）以及 Nanobot 和 Zeroclaw 等。 他认为“爪子”将成为这个类别的定义术语，并对AI堆栈中这一新层的潜力感到兴奋，认为它是从LLM到LLM代理的自然演进。 这种受欢迎程度显而易见，据报道，Mac Minis 正在迅速售罄，许多爱好者渴望进行实验。
## 黑客新闻讨论总结：Karpathy 的 “Claws” 与 Simon Willison 的博客
这个黑客新闻讨论围绕 Andrej Karpathy 在 X (Twitter) 上创造的 “Claws” 术语，描述一种新型 AI 代理。讨论焦点很快转移到对 Simon Willison 博客的批评，该博客报道了 Karpathy 的这个术语。
许多用户认为 Willison 的博客文章只是链接到原始来源（Karpathy 的推文），构成了为了点击量而进行的“链接农场”，违反了黑客新闻关于推广内容和原创来源的准则。一些人指责 Willison 因为赞助而产生这种内容。另一些人则为 Willison 辩护，赞扬他的写作和突出新术语的价值。
Willison 本人回应称，他并非将所有博客文章提交到 HN，而是旨在为原始来源添加背景信息。他还回应了关于最近赞助的担忧，表示他重视自己的独立性，并正在考虑避免接受来自他经常报道的公司提供的赞助。讨论还涉及 AI 领域内炒作和术语的更广泛问题。版主介入提醒用户避免人身攻击。
## 云边测试床经验：etcd 与存储性能 使用 Karmada 构建云边连续统演示，用于 MLSysOps（一个动态应用部署框架）时，揭示了一个关于分布式系统的关键经验：**etcd 对存储延迟非常敏感。** 该演示旨在展示基于性能遥测数据，实时对象检测从树莓派切换到 Jetson AGX Orin。然而，运行在 NUC 虚拟机上的 Karmada 集群频繁出现 Pod 崩溃。经过大量调查，问题并非与应用程序相关，而是源于**不稳定的 I/O 性能**影响了 etcd，Karmada 的状态存储。 etcd 的强一致性需要快速的 fsync 操作，而由于 NUC 上的共享存储，这些操作失败了。 增加超时阈值等解决方案不足以解决问题；修复涉及**优化 ZFS 设置**（禁用同步写入，启用 LZ4 压缩，禁用 atime，并调整 recordsize）以优先考虑速度。 这次经验强调了**优先考虑 etcd 的存储性能**的重要性。 监控 `etcd_disk_wal_fsync_duration_seconds` 等指标并主动基准测试存储至关重要。 虽然专用的存储对于生产环境来说是理想的，但仔细调整可以稳定演示环境。最终，团队成功演示了动态工作负载的切换，但只有在解决了这个基本基础设施依赖之后才得以实现。
启用 JavaScript 和 Cookie 以继续。
## LibreOffice 与 OnlyOffice：格式锁定争议
一篇最近的博文在Hacker News上引发了关于LibreOffice批评OnlyOffice与微软合作的争论。LibreOffice声称这种合作旨在将用户锁定在微软的文件格式中。这场讨论凸显了人们对办公软件套件中格式兼容性和厂商锁定的持续担忧。
用户分享了关于格式问题的经验，尤其是在从Google Sheets迁移或处理复杂的Excel功能时。虽然有些人更喜欢LibreOffice的开源性质，但另一些人认为它的用户界面过时且令人沮丧，尽管承认其功能正确性。一些用户推荐了替代方案，如Gnumeric或SoftMaker的FreeOffice。
一个关键点是，由于OOXML（微软）和ODF（LibreOffice）等文件格式的复杂性，实现真正的互操作性本质上是困难的。一些人认为微软并不真正优先考虑“开放”格式，而另一些人则认为，优先考虑与市场领导者的兼容性是OnlyOffice务实的选择。这场争论还涉及平衡创新与向后兼容性的挑战，以及基于标记的文档创建的潜在好处。
## 24 Hour Fitness 无法使用的退订链接
24 Hour Fitness 因其营销邮件中持续无法使用的退订链接面临潜在法律问题，这个问题早在2019年就被报告。点击该链接会显示西班牙语错误信息，源于与OneTrust同意管理平台通信时，JavaScript代码中关于内容类型标头的一行错误——讽刺的是，OneTrust是一家专注于法规遵从的公司。
尽管该问题于2025年11月被报告，并提供了简单的修复方案，但至今仍未解决，导致作者收到了超过40封不想要的营销邮件。这违反了CAN-SPAM法案，该法案要求提供可用的退出机制，类似违规行为的近期罚款已达数百万美元。
作者对持续不断的无关营销“精神攻击”感到沮丧，因此自行构建了一个可用的退订页面作为替代方案。他们呼吁24 Hour Fitness的工程团队中的某人实施这一行修复代码，并为所有用户解决该问题。
## 24 Hour Fitness 垃圾邮件与AI辅助
一名Hacker News用户daem详细描述了他修复24 Hour Fitness营销邮件失效退订链接的过程。问题在于该公司未能尊重退订请求，促使daem通过编程方式调试并解决问题。
这篇帖子引发了关于AI辅助写作的争论，评论者质疑daem文章的真实性，认为它受到AI（特别是Claude和一个名为Mars的“OpenClaw agent”）的强烈影响。Daem承认使用了AI进行草稿撰写，但也承认需要完善写作以恢复个人风格。
讨论还涵盖了更广泛的问题，例如退订链接的有效性、垃圾邮件的普遍性以及潜在的解决方案，例如使用唯一的电子邮件别名或基于域的catch-all。 许多评论者强调了公司无视退订请求的令人沮丧的做法以及可能违反CAN-SPAM法规的风险。 另一些人指出“List-Unsubscribe”标头对于电子邮件客户端正确处理退订的重要性。最终，daem报告说，在修复后，来自24 Hour Fitness的垃圾邮件显著减少。
## LinkedIn 的蓝色勾选与您的数据：隐藏的代价 为了获得 LinkedIn 的“真实身份”蓝色勾选，作者发现了一个重大的隐私权牺牲。验证过程并非由 LinkedIn 直接处理，而是由一家名为 Persona Identities, Inc. 的第三方公司负责。扫描护照和自拍会赋予 Persona 访问大量个人数据的权限——包括生物特征面部几何信息、国家身份证号码和地理位置——这些数据远超于简单的验证所需。 Persona 不仅*使用*这些数据，还会将其与政府数据库、信用机构进行交叉引用，甚至用于训练他们的人工智能。令人担忧的是，数据会与一个由 17 个子处理商组成的网络共享，主要为美国公司，如 OpenAI 和 Amazon，使其受到美国 CLOUD 法案的约束——无论数据存储在何处，甚至在欧盟境内，都可能允许美国执法部门访问。 尽管声称符合欧盟-美国数据隐私框架，但作者强调了其脆弱的法律基础。即使 Persona 在发生数据泄露的情况下将责任限制在 50 美元，真正的风险在于生物特征数据的永久性及其潜在的滥用。作者建议，如果已经验证，应请求删除数据并反对用于人工智能训练，并在追求勾选之前仔细考虑隐私影响。
新的欧盟电池法规今天生效，旨在实现可持续的电池生命周期——从原材料采购到报废处理。该立法通过最大限度地减少电池的碳足迹、减少有害物质以及减少对非欧盟原材料的依赖，来支持欧洲绿色协议。 主要方面包括逐步引入电动汽车电池的碳足迹限制（从2025年开始）、更严格的回收目标（从2025年开始），以及强制回收*所有*收集的电池，重点是回收钴和锂等关键材料。消费者将获得更多控制权，便携式电子设备将配备易于拆卸的电池（2027年），并通过数字护照和二维码访问详细的电池信息。 该法规还为公司引入了尽职调查义务，以确保负责任地采购原材料。 受到电池需求快速增长的推动——预计到2030年将增加14倍——这项法律旨在确保可持续和具有竞争力的欧洲电池产业。
## gitas：轻松管理多个 Git 账户
**gitas** 是一款在 Linux、macOS 和 Windows 上无缝切换多个 Git 账户的工具。它简化了使用个人和工作账户，或访问私有仓库的操作。
**安装** 通过 shell 脚本、PowerShell、Homebrew 或 Cargo 可以轻松完成。
**主要特性：**
* **账户管理：** 使用交互式 TUI (`gitas`) 添加、编辑和删除账户。
* **身份切换：** 更新 Git 配置以持久使用账户。
* **命令代理：** 以特定账户运行单个 Git 命令，而无需更改您的配置 (`gitas git clone ...`)。
* **安全存储：** 凭据安全地存储在您系统的原生钥匙链中。
**卸载** 也同样简单，使用与安装相对应的方法即可。
gitas 采用 Apache 许可证 2.0。安装脚本和更多信息可在项目的 GitHub 页面上找到。
## Gitas：一个Git账号切换工具 - 摘要
最近Hacker News上出现了一场关于“Gitas”的讨论，这是一个旨在简化在多个Git账号（如个人和工作）之间切换的新工具。然而，许多评论者指出，现有的Git功能已经可以有效地解决这个问题。
核心问题是管理不同项目的不同身份，尤其是在GitHub上。讨论的解决方案包括使用配置在`~/.ssh/config`中的专用SSH密钥，以及利用Git的`includeIf`功能，根据项目目录应用特定的配置。一些用户使用post-checkout钩子来自动设置Git身份。
一些评论员批评Gitas是在解决Git已经很好地处理的问题，强调了一种过度工程化解决方案的趋势，即在发现现有解决方案之前就先构建新的解决方案，这可能受到LLM的影响。其他人讨论了需要多个账号的原因——SSO要求、分离工作/个人项目，或管理顾问的客户工作。
GitHub CLI的`gh auth switch`和`.gitconfig`中的条件包含等替代方案也被建议为更简单、内置的解决方案。这场讨论强调了在采用新工具之前，理解Git现有功能的重要性。
艾克米天气
Acme Weather
2 天前
## Acme 天气：一种新的预报方法
在开发天气应用程序 15 年后，包括流行的 Dark Sky（后来整合到 Apple 天气中），其创建者推出了 Acme 天气。他们对现有应用程序的局限性感到不满，特别是它们未能解决预报的*不确定性*，因此他们构建了一项新的服务，专注于提供更真实和信息丰富的体验。
Acme 天气不提供单一的“最佳猜测”预报。相反，它呈现“可能的替代未来”——一系列预测，说明了可能的结果范围，帮助用户了解预报的可靠性。“社区报告”功能进一步提高了实时准确性，允许用户分享当前状况。
除了预报之外，Acme 天气还拥有一套详细的上下文地图（雷达、闪电、温度等）以及针对从降雨预警到潜在彩虹的一切的可定制通知。独特的“Acme Labs”部分提供有趣的实验性功能，例如日落提醒。
Acme 天气优先考虑用户隐私，采用直接订阅模式（每年 25 美元），不进行第三方跟踪或数据销售。它目前可在 iOS 上使用，Android 计划正在开发中。
## Acme Weather：一个拥挤领域的新竞争者
Acme Weather 由曾经开发出广受欢迎（并被苹果收购）的 Dark Sky 应用的团队打造，其发布重点在于改进现有的天气应用体验。Hacker News 上的讨论显示出褒贬不一的反应。许多人赞赏该团队过去的工作和该应用的潜力，但担忧集中在其最初的美国可用性和订阅模式（每年 25 美元）上。
用户哀叹 Dark Sky 功能和准确性在苹果天气应用中消失，但鉴于“订阅疲劳”和免费替代品的存在，他们不愿再订阅。一些评论员强调欧洲已经存在出色的、本地化的天气应用（如 Yr.no、MeteoSwiss 和 DWD WarnWetter），质疑是否需要另一个付费选项。
一个关键的讨论点是通过众包数据提高预测准确性的潜力，以及在天气建模方面持续创新的必要性。尽管存在最初的局限性，但许多人仍持谨慎乐观态度，并渴望尝试该应用，希望它能兑现提供精心设计和准确天气体验的承诺。
## 基于主干的开发：总结
基于主干的开发 (TBD) 是一种源代码控制策略，侧重于频繁地直接提交到主分支（“主干”/“main”），避免长期存在的分支。这种方法是实现持续集成和持续交付的关键，确保代码库始终可发布。
团队，无论规模大小，都致力于每天集成多次变更。小型团队可以直接提交，而大型团队则使用短期的特性分支——理想情况下是单个开发者完成的工作——并使用拉取请求进行代码审查和自动化构建验证。特性标志和“抽象分层”等技术有助于管理较大的变更。
TBD 与 Gitflow 等模型形成对比，后者依赖于许多长期运行的分支。虽然可以使用发布分支进行稳定化，但许多高吞吐量团队直接从主干发布，采用“修复后提交”策略。
成功的 TBD 需要一个强大的 CI 系统来防止构建中断，并且具有可扩展性，例如谷歌等拥有数万名开发人员共享单个主干的组织所证明的那样。 这是一种成熟的做法，可以追溯到 1980 年代，随着源代码控制和相关工具的进步而日益普及。