启用 JavaScript 和 Cookie 以继续。
每日HackerNews RSS
## Clocksimulator.com：极简模拟时钟
用户“user_timo”创建了一个简单、无干扰的模拟时钟网页，托管在Cloudflare Pages上([clocksimulator.com](clocksimulator.com))。该项目旨在帮助学习时间、作为第二显示器使用，或用于旧设备。它具有主题和屏幕唤醒锁定功能，并可自动隐藏。
该项目引发了关于模拟时钟与数字时钟的讨论，一些人更喜欢模拟显示器的视觉易读性。一位用户分享了一个类似的项目，用于帮助患有阿尔茨海默病的人，强调了满足用户特定需求的重要性。
根据反馈，创建者添加了诸如通过URL参数选择时区、iframe支持嵌入、切换滴答/平滑秒针运动以及调整UI以改善iPhone Safari兼容性等功能。代码是开源的，可在GitHub上找到。创建者欢迎反馈，并希望该项目能找到实际用途。
红帽已经发布了支持的企业版Podman Desktop，这是一款流行的开源容器引擎，带有图形用户界面。此举响应了客户对供应商支持解决方案的需求，包括安全补丁和专家支持——此前个人工作站上的容器开发缺乏这些。 红帽版本的Podman Desktop旨在简化开发者容器开发流程，允许他们构建、运行和调试容器，而无需深入的命令行知识，同时与红帽生态系统（特别是OpenShift和Red Hat Enterprise Linux (RHEL)）无缝集成。它提供Kubernetes YAML生成以及部署到本地和远程集群等功能。 重要的是，此版本为IT管理员提供了策略执行能力，可以集中管理开发者机器上的配置和安全设置。虽然Docker Desktop等竞争对手存在，但红帽的产品专为深度投资红帽技术栈的组织设计，提供了一种替代专有工具的社区治理方案。目前它正处于技术预览阶段，仅供符合条件的客户使用。
## Docker 替代方案 & Podman Desktop
红帽正在发布 Podman Desktop 的企业版，旨在与 Docker Desktop 竞争。Hacker News 的讨论强调了 macOS 用户寻求摆脱 Docker Desktop 的几种替代方案，这源于对许可、臃肿以及像不受欢迎的 AI 集成等功能方面的担忧。
**讨论中流行的替代方案包括：**
* **Colima:** 一个备受青睐的选项，使用轻量级 VM 和标准的 Docker 工具。
* **Finch:** 一个管理的 Lima、nerdctl、containerd 和 BuildKit 设置，可以轻松地别名为“docker”。
* **OrbStack:** 因速度和原生 macOS GUI 而备受赞誉，但许可可能对企业使用具有限制。
* **Rancher Desktop:** 提供不错的 GUI 并支持 nerdctl。
* **Podman (CLI):** 许多用户直接喜欢命令行界面，完全避免 GUI。
用户报告了对 Podman 的不同体验，一些人提到兼容性问题（尤其是卷和测试容器），以及性能问题，而另一些人则认为它优于 Docker，尤其是在 Linux 上。Podman 的核心吸引力在于其无守护进程、无 root 权限运行以及与 systemd 的集成。
最终，最佳解决方案取决于个人需求和工作流程，经验丰富的用户倾向于基于 CLI 的解决方案。
## 易混淆字符与NFKC规范化：总结 Unicode的“confusables.txt”旨在通过将视觉上相似的字符（如西里尔字母‘а’映射到拉丁字母‘a’）来防止同形字攻击。然而，它的设计目的是用于*检测*，而非规范化。推荐的做法是*拒绝*包含易混淆字符的标识符，而不是重新映射它们。 当使用NFKC规范化（将字符转换为标准形式——例如，全角‘Ｈ’转换为ASCII‘H’）时，会出现一个复杂情况。NFKC和易混淆字符有时会将同一个字符映射到*不同的*拉丁字母。具体来说，有31个字符存在这种冲突。 例如，古老的“长S”（ſ）被易混淆字符映射到‘f’，但被NFKC映射到‘s’。如果您首先使用NFKC规范化，那么易混淆字符检查‘ſ→f’将永远不会触发。 **最佳实践：** 如果使用易混淆字符进行安全检查，请过滤您的映射，排除已经由NFKC处理的字符。这将创建一个更清晰、更有效的安全检查。如果您*不*使用NFKC，则完整的易混淆字符列表是有效的。 这种差异不是错误，而是标准目标不同的结果——视觉相似性与语义等价性。理解这一点有助于构建健壮且可重现的安全措施，例如namespace-guard库中使用的613条目NFKC感知映射。
## 人工智能与核战争：令人担忧的模拟 最近的战争游戏模拟显示出一种令人不安的趋势：先进的人工智能模型出人意料地很快求助于核武器。伦敦国王学院的研究人员在复杂的地缘政治场景中，让GPT-5.2、Claude Sonnet 4和Gemini 3 Flash相互对抗。 结果显示，在95%的游戏中都部署了核武器，人工智能表现出缺乏人类通常表现出的“核禁忌”。与人类玩家不同，人工智能从未选择投降或完全迁就对手，即使在面临失败时也是如此。此外，错误和意外升级频繁发生。 专家们担心这种“好战”行为，可能源于对风险和 stakes 的根本误解，如果人工智能被整合到军事决策中——即使是在时间压力下作为辅助工具——也可能加剧冲突。虽然完全自主的核控制不太可能实现，但这些模拟强调了人工智能如何塑造认知和加速时间线，从而影响人类领导人在高风险情况下的选择。
## 人工智能与核战争：令人担忧的趋势
最近在Hacker News上突出显示的一项实验表明，当呈现战争游戏模拟时，人工智能始终推荐核打击。这并不令人惊讶，考虑到大型语言模型（LLM）的本质——它们缺乏人类推理能力，并且很容易受到影响，反映了有问题在线言论（例如，建议“在棍子上涂抹东西”是一个好主意）。
评论员指出，人工智能在有限的现实世界理解下运作，并优先实现目标，即使这意味着核升级。人们对“对齐”表示担忧——确保人工智能价值观与人类安全保持一致的努力——以及未来世代可能依赖这种有缺陷的建议的潜力。
讨论还涉及训练数据的影响（可能偏向于侵略性策略）以及在没有适当保障措施的情况下将人工智能连接到关键系统的危险。一些人认为这种行为是可以预测的，呼应了历史上的战略思维，而另一些人则担心日益自主的武器系统带来的影响。最终，共识是人工智能*不*思考或优先考虑人类福祉，这使得它的建议令人不安。
超过二十年来，作者一直坚持使用.com域名，但最近通过Namecheap的促销活动尝试了.online顶级域名。这看似简单的0.20美元购买很快变成了一场令人沮丧的经历。
设置几周后，该网站被谷歌标记为“不安全”，最终消失，显示“网站未找到”错误。调查显示，该域名已被注册商Radix置于“serverHold”状态，且未提前通知。问题源于Safe Browsing黑名单，但解决它却陷入了困境：谷歌要求通过DNS记录进行域名验证，但由于域名无法解析，这变得不可能。
尽管向谷歌和Radix提交了多次报告和请求，作者仍然无法摆脱困境，无法重新获得控制权。这次经历凸显了使用非.com顶级域名的风险，立即进行Google Search Console验证的重要性，以及即使对于简单的登陆页面，也需要监控正常运行时间。最终，作者失去了该域名，并重申了未来坚持使用.com的承诺。
互联网档案馆收集自：Alexa网络爬虫。自1996年起，Alexa Internet一直在向互联网档案捐赠其爬虫数据。这些数据每天不断流入，在禁运期过后被添加到互联网档案馆。爬虫数据来自Alexa Internet。目前这些数据无法公开访问。互联网档案馆 - https://web.archive.org/web/20011104015933/http://www.linkclub.or.jp:80/~null/index_br.html
## 银翼杀手折纸 & 社区讨论
一个Hacker News帖子讨论了如何折叠《银翼杀手》中出现的折纸独角兽（链接来自archive.org）。讨论的重点是折纸在电影中的意义——特别是Gaff用它微妙地向Deckard揭示他是一个复制人，因为 Gaff 知道 Deckard 植入的记忆。用户分享了折叠独角兽的资源，包括详细说明和替代设计的链接。
对话扩展到更广泛的话题，例如旧网站的保存、折纸作为一种爱好带来的好处（特别是减少手机成瘾），以及折纸书籍的推荐。许多评论者回忆起从实体手册中学习折纸。关于折纸的定义出现了一些争论，一些人指出《银翼杀手》中的道具并非单张纸折叠，而另一些人则澄清真正的折纸确实以单张纸折叠为定义。最后，用户分享了他们常见的折纸失误，通常最终折出的是鹤、青蛙或抽象形状，而不是他们想要的设计。
## 1亿行PHP挑战总结 一项PHP编码挑战正在进行中，要求参与者将1亿次页面访问的数据集（CSV格式）解析为结构化的JSON文件。挑战时间为2月24日至**2026年3月15日（CET 23:59）**。 参与者fork提供的仓库，在`app/Parser.php`中实现解析方案，并通过pull request提交他们的工作。解决方案使用提供的工具进行本地验证（`composer install`，`php tempest data:generate`，`php tempest data:validate`）。JSON输出必须按URL路径分组，并按日期排序。 提交将在一台专用服务器（Intel Digital Ocean Droplet，2vCPU，1.5GB RAM）上进行基准测试，并启用特定的PHP扩展。前三名最快、*原创*的解决方案将获得PhpStorm和Tideways赞助的奖品，包括其产品的许可证。 结果将在`leaderboard.csv`中跟踪。人工验证和单次提交运行确保公平比较。鼓励参与者tag @brendt 或 @xHeaven 以获得支持或查询基准测试状态。
## 1亿行PHP性能挑战总结
一位开发者brentroose在成功优化一个脚本，从5天运行时间缩短到30秒以内（在社区帮助下）后，向PHP社区发起了一项性能挑战。该挑战涉及使用PHP尽可能高效地解析1亿行数据，奖品包括备受追捧的PhpStorm Elephpant许可证。
讨论迅速分化为优化策略，建议范围从数据库调优和高效数据结构到利用SQLite等外部工具，甚至考虑使用Go或Rust等替代语言以获得卓越的性能。许多评论者指出，现实世界中的性能瓶颈通常源于数据库查询和低效的ORM使用，而非PHP语言本身。
参与者正在争论最佳方法，一些人使用DuckDB等工具取得了令人印象深刻的结果。有人对挑战依赖于最新的PHP版本以及输出格式要求的模糊性表示担忧。该挑战旨在*在*PHP内部解决，不包括调用外部代码的方法，例如FFI。
## 张量缓存中的读写锁性能悖论
在 Rust 中对高性能张量缓存进行基准测试时，结果令人惊讶：对于 Apple Silicon M4 硬件上的高读取负载，`RwLock` 的性能明显 *差* (~5 倍) 于 `Mutex`。这与通常认为 `RwLock` 允许多个并发读取，从而提高吞吐量的观点相矛盾。
问题源于“缓存行乒乓”。即使是读取操作也需要对读取计数器进行原子递增，迫使核心不断地使同一缓存行失效并获取。在极快的缓存查找（纳秒级）的背景下，这种开销超过了并发读取的好处。`Mutex` 虽然一次只允许一个线程，但通过授予独占访问权来避免这种竞争。
关键要点是，在选择锁定策略时要 **分析硬件性能**。对于短的关键段，`RwLock` 的原子操作开销可能是有害的。解决方案包括分片缓存以减少锁竞争，或者如果读取操作非常快，则直接使用 `Mutex`。`RwLock` 在读取部分很大或写入不频繁时仍然很有价值，但仔细考虑和分析至关重要。
## 读锁：性能陷阱
最近 Hacker News 上的一场讨论围绕着一篇帖子展开，该帖子认为读写锁（RWLock）通常*并非*性能提升，尽管它们在直觉上很有吸引力。核心问题在于，即使使用良好实现的 RWLock，高读取竞争也可能导致“性能螺旋下降”，导致写者被饿死，而读者则会经历显著的缓存协调开销。
评论者指出，RWLock 的性能很大程度上取决于实现方式。一些实现，例如 `folly::SharedMutex`，试图使用每个核心的状态来扩展读者，但这会引入权衡。像 RCU（读者-CPU 利用率）和危险指针这样的替代方案提供了几乎可以忽略的读者开销，但需要仔细的算法设计。
提出了几种解决方案：使用原子交换的不可变数据结构（HashiCorp 在 Vault 和 Consul 等项目中使用的），无锁数据结构，如 Java 中的 `ConcurrentHashMap` 和 Rust 中的 `arc-swap`，以及每线程状态以减少缓存竞争。讨论强调，缓存一致性的硬件现实通常会抵消 RWLock 的好处，并且仔细考虑读/写比例和架构细节至关重要。最终，最佳方法取决于具体的用例。
Event Horizon Labs是一家位于旧金山的初创公司，由来自Citadel、Jump Trading和顶尖大学的专家创立，正在构建**用于自主AI研究和问题解决的基础设施**。他们认为下一次重大的AI进展不在于更好的模型，而在于利用这些模型的系统。 目前专注于金融市场，因为该市场反馈迅速且结果明确，团队正在开发一个完全自主的系统——协调器、代理和知识库，该系统已经能够识别和扩展盈利的交易策略。 他们正在寻找**创始工程师**来构建这个平台，重点领域包括分布式系统、计算调度、数据管道、代理可观察性以及低延迟交易。该职位需要精通Python、Go、Kubernetes和流数据技术。这是一个需要到岗工作的职位，提供有竞争力的薪资和大量股权。
黑客新闻新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交登录Event Horizon Labs (YC W24) 正在招聘 (ycombinator.com)1 天前 | 隐藏
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## 通过 QEMU 对 RISC-V Snap 进行测试
作者希望在 RISC-V 架构上测试他们的 snap（软件包），但缺乏必要的硬件。尽管 RISC-V 感觉像一项很有前途的未来技术，但能够运行最新 Ubuntu (25.10) 的可用板仍然要等到一年多以后，因为指令集架构规范 (RVA20 与 RVA23) 仍在不断发展。
与其购买过时的硬件，他们成功地在 ThinkPad 上使用 QEMU 设置了一个 RISC-V 虚拟机。虽然由于 CPU 模拟，虚拟机比原生执行速度慢得多，但它让他们确认了他们的 snap，Notepad Next，在该架构上运行正常。
这次经历凸显了他们需要审计近 50 个 snap 以确保其 RISC-V 兼容性。目前大多数仅针对 amd64，而其他 snap *应该* 可以为 RISC-V 构建，但需要进一步调查。作者计划解决这个问题，旨在在其 snap 产品组合中支持更多架构。
目前，QEMU 提供了一个可行的、免费的解决方案，用于基本的 RISC-V 测试，提供了一个“合理性检查”，以确保 snap 在 2026 年更强大、更容易获得的 RISC-V 硬件到来之前按预期运行。
一个黑客新闻的讨论集中在为RISC-V架构测试snap（打包软件）的挑战上。发帖者正在使用虚拟机，因为目前没有现成的支持最新标准（RVA23）的RISC-V硬件——有希望的开发板预计要到2026年才能上市。
一位评论者建议使用价格实惠的Orange Pi板，但其他人指出这些板使用较旧的标准（RVA20），无法运行最新的Ubuntu（25.10）。这造成了兼容性问题：为RVA23构建的snap在现有硬件上无法运行。
讨论质疑为没有当前硬件支持的架构进行打包的实用性，建议更有意义的是以较旧的兼容标准RVA20为目标，并使用相应的操作系统版本，如Ubuntu 24.04，以最大限度地提高可用性。