系统与基础设施spectrum.ieee.org
从软件开发者视角看波音 737 Max 灾难
How the Boeing 737 Max disaster looks to a software Developer
2019 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
IEEE Spectrum 的这篇长文从软件开发者的视角剖析波音 737 Max 两起空难：MCAS 系统依赖单一迎角传感器、反复压低机头，而波音为了规避适航认证和培训成本淡化了它的存在。文章还批评软件行业“先上线后修补”的文化惰性蔓延到了航空工程。
为什么经久不衰：它把复杂的航空事故讲成外行也能懂的软件工程教训，几年后重读仍是对“软件轻易可改导致设计草率”这一文化问题的有力警示。
HN 评论精选
补充分析：MCAS 累积触发、配平限值被改大、无法人工接管等多重设计缺陷共同导致空难
这篇分析很好，但有致命的遗漏。关键原因之一是 MCAS 每次触发都当作第一次：上次加 1 度配平，这次再加 1 度，直到加满 5 度把配平推到极限。其次，FAA 存档设计里每次最多加 0.8 度，测试后改成了 2.4 度，两次触发就可能几乎推到头。第三，唯一能压过 MCAS 的办法是切断配平电机电源，但 400 节以上时速时，用手摇柄回配平所需的力量超出真实飞行员的体力，尤其当他们还要全力拉杆。第四，有两台飞控计算机，飞行员可以（部分）关掉出故障的那台，却无法切换启用另一台，必须先落地才行。第五，它无视飞行员拼命拉杆这一明显信号。第六，它本可以对比另一台计算机的判断。
ncmncm查看英文原文
This is a very good analysis, but fatally incomplete. One really essential reason those planes crashed was that each time the MCAS triggered, it acted like it was the first time. If it added 1 degree of trim last time, it adds a second this time, a third next time, up to the five degrees that runs the trim all the way to the stops. A second reason is that, under the design still on file at the FAA, it could only add a maximum of 0.8 degrees (each time). This was raised to 2.4 degrees after testing, so only two hits could, in principle, put you almost to the stops. A third was that the only way to override the MCAS was to turn off power to the motor that worked the trim. But above 400 knots, the strength needed to dial back the trim with the hand crank was more than actual live pilots have, especially if it is taking all their strength to pull back on the yoke. A fourth was that, with two flight control computers, the pilot could (partly) turn off a misbehaving one, but there is no way to turn on the other one. You have to land first, to switch over, even though the other is doing all the work to be ready to fly the plane. A fifth was that it ignored that pilots were desperately pulling back on the yoke, which could have been a clue that it was doing the wrong thing. A sixth was that, besides comparing redundant sensors, it could have compared what the other flight computer thought it should be doing.
指出文章存在事实错误：737 是机械操纵、迎角无法目视判断
这篇文章读起来不错，但充满根本性错误。737 恰恰是当今少数仍将飞行员操纵装置直接机械连接到舵面的客机，驾驶杆与舵面之间有实打实的钢索，所以它其实有“自然手感”——这正是 MCAS 要解决的问题：在大迎角某些速度区间给驾驶杆增加力度以满足认证要求的线性响应。另外，飞行员也无法通过目视确认迎角，迎角没有视觉指示，作者把它和俯仰角混淆了——机头对准地平线时迎角仍可能高达 45 度。
DuskStar查看英文原文
This article reads well. Unfortunately, it's filled with fundamental mistakes. > In the old days, when cables connected the pilot’s controls to the flying surfaces, you had to pull up, hard, if the airplane was trimmed to descend. You had to push, hard, if the airplane was trimmed to ascend. With computer oversight there is a loss of natural sense in the controls. In the 737 Max, there is no real “natural feel.” Whoops. The 737 is one of the few airliners produced today that DOES still directly connect the pilot's controls to flying surfaces. There's literally 12mm wires connecting the yoke to the control surfaces. So, in fact, the 737 does have "natural feel". In fact, that's the whole problem MCAS was designed to solve - how to add force to the yoke when at high AOA in certain speed regions, in order to ensure a linear AOA response. (Certification requires something along the lines of "5 pounds force -> 5 degree AOA, 10 pounds force -> 10 degree AOA, etc") If the 737 was fly-by-wire, this force could be added directly in software. Instead, they added this force by changing the aircraft's trim. > In a pinch, a human pilot could just look out the windshield to confirm visually and directly that, no, the aircraft is not pitched up dangerously. No, you can't. There isn't a visual indication for AOA - the author is confusing this with pitch. You can have a 45 degree AOA while still having the nose of the plane pointed at the horizon. (The author mentions using the artificial horizon for this purpose, too) If you could read AOA from sensors that didn't require being exposed to the airflow, planes would use them. I'm sure there's more, and it greatly reduces my confidence in the article.
认同文章观点：软件易于更新助长了工程上的敷衍文化
“软件更新的便利和零成本在软件工程界造成了一种文化上的懒惰”——说得太对了。作为一个力求完美的人，看到外面那些粗制滥造的代码让我抓狂。我知道有人会说我“效率低”，但长期来看，先发布带 bug 的软件再回头修补反而更没效率。
rkagerer查看英文原文
I believe the relative ease — not to mention the lack of tangible cost — of software updates has created a cultural laziness within the software engineering community. -- This --^ As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts. I know folks here will deride me for being "inefficient", but in the long term I still maintain from my experience it's less efficient to push out buggy software and try to fix it retrospectively.
引用并赞同“软件文化惰性蔓延到硬件工程”的论断
这篇文章最好的一段：软件更新的便利和零成本造成了软件工程界文化上的懒惰；由于越来越多硬件由软件监控和控制，这种懒惰正蔓延到硬件工程——比如造客机。人们越来越少花心思在设计之初就把方案做对做简单，因为事后修补太容易了。我个人发现这种懒惰甚至蔓延到了建成后不受软件控制的领域，比如建筑和道路施工。
lqet查看英文原文
This is one of the best paragraphs of this great article: > I believe the relative ease—not to mention the lack of tangible cost—of software updates has created a cultural laziness within the software engineering community. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners. Less thought is now given to getting a design correct and simple up front because it’s so easy to fix what you didn’t get right later. Personally, I have noticed this laziness creeping into areas that are not controlled by software at all after they are finished, like building or road construction.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选