TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Postel's Law and the Three Ring Circus

58 点作者 zdw大约 2 个月前

13 条评论

zamfi大约 2 个月前
As a counterpoint, Postel&#x27;s Law as implemented in other domains has been spectacularly successful.<p>One classic example is in transistor networks: each node in a network (think interconnected logic gates, but at the analog level) accepts a wider range of voltages as &quot;high&quot; and &quot;low (i.e., 1- and 0-valued) than they are specified to output. In 5V logic, for example, transistors might output 5V and 0V to within 5%, but accept anything above 1.2V as &quot;high&quot; and below that as &quot;low&quot;. (Sometimes called the &quot;static discipline&quot; and used as an example of the &quot;robustness principle&quot;—the other name for Postel&#x27;s Law.)<p>This is <i>critical</i> in these networks, but not because transistor manufacturers don&#x27;t read or fully implement the spec: it&#x27;s because there is invariably <i>unavoidable noise</i> introduced into the system, and one way to handle that is for every node to &quot;clean up&quot; its input to the degree that it can.<p>It&#x27;s one thing to rely on this type of clean-up to make your systems work in the face of external noise. But when you start rearchitecting your systems to operate close to this boundary—that is, you&#x27;re no longer trying to meet spec, because you know some other node will clean up your mess for you—you&#x27;re cooked. Because the invariable noise will now push you outside the range of what your spec&#x27;s liberal input regime can tolerate, and you&#x27;ll get errors.<p>The problem isn&#x27;t Postel&#x27;s law. It&#x27;s adverse selection &#x2F; moral hazard &#x2F; whatever you want to call the incentive to exploit a system&#x27;s tolerance for error to improve short-term outcomes for the exploiter but at long-term cost to system stability.
评论 #43494854 未加载
phkahler大约 2 个月前
I think there&#x27;s a related phenomenon that we see all the time in automotive circles. A vehicle manufacturer (OEM) needs a new thing, so a supplier develops it in cooperation with them. Great! The requirements were vague and all that, but you arrive at a solution that works. The supplier documents the performance in a <i>product specification</i> stating what it can do and under what conditions. Great! Next the OEM asks for quotes on next gen, and also goes to other suppliers to see if they can provide at lower cost. The OEM uses your product spec as a <i>requirements document</i> and this is where it all goes to shit (a product specification is <i>not</i> a requirements document). They no longer know what they need, but the know what they have and they want &quot;same or better&quot; next time. Over time this can lead to absurd specs and increased complexity to meet them. Sometimes a competitor comes in with a cheaper version and the OEM gets excited based on price and all the <i>actual requirements</i> might get revisited because the cheaper part is out of spec (to save cost).<p>This seems similar to the Postel&#x27;s Law thing. If you produce to spec but accept things out of spec, the ecosystem will unofficially change the spec to what&#x27;s actually out there. Then people will re-apply Postel&#x27;s Law with a wider spec on what you produce and even wider on what you accept. Eventually you end up with a complex mess, but in this case it&#x27;s a widening spec where in the automotive example it&#x27;s usually a narrowing spec.
kayo_20211030大约 2 个月前
Perhaps the specification is irrelevant, and it would be better to look at the actors&#x27; goals and incentives.<p>Using the OP&#x27;s example<p>As a first approximation, it&#x27;s reasonable to say that the goal of the closed source software&#x27;s producer is to <i>make money</i>, and the goal of the open source software&#x27;s provider is to have people <i>use it</i>.<p>The closed source software&#x27;s author has no incentive to continue to follow the specification unless it advances the goal of making money; and the open source software&#x27;s authors have no incentive to reject deviations from the specification if the result is a drop in usage.<p>Postel&#x27;s law still holds even in this asymmetric situation because that&#x27;s where the incentives are.
ChrisMarshallNY大约 2 个月前
<i>&gt; I encourage maintainers to reject user feedback that is much more properly directed to some commercial software vendor who has not implemented the specification correctly.</i><p>Words to live by.
评论 #43493566 未加载
ipython大约 2 个月前
I think there’s a temporal aspect to this. Postel’s law was the right idea <i>at the right time</i>. It allows for wide experimentation in the early growth curve while at the same time exploding the realistic user base (because these implementations could in large part talk to each other)
andrewstuart大约 2 个月前
A very wordy post, no really sure the point of it.<p>What I can say though is that Postel&#x27;s Law is a pile of rubbish that sounds sage and wise and leads to software problems.<p>Make software clearly defined in what you output and what you accept. Clear and strongly typed data interfaces help everyone get along with minimal bugs. Being “liberal in what you accept” is a recipe for errors.<p>Ref:<p>The Harmful Consequences of the Robustness Principle<p><a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-thomson-postel-was-wrong&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-thomson-postel-was-wr...</a>
评论 #43493380 未加载
评论 #43492913 未加载
roenxi大约 2 个月前
&gt; Ecosystems that adhere to Postel’s Law therefore experience a one way ratchet: consumers must accept more and more deviations from the specifications, and because consumers accept the deviations, producers are never forced (or incentivized) to themselves become stricter in following the specifications<p>He&#x27;s not wrong but this isn&#x27;t exactly true - it is sometimes the case that protocols will incentive conformity even while accepting liberally.<p>As a basic example, not failing on an unknown tag - say we have a system with emoji and if we sees an emoji tag we don&#x27;t recognise we print it in text. This is liberal in what it accepts because if someone typos an emoji it is still accepted, but they are nonetheless incentivised to get the spelling right because they were trying to get an emoji to display. The same principle means that most comemnts on HN are spelled correctly or close too.<p>So the truly inspired protocol will attach subtle costs to non-conforming emitters, but nonetheless tolerate them and allow them to participate in a network.
akoboldfrying大约 2 个月前
Agree, but I don&#x27;t think the incentives align as claimed -- with bad (lax) producers being usually commercial, and good (strict) consumers being usually open source. I think anyone who has already made a thing in program X and then finds that program Y won&#x27;t load that thing will tend to complain about program Y first -- both unconsciously, and also consciously (because if the bug is in X, they might need to recreate their thing, and nobody wants that). So even open source producer programs will tend to be favoured over open source consumers.<p>The ability to complain at open source consumers is real, but I think this form of pain probably reached its apex in commercial software: backwards compatibility in Windows. Raymond Chen&#x27;s blog The Old New Thing details the absolutely insane lengths Windows engineers went to to keep buggy software running on new versions of Windows.
评论 #43493180 未加载
robinhouston大约 2 个月前
I would find this argument more compelling if it were supported by examples. Although it’s easy to imagine this sort of dynamic unfolding, offhand I can’t think of any good examples of it happening with internet protocols in quite this way.<p>On the other hand, I can immediately think of an example to the contrary: I would at least partly attribute the failure of XHTML to the fact that conforming renderers were forbidden to be liberal in what they accept, and viewers of XHTML pages would often be faced with an error message in place of the page they wanted to see, as a consequence of some minor mistake.
评论 #43492465 未加载
评论 #43492501 未加载
评论 #43492377 未加载
评论 #43493935 未加载
mhb大约 2 个月前
This is an example of the broader explanation of why we can&#x27;t have nice things. In a high trust society, condiment packets are free with the expectation that customers will be reasonable in their use. Then customers take advantage of this to use the free ketchup to fill a wading pool.
gpvos大约 2 个月前
I think a fair amount of leniency with input is a good thing. The problem starts when you start to <i>increase</i> your leniency in response to someone else&#x27;s out-of-spec output.<p>A nice thing of open source projects is that they are freeer to call out other software that produces out-of-spec output, and I would encourage them to do so... liberally.
shadowgovt大约 2 个月前
Good essay.<p>Counter-argument: the Python setuptools outage this week (<a href="https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;setuptools&#x2F;issues&#x2F;4919" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;setuptools&#x2F;issues&#x2F;4919</a>) was more-or-less an exercise in ignoring Postel&#x27;s Law to the peril of the project. Python (as an ecosystem) had historically allowed hyphens and underscores in the `setup.cfg` file. The setuptools project deprecated this behavior years ago. This week, they tried to act on the deprecation and blew up multiple high-use dependencies.<p>The best way to avoid this issue would have been to never deprecate it in the first place; treating hyphen and underscore as the same had minimal impact on the codebase and made setuptools more compatible with other Python tooling.
评论 #43493027 未加载
zombot大约 2 个月前
When &quot;liberal&quot; means to permit deviations from the relevant specification, then normalization of deviance is a predictable outcome. I never interpreted &quot;liberal&quot; that way, but rather as accepting multiple input formats, and each one has to be used correctly. You cannot parse sensibly when you don&#x27;t know by what spec or syntax.