Recent Features
| |||||||||||||
This isn't either/or. Phase in such changes instead!This isn't either/or. Phase in such changes instead!Posted Nov 12, 2010 1:10 UTC (Fri) by dafid_b (guest, #67424)In reply to: This isn't either/or. Phase in such changes instead! by xilun Parent article: Glibc change exposing bugs
Firstly, I am sorry, I wrote as if I was posting a new post at the top level but posted to it as a reply to your post.. and then corrected by reposting clarified thoughts at the top level - not the right way to do things.
However, I think that the conversation we are having in this thread is a bit disjointed because when I say 'user' I mean a 3rd party to this conversation - not the Flash developer, not the Glibc developer, nor the crushfs developer.. but a simple user:). Whereas I think you read my user as 'developer'.
In the later post I liken (the knowing continued) delivery of this change to Glibc to mugging the person (user) who is near (uses the software written by) a jay-walker(developer who used undefined behaviour that used to work in the past).
That does not seem very fair to the user. It is sure to convince most users to stop being Linux users if the change does cause a security issue to happen - and they find out that it was a deliberate choice.
I think a better policy would be to mug the developer (send the crash reports, mocking messages in the trade press, or whatever).
This could be done by putting an intercept layer between Glibc in system tests that any user could load - at a known performance cost - that logs such violations of API requirements.
I would be happy, ecstatic even, to take part in such a mugging, when I am not doing my banking on the system.
Thanks for pointing out my other mistake - I should have said 'randomly activated bugs' rather than 'randomly inserted bugs' - as from both the end-user and developer perspective that is what is happening.
On your other points, I agree. However I think that the problem the points address is developer behaviour, and the person you mug is the user.
(Log in to post comments)
end user should not be punished, depending of distro target Posted Nov 12, 2010 2:28 UTC (Fri) by xilun (subscriber, #50638) [Link]
Even according to my position that the glibc has 0 responsability in the way Flash misbehaves, I agree with you that the end user should, when possible, not be punished. I think this is clearly the job of distributions, that can identify, given their target and if they have the occasion and resources, which interaction exposing a bug in some piece of software is acceptable, and which is not. Maybe some distributions will indeed make the choice of temporarily reverting this optimisation, but I hope Adobe will simply have enough time to fix their stuff before lot of distro are released, and if the timing is OK maybe the distributions could pressure Adobe by sending them a clear message that they will ship with the best technology anyway, so that it's up to Adobe to cleanup their mess if they want that flash continue working correctly under distro X. If the timing is bad, I would clearly prefer an automatised LD_PRELOAD style work around (if done transparently for the end user) to a whole system disabling of an optimisation.
But I would not even be angry against a distribution that makes the choice to not care at all about Flash. I perfectly understand that some can absolutely not care about Flash, in which case an angry user should just do a workaround himself or switch to an other distro, if he indeed is not in the target of the one he used.
end user should not be punished, depending of distro target Posted Nov 12, 2010 5:03 UTC (Fri) by dafid_b (guest, #67424) [Link]
we are in agreement mostly.
end user should not be punished, depending of distro target Posted Nov 12, 2010 19:28 UTC (Fri) by charlieb (subscriber, #23340) [Link]
> Maybe some distributions will indeed make the choice of temporarily
> reverting this optimisation
And wouldn't it be nice if Fedora 14 were to do this :-)
|
|||||||||||||