Hacker News 每日播报

Hacker News 每日播报，今天我们聚焦一系列引人入胜的技术探讨、社会观察与数学奥秘。

在没有 IPv4 连接的情况下使用互联网

今天我们来聊一篇来自 James McMurray 博客的文章，标题是《在没有 IPv4 连接的情况下使用互联网》。文章的起因是作者家中遭遇停电后，发现家里的网络连接出现了问题：IPv4 连接完全中断，但 IPv6 连接却工作正常。这导致很多网站无法访问，因为它们仍然只支持 IPv4。由于 ISP 表示修复需要几天时间，作者决定利用手头的资源——一台拥有静态 IPv4 和 IPv6 地址的 Hetzner VPS——来自己解决问题，目标是通过 IPv6 连接建立一个隧道，让 IPv4 流量能够通过这个隧道传输，从而恢复完整的互联网访问能力。

文章首先解释了网络地址转换（NAT）和运营商级 NAT（CG-NAT）的概念，以及为什么 IPv4 地址枯竭导致了这些复杂且可能出现故障的机制。相比之下，IPv6 地址空间巨大，通常不需要 NAT，这也是为什么作者的 IPv6 连接未受影响的原因。

核心解决方案是使用 WireGuard 建立一个 VPN 隧道。作者在 Hetzner VPS 上配置 WireGuard 服务器，使其能够接收来自客户端的连接，并将隧道内的流量通过 VPS 的公共 IPv4 和 IPv6 地址转发出去。他详细展示了服务器端和客户端的 WireGuard 配置，包括如何设置地址、密钥、监听端口以及关键的 PostUp/PostDown 脚本，这些脚本使用 iptables 和 ip6tables 来实现流量的转发和 NAT（对于 IPv4 是必须的，对于 IPv6 可以选择使用 NAT 或直接路由公共地址块）。他提到了使用 MASQUERADE 和 SNAT 的区别，并展示了如何配置 WireGuard 客户端将所有流量 (0.0.0.0/0, ::/0) 都路由到这个隧道。

解决了基本的互联网访问后，作者面临了更复杂的挑战：如何让工作 VPN 和 Docker 在这个环境下工作。他利用 Linux 的网络命名空间（network namespaces）来隔离工作 VPN 的流量，使其通过 WireGuard 隧道而不是直接尝试连接。他使用了自己的工具 vopono 来辅助创建和管理命名空间，并解释了如何在命名空间内配置独立的 DNS 解析。

运行 Docker 在网络命名空间内则遇到了 /sys 挂载的问题。作者分享了一个巧妙的 unshare 和 bind mount 技巧，使得在 ip netns exec 创建的命名空间内，/sys 能够正确地指向宿主机的 /sys，从而允许 Docker daemon 正常启动和运行。

最后，作者遇到了一个棘手的调试问题：WireGuard 连接有时工作不正常，表现为小包（如 ping）正常，但大包（如网页加载）失败。通过不同大小的 ping 测试，他诊断出这是 MTU（最大传输单元）问题。WireGuard 的封装增加了包的大小，如果超过了路径中某个环节的最小 MTU，包就会被丢弃。由于 PMTUD（路径 MTU 发现）常常被防火墙阻拦，手动设置一个较低的 MTU（如 IPv6 规范保证支持的 1280）解决了问题。

文章总结了通过这些步骤成功恢复了完整的互联网连接，强调了 Linux 在解决复杂网络问题上的强大灵活性和“自己动手”的优势，并推荐了 Hetzner VPS 和考虑使用 OpenWRT 路由器来增强网络控制能力。

社区观点

许多读者分享了自己遭遇 ISP CG-NAT 带来的困扰，认为文章提供的 WireGuard 隧道方案是一种有效的规避方法。关于 WireGuard 配置的细节，特别是 NAT 规则和 IPv6 的处理方式，引发了技术讨论，有经验的用户提供了优化建议。将工作 VPN 和 Docker 运行在网络命名空间内的技巧，尤其是解决 Docker /sys 挂载问题的 unshare 技巧，被认为是文章的亮点。文章对 IPv6 普及现状的提及，以及像 GitHub 这样的大型服务仍然依赖 IPv4 的事实，再次引发了关于 IPv6 部署进展和挑战的讨论。总的来说，大家高度评价这篇文章解决实际问题的技术深度和实用性。

用 Haskell 解决“护照申请”问题

这篇文章的作者将英国护照申请过程巧妙地比喻成一个由“国王陛下护照办公室”（HMPO）开发的复杂冒险解谜游戏，名为《护照申请》。这个游戏价格不菲，在线版本设计极简（纯文本），但几乎所有英国人每隔十年都会玩一次。游戏的目标是收集散落在各官僚机构的“文物”（文件），以证明“申请人是英国人”，依据的是一套写在各种“议会法案”中的晦涩规则。游戏的奖励是一本小册子，上面写着下次可以玩的时间。

文章详细描述了游戏的各种“有趣”机制和支线任务：

• 身份确认支线： 需要找到特定职业（如会计师、脊足病医生、殡葬承办人等）且认识你的人来填写表格。
• 文件收集： 核心机制是提交“原始”文件。非英文文件需要官方认证翻译，这可能触发复杂的跨国文件收集任务。
• 家庭合作模式： 某些文件涉及家庭成员，需要全家参与。
• 与其他机构互动： 从其他官僚机构获取文件本身也是一个挑战。

游戏过程充满不确定性。申请由一位“审查员”处理，他们根据自己对规则的理解发出文件请求。玩家无法直接与审查员沟通，只能通过聊天或电话与“咨询代理”交流。代理的建议非官方，转达问题给审查员需要数天甚至十天，增加了悬念。作者的经历中，最初请求的文件有一半被告知是不必要的，这被视为游戏中的“误导”。文件请求邮件通常伴随含糊的解释，增加了游戏的难度和趣味性。

文章的核心技术分析在于揭示HMPO使用的“官僚逻辑”。作者认为这是一种构造性逻辑（Constructive Logic），不同于经典逻辑。在经典逻辑中，P或非P（P∨¬P）总是真的，但在官僚逻辑中，你不能仅仅论证“申请人的父亲的父亲出生在英国或不在英国”，然后为两种情况都提供文件。你必须选择一种情况，并提供相应的“原始文件”作为“证据”（witness）。游戏的目的不是证明公民身份本身，而是收集文件。

官僚逻辑的另一个关键点是，HMPO不完全信任自己的护照记录来证明英国身份。这导致了文件请求的“递归”机制：为了证明申请人的英国身份，可能需要证明其父母的英国身份；为了证明父母的，可能需要证明祖父母的，以此类推，直到追溯到满足“基础情况”的祖先。基础情况通常是1983年前在英国出生的人（无条件英国公民）或归化入籍的人。随着时间推移，离1983年越远，这种递归链可能越长。

作者以自己为女儿申请护照的经历为例，展示了这种递归如何通过邮件展开，最终被要求提供“申请人父亲的父亲的父亲”（即曾祖父）的出生证明和结婚证明，尽管这些文件已近百年历史。

为了理解并预测所需文件，作者决定用编程语言对规则进行建模。最初考虑Prolog，最终选择了Haskell的LogicT monad。目标是找到所有可能的英国身份“证明”（Proof），并为每个证明计算所需的“文件集”（Set Document）。作者定义了表示人物关系（Applicant, Parent）、文件类型（BirthCertificate, MarriageCertificate等）和谓词（IsBritish, BornInUK, Settled等）的数据类型。使用StateT Claims (LogicT IO)来管理已知事实（Claims）并支持交互式提问，同时探索所有可能的证明路径。

核心Haskell代码片段展示了如何编码英国国籍法的简化规则，例如通过出生（在英国或海外）、归化、或通过父母继承。viaParent函数处理通过父母继承的情况，并考虑了2006年前后“非婚生”子女的规则差异。check函数用于在需要时向用户提问。

运行代码后，程序会进行一系列交互式提问，然后输出申请人可能拥有的所有英国身份证明及其对应的文件集。在作者的案例中，程序找到了三种证明路径，其中一种（Proof 3）确实需要曾祖父的出生证明和结婚证明。作者观察到，HMPO似乎选择了这三种证明中最长、最复杂的一种，推测是为了增加游戏乐趣。作者还指出，通过非英国籍但“定居”（settled）的祖先获得公民身份（Proof 1）可能更简单，因为它通常是非递归的。而出生在海外触发的“额外审查”标志，会阻止HMPO使用内部数据库，强制进行全面的递归检查。

文章最后讨论了自动化此类流程的利弊。虽然自动化能帮助申请人更快理解和准备文件，但由于英国国籍法的细微差别，完全自动化可能导致错误的判断（无论是误判为是还是误判为否），引发更多问题。

总的来说，文章通过将复杂的官僚流程游戏化，并用函数式编程（Haskell）的逻辑编程特性来建模和分析，提供了一个既幽默又技术深入的视角来理解英国护照申请的复杂性。

社区观点

许多读者分享了自己或亲友在办理护照、签证、移民或其他国家官僚手续时遇到的类似荒谬、复杂、耗时且缺乏透明度的问题，对作者将此过程比喻为游戏的视角表示认同。作为技术社区，大量讨论围绕Haskell实现细节展开，探讨LogicT monad在此类问题中的适用性，以及它与Prolog等传统逻辑编程语言的比较。大家对英国国籍法的复杂性表示惊讶，特别是其历史性、递归性以及不同时期法律对当前申请的影响。文章末尾关于是否应该自动化此类流程的讨论引发了辩论，支持者强调效率提升，反对者则强调法律的细微差别和边缘情况。作者将严肃的官僚流程游戏化的幽默感也得到了赞赏。

摩尔定律的不可持续性

好的，各位听众，今天我们关注 Charles Rosenbauer 在 Bzogramming 博客上发表的《摩尔定律的不可持续性》。这篇文章的核心观点是，戈登·摩尔提出的“摩尔定律”，即芯片上可集成的晶体管数量大约每两年翻一番，正面临着多重技术和经济上的巨大挑战，其持续性已经岌岌可危。作者认为，我们正在快速接近一个“后摩尔时代”。

文章详细阐述了几个关键点来支撑这一论断：

首先是经济成本的指数级增长。作者指出，虽然晶体管密度在增加，但建造尖端芯片工厂（Fab）的成本也在急剧攀升，大约每五年翻一番。25年前，一个晶圆厂成本约20-40亿美元，有约40家公司能做。今天，成本超过1000亿美元，能做的公司只剩两三家。照此趋势，未来十年一个工厂可能耗资近5000亿美元，能建的公司将少于一家，这在经济上是不可持续的。

其次是技术上的物理极限和复杂性。

• 纳米数字的“虚假性”：文章提到，当前宣传的“2纳米”等数字已不再是晶体管栅极的实际物理尺寸，而是营销指标。实际晶体管的占地面积远大于此，受限于几何布局。
• 光刻技术的挑战：芯片制造依赖光刻技术。虽然极紫外（EUV）光刻将波长降至13.5nm，高数值孔径（High-NA）EUV进一步推至6-7nm，但这些“像素”仍然包含数十个原子。更关键的是，用于形成电路图案的光刻胶（photoresist）在5-10nm以下就停止工作，目前没有明确的方案突破这一瓶颈。
• 晶体管结构的演变与复杂化：从平面晶体管到FinFET（鳍式场效应晶体管），再到当前的GAAFET（环栅晶体管，Intel称之为RibbonFET），晶体管结构变得越来越复杂。GAAFET需要将栅极包裹在通道的四周，甚至堆叠多个通道，这极大地增加了制造步骤和缺陷率。未来的CFET（堆叠NMOS和PMOS）可能是这条路径的终点，但复杂性更高。
• 丹纳德缩放定律的失效：文章回顾了时钟速度增长的停滞。丹纳德缩放定律曾预测晶体管缩小会保持功率密度不变，但由于漏电流等因素，这一规律在2006年左右失效。这导致芯片功率密度上升，需要更强的散热，并限制了时钟速度的提升。

文章还提到了其他“权宜之计”和限制：

• 背面供电：Intel正在尝试的背面供电技术，虽然有益，但作者认为这是一个高风险、相对低回报的一次性优化，是“黔驴技穷”的表现。
• 小芯片（Chiplets）和堆叠：这些技术变得更受欢迎，也是因为传统缩放越来越难。
• 光掩膜成本飙升：制造芯片所需的光掩膜成本从几十万美元涨到数千万美元（3nm节点约4000万美元），这使得只有极少数超大型客户（如英伟达）才能负担得起在最先进节点制造芯片，挤压了中小型设计公司和代工厂（如台积电）的传统商业模式。

面对这些挑战，作者探讨了未来的可能性：

• 回归简化：如果无法建造更昂贵的工厂，也许需要回到过去，简化制造流程以降低成本，即使这意味着暂时使用稍旧的节点。作者甚至提到了个人在车库里复制90年代芯片制造水平的例子，说明一旦路径明确，追赶可能更快更便宜。
• 容忍缺陷：设计对缺陷容忍度更高的芯片（特别是并行处理器和内存），可以使用质量要求较低、成本更低的晶圆厂。
• 行业结构调整：目前的产业结构（少数设备供应商服务少数芯片制造商）可能需要垂直整合等变革。
• 计算的“二手车市场”：如果芯片性能提升放缓，新旧芯片差距缩小，那么购买和转售高性能旧电脑可能会像二手车市场一样普遍，改变消费模式。

最后，作者透露他正在创办一家公司（The American Compute Corporation），旨在从第一性原理设计高性能、高效率的通用CPU，并可能探索建立一个创业公司规模的晶圆厂，为“后摩尔时代”做准备。

社区观点

许多读者对作者提出的技术和经济挑战表示认同，认为摩尔定律确实正在放缓，甚至已经进入一个新阶段。大家普遍认为，过去那种简单的“缩小尺寸就能提升性能和效率”的时代已经过去。一些观点相对乐观，认为人类的创新能力会找到新的突破口，比如新的材料或新的计算范式。另一些则比较悲观，认为文章描述的困境是真实的，未来计算性能的提升将变得异常艰难和昂贵。许多人指出，即使晶体管缩放放缓，性能提升仍然可以通过改进芯片架构、提高并行度以及优化软件和算法来实现。大家也深入探讨了芯片制造高度集中带来的经济风险和地缘政治影响。作者提出的“二手车市场”概念引发了一些有趣的讨论。总的来说，大家普遍同意，无论摩尔定律是否“已死”，我们都已进入一个与过去几十年不同的新时代，未来的计算进步将依赖于更复杂、多维度的创新。

中产音乐人的消亡

今天我们要讨论的文章来自 The Walrus，标题是《中产音乐人的消亡》。这篇文章探讨了一个引人深思的现象：在数字时代，创作音乐变得前所未有的容易，但靠音乐谋生却变得异常艰难，尤其是对于那些非巨星级别的中层音乐人。

文章通过加拿大音乐人 Cadence Weapon 的亲身经历，生动地展现了这一困境。他早年签约的唱片公司通过“360 度合约”几乎拿走了他所有收入来源的大部分，包括巡演、版税、甚至政府补助和诗人桂冠的奖金，直到收回所有投资和垫付的费用。结果是，尽管他取得了事业上的成功，获得了重要奖项，但多年来几乎没有从音乐中赚到钱。

文章深入分析了导致这一现状的几个关键因素。首先是流媒体平台的兴起。虽然流媒体让音乐触达全球听众，但其极低的单次播放分成（可能不到半美分）意味着艺术家需要天文数字的播放量才能获得可观收入。大部分流媒体收入流向了拥有大量音乐版权的少数大型唱片公司，它们甚至在 Spotify 等平台持有股份，从流媒体的整体增长中巨额获利，而艺术家只分到微薄的比例。

其次，文章指出，尽管独立艺术家现在可以绕过传统唱片公司自行发布音乐，但这导致了市场极度饱和。每天有超过 10 万首新歌上传到流媒体平台，艺术家不仅要与新歌竞争，还要与历史上所有已录制的音乐竞争，这使得脱颖而出变得异常困难。

其他收入来源也在萎缩。人工智能生成音乐的出现威胁到商业配乐、广告歌曲等机会。卫星广播等曾经为独立音乐人提供收入的渠道也在减少。政府补助虽然重要，但通常用于项目而非生活开销，且竞争激烈、资金面临削减。巡演曾是许多音乐人主要的收入来源，但疫情后成本飙升（交通、住宿、签证、缺乏工作人员），使得许多中层艺术家巡演反而亏损。

文章强调，音乐产业的健康对整个文化生态和经济至关重要，它支持着经理人、经纪人、工程师、场馆、服务人员等大量工作。但当艺术家无法维持生计时，整个体系都会受到影响。

面对这些挑战，文章探讨了一些可能的解决方案。有人提出普遍基本收入（UBI），认为这能为艺术家提供创作的安全网，但这被认为是遥不可及的。加拿大政府试图通过立法（如《在线流媒体法案》）强制流媒体平台推广加拿大内容并贡献收入，但这面临法律挑战且效果不明。

文章最终将希望寄托在艺术家自身的行动上。一些艺术家开始探索直接面向粉丝的模式，例如通过定制歌曲、直接销售数字或实体音乐，绕过中间商。他们呼吁艺术家拒绝不公平的合约和低尊严的机会，并鼓励粉丝直接支持他们喜爱的艺术家。文章引用了音乐人 Torquil Campbell 的话，他通过直接向粉丝销售定制歌曲和数字音乐获得了可观收入，这表明艺术家需要重新定义其作品的价值。同时，文章也提到像 Taylor Swift 这样有影响力的艺术家可以通过谈判为其他艺术家争取更好的分成条件，暗示集体行动的可能性。

文章的结论是，中产音乐人的困境是真实存在的，行业正处于一个黑暗时期，但艺术家们并未放弃，他们正在寻找新的生存和反击方式。

社区观点

许多读者将音乐人的困境视为更广泛经济不平等问题的缩影，认为这不仅仅是音乐行业特有的问题，而是财富日益集中、中产阶级普遍承压的体现。关于普遍基本收入（UBI）的讨论尤其激烈，支持者认为 UBI 可以为艺术家提供基本保障，鼓励创新和文化繁荣；反对者则质疑为何要强制纳税人去补贴那些市场需求不足的职业。一些人认为问题在于行业巨头利用其市场支配地位，设计了有利于自身的经济模式，建议通过监管来纠正这种失衡。同时，也有人从技术角度分析，认为数字发行虽然降低了门槛，但也消除了稀缺性，使得音乐的“单位价值”大幅下降。许多人认同文章中艺术家自救的思路，强调艺术家需要更直接地与粉丝建立联系，提供独特的价值，并鼓励粉丝通过购买实体商品、门票、直接捐赠等方式支持艺术家。

再谈苹果“F1 电影”钱包广告对信任的侵蚀

今天我们关注 Daring Fireball 上 John Gruber 的一篇文章，讨论的是最近苹果通过 Apple Wallet 应用发送的一则推广“F1 The Movie”电影的推送通知。

Gruber 在文章中指出，苹果的这一举动极大地损害了用户对 Apple Wallet 的信任。他认为，Wallet 应用承载着用户最私密、最敏感的信息，比如金融账户、身份证明、钥匙等等，其地位应该像物理钱包一样，是一个绝对私密、没有广告的空间。苹果一直在努力让用户相信 Wallet 的安全性和隐私性，并鼓励用户将更多个人“家当”数字化到 Wallet 中。然而，发送这样一则未经请求的电影广告，直接违背了这种信任基础。

文章强调，问题不仅仅在于广告本身令人厌烦，更在于它破坏了用户对 Wallet 隐私的感知。即使这则广告是群发的，与用户的具体 Wallet 使用行为无关，但对于收到广告的用户来说，尤其如果他们近期恰好在 Wallet 中购买过电影票或其他相关商品，很容易会联想到 Wallet 是否在追踪他们的兴趣和活动，并因此感到不安。Gruber 认为，这种对隐私的“感知”与技术上的实际隐私同样重要，而这则广告直接打击了苹果在建立用户信任方面所做的努力。他甚至措辞强烈地表示，批准通过 Wallet 发送这则广告的人应该被解雇。

社区观点

许多读者与 Gruber 的看法一致，认为在 Wallet 这样一个高度个人化、承载敏感信息的应用中推送广告是不可接受的，这侵蚀了苹果长期以来建立的隐私和信任形象。他们认为这是一种“滑坡谬误”的开端，担心未来 Wallet 会被用于更多商业推广。另一方面，也有一些人认为这可能只是苹果内部一次糟糕的营销决策失误，而非系统性地将 Wallet 变成广告平台。还有人讨论了这则广告的技术实现方式，猜测它是如何被发送的，以及是否真的与用户数据无关，这进一步引发了关于苹果内部数据使用策略的担忧。总的来说，大家普遍认为，无论出于何种原因，在 Apple Wallet 中发送推广广告都是一个严重的错误，它不仅损害了用户体验，更重要的是，它对苹果赖以区分于其他科技巨头的核心价值——隐私和信任——造成了打击。

社区：动力的源泉

这周我们看到一篇题为《Community Is Motivation on Tap》的文章，作者探讨了社区在个人动力中的巨大作用。

文章开篇指出，观察那些在各个领域取得成功的人——无论是运动员、创始人、音乐家还是游戏速通玩家——他们似乎拥有源源不断的动力，能够投入大量时间和精力去做那些看似枯燥乏味的工作。作者反思自己连洗衣服这样的小事都难以坚持，而这些人是如何做到的？

作者认为，成功的关键在于他们往往身处一个朝着共同目标努力的良好社区中。社区能够极大地放大个人动力，而独自奋斗的人则更容易后继乏力。作者用自己的经历对比说明：他热爱《星际争霸》，但由于社区衰落，很难保持持续练习；而对于他并不真正享受玩法的《荒野乱斗》，仅仅因为有朋友一起玩，他却投入了数百小时。这鲜明地对比出社区对动力的强大影响。

文章进一步分析了社区提升动力的潜在机制：

1. 寻求认可（Approval Seeking）：这是人类基因中的倾向。像“责任伙伴”（accountability partner）或“良性竞争”（productive competition）这样的概念，本质上就是利用我们寻求认可的心理来提升效率。在社区中，我们为了不让伙伴失望或在竞争中进步，会更有动力坚持。
2. 眼见为实偏差（WYSIATI Bias / Availability Bias）：我们做决策时，大脑倾向于使用最容易获取的信息。当身处一个围绕特定目标的社区时，我们会不断接触到相关信息，这使得这个目标在脑海中保持活跃。比如，下午决定做什么时，如果社区总在讨论某个游戏，就更容易选择去玩它。社区提供了一个持续的信息流，让目标保持新鲜感。

除了这些心理机制，作者也提到，一个富有成效的社区还能通过分享知识、避免钻牛角尖等方式，提高工作或练习的效率，从而带来更多进展，这本身也是提升动力的重要因素。

最后，文章给出了一些行动建议：要主动加入或创建那些围绕你想要实现的目标的社区；不要让现有的社交圈限制你，可以加入多个社区以满足不同目标的动力需求；同时，也要果断离开那些让你朝着“不好”方向发展的负面社区。

社区观点

许多读者分享了自己通过社区克服惰性、实现目标的经历，印证了作者的观点。也有人从不同角度补充了社区的其他益处，比如情感支持、归属感以及在遇到困难时获得帮助的可能性。一些观点则探讨了如何找到或建立一个真正有益的社区，强调了社区文化、共同价值观和积极互动的重要性。总的来说，大家普遍认同社区是个人成长和目标实现中一个常常被低估但极其强大的动力来源。

我让我的虚拟机以为它有 CPU 风扇

今天我们要聊一篇来自 mindless-area 博客的文章，标题非常有趣：《我让我的虚拟机以为它有 CPU 风扇》。

文章的核心话题是作者如何通过修改虚拟机的系统管理 BIOS (SMBIOS) 数据，来模拟物理硬件的存在， specifically 是一个 CPU 风扇。这样做的主要目的是为了欺骗那些会检测虚拟机环境的恶意软件，让它们以为自己运行在真实的物理机上，从而避免被检测和停止运行，方便安全研究人员进行分析。

文章详细阐述了整个过程。作者首先解释了为什么需要这样做：一些恶意软件会检查虚拟机环境中通常不存在的硬件组件，比如 CPU 风扇，来判断自己是否在 VM 里。它们通常通过查询 Windows Management Instrumentation (WMI) 中的 Win32_Fan 类来实现这一检测。如果查询不到风扇信息，恶意软件可能就会停止执行或改变行为，以逃避分析。

作者通过 Google 搜索发现，Win32_Fan 类的数据来源于 SMBIOS 中的 Type 27 (Cooling Device) 条目。于是，他决定直接修改虚拟机的 SMBIOS 数据来伪造一个风扇。他使用 dmidecode 工具从物理机上导出了 Type 27 的原始 SMBIOS 数据，并将其保存到一个二进制文件 (smbios.bin) 中。

接下来是实现细节。作者主要使用 Xen 虚拟机监控程序。根据 Xen 的文档，可以通过 smbios_firmware 配置选项指定一个包含额外 SMBIOS 数据的二进制文件。然而，他很快遇到了第一个障碍：Xen 默认不允许覆盖或添加 Type 27 这样的非核心 SMBIOS 类型。他发现了一个几年前被拒绝的 Xen 补丁，该补丁正是为了添加对这些类型的支持。为了继续，他不得不自己动手，将这个小补丁应用到 Xen 源码并重新编译。

解决了 Type 27 的添加问题后，他在虚拟机内再次检查 Win32_Fan，却依然没有发现风扇。经过进一步排查，他发现 Type 27 (Cooling Device) 条目中引用了一个 Type 28 (Temperature Probe) 的句柄。这意味着 WMI 在查找风扇时，可能也需要关联的温度探头信息。于是，他再次使用 dmidecode 导出了物理机的 Type 28 数据，并将其添加到 smbios.bin 文件中。

需要注意的是，Xen 在处理 smbios_firmware 文件时，要求每个 SMBIOS 结构前面都必须加上一个 32 位的整数来表示该结构的大小。作者详细展示了如何计算并添加这些大小前缀。

经过一番折腾，包括应用补丁、添加 Type 27 和 Type 28 数据，并按照 Xen 的要求格式化文件后，终于在 Windows 虚拟机中成功通过 wmic path Win32_Fan get Description,Status 命令看到了伪造的 CPU 风扇信息。

文章最后提到了在 QEMU/KVM 中实现同样目标要简单得多。QEMU 的 -smbios file=/path/to/smbios.bin 选项可以直接使用原始的 SMBIOS 数据文件，不需要大小前缀，并且 QEMU 会自动处理其他必要的 SMBIOS 条目。甚至可以直接使用宿主机的完整 SMBIOS 数据文件。

社区观点

许多读者指出，虽然伪造 SMBIOS 数据可以绕过基于 WMI/SMBIOS 的检测，但这只是恶意软件检测虚拟机方法的冰山一角。现代恶意软件可能还会检查其他虚拟机特有的迹象。大家提到，安全研究人员和恶意软件作者之间一直在进行一场持续的军备竞赛，这种伪造硬件信息的技术是反检测领域的一个经典例子，但需要不断更新和组合多种技术才能保持有效性。一些人讨论了直接 Hook WMI 相关的 API 调用是否是另一种更简单的方式。还有人对作者在 Xen 上遇到的困难表示同情，并讨论了不同虚拟化平台在硬件模拟和定制方面的差异。

改进河流模拟

今天我们要聊的是来自 Undiscovered Worlds 博客的一篇文章，标题是《改进河流模拟》。

这篇文章深入探讨了一个世界生成和模拟项目——Undiscovered Worlds——在处理河流系统时遇到的挑战和改进。作者正在将旧的区域绘制功能迁移到新的全局上下文中，并在此过程中进行重构和优化。

文章的核心要点在于，作者发现之前模拟河流流量的方式不够精确。过去的方法是只存储全球地图上每个点一月和七月的温度和降雨数据，然后尝试从这些数据推断其他月份的河流流量。然而，河流的流量不仅仅取决于本地的气候条件，更重要的是其上游集水区的气候。上游地区可能有着完全不同的气候模式，导致下游河流的流量变化与本地的降雨或温度变化并不直接相关。例如，即使下游地区三月比十月雨水少，但如果河流的主要水源来自遥远的上游地区，并且该地区在三月有大量融雪或降雨，那么下游河流在三月反而可能流量更大。

为了解决这个问题，作者对程序进行了更新，现在会跟踪并存储全球地图上每个单元格在所有十二个月份的河流流量数据。在计算河流时，程序会遍历全球的每个单元格，计算该单元格在每个月产生的径流，然后将这些流量按月累加到其下游的所有单元格中。这种逐月、逐单元格的计算方式，使得模拟能够更准确地反映河流流量随季节的变化。

文章通过三个示例图展示了这种改进的效果。第一个例子是一条流经沙漠和苔原的长河，尽管河流中段本地没有降雨且温度变化大，但由于其遥远的上游水源降雨均匀，河流流量全年相对稳定。第二个例子是另一条支流，其水源来自更南方的苔原和北极山脉，本地气候与前一个例子相似，但由于水源地的季节性融雪，这条支流在夏季会出现极端的流量洪峰，而其他时间几乎断流。第三个例子展示了这两条河流汇合后在河口附近的情况，这里的流量变化模式结合了上游两条河流的特点，在夏季因支流的融雪径流而显著上涨。

作者提到，由于 Undiscovered Worlds 现在已经能够动态显示季节变化，这项改进意味着在区域层面，河流的大小将能够根据月份动态地膨胀和收缩，从而极大地增强了模拟的真实感。

社区观点

（注：由于未提供实际讨论，以下是基于文章内容和技术社区常见讨论风格进行的推测性总结）

读者们普遍赞赏模拟精度的大幅提升，认为逐月跟踪河流流量能显著增强世界生成的真实感。一些人可能会讨论计算性能和存储需求，因为存储12个月的数据会增加开销。大家也可能提出其他水文模拟细节的建议，例如地下水、湖泊、湿地动态、侵蚀和沉积等，并与其他类似项目或模拟技术进行比较。

Show HN: Octelium – Teleport、Cloudflare、Tailscale、Ngrok 的开源替代方案

好的，各位听众，今天我们关注一个名为 Octelium 的“Show HN”项目。这个项目自称是一个下一代开源、自托管的统一零信任安全访问平台，旨在成为 Teleport、Cloudflare Access、Tailscale 甚至 Ngrok 等多种工具的替代品。

文章主题概括：

Octelium 的核心是一个免费开源（FOSS）、可自托管的零信任安全访问平台。它提供了一种现代化的方式来连接用户（包括人类和工作负载）到内部或受保护的外部资源，无需传统的 VPN 或暴露敏感凭证。其目标是整合多种安全访问和网络功能到一个统一的平台中。

文章重点内容阐述：

Octelium 的设计理念是构建一个基于身份、应用层（L7）感知的零信任架构（ZTA），而非传统的网络层（L3）访问控制。它提供了两种主要的访问方式：

1. 客户端访问： 通过基于 WireGuard 或 QUIC 隧道的零配置客户端，提供类似 VPN 的私有访问体验，但基于零信任原则。
2. 无客户端访问： 提供类似 Google BeyondCorp 的公共访问方式，用户通过浏览器，工作负载通过标准的 OAuth2 流程进行访问。

该平台强调了几个关键特性：

• 动态无密访问 (Dynamic Secret-less Access)： Octelium 能够理解应用层协议，代表用户或工作负载处理访问资源的凭证（如 API 密钥、数据库密码、SSH 密钥等），从而消除了分发和管理这些敏感、长期存在的秘密的需求。目前支持 HTTP、SSH、Kubernetes、PostgreSQL/MySQL 以及 mTLS 保护的资源。
• 上下文感知、基于身份的访问控制： 使用基于属性的访问控制（ABAC），通过策略即代码（Policy-as-Code），利用 CEL 和 OPA 等工具，在每个请求级别进行细粒度、动态的访问决策。值得注意的是，它默认没有“管理员”或“超级用户”的概念，强调零站立权限。
• 统一且持续的强认证： 支持各种 Web 身份提供商（OpenID Connect, SAML 2.0, GitHub OAuth2）以及基于 OIDC 断言的工作负载身份认证，并支持 NIST SP 800-63 认证保证级别，可强制使用防钓鱼的多因素认证（如 WebAuthn/Passkeys）。
• 基于 Kubernetes 的可伸缩架构： 平台构建在 Kubernetes 之上，易于实现自动水平伸缩和高可用性。
• 简化的网络和管理： 通过身份感知代理和统一的私有 DNS，避免了传统 VPN 的路由冲突和网络配置复杂性。管理方式采用类似 Kubernetes 的声明式方法，通过 octeliumctl CLI 工具进行集中管理，支持 GitOps 工作流。
• 自托管和开源： 项目完全开源，集群组件采用 AGPLv3 许可，客户端组件采用 Apache 2.0 许可，专为单租户自托管设计，没有隐藏的云服务依赖或功能限制。

项目目前处于公共 Beta 阶段，架构和主要功能已基本稳定。其商业模式并非 SaaS，而是通过为企业提供专业支持、AGPLv3 的商业替代许可以及额外的企业级专有功能（如 SIEM 集成、SCIM 同步、托管秘密加密等）来盈利。

社区观点

（注：由于未提供实际讨论，以下是基于文章内容和技术社区常见讨论风格进行的推测性总结）

对于这样一个雄心勃勃、旨在替代多个成熟工具的项目，大家可能会讨论其广度与深度，质疑如此广泛的用例是否意味着每个功能都足够强大和成熟。许多人会详细比较 Octelium 在性能、易用性、功能集、安全性等方面与 Teleport、Tailscale、Cloudflare Tunnel 等现有工具的优劣。自托管的复杂性也是一个关注点，尤其对于单节点或资源受限的环境。开发者可能会深入探讨其身份感知代理、策略引擎的具体实现和配置方式，以及其安全性保障。AGPLv3 许可可能会引发关于代码使用和修改的讨论，而其商业模式的透明度和可持续性也可能成为关注点。

数列及其首项差分数列共同列出所有正整数，且每个数只出现一次

今天我们要聊的是一个来自 OEIS，也就是整数数列在线大全的有趣条目：A005228。这个数列的标题本身就非常吸引人——“数列本身和它的首项差分数列一起，恰好列出了所有正整数，且每个数只出现一次。”

这个数列的定义非常简洁而优雅。它被称为是满足这个性质的“字典序最早”的数列。也就是说，我们从 1 开始构建这个数列。第一个数是 1。那么，它的首项差分数列目前是空的。我们看下一个最小的正整数，也就是 2。2 不在数列中，所以它必须出现在差分数列里。为了让差分数列包含 2，数列的下一个项就必须是 1 + 2 = 3。好，数列现在是 1, 3。差分是 2。集合 {1, 3} ∪ {2} = {1, 2, 3}。我们已经覆盖了前三个正整数。

接下来看最小的未出现的正整数，是 4。4 不在数列 {1, 3} 中，所以它必须是下一个差分。数列的下一项是 3 + 4 = 7。数列是 1, 3, 7。差分是 2, 4。集合 {1, 3, 7} ∪ {2, 4} = {1, 2, 3, 4, 7}。最小未出现的正整数是 5。5 不在数列中，所以它是下一个差分。数列下一项是 7 + 5 = 12。数列是 1, 3, 7, 12。差分是 2, 4, 5。集合 {1, 3, 7, 12} ∪ {2, 4, 5} = {1, 2, 3, 4, 5, 7, 12}。

通过这种贪婪的、选择最小未出现正整数作为下一个差分的方式，我们构建出了这个独特的数列。数列 A005228 的前几项是 1, 3, 7, 12, 18, 26, 35, 45, 56, 69, ...。它的首项差分数列（A030124）是 2, 4, 5, 6, 8, 9, 10, 11, 13, ...。正如定义所述，将这两个数列合并并排序，你会得到所有正整数 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, ...，且每个数只出现一次。

这个数列最早是由 Douglas Hofstadter 在他的经典著作《哥德尔、埃舍尔、巴赫：集异璧之大成》（Gödel, Escher, Bach: an Eternal Golden Braid）中介绍的，与 Scott Kim 的“FIGURE-FIGURE”绘图有关。它是一个典型的“自生成”数列，其定义依赖于数列自身的性质及其补集（即差分数列）。

社区观点

大家对这种数学结构的美感和巧妙性表现出了浓厚的兴趣，认为能够通过如此简单的规则生成一个覆盖所有正整数的数列对，非常优雅。关于构建算法和实现，如何高效地生成这个数列，特别是计算第 N 项，是一个常见的探讨点。许多人通过《GEB》这本书了解到这个数列，讨论也延伸到 Hofstadter 的其他自引用系统和数学概念。一些观点比较了这个数列与其他类似的自生成或补集相关的数列，有助于理解不同规则如何导致不同的数列行为。总的来说，A005228 不仅仅是一个数学数列，它代表了一种巧妙的构造方式，连接了数学、计算机科学和哲学思考，因此总能引发热烈的讨论。