## ECS Survivors：近期更新总结
经过七个月的停滞，ECS Survivors项目在四个更新中取得了显著进展。该项目现在具有改进的视觉效果，集成了使用Tiled编辑器和tmxlite库的**瓦片地图**。通过实施用于瓦片渲染的“截图”方法以减少绘制调用，以及**贪婪合并算法**以大幅减少碰撞体数量，从而优化了性能。
通过添加**空间哈希网格**以加速碰撞检测，进一步提高了性能，从而在处理大量实体时将速度提高了10倍。
通过**升级系统**引入了游戏进程，允许玩家在击败敌人后获得强化道具。
最后，一次重大**重构**将代码库组织成分层架构，并采用新的文件层次结构和CMake配置，从而能够创建单独的模块（输入、渲染等）和应用程序——包括潜在的编辑器和无头服务器，从而改善了代码组织和未来的可扩展性。
开发者承认过于雄心壮志减缓了进度，但该项目现在处于稳定状态，未来的开发将侧重于核心游戏玩法功能，例如近战攻击。可在Itch.io上获取可玩版本，并在GitHub上获取源代码。
每日HackerNews RSS
最近一篇Hacker News帖子强调了一位研究生Laurent Voisard关于实体-组件-系统（ECS）架构的研究——一种游戏开发中常见的设计模式。该帖子是ptildej.net上一个系列文章（第七至第十部分）的一部分，探讨了ECS对软件质量的影响。
一些评论者最初误以为“ECS”是亚马逊的弹性容器服务，但很快意识到讨论的重点是软件架构。读者对这个话题表现出兴趣，有人建议从系列文章的第一篇开始阅读以获取背景信息。对话中还包含对Amiga的ECS/AGA图形芯片的怀旧参考，展示了对该缩写的不同解读。该帖子源于一位教授布置基于软件工程学生研究的博客作业。
## Java垃圾回收的演变成本 数十年以来，Java的垃圾回收（GC）一直自动管理内存，使开发者摆脱了手动生命周期管理。然而，这种便利是以CPU周期为代价的。传统上，GC性能通过暂停时间来衡量，但随着GC算法的演进，这个指标变得越来越不可靠。 现代GC引入了复杂性：*显性成本*（专门用于GC任务的CPU周期）、*隐性成本*（注入到应用程序代码中的屏障）和*微架构效应*（缓存影响）。并行GC用CPU换取更短的暂停时间，而像G1和ZGC这样的并发收集器则将工作转移到后台，掩盖了总CPU开销。ZGC旨在实现最小的暂停时间，但并未消除工作，只是将其分摊。 这种转变意味着暂停时间不再能准确反映GC效率。Amdahl定律进一步限制了并行化的好处。为了解决这个问题，OpenJDK 26引入了新的API——通过`-Xlog:cpu`进行统一日志记录，以及`MemoryMXBean.getTotalGcCpuTime()`方法——以提供对GC显性CPU成本的精确核算。 这些工具能够做出关于堆大小和GC算法选择的明智决策，从而超越了对暂停时间进行反应式优化，转向主动资源管理。通过暴露真实的计算成本，开发者和研究人员可以同时优化吞吐量和延迟，最终实现更高效、更具成本效益的Java应用程序。
## AI 与 3D 建模：尚未成熟
尽管人工智能取得了进步，但为电商生成可用的 3D 模型仍然是一个重大挑战。虽然人工智能可以快速生成乍一看还不错的模型，但仔细检查会发现关键缺陷阻碍了实际应用。最近对人工智能生成的匹克球拍和手工制作版本进行的比较凸显了这些问题。
人工智能模型存在“三角形汤”问题——混乱、无序的几何结构，使得即使是简单的编辑也变得极其困难和耗时，通常需要完全重建。纹理通常是低分辨率的“幻觉”，缺乏对材质的理解，导致烘焙光照和难以辨认的细节。虽然人工智能生成的文件尺寸较小，但这归因于低效的几何结构，而非优化的质量。
目前，人工智能 3D 生成优先考虑速度和文件大小，而不是可用性。这导致模型不适合产品配置器，在产品配置器中，视觉保真度和可编辑性对于建立客户信任至关重要。除非人工智能能够可靠地生成干净的拓扑结构和正确的材质分离，否则“节省时间”的说法是一种谬论——修复人工智能生成的模型通常比从头开始创建它们花费*更多*时间。目前，人工干预仍然是高质量、生产就绪的 3D 资产的关键。
## AI 生成的 3D 模型：批判性观察
这次 Hacker News 讨论围绕一篇关于 AI 生成 3D 模型质量差的文章展开——被称为“3D 垃圾”。核心论点是，虽然 AI 可以快速*创建*模型，但它们缺乏人类创建资产的结构完整性和高效设计。
用户将其与 AI 生成的代码进行类比，指出两者都倾向于过于复杂，并且需要专业人员进行大量清理。缺乏“内在能动性”——对形式和功能的根本理解——导致模型拓扑混乱，无法用于动画或详细编辑。虽然存在*改进* AI 生成网格的工具，但该过程通常比从头开始创建模型更耗时。
尽管承认目前的局限性，许多人认为正在取得快速进展。然而，一个关键挑战是与图像生成等其他 AI 领域相比，高质量 3D 训练数据的可用性有限。这次对话强调了 AI 作为辅助艺术家的工具与 AI 完全自动化、高质量生产的潜力之间的区别——后者仍然是一个遥远的目标。
祝大家节日季温暖、安宁（或者至少比随机包裹升级少点意外）。无论您是旅行、待在家中、编写一些美妙的无用代码，还是仅仅抱着一杯热饮潜伏着，我都希望您能获得片刻宁静和满满的舒适。感谢您成为这个特别之处的一部分：这里的创造力、善良、古怪的小项目，以及持续提醒我们互联网仍然充满人情味。 圣诞节快乐给庆祝的人们，节日快乐给所有人。日历翻页后再见。~deepend
## tilde.club：共享的Unix体验
一篇最近的Hacker News帖子强调了**tilde.club**，一个提供访问共享Unix计算机的社区。讨论引发了对大学时代时间共享系统（许多用户登录到单个强大的机器）的怀旧。
用户回忆了有限计算能力的挑战——例如旧系统上漫长的编译时间——并将其与现代个人电脑进行了对比。一些人表达了对这种协作、多用户环境的回归的渴望，特别是对于学生来说，可以获得可访问的计算资源。
该帖子还提到了类似的社区，如**SDF.org**和**envs.net**，用户称赞tilde.club比一些替代方案更易于使用。其他人分享了与历史系统（如PLATO和早期工作站）的经验，展示了计算的演变。一些用户已经开始搭建自己的类似服务器，例如**tildeweb.nl**。
该服务由一位不堪重负的志愿者运营，因此帐户批准可能需要时间。
## Linum图像-视频VAE：潜空间中的经验教训
Linum最近开源了他们的图像-视频VAE，并附带了详细的开发日志，重点介绍了关于压缩和生成模型质量的关键发现。VAE对于高效视频生成至关重要，可以将数据压缩到可管理的潜空间中，供扩散Transformer使用——否则，由于注意力机制的二次方扩展，它们会因计算成本而苦恼。
他们的探索表明，**更好的压缩并不一定意味着更好的下游生成**。他们花费了数月时间来解决不稳定性问题和重建质量差的问题，最终选择了Wan 2.1的VAE用于他们的文本到视频模型，因为它速度快且体积小。
主要挑战包括联合训练图像和视频（需要仔细的损失权重以避免偏差），以及克服诸如变色斑点之类的伪影——通过诸如自调节卷积之类的修改来解决。他们还发现，**过度优化像素级的完美重建实际上会*损害*生成质量**，因为它迫使VAE编码噪声。
展望未来，Linum正在探索两条路径：正则化VAE以学习更具语义的潜空间（通过诸如与预训练编码器对齐之类的技术），以及可能完全绕过VAE，采用诸如JIT之类的技术，该技术在扩散模型中直接学习压缩。他们的最终目标是通过生成视频技术的进步来实现易于访问的动画。
## Linum AI 分享图像-视频 VAE 学习成果
Linum v2 文本到视频模型的作者发布了他们的图像-视频 VAE（带有开放权重）以及关于其开发的详细说明，发布在 Hacker News 上。讨论的重点是构建该模型面临的挑战和经验，引发了相关领域从业者的交流。
主要收获包括使用高位深图像和真实世界相机素材进行训练的困难，原因在于数据存储成本和维持数据多样性。团队发现过滤低质量数据对于成功的重建至关重要。他们使用了 WAN 2.1，并讨论了迭代实验的过程，承认了漫长的训练时间带来的固有缓慢反馈循环——严重依赖直觉以及对每次实验的成本效益分析。
用户表示有兴趣将该模型微调用于艺术生成和合成卫星图像等应用，并赞赏清晰且富有洞察力的报告。进一步的讨论涉及了 EQ-VAE 等技术，以改善正则化和收敛性。
避免使用暗语。有时人们写的东西听起来像在说一件事，但他们的词语是“编码”过的——对某些读者来说意味着其他含义。例如，有人可能会写：“那些北极熊总是毁掉我们的粥。”对大多数读者来说，这似乎是对熊和食物的抱怨。但对某些群体来说，它实际上在说完全不同的事情。（实际评论内容并非关于熊。）你可以通过告诉Respectify禁止什么来避免这种情况。根据你的网站、主题和受众进行定制。
使用Anthropic的MCP（托管定制计划）的AI代理可能由于工具加载方式导致API成本超支。MCP会在每个会话开始时预加载*所有*工具定义（作为冗长的JSON模式），消耗大量token。使用CLI工具和CLIHub展示了一种更有效的方法——“延迟加载”，仅在需要时加载工具详情。
CLI使用轻量级的技能列表，而不是大量的预加载模式。虽然通过“--help”命令发现工具用法最初会消耗token，但总体使用量显著减少。测试表明，即使与Anthropic较新的“工具搜索”功能相比（该功能提供了一些改进，但仍然在获取工具时加载完整的模式），CLI使用的token最多可减少94%。
CLIHub提供现有CLI的目录，并提供转换器，可以轻松地从MCP定义生成CLI，为管理代理工具提供了一种更便宜、与模型无关的替代方案，优于MCP和工具搜索。
## AI 代理：MCP 与 CLI 总结
这次 Hacker News 讨论的核心是，使用微软连接器协议 (MCP) 与 AI 代理直接使用命令行界面 (CLI) 工具的效率。主要观点是，**在某些情况下，CLI 工具可以比 MCP 更便宜、更有效。**
MCP 的问题在于其上下文窗口膨胀。每个 MCP 工具的描述都会随*每次*请求发送，消耗宝贵的 token。此外，MCP 工具不易组合——数据处理通常需要繁琐的转储。**然而，模型已经理解 CLI（经过 shell 命令训练），并且允许通过管道（如 `jq` 或 `grep`）进行脚本编写和数据处理，从而减少 token 使用。**
许多评论员强调了 `mcpshim` 和 `clihub` 等项目，旨在通过为 MCP 工具创建运行时代理或将它们编译为可移植的 CLI 来弥合这一差距。虽然 MCP 提供标准化的身份验证层，但许多人认为，**CLI 的优势——降低上下文成本、可组合性和模型现有熟悉度——超过了 MCP 的便利性**，尤其是在开发者工作流程中。
最终，讨论指向一个未来，代理将利用定义明确的 CLI 工具网络，并可能辅以标准化的身份验证方法，而不是严重依赖 MCP 的广泛工具定义。
启用 JavaScript 和 Cookie 以继续。
## 去虚拟化与静态多态：总结
这次Hacker News讨论围绕优化多态的技术，尤其是在C++和Rust中。传统上，多态依赖于虚拟表（vtables）和指针（vptrs），添加到每个对象实例中，从而实现动态分派。但这会引入运行时开销。
Rust提供了一种替代方案，即“胖指针”——只有在*需要*动态分派时才携带vptrs，避免了每个实例的成本。C++也有类似的方法，例如类型擦除库，允许内联vtables。
核心思想是平衡静态（编译时）和动态（运行时）分派。静态分派更快但灵活性较差，而动态分派以性能为代价提供可扩展性。Rust允许在这两种模式之间切换，转换为`&dyn Trait`进行动态分派，然后再转换回来。这对于避免模板实例化（单态化）造成的过度代码膨胀，同时仍然在必要时启用动态行为非常有用。
最新的C++标准（C++23的“deducing this”）也旨在减少动态分派开销。其他替代方案，例如对vtables进行完美哈希，以及使用`std::variant`（在现代C++中），在编译时已知可能的类型时，可以提供进一步的性能提升。讨论强调了在实现多态性时，性能、灵活性和代码复杂性之间的权衡。
LINEX BETA
0
00:00
WhatsApp
Telegram
Email
QR
LINEX
: . /7.
## Linex：一款移动优先的益智游戏
Humanista75分享了Linex（playlinex.com），这是一款使用HTML、JavaScript、MySQL和PHP构建的新网页游戏，专为移动浏览器设计。核心玩法是在8x8棋盘上放置俄罗斯方块风格的方块来消除行，但具有独特的机制。
与典型游戏不同，Linex通过随机出现的障碍单元格来逐步增加难度，迫使玩家采取适应性策略。玩家拥有有限使用的工具来帮助克服挑战。每日挑战由日期决定，确保每个人面临相同的序列，难度随着一周的推移而增加。排行榜允许基于消除的行数和速度进行全球和私人的竞争。
初步反馈指出存在注册障碍（现已移除）、桌面游玩的用户界面/用户体验考虑以及翻译问题（已修复）。开发者欢迎对难度、方块放置和平衡性的反馈。该游戏现已在HN Arcade上发布，并引发了关于采用逐点点击放置方块的有意设计选择，以提高控制力和战略思考的讨论。
展示 HN：Django-xbench – Django 的慢端点聚合
Show HN: Django-xbench – slow endpoint aggregation for Django
2 天前
## django-xbench：轻量级 Django 请求性能分析
django-xbench 是一个零代理的 Django 中间件，旨在快速识别性能瓶颈，提供 APM 风格的洞察，而无需完整 APM 解决方案的复杂性。它测量并暴露请求时间分解——特别是数据库时间与应用程序/序列化时间——以及执行的数据库查询数量。
主要功能包括：近乎零配置（只需添加中间件），注重隐私的指标（仅暴露时间戳和查询计数，不暴露查询内容），以及通过 Chrome DevTools 中的 Server-Timing header 进行的可视化。可选的日志记录提供每个请求的指标，并且一个实验性的内存慢端点聚合功能提供了一个基本仪表盘，用于识别性能热点。
django-xbench 可以通过 pip 轻松安装，并支持可配置的设置，用于日志记录、慢端点聚合和桶大小调整。它非常适合本地开发和内部调试，提供清晰的视图，了解 Django 请求中时间的消耗情况。
需要 Python 3.9+ 和 Django 3.2+（在 5.2 上测试过）。
```html
<!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>错误 502（服务器错误）!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
</style>
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p><b>502.</b> <ins>这是一个错误。</ins>
<p>服务器遇到临时错误，无法完成您的请求。请30秒后重试。 <ins>我们所知道的就只有这些。</ins>
```