最新

Ark 是一个高性能的实体组件系统（ECS）库，专为 Go 语言设计。<p>Ark v0.6.0 引入了一种新的事件系统，基于轻量级、可组合的观察者。这些观察者允许应用程序通过声明式过滤器和回调函数对 ECS 生命周期的变化（如实体的创建/删除、组件更新、关系变化）做出反应。观察者遵循与 Ark 查询系统相同的模式，使其易于集成和理解。<p>此外，Ark 还支持自定义事件。这些事件可以手动触发，并使用相同的过滤逻辑进行观察，非常适合建模特定领域的交互，例如输入处理和其他反应式游戏逻辑。<p>作为一项新的性能相关功能，过滤器和查询现在是线程安全的，可以并行执行。<p>此次发布还包括大量性能改进，从更快的原型切换、优化的查询和表创建，到改进的位掩码操作性能。新的 World.Shrink 方法有助于在动态工作负载中回收未使用的内存。<p>文档已扩展，包含了事件系统的完整指南、内置和自定义事件的示例，以及一个 Ebiten 集成示例。同时还增加了常见操作的速查表。最后，Ark 现在实现了 100% 的测试覆盖率。<p>更新日志： <a href="https://github.com/mlange-42/ark/blob/main/CHANGELOG.md" rel="nofollow">https://github.com/mlange-42/ark/blob/main/CHANGELOG.md</a> 代码库： <a href="https://github.com/mlange-42/ark" rel="nofollow">https://github.com/mlange-42/ark</a><p>欢迎任何在 Go 中构建游戏、模拟或 ECS 工具的开发者提供反馈。

嗨，HN！我开发了一个 React 组件，使得使用文档画中画（Document Picture-in-Picture）API 变得更加简单。 什么是文档画中画？ 与传统的视频画中画不同，文档画中画允许你将任何 HTML 内容放置在一个始终位于顶部的浮动窗口中。 包链接：<a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;react-document-pip" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;react-document-pip</a> 这个库使用了文档画中画 API，目前支持的浏览器有： - Chrome 116 及以上版本 - Edge 116 及以上版本 - Opera 102 及以上版本

bzfs 是一个简单、可靠的命令行工具，用于在本地或通过 SSH 复制 ZFS 快照（zfs send/receive）。它的伴侣工具 bzfs_jobrunner 可以将这一功能转化为跨 N 个源主机和 M 个目标主机的定期快照/复制/修剪作业，由一个版本化的作业配置驱动。 此次发布使得 1 秒的复制频率对于小增量变得实用，甚至在受限环境下（低 RTT、少量数据集、守护进程模式）也可以实现亚秒级的频率。 v1.13.0 主要关注于降低每次迭代的延迟——这是在大规模复制中高频率复制的敌人： - 在数据集之间和启动时重用 SSH：减少握手和往返次数，这样小增量发送可以节省大量时间。 - 更早的流启动：并行估算“待发送字节”，以便数据路径可以更早打开，而不是在预检时阻塞。 - 更智能的缓存：更快的快照列表哈希和更短的缓存路径，以减少在紧密循环中重复的 ZFS 查询。 - 更具弹性的连接：在失败之前短暂重试 SSH 控制路径，以平滑过渡瞬态波动。 - 更清晰的操作：标准化退出代码；当用户终止管道时，抑制“管道破裂”的噪声。 为什么这很重要： - 在 1 秒的频率下，固定成本（会话设置、快照枚举）占主导地位。减少 RTT 和冗余的 `zfs list` 调用比原始吞吐量带来更大的收益。 - 对于大规模系统，尾部延迟很重要：减少每个作业的抖动和启动开销，在 N×M 个作业的情况下改善端到端的新鲜度。 1 秒（及亚秒级）复制： - 使用守护进程模式来避免每个进程的启动成本；保持进程处于活跃状态，并循环使用 `--daemon-replication-frequency`（例如，`1s`，在受限情况下甚至可以是 `100ms`）。 - 重用 SSH 连接（现在为默认设置），即使对于新进程也避免握手。 - 保持每个数据集的快照计数较低，并积极修剪；较少的条目使得 `zfs list -t snapshot` 更快。 - 限制范围，仅针对真正需要该频率的数据集（如 `--exclude-dataset<i>`、`--skip-parent` 等过滤器）。 - 在大规模系统中，添加小的抖动以避免“雷鸣般的群体”，并限制工作进程以匹配 CPU、I/O 和链路 RTT。 工作原理（简要）： - 从最新的公共快照进行增量发送；支持书签以确保安全和减少状态。 - 持久的 SSH 会话在数据集/zpool 之间和运行之间重用，以避免握手/执行开销。 - 快照枚举使用缓存，以避免在没有变化时重新扫描。 - 通过 bzfs_jobrunner 进行作业编排：相同的配置文件在所有主机上运行；添加抖动以避免“雷鸣般的群体”；设置工作进程计数/超时以实现规模化。 高频率提示： - 以与快照创建成比例的频率进行修剪，以保持枚举速度。 - 使用守护进程模式；将快照/复制/修剪分成专用循环。 - 在主机之间添加小的随机启动抖动，以减少跨集群争用。 - 根据您的 I/O 和 RTT 范围调整 jobrunner 的 `--workers` 和每个工作进程的超时。 快速示例： - 本地复制：`bzfs pool/src/ds pool/backup/ds` - 从远程拉取：`bzfs user@host:pool/src/ds pool/backup/ds` - Jobrunner（定期）：以守护进程模式运行共享的作业配置以实现 1 秒频率：`... --replicate --daemon-replication-frequency 1s`（在受限环境下，亚秒级如 `100ms` 是可能的）。为 `--create-src-snapshots`、`--replicate` 和 `--prune-</i>` 使用单独的守护进程。 链接： - 代码和文档：https://github.com/whoschek/bzfs - README：快速入门、过滤器、安全标志、示例 - Jobrunner README：多主机编排、抖动、守护进程模式、频率 - 1.13.0 差异：https://github.com/whoschek/bzfs/compare/v1.12.0...v1.13.0 注意事项： - 仅限标准工具（ZFS/Unix 和 Python）；没有额外的运行时依赖。 我希望能收到在多个数据集/主机上运行 1 秒或亚秒复制的用户的性能反馈： - 每次迭代的墙时间、增量快照的数量/大小、数据集计数和链路 RTT 有助于结果的上下文化。 欢迎提问！