在与朋友前往西安旅行时，由于手机没电且简化版龙与地下城游戏需要随机数，他们想出了一个独特的掷骰方法。他们仅利用身体，并受到一个旅游陷阱的启发，运用极坐标来生成伪随机数。
核心思想是两位玩家同时在单位圆上提出角度。角度差经过标准化和调整后，模拟掷骰结果。为了实用性，系统简化为12面的“时钟”，角度差直接对应骰子点数（1-6）。Lua实验证实了接近公平的概率，尽管存在轻微差异。
除了龙与地下城，他们还创造了“口头网球”，一个基于耐力的游戏，掷骰决定成功的回击，为影响结果增加了耐力消耗的策略层面。
虽然这种方法并非完美——需要玩家利益冲突以保证公平性，且仅限于d6——但它为在没有常规工具时生成随机数提供了一种有趣且低科技的解决方案。
每日HackerNews RSS
## 双人骰子模拟 - Hacker News 摘要
最近 Hacker News 的讨论集中在一个方法上，该方法使用两个人以及他们生成随机数的能力来模拟公平的骰子投掷。核心思想是每个人选择一个数字，将它们组合起来，并应用模运算以获得 1 到 6 之间的结果。
然而，评论者很快指出该方法的复杂性和潜在的低效性。许多人建议更简单的替代方案，例如直接相加数字并取模，或者甚至使用石头剪刀布来生成位。一个关键的争论点在于真正无偏随机数生成器的假设——如果双方*能够*生成无偏数字，问题就变得微不足道。
提出了几种替代方法，包括使用扑克牌、承诺方案（以防止作弊）以及平方根等数学函数。讨论强调了使用人类输入实现真正随机性的困难，以及这些模拟中复杂性和公平性之间的权衡。最终，共识倾向于更简单的方法来实现类似的结果，优先考虑实用性而非数学上的优雅。
问题状态描述： 重现步骤：邀请 nel0x 来这里寻求帮助，继续进行设置、构建和发布。 * 使用旧维护者签名允许吗？ * 我们可以玩签名吗？ * 恢复 GitHub Actions 工作流 * 联系 F-Droid 以继续发布 一般问题： * Syncthing 分叉的名称可以接受吗，还是应该更改？ App 版本：123 App 安装来源：请参阅 wiki 以了解发布渠道 GitHub 或 F-Droid 发布版本 Android 版本：123 ROM 供应商：123 设备制造商：无响应 设备型号：无响应 设备平台信息（可选） Android 日志 (logcat) 👀React with 👀1user334
经过五年后，Scribd 已经退役了其内部数据摄取工具 `kafka-delta-ingest`，尽管它最初成功地将流数据成本降低了 95%。该项目催生了 `delta-rs`，一个流行的 Rust 开源库，用于与 Delta Lake 表交互——此前仅限于 Apache Spark。 虽然 `kafka-delta-ingest` 实现了其目标，但更新的基础设施以及作者的 “oxbow” 套件和中介数据架构进一步将摄取成本降低到总数据平台支出的 10% 以下。随着 Scribd 上其他 Kafka 消费者消失，该工具的价值降低，基于 Kafka 的专用摄取变得不那么划算。 虽然在 Scribd 已经不再需要，但维护者将继续通过 `kafka-delta-ingest` 更新 `delta-rs` 以进行测试。该工具可能对*已经*使用 Kafka 的组织有用，但不建议将其作为采用该平台的唯一理由。
一个名为“kafka-delta-ingest”的项目，旨在高效地将数据从Kafka持久化到Delta Lake（使用Parquet格式），由于运行Apache Kafka的固有成本，将被停止。正如Hacker News讨论中提到的，随着组织内其他使用Kafka的应用消失，该项目价值降低，Kafka仅用于数据摄取——这是一种代价高昂的目的。
评论者们一致认为Kafka可能消耗大量资源，并建议使用WarpStream和Oxbow等替代方案来构建纯粹的摄取管道。尽管项目已结束，贡献者们强调了delta-rs相关库的工作价值。总体 sentiment 是，Kafka最适合在支持多个应用时使用，而当仅需要数据摄取时，应考虑更精简的解决方案。
机器学习的最新进展，特别是大型语言模型（LLM），在**持续学习**方面仍然面临挑战——即在不遗忘先前知识的情况下持续学习的能力，而人脑则通过神经可塑性擅长于此。当前的LLM在更新新信息时会面临“**灾难性遗忘**”问题，牺牲过去的学习成果。 研究人员通常通过架构改变或改进训练方法来解决这个问题，但往往将它们视为独立的实体。一种新的方法，**嵌套学习**，在NeurIPS 2025论文中提出，统一了这些概念。它将模型视为相互关联的多层学习问题，并*同时*进行优化，认识到架构和优化是同一过程的不同层次。 这允许更深层的计算深度和更高的学习效率，从而减轻灾难性遗忘。一个概念验证模型“Hope”展示了优于现有模型的语言建模和长上下文记忆能力，验证了嵌套学习构建更具适应性和能力的AI的潜力。
## 嵌套学习：一种新的持续学习方法
最近的一篇谷歌研究论文介绍了“嵌套学习”，这是一种新的机器学习范式，旨在改进持续学习——模型学习新任务而不忘记旧任务的能力。其核心思想是冻结预训练的Transformer模型（“骨干”），并在其之上仅训练新添加的“记忆路径”（HOPE/TITAN/CMS模块）。
这种方法允许类似适配器的微调，利用现有的模型知识，同时适应新的信息。一个开源复现尝试正在进行中 ([https://github.com/kmccleary3301/nested_learning](https://github.com/kmccleary3301/nested_learning))。
讨论的中心在于这是否只是用新术语描述的梯度下降，以及它在多大程度上有效地解决了遗忘问题。相关的谷歌研究，例如TITAN，也被提及。 一种关于英伟达通过结合扩散和自回归实现6倍性能提升的说法正在流传，现在找到了来源 ([https://arxiv.org/abs/2511.08923](https://arxiv.org/abs/2511.08923))。 一些人认为，这种方向——重用训练好的模型并进行架构增强——对于未来的AI发展至关重要。
启用 JavaScript 和 Cookie 以继续。
最近Hacker News上的一项发现强调了真核生物的新温度记录：地热阿米巴*Incendiamoeba cascadensis* 可以在63°C (145.4°F) 的温度下繁殖。虽然这令人印象深刻，但评论员指出，古菌和细菌可以在显著更高的温度下生存——高达*Methanopyrus kandleri* 的122°C。
讨论的重点是这种耐热生命的影响。用户指出，这扩展了生命生存的可能性，即使在太阳最终膨胀成红巨星等极端事件中。其他人推测了完全灭绝的挑战，以及旨在消灭地球生命的假设外星力量所面临的困难。对话还涉及生命在这些事件发生之前扩展到地球之外的可能性，也许是扩展到我们太阳系的较冷区域或其他恒星系统。
## LeetCode 年度总结：你的代码一年 LeetCode 年度总结 (网址：leetcodeWrapped.com) 是一个个性化的“Spotify Wrapped”风格的 LeetCode 活动回顾。它使用 React、Vite 和 Framer Motion 构建前端，使用 Cloudflare Pages Functions 和 Firebase 构建后端，以可视化你的编码统计数据。 该应用通过 LeetCode GraphQL API 获取数据，并（可选）将用户数据存储在 Firebase 中。它通过交互式幻灯片展示你的提交记录、难度分布等信息。 目前，未认证用户的数据仅限于最近 20 次提交。但是，提供 LeetCode 会话 Cookie 可以解锁访问*所有*提交记录，从而进行更详细的年度分析。开发者根据社区兴趣考虑过 Chrome 扩展程序来处理 Cookie。 数据分析使用 Posthog 跟踪，电子邮件通知通过 Firebase 扩展程序发送，但也可以在本地使用，无需这些功能。
Hacker News上有一个新项目，灵感来自Spotify Wrapped，它可视化用户在LeetCode上的活动（github.com/collinboler）。LeetCode最初被认为是那些寻求在FAANG公司工作的人的面试准备，但现在已经发展成为许多开发者的日常习惯，这得益于像连胜和竞赛这样的游戏化功能。
讨论表明，LeetCode不仅仅面向学生；一些高级开发者用它来保持技能或探索新的编程语言。还有人把它当作一种智力锻炼，类似于填字游戏，享受解决问题的乐趣。一个蓬勃发展的竞技编程社区也存在，人们参与其中是为了这项运动本身，与就业前景无关。
目前该项目需要用户输入LeetCode的cookie，引发了信任问题。创建者正在考虑一个Chrome扩展来解决这个问题，但他承认这可能会与用户采用产生摩擦。LeetCode本身提供了一个年度“回顾”功能，但与该项目旨在提供更详细、累积的统计数据相比，它的可重玩性和范围都有限。
## 估算困境：开发者 vs. 产品负责人 本文探讨了开发者和产品负责人之间关于任务估算固有的紧张关系。产品负责人（POs）依赖估算来确定 backlog 的优先级、管理发布期望以及平衡风险/回报——尤其是在协调多个团队和预先沟通的截止日期时。如果没有估算，POs 可能会交付用户不需要的功能或错过关键的发布日期。 然而，开发者通常*不喜欢*估算。核心问题在于软件开发的不可预测性。估算本质上是不确定的，但经常被视为明确的截止日期，导致估算被虚报并信任度降低。开发者优先考虑代码质量和解决技术债务，而产品负责人——缺乏技术专长——可能低估这些，从而进一步使准确估算变得复杂。 作者认为问题不在于估算本身，而在于估算*如何*被使用。将估算视为预测会造成压力并降低心理安全感。更好的方法是在开发过程中透明、持续地沟通更新后的估算，同时采用 DevOps 原则来改进工作流程并主动管理技术债务。最终，理解彼此的压力——POs 需要计划，开发者追求质量——是实现更健康、更高效的开发过程的关键。
## 布局为何困难 网页布局出乎意料地复杂，这源于众多相互作用的因素，而不仅仅是定义元素*应该*如何呈现。CSS虽然看似简单，却充斥着细微的规则，这些规则源于数十年的设计经验，旨在解决现实世界的边缘情况。 例如，`text-align: center`——它优先考虑防止文本溢出小容器，默认采用左对齐，这看似奇怪的特性实际上提高了可用性。这说明了一个关键点：布局不仅仅是关于理想情况，还在于优雅地处理屏幕尺寸、字体渲染差异，甚至语言变化（德语与中文词长）等约束。 这些“隐式规则”通常源于历史实践——例如报纸编辑为了避免不自然的排版而改写文本——并被写入规范。虽然纯粹的约束型系统*看起来*更简洁，但它可能会忽略这些关键的、来之不易的设计决策。最终，成功的布局依赖于这种内嵌的知识，使其成为一个充满挑战的领域，其中不可避免地会出现意想不到的行为。
在添加新功能之前，作者优先简化了底层代码，以便更容易扩展。他们将编程视为两个部分：定义*需要做什么*，以及*如何高效地表达它*。然而，真正的效率并非关于优化的代码速度，而是最小化整个开发生命周期中的*人力成本*——包括打字、调试、修改和适应。 作者提倡一种“压缩导向”的方法，类似于字典压缩器如PKZip。他们不是预先创建可重用的代码，而是首先专注于编写特定的解决方案。可重用性是在*识别出重复代码之后*才出现的——有效地“压缩”它。这避免了在可能不需要的抽象上浪费精力。 当出现重用机会时，代码要么按原样使用，要么经过深思熟虑地修改/分层。这产生简洁、易读的代码，它反映了问题的自然语言，并且更容易维护和扩展。这种自下而上的方法，从具体细节开始，避免了过早架构规划的陷阱，并最终导向更健壮、更高效的代码库。
一个黑客新闻的讨论围绕着凯西·穆拉托里2014年关于“语义压缩”的文章，该文章提倡编写优先考虑简单性并避免过早工程的代码。 许多评论者对只构建必要内容并抵制在功能被证明之前进行代码重复的做法表示赞同。
这篇文章似乎挑战了流行的面向对象编程（OOP）趋势，允许开发者避免复杂的抽象。 然而，一位评论者强烈不同意，为OOP在大型代码库和抽象方面的优势辩护，并以Ruby和Rails作为成功的OOP实现案例。
其他人指出文章示例的背景——一个没有业务需求或数据库问题的项目——并警告说，自下而上地构建并非总是可行的，尤其是在协作的现实场景中。 此次对话凸显了务实、简约编码与OOP结构化方法之间的紧张关系。