ZhuLink ZhuLink
登录

【HN中文日报】硬核干货！程序员必看技术趋势：编译器优化、AI模型、职场生存全攻略！

意外富翁 · 1个月前 · News · 29 · 0

今天 Hacker News 社区聊了啥？ NO.20251202

这期日报信息量爆炸！从编译器如何用骚操作优化代码，到AI模型构建游戏的硬核挑战，再到远程办公对程序员的影响，绝对让你大开眼界。想知道2026年有哪些经典作品进入公共领域？想用代码玩转音乐？还有AWS Lambda性能大PK和各种求职信息！别犹豫了，赶紧点开全文，充电学习，走上技术巅峰！

Hacker News 中文精选

使用 LEA 指令在 x86 架构中进行整数加法优化

这篇文章讨论了在 x86 架构下，编译器如何巧妙地利用 LEA (Load Effective Address) 指令来优化整数加法操作。通常，x86 的 add 指令是 lhs += rhs 这种形式，会修改其中一个操作数，并且不能直接指定结果存放的寄存器。

为了解决这个限制，编译器会使用 LEA 指令，它原本用于计算内存地址，但实际上可以被“滥用”为一个三操作数的加法器。LEA 指令可以计算 rdi + rsi * scale + offset 这样的地址，而不需要真正访问内存。通过这种方式，编译器可以实现 result = rdi + rsi 的效果，同时指定结果寄存器，并且不改变原始操作数的值。使用 LEA 指令通常可以节省一条指令，并且在操作数后续还需要使用时非常有用，因为它不会改变原始操作数的值。此外，LEA 可以在 x86 的多个执行单元中并行执行，提高效率。文章还提到，尽管 LEA 计算的是 64 位地址，但当结果写入 32 位寄存器时，高位会被丢弃。

评论区里，大家对这篇文章展开了热烈的讨论：

  • 有人指出 LEA 不仅可以保留操作数的值，还可以保留 CPU 标志位。
  • 有人提到 LEA 还可以用于乘法，例如 lea eax, [rdi+rdi*4] 可以实现 x * 5。
  • 还有人对作者使用 LLM 进行校对的透明做法表示赞赏。
  • 有读者提问学习汇编的最佳资源，以便理解简单函数的输出。
  • 有人开玩笑说作者在诱导大家学习汇编。
  • 有人对高位丢弃和编译器依赖高位为零的说法感到困惑，需要进一步解释。
  • 还有读者分享了自己实现 Z80 模拟器的经验，认为这篇文章提供了很好的上下文。
  • 有人质疑 LEA 是否真的使用了硬件内存地址计算单元，还是被重定向到标准的整数加法单元。
  • 最后，有人指出 LEA 中使用 [] 容易让人误以为是内存访问。

靠近同事的利弊：长期发展与短期产出之辩

这篇文章探讨了在远程工作日益普及的背景下，靠近同事对软件工程师的影响，研究发现，与同事保持近距离在长期人力资本发展方面有益处，但会牺牲短期产出。

研究对象是一家财富 500 强公司的软件工程师，该公司主园区有两栋相隔几个街区的建筑。疫情前，与所有团队成员在同一栋楼工作的工程师，比与团队成员距离较远的工程师收到的在线反馈多 22%。疫情导致办公室关闭后，这种优势基本消失。然而，坐在一起会降低工程师的编程产出，尤其是对于资深工程师而言。

对于女性而言，靠近同事的利弊更为明显，她们在靠近同事时，会进行更多的指导，也会获得更多的指导。近距离工作还会影响职业发展轨迹，抑制短期加薪，但会促进长期加薪。这些结果有助于解释国家趋势：二十多岁的需要指导的员工和四十多岁的提供指导的员工更有可能返回办公室。

即使大多数导师和学员都去办公室，远程工作也可能会减少互动：在疫情之前，即使只有一个远程队友，也会减少共同办公的员工之间的反馈。总的来说，这项研究揭示了近距离工作对软件工程师的复杂影响，需要在长期发展和短期产出之间进行权衡。

评论区中，有用户指出该文章目前的状态是“修改后重新提交，经济学季刊”，建议等待最终版本。

Matt Godbolt 发布 2025 年编译器优化系列

Matt Godbolt 宣布推出“2025 年编译器优化”系列，这是一个为期 25 天的项目，每天发布一篇博客文章和一个视频，详细介绍 C 或 C++ 编译器可以执行的有趣优化。

该系列将深入探讨编译器优化的细节，包括优化何时适用、如何解读汇编代码，以及更重要的，何时不适用。内容涵盖了从非常底层的、特定于架构的技巧到更大型、更高级的优化。虽然主要关注 x86-64 架构，但也会涉及 64 位和 32 位 ARM 架构。

可以通过多种方式关注这个系列，包括关注博客上的 AoCO2025 标签、订阅 Matt Godbolt 的 YouTube 频道，或者关注 YouTube 播放列表。作者表示，这个项目耗费了大量精力，但也充满了乐趣，希望大家能像他一样享受学习编译器优化的过程。该系列从 12 月 1 日开始，每天更新。Matt Godbolt 是一位 C++ 开发者，在 Hudson River Trading 工作，同时也是 Two's Complement podcast 的主创之一。

评论区里，大家对这个系列表示了极大的兴趣和赞赏。有人希望作者能介绍 SQLite 使用的代码合并技术，认为这是一种可以带来 5-10% 性能提升的优化方法。还有人赞赏作者从简单内容入手，没有直接讲解晦涩难懂的 x86 指令集。一些开发者表示，他们一直想知道是否使用了最佳的编译器标志。Matt Godbolt 被誉为 C 和 C++ 社区的瑰宝，他的 Compiler Explorer 工具也广受好评。也有人询问是否有 PDF 版本，方便无法观看视频的读者。总体来说，评论区充满了对 Matt Godbolt 的感谢和对这个系列的热切期待。有人甚至直言“永远不会嫌 Godbolt 的内容太多！” 也有人表示不理解要解决的问题是什么。

软件工程的“死亡”与“多媒体时代”的幻灭：回顾技术浪潮中的预言与现实

这篇文章作者以个人经历为线索，讲述了过去几十年间，人们对软件工程未来发展方向的几次“预言”以及这些预言最终的破灭。作者通过童年和早期职业生涯中的几个小故事，生动地展现了技术变革的浪潮以及人们在面对变革时的不同心态。

文章首先提到，早在 1996 年就有人预言，面向对象编程的出现将导致软件工程师失业，因为所有问题都将被封装成可重用的“乐高积木”。然而，现实是，软件开发并没有因此而消失，反而不断涌现出新的问题和挑战。接着，作者回忆了 90 年代“多媒体时代”的兴起，当时人们认为所有软件都必须具备多媒体功能，否则就会被淘汰。但最终，多媒体技术变得司空见惯，并没有对行业产生颠覆性的影响。

随后，作者分享了 2000 年左右，有同事认为 IntelliJ IDE 的出现将取代程序员，因为它强大的代码自动完成和重构功能可以大大提高开发效率。然而，作者认为，工具只能提高效率，而不能取代创造性思维。最后，作者讲述了自己通过编写脚本自动化工作的故事，包括帮助他人自动化 MUMPS 数据迁移，以及自动化更新政府网站上的 mental health providers 列表。这些经历让他意识到，自动化虽然可以提高效率，但也可能导致失业，同时也引发了他对工作意义的思考。

总的来说，这篇文章通过几个小故事，探讨了技术变革对软件工程行业的影响，以及人们在面对变革时的不同反应。作者认为，技术的发展是不可阻挡的，但它并不能完全取代人类的创造性和思考能力。

基于 Normalizing Flow 的端到端视频生成模型：STARFlow-V

STARFlow-V 是首个基于 Normalizing Flow 的因果视频生成器，它在视频生成领域取得了显著进展，能够与视频扩散模型在视觉质量上相媲美，同时提供端到端训练、精确的可能性估计以及对 T2V/I2V/V2V 生成的原生多任务支持。该模型通过结合全局-局部架构、Flow-Score Matching 降噪和视频感知 Jacobi 迭代等创新技术，实现了高质量和高效率的视频生成。

STARFlow-V 的核心在于其全局-局部架构。该架构通过一个深度因果 Transformer 块在压缩潜在空间中自回归地处理视频，从而捕获长期的时空依赖关系。同时，浅层 Flow 块独立地对每个帧进行操作，以建模丰富的局部结构。这种设计有效地缓解了像素空间自回归模型中常见的复合误差问题。此外，Flow-Score Matching 降噪技术通过训练一个轻量级的因果神经降噪器，使其能够预测模型自身分布的分数（对数概率的梯度），从而实现高质量的单步细化，同时保持因果关系。为了提高采样效率，STARFlow-V 采用了一种视频感知的 Jacobi 迭代方案，将生成（Flow 反演）重新定义为求解非线性系统，从而实现多个潜在变量的块式并行更新，而不是逐个生成。

STARFlow-V 模型在 7000 万个文本-视频对和 4 亿个文本-图像对上进行训练，最终的模型拥有 70 亿个参数，能够以 16fps 的速度生成 480p 的视频。该模型在压缩的潜在空间中运行，并利用 Normalizing Flow 的可逆性，原生支持多种生成任务，而无需任何架构更改或重新训练。实验结果表明，STARFlow-V 在视觉保真度和时间一致性方面表现出色，并且具有相对于基于扩散的基线的实用采样吞吐量。该研究表明，Normalizing Flow 有能力实现高质量的自回归视频生成，并将其确立为构建世界模型的一个有希望的研究方向。

该文章还展示了 STARFlow-V 在文本到视频生成任务中的一些示例，例如 "一只边境牧羊犬在一棵倒下的原木上保持平衡"、"篝火噼啪作响，余烬升起" 等，这些示例都以 480p 和 16fps 的速度生成。

2026年进入公共领域的作品有哪些？

这篇文章介绍了2026年即将进入公共领域的作品，这意味着这些作品可以被自由地使用、分享和再利用，无需担心版权问题。由于世界各地的版权法不同，进入公共领域的作品也因地区而异。

文章重点关注了三个主要的版权期限：作者去世后70年（例如，英国、俄罗斯、大多数欧盟国家和南美洲）、作者去世后50年（例如，新西兰以及大多数非洲和亚洲国家）以及美国。在美国，1930年出版的电影和书籍（包括其中的艺术品）将进入公共领域。

文章以日历的形式，每天揭晓一个亮点作品，包括文学、电影、音乐和艺术等领域。一些值得关注的亮点包括：威廉·福克纳的《我弥留之际》，阿加莎·克里斯蒂的《牧师公馆谋杀案》，弗朗茨·卡夫卡的《城堡》（英文翻译），以及埃里希·玛丽亚·雷马克的电影《西线无战事》（1930年版）。此外，还有兰斯顿·休斯、阿尔伯特·爱因斯坦、查理·帕克等名人的作品也将进入公共领域。

文章还推荐了一些资源，例如John Mark Ockerbloom在Mastodon上的“公共领域日倒计时”，以及Standard eBooks提供的免费阅读的美国作品。此外，还提到了Communia的《公共领域宣言》，以及一篇关于作品进入公共领域后是否会发生“坏事”的文章。总的来说，这篇文章提供了一个关于2026年公共领域新作品的全面预览，并鼓励人们探索和利用这些资源。

使用 Strudel.cc 在浏览器中学习音乐编程（免费开源）

这篇文章介绍了一个免费开源的课程，教你如何使用 Strudel.cc 在浏览器中制作音乐。这个课程非常适合音乐制作的初学者，即使你完全没有音乐基础也能轻松上手。

课程内容包括音乐制作的基础知识，以及如何在 Strudel 中制作节拍等。课程还提供了 GitHub 仓库，方便大家贡献和学习。通过这个课程，你可以在浏览器中轻松地进行音乐创作，并且学习到一些音乐理论知识。

Strudel.cc 提供了一个非常友好的界面，让你可以通过编写代码来创作音乐。它将代码和音乐创作结合起来，为音乐爱好者和开发者提供了一个全新的创作方式。无论你是想学习音乐制作，还是想尝试一种新的音乐创作方式，Strudel.cc 都是一个不错的选择。这个课程的开源特性也意味着你可以自由地学习、修改和分享。

评论区里，有用户分享了一个关于使用代码创作 Trance 音乐的视频，并称赞其为优秀的编程和音乐表演。另一位用户分享了自己使用 Strudel.cc 创建的音乐链接，表达了对 Strudel.cc 的喜爱。还有用户提到，越来越多的音乐家（或开发者？）使用 Strudel 进行现场编码表演，并在 TikTok 和 Reels 上发布视频，这非常有趣。总的来说，评论区对 Strudel.cc 抱有积极的态度，认为它是一个有趣且有潜力的音乐创作工具。

YouTube 提升 FreeBASIC 性能 (2019)

这篇文章讨论了一个有趣的现象：YouTube 似乎能够提升 FreeBASIC 程序的性能。具体来说，有人发现通过运行 YouTube 视频，FreeBASIC 程序的帧率得到了提升。这背后的原因可能与 Windows 的能量节约定时器机制有关。Windows 会调整定时器的分辨率以节省电能，但较低的分辨率可能会影响程序的性能。当 YouTube 运行时，它可能会提高定时器的分辨率，从而间接提升了其他程序的性能，包括 FreeBASIC 程序。

文章还提到，有人建议使用 Sleep(16, 1) 来稳定帧率在 60 fps。同时，也有开发者推荐使用 "fix your timestep" 的方法，将游戏运动与帧率解耦，以获得更平滑的体验。这种方法需要更多的数学计算，但通常能带来更好的效果。

评论区也对此现象进行了讨论，有人指出这与运行 Winamp 听音乐时游戏性能提升的原因类似。也有人认为这是 Windows 技术债务的一个例子，并呼吁对整个技术栈进行重写，以解决性能问题。

评论区观点：

  • mrozbarry: 建议使用 "fix your timestep" 方法解耦游戏运动与帧率。
  • TonyTrapp: 认为与运行 Winamp 听音乐提升游戏性能的原因类似。
  • aa-jv: 指出这是 Windows 技术债务的体现，并联想到 MSDOS 时代的 Turbo 按钮。
  • user3939382: 认为这凸显了现有技术栈的臃肿和低效，需要重写。

AWS Lambda Arm64 vs. x86_64 性能对比（2025年末）

本文对 2025 年末 AWS Lambda 在 Arm64 和 x86_64 架构下的性能进行了基准测试，对比了 Node.js、Python 和 Rust 等多种运行时的 CPU、内存和 I/O 工作负载表现。

文章作者分享了在 2025 年底对 AWS Lambda 进行基准测试的结果，旨在了解 Arm64 架构与传统的 x86_64 架构相比，在性能和成本效益方面的差异。作者构建了一个基准测试，在两种架构上运行 Lambda 函数，并使用 Node.js、Rust 和 Python 等运行时，涵盖 CPU 密集型、内存密集型和轻量级工作负载。

基准测试方法包括模拟轻量级、CPU 密集型和内存密集型三种类型的工作负载，并尽量在不同运行时之间保持一致。轻量级工作负载模拟了与 DynamoDB 的交互，CPU 密集型工作负载执行 SHA-256 哈希运算，内存密集型工作负载分配和排序大型数组。

测试结果显示，Rust 在 Arm64 架构上表现出最佳的性能和成本效益。Python 3.11 在 Arm64 上的性能略优于更新的 Python 运行时。Node.js 22 在 Arm64 上也比 Node.js 20 在 x86_64 上更快。总体而言，Arm64 架构在成本方面具有显著优势，计算成本比 x86_64 低 30-40%，同时性能相当或更好。因此，除非存在兼容性问题或特殊的工作负载需求，否则 Arm64 是 Lambda 的一个不错的默认架构选择。

作者还强调，AWS Lambda 的 CPU 算力与分配给函数的内存量成正比。要获得 1 个完整的 vCPU，必须为 Lambda 分配 1,769 MB 的内存。

由于文章没有评论区，所以无法分析评论观点。

Python Data Science Handbook 概览

这篇文章介绍了 Jake VanderPlas 撰写的《Python Data Science Handbook》，它是一本关于使用 Python 进行数据科学的综合指南，以 Jupyter notebooks 的形式托管在 GitHub 上。这本书涵盖了 IPython、NumPy、Pandas、Matplotlib 和机器学习等核心库，旨在为读者提供数据科学的坚实基础。

这本书的内容非常丰富，从 IPython 的高级特性讲起，比如帮助文档、快捷键、魔法命令等，然后深入到 NumPy 的数据类型、数组操作、通用函数、聚合、广播、索引和排序。接着，Pandas 部分介绍了 Pandas 对象、数据索引和选择、数据操作、处理缺失数据、层级索引、合并数据集、聚合和分组、透视表、字符串操作和时间序列分析。Matplotlib 部分则涵盖了各种绘图类型，包括折线图、散点图、等高线图、直方图等，以及如何自定义图例、颜色条、子图、文本和刻度。最后，本书还介绍了机器学习的基础知识。

这本书以 CC-BY-NC-ND 许可发布文本内容，MIT 许可发布代码，鼓励大家通过购买书籍来支持作者的工作。无论你是数据科学的初学者还是有经验的从业者，这本书都将是你学习和参考的宝贵资源。它不仅提供了理论知识，还包含了大量的示例代码，方便读者动手实践。通过学习这本书，你可以掌握使用 Python 进行数据分析、可视化和机器学习的关键技能。

DeepSeek-V3.2：开源大语言模型的新突破

DeepSeek-V3.2 旨在通过技术创新，在计算效率、推理能力和 Agent 性能之间实现平衡，缩小与闭源模型的差距。该模型主要有三个技术突破：DeepSeek 稀疏注意力（DSA）、可扩展的强化学习框架和大规模 Agent 任务合成管线。

DeepSeek-V3.2 引入了 DSA，这是一种高效的注意力机制，显著降低了计算复杂度，同时保持了模型在长文本场景中的性能。DSA 的核心是闪电索引器和细粒度的 token 选择机制。闪电索引器计算 query token 和 preceding token 之间的索引分数，决定哪些 token 被选择。细粒度的 token 选择机制只检索与 top-k 索引分数相对应的 key-value 条目，然后计算注意力输出。

为了提升模型在复杂任务上的性能，DeepSeek-V3.2 开发了一个稳定且可扩展的强化学习协议，并在后训练阶段投入了大量的计算资源，超过了预训练成本的 10%。此外，为了提高模型在工具使用场景中的泛化推理能力，研究团队设计了一个新颖的管线，系统地生成大规模的训练数据，包含超过 1800 个不同的环境和 85000 个复杂的 prompt。

实验结果表明，DeepSeek-V3.2 在多个推理基准测试中取得了与 Kimi-k2-thinking 和 GPT-5 相似的性能。在 Agent 能力方面，DeepSeek-V3.2 也取得了显著的进步，尤其是在 EvalSys 等基准测试中引入的长尾 Agent 任务上表现出色。为了进一步探索开源模型在推理领域的潜力，DeepSeek-V3.2-Speciale 放宽了长度限制，达到了与领先的闭源系统 Gemini-3.0-Pro 相当的性能水平，并在多个国际奥林匹克竞赛中取得了金牌级别的成绩。

总而言之，DeepSeek-V3.2 通过 DSA 提高了计算效率，通过强化学习框架提升了推理能力，并通过大规模 Agent 任务合成管线增强了 Agent 性能，为开源大语言模型的发展做出了重要贡献。

Beej 发布计算机科学学习指南

Beej 发布了一份计算机科学学习指南，旨在帮助初学者入门。该指南涵盖了 HTML 格式和 PDF 格式，同时也为翻译者和作者提供了 GitHub 链接。

这份指南目前还是一个半成品，但作者希望它能对读者有所帮助。内容包括 HTML 基础知识，并提供多种格式下载，方便不同需求的读者。作者也鼓励大家通过 GitHub 参与贡献和纠错。指南还提供了联系方式，方便读者反馈意见。

评论区里，有人提到软件开发中爱好与工作之间的界限模糊，导致行业内出现一些不良现象。程序员常常利用业余时间学习新技能，无偿加班，而那些不这样做的人则被认为不够热爱。这种文化使得那些仅仅为了赚钱而工作的人面临更大的压力。还有人提到了在不同 HN 帖子中，关于 AI 的讨论态度差异很大，怀疑某些帖子可能存在来自 AI 相关组织的幕后操纵。也有人分享了使用 Beej 的网络编程指南的经验，认为它非常棒，并将其应用到了 Rust 语言中。很多人表达了对 Beej 的感谢，认为他的指南对他们的学习和职业生涯非常有帮助。此外，还有人提出了关于使用 Python 实现非阻塞 TLS 服务器的问题，希望找到相关的指南。总的来说，评论区对 Beej 的新指南表示欢迎，并分享了各自的学习经验和问题。

Zig 异步编程新方案：兼顾简洁与性能

Zig 编程语言正在探索一种新的异步代码设计方案，旨在解决函数着色问题，并实现同步和异步 I/O 代码的复用。该方案通过引入泛型接口 Io 来隐藏异步操作，力求在不增加语言复杂性的前提下，实现对异步操作的精细控制和高性能事件驱动 I/O。

Zig 的设计者们不希望像其他语言那样引入特殊的异步语法，也不希望像 Haskell 那样将所有操作都变为异步。他们希望找到一种更简洁、更可控的方式。新的 Io 接口允许开发者通过传递 Io 实例来执行 I/O 操作。标准库提供了 Io.Threaded 和 Io.Evented 两种实现，前者使用同步操作，后者使用事件循环和异步 I/O。开发者也可以根据需要实现自定义的 Io 版本。

使用 Io.Threaded 时，代码会像普通的同步代码一样执行，除非显式地使用 async() 函数来并行执行任务。而使用 Io.Evented 时，代码会利用 io_uring 或 kqueue 等异步后端，实现真正的异步操作。这种设计使得开发者可以先编写简单的同步代码，然后在需要时通过异步操作进行性能优化，而无需修改函数签名或代码结构。

如果程序需要在两个部分同时执行以保证正确性（例如，监听端口和响应用户输入），则可以使用 asyncConcurrent() 函数来显式地并行运行指定的函数。Io.Threaded 会使用线程池中的线程来完成此操作，而 Io.Evented 则将其视为普通的 async() 调用。

总的来说，Zig 的新异步方案旨在提供一种灵活、可控、高性能的异步编程模型，同时保持语言的简洁性和可读性。虽然代码可能略显冗长，但它仍然是标准的 Zig 代码，可以使用 try 和 defer 等常用的控制流原语。

解构 Brian Eno 的《Ambient 1: Music for Airports》

本文深入探讨了 Brian Eno 如何创作出具有里程碑意义的氛围音乐专辑《Ambient 1: Music for Airports》。文章详细介绍了这张专辑的创作背景、录制过程以及 Eno 独特的音乐理念。

文章指出，《Music for Airports》并非史上第一张氛围音乐专辑，但它是第一张被明确定义为“氛围音乐”的专辑。Eno 在创作中大量运用磁带循环技术，这可以追溯到他与 Robert Fripp 合作的《(No Pussyfooting)》。他通过控制磁带机的物理距离来调整延迟，创造出丰富的音景。在《Discreet Music》中，Eno 使用了两个不同长度的磁带循环，制造出一种相位效果，使得每次重复都产生不同的变化。

《Music for Airports》的录制始于 1976 年，Eno 在 Conny Plank 的录音室录制了由三位女歌手演唱的单音符，然后通过磁带机进行循环。他使用长度不一的磁带循环，使得这些循环以不同的速率重复，从而产生意想不到的组合和变化。Eno 认为，这种方式创作出的音乐听起来并不机械或数学化，反而像是有人充满感情地演奏钢琴。文章还提到了专辑封面的图形乐谱，这是 Eno 为无法读写乐谱的自己设计的，用图形符号来表示每个乐句或循环。最后，文章还对专辑中的曲目《1/1》进行了分析。

由于没有评论内容，这里就不进行评论观点的总结和分析了。

DIY 飞行航班信息 LED 显示墙：TheFlightWall

想在家中实时显示你周围的航班信息吗？TheFlightWall 是一个开源项目，教你如何用 LED 面板打造一个航班信息显示墙，让你随时掌握空中的动态。

这个项目使用 ESP32 开发板，配合 16x16 LED 面板，通过 OpenSky 和 FlightAware AeroAPI 获取航班数据。你需要准备一些主要组件，包括 20 个 LED 面板、ESP32 开发板、3D 打印支架（或 MDF/纸板）以及木条。电源方面，需要 5V 20A 的电源适配器和 3.3V-5V 电压转换器。

在软件方面，你需要注册 OpenSky 和 FlightAware AeroAPI 的账号，获取 API 密钥，并将其配置到 APIConfiguration.h 文件中。同时，还需要在 WiFiConfiguration.h 中设置你的 WiFi 凭据，并在 UserConfiguration.h 中设置你的位置信息，以便追踪附近的航班。

项目使用了 PlatformIO 构建和烧录固件到 ESP32。你可以在 UserConfiguration.h 中自定义显示亮度、文字颜色等参数。硬件配置方面，可以在 HardwareConfiguration.h 中调整引脚和面板布局。

这个项目的核心在于利用开源数据和硬件，打造一个个性化的航班信息显示设备。虽然刷新率不高，不适合玩游戏，但对于关注航班信息的爱好者来说，是一个不错的 DIY 选择。如果你不想自己动手，也可以直接购买他们的官方产品。

评论区里，有用户表示很喜欢这个项目，认为 ESP32 是一个很棒的平台。还有用户表示，自己也考虑过类似的项目，因为他们住在机场的航线下，对航班信息很感兴趣。

'逆向数学' 揭示难题为何难解

本文探讨了“逆向数学”如何用于理解计算复杂性理论中难题的本质，以及为何证明这些难题如此困难。研究者使用元数学技巧来揭示表面上不同的定理在逻辑上是等价的。

文章指出，计算机科学家在解决难题方面遇到了瓶颈，例如旅行商问题。尽管人们怀疑不存在更有效的算法，但无法证明这一点。计算复杂性理论试图将“旅行商问题很难”这类直观陈述转化为严格的数学定理，但进展甚微。

逆向数学通过改变数学系统的基本假设（公理），来研究这些改变如何影响可证明的定理。在计算复杂性理论中，这种方法旨在了解不同的公理集可以证明哪些关于计算难度的结论，从而帮助理解证明难题的障碍。文章还提到，通过研究证明过程本身，元数学家希望找到新的思路来攻克这些难题。

总而言之，逆向数学为理解计算复杂性难题的本质和证明难度提供了一个新的视角，它通过分析公理系统与可证明定理之间的关系，为未来的研究提供了方向。

Elixir v1.19 的惰性二元决策图 (BDD) 用于集合论类型

本文主要介绍了 Elixir 团队和 CNRS 合作，为 Elixir 设计的集合论类型系统，以及 Elixir v1.19 中引入的优化方案，重点在于使用惰性二元决策图（BDD）来更有效地表示和操作类型。文章深入探讨了类型系统的实现细节，解释了从析取范式 (DNF) 到 BDD 的演变过程，以及 BDD 如何解决 DNF 在处理类型推断和否定时遇到的性能问题。

文章首先解释了析取范式 (DNF) 的概念，它是一种使用析取（并集）和合取（交集）来标准化表示逻辑公式的方法。在 Elixir 中，DNF 被用来表示 union 和 intersection 类型。文章展示了 DNF 的优点，例如其简单的结构，但也指出了其缺点，即在执行交集操作时可能导致指数级的膨胀，尤其是在处理包含大量 union 的类型时。

接着，文章解释了 Elixir v1.19 中引入的匿名函数类型推断功能，以及它如何加剧了 DNF 的性能问题。匿名函数类型推断需要使用否定（difference）来表示类型，这使得 DNF 的大小呈指数级增长，导致编译时间过长。

为了解决这个问题，Elixir v1.19 引入了二元决策图 (BDD)。BDD 将集合论操作表示为有序树，从而可以更有效地表示和操作类型。文章详细解释了 BDD 的节点类型（:top，:bottom 和三元组），以及如何使用 BDD 来表示各种类型操作，例如交集、并集和差集。通过使用 BDD，Elixir 可以避免 DNF 的指数级膨胀问题，从而提高类型推断的性能。

(由于没有评论内容，跳过评论相关的输出)

C 语言中的 URL 奇妙现象：一段可以编译运行的代码

这段 C 语言代码 https://susam.net/ 加上 printf("hello, world\n"); 竟然可以成功编译并运行，这究竟是怎么回事？

原来，https: 在 C 语言中被解释为一个标签（label），而 // 及其后面的内容则被视为 C99 引入的行注释。因此，编译器会忽略 //susam.net/ 这部分内容，将其视为注释。C99 标准明确指出，// 引入的注释会一直延续到行尾。所以，这段代码实际上定义了一个名为 https: 的标签，但并没有被使用，而 printf 语句则正常执行。

评论区也引发了热烈的讨论，大家分享了各种有趣的发现和使用场景。

  • 有人分享了同事不小心将 YouTube 链接粘贴到 Java 代码库中的趣事，说明了类似情况在实际开发中可能会发生。
  • 有人展示了一种巧妙的注释技巧，可以通过修改注释中的斜杠来控制代码的执行。
  • 有人指出，如果代码启用了语法高亮，这个问题会变得非常明显。
  • 有人提到，如果使用相同的 scheme 定义多个 URL，编译器会报错，提示标签重复定义。
  • 还有人分享了将 shell 命令嵌入 C/C++ 代码中的技巧，通过 #if 和 #endif 将命令包裹起来，使其在文本编辑器中可以通过快捷键执行。
  • 有人称赞 C++ 的 // 注释方式，并庆幸它也被引入到 C 语言中。
  • 有人提到，启用 -Wall 编译选项后，编译器会给出未使用标签的警告，从而提示开发者。
  • 最后，有人认为，了解 C 语言的解析规则后，这个问题其实并不难理解。

评论中也有人建议只使用 /* */ 风格的注释，以避免此类问题。总的来说，评论区从不同角度探讨了这个问题，并分享了各自的经验和看法。

三大模型挑战：Codex、Opus、Gemini 尝试构建《反恐精英》

本文记录了 Codex Max 5.1、Claude Opus 4.5 和 Gemini 3 Pro 三大模型挑战构建一个基础版《反恐精英》的过程，重点考察了它们在前端和后端开发中的表现。文章通过一系列提示词，引导模型逐步完成游戏地图、角色、射击逻辑、音效以及多人联机功能。

在前端方面，Claude Opus 4.5 在地图、角色和枪械的设计上表现最佳，整体场景效果也更胜一筹。Gemini 3 Pro 在后端开发中更具优势，尤其是在多人联机和数据持久化方面，错误更少。Codex Max 则表现均衡，在前端和后端均取得不错的成绩，但亮点不足。

具体来说，在创建地图和物理效果方面，Claude 生成的地图最具吸引力，而 Codex 首次运行出现错误。在角色设计上，Claude 再次领先，其角色设计接近《我的世界》的水平。在添加枪械和后坐力动画方面，Claude 和 Codex 一次成功，而 Gemini 则遇到了枪械透明的问题。在音效和动画方面，所有模型都顺利添加了音效，但对“死亡动画”的理解存在偏差，都将其理解为角色死亡方式的动画。

在后端开发中，Gemini 在位置共享方面表现出色，而 Codex 和 Claude 需要更多指导。文章观察到，Codex 倾向于大量使用内省，不断查看 TypeScript 库中的可用函数；Claude 则更依赖文档，反复阅读关于 presence 的文档；Gemini 似乎兼顾两者，既查阅文档，又通过运行构建步骤来发现并修复 TypeScript 错误。在实现射击功能方面，文章未提供详细信息。

总的来说，这次实验展示了不同模型在游戏开发中的优势和劣势，为开发者选择合适的模型提供了参考。

Ghostty Web：基于 xterm.js 的 Web 终端实现

这篇文章介绍了 coder/ghostty-web，一个与 xterm.js API 兼容的 Web 终端项目。Ghostty-web 旨在提供一个高性能、现代化的 Web 终端体验，它使用 WASM (WebAssembly) 构建，充分利用了 Web 浏览器的性能优势。该项目通过实现 xterm.js API，使得开发者可以轻松地将 Ghostty-web 集成到现有的 Web 应用中，而无需进行大量的代码修改。

Ghostty-web 的核心优势在于其高性能和与 xterm.js 的兼容性。由于使用了 WASM，它能够提供接近原生应用的性能，从而实现流畅的终端体验。同时，兼容 xterm.js API 意味着开发者可以利用现有的 xterm.js 插件和扩展，快速构建功能丰富的 Web 终端应用。项目采用 MIT 许可，允许开发者自由地使用和修改代码。目前该项目有 824 个 star 和 21 个 fork，表明其在开发者社区中具有一定的受欢迎程度。该项目还提供了分支、标签和活动等功能，方便开发者进行版本控制和协作。

有趣的物理学猜想

本文作者分享了一些他认为有趣的、跳脱传统思维的物理学猜想，包括轻子可能不产生引力、引力可能是矩阵力学的熵增结果，以及电子可能是具有环形拓扑结构的光子。这些想法虽然可能不完全正确，但能够激发人们对宇宙本质的思考。

作者首先提到，主流物理学研究，例如对新材料或标准模型的验证，已经让人感到乏味。他更喜欢那些能让人思考“如果宇宙是这样会怎样”的古怪科学。第一个猜想是关于轻子，特别是电子，它们质量很小，作者认为它们是否产生引力尚未精确测量。第二个猜想认为引力是矩阵力学中熵增的结果，通过快慢时间尺度矩阵元素之间的复杂纠缠相互作用产生。虽然这个猜想使用了面条理论，但作者仍然觉得将引力视为熵增现象很有趣。第三个猜想，也是作者最喜欢的，是电子可能是一个具有环形拓扑结构的光子。这个想法可以解释电子的许多特性，例如自旋、磁偶极矩和电荷，甚至可以自然地推导出电子的康普顿波长，从而解释量子力学的起源。

总的来说，作者希望通过分享这些“古怪”的物理学想法，鼓励人们进行更具想象力的思考，挑战现有的物理学框架。

2025 年 12 月谁在招聘？

这篇帖子汇总了 2025 年 12 月份正在招聘的公司和职位，主要面向软件工程师、数据工程师、AI 相关人才等。其中既有全职岗位，也有远程和混合办公的选择，地点涵盖欧洲、美国等地。

文章列举了多家公司的招聘信息，包括 Langdock、Rover、Recital、Subsets、Holepunch、Internet Archive 和 Matterworks.ai 等。Langdock 正在招聘产品工程师、基础设施工程师和 AI 助理，地点在德国柏林。Rover 在巴塞罗那和西雅图都有职位空缺，包括数据分析工程师、软件工程师和 SRE 等。Recital 是一家位于加拿大的远程 startup，招聘有 Ruby on Rails 和现代前端框架经验的全栈工程师。Subsets 位于丹麦哥本哈根，招聘全栈、后端和数据工程师。Holepunch 是一家致力于 P2P 平台的公司，招聘远程 Node.js 工程师。Internet Archive 正在寻找数据中心网络基础设施工程师，地点在旧金山。Matterworks.ai 正在招聘机器学习科学家和工程师，可以选择远程或在波士顿/萨默维尔混合办公。

这些公司涉及的领域包括 LLM 平台、宠物护理、法律科技、订阅业务增长、P2P 网络、互联网档案和生物数据分析等。技术栈也比较多样，包括 NextJS、React、Prisma、Postgres、Redis、Terraform、Azure、AWS、GCP、OpenShift、Ruby on Rails、Vue 等。

评论区集中展示了各个公司的招聘岗位，方便求职者直接查看并申请。总体来看，这些招聘信息为软件开发者和科技爱好者提供了丰富的就业机会。

使用 Rust 实现 Rootless Ping

本文介绍了如何使用 Rust 语言在没有 root 权限的情况下发送 ping 包。通常创建 ICMP socket 需要 root 权限，但通过使用 UDP socket 并设置特定的协议标志，可以绕过这个限制。

文章的核心在于展示了如何创建一个无需 root 权限即可发送 ICMP 包的 UDP socket。首先，使用 socket2 crate 创建一个指定 ICMP 协议的 UDP socket。其次，构建 ping 数据包，需要注意的是，Linux 和 macOS 在处理校验和以及是否包含 IP 头部上有所不同。在 Linux 上，内核会覆盖标识符和校验和字段，而在 macOS 上则需要手动计算校验和。最后，接收并解析响应，同样需要根据操作系统来处理 IP 头部。文章还指出了 macOS 在响应中包含 IP 头部，而 Linux 则不包含。作者提供了一个 GitHub 仓库的示例代码，展示了具体实现。

评论区对文章进行了补充和讨论。有人指出，文章实际上创建的是 IP datagram socket，而非真正的 UDP socket，并解释了 Linux 允许 rootless ping 的机制，与 net.ipv4.ping_group_range 相关。另有评论提到，在 Linux 上可以通过添加 CAP_NET_RAW capability 或配置 net.ipv4.ping_group_range sysctl 来允许非 root 用户执行标准 ping 命令。还有人分享了 Python 的 icmplib 库，该库也提供了 privileged 选项来处理 ICMP 数据包。有人强调了在容器环境中使用 unprivileged DGRAM 方法的重要性，并指出了 Linux 和 macOS 在校验和处理上的差异。最后，有人建议增加 IPv6 支持，并指出了文章中关于 Linux 和 macOS 在 ICMP socket 行为差异的描述非常重要。有评论指出提供的 GitHub 仓库链接已失效。

瑞士地图中的秘密：地图绘制者的隐藏插图

这篇文章讲述了瑞士地图绘制者在官方地图中偷偷隐藏插图的趣事。这些隐藏的图像，如土拨鼠、人脸和蜘蛛等，挑战了地图绘制的精确性和客观性原则，也展现了地图绘制者在严谨工作中的一丝创意和幽默。

文章指出，瑞士联邦地形办公室（Swisstopo）的地图制作过程非常严格，但一些地图绘制者还是设法在地图中加入了这些不易察觉的图像。这些行为被视为对机构规则的“违抗”，因为他们的职责是“重构现实”。为了不被发现，许多地图绘制者选择在退休时或退休后才公开这些秘密。一旦被发现，这些插图通常会被移除，就像2016年发现的土拨鼠图案一样，很可能在下一次官方地图更新中消失。

文章还提到了地图中错误的普遍性，包括意外错误和故意为之。故意错误通常用于防止版权侵犯，例如虚构街道。然而，瑞士地图绘制者的隐藏插图更多的是一种内部玩笑和应对日常工作的方式。在长时间的高精度工作下，这些小插图成为了他们突破常规、寻找乐趣的方式。这种行为也反映了地图绘制者在严谨的专业精神之外，对个性和创意的追求。

Replicate 加入 Cloudflare：强强联合，共筑 AI 基础设施

Cloudflare 宣布 Replicate 正式加入，旨在结合双方优势，构建更强大的 AI 基础设施层，将模型运行、网络、存储等能力整合，加速 AI 应用的开发和部署。

Replicate 最初的目标是让开发者更容易地使用机器学习模型，他们开发了 Cog，一种用于机器学习模型的标准打包格式，以及 Replicate 平台，用于以 API 形式运行 Cog 模型。Cloudflare 拥有强大的网络、Workers、R2 和 Durable Objects 等基础设施，这为构建完整的 AI 技术栈提供了坚实的基础。双方的结合能够实现在边缘运行快速模型、在 Workers 上运行模型管道、通过 WebRTC 流式传输模型输入和输出等功能，极大地提升 AI 应用的性能和效率。Replicate 在生成式 AI 服务平台领域处于领先地位，定义了许多被同行采用的抽象和设计模式，Cloudflare 的加入将进一步加速 AI 技术的发展和应用。

评论区观点：

  • 收购的根本原因： 有评论指出，Replicate 加入 Cloudflare 的直接原因是资金流动，即 Cloudflare 向 Replicate 的股东支付了收购费用。
  • Replicate 的价值主张： 有开发者分享了自己使用 Cog 的经历，认为对于有能力的工程师来说，Cog 可能会成为阻碍，而不是加速器。他们更倾向于使用轻量级的 FastAPI 层来运行模型，因为这样可以更灵活地控制 I/O、使用最新的 Docker 镜像，以及并行运行不同的框架。因此，对于技术实力较强的创业公司来说，Replicate 的“易用性”优势可能并不明显。
  • AI 中间件市场的挑战： 有评论认为，独立的 AI 中间件市场面临着快速变化和技术创始人自主性的挑战，这可能是 Replicate 选择被收购的原因之一。

总的来说，评论区对此次收购的动机和 Replicate 的价值提出了不同的看法，既有对资金层面的解读，也有对技术选型和市场竞争的分析，体现了开发者们对 AI 领域发展趋势的关注和思考。

博客写作十年心得：写给无人阅读的博客

这篇文章探讨了作者坚持写博客十年的经验与感悟，重点分享了写作技巧、写作过程以及写作的意义。作者反思了自己写作风格的演变，强调了简洁明了的重要性，并讨论了在人工智能时代人工写作的价值。

作者分享了自己写作的动力之一是提升写作水平，他坦诚早期作品存在冗余和口语化的问题，建议避免使用过多限定词和模糊表达。文章强调写作应是公开交流的贡献，即使阅读量不高，也要清晰表达观点，不怕被挑战。作者还提到了写作过程的迭代性，强调多次修改和不同视角的审视，以及随时记录灵感的重要性。此外，文章也探讨了人工智能对写作的影响，认为尽管AI写作工具的出现降低了写作门槛，但人工写作依然具有主观价值，例如通过书评加深对阅读内容的理解，并促进知识的整合。作者最后总结道，写作是一个不断改进的过程，需要不断精简内容，聚焦核心思想。

评论区中，一位读者分享了自己担任法官助理的经验，强调了写作时明确受众的重要性。他建议作者在写作时，应针对特定受众，逐句审查，删除无助于传达信息的句子，并建议在追求说服力时，优先呈现最有力的论点，并剔除薄弱的论据，以避免给读者留下作者黔驴技穷的印象。

评论 0 条

暂无评论，来种下第一颗种子。