The real problem here
The real problem here
Posted Nov 11, 2010 12:58 UTC (Thu) by nye (subscriber, #51576)In reply to: The real problem here by bojan
Parent article: Glibc change exposing bugs
Which would of course be a great shame, because avoidably breaking existing applications is wrong, regardless of whether that program has a hidden bug in it or not.
Posted Nov 11, 2010 18:41 UTC (Thu)
by xilun (guest, #50638)
[Link]
Posted Nov 12, 2010 13:01 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
You can get yourself tied in some terrible knots this way. Chen's blog The Old New Thing is currently documenting how starting from [let's not annoy CP/M programmers] got them to [making an OS component optional causes security vulnerabilities in third party programs], over the course of a decade or so. Every step along the way is completely rational but the result is a confusing, insecure mess that's hard to reform.
But the alternative school, where everything not tied down and documented is up for grabs, and the tied down stuff might be cut loose and "deprecated" with relatively little notice, causes its fair share of problem as we've seen with the thread's topic.
Let me say this: It is very far from clear which of the alternatives here is better for anyone, from users to developers to OS vendors, let alone which would be best for all.
Posted Nov 12, 2010 17:48 UTC (Fri)
by jzbiciak (guest, #5246)
[Link]
I can just imagine trying to convince the glibc folks to autodetect SimCity to dynamically change how free() works.
The real problem here
Two schools
Two schools