X平台（前身为Twitter）一项新的透明度功能显示，大量积极参与、亲特朗普的政治账号实际上由美国境外运营，这一发现与2016年俄罗斯干预选举的担忧相呼应。声称是美国“爱国者”并倡导“美国优先”政策的账号，被追踪到欧洲、亚洲、非洲等地。 X平台承认，一些差异可能是由于VPN的使用，但数量之多——包括像“MAGA NATION”这样从东欧运营的知名账号——表明这是一项协调一致的干预美国政治话语的行动。这与俄罗斯互联网研究机构在2016年使用的策略相似，该机构创建虚假身份以制造分裂并支持唐纳德·特朗普。 这些账号的来源多样，可能表明既有国家支持的行动，也有出于经济动机而利用政治极化牟利的人员。这一发现凸显了外国干预的持续威胁，并引发了对在线政治对话真实性的质疑，需要加强对社交媒体趋势的审查以及X平台在解决这一问题中的作用。
每日HackerNews RSS
只是意外暴露了一个以美国人为目标的秘密影响力网络。
X Just Accidentally Exposed a Covert Influence Network Targeting Americans
15 小时前
## X平台（前身为Twitter）的秘密影响力网络
最近一篇Hacker News帖子详细描述了X平台上一个秘密影响力网络意外暴露的情况，该网络针对美国人。该网络涉及源自以色列等国家，并可能由这些国家运营的账号，部分证据指向国土安全部运营着一个来自以色列的账号。X曾短暂显示账号的原产国信息，揭示了这一活动，但此后已使.gov账号无法追踪，引发了有关掩盖问题的指控。
讨论的中心是这是否是真正的新信息，许多评论员指出，类似的操纵行为已经报道多年。关于媒体报道存在争议，有观点认为新闻媒体不愿报道是由于政治倾向或害怕报复。
对话还强调了其他国家潜在的互惠干涉问题，以及难以辨别真正的公众舆论和策划活动之间的区别。一些人推测埃隆·马斯克的行为受到政治目标驱动，而另一些人则质疑X的地理位置数据的准确性。
## std::Mutex vs. parking_lot::Mutex：深入分析与决策指南
团队考虑从 Rust 的标准 `std::sync::Mutex` 切换到 `parking_lot::Mutex`，从而引发了对两者性能差异的深入调查。 尽管初步搜索结果偏向 `parking_lot`，但作者希望更深入地理解，因此对两种实现方式进行了详细检查，并进行了大量的基准测试。
`std::Mutex` 使用平台特定的实现（通常是 Futex），并采用内核管理的队列，优先考虑吞吐量。 然而，在高度竞争的情况下，这可能导致线程饥饿。 另一方面，`parking_lot::Mutex` 在所有平台上使用单一算法和用户空间队列，优先考虑公平性和可预测性。 它通过更小的内存占用（始终为 1 字节）和公平定时器（防止无限期锁定）来实现这一点。
在各种场景下的基准测试表明，`std::Mutex` 在低到中等竞争和短临界区中表现出色。 然而，`parking_lot::Mutex` 在高竞争、突发工作负载以及存在潜在锁垄断的场景中表现出卓越的性能，提供更稳定的等待时间并防止线程饥饿。
**选择 `std::Mutex` 的时机：** 需要零依赖项，竞争较低，需要用于调试的毒化（poisoning），或平台特定优化至关重要。 **选择 `parking_lot::Mutex` 的时机：** 公平性至关重要，可预测的行为至关重要，内存占用很重要，或存在锁垄断的风险。
最终，选择取决于应用程序的特定需求——吞吐量与公平性和可预测性。
## Rust Mutex 性能：std vs. parking_lot
最近的分析比较了 Rust 标准库 (`std`) mutex 和 `parking_lot` crate 的 mutex。 历史上，`std` 使用效率较低的 pthread mutex，但现在利用操作系统特定的锁（Windows 上的 SRW，Linux/macOS 上的基于 futex 的锁）来实现性能和内核集成。
直接采用 `parking_lot` 的主要限制在于它依赖于需要内存分配的全局哈希表——在使用自定义分配器时会产生循环依赖。
虽然 `parking_lot` 在需要细粒度锁定的场景中表现出色（由于其较小的锁大小，允许锁位于对象头内），但 `std` mutex 通常表现出可比或更好的性能，尤其是在低竞争情况下。 `parking_lot` 在高竞争下的公平性和较低方差方面表现出色。
目前的工作旨在将 poisoning（panic 处理）从 `std` mutex 中解耦，以解决一个常见的批评。 讨论强调了在 Rust 中选择锁定机制时，性能、安全性和抽象级别之间的权衡。
## Shai-Hulud 蠕虫再次袭击 npm 名为“第二次降临”的新一波攻击来自 Shai-Hulud npm 蠕虫，正在影响开发者。这种自我复制的恶意软件，以《沙丘》中的沙虫命名，利用 npm 在 12 月 9 日撤销经典令牌前的漏洞窗口，入侵软件包以窃取密钥并进一步传播。 本次攻击与之前的攻击不同，它使用 `bun` 进行执行，并为泄露的数据创建动态命名的 GitHub 仓库。它的影响范围也在扩大，目标数量从之前的 20 个软件包增加到 100 个，并威胁如果 GitHub/npm 身份验证失败，将擦除用户主目录。 目前，已有 **492 个软件包** 确认被入侵，其中包括来自 Zapier、ENS、AsyncAPI、PostHog 和 Postman 的软件包，总计 **1.32 亿次每月下载量**。该蠕虫使用 TruffleHog 搜索暴露的 API 密钥和令牌，并将结果上传到公共 GitHub 仓库。 **安全团队应立即：** 审计依赖项，轮换凭据，检查 GitHub 上是否有可疑仓库，在 CI 中禁用 `postinstall` 脚本，固定软件包版本，并强制 MFA。 这是一个持续发生的情况，保持警惕至关重要。
## 沙伊·胡鲁德供应链攻击 - 摘要
沙伊·胡鲁德组织发起的第二次供应链攻击已经破坏了超过300个NPM软件包，影响了Postman、Zapier和PostHog等公司。攻击者正在窃取机密信息，包括AWS凭证，并将它们公开发布在GitHub上，仓库名为“Sha1-hulud: The Second Coming”（虽然名称有拼写错误 – 应该是Shai-Hulud）。
Hacker News上的讨论最初涉及识别潜在的重复帖子，最终导致合并相关评论并将新文章的链接添加到原始讨论中。用户正在分享资源以减轻风险，包括Bubblewrap工具（bwrap）以限制恶意代码在安装期间造成的损害，以及一个Python脚本来检查锁定文件中是否存在受损软件包。一些人认为，此时将暴露的密钥保留在GitHub上可能比对攻击者更有帮助。
## 无服务器搜索：深入研究 Nixiesearch 在 AWS Lambda 上的应用 本文探讨了实现真正无服务器搜索的挑战，揭穿了当前“无服务器搜索”解决方案不过是隐藏的、始终在线的基础设施的观点。作者尝试在 AWS Lambda 函数中运行 Nixiesearch，一个基于 Lucene 的搜索引擎，来解决这个问题。 主要障碍包括类似 Elasticsearch 引擎的大型容器尺寸（约 700MB）、缓慢的启动时间（40+ 秒）以及集群状态管理的复杂性。解决方案涉及使用 GraalVM native-image 创建更小、更快的二进制文件，并探索通过 S3 和 EFS 进行远程索引存储。 实验表明，虽然冷启动时间可以缩短到半秒以下，但网络存储（尤其是 EFS）由于缓慢的随机读取而引入了显著的延迟。将索引烘焙到 Docker 镜像中并不能改善情况，因为 Lambda 仍然将其缓存在 S3 中。 作者提出了一种未来的方向：利用 S3 的并发性在 HNSW 图遍历期间并行化 embedding 加载，可能实现约 100 毫秒的基线延迟。最终，该项目展示了无服务器搜索的复杂性，并强调了需要进行架构调整以克服固有的限制。
一位开发者构建了NixieSearch，一个以Lambda函数实现的搜索引擎，旨在降低成本——仅在搜索时付费。该项目利用Lucene和GraalVM原生二进制文件来提高性能。
Hacker News上的讨论强调了类似的工作，一位用户之前曾在Lambda上使用Lucene，但由于AWS账户偏好而放弃。另一位用户提到了Quickwit，一个低成本选择，但其Lambda支持即将结束，因此需要像NixieSearch这样的替代方案。
讨论的关键点集中在Lambda的内存限制上。虽然文档显示最多可用10GB，但一些用户报告需要向AWS支持请求增加，才能访问更高的内存分配，尽管最近有更广泛可用性的公告。对话还涉及了搜索实现成本的增加以及向“无计算机”架构的演变，Cloudflare被认为是抽象数据位置的领导者。
展示 HN：使用 Docker Compose 的虚拟 SLURM HPC 集群
Show HN: Virtual SLURM HPC cluster in a Docker Compose
16 小时前
## 基于 Docker 的 SLURM 高性能计算集群 本项目提供了一个精简、生产就绪的多容器高性能计算 (HPC) 环境，使用 Docker 和 Rocky Linux 9。由 eXact lab S.r.l. 开发，它虚拟化了一个具有 SLURM 工作负载管理器和 OpenMPI 支持的 HPC 系统，并可选地通过 MariaDB 提供完整的作业会计。 默认设置包括一个主节点、两个工作节点（每个 4 个 vCPU/2GB RAM）和一个可选的数据库节点。提供 SSH 访问（使用生成的密钥 – *不适用于生产环境*）用于集群交互。用户通过挂载的主目录卷在节点之间同步，SLURM 配置共享。 主要功能包括节点内/节点间 MPI 作业执行、通过软件包安装（使用 `packages.yml`）进行运行时自定义，以及模拟 scratch/work 区域的共享存储。SLURM 配置可以通过卷挂载进行自定义。缓存机制优化了软件包安装速度。 镜像可在 GitHub Container Registry 上获取，也可以本地构建。本项目旨在用于教育和测试目的，提供了一种便捷的方式来探索和试验 HPC 概念。
## vHPC：一个虚拟SLURM HPC集群
一位开发者开源了“vHPC”，这是一个使用Docker Compose和SLURM构建的虚拟高性能计算（HPC）集群。vHPC旨在方便针对大型生产HPC系统（Cineca Leonardo）的开发，解决了现有容器化解决方案通常缺乏诸如会计和MPI支持等关键功能的局限性。
该项目力求简单和通用，提供一个本地原型设计环境，而无需像Ansible、Chef或Puppet等传统部署工具的复杂性。虽然存在几种HPC部署系统（包括来自Compute Canada和NVIDIA的选项），但vHPC提供了一种现代且易于访问的替代方案。
用户对其功能感到好奇，包括SSH访问以及与OpenOnDemand（现有集群的Web界面）等工具的比较。vHPC主要用于开发和测试，在单台机器上模拟多节点集群，而不是部署全规模的生产环境。开发者可供提问。
一位Booking.com的顾客预订了价值4000美元的酒店，结果被取消，随后发现同样的房间重新挂牌，价格高达17000美元。Booking.com最初以“价格错误”为由，根据其允许酒店在这种情况下取消预订的政策，来解释此次取消。
但在媒体关注（通过CBC的“Go Public”）后，Booking.com改变了决定，并表示愿意履行原始预订，承担价格差额。
Hacker News上的评论员认为，这凸显了一个系统性问题：酒店取消预订以利用需求增加（例如在活动期间），而Booking.com作为经纪人的角色使其暴露在价格波动中。虽然Booking.com最终由于负面宣传纠正了这种情况，但酒店利用系统的核心问题仍然存在，一些人建议Booking.com应该移除参与这种行为的酒店。
登录
## Chromium 重新评估 JPEG XL
谷歌重新考虑在 Chromium 浏览器中集成 JPEG XL (JXL) 解码器。这得益于该格式的积极信号，特别是基于 Rust 的解码器正在开发中。然而，谷歌在默认启用 JXL 之前，需要对长期维护做出承诺。
讨论强调了 JXL 相较于 JPEG、WebP 和 AVIF 等现有格式的潜在优势，包括更好的 HDR 支持和无损重压缩能力。一些人认为 JXL 是一个比其前代更经过深思熟虑的图像格式。
然而，由于谷歌放弃项目的历史，以及对向网络中已经复杂的图像格式生态系统添加另一种格式的担忧，仍然存在怀疑。无损重压缩功能，允许精确的 JPEG 重压缩，被视为一个关键优势。Mozilla 也表达了兴趣，但前提是需要一个高性能且内存安全的解码器。最终，采用取决于持续的开发和支持。
## Serflings：对《Settlers 1》的忠实重制 Serflings是对经典策略游戏《Settlers》（在某些地区被称为《Serf City》）的重制，旨在最大限度地忠于原作，同时添加现代改进，例如更高的分辨率和联网游戏。 运行Serflings需要原始《Settlers 1》游戏中的一个文件——SPAE.PA（或其语言版本），但如果您安装了历史版本，则不需要此文件。它完全支持来自DOS版本和历史版本（Ubisoft提供）的存档游戏。 该重制版包含所有原始任务、人工智能和核心功能，以及流畅滚动、缩放、可调节游戏速度和局域网多人游戏等功能。它支持德语、英语、法语和波兰语。 目前仍在开发中，建筑替换和网络大厅等原始功能仍在计划中。您可以在他们的[Github](https://github.com/Serflings/Serflings)和[Discord](链接未提供)上找到更多信息、开发更新和报告错误。
## 《殖民者》重制版与续作引发讨论
一个Hacker News论坛讨论了《殖民者1》的重制版“Serflings”，引发了关于该系列遗产和现代替代品的对话。 许多用户怀念《殖民者1 & 2》，强调其独特的物流挑战——通过严格的路径网络系统管理资源运输，本质上是构建一个具有有限吞吐量的节点和边的图。
值得注意的是，有人提到了由原《殖民者》创作者打造的现代续作“Pagonia先驱者”，目前处于抢先体验阶段。 其他推荐给粉丝的游戏包括开源游戏“Widelands”、独立游戏“The Colonists”（专注于道路建设物流）和“Farthest Frontier”。
讨论还涉及优化资源流的吸引力以及对后期《殖民者》游戏放弃复杂路径系统的沮丧。 一些用户甚至将游戏中的物流挑战与现实生活中的组织习惯联系起来！ 此外，还提出了一个关于使用人工智能重现原始图形的法律问题，并讨论了“干净房间设计”原则。
``` -- 创建一个新的本地服务器 local server = require("http").server.new() -- 注册一个路由 server:get("/", function() return "hello from default Astra instance!" end) -- 你也可以在路由中使用局部变量 local counter = 0 server:get("/count", function(request, response) -- 消费请求体 print(request:body():text()) -- 设置状态码 (可选) response:set_status_code(300) -- 设置头部 (可选) response:set_header("header-key", "header-value") counter = counter + 1 -- 也可以返回JSON return { counter = counter } end) -- 配置服务器 server.port = 3000 -- 运行服务器 server:run() ```
## Astra：一个用 Rust 构建的 Lua Web 服务器运行时 - 摘要
一个名为 Astra 的新项目旨在为 Lua (5.1-5.4)、Luau 和 LuaJIT 提供一个 Web 服务器运行时，使用 Rust 构建。然而，讨论很快表明 Astra **并没有用 Rust 实现一个新的 Lua 引擎**，而是通过像 `mlua` 这样的 crates 包装现有的 C/C++ Lua 实现，提供 Rust 接口并将它们打包成一个单独的二进制文件。
该项目的命名和描述引发了争论，一些人质疑使用“运行时”，因为它并没有重写 Lua 解释器本身。作者承认这种混淆，并计划澄清文档。Astra 的目标是通过提供一个捆绑的环境，其中包含可以从 Lua 访问的现成 Rust 库，从而加快开发速度，最初专注于 Web 服务器应用程序，但会扩展到其他用例。
虽然 Astra 不是一种新颖的 Lua 实现，但它旨在提供便利性和与 Rust 生态系统的集成，类似于 JavaScript 世界中的 Bun 或 Deno 等项目。讨论中还提到了其他几个 Lua Web 服务器框架，如 Redbean 和 Luvit。
## Cynthia：适用于Windows的可靠MIDI播放器
一款名为Cynthia的新型、轻量级且便携的MIDI播放器已发布，解决了现代Windows版本中MIDI支持逐渐减少的问题。Cynthia历经一年开发，旨在恢复Windows 95时期近乎即时且可靠的播放体验。
主要功能包括支持.mid、.midi和.rmi文件，多种播放模式，实时数据可视化，Xbox手柄支持，以及管理大型MIDI库的能力。值得注意的是，它拥有定制的播放引擎，以确保稳定性和占用空间小——与资源密集型应用程序形成鲜明对比。
虽然它原生运行于Windows，但据报道，它也可以通过Wine在Linux/Mac上运行。该项目是开源的（MIT License），并在GitHub上提供，附带演示视频展示其功能。初步反馈指出，在4K屏幕上界面略有延迟，CPU占用率较高，但赞扬了其体积小巧。