Defold：免费、高性能的跨平台游戏引擎
Defold 是一款免费、开箱即用且经过生产验证的游戏引擎，旨在帮助开发者高效构建跨平台的高性能游戏。它提供包含代码和可视化编辑器的完整开发环境，支持 Lua 脚本，并内置场景、粒子、瓦片地图等编辑器，同时支持 2D 和 3D 游戏开发。其核心优势在于真正的跨平台能力，开发者可以使用单一代码库，无需外部工具即可为 PlayStation、Switch、移动设备、桌面端、Steam 和 HTML5 等多个平台构建游戏。
Defold 引擎介绍
Defold 提供了一套完整的游戏开发解决方案。下载编辑器后即可开始工作，无需复杂的环境配置。引擎内置了可视化编辑器和代码编辑器，配备了支持调试器的 Lua 脚本环境，以及用于场景、粒子效果和瓦片地图的专用编辑器，能够满足 2D 和 3D 游戏的开发需求。
Defold 强调其“交钥匙”式的开发体验，主要通过预制构件（building blocks）和 Lua 脚本来构建游戏逻辑。它还提供了零配置的云构建服务，用于生成原生代码包。此外，开发者可以通过原生代码扩展引擎功能，并与外部工具集成。
最吸引人的一点是，得益于 Defold 基金会的支持，该引擎完全免费，无任何前期成本、授权费、版税或运行时费用。官方也强调了其在商业项目中的成功案例（如 Family Island）、活跃的月度更新以及可用的技术支持服务。
社区讨论
社区中讨论最热烈的是 Defold 的授权模式。用户赞赏 Defold 明确将其称为“源码可用”（source-available）而非“开源”（open source）。其许可证被认为是公平的：允许开发者为自己的游戏进行闭源修改（不同于 GPL），可以自由地商业化游戏，并承诺不会有“诱导转向”（bait-and-switch）的策略。
然而，关键限制在于不能将引擎本身或其衍生品商业化。这引发了关于何为“衍生品”或“游戏引擎产品”的讨论，例如销售基于 Defold 构建的工具或编辑器是否被允许。一些人认为这种限制是必要的，可以防止他人分叉并销售增强版本，从而分裂社区或损害基金会的目标；另一些人则质疑这种担忧的必要性，因为引擎本身是免费的。
Defold 经常被拿来与 Godot 等其他引擎比较。普遍认为 Defold 在 2D、移动和 Web 平台表现强劲，占用资源少，物理引擎稳定；而 Godot 在 3D 方面更先进，但主机平台移植通常依赖第三方（往往是付费服务），Defold 则能更直接地支持主机平台。
对于 Defold 选择 Lua 作为脚本语言，社区看法不一。一些人认为 Lua 足够胜任，而另一些人则认为对于大型项目来说，Lua 可能会成为“雷区”。不过，也有人提到了类型化 Lua（Teal）和实验性的 C# 支持等选项。引擎源自 King（糖果传奇开发商）的背景也被提及，社区还讨论了 Defold 基金会如何通过企业合作和付费支持服务来维持发展，而非仅仅依靠捐赠。
Kagi Search 为付费用户全面开放 AI 助手
Kagi Search 近期宣布，其 AI 助手功能已向所有付费用户开放，此前该功能为 Ultimate 订阅计划专享。该助手基于 Kagi 搜索结果，并整合了顶尖的大语言模型（LLM），旨在帮助用户更高效地研究和整合信息。Kagi 强调其 AI 哲学：AI 是辅助研究的工具，用于增强用户能力，而非取代独立思考。
Kagi Assistant 功能介绍
Kagi Assistant 的核心能力是基于 Kagi 搜索结果进行问答。用户也可以选择关闭网络访问，直接与 AI 模型进行对话。此外，它还支持上传文件以提供额外的上下文信息。
用户可以创建定制化的助手（Custom Assistants），为其设定特定的指令和偏好，例如专门用于编程辅助或特定领域知识查询。在对话过程中，用户可以编辑提示（prompt）、切换不同的 AI 模型，从而保持对交流过程的控制。
隐私是 Kagi 的核心承诺之一。所有对话默认是私密的，不会被用于训练 AI 模型。
定价与公平使用政策
针对 AI 助手的使用，Kagi 引入了基于订阅计划价值的公平使用政策。每个用户的月费对应一定的原始 token 成本额度。Kagi 表示，预计 95% 的用户不会达到这个上限。
Kagi 解释称，之所以开始强制执行这项政策，是因为少数用户消耗了巨额的 token 成本，影响了服务的可持续性。不同的订阅计划可访问的 AI 模型种类有所不同，Ultimate 计划提供最丰富的模型选择。目前，这项功能正在分阶段向全球用户推出。
社区反馈
评论区对 Kagi 的举措反响热烈。许多用户赞赏 Kagi 在公平使用政策上的透明度，认为这种直接说明成本和定价逻辑的方式非常清晰。但也有用户对“无限”助手（Kagi 曾用此宣传语）与实际存在的公平使用限制之间的矛盾感到困惑，一些老用户觉得自己的权益价值被稀释了。
一个反复出现的讨论点是关于 AI 服务的未来模式：用户是应该为每个 SaaS 服务单独支付模型使用费，还是应该出现一种“自带模型”（Bring Your Own Model, BYOM）的模式？后者允许用户在一个地方支付模型费用，然后在各种服务中连接使用。有人认为这代表了软件模式从垂直整合向水平代理的转变，并指出 OpenAI 的 SSO 策略可能预示着这一方向。
关于 Kagi 服务本身的价值，许多用户认为其搜索质量远超免费选项，每月 10 美元的专业版物有所值。即使是 5 美元的入门计划，用户也可以通过提前续订的方式灵活应对搜索量超限的问题。不过，也有用户觉得每月 300 次搜索不够用，希望能有按量付费或基于速率限制的选项。
用户还将 Kagi Assistant 与 Perplexity 进行了比较。一些人认为 Kagi 在通用搜索和聊天方面更均衡，而 Perplexity 在特定类型的搜索问答上可能更强，但在界面和上下文管理方面有待改进。
此外，用户还提出了一些具体的产品反馈，例如希望看到更详细的 token 使用量统计。还有用户报告了网站阻止页面缩放的问题，Kagi 团队成员已在评论区回应并表示已修复。
最后，关于在工作环境中使用 Kagi Assistant，有用户询问是否有禁用 AI 功能的选项，因为其公司有严格的无 AI 政策。这反映了企业用户在采用此类工具时面临的实际挑战。
通过 68 万首歌曲分析和弦走向的趋势
一位作者利用名为“Chordonomicon”的新数据集，对 68 万首歌曲的和弦使用模式进行了分析。该数据集来源于 Ultimate-Guitar 网站，包含了大量歌曲的和弦进行和流派信息，旨在探索流行音乐中的和弦规律。
Chordonomicon 数据集分析
分析首先关注了最常见的单个和弦。结果显示，G 大调和 C 大调和弦位居榜首，尤其在乡村音乐等流派中更为普遍。
接着，作者将和弦分为大三和弦、七和弦、强力和弦等类别，并展示了它们在不同音乐流派中的使用频率差异显著：爵士乐偏爱七和弦，朋克音乐倾向于使用强力和弦，而说唱音乐则很少使用挂留和弦、减和弦或增和弦。
从时间趋势来看，分析发现自 20 世纪 40 年代以来，七和弦的使用率显著下降，这很大程度上与爵士乐的衰落相关。与此同时，简单的 小三和弦变得更加常见。
最后，为了探讨现代音乐是否越来越重复的问题，作者分析了每首歌曲的“独特和弦率”（unique chord rate）。结果表明，自 20 世纪 60 年代以来，这一比率显著下降，暗示现代歌曲的和弦进行确实变得更加冗余。作者承认旋律和节奏等其他音乐元素也至关重要，但数据确实指向了数十年来和弦选择简化的趋势。
社区评论与质疑
评论区的讨论非常热烈，主要集中在数据来源的可靠性和分析方法的局限性上。
一个主要的争议点是数据集来源于 Ultimate-Guitar 的吉他谱。许多音乐人认为这些吉他谱常常不准确、过于简化，并且忽略了和弦转位、声部配置或变调夹（capo）使用等关键细节。
最大的批评则在于，该分析主要关注的是 单个和弦 的出现频率，而不是 和弦进行（chord progressions）或和弦之间的 关系。评论者认为，音乐的核心在于和弦的变化和它们在调性中的功能（通常用罗马数字表示，如 I-IV-V），仅仅统计单个和弦忽略了音乐的基本结构和和声。
一些评论者根据自己的音乐经验，指出了分析中一些看似不合理的数据点，例如报告中金属和朋克音乐里强力和弦的比例偏低，或者爵士乐中大三和弦的普遍性。
尽管对方法论和数据质量存在诸多批评，但讨论本身也深入探讨了有趣的乐理概念和分析音乐数据的替代方法，例如使用和弦转换矩阵（transition matrices）或像 Hooktheory 这样的相对和弦分析工具。
使用 Lua 开发 6 万行代码游戏项目的经验反思
一位主程序员分享了使用 Defold 引擎（该引擎重度使用 Lua）开发游戏《Craftomation 101》（一个拥有约 6 万行 Lua 代码的项目）的经验。作者回顾了在发布一个重要项目后，对 Lua 语言的特性、优点和挑战的看法。
使用 Lua 开发大型游戏的经验
选择 Lua 的主要原因是 Defold 对其原生支持，一位同事也推荐了它，并且 Defold 引擎非常适合制作轻量级的 Web 版本，这对于项目的教育用途至关重要。
在项目初期，作者对 Lua 的一些特性感到惊讶，例如数组索引从 1 开始、缺少简单的自增运算符（++）、以及没有 continue 语句。这些对于习惯了 C++ 和 Python 的开发者来说感觉有些不适应。
一个主要的学习曲线是理解 Lua 的“万物皆 table”哲学，特别是赋值操作通常创建的是引用而非副本。在彻底理解这一基本行为之前，这导致了一些棘手的 bug。尽管初期有些困惑并因此产生了一些 bug，但作者发现与 C++ 相比，使用 table 来组织游戏逻辑非常方便。
对于他们的项目来说，Lua 的性能感觉“足够快”。虽然可以使用 C++ 模块来解决性能瓶颈，但通常通过优化 Lua 算法就足够了。与使用 Python 的经验类似，作者已经习惯了动态类型带来的运行时错误，因此缺少编译步骤并不是一个巨大的冲击。不过，他们也指出静态分析工具可以帮助更早地发现问题。
社区讨论：动态 vs 静态类型
评论区主要围绕作者希望在未来大型项目中获得编译时检查的需求，展开了关于动态类型与静态类型优劣的激烈讨论。
许多开发者认同动态语言在项目规模扩大后难以维护的观点，指出了函数签名变更和参数不匹配等问题，而这些问题本可以被静态类型检查捕获。一些人认为，对于动态语言，单元测试至关重要，可以弥补类型检查的缺失；而另一些人则反驳说，静态类型相当于免费提供了一套庞大的编译时测试。Python 的类型提示（type hints）和 TypeScript 被提及，作为给动态语言添加静态验证的方法，但也有人觉得它们提供的信心和强制性检查不如 Go 或 Rust 等语言。
评论者们也分享了自己遇到 Lua 特性的经历，比如删除 table 元素时的行为，或者 1-based 索引在与 C 语言交互时导致的 off-by-one 错误。
尽管存在挑战，许多人承认 Lua 在游戏开发中的历史地位和持续应用，它经常作为 C/C++ 核心引擎之上的灵活脚本层，并列举了许多使用 Lua 的著名游戏。
Defold 团队成员也参与了讨论，确认他们正在朝着支持通用转译器（transpiler）和官方 Teal（一种类型化的 Lua 方言，而非 Luau）支持的方向发展，同时也在改进 C/C++ SDK 选项。这表明 Defold 引擎正在不断进化，以解决部分与语言相关的担忧。
AMP for Email 的兴衰：为何邮件不应变得过于“动态”
这篇文章探讨了 Google 的 AMP for Email 项目，并分析了为什么电子邮件不应该（也可能永远不会）变得像现代网页那样具有丰富的交互性。文章首先回顾了 AMP (Accelerated Mobile Pages) 最初在移动网页上的推广历程，它如何通过性能优势和搜索排名激励开发者采用，但也因其对开放网络的潜在威胁和 Google 的垄断行为而备受批评。
AMP for Email 的目标与挑战
文章接着详细介绍了 AMP for Email 的目标：让邮件内容能够保持最新状态，并允许用户直接在收件箱中执行操作，例如回复评论或预订酒店。它使用了与 AMP for Web 相同的框架，但组件集更小。
然而，实现 AMP Email 对发送方来说负担沉重。开发者不仅需要额外编写邮件的 AMP 版本，还需要完成复杂的域名认证和注册流程。尽管 Google 在自家服务（如 Google Docs 的评论回复）中使用了该技术，但 AMP for Email 的客户端支持非常有限，微软在尝试后甚至放弃了对其的支持。
AMP for Email 的消亡与电子邮件的本质
最终，随着 Google 悄悄停止对 AMP for Web 的推广，AMP for Email 也随之淡出人们的视线，尽管 Google 内部仍在使用其“动态邮件”（Dynamic Email）功能。
文章认为，电子邮件之所以能够长久存在，恰恰在于其简单、去中心化以及内容相对静态的特性。这使得电子邮件成为互联网上少数能够保留永久记录的地方之一。而 AMP 所追求的动态性，恰恰破坏了电子邮件这一核心价值。
社区观点
评论区对此反应强烈，许多人认为电子邮件的核心价值在于其作为“数字纸质记录”的不可变性。他们担心交互式或动态邮件会导致邮件内容在发送后被修改，从而带来“被煤气灯效应”（gaslighting）的风险，破坏邮件作为历史记录的可靠性。
一些用户分享了亚马逊等公司从邮件中移除订单详情，转而只提供链接的做法，认为这同样是为了让公司保留对信息的控制权，而非真正为了用户方便。
关于 AMP for Web，评论者们承认它在技术上提供了一些性能优势和“护栏”（guardrails），有助于防止开发者创建过于臃肿的网站。但普遍认为，其推广的主要驱动力是 Google 的市场垄断地位以及对开放网络的潜在威胁。也有人指出，AMP 的一些技术理念（如使用预构建组件）与 HTMX 等现代前端技术有相似之处，但 Google 的强制推广方式是问题的关键。
少数评论者对交互式邮件持更开放的态度，认为某些用例（如在邮件中直接接受会议邀请）确实很方便。甚至有人设想，未来是否会出现一个基于开放标准的、像 Slack 一样强大的交互式通信平台来取代现有的邮件系统。
但主流观点仍然是，电子邮件的静态和去中心化特性是其宝贵的优势，不应为了追求短暂的交互性而牺牲。
网络数据包大小之谜：为何至今没有完美答案？
这篇文章探讨了一个看似简单却困扰网络工程师数十年的问题：网络数据包到底应该多大？尽管我们依赖包交换网络已有几十年历史，但对于理想的数据包大小，至今仍没有一个明确的、普遍适用的答案。
互联网默认包大小的历史根源
文章追溯了历史，解释了为何互联网的默认数据包大小（MTU，最大传输单元）通常在 20 到 1500 字节之间。这很大程度上是受早期 10Mbps 以太网设计的影响。当时 1518 字节的最大帧大小是基于数据传输时序、网络利用率以及 CSMA/CD 碰撞检测算法等多方面因素权衡的结果。
随着以太网速度从 Mbps 飙升到 Tbps 级别，虽然物理层技术发生了翻天覆地的变化（从共享总线到交换机），但为了保持向后兼容性，基本的帧大小规范却一直沿用至今。
大包的优势与挑战
这带来了一个问题：传输速度飞速增长，但处理每个数据包所需的芯片处理能力增长相对缓慢，使得处理大量小数据包的压力越来越大。
理论上，更大的数据包（例如数据中心常用的 Jumbo Frames，通常为 9000 字节）能够提高传输效率，因为固定大小的包头开销被分摊到更大的数据载荷上。IP 协议本身也支持更大的数据包。
然而，在公共互联网上，普遍存在的路径 MTU（Path MTU）限制以及 IP 分片（fragmentation）带来的问题（如丢包风险增加、与安全中间件冲突等）使得大包传输变得不可靠。路径 MTU 发现（PMTUD）机制本应解决这个问题，但由于各种原因（例如防火墙阻挡 ICMP 消息），它在实践中并不可靠，而且实现起来也很复杂。
因此，许多应用程序和主机，包括像 QUIC 这样的新协议，宁愿选择使用一个更小的、成功率更高的默认 MTU（如 1200 或 1500 字节），以避免分片和 PMTUD 带来的麻烦。
社区讨论与实践
评论区里，大家对这个话题感触颇深。有人分享了亲身经历的“血泪史”：在一个金融交易系统中，仅仅因为消息大小增加了几个字节，超过了 1500 字节的 MTU 限制，导致大量消息被分片，进而引发了严重的延迟问题。这生动地说明了 MTU 限制和分片开销在高性能场景下的巨大影响。
关于如何改进 MTU 发现机制，评论区展开了热烈讨论。有人提出了一种激进的想法：网络中间设备在遇到超大包时，不是直接丢弃，而是将其截断后转发。终端可以通过比较接收到的数据大小和包内编码的原始大小来发现路径 MTU。这种方法理论上可以简化发现过程并提高可靠性，因为它不依赖于 ICMP 消息，且发现信息直接到达终端。
但反对者也指出了其中的复杂性和潜在问题，例如如何处理截断后包的校验和、如何区分是 MTU 截断还是其他原因导致的损坏、以及在多层隧道（VPN、VXLAN 等）场景下的实现困难和分层违规问题。
大家普遍认为，尽管现有的 PMTUD 机制（尤其是依赖 ICMP 的那种）在实践中确实不可靠，经常被防火墙或性能低下的路由器 CPU 阻碍，但它至少在设计上避免了中间设备修改数据包内容，相对更符合网络分层原则。
最终，许多评论者都认同文章的观点：在公共互联网上，手动设置一个保守的、有高成功率的 MTU 值（比如 1500 字节）往往是最务实的选择，即使这意味着牺牲一些潜在的效率。大家也提到，虽然数据中心等受控环境可以使用 Jumbo Frames，但将这种大包无缝扩展到复杂的公共互联网仍然是一个难题。
美国法院裁定大规模手机信号塔数据转储违宪
美国内华达州一位联邦法官近期做出一项重要裁决，认定执法部门获取特定区域和时间段内连接到某个手机信号塔的所有手机数据的行为，即“塔楼转储”（tower dumps），违反了美国宪法。
内华达州法院裁决：“塔楼转储”违宪
“塔楼转储”本质上是一种“拖网式”搜查。执法部门通过这种方式，可以获取潜在成千上万人的位置信息和身份识别信息，而不仅仅是犯罪嫌疑人。只要用户的手机与信号塔通信（通常每隔几秒），其数据就可能被收集。
法官 Miranda M. Du 认为，这种做法违反了美国宪法第四修正案关于禁止无理搜查和扣押的规定。她特别指出，用于授权此类搜查的令状属于被禁止的“一般令状”（general warrants），即没有明确指明搜查对象的令状。
“善意例外”及其争议
然而，该裁决也应用了“善意例外”（good faith exception）原则。这意味着，尽管搜查方式被认定为违宪，但警方在本案中通过“塔楼转储”获得的证据仍然可以使用。理由是警方当时是依据另一位法官签发的令状行事，并相信该令状是合法的。
这是第九巡回上诉法院首次就“塔楼转储”的合宪性做出明确裁决，尽管密西西比州的一位联邦法官最近也得出了类似结论。
更广泛的影响与未来
这个问题，特别是在最高法院就针对特定目标的手机位置数据案（Carpenter v. United States）做出有限裁决之后，很可能最终会提交至最高法院寻求最终定论。在本案中，一次“塔楼转储”就捕获了 1686 名用户的数据，凸显了此类搜查的广泛性。
社区反应
Hacker News 社区的评论主要聚焦于“善意例外”原则。许多用户对此表示失望和不满，认为执法人员似乎总能因其后来被认定为违宪的行为而免受惩罚，这与普通公民被期望了解并遵守法律的情况形成鲜明对比。
评论中弥漫着对警方策略（包括在审讯中撒谎）的普遍不信任感，这也印证了“没有律师在场绝不与警察交谈”的普遍建议。一些人争论责任主要在于申请如此宽泛令状的警方，还是在于批准这些令状的法官，尽管“善意例外”通常在法官签发令状的情况下保护警方。
讨论还涉及该裁决可能对其他监控方法（如地理围栏令状或 Stingray 设备）产生的影响，以及裁决的重点究竟是数据收集的 广度 本身，还是使用手机信号塔数据这一行为。
最终，许多评论者认为，这项裁决虽然在原则上是积极的，但允许使用非法获取的证据削弱了其效果，并质疑其在阻止未来违宪搜查方面的实际威慑力。
2025 年，还能用纯 C 语言开发 iOS 应用吗？
Hacker News 上最近讨论了一个问题：到了 2025 年，是否仍然可以使用纯 C 语言来构建 iOS 应用程序？简短的答案是：技术上可行，但对于开发一个带有标准用户界面的普通应用来说，这远非简单或典型的方式。
技术上的可能性
核心思路在于 Objective-C，作为苹果许多旧框架（如 UIKit）的基础，其本身是构建在 C 语言运行时之上的。这意味着理论上可以绕过 Objective-C 的语法，直接调用底层的 C 函数来与系统交互。这就像是手动编写 Objective-C 编译器会为你生成的代码。
然而，正如许多评论者指出的那样，这样做比直接使用 Objective-C 或 Swift 语法要复杂得多，体验也差得多。
实践中的挑战与替代方案
对于特定类型的应用，例如不严重依赖标准 UI 元素的游戏或实用工具，像 SDL (Simple DirectMedia Layer) 这样的库提供了一个 C API。SDL 抽象了许多平台相关的细节，包括图形、音频和输入处理，使得在这些场景下使用纯 C 语言变得更加可行。
苹果也提供了一些底层的 C API，用于处理 CoreFoundation 或使用 Metal/QuartzCore 进行图形渲染等任务。但是，主要的 UI 框架 UIKit 并没有一个可以直接、方便使用的 C 语言等价物。
社区观点
讨论中呈现了多种观点：
- 不切实际论： 一些人认为，虽然技术上可能，但对于大多数应用来说不切实际，因为你最终不可避免地需要与苹果的框架交互，而这些框架是为 Objective-C 或 Swift 设计的。
- 混合方法论： 另一些人则指向混合开发模式，即将性能关键或跨平台的核心逻辑用 C 或 C++ 编写，然后用一个最小化的 Objective-C 或 Swift 层来处理 UI 和操作系统集成。这是一种常见的模式，尤其是在游戏或包含复杂引擎的应用中。
- 跨平台库： 还有人讨论使用 C 语言编写跨平台（iOS、Android、桌面）共享库，并用原生代码进行封装。
- 底层操作： 直接写入帧缓冲区（framebuffer）的想法也被提及，作为一种极端可能性，类似于某些低级别的 Android 开发示例。
最终的共识倾向于：虽然你可以从 C 语言调用 Objective-C 运行时，但你仍然是在与一个基于 Objective-C 的系统进行交互。使用纯 C 开发 iOS 应用在特定领域（如游戏、底层工具）或用于教育/实验目的是可能的，但它并非 2025 年构建典型 iOS 应用的主流或简便方法。
惊艳！这款 Doom 风格游戏竟能塞进一个 QR 码
Hacker News 上展示了一个令人印象深刻的项目：有人构建了一款受《Doom》和“The Backrooms”启发的网页游戏，并且整个游戏能够完全嵌入到一个 QR 码中。这个项目的核心理念是挑战 QR 码的数据容量极限，并将其作为一个自包含的 Web 应用来运行。
“The Backdooms”项目介绍
开发者 Kuberwastaken 创作了这款名为“The Backdooms”的小型、无限生成的 HTML 游戏。整个游戏代码被压缩到大约 2.4KB，并直接嵌入到一个 HTML 包装器内的 data: URI 中。
当你扫描包含这个长 data: URI 的 QR 码时，你的浏览器会打开这个自包含的 HTML 页面。页面随后利用 JavaScript 中的 DecompressionStream API 实时解压缩游戏代码并运行它。该游戏设计为扫描后完全离线运行，展示了一种无需独立服务器即可分发轻量级 Web 应用的创新方式。
技术实现细节
这个项目涉及了高超的压缩技巧，包括使用一个自定义脚本结合 Zlib 进行压缩（配合 Gzip 解压缩），并仔细调整 QR 码的版本和纠错级别以最大化数据容量。
社区反馈与互动
评论区的用户对此赞不绝口，称其为“非常酷！”和“疯狂的东西！”。
讨论的焦点之一是能将如此多的功能塞进如此小的空间的技艺，特别是对 DecompressionStream API 和 data: URL 的巧妙运用表示赞赏。
然而，许多用户在尝试用手机自带相机扫描这个大型 QR 码时遇到了困难，或者在某些移动浏览器（如 Safari 和 Firefox）上无法正常运行游戏。这些浏览器有时难以处理过大的 data: URI 或缺乏完整的 API 支持。
作者非常积极地回应了反馈，解释说大型 QR 码通常需要专门的扫描器应用，并最初指出由于大小限制，移动端兼容性有限。但随后，在一个体现开源精神的互动中，有社区成员提交了一个 Pull Request，进一步压缩了代码字节数，使得作者能够在托管版本中为游戏添加基本的移动触摸支持！
社区还讨论了运行嵌入在 QR 码中任意代码的安全隐患，尽管有人指出通过 QR 码链接到恶意网站本身就是一个已知的风险。
其他用户也分享了类似的项目，这些项目涉及极端的大小限制或让《Doom》在意想不到的硬件上运行，突显了技术社区长期以来对这类挑战的浓厚兴趣。
Trail of Bits 为 Python 构建高性能 ASN.1 API
信息安全公司 Trail of Bits 发表文章，介绍了他们正在为 Python 构建的一个新的 ASN.1 API。此举旨在解决 ASN.1 数据结构带来的复杂性问题。ASN.1 在密码学、网络和电信领域非常普遍，尤其用于像 TLS 证书（X.509）这样的场景。
背景：ASN.1 的复杂性与现有库问题
核心问题在于，尽管 Python 拥有像 pyasn1 这样的现有 ASN.1 库，但它们通常因为是纯 Python 实现而面临性能瓶颈。更严重的是，它们可能引入“解析器差异”（parser differentials）——即不同库对相同数据可能产生细微的解释差异，这可能导致安全漏洞。
Trail of Bits 的新 API
Trail of Bits 在 Alpha-Omega 项目的资助下，正在将一个新的 ASN.1 API 集成到广受欢迎的 cryptography 库中。这个新 API 利用了一个快速、纯 Rust 编写的 ASN.1 解析器（该解析器已被 cryptography 库用于解析 X.509 证书）。此举旨在显著提升性能，并通过使用相同的底层逻辑来减少棘手的解析器差异问题。
此外，新 API 采用了现代 Pythonic 设计风格，使用 dataclasses 和类型提示（type hints），使其相比旧 API 更易于使用。文章展示了一个示例：开发者可以使用带有类型提示和装饰器的 Python dataclass 来定义 ASN.1 结构，然后轻松地从 DER（Distinguished Encoding Rules）字节流解析或编码为 DER 字节流。这项工作建立在他们之前在 X.509 验证方面努力的基础上，显示了其致力于改善 Python 安全生态系统的决心。
社区讨论
评论区的讨论内容丰富，既有历史回顾，也探讨了更广泛的 ASN.1 生态。
一些资深开发者回忆了公钥基础设施（PKI）的早期发展，以及为何选择 DER 而非 Sun 的 XDR 等替代方案。他们强调了 DER 的确定性（determinism）和规范化格式（canonical formats）对于安全性和简化状态机分析的重要性，即使这意味着早期的一些性能开销。
讨论还涉及了其他的 Rust ASN.1 库，例如 rasn。rasn 支持更多的编码规则，如 UPER（Unaligned Packed Encoding Rules）。UPER 是一种在电信领域广泛使用但极其难以处理的格式，其规范通常定义在难以解析的 DOCX 文件中。社区讨论了 UPER 的挑战以及缺乏完全兼容的开源工具的现状，并将其与相对简单的 DER 进行了对比。
多位评论者强调了 DER 规范化特性的价值，尤其是在对数据结构进行签名等场景下，一致的字节表示至关重要。
关于“纯 Python”与使用原生扩展（如 Rust）的争论也再次出现。虽然纯 Python 曾因兼容性而被视为卖点，但现在的共识倾向于对性能敏感的任务使用编译型代码，尤其是在现代打包工具（如 wheels）使得分发更加容易的情况下。
最后，商业 ASN.1 工具（如 OSS Nokalva 提供的工具）的角色也被提及。评论指出，尽管这些工具价格昂贵，但它们提供了开源替代品有时缺乏的支持和保障。不过，许多人仍希望强大的开源选项能够不断涌现和发展。