客户端挑战：您的浏览器已禁用 JavaScript。请启用 JavaScript 以继续。网站的必要部分无法加载。这可能是由于浏览器扩展、网络问题或浏览器设置造成的。请检查您的连接，禁用任何广告拦截器，或尝试使用不同的浏览器。
每日HackerNews RSS
## 巨型蟒蛇：长久的历史
剑桥大学的一项新研究表明，蟒蛇已经保持了巨大的体型超过1200万年。这项研究在Hacker News上讨论，引发了关于为什么这些蛇类——以及鲨鱼——尽管全球变化影响了其他巨型动物，但却没有显著进化的话题。
用户们争论了潜在的原因，包括环境限制了最大体型以及蟒蛇现有身体结构的效率。一些人质疑为什么没有显著的捕食者进化来捕食它们，考虑到它们所代表的卡路里价值。
讨论也转向了恐惧的心理学，用户们分享了个人经历和理论，解释了为什么蛇和蜘蛛在某些人身上会引起如此强烈的反应，而另一些人则毫无恐惧。理论从童年印记到先天反应，甚至包括潜在的产前经历。一个相关的讨论涉及了英国法律对某些用户访问研究链接的影响。
## 古代蟒蛇：令人惊讶的稳定巨型生物 在委内瑞拉的一项新化石发现表明，蟒蛇至少在1240万年前就保持了其令人印象深刻的体型，可追溯到中到上新世时期。研究人员分析了183节化石椎骨，发现古代蟒蛇的长度为四到五米——几乎与现代蟒蛇相同。 这一发现挑战了之前关于较温暖的新世气候将支持更大的蛇类的假设。尽管该时期其他巨型爬行动物，如巨大的凯门鳄和乌龟，随着气温下降而灭绝，但蟒蛇却表现出惊人的适应力。 该研究表明，这种稳定性与蟒蛇专门的生态位有关：南美洲北部沼泽湿地环境，富含鱼类和水豚等猎物，在数百万年来一直相对稳定。这项研究建立了一个关键的时间线，证实蟒蛇在其进化历史的早期就达到了巨型体型，并一直保持至今。
我们对模式提供了一种现代视角。对于设计模式的一个常见批评是它们不必要地增加了复杂性。我们的观点是，模式对于解决特定问题很有价值，通常有助于向人类传达代码问题中的共性。如果一个项目没有这些问题，就没有必要应用它们。模式也可能非常依赖于语言或框架（例如 React），这通常意味着思考超越最初的 GoF 设计模式的范围。我们帮助您扩展 Web 应用程序的性能。了解用于更有效地加载代码的 Web 性能模式。不确定如何思考现代化的加载或渲染用户体验方法？我们为您提供支持。
VCMI是《英雄无敌III》的一个开源引擎，提供新的和扩展的可能性。要使用VCMI，你需要拥有原始数据文件。下载 新闻 论坛 前往VCMI-Discord
## VCMI：英雄无敌3的复兴
VCMI是一个开源引擎，重现了《英雄无敌3》（[vcmi.eu](https://vcmi.eu)），作为游玩这款经典策略游戏的有效途径，尤其是在Mac和Android等兼容性可能存在问题的平台上，它正逐渐受到欢迎。用户反馈体验流畅，避免了使用Wine或模拟器的问题。
最初VCMI对流行的《深渊号角》（HotA）模组支持不完全，但现在已经存在部分移植版本。讨论强调了VCMI的可访问性和稳定性，一些人指出AI仍然比较简单，但有模组可以改进它。
这个项目唤起了人们对《英雄无敌》系列的怀旧之情，有些人更喜欢带有HotA的原始游戏，而另一些人则欣赏VCMI的原生可玩性和潜力。它也引起了人们对《fheroes2》的关注，这是一个为《英雄无敌2》开发的类似项目。社区指出，这款游戏在东欧和拉丁美洲的部分地区非常受欢迎，但在美国则相对较少。
## OpenRouter 广播：LLM 使用情况监控 OpenRouter 的“广播”功能允许自动将来自您 LLM 请求的详细跟踪数据发送到各种可观察性和分析平台——无需代码更改。只需在您的 OpenRouter 控制面板中启用该功能并添加您想要的目的地。 **主要特点：** * **全面数据：** 跟踪数据包括请求/响应数据、token 使用量、成本、时间、模型信息和工具使用情况。 * **定制化：** 使用 `user_id` 和 `session_id` 丰富跟踪数据，以获得更好的上下文。按 API 密钥过滤跟踪数据，并调整每个目的地的采样率以管理数据量和成本。 * **安全性：** 凭据已加密，并且跟踪数据传输是异步的，确保不会增加延迟。 * **组织支持：** 管理员可以配置共享目的地，以实现团队范围内的统一可观察性。 **当前支持的目的地：**（请查看控制面板以获取最新列表） **即将推出：** Arize, AWS Firehose, Clickhouse 等更多。 有关 Langfuse、LangSmith、Datadog 等目的地的详细操作指南已提供。
## OpenRouter 讨论总结
OpenRouter 是一款新的 AI 聚合平台，旨在简化对各种 LLM（以及潜在的图像/视频模型）的访问，正在 Hacker News 上引发讨论。虽然它因“发射后即忘”的便利性——无需管理多个 API 密钥——而受到赞扬，但许多用户批评其名称中使用“Open”，认为这具有误导性，因为该平台是闭源的。
用户表达了对真正开源替代方案或能够自托管 OpenRouter 的愿望。一些人建议使用现有的解决方案，如 borgllm 和 Hugging Face 推理提供程序，作为提供更多控制权的替代方案。
讨论还涉及了公司使用“Open”作为前缀但并非真正开放的模式，并指出了创始人与 NFT 平台 OpenSea 的历史。另一个帖子强调了 OpenRouter 与 WhyLabs 的集成，鉴于 WhyLabs 报告的关闭，这引发了对其未来的质疑。总体而言，人们对该*概念*持积极态度，但对该品牌表示怀疑。
启用 JavaScript 和 Cookie 以继续。
## 用于增强SaaS安全性的分片：摘要 现代SaaS平台面临“全面”数据泄露的风险，影响大量用户。因此，一个关键的安全原则是**爆炸半径降低**——设计系统以限制任何单一泄露的影响。本文重点介绍了**分片**，即将数据划分为分区，作为实现这一目标的关键策略。 分片最初是一种可扩展性技术，现在越来越被认为是安全控制。有效的分片不仅仅是数据*如何*分割，而是*怎样*分割。传统方法按租户、地理位置或产品进行分片。然而，**Mimir的“按用户访问分片”模型**提倡将分片与实际的安全边界对齐——谁被授权查看什么。 该模型采用结构和密码隔离相结合的方式，确保服务器即使被攻破，也永远不会拥有足够的信息来访问超出用户权限的数据。它利用客户端加密和限定在访问域内的密钥，将泄露的影响限制在特定分片。 最终，分片，特别是与零信任原则相结合，将重点从周界安全转移到以数据为中心的保护，将潜在的灾难性泄露转化为有界且可审计的事件。首席信息安全官应根据最大泄露单位以及向审计员展示这些保证的能力来评估其架构。
## SaaS 安全与可扩展性的数据库分片
一则 Hacker News 讨论探讨了在 SaaS 应用中使用每个客户一个专用数据库的做法——即分片。其目的是隔离客户数据，简化合规性、迁移和资源监控，并限制潜在数据泄露的“爆炸半径”。
多位评论者分享了使用这种方法的积极经验，尤其是在使用 Microsoft SQL Server 和 MySQL 时。优点包括更轻松的审计、独立的客户迁移和简单的监控。然而，也存在挑战。在众多数据库（“分片模式漂移”）中保持模式一致性需要强大的自动化和声明式模式管理工具。
管理开销、扩展连接限制和成本优化也是需要考虑的问题。管理配置并将请求路由到正确的数据库会增加复杂性，但现代工具（如集中式授权服务和反向代理）可以缓解这一问题。一些人建议对较小规模的部署使用 SQLite 为每个客户提供服务。最终，讨论强调了虽然分片功能强大，但它需要严格的运维纪律，并不适用于所有情况。
## Common Lisp 加载与系统：总结 Common Lisp 的文件处理和代码加载可能令人困惑，这源于其历史和妥协。标准定义了使用“名称字符串”和“路径名”的基本文件访问，但代码加载依赖于 `LOAD`，其行为在不同实现中有所不同。编译为 `.fasl` 文件可以加速加载，通过预解析代码实现。 除了标准之外，像 ASDF 和 Quicklisp 这样的工具简化了依赖管理。ASDF 定义了“系统”——本质上是库——并处理加载依赖项。系统不是 Lisp 的核心特性，而是一种组织 `LOAD` 和 `COMPILE-FILE` 调用方式。Quicklisp 建立在 ASDF 之上，增加了从互联网下载系统的能力。 重要的是，Common Lisp 使用 **包 (packages)** 作为符号的命名空间，与系统分离。一个好的做法是使用 ASDF 的 `package-inferred-system` 功能，让文件直接定义包，从而简化系统定义。 对于项目设置，将你的代码目录符号链接到 `~/.local/share/common-lisp/source` 允许 ASDF 找到你的系统。Quicklisp 管理外部依赖项，并且像 `~/quicklisp/local-projects` 这样的中心位置可以容纳 Quicklisp 本身中找不到的依赖项。 为了更深入的理解，建议研究 ASDF 和 Quicklisp 的源代码。
这个Hacker News讨论围绕Common Lisp的包和依赖管理。虽然Quicklisp是事实上的标准，但对话强调了它的局限性并探讨了替代方案。ASDF是核心的包加载机制，而Quicklisp充当包装器和管理器。
用户们争论使用Quicklisp与手动使用`curl`下载包并通过ASDF管理它们的优缺点，涉及安全问题（供应链攻击）和版本控制。一些人提倡使用更现代的包管理器，如OCICL或Qlot，来处理版本锁定，这是Quicklisp所缺乏的功能。
一个反复出现的主题是Common Lisp中独特的、有时是过时的命名约定（例如，“system”与“package”）。社区承认生态系统的稳定性通常降低了对严格版本控制的*需求*，但也指出了测试框架的不足。最终，讨论揭示了一个充满活力但有些怪异的生态系统，其中“自己动手”的解决方案很常见，这可能会阻碍更广泛的采用。
受够了谷歌地图上带有偏见的餐厅推荐，数据科学家劳伦·利克构建了一个机器学习模型，分析了大伦敦地区的每家餐厅。这个项目演变成对数字平台如何影响地方经济的调查，揭示了一个“算法市场”，餐厅的可见度极大地影响其成功。 利克的分析表明，谷歌地图不仅仅*反映*受欢迎程度，而是通过排名信号主动*塑造*它——相关性、距离，以及关键的“显著性”（基于评论、品牌认知度和网络可见性）。这为成熟的企业和连锁店创造了累积优势，而新的独立餐厅则面临“冷启动”问题。 为了量化这一点，利克开发了一个模型，根据结构特征预测预期的评分，从而识别出表现高于或低于算法预期的餐厅。这些数据被可视化在一个公共仪表板上，允许用户发现“被低估的瑰宝”。进一步的分析绘制了伦敦的“餐厅生态系统强度”，揭示了烹饪多样性的不均衡分布，通常与移民模式和可负担性相关联。 最终，利克认为像谷歌地图这样的平台拥有巨大的经济影响力，因此有必要对排名算法进行透明化和可审计性，作为地方经济政策问题。
## Google 地图与餐厅可见性：摘要
最近的一项分析探讨了 Google 地图的算法如何影响伦敦的餐饮业，认为它已经超越了简单的目录，成为一个“市场创造者”。作者发现，在 Google 地图上的可见性并非中立，它倾向于成熟的连锁店和高流量区域，因为它们具有累积的认知度和更快的评论生成速度。这形成了一个反馈循环，已经受欢迎的地方变得*更*可见，可能会阻碍独立餐厅的发展。
Hacker News 的评论讨论强调了用户对 Google 地图搜索功能的不满——特别是放大时难以找到商家，以及对 Apple 地图或 OpenStreetMap 更全面列表的偏好。许多评论员也对个性化推荐的下降表示遗憾，将当前的算法与 Google 和 Netflix 早期更量身定制的方法进行了对比。
一个主要关注点是 Google 排名系统的缺乏透明度和可审计性，以及它对公平竞争的潜在影响。一些用户分享了关于评论操纵的经历，以及对平台算法在本地发现中日益增长的依赖，质疑这最终是否会限制选择和创新。 这篇文章引发了关于便利性、算法控制以及支持多元化本地生态系统之间平衡的争论。
## VoxCSS：一个基于CSS的3D体素引擎
VoxCSS是一个轻量级的JavaScript库，使用CSS变换直接在DOM中创建3D体素艺术。它通过堆叠网格层渲染HTML长方体，提供了一种在没有WebGL的情况下构建3D场景的简单方法。
主要特性包括对颜色、纹理、交互控制的支持，以及像剔除和体素合并这样的性能优化。你可以使用体素数组定义场景，指定坐标、形状（立方体、斜坡、楔形、尖峰）、颜色和纹理。
VoxCSS与框架无关，可以与Vue、React、Svelte或纯JavaScript无缝协作。专用的组件，如`<VoxCamera>`和`<VoxScene>`简化了集成。它还包含一个内置的解析器，用于加载MagicaVoxel (.vox) 文件。
性能通过仅渲染可见面，并可选地将相邻体素合并成更大的元素来管理，这对于复杂的场景尤其有益。 了解更多信息并探索示例，请访问[voxcss.com](voxcss.com) 或通过npm安装：`npm install @layoutit/voxcss`。