31–40 of 66 posts
Postel's law aka robustness principle [1] can easily lead into accumulating complexity when implementations adapt to the bugs in other implementations. How could protocol designers mitigate this problem beforehand?
What is the general lesson we should learn from this? Postel's law aka robustness principle [1] can easily lead into accumulating complexity when implementations adapt to the bugs in other implementations. How could protocol designers mitigate this problem beforehand? [1]: https://en.wikipedia.org/wiki/Robustness_principle
For instance, a lesson learned by the Linux kernel developers: when adding a new system call to an operating system, if you have a flags parameter (and you should, which is another lesson they learned), if any unknown flag is set, fail with -EINVAL (or equivalent). Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features.
But it has to be since the beginning; once the protocol is "in the field", you can't increase the strictness without pain.
This reminded me of the best TCP timeout story I've ever heard, the case of the 500-mile email: http://www.ibiblio.org/harris/500milemail.html
Great story with the added bonus of showing me the GNU Units command. What a fantastic program, no more Googling when I need to convert stuff.
Earlier quoted context omitted.
Great story with the added bonus of showing me the GNU Units command. What a fantastic program, no more Googling when I need to convert stuff.
Indeed, I just checked OSX - sadly, units doesn't know about millilightseconds ("586 units, 56 prefixes").
This reminded me of the best TCP timeout story I've ever heard, the case of the 500-mile email: http://www.ibiblio.org/harris/500milemail.html
Great story with the added bonus of showing me the GNU Units command. What a fantastic program, no more Googling when I need to convert stuff.
Earlier quoted context omitted.
Indeed, I just checked OSX - sadly, units doesn't know about millilightseconds ("586 units, 56 prefixes").
GNU Units (available in Homebrew) is much more complete than the OS X version.
Since it took me a moment to figure it out, heres how to install it:
brew install gnu-units
then run as: gunits
So it lives happily besides the default units command.
What is the general lesson we should learn from this? Postel's law aka robustness principle [1] can easily lead into accumulating complexity when implementations adapt to the bugs in other implementations. How could protocol designers mitigate this problem beforehand? [1]: https://en.wikipedia.org/wiki/Robustness_principle
The lesson is "be strict in what you accept, since the beginning". For instance, a lesson learned by the Linux kernel developers: when adding a new system call to an operating system, if you have a flags parameter (and you should, which is another lesson they learned), if any unknown flag is set, fail with -EINVAL (or equivalent). Otherwise, buggy programs will depend on these flags being ignored, and you won't be ab…
I don't understand why that's true. Just add the new flag and use it for your new feature. Aren't buggy programs who were already sending the flag responsible for their own bugs?
Earlier quoted context omitted.
Indeed, I just checked OSX - sadly, units doesn't know about millilightseconds ("586 units, 56 prefixes").
GNU Units (available in Homebrew) is much more complete than the OS X version.
Earlier quoted context omitted.
The lesson is "be strict in what you accept, since the beginning". For instance, a lesson learned by the Linux kernel developers: when adding a new system call to an operating system, if you have a flags parameter (and you should, which is another lesson they learned), if any unknown flag is set, fail with -EINVAL (or equivalent). Otherwise, buggy programs will depend on these flags being ignored, and you won't be ab…
Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features. I don't understand why that's true. Just add the new flag and use it for your new feature. Aren't buggy programs who were already sending the flag responsible for their own bugs?
Earlier quoted context omitted.
The lesson is "be strict in what you accept, since the beginning". For instance, a lesson learned by the Linux kernel developers: when adding a new system call to an operating system, if you have a flags parameter (and you should, which is another lesson they learned), if any unknown flag is set, fail with -EINVAL (or equivalent). Otherwise, buggy programs will depend on these flags being ignored, and you won't be ab…
Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features. I don't understand why that's true. Just add the new flag and use it for your new feature. Aren't buggy programs who were already sending the flag responsible for their own bugs?
When the kernel breaks userspace, it's a kernel bug. It's a philosophy for system robustness that the kernel has and other operating systems tend to adopt as well. As you get higher up the stack into 3rd party libraries and other programming tools the maintainers often take a more cavalier approach to maintaining compatibility.