1. 光盘也能玩出花？大神重拾“图像烧录”神技，让CD表面显影！ (A tool for burning visible pictures on a compact disc surface)
一位开发者近日分享了他重拾的“CD图像烧录”项目，通过独特技术将数字图像以肉眼可见的方式烧录到光盘表面，唤醒了对CD时代的回忆。这项非凡的创意并非首次尝试，作者早年受启发于15年前的Instructables用户和另一位名为[unDEFER]的开发者，并在2008年开发了原型，但因不同光盘品牌和型号的几何校准难题而一度搁置。
如今，他重新梳理旧代码并将其成功移植到现代Qt6平台，甚至为Windows用户提供了便捷的二进制版本，希望能为这一独特的概念注入新生命。该工具的核心原理是生成一个约800MB的特殊音频轨道，通过标准光驱烧录后，光盘表面便能呈现出独特的图像。然而，项目的最大挑战在于光盘的几何参数差异——即使是同一型号的光盘也可能存在细微差别，这极大地影响了图像的计算精度。因此，用户若想成功，需要精确已知的光盘几何参数或进行复杂的手动校准，这无疑是一项技术与耐心的双重考验。
尽管面临校准难题，作者对项目的未来仍充满好奇与乐观。他提出了利用先进图像识别算法甚至人工智能来自动化这一过程的设想，以取代目前依赖人工经验的繁琐步骤。这不仅仅是一个向CD时代致敬的怀旧之作，更是一项融合了计算数学与潜在AI应用的多目标优化挑战。作者期待科技爱好者们能加入进来，共同探索光盘的“艺术”潜能，让这份独特的科技魅力在当下绽放光彩。
原文链接：https://github.com/arduinocelentano/cdimage
论坛讨论链接：https://news.ycombinator.com/item?id=44208283
社区成员围绕光盘刻录技术展开了怀旧讨论。一些人对LightScribe技术印象深刻，认为它“很棒”。有评论者提到自己仍珍藏着未拆封的LightScribe DVD，因其停产而觉得使用它们显得“亵渎”，且4.7GB的容量在当下已不足用。
然而，也有人指出4.7GB的光盘容量仍足以存储Linux系统，可用于为老旧PC或不常用架构保存操作系统，甚至可能在eBay上卖出好价钱。一些“新旧库存”媒体收藏者证实了市场需求，他们热衷于购买如软盘、MiniDisc、Zip磁盘等旧式存储介质。不过，目前eBay上LightScribe光盘的价格显示其收藏价值尚未显著。
讨论随后转向了Yamaha的另一项类似技术——DiscT@2。这款名为CRW-F1的刻录机（2002年发布）能够在CD-ROM的未使用区域刻录图像和文本，被视为“酷炫”功能，其写入时独特的紫色指示灯也令人印象深刻。多位用户表示自己曾拥有或仍保留着这款刻录机，其中有人在Linux环境下成功测试了DiscT@2功能，还有人回忆起其独特的盘片托架设计。
2. Cloudflare认证库幕后：我“考古”了所有Claude生成的代码提交 (I read all of Cloudflare’s Claude-generated commits)
近日，Cloudflare开源了一个由AI模型Claude几乎完全编写的OAuth 2.1认证库，引发科技界广泛关注。该项目最独特之处在于，其将开发全过程、每次AI指令（prompt）、迭代及人工干预都详细记录在Git提交信息中，仿佛一次“人机协作考古”，生动展现了人类直觉与人工智能之间的实时对话。
首席工程师Kentonv最初对AI持怀疑态度，但短短两个月内，Claude就为这个生产级认证库生成了绝大部分代码，令他信服。研究显示，高效AI协作模式包括：以代码示例作初始指令，以及简洁、情境化的反馈。AI在生成文档方面表现尤为出色，将繁琐工作变得轻而易举。
然而，AI在复杂代码重构与格式清理等“家务活”上仍显不足。尽管AI生成了逾95%代码，但人类的指导与判断至关重要，有时手动修复反而更高效。此次实践不仅是技术里程碑，更揭示了未来人机协作的新动态：AI负责机械实现，人类提供战略方向。尽管目前仍需大量人工参与，但像Claude Code这样不断自我进化的AI工具，正逐步拓宽我们的创造边界，为科技发展注入无限可能。
原文链接：https://www.maxemitchell.com/writings/i-read-all-of-cloudflares-claude-generated-commits/
论坛讨论链接：https://news.ycombinator.com/item?id=44205697
社区中一项关于将AI提示词（prompt）视为实际源代码的提议引发了热烈讨论，提议者认为，此举能将提示词纳入版本控制，以便模型改进后重新生成整个代码库。
然而，多数评论者对此表示反对。有人质疑，在存储成本几乎为零时，不提交生成的代码本身就不可思议，且会导致无法审计安全漏洞或调试。一位拥有十余年代码生成器项目经验的开发者分享道，将生成的代码与人工编写代码放在同一仓库不可持续，因审查性质不同；他们发现生成后修改代码或追求100%代码生成均不可行，最终需将人工代码注入生成代码中，且生成器改动需特性开关。
另有评论者区分了传统确定性代码生成器与LLM（大型语言模型）的根本区别，认为LLM更像人类处理输入输出。一位AI项目经验丰富的用户强调，即使使用相同模型工具，按序重跑LLM提示词也几乎必然失败，因为后续提示可能引用不存在的代码或回应未出现的AI输出。这使得元提示（AI准备AI提示）和人工代码修改的表示变得异常复杂。整体而言，这种想法忽视了AI并非无限快或免费。
3. 航空数据迷思：程序员不了解的飞行真相 (Falsehoods programmers believe about aviation)
专业航班追踪公司FlightAware的工程师们发现，处理海量航空数据时，现实远比想象中复杂。他们梳理了关于航班、机场、航空公司、导航系统乃至ADS-B应答器的一系列“错误假设”，揭示了航空数据背后有趣的真相。
例如，航班号可能重复，不同航班短时间内使用相同编号；机场识别码不唯一，甚至美国机场的ICAO代码并非都以“K”开头；航空公司代码或飞行任务分配并不总是清晰；导航信息可能延迟或不准确，飞机甚至可能多次改变目的地。ADS-B信号也非仅来自飞机，其GPS定位并非绝对精确，应答器数据还可能被错误编程或人为篡改。
这些看似“混乱”的真实数据，给软件系统带来巨大挑战。为向用户提供干净、一致、可靠的航班追踪信息，FlightAware的“Hyperfeed”引擎肩负重任，它必须巧妙解析和整合这些“奇特”且变量繁多的数据流。这不仅考验技术实力，也生动展现了大数据处理的精妙之处，让我们对航空科技的精准与韧性充满好奇与赞叹。
原文链接：https://flightaware.engineering/falsehoods-programmers-believe-about-aviation/
论坛讨论链接：https://news.ycombinator.com/item?id=44205590
飞机没有单一、不变的唯一标识符，这让一位社区用户感到惊讶。该用户参与了一项专利，认为飞机从生产到报废的唯一真正标识符是制造商、型号和序列号的组合。他解释说，飞机注册号、机尾号或ICAO 24位地址等常见标识符都可能发生变化或存在歧义。
社区其他讨论者对这种看似简单的概念如何获得专利表示好奇。一些评论指出，在大型公司，工程师们发现自己很容易被鼓励甚至被要求为看似基本或未实现的概念申请专利。有用户提到，在微软时，避免名字出现在专利上比主动申请更困难。一位谷歌前员工则表示，公司为提交和批准的专利提供丰厚奖金，甚至曾因提交未实现的技术架构专利而获得不菲的报酬，这凸显了在大公司获得专利的便捷性。
有评论认为，将一个简单想法包裹在大量模糊的技术细节中，就足以满足专利局、律师和公司的要求，使公司得以宣称其拥有“超级创新专利”。讨论者们普遍认为，某些概念之所以能获得专利，可能仅仅因为它们处于特定领域（如航空业），而非其内在的复杂性或创新性，甚至被戏称为“右键级别”的专利。这反映了社区对大公司专利实践的普遍看法。
4. 苹果传奇陨落：比尔·阿特金森逝世，享年74岁 (Bill Atkinson has died)
苹果和计算机界传奇人物比尔·阿特金森于2025年6月5日因胰腺癌辞世，享年74岁。作为Macintosh核心团队关键成员，他以高效优雅的代码和算法，在硬件限制下实现诸多“不可能”。阿特金森是QuickDraw、MacPaint（像素图像编辑典范）和HyperCard的缔造者，后者影响深远。他发明的抖动算法至今仍活跃于Playdate等设备。这位被誉为“史上最伟大程序员之一”的奇才，其卓越贡献深刻改变了数字世界，永远值得铭记。
原文链接：https://daringfireball.net/linked/2025/06/07/bill-atkinson-rip
论坛讨论链接：https://news.ycombinator.com/item?id=44210606
社区中，一位曾任苹果ColorSync团队的工程师分享了他与史蒂夫·乔布斯私下会面的经历。他回忆当时仅限于讨论色彩相关技术，未能深入交流其他话题，至今感到遗憾。乔布斯当时热衷于数字摄影，使用高端滚筒扫描仪扫描中画幅胶片，对数字工作流能更好地捕捉“暗部”细节感到兴奋，认为传统模拟冲印会导致暗部细节流失。乔布斯曾向他们展示他拍摄的海岸岩石照片，特别强调阴影中的细节，并透露当时正准备出版一本摄影集。这位工程师坦言最初对乔布斯斥巨资玩摄影有所保留，将“技术流”与“艺术流”对立，但后来意识到顶尖摄影师（如安塞尔·亚当斯）的作品中，技术与艺术实则密不可分。
另一位评论者看到此言论后，随即抓住机会，希望能与这位工程师就Macintosh色彩的演进，特别是色彩选择器进行非正式交流。此外，讨论中有人指出，数字摄影至今仍难以完全达到乔布斯当年所追求的那种高动态范围，尽管进步显著，但仍需在单色摄影等领域应对类似限制。还有评论者提到，价格亲民的优秀单色数码相机难寻，且不敢尝试移除彩色CCD上的拜耳滤镜来增强低光表现，尽管此举可能带来额外的曝光档位，但也会同时移除有助于提升感光度的微透镜。另有人曾考虑用天文级单色CCD制作相机，但高像素型号价格不菲。
5. 告别Nix：Railway的百万级用户飞跃之路 (Why We’re Moving on from Nix)
Railway 近日发布全新构建器 Railpack，旨在取代其在过去三年中构建了超1400万应用的 Nixpacks。Nixpacks 虽服务80%用户，但其在版本管理、镜像体积及缓存效率上的局限性，影响了20万用户日常体验，促使 Railway 为支持用户规模从百万级迈向亿级，决心进行重大升级。
Railpack 基于全新架构开发，从 Rust 转向 Go 语言并深度整合 BuildKit，带来了显著提升：
- 精细版本控制：告别过往模糊的版本锁定，支持
major.minor.patch精确版本，确保依赖稳定。 - 极致瘦身：经 BuildKit 优化，Node 镜像缩小38%，Python 更达77%，极大加速部署。
- 智能缓存：通过直接控制 BuildKit 层级，实现高效、跨环境共享缓存，并能锁定成功构建的依赖版本，提升构建稳定性。
Railpack 已在 railway.com 等核心服务稳定运行，并面向 Node、Python、Go、Php 及静态 HTML 部署开放 Beta 试用，特别为 Vite、Astro 等现代前端框架提供零配置支持，简化了全栈应用部署。此次升级不仅提升了开发体验，也为 Railway 拓展更广阔用户群体奠定了坚实基础。Railpack 现已开源，欢迎访问 railpack.com 了解详情。
原文链接：https://blog.railway.com/p/introducing-railpack
论坛讨论链接：https://news.ycombinator.com/item?id=44208968
社区围绕Nix技术讨论了其适用性和用户体验。一位Nix爱好者首先澄清，对Nixpkgs的“提交式版本控制”抱怨不尽准确，强调Nix不等于Nixpkgs，Nix工具支持任意版本拉取，且Nix依赖可轻易分层。他指出，将代码库从Rust转向Go可能与Nix无关，更像是团队或项目重构所致，并表示非Nix用户处理未完成的Nix方案时常遇挑战。
一位非Nix用户回应称，“Nix不等于Nixpkgs”的说法可能过于轻率。他认为，如果Nixpkgs是默认选择且替代方案需额外研究，那么对多数用户而言，Nix即Nixpkgs，并质疑依赖分层是否真正简单或默认。
另一位讨论者则指出，在生产环境中，Nixpkgs很少被直接使用，定制化和管理包集是专业公司的常态，覆盖任意版本轻而易举。他进一步表示，如果专业人士在核心业务功能上仍需“显而易见、简单、默认”的解决方案，可能存在技能文化问题，但也承认行业中普遍存在能力不足。
最后一位参与者则认为，这种将“行业充满无能”的论断，显得有些武断。
6. 梯度噪声：数字世界的“魔法画笔”炼成记 (Sharing everything I could understand about gradient noise)
Perlin噪声，作为一种应用广泛的“梯度噪声”，在视觉效果、视频游戏和程序化艺术等创意领域中扮演着举足轻重的角色。该新闻从GPU（特别是WebGL2/GLSL）的视角，深入浅出地剖析了梯度噪声的实现原理，从基础的一维案例逐步扩展到复杂的多维应用。
文章指出，构建高效的梯度噪声核心在于建立一个基于坐标的确定性伪随机系统。为优化GPU性能，作者详细介绍了“lowbias32”这一32位整数哈希函数，它能精准生成高质量的随机值。与传统的值噪声不同，梯度噪声通过插值随机“梯度”（而非直接的值）来构建信号，使其在整数坐标点处平滑地归零，从而产生更自然、连续的纹理效果。
随着维度的提升，噪声的实现涉及更复杂的点积与双/三线性插值。而通过叠加多层不同频率和振幅的噪声（即fBm，分形布朗运动），能够生成极其丰富且逼真的分形纹理，为虚拟世界增添无限细节。此外，文章还着重强调了噪声“导数”的重要性，它在地形生成、光照模拟（如计算法线）、物体表面凹凸感渲染等高级视觉效果中发挥着关键作用，并详细探讨了数值与解析导数的计算方法。
尽管原理深奥，但梯度噪声的强大功能为数字创意带来了无限可能。文章展望了OpenSimplex噪声、域扭曲等前沿技术，暗示着梯度噪声领域的未来仍有广阔的探索空间，持续激发着我们对科技与艺术融合的好奇心。
原文链接：https://blog.pkh.me/p/42-sharing-everything-i-could-understand-about-gradient-noise.html
论坛讨论链接：https://news.ycombinator.com/item?id=44201527
社区讨论围绕一个拥有“无尽”且“令人着迷”插画的项目展开，用户赞扬其视觉效果对阅读的激励作用。作者解释，插画并非预录动画，因噪音压缩带宽消耗巨大；项目利用着色器以极低的70KB大小实现了“无损且无尽”的视觉效果，技术选择“显而易见”地明智。
有成员指出，尽管解释出色，但“平滑噪音”风格似乎“过度使用”，期望有更多变体。另有评论者感谢阐述，认为虽数学复杂，但结果呈现清晰。
一位用户对其进行了“深刻而详尽的探讨”，分享了对梯度噪音的理解，并承认过去项目中忽视数学细节，现在深感导数和数值稳定性对实现平滑自然效果的重要性。他询问其他开发者是否有调整淡出函数以达完美波浪效果的经历。作者回应，淡出函数要求导数为零，并提供了相关资源。
此外，有用户探讨将3D Perlin噪音转化为高斯噪音，但立刻有评论者反问为何不直接生成高斯噪音，因理论上两者应无法区分。整体而言，社区对内容积极评价，认为其“既美观又富有信息量”。
7. Zig语言：突破性能瓶颈的优化利器 (Low-Level Optimization with Zig)
在追求极致性能的科技世界，程序优化至关重要。当传统编译器在优化时难以理解代码“意图”而遭遇瓶颈时，新锐语言Zig凭借其独特的低级特性和强大的“编译期执行”（comptime）功能，提供了革命性方案。
Zig允许开发者向编译器提供精确底层信息，从而生成高效、向量化的机器码。其核心comptime是一种独特的元编程能力，让Zig代码能在编译阶段运行，实现高级代码生成、泛型及基于已知数据的深度优化，例如，实现字符串比较的极致优化，显著提升程序运行效率。
comptime的无缝集成极大地简化了复杂优化。对于热爱探索前沿科技的中文读者而言，Zig无疑提供了一个新颖而强大的工具，助你轻松突破性能极限，让创意全速绽放。
原文链接：https://alloc.dev/2025/06/07/zig_optimization
论坛讨论链接：https://news.ycombinator.com/item?id=44208060
社区中，一位游戏开发者对Zig语言的构建系统、跨平台编译能力及高迭代速度表现出浓厚兴趣。他认为性能并非其选择语言的首要考量，更看重代码的未来兼容性和模块化，希望能构建可维护数十年的框架，并认为Zig有望匹敌C/C++的普适性。
另一位用户分享了在老旧Kindle设备上成功运行Zig的经历，对Zig的成熟度感到惊喜，指出许多功能开箱即用，甚至能用老版调试器解决问题，同样对Zig表示认可。
然而，讨论也触及了Zig在长期可维护性和模块化方面的争议点。有评论者认为，Zig的弱点在于其“敌视封装”的设计，不允许结构体成员私有化。他引用Zig官方的观点，即“私有字段是反模式”，字段应作为数据公开并精心命名为公共API。该评论者认为，如果不能隐藏内部表示，就无法合理地形成API契约，从而影响软件模块化和未来修改内部实现而不破坏用户代码的能力，并希望Zig能支持私有字段。
对此，有反驳观点指出，他个人多年来已不再纠结于“私有”设置，且未因此影响长期可维护性。他认为，API契约可以通过清晰的注释、文档字符串和示例来沟通，并借鉴Clojure的经验，建议划分独立的命名空间或代码区域来构建稳定、易用的公共API。他还强调，在某些情况下，开发者可能需要以非预期的方式使用内部组件，此时公开字段反而提供了必要的灵活性。
8. 克服拖延：职场突围之道 (Getting Past Procrastination)
还在等待灵感降临才开始工作吗？你可能陷入了“拖延-焦虑”的恶性循环。Y Combinator支持的科技职业平台Taro创始人Rahul Pandey分享了他的核心洞见：是行动催生动力，而非动力驱动行动。
作为曾在Meta和Pinterest等高增长科技公司工作十年的资深人士，Pandey也曾深受拖延困扰。他发现，顶尖工程师的秘诀在于建立一个能让他们持续高效的“系统”。这个系统的关键，就是将复杂艰巨的任务分解成微小的、可立即执行的步骤。例如，面对一个复杂的程序漏洞，不妨先从添加一行打印相关变量值的日志代码开始。
这个微小的成功会启动一个强大的“飞轮效应”：完成任务带来积极情绪，积极情绪又进一步提升效率。这个理念打破了必须等待“好状态”的迷思，将我们从被动等待转为主动出击。正如著名激励演讲家托尼·罗宾斯所说，“运动创造情绪”。因此，别再刷手机等待灵感了，从小处着手，你会发现动力随之而来，实现轻松高效的工作状态。
原文链接：https://spectrum.ieee.org/getting-past-procastination
论坛讨论链接：https://news.ycombinator.com/item?id=44207095
社区围绕“行动产生动力而非反之”这一观点展开讨论。一位用户分享经验，建议每天开始时先做一项微不足道的任务，这有助于迅速进入工作状态，并由此激发后续动力。这一方法在软件开发及其他领域均有效。
有评论指出，此法与海明威的写作习惯不谋而合——即在灵感充沛且已知下一步内容时停笔，以便次日能轻松接续。另有用户提及，该技巧虽有多种名称，如“时间分块”，但其核心原理始终有效，甚至对患有ADHD的人群也大有裨益，关键在于找到最适合自己的实践方式。
在具体操作层面，有用户分享了更实用的“黑客”技巧：刻意留下一个语法错误，或在代码中添加TODO注释，这样次日打开文件时能立刻明确工作中断处，无需花费时间恢复上下文，从而节省精力。还有人建议，每天下班前记下三件最重要的事情，同样有助于快速找回工作状态。
对于如何追踪这些标记，有讨论提出可利用Git的特性来查看工作区差异，或设置提交钩子（commit hook）以防带标记的代码被意外提交。不过，也有用户质疑Git在此处的直接查找优势，认为grep命令可能更为直接高效，而另一些人则强调这更多是个人习惯使然，因为他们在打开编辑器时会无意识地检查Git状态和差异。
9. WordPress迎来去中心化变革：FAIR项目重塑插件生态 (The FAIR Package Manager: Decentralized WordPress infrastructure)
WordPress生态系统正迎来一场深远变革。长期以来，社区对权力集中和治理不透明的担忧日益加剧，促使核心贡献者们积极呼吁改革。去年10月，AspirePress社区运行的插件镜像项目，技术上展示了去中心化的可能性。紧接着，20位核心贡献者联名公开信，强调治理改革的必要性。
在此背景下，一项名为FAIR（联邦式独立存储库）的创新项目应运而生。该项目现已正式成为Linux基金会旗下的技术实体，由Carrie Dils、Mika Epstein和Ryan McCue等三位社区领袖领导的技术指导委员会（TSC）负责，并由WordPress生态系统内的贡献者共同建设。FAIR的目标并非是“分叉”WordPress，而是在现有核心软件基础上，新增一个去中心化的分发层，并引入一套独立、透明且负责任的治理机制。
通过多月来的协同努力，FAIR已成功开发出分布式包管理系统、联邦兼容镜像、商业插件支持及加密签名等关键功能。这意味着，用户除了通过WordPress.org安装外，将拥有更多对插件交付的控制权，并享受到去中心化带来的灵活性和选择自由。FAIR致力于改善WordPress基础设施，实现更负责任的治理，为开放网络描绘出一条充满活力的新路径，彰显了开源社区“携手共建更优选择”的理念。更多信息可访问fair.pm。
原文链接：https://joost.blog/path-forward-for-wordpress/
论坛讨论链接：https://news.ycombinator.com/item?id=44207503
社区正在讨论Linux基金会发布的FAIR协议及其与WordPress的关联。一位评论者对FAIR协议表示欢迎，并将其与ATProto、IPFS等去中心化协议相比较，强调了普遍采纳通用协议的重要性。
然而，另一位评论者对FAIR协议的实施方法提出质疑，认为与其尝试“劫持”WordPress核心功能，不如采取WordPress软分叉的策略，并预测此举将因核心开发者的抵制而失败。该评论者还严厉批评WordPress联合创始人Matt Mullenwegg的“jkpress”文章极不专业。
对此，有评论者认为FAIR项目采取“不合理地合理”的开源贡献方式是明智之举。他们认为，如果Matt选择对抗，此举能为未来可能的分叉争取到社区的广泛支持，同时仍为Matt留下了接受或欢迎此努力，并逐步恢复信任的可能。
另一位社区成员则进一步证实了对Matt Mullenwegg的负面评价，指出他长期以来表现出刻薄、操控、不诚实的特点，并提供了相关诉讼和讨论链接作为佐证。
最后，有评论者对WordPress核心开发者会主动破坏FAIR机制的可能性表示怀疑，认为此举会损害大量插件和网站，与WordPress“一键安装”的核心卖点相悖。
10. 烟囱高耸的秘密：守护呼吸的科技防线 (Why are smokestacks so tall?)
空气污染，自人类用火以来便如影随形，与我们的生活交织。看似平常的烟囱，实则扮演着守护我们呼吸的关键角色。它从工业革命时期单纯追求燃烧效率，演变为如今应对空气污染的重要工程。
工程师巧妙运用“烟囱效应”，通过内部热气流与外部冷空气的密度差，产生自然上升气流，将排放物高效推向高空，促其稀释与扩散。这并非单一手段，更辅以催化反应器、静电除尘器、洗涤器等前沿技术，对煤电厂等排放源的氮氧化物、颗粒物和二氧化硫等200余种有害污染物进行源头净化。
烟囱的设计远非直观，需工程师们综合考量气团输送、扩散规律、风速风向、大气稳定性及地形建筑等复杂因素，确保污染物浓度符合国家环境空气质量标准。他们借助美国环保署（EPA）开发的先进模拟软件，预测并优化排放高度，平衡建设维护成本与公共健康效益。
正是这些不懈钻研的环保工程师，以其精湛的专业知识和严谨的科学态度，默默守护着我们赖以生存的清新空气，让现代生活在科技进步的同时，也能畅快呼吸。
原文链接：https://practical.engineering/blog/2025/6/3/why-are-smokestacks-so-tall
论坛讨论链接：https://news.ycombinator.com/item?id=44206553
社区讨论围绕工厂烟囱为何高耸展开。有评论指出，最初钢炉需要大量热量和压力推动碳燃烧，高烟囱通过产生更大的气流，提供了高效燃烧所需的温度和压力。尽管日本等国存在其他技术，但在工业革命时期，这些技术难以大规模应用。
关于“避免烟雾”的说法，许多评论认为这更多是后来的“补叙”。历史照片显示，19世纪烟囱的首要目的是提高燃烧效率，改善空气质量是次要效益。伦敦浓雾即是例证。随着柴油和电机的出现，强制通风技术取代了对高烟囱自然通风的依赖，工业烟囱的数量因此减少。但随着环保法规日益严格，空气质量才从次要效益转变为主要考量，促使使用过滤器而非仅仅增高烟囱。
讨论中，有用户认为社区平台能快速给出答案，比冗长叙述的“原文”更有效。然而，也有人反驳说，“原文”实为高品质工程教育视频的文字稿，旨在提供背景和历史信息，并非只为简单解答。另一位评论者提及德国的“高烟囱政治”，指出高烟囱初期是为了分散本地污染，后来则转向了使用过滤器解决问题。