Hacker News 每日播报，今天我们将深入探讨科技裁员背后的税法“定时炸弹”、GitLab 如何将备份时间从 48 小时缩短到 41 分钟、日本研究人员开发的透明纸能否替代塑料、Amazon 资助下的 FreeBSD 开发进展、YouTube 对自托管媒体的“有害”判定、以及将 C 代码移植到 WebAssembly 的“受虐”之旅，最后还会关注 Meta AI 的隐私争议和 Sandia 实验室的“无存储”类脑超算。

近期科技行业的大规模裁员潮，除了疫情期间过度招聘和 AI 崛起等常见原因外，一项鲜为人知但影响深远的美国税法调整被认为是其幕后推手。文章指出，美国税法第 174 条在 2022 年生效的静默修改，要求企业将研发（R&D）支出从原先的当年 100% 立即抵扣，改为在美国本土 5 年内、海外 15 年内分期摊销。

这项调整显著增加了研发密集型公司的税务负担，即使实际现金流未变，账面应税收入也大幅增加，导致税单沉重。对于尚未盈利或现金流紧张的公司而言，影响尤为剧烈。文章认为，这正是 2023 年初开始的科技裁员潮的“隐藏加速器”，使得作为研发主要开支的人力成本成为最容易被削减的部分。

围绕这一观点，社区展开了热烈讨论。许多人认同税法变化是一个被低估的因素，认为这是“捡了芝麻丢了西瓜”的政策。然而，也有不少声音对此表示怀疑，认为宏观经济环境恶化（利率上升、融资成本增加）、疫情期间的过度招聘、市场泡沫破裂以及 AI 的影响才是更主要的原因。更普遍的观点是，裁员是多种因素叠加的结果，税法变化可能不是唯一原因，但它无疑是一个重要的“助推器”或“催化剂”，使得研发成本的增加在经济下行背景下变得难以承受，从而加速了裁员的发生。讨论还触及了税收政策本身，以及这项变化对初创企业和中小型公司的更大打击。

GitLab 团队通过优化底层 Git 命令的性能，成功将大型仓库的备份时间从惊人的 48 小时缩短到仅仅 41 分钟。文章详细介绍了他们如何解决这一痛点。

大型 Git 仓库备份面临时间过长、资源消耗大、难以安排维护窗口以及长时间运行易失败等挑战。GitLab 团队通过火焰图分析发现，git bundle create 命令在处理大量引用时，一个名为 object_array_remove_duplicates() 的函数效率低下，其 O(N²) 的时间复杂度对于拥有数百万引用的仓库而言是严重的性能瓶颈。

解决方案是贡献一个上游补丁给 Git 项目，用更高效的哈希表（map）代替嵌套循环进行去重，将时间复杂度大大降低。这项改进被 Git 社区接受并合并，GitLab 也迅速将其回port到自己的版本中。结果是，GitLab 最大的仓库备份时间从 48 小时锐减到 41 分钟，性能提升显著，不仅降低了数据丢失风险，还节省了资源和成本。

社区对这项工作表现出高度赞赏，特别是对 GitLab 将修复贡献回上游 Git 项目的行为给予了积极评价。关于 O(N²) 复杂度，许多开发者分享了类似经历，认同“O(N²) 是一个甜蜜点：快到足以进入生产环境，但慢到足以在数据量增长后崩溃”的观点。大家还讨论了为何使用 git bundle 而非文件系统快照（如 ZFS），解释了 git bundle 在异地存储和加速初始克隆方面的优势。尽管一些人认为文章风格略显冗长，但普遍认为这项技术改进本身非常有价值。

日本研究人员开发出了一种“透明纸”，有望成为塑料的环保替代品。这项研究利用植物生物质中的纤维素，成功制造出了厚实且透明的纸张。

这种透明纸的主要成分来源于棉籽纤维粉末，通过特定工艺制成。其最大的亮点在于环保特性：它是可生物降解的，能在微生物作用下分解成水和二氧化碳。研究甚至在海中进行了测试，发现即使在深海也能在四个月内基本分解。此外，这种透明纸具有相当的强度和透明度，可与聚碳酸酯塑料媲美，有望替代需要看到内容的塑料容器。当然，大规模生产的技术和成本仍是其推向市场的主要挑战。

社区围绕这篇文章展开了热烈讨论。一个主要讨论点集中在塑料为何如此普及，认为其轻便、耐用、防水、易模塑、成本低廉等特性才是关键，透明度并非主要原因。这引出了关于塑料“真实成本”和环境外部性的讨论，不少人认为塑料的低价并未包含其对环境的长期损害。

关于塑料废弃物的处理方式也引发了激辩：是焚烧发电更好，还是填埋更优？支持焚烧的观点认为可以产生能源，减少填埋量；反对者则强调焚烧会释放碳，加剧气候变化。而关于填埋，更多人担忧的是塑料长期存在以及最终分解产生的微塑料问题，认为其是比宏观塑料垃圾更隐蔽和普遍的威胁。讨论还触及了新材料在恶劣环境下的实用性，以及废弃物收集和回收的挑战与激励，例如欧洲成功的押金返还系统。

Tarsnap 创始人兼 FreeBSD 资深贡献者 Colin Percival 分享了过去一年在 Amazon 资助下，他在 FreeBSD 项目上所做的工作，主要集中在 FreeBSD 的发布工程和 Amazon EC2 平台上的开发与维护。

Colin 提到，Amazon 通过 GitHub Sponsors 为他提供了为期一年的资金支持。在发布工程方面，他主导了四个 FreeBSD 版本的发布，并成功将发布构建过程并行化，将构建时间从约 22 小时大幅缩短到约 13 小时。最引人注目的是 FreeBSD/EC2 平台的开发工作，他优先处理了 AWS Graviton 实例的电源驱动和设备热插拔功能，解决了复杂的兼容性问题和 Amazon 方面的固件 bug。

此外，Colin 还投入大量精力优化了 FreeBSD 在 EC2 上的启动性能。他发现了一个令人惊讶的现象：将根磁盘大小从 5GB 增加到 6GB 竟然导致启动时间慢了三倍，而增加到 8GB 又恢复了性能，这可能与 Amazon EBS 缓存的“魔法”启发式算法有关。他还解决了 Graviton 2 实例上因熵不足导致的启动停滞问题，以及 ZFS 镜像启动慢和 IMDSv2 访问慢的问题。

社区对文章中的技术细节表示赞赏，特别是对磁盘大小与启动性能的神秘关联感到好奇，Colin 进一步解释这可能与 Amazon EBS 后端存储的缓存启发式算法有关。企业对开源的资助也是一个重要讨论点，社区探讨了 Amazon 直接资助开发者与通过基金会资助的区别，以及其他公司对 FreeBSD 的贡献。关于 FreeBSD 的定位及其与 Linux、OpenBSD、NetBSD 的比较也引发了深入探讨，FreeBSD 用户强调其在平衡性、ZFS 支持、性能、系统集成度以及社区文化方面的优势。

Jeff Geerling 在其博客上发表文章，指出 YouTube 将他关于在 Raspberry Pi 5 上使用 LibreELEC 播放 4K 视频的教程标记为违反社区准则，理由是推广“危险或有害内容”，具体指未经授权或免费获取付费音视频内容。

Jeff 强调，他的视频刻意避免展示任何可能用于盗版或规避版权的工具，他只是想展示如何方便地观看自己合法拥有的媒体库。尽管视频在引起社交媒体关注后被 YouTube 恢复，但这暴露了平台审核机制的随意性和对内容创作者的潜在威胁。他将 YouTube 的巨大影响力和收入潜力比作“黄金手铐”，使得创作者的内容和生计随时可能受到平台任意规则变动或误判的影响。

社区对 Jeff 的遭遇表达了广泛的同情和共鸣。许多人认为 YouTube 的自动化审核系统存在严重问题，容易产生误判，且这种系统可能更倾向于迎合大型媒体公司的利益。一些人指出，像 Kodi（LibreELEC 基于的软件）过去确实因为第三方插件被用于非法目的而声名狼藉，这可能导致平台将其与盗版关联起来，即使软件本身是干净合法的。寻找 YouTube 替代方案的挑战也是一个重要话题，普遍认为其他平台在用户基数、发现机制和可持续性方面与 YouTube 存在巨大差距。讨论还触及了数字所有权和信息自由的更广泛议题，将自托管媒体视为对抗订阅服务碎片化和内容随时可能消失的方式。

Sebastiano Tronto 撰写了一篇引人注目的文章，记录了他将一个复杂的 C 语言 Rubik's Cube 求解器移植到 Web 上的经历，使用了 Emscripten 工具链将 C 代码编译成 WebAssembly (WASM)。他坦承，这并非一条轻松的道路，更像是一场充满挑战的“受虐”之旅。

文章详细分解了整个移植过程中的关键技术点和遇到的障碍，包括：基础编译与运行、WebAssembly 简介、构建库与导出函数、JavaScript 与 DOM 交互、模块化构建（特别是 .mjs 文件扩展名带来的麻烦）、多线程（通过 pthreads 和 Web Workers 实现，需要设置特定的 HTTP 响应头）、避免阻塞主线程、回调函数、以及持久化存储（利用 IndexedDB）。作者的核心体会是“抽象无处不在，但它们都在漏水”，即尽管 Emscripten 试图抽象 Web 平台的复杂性，但一旦涉及多线程、文件系统、内存管理等高级特性，开发者就必须深入理解底层细节。

社区对这篇文章的反应非常热烈，许多开发者对作者的经历表示共鸣。一个最突出的讨论点集中在 JavaScript 的模块系统，多位开发者对 .mjs 文件扩展名和 CommonJS 到 ESM 的过渡带来的麻烦深有同感。另一个重要话题是 WebAssembly 的性能，文章中提到“接近原生速度”引发了讨论，共识是 WASM 对于移植大型、计算密集型的原生代码库非常有用，但并非所有场景都能带来巨大性能提升。此外，社区也有开发者分享了他们在 Web/Node.js 环境中处理多线程和共享内存的痛苦经历，进一步印证了作者关于“抽象泄露”的观点。

Mozilla 基金会发布博文，强烈呼吁 Meta 立即关闭其 AI Discover feed，认为 Meta 正在悄悄地将用户与 AI 的私密对话转化为公开内容，而许多用户对此并不知情。Mozilla 强调，这种做法模糊了私人与公共的界限，侵犯了用户隐私，并且缺乏知情同意。

Mozilla 提出了五项具体要求，包括在建立真正的隐私保护措施之前关闭 Discover feed、将所有 AI 互动默认设置为私密、完全透明地公开有多少用户在不知情的情况下分享了私人信息、为所有 Meta 平台创建通用易用的退出系统，以及通知所有对话可能已被公开的用户并允许他们永久删除相关内容。

社区对 Mozilla 的呼吁展开了多角度的讨论。一个核心争议点在于 Meta 的 AI 分享机制究竟是如何工作的，以及 Mozilla 的描述是否准确。一些人指出，AI 对话默认是私密的，用户需要点击“分享”按钮并确认才能公开。但另一些人则认为，问题在于用户对“分享”按钮的普遍认知，Meta 将其行为设置为“发布”到公共 feed，即使有预览和确认步骤，也可能构成一种“暗模式”，利用用户习惯导致他们无意中公开了本以为是私密的对话。讨论也触及了用户理解能力与平台责任，以及对 Mozilla 沟通方式的批评，认为其文章缺乏具体细节，可能为了宣传目的而夸大问题。

Sandia 国家实验室最近启动了一台名为 SpiNNaker 2 的新型超级计算机，这台机器被描述为“类脑”且“无存储”。这台由德国公司 SpiNNcloud 提供的系统，旨在模拟大规模脉冲神经网络（Spiking Neural Networks, SNNs）。

SpiNNaker 2 的核心在于其高度并行的架构，每个芯片包含 152 个基于 Arm 的核心和专用加速器，并配备 20MB 的 SRAM。文章强调，SpiNNaker 2 系统没有传统的操作系统或磁盘存储。它通过高速的芯片间通信和庞大的内存容量来处理数据，并通过标准的以太网端口连接到现有的高性能计算（HPC）系统进行数据加载和保存。这种设计据称比基于 GPU 的系统在处理复杂的事件驱动计算和模拟时更具能效，并且能够以生物学上的实时速度模拟大型类脑网络。

社区对这台新机器的发布表现出浓厚兴趣，但也伴随着一些疑问和讨论。首先，关于“无存储”的说法引发了广泛讨论，许多人指出文章中提到的庞大 DRAM 容量本身就是一种存储，更准确的说法应该是“无持久性存储”或“无磁盘/操作系统”。其次，关于神经形态计算本身的潜力与挑战，社区观点多样，有人对其编程难度以及是否能支持现有机器学习框架表示怀疑。讨论还将其架构与现有 GPU 或 FPGA 进行比较，并探讨了其在哪些特定类型的计算任务上能超越传统架构。

一篇来自 Apple 的论文《思维的幻觉：推理模型的优势与局限性》引起了广泛关注。这篇论文深入探讨了大型推理模型（LRMs），即那些在给出答案前会生成详细“思考过程”的模型。

论文的核心观点是，当前对这些模型能力的评估主要依赖于数学和编程基准测试，但这存在数据污染问题，并且无法深入了解模型内部的推理过程。为了更系统地研究 LRMs，作者们采用了可控的谜题环境，例如汉诺塔、跳棋等，通过模拟器验证中间步骤，从而分析模型是如何“思考”的。

论文的主要发现引人注目：LRMs 在面对不同复杂性问题时表现出三种截然不同的性能模式——低复杂度时标准 LLMs 更优，中等复杂度时 LRMs 展现优势，但当问题复杂度达到一定阈值后，无论是 LRMs 还是标准 LLMs，其准确率都会完全崩溃。论文还发现 LRMs 存在一个反直觉的扩展限制，即随着问题复杂度的增加，模型最初会投入更多推理努力，但当接近其性能崩溃点时，反而会减少推理努力。此外，通过对模型内部“思考痕迹”的分析，作者们发现了“过度思考”现象，并质疑了 LRMs 执行精确计算的能力。

社区对论文采用可控谜题环境来评估模型能力的方法表示赞赏，并对“三种复杂度模式”和“推理崩溃”现象感到特别有趣。关于 LRMs 是否真正“思考”或“推理”的辩论是核心焦点。一些人认为，模型使用语言生成“思考痕迹”容易让人产生错觉，但其内部机制可能完全不同，本质上是强大的模式匹配器和概率生成器，缺乏真正的语义理解。另一些人则持更开放或结果导向的观点，认为判断智能应该看结果，而不是机制。讨论还触及了语言本身作为认知工具的局限性，以及如何构建更可靠的 AI 系统。

Odyc.js 是一个微型 JavaScript 库，旨在帮助即使没有丰富编程经验的人也能创建视频游戏，特别是那些侧重于叙事或文本驱动的游戏。项目网站强调“边玩边创造游戏”的理念，并提供了文档、一个在线试玩平台和示例游戏画廊。

示例游戏包括简单的像素或 ASCII 风格游戏，如基础的汽车驾驶、角色地图导航和互动场景，展示了该库为创建具有视觉、声音和文本的互动体验提供的基本构建块。

社区对“叙事游戏”这个标签提出了疑问，认为示例并不完全符合他们对叙事游戏的定义。创建者 achtaitaipai 解释说，该库的结构侧重于回合制互动、消息、提示和对话，因此感觉适合叙事或文本驱动的游戏，但也承认标签可能需要重新考虑。这引发了关于简单屏幕游戏类型描述的讨论，有人建议“ZZT-like”可能更贴切，并将其与 RPGMaker、Bitsy 等其他易于上手的游戏创作工具进行比较。

除了类型辩论，社区普遍对该项目表示赞赏，称赞其使用 ASCII 地图进行原型设计的简洁性以及整体的易用性。许多人认为 Odyc.js 是一个很棒的学习工具，特别是对于儿童，它提供了一个从可视化编程到更复杂引擎之间的良好过渡。从技术角度看，编辑器的打字和自动补全功能受到了特别好评。创建者还确认该项目是开源的，并计划很快添加 MIT 风格的许可证，鼓励社区贡献。

相关链接：

• The time bomb in the tax code that's fueling mass tech layoffs
• How we decreased GitLab repo backup times from 48 hours to 41 minutes
• Researchers develop ‘transparent paper’ as alternative to plastics
• A year of funded FreeBSD development
• Self-hosting your own media considered harmful according to YouTube
• A masochist's guide to web development
• Meta: Shut down your invasive AI Discover feed
• Sandia turns on brain-like storage-free supercomputer
• The Illusion of Thinking: Strengths and limitations of reasoning models [pdf]
• Odyc.js – A tiny JavaScript library for narrative games